WO1999006967A2

WO1999006967A2 - Expected value payment systems for refunding balances on stored value cards

Info

Publication number: WO1999006967A2
Application number: PCT/US1998/016029
Authority: WO
Inventors: Michael T. Rossides
Original assignee: Rossides Michael T
Priority date: 1997-08-01
Filing date: 1998-08-03
Publication date: 1999-02-11
Also published as: WO1999006967A3; AU8681898A

Abstract

Herein disclosed are two general payment execution systems for stored value cards that incorporate expected value payment means for refunding balances on such cards. One system enables people to refund balances on cards whose account balances are stored on a central computer. The other system enables people to refund balances on cards whose balances are stored on a magnetic medium that is part of the cards.

Description

Expected Value Payment Systems for Refunding Balances on Stored Value Cards

Background — The Prior Art

The invention of this specification makes use of the expected value payment method (EVPM) of US Pat. 5,269,521. Certain novel methods, disclosed herein, are required to apply the EVPM to refunding balances on stored value cards. Although billions of stored value cards have been used over two decades, as far as the inventor knows, no one has proposed or implemented a system for refunding balances through EVPM bets.

Summary of the Invention

The invention is actually two related inventions. Each of these is a payment execution system for stored value cards that incorporates EVPM means for refunding balances on such cards. One system enables people to refund balances on cards whose account balances are stored on a central computer. The other system enables people to refund balances on cards whose balances are stored on a magnetic medium that is part of the cards.

Introduction

People who buy stored value cards, such as pre-paid phonecards and metro farecards, often do not want to use the full value of those cards and would like to get a refund for the unused balance. Yet, systems for enabling payment with these cards do not include convenient means for enabling refunds. Here we describe means for enabling refunds using the expected value payment method (EVPM) of US patent 5,269,521. In other words, we describe means that enable a user to make a refund bet where the user gets nothing refunded or gets an amount back that is larger than the balance.

Note: in this specification, except in Addendum 2, we assume, for the sake of simplicity, that the expected value (EV) of a refund bet equals the balance on a card. It is possible to set up a bet in which the EV is less than the balance, which can be desirable for a variety of reasons. Definitions

We define the following terms to be used in this specification:

A balance is the value that remains on a stored value card.

A refund bet is an EVPM bet for refunding a balance.

A bet signal is a command that is given to execute a refund bet.

A payoff is the amount that can be won in a refund bet by a user of a card.

An RN is a random number (integer) that is used to decide a refund bet.

An RNS is a random number supplier that is used to supply the RN. Also called a random number generator (RNG).

Dix is the name we use to represent a user or the user.

Definitions of Types of Stored Value Card Systems

There are three general kinds of stored value cards and corresponding payment execution systems (PES's).

1. Central Account Balance Cards (CAB Cards). These cards have an account number that corresponds to an account that is maintained in a central database that is accessed over a network. The two major sub-types of these cards are memory-aid cards and machine-readable cards.

la. Memory-aid cards have numbers printed on them and are really just memory-aids for people. The data storage and processing occur on a central computer database. Examples of these are pre-paid phonecards of the kind most commonly used in the US. Dix dials in to a central computer and enters the number of the phonecard. He can then use the value "on the card". In fact, the account information is on a central computer, the PES, that credits and debits money from the account.

lb. Machine-readable cards have an account number stored on a machine readable medium, usually a magnetic strip. The account information is read by an input device, such as a point-of- sale terminal, and then transmitted on-line to a central database where payment processing occurs. Examples of these are pre-paid giftcards that are read by online debit card terminals. The magnetic strip on this kind of card can also contain account balance information to enable an easy read-out of the balance using a card reading terminal. Still, the PES relies on the balance being maintained on a central database, rather than on the strip. 2. Magnetic Media Balance Cards (MMB Cards). These cards store payment data on a magnetic strip as, for example, metro farecards. Card readers add and subtract value. Here the PES is the card readers that take currency and/or other forms of payment and transfer it to the cards. Card readers can add value, subtract value or do both. In a PES for this kind of card the balance is held on the magnetic strip, not a central database.

3. Smartcards. These cards include internal chips with logic and memory means for recording and manipulating payment data. The methods disclosed for MMB cards are easily adapted to smartcards. Bets can also be executed by the logic means of the cards. We will not discuss smartcards because^' we would be repeating ourselves.

Organization of Specification

There are two generic ways that a signal can be given to execute a refund bet: Dix can "push a button" or an expiration date can be used as a default. We will discuss how both signals can be incorporated into PES's for CAB cards and MMB cards. In describing CAB card PES's, we give embodiments for memory-aid cards. Accordingly this specification has four main sections for describing core refund processes:

Section 1: The expiration date bet signal in PES's for memory-aid cards.

Section 2: The push-button bet signal in PES's for memory-aid cards.

Section 3: The expiration date bet signal in PES's for MMB cards.

Section 4: The push-button bet signal in PES's for MMB cards.

Where relevant, sub-sections and addenda describe features that can be added to these core processes. These sub-sections describe features that may apply to more than one kind of PES.

Section 1: Expiration Date Bet Signal in PES's for Memory-aid Cards

As our representative example of memory-aid cards we will have in mind pre-paid phonecards and their corresponding PES's.

The idea behind an expiration date bet signal is simple: the balance on a card is refunded through the EVPM at an expiration date. Thus, the PES executes the following steps to refund the balance on the card:

—periodically checks to see whether the expiration date has arrived,

—when the expiration date arrives, checks the balance in cents,

—if the balance is 0, stops.

—if the balance is greater than 0, gets an RN from 1 to the number of cents in the payoff,

—compares the RN to the number of cents in the balance, if the RN is greater than the number of cents in the balance, declares the card (identified by the card account number) a loser and sets the card account balance to 0. if the RN is less than or equal to the number of cents in the balance, declares the card (identified by the card account number) a winner and sets the card account balance to the payoff.

We say the PES "gets" an RN because, where an expiration date signal is used, the RN for deciding refund bets would commonly e one generated by a public RNG. Data identifying the RNG and the time that the RN is to be generated — e.g., the Powerball number on a given date — would be printed on the card. As with conventional lotteries, the RN's that decide bets would be posted in various ways so that Dix's could check them.

Another way to let Dix find out whether he has won is for the PES to include means for making a its database of refund bet results available via a website. The PES can capture Dix's account number through a webform, check the number, and if genuine, output the result of Dix's refund bet. Similarly, the PES can make results available by IVR means.

The payoff can be standard or the PES can include input means (interactive voice response means) for enabling Dix to set the payoff. These input means can prompt Dix to enter the payoff amount he desires. If Dix enters a payoff, the PES stores it as part of the card account information. Likewise, the expiration date can be predetermined or the PES can include means for enabling Dix to set the expiration date.

If predetermined, the expiration date can be set at the time of manufacture. If so, the PES stores the expiration date as part of the card account information.

Alternatively the expiration date can be a predetermined period of time after the first use of the card. In this case, after registering the first use of the card, the PES checks whether a balance remains at the end of the expiration period and, if so, executes a refund bet.

If the PES enables Dix to set the expiration date, and if Dix sets the date, the PES stores the date as part of the card account information.

Section 2: Push-button Bet Signal in PES's for Memory-aid Cards

Again, as our representative example of memory-aid cards, we will have in mind pre-paid phonecards and their corresponding PES's.

A basic way to cause a refund bet to be executed is by a human actuated signal, which we will call a push-button bet signal (even though the actuating mechanism does not have to be a button — it can, for example, be a voice command).

Thus, an interactive voice response PES for pre-paid phonecards can include commands for enabling Dix to signal that he wants an EVPM bet to be executed to refund the card balance. The payoff can be standard or, the PES can enable Dix to set the payoff.

Embodiment: A PES That Refunds Balances on Pre-paid Phonecards

Here we describe a PES that enables users of memory-aid, pre-paid phonecards to refund account balances though the EVPM. The PES is an interactive voice response system that includes conventional means for adding to and subtracting from account balances. In addition, the PES includes means for executing refund bets. The PES includes a refund command signifying that Dix wants to get a refund by the EVPM. For example, the PES might enable Dix to press "**" before placing a call, or after the completion of a call, or any time during a call, to instruct the system to execute a refund bet. As noted, the payoff can be standard or it can be variable. Below, we'll assume it is variable (settable by Dix).

Thus, when Dix enters a refund command the PES executes the following steps:

—prompts Dix to enter the payoff he desires,

—registers the payoff,

—checks the balance in the card account,

—supplies an RN that ranges from 1 to the number of cents in the payoff, if the RN is greater than the number of cents in the balance, tells Dix he has lost and sets the account balance to 0. if the RN is less than or equal to the number of cents in the balance, tells Dix he has won, gives him instructions on how to collect his winnings, and sets the account balance to the payoff.

The PES can also prompt Dix when his card balance dips below a threshold. For example, the PES might say, "Your balance is $1, do you want to have the amount refunded by a bet? You can win $100. Your odds will be 1/100. If yes, press "1".

Refunding Balances Via the World Wide Web Interface

It is also possible for the PES to include an input/output interface through a website. The user could then enter his phonecard number into a webform and the central database would return the balance. Then the user could enter a refund command and the PES could execute the refund bet.

A PES that Refunds Balances on Machine Readable CAB Cards

A PES for refunding balances on machine readable CAB cards incorporates the same basic procedures as described above. The main difference is in the way that the user interacts with the central database system. The card supplies the account ID data, via a card reading terminal. Thus, the initial steps of accessing the account are performed automatically. Then, the user would be presented with options, including the option to enter a refund command. The card reading terminal would also include display means for viewing the balance and showing the result of a refund bet. Anti-Cheating Mechanisms

One problem with the push-button bet signal is that the refund bet can be rigged in the PES's favor. Dix will want assurance that the bet is fair.

One anti-cheating method that lends itself readily to memory-aid cards is the use of a random number generating formula that is verifiably independent of the owner of the PES. By independent we mean that it is created by a neutral third party. The formula is stored by the PES and by the third party. The formula is tagged so that it can be identified.

The PES stores a tagged formula (or a pointer to it) as part of a card's account information. This formula is the one that is used for that card account. (The PES can store different formulas for different accounts.)

An advantage key to using an independent RNG formula is that the seed value for the formula can be the date Dix decides to do a refund bet. (It can also be the date and the account number.)

Thus, when Dix initiates a refund bet, the PES executes the following steps:

—gets the formula that corresponds to card account that Dix is using,

—feeds the current date into the formula,

—calculates the RN,

—uses the RN to decide the refund bet.

The formula is verifiable in the sense that if Dix wants to verify the RN he can contact the third party's server and enter the tag and the date of the bet. The third party's server will then find the^" formula corresponding to the tag, feed the date into the formula and, output the resulting RN. Dix can then see if it is the same RN as was used in his bet with the PES.

In order for Dix to verify an RN, of course, he needs to know the tag and how to contact the third party's server. So, a phonecard would have the tag printed on it along with contact data for the third party. Alternatively, Dix's card account can be associated with the formula so that Dix can merely enter his account number, which would serve as the tag.

In order to stop Dix from finding out the RN before he initiates a bet, the third party server can verify the RN for a date only after that date is past. As a variation on the anti-cheat method above, Dix can enter the seed value by IVR means. This method is fair as well — since the PES cannot influence the seed value Dix enters — but it is not as simple as using a date.

Another variation is to have the PES store a tagged RN input with each card account. (The PES's RN input is verifiably independent in the sense that it is tagged and stored by a third party.) In this variation, Dix enters an input that is combined with the tagged RN for his card account.

If an anti-cheat method is used where Dix enters an input, then measures must be taken to insure that Dix does not cheat. One such measure is for the PES to store a release key along with a tagged RN. This key would be needed to verify an RN. Otherwise, before Dix decided to do a refund bet, he could check which resulting RN corresponded to his input. So, the PES can store a release key along with an RNG formula or a tagged RN input. After a bet is decided for Dix's card account, the PES outputs the key.

Another way Dix can be prevented from cheating is to have the third party server alert the PES every time that Dix checks an RN. If he tries to check an RN in advance of initiating a bet, he can be disqualified. In this case, the third party server can be considered part of the PES.

Collecting the Payoff

One way the PES can refund a balance is by crediting the payoff back to the card when Dix wins^" the refund bet.

Another way is to send Dix a check. (When we say "send a check" we mean that the PES registers that Dix is owed the payoff and that the PES might employ some method for transferring the payoff to Dix's bank account.)

If Dix wants a check there must be a way to identify him.

One simple way is for the PES to include voicemail means that let Dix enter his ID data such that the PES registers that the voicemail message corresponds to the winning bet. Human operators can then check the voicemail to capture the ID data. Alternatively, the PES can output a redemption phone number that Dix can call to talk to a human operator. Another simple way is for Dix to mail in a winning card, along with his name and address, to a redemption center.

The PES can also enable Dix to enter contact data, such as a phone number, in advance of the execution of a refund bet. For example, if the phonecard is sold through a website, Dix can enter his phone number into a webform. Another way contact data can be given is through IVR means whereby the PES prompts Dix to enter his phone number using a phone keypad the first time he uses his card. The phone number is captured and can be used in the event that he wins a refund bet.

Whenever the PES "sends a check" it can register the fact that the corresponding bet debt has been paid for that account. However, the "send-a-check" functionality may be separate from the functionality for maintaining account balances and executing bets.

Combining Refund Methods

It is possible, of course, for a PES to enable users to refund card balances by either an expiration date signal or by a human actuated signal. Dix can be given the option of refunding any time he is using his card. If he chooses not do to so within a given period of time, the expiration date becomes the signal for executing a refund bet. In other words, if Dix does not actuate a refund bet by an expiration date, and if a balance remains on his card after this expiration date, then the PES automatically executes the refund bet.

Section 3: Expiration Date Bet Signal in PES's for MMB Cards

In thinking of MMB cards and their corresponding PES's, we will have in mind two examples: a copicard of the kind most commonly used to pay for photocopy machine services and a farecard of the kind most commonly used to pay for transportation services.

By copicard we will mean a card that is dispensed by a PES that does not print anything on the card. The balance can only be seen by inserting the card into a PES card reader which then displays the balance. (Pre-printed instructions may be on the card telling Dix how to use it.) By farecard, we will mean a card that is dispensed by a PES that can print information on the card. Pre-printed instructions may also be on the card telling Dix how to use it.

Using an expiration date as a signal for copicard and farecard refund bets is simple. At the expiration date, the refund bet is executed. The bet is decided by an RN that is generated by a public RNG. The bet terms are set on the card. The identity of the public RNG will be preprinted on the card. If the payoff is standard then it too can be pre-printed on the card. The expiration date may also be printed on the card.

However, most PES's for MMB cards do not write an expiration date onto the magnetic strips of the cards. In order for the expiration date method to work, the PES must include means for writing the expiration date onto the magnetic strip of the card.

As with a conventional lottery ticket, it is up to Dix to check whether he has won. If he has won he can send his card to a redemption center that can verify the result and send him a check.

The problem with this method is that Dix can potentially cheat by changing the balance after he sees the RN. Therefore, the PES must stop Dix from changing the balance. Further, the PES must prevent Dix from using a card on or after its expiration date. Otherwise he could check if he won on the expiration day, and if he lost he could continue using his card. Thus, the PES must include means for checking the expiration date on cards and rejecting expired cards.

PES's can also include input means — buttons — for enabling Dix to set the expiration date and the payoff amount to be stored on a card that is dispensed to him. This data is magnetically stored just like balance data. The data can then be verified at a redemption center. (Note: if the PES can print on the card, it can print the expiration date and the payoff on the card.)

Section 4: Push-button Bet Signal in PES's for MMB Cards

(As above, we will have in mind copicards and farecards and their corresponding PES's.) To incorporate a push-button bet signal, a PES will include a button that, when pushed, signifies that Dix wants a refund bet to be executed. After Dix pushes the button the PES executes a bet. The payoff for the bet can be standard. Or, the PES can include means for enabling Dix to enter the payoff The PES can include a set of predetermined payoffs that Dix can choose from, or the PES can include means for enabling Dix to enter any payoff he desires.

The advantage of having variable payoffs or multiple, pre-set payoffs is that smaller payoffs can be used as trade while the bigger payoffs can be redeemed for cash. For example, one payoff can be set at one full metro fare, while another can be set a $100. The smaller amount would normally be chosen by someone who wanted to use the card to pay for additional service while the larger amount would more likely be redeemed for cash.

Embodiment: Dispenser for MMB Cards

We now describe a PES that enables refunds of balances left on MMB cards. The PES in this case is the machine that credits value to cards. We will take metro farecards and a farecard dispenser as our example. The dispenser enables people to insert cards so as to add value or get refunds. The dispenser includes a button for executing a refund bet. The dispenser also includes means for setting the payoff of a refund bet.

Thus, the PES is a conventional card dispenser including logic means for executing refund bets, an input button for signifying that Dix wants to do a refund bet, and buttons for entering the payoff amount of refund bets. After Dix inserts a card, the PES executes the following steps: —reads the balance, —checks to see if the refund bet button has been pushed, if not, allows Dix to add credit to the card through cash payments, if yes, checks to see if a payoff has been entered, if no, displays a message telling the user to enter a payoff, if yes, registers the payoff and supplies an RN that ranges from 1 to the number of cents in the payoff, compares the RN to the number of cents in the balance, if the RN is greater than the number of cents in the balance, keeps the farecard and displays a message saying Dix has lost. if the RN is less than or equal to the number of cents in the balance, dispenses a new farecard having the payoff value. Anti-Cheating Mechanisms

The problem with the method above is the potential for the PES to cheat. Dix would like some assurance that the refund bets are not rigged.

Using Verifiably Independent Random Numbers

The anti-cheat methods using tagged RNG formulas and tagged RN's, described in Section 2, can be used with MMB cards as well.

There is no real difference in steps that the PES performs, and only minor differences in mechanisms. The PES card reader stores an RNG formula (or RN input) to correspond to a card, and the PES can display the tag for a card's formula — just as it displays the balance — when the card is inserted into the reader. (Alternatively, the card can have the tag preprinted on it.) If the PES enables Dix to enter a seed or an RN input, then the PES will also include input means for this purpose.

Preventing Cheating by the Real Time Display of Bet Result Tallies

Yet another anti-cheat method is for the PES to display a real time, running total of its bet results — its net profit or loss from bets and it's profit or loss margin. Let us be a little more specific and define a few terms.

What the PES can win in a bet is Dix's stake, which is the balance. We will also call it the PES's winnings in a bet.

What the PES can lose in a bet is the PES's stake, which is the payoff minus the balance. We will also call it the PES's loss on a bet.

We will call the sum of winnings the total winnings. We will call the sum of losses the total losses.

The total profit (it can be negative) is total winnings minus the total losses. The total amount risked by the PES is the sum of the PES's stakes that the PES has risked in all its bets.

The profit margin (it can be negative) is the total profit divided by the total amount risked.

The PES can keep a running display of its total winnings, total losses, total profit and profit margin. The PES does not have to display all of these figures to demonstrate that its bets are fair, but it can do so.

The key to making this display an anti-cheat mechanism is that the result statistics are shown in real time and are affected by Dix's bet. Thus, Dix can see his bet reflected in the result totals. If Dix loses, he can see the PES's total profit go up by the amount that he lost. And if Dix wins, he can see the PES's total profit go down by the amount that he won.

Thus, in addition to the steps described above for executing refund bets, a PES can execute the following steps: —decide the bet, if the PES wins the bet, add the winnings to the total winnings, if the PES loses the bet, add the loss to the total losses, —calculate the total profit, —calculate the profit margin, —display total winnings, total losses, total profit, and the profit margin.

Since every Dix can see this happening, the PES cannot cheat. (This method is vulnerable to cheating in which the PES is rigged in favor of the owner of the PES. The owner can "normalize" results by artificially losing bets when no one is looking. However, this cheat can usually be detected by anyone who observes the PES regularly.

(We note that this method of preventing cheating can also be used in cash registers, vending machines and other publicly displayed payment systems that can incorporate the EVPM.) Addendum 1: Having a Third Party Execute the Refund Bets

The CAB card PES's described above can enable refund bets to be executed by a server controlled by a third party which we will call a neutral, bet server (NBS). Using a third party reduces concerns about rigged bets.

Where the expiration date signal method is used, the PES transmits to the NBS a list of accounts that have expired and their balances. The NBS can then execute refund bets for all of those accounts. The results can then be transmitted back to the PES. Users can find out the results by querying the NBS which can have any of several number of input/output means for enabling users to check whether they have lost or won their bets. If the PES reports the results then the NBS can act as a verifying server.

Where the push-button signal method is used, the PES can transmit the bet terms to an online NBS in real-time. The bet terms would include the account number, the balance and the payoff. The NBS then transmits back the result to the PES which can then report the result to Dix in real time. The NBS can also act as a verifying server.

In addition to executing bets, the NBS can also include means for handling the paying off of winning bets.

Addendum 2: Enabling Different Balances for Purchasing and Refunding

As noted in the introduction, the EV in a refund bet may be less than the balance on a card. In practice, this will usually be the case, if only to allow the card issuer to recover the costs of transacting refunds.

There are other reasons. Stored value cards are used, predominantly, to pay for something sold by a particular vendor, for example, phone service or subway transportation or gifts from a particular store. Because of this fact, the vendors who issue these cards have an incentive to establish two kinds of balances, one for purchasing something from the vendor, and one for refunding the balance.

In some cases, having separate balances is the only feasible approach, as when the cards are sold through a middleman — for example, a phonecard being resold through a retail store — because when a user refunds a balance, it is hard to get the money back from the middleman. In practice, the user will normally have to settle for a refund balance that is substantially lower than the purchase balance.

Thus, we will define a purchase balance as the amount of value on a card for purchasing a particular product or service from the issuer of the card.

We will define a refund balance as the amount of value on a card available for refunding. The refund balance will be equal to or less than the purchase balance. The refund balance would normally be a simple percentage of the purchase balance (minus, perhaps, some flat charge). For example, the refund balance might be 80% of the purchase balance.

In order to implement separate balances, would include an algorithm for converting the purchase balance to the refund balance, and could output both balances, or it can include means for outputting the refund balance upon a request from the user. (Depending on the embodiment, the PES might not include means for outputting the refund balance.)

The main modification to the PES's described above is that the EV of a refund bet equals the refund balance not the purchase balance. Thus, for example, given a PES incorporating the push-button bet signal method for CAB cards: the PES, upon receiving a refund signal from the user, calculates the refund balance from the purchase balance and executes a bet where the EV equals the refund balance, and outputs the results.

Addendum 3: Incorporating Threshold Rules for Refunding Balances

The meta-rules of a PES might hold that the balance on a stored value card must be below a threshold in order for a refund bet to be executed. Further, they might hold that a certain percentage of the original balance on a card must be used up before a refund bet can be executed. Thus, a PES's logic means can incorporate such thresholds and check against them when Dix attempts to initiate a refund bet using a push-button signal. In other words, upon registering a push-button bet signal, the PES checks to see if the balance is less than or equal to a threshold, if not, the bet is canceled and the PES outputs a message telling Dix that his balance is too high to conduct the bet. (Likewise, an expiration bet signal can be nullified if the rules thresholds are not met.)

Claims

ClaimsI claim:

1. a payment execution system for stored value cards that includes means for refunding the balance on a card, said system comprised, in combination of a computer database system for storing credits and debits to a card account, maintaining balance data, and outputting said balance data,

said database system being connected to a network of terminals for enabling the user to interact with the system and enter data for identifying the user's account and for entering instructions to the system,

said system including means for registering a refund command from said user, and for registering a payoff amount desired by said user,

said system executing the following steps for refunding the balance in a user's card account when the user enters a refund command:

ΓÇöprompts the user to enter the payoff he desires,

ΓÇöregisters the payoff,

-checks the balance in the card account,

ΓÇösupplies an RN that ranges from 1 to the number of cents in the payoff, if the RN is greater than the number of cents in the balance, tells the user he has lost and sets the account balance to 0. if the RN is less than or equal to the number of cents in the balance, tells the user he has won, gives him instructions on how to collect his winnings, and sets the account balance to the payoff.