WO2000030015A1

WO2000030015A1 - Online systems for enabling expected value payments

Info

Publication number: WO2000030015A1
Application number: PCT/US1999/027583
Authority: WO
Inventors: Michael T. Rossides
Original assignee: Rossides Michael T
Priority date: 1998-11-19
Filing date: 1999-11-19
Publication date: 2000-05-25
Also published as: AU3102000A

Abstract

An online system for registering payment obligations and executing expected value payment bets. To this core, a variety of enhancements are added including for: transferring payment, preventing fraud, guaranteeing payment, assigning payment, and charging users and rewarding users for given actions. Thus, the system can range from a minimal system for registering and executing payment bets to a system that acts as an online bank that utilizes the expected value payment method.

Description

Online Systems for Enabling Expected Value Payments

Description

Organization of this Description

The object of the invention is to enable expected value payments through an online database system. Let us give some example applications:

• A company might use the invention to pay an individual a small amount of money — such as a small dividend, utility bill credit or gift certificate refund — because small, definite payments entail high transaction costs.

• A company might use the invention to pay an overseas company an amount under $1000 because international payments come with high transaction costs.

• An individual might use the invention to pay another individual an amount of money electronically because there is no good way currently for individuals to pay each other electronically.

• An individual might use the invention to pay a merchant an amount of money because an expected payment may have lower transaction costs for the merchant than a definite payment.

• An airline might use the invention to pay a customer an amount of frequent flier miles because there is no good way to redeem amounts that are under the threshold for a free trip or upgrade.

An invention that enables such expected payments can incorporate a variety of features (e.g., a process for insuring payment) and therefore can take a variety of forms. Any combination of features will be built around a core process for executing an EVP bet between two parties.

This core process — and core system — can be configured in two ways that seem basically the same and yet have important differences.

One process executes an EVP bet where the result is revealed by the payer, in the sense that the payer operates the system and the result is automatically reported to both parties after the bet is executed. This process is useful where both parties have pre-agreed upon bet terms. For example, a company and a shareholder may have pre-agreed that dividends are to be paid by the EVPM. In this situation, the core process of invention will not need to include steps where the recipient of the payment determines when and if the result of the EVP bet is revealed.

The other version of the core process executes a bet and enables the recipient to decide when and if the result is revealed. One reason for this version is that it enables her to signify agreement to the bet terms. Another reason is that in its unrevealed state a bet payment has a value, the EV, that can be transferred. Thus, the system can enable the recipient to transfer this value — to transfer the bet payment whose result is revealed. This capability can be important in a variety of applications.

Accordingly, this description has two Parts, the first describing features added to the first core process, and the second describing features added to the second core process. Most of the features are the same, so Part II will often refer to features that are defined in Part I. Both Parts share the same basic definitions which are given at the start.

We call a computer that operates the core process the core system.

Contents of the Description

Basic Definitions

Part i Processes with Recipient Not Involved in Bet Execution

Section 1 Core Payment Process

Section 2 Payment Transfer Functionality

Part 2 Processes with Bet Result Revealed by the Recipient

Section 3 Core Payment Process Revisited

Section 4 Recipient Form and Processes

Section 5 Transferring Expected Payments

Section 6 Bank Features Basic Definitions Used in this Description

Here we give definitions that will be used throughout this description. Additional definitions will be introduced as needed.

The payer is a party that is paying an amount of money (or other commodity) to another party, the recipient. We also call the payer Paul.

The recipient is a party that is to receive an amount of money (or other commodity) by another party, the payer. We also call the recipient the receiver or Reece.

The payment amount (PA) is the definite amount of money (or other commodity) that is intended to be paid by the payer to the receiver.

An EVP bet is a bet between a payer and recipient where the expected value (EV) to the recipient equals the PA. Note: in this specification, we usually assume, for simplicity, that the EV of a bet equals the PA. It is possible to set up and execute a bet in which the EV is less than the PA, which can be desirable to recover costs.

The expected payment (EP) is the payment amount paid by the expected value payment method.

The payoff is the amount that can be won in an EVP bet by the recipient.

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

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

A procedure is a set of steps that the system executes to perform a task. We will think of procedures as modules that operate together in an overall system. A module represents a particular task and the procedure for performing that task, e.g., a payment transfer procedure. We take a modular approach in this description because it makes it easier to envision how the core process can be enhanced. When we use the term enhancement ox feature we have in mind the input/output means, memory means, calculation means and program means for performing a task. Hence, we can also think of enhancements and features as modules.

Note too that we usually refer to the invention as the system.

Part i Processes with Recipient Not Involved in the Bet Execution

Section 1: The Core Payment Process

In many payment situations, Paul and Reece will have agreed upon payment terms at some time before payment is actually transacted. For example, a utility company might have a policy of making refunds of customer deposits according to certain terms, and customers may agree to these terms upon signing up for the utility's service. In such situations where the Paul and Reece have agreed to use the EVPM, a neutral agency for executing the EVP bets can be operated by Paul alone without Reece's involvement. The agency can enable Reece to verify that the EVP bet was conducted and reported properly by Paul.

Hence, the core process of the invention enables an online database system — the core system — to execute, record and verify EVP bets. Minimal Core System

In its most minimal form, the core system includes an online interface — for example, a webform — and registers the following data: (a) a payment descriptor and (b) an RN range. These two pieces of information are enough if Paul does not want to enter the PA and the payoff. He simply identifies the payment in question with a descriptor and specifies a range for the RN that decides the bet, i.e., a range of integers 1-N inclusive.

Thus, when Paul has entered the descriptor and the RN range, the system:

—supplies an RN in that range,

— timestamps the RN generation,

—stores the RN to correspond to the payment descriptor,

—outputs the RN to Paul in a webpage.

The system also includes an interface for enabling Reece to search the system database to verify the RN that was used for the EVP bet between Reece and Paul. The system enables Reece to search the system database by entering the payment descriptor. Thus, when Reece enters the payment descriptor, the system searches for the corresponding payment and RN. If the system finds it, the system outputs the RN range Paul specified, the RN the system supplied to Paul, and the time/date the RN was supplied.

We have assumed web based I O mechanisms, but other mechanisms — such as interactive voice response means — can be employed.

The Core System

For most applications the functionality above is too little, so we will describe a core system that has more functionality.

Core System Interface The core system will include a webform interface — that we call the EVP form — with the following fields that Paul enters information into:

(Note that when we say field we have in mind a field or set of fields. Whether multiple fields are necessary depends on the implementation.)

Payer. This field is for identifying the payer. This field can automatically be filled in by the system if the payer is authenticated by a log-in procedure. (Note: the payer may be a company/organization and therefore an additional field for the signer might be necessary.)

Payer Contact Data (possibly). This field is for entering contact data so that the payer can be told of the bet result. This field is unnecessary if the payer has established an account with the system. It is also unnecessary if the output is only by real-time output to a webpage.

Signer (possibly). This field is for stating the person responsible for making the payment, e.g. a company employee.

Recipient (Pay to). This field is for identifying the recipient.

Recipient Contact Data (possibly). This field is for entering contact data for the recipient so that the recipient can be told the result of the EVP bet. This field is unnecessary if it is understood that the payer will contact the recipient about the bet result.

Payment Descriptor. This field, like the "memo" field on a paper check, is for describing the payment.

Payment Amount (also referred to as the Expected Payment ). This field is for stating the expected amount that the payer intends to pay the recipient.

Type of Commodity (possibly). This field is for stating the commodity that is being paid. This field is unnecessary in most cases since the commodity will in most cases be understood (e.g., dollars, yen, frequent flier miles).

Payoff. This field is for stating the payoff for the recipient of the EVP bet. The payoff may default to a standard in which case this field not necessary. The webform will also include an Execute button that Paul clicks on when he is ready to submit the payment information and have the EVP bet executed according to that information.

The system will create and store a transaction record of the EVP bet.

Creating and Using a Payer Account

User accounts are well known and need no elaboration. Suffice to say that the system can include means for enabling Paul to create a payer account so that Paul can enter ID data for authentication purposes and contact data so that the system can send him e-mail messages (if necessary).

The core system does not necessarily require payer account functionality, since the system can simply be a neutral resource for executing and recording EVP bets, but we assume that in most implementations that a payer account is employed, at least for authentication purposes. Thus we also assume that the system includes a log-in procedure.

Core Sequence of Operations

The core system will execute the following steps for enabling Paul to execute an EVP bet between him and Reece:

—authorizes/authenticates the payer,

—outputs EVP form to the payer,

—receives submission of the form,

—verifies that the form has been completed,

—supplies an RN in the range dictated by the payment amount and payoff,

—determines the result of the bet,

— timestamps the result

—stores a transaction record that includes the result, the EVP form data, the timestamp, and a transaction ID,

—outputs the result (and possibly the full transaction record) to the payer.

Accessing a Completed EVP Form In addition to this payer sequence, the system will also include a process for enabling Reece to verify the EVP transaction. Thus, the system includes means for outputting a search form to Reece enabling her to search the system database according to a variety of parameters, including her name, the payer's name, the payment descriptor and or a transaction ID. Upon receiving search criteria from Reece, the system outputs the corresponding transaction record, which includes the all the data entered into the EVP form by Paul and all the data outputted to Paul.

The system can, of course, enable Paul to use these search means as well.

The system can include means for restricting access to the transaction record through password protection, or other authentication mechanisms.

Assessing Charges

If the system is financially supported through payer fees charges then it will also include functions for assessing charges to Paul.

Account Statement for Payer

The system can include means for grouping transaction records to create an account statement that lists, summarizes and tallies all the EVP transactions Paul has made over a given period of time. The system will also include means for outputting an account statement to Paul.

Interactive Voice Response Interface

The system can have an interactive voice response (IVR) interface. An IVR interface can be useful, of course, because it enables Paul to make payments without entering data into a display screen interface.

If the EVP form is presented by an IVR interface, the EVP form can be simplified so that, after authorizing Paul, the system presents the following data input fields: payment descriptor, the payment amount, and payoff (which may be standard). Upon receiving this data, the system prompts Paul to enter an Execute command. Upon receiving that command, the system: supplies an RN, declares and outputs the result, timestamps the transaction, and stores the result in a transaction record.

The IVR interface will also include search means and prompts for enabling Paul and Reece to find the transaction record by entering the appropriate payment descriptor and (payer account ID if necessary).

Automated Data Entry Interfaces for Paying Multiple Recipients

It will be useful for the system to also enable Paul to enter EVP form data automatically. Automated data entry is likely to be the implementation of choice, of course, where Paul must make a large number of small payments (such as a company paying stock dividends or an airline making frequent flier point refunds).

Automated processes for inputting data into webforms are well known. Paul himself can have an interface that feeds individual, completed EVP forms to the system by an suitable protocol (e.g., TCP/IP, FTP, and SMTP).

In addition the system can enable Paul to send a list of recipient records, each record having the EVP form data described above for an individual payment transaction. The list of recipient records can be received by any suitable protocol. The system will read each record from the list and execute a bet for each.

Section 2 : Adding Payment Transfer Functionality

Organization of this Section

The system can include payment transfer functionality for taking payment from Paul and disbursing payment to Reece. (We assume the commodity being paid is money although virtual commodities, such as redeemable "points", can be transferred by analogous mechanisms.) Payment transfer means are well known yet we elaborate a little so that we can trace the flow of money in and out of the system and explain useful enhancements. We describe in turn: Getting money into the system.

Getting money out of the system.

Transferring the payoff risk to the system

Anti -fraud procedures.

An illustration of an international, expected payment.

A. Getting Money Into the System

To enable Paul to make payment into the system, the system can include electronic funds transfer means, such as means for receiving credit card payments and wire transfers. The system can also include means for registering payments by paper check.

The system can enable Paul to make a payment without establishing a bank account for him. It can simply take payment for a given EVP bet transaction — through the means discussed above — and can register that payment only for that transaction. For example, the system can let Paul make a payment of, say, $25 with a credit card. This payment can be applied to a single EVP bet and does not have to be registered in an account that stores records of multiple transactions.

Alternatively, the system can enable Paul to make payment into a payer bank account. This kind of account is useful if Paul is making multiple payments through the system. Thus the system can include well known processes for creating a bank account and maintaining bank account information for Paul — registering credits and debits to the account, and calculating and outputting balance information. If the system includes payer bank accounts it can enable Paul to deposit a sum of money to be applied to any number of EVP bets.

If the system transfers payment then the EVP form can include a field for the mode of payment (e.g., credit card, debit account, wire transfer, etc.).

B. Getting Money Out of the System

There are two basic ways that the system can enable Reece to withdraw money from the system:

(1) it can send her a check and

(2) it can transfer the money to an account outside the system by electronic funds transfer EFT means (e.g., by wire transfer). Thus, the system will include well known, automated processes for creating and sending paper checks or for transmitting the necessary data to an agent that will create and send the paper checks. Likewise, the system will include well known processes for executing EFT's.

For either of these payment methods to be used the system must register enough information about Reece's identity to effect payment. What data is sufficient depends upon the mode of payment. If a paper check is to be used then Reece's legal name and her physical address are necessary. If a wire transfer is used then a bank routing number is needed.

Thus, the system will include a form for enabling Reece or Paul to enter the data needed to effect the payment transfer. (As discussed below, the system will also incorporate methods for authenticating Paul and/or Reece.) The system can enable Paul to enter the receiver payment data in the EVP form before the bet result is known.

Alternatively, the system can output a winner's redemption form to Paul and/or Reece if Reece wins the bet. This form can be outputted when the result of the bet is outputted.

The system can have a redemption webpage with a webform for enabling Reece to enter authentication data for claiming the payoff.

Who enters the payment data, and when, depends upon the situation and the implementation.

The system can also enable Reece to create a receiver bank account where the system can accumulate payoff and/or expected payments to Reece. The system can enable her to withdraw money from this account at any time through the mechanisms discussed above.

Assessing a Charge to the Receiver

The system can also assess a charge to Reece for making an actual payment to her. This charge can be taken out of the amount paid to her.

C. Transferring the Payoff Risk to the System Paul may not want to be liable for payoff amount if he loses an EVP bet. Thus, the system can enable him to insure the risk so that if he loses an EVP bet the system pays for him. In this scheme, when Paul makes a payment, the system credits the payment amount to a system bank account and then executes the bet in which the system takes the side opposite Reece. If the system loses the bet, it pays Reece the payoff and debits the payoff from the system bank account.

The system may include steps for charging Paul for this insurance.

If the system takes one side of the bet then Reece may suspect cheating. Various anti-cheating methods can be employed. For example, an RN can be taken from an independent source, such as a state lottery, at some pre-determined time after the EVP bet has been entered into the system. Thus, the system cannot affect which RN is supplied for the bet.

D. Anti-Fraud Procedures

The system can incorporate a variety of anti-fraud procedures. We discuss the following kinds of procedures in turn:

1. Procedures for preventing "bounced payments".

2. Procedures for authenticating payers.

3. Procedures for authenticating receivers.

4. Procedures for delaying and confirming payments.

5. Procedures for limiting payments.

1. Procedures for Preventing "Bounced Payments".

One cheat a payer can attempt is to promise to pay more than he has deposited into his bank account. Thus, a simple but obviously important check for the system to perform is whether the payer has enough in his account to cover a payoff. If his payoff risk is insured, the system still has to check whether he has enough in his account to make the expected payment. If not, the system rejects the transaction.

These "funds available" checks are important to Reece because she wants to be assured that a payment that Paul makes to her will not wind up failing due to insufficient funds. Of course, the system can also include well known means for enabling Paul to establish a credit account. In this case, the credit issuer — the system — is taking the payment risk. But, if the system stands behind the payment, then the receiver is still assured that payment will be made.

2. Procedures for Authenticating Payers

Another kind of fraud is to impersonate a payer. Thus, the system can include authentication procedures, such as a password procedure. Another authentication technique is to send an e-mail notification to the payer after an EVP form has been submitted requesting confirmation from him that he has actually submitted the form (see below). All manner of more sophisticated techniques, such as smartcards and biometric techniques can be employed, of course, but are not easily implemented given the current (11/17/98) state of the market.

3. Procedures for Authenticating Receivers

Another kind of fraud is to impersonate a receiver. Thus, the system can include procedures for authenticating Reece.

The simplest method is to have Paul enter Reece's legal name into the EVP form. That way the system can issue a check, or send an EFT only to that name. Reece's bank will have its own ID checking measures that protect against fraud. For extra security Paul can, if he is given the information, include Reece's bank routing information.

Another method is for the system to enable Reece to pre-establish a user account. This method is appropriate if Reece receives multiple expected payments. Then, is she wins an EVP bet, she can enter her password in order to collect her payoff (after entering her password, she can instruct the system where to send a check).

Another method is to enable Paul to enter a one-time password into the EVP form that Reece must use to collect her payoff. Thus, if Reece wins the EVP bet, the system will require her to enter this password. (We presume Paul can send Reece this password by a secure channel.) Another way to authenticate Reece is for Paul to enter Reece's e-mail address into the EVP form. Then if Reece wins the EVP bet, the system can send her an e-mail along with a redemption code. In order to collect the payment the system can require that she enter the code.

4. Procedures for Delaying and Confirming Payments

Anther procedure for preventing fraud is to have the system can confirm with Paul that he entered data into the EVP form. Thus, when payment data has been entered by a user purporting to be Paul, the system can send a confirmation notice to Paul's e-mail address (we assume that the system has captured his address when he established a user account) and enable Paul to object to the payment. If Paul does not respond to the notice after a period of time, the system can execute the EVP bet. The system can enable Paul to set the period of time within which he must object to the payment.

Another, measure to prevent fraud is for the system to have a pre-set "clearing period" for any actual payoff payments to be made.

5. Procedures for Limiting Payments

Another procedure the system can include for preventing fraud is to enable Paul to set a maximum payment amount per EVP bet and a maximum total amount of payments per day.

If a user tries to make a payment over either threshold, the system can send Paul an e-mail alert, and can reject the payment.

E. An Illustration of an International, Expected Payment

Here we give an illustration of Paul, in the United States, paying Reece $100 in Japan. Currently, the transaction costs of such a payment are approximately $35-$40.

Using the system, the transaction costs can be cut to around 7%, if we assume that the payoff is $1000, an amount he and Reece have pre-agreed upon. We assume a wire transfer charge of $35.00 and credit card service charges of $3.50. In the illustration below, we further assume that the system automatically insures the payoff risk, so that Paul is liable only for the expected amount he is paying plus a service charge.

Paul goes to system webpage that enables him to fill in an EVP form.

1. He enters: a. his name, b. his e-mail address, c. Reece's legal name, d. the payment amount, $100 e. the payoff, $1000.

2. He enters Reece's e-mail address (if she has one) and (possibly) a password she can use to verify her identity.

4. He enters his credit card number.

5. He presses a calculate button and the system shows him the total charge, which is the $100 expected payment plus a $3.50 service charge.

6. He presses the Execute button and the system checks if he has adequate funds in his credit card account to cover the charges ($103.50) and, if no, rejects transaction, outputs a rejection and stops, if yes, a. runs the credit card payment for $103.50 and credits the funds to a system bank account, b. records the expected payment and the service charge, c. timestamps the transaction and creates a transaction ID, d. generates a random integer from 1-10, if the integer is 1-9 then declare Reece's the loser, if the integer is 10 then declares Reece the winner, e. stores the transaction record, f. outputs the result to Paul in a webpage and sends the result to his e-mail address, and sends the result to Reece's e-mail address.

7. If Reece has won the EVP bet, the system: a. debits the payoff ($1000) from the system bank account, b. credits the payoff to a temporary account identified by Reece's name and the Paul's name and (possibly) by the password Paul has entered for the transaction.

8. Receives a redemption request from Reece through a redemption webpage, a. authenticates Reece (she can be authenticated simply because she has entered a redemption code). b. sends payment data to a paper check creation agent directing the payment agent to make a paper check payable to Reece (suing her legal name) in the payoff amount.

Part 2 Processes with Bet Result Revealed by the Recipient

Section 3: The Core Payment Process Revisited

The second form of core process executes a bet and enables the recipient to decide when and if the result is revealed. The terms of the bet are shown but the result of the bet is not revealed to the Reece until she enters a command. In other words, the system includes an Execute Bet or Reveal the Result command that the Reece enters to reveal the result.

As mentioned, having Reece reveal the result enables her to signify agreement to the bet terms. Moreover, it enables her to leave the result unrevealed and to transfer the expected payment to another person.

In this Part of the description, when we refer to the core process we will have in mind the core process in which the system reveals the bet result contingent upon getting a command from Reece. Process in which the Recipient Enters the Command to Execute the Bet

The core process can be configured so that Paul or Reece enters the command to execute the EVP bet.

If Paul enters the command then the system can inform him of the result while not revealing it to Reece. If so, the system will have "Reveal the Result" command that Reece can enter. This variation may suit certain applications, as for example if Paul is a company that wants to know the results of the EVP bets it has made.

Another variation — the one we will be describing in this Part — has Reece enter the Execute command, after which the system can inform both Paul and Reece of the result. We choose to elaborate on this variation because it allows more features to be added to the system than does the variation where Paul enters the Execute command. Moreover, in what will likely be the most popular implementation, Paul will insure his payoff risk so that it does not matter to him what the result of the EVP bet is.

Otherwise, the variations are directly analogous so that features described in the discussion below can apply to both, as the reader's common sense will make apparent.

Having a Distinct Agreement/Rejection Commands

If Reece reveals the result then she signifies her agreement to the bet terms. In other words, when she enters the Execute Bet command she is implicitly agreeing to the terms of the EVP bet. Yet the system can also include distinct "I Agree" and "I Reject" commands for signifying her agreement to or rejection of the EVP bet terms, but not for directing the system to execute the bet and reveal the result.

Having a distinct "I Agree" command can be useful for certain applications where Paul and Reece want a way to record that an expected payment has been agreed upon without requiring the EVP bet to be executed. That way Reece and has the option to transfer the expected payment.

Note: if Paul has insured the bet then his obligation is satisfied; it is the system that is betting with Reece. If he has not insured the bet, then he still needs to find out the result of the bet — he still needs to have the bet executed — in order to find out his definite payment obligation. The Payer or the Recipient Can Fill in the EVP Form

If the recipient is involved in the EVP bet process, she can fill in the EVP form. For example, a merchant (the recipient) might fill in data from a payer (a customer). The merchant can then send the EVP form data to the system to execute an EVP bet between the merchant and the customer.

Assumptions for this Discussion

To simplify the discussion of how the system can be built up around the core process, we make the assumptions below. (With these assumptions we do not mean to limit the invention, as those skilled in the art will see equivalent or highly similar configurations.)

We assume that the system includes payment transfer functionality. (If the system can transfer payments, it can have many more features than if it just records and executes EVP bets.)

For simplicity, we assume that the payer fills in the EVP form and that the data entered by the payer is shown to the recipient. The recipient can then choose to execute the bet or not.

We assume that processes discussed in Part 1 , such as authentication methods and payoff methods, are applied where appropriate. We try to not repeat the description of Part 1, except where useful for clarity's sake.

We take as our illustrative embodiment a website — including webpage interface and computer database means — that Paul and Reece access to enter and view EVP bet data. We do not repeat the explanation, given in Part 1, of how the system enables Paul to enter EVP form data. (As noted in Part 1, IVR interface may also be desirable. We do not delve into that kind of interface in Part 2. Those skilled in the art will see how to apply such an interface to the system described here.)

Organization of this Discussion

This discussion will describe a variety of features and processes that can be added to the core process. These features and processes will be explained by referring to a recipient form that Reece interacts with. We will also call this form an EVP certificate. This form offers a convenient way to show the kinds of functionality that the system can include. We note that the description will also explain features and processes that are not shown in the form.

For illustrative purposes the form has more features than are necessary for the system to operate. Those who implement the invention will choose the optimal mix of features for their application.

We divide the form and the functions behind it into three "areas":

(1) a bet terms and status area

(2) a payment options area

(3) a security area.

In Section 4 we describe all three areas in turn. In Section 5 we delve into additional features and functions that the system can include for enabling convenient and secure transfers of expected payments. And in Section 6 we give some additional "bank" features.

Section 4: The Recipient Form

In this section we explain each feature of the recipient form (also called the EVP certificate) and the corresponding operations that Reece and the system perform regarding those features. We use the term "EVP certificate" because the value of the EVP bet is being represented by the recipient form. It is a kind of electronic certificate.

The Bet Terms and Status Area

The form will display some or all of the "bet terms and status" data listed below. We assume that the payer or the system has supplied the data, as dictated by the given field. (We have discussed most of these fields in Part 1. We add a little to that description.)

The Payer

This field shows the payer's name.

The Recipient

This field shows the recipient's name. The Expected Value

This field shows the expected value of the EVP bet. We also call it the expected payment and the payment amount.

The Payoff

This field shows the payoff amount.

The Odds of Winning

This field shows the odds of the recipient winning.

The Actual Value (The Status of the EVP bet)

This field shows the actual value of the EVP bet. If the result has been revealed, then the actual value will be known — it will be zero or the payoff. Thus, this field is equivalent to a "Status of the Bet" field showing whether or not the bet result has been revealed or not.

The Memo

This field shows a description of the expected payment. The information here can be entered by the payer.

Timestamp

This field shows a timestamp that indicates when the EVP bet was committed to by the payer — when he submitted the EVP bet data.

EVP Bet Identifier

This field shows a payment identifier that is generated by the system.

The Payment Options Area

The form will also have a button or buttons that Reece can click on to transact the EVP bet — the payment to her — in some way. The form can enable her to at minimum press a button for executing the bet. It can also give her other options, as described below.

Execute the Bet

This command causes the system to execute the bet. Reject Payment

This command causes the system to register that Reece has rejected the payment. Reece's rejection is sent to Paul by e-mail (we assume that the system has stored an e-mail address for Paul).

Deposit the Payment

This command causes the system to deposit the expected payment (the expected value) in Reece's bank account (we assume that the system has created a bank account for Reece).

Transfer the Payment to Another Party

This command causes the system to present Reece with additional options (see Section 5) for transferring the expected payment to another party.

The Security Area of the Recipient Form

The system can give users two kinds of access to the EVP certificate. One is access to view the bet terms and status fields. Another is access to operate the payment option command. There are various ways that Reece can be authenticated so that she can operate these commands. For simplicity, we will assume that anyone can view the EVP certificate if that person enters the matching search criteria into the system. But we assume that the system requires that Reece enter a password in order to transact payment — i.e., use the payment options.

The EVP certificate has an expected value to its owner, the recipient. Thus, the certificate needs to be protected by some kind of security measures. In part 1 we discussed various ways that Reece could be authenticated so that she could collect a payoff that was due her. If Reece is given control of the expected payment so that she can decide whether to reveal the EVP bet result, and so that she can transfer the expected payment, then she needs to be authenticated when she operates the recipient form (the certificate).

Security Status (Locked/Unlocked)

The form will have a security status field that shows whether the form is locked or not. If locked, the only way to operate the form is to enter the correct password. Thus we assume that the system has well known means for granting operational access to the form based upon a password or other equivalent authenticating data. If the form is unlocked, the system enables a user to operate any of the options on the form. Enter Password

The certificate will have a field for enabling a user to enter a password. The password may be set by Paul or by the system. If Paul sets the password, the system will include a field in the EVP form that Paul fills in (see Part 1). Paul may then be responsible for sending the password to Reece or Paul can direct the system to send the password to Reece's e-mail address. If the system sets the password then the system will send Reece the password via e-mail. When a password is submitted in the EVP certificate, the system will check it against the password stored for that certificate and authorize the user, if the password is correct.

Lock Certificate

This command enables Reece to lock the certificate so that only a person with the proper password can unlock it.

Unlock Certificate

This command enables Reece to unlock the certificate. But, this command will only work if she also enters the proper password.

Change Password

This command enables Reece to change the password.

Get Password

This command enables Reece to get a certificate password if she has forgotten it. For example, the system can send a password to Reece's e-mail address.

Section 5: Transferring Expected Payments

As stated in Section 4, the EVP certificate can include an option that enables Reece to transfer her expected payment — to transfer ownership of the EVP certificate itself — to another party. This functionality turns an EVP certificate into a negotiable (transferable) payment instrument.

Let us give an example application. Assume that Paul is in the United States and he wants to make a payment of $100 to a relative, Reece, in Mexico. He decides to use the system because sending a wire transfer in that amount involves over $20 in transaction costs. The problem is that Reece does not want an expected (uncertain) payment, she needs a definite payment. The solution is to enable Reece to sell the EVP certificate for cash to a local party, say Juan the pawnbroker or banker, in Mexico. (She may incur a transaction cost because Juan may charge her a premium, but we assume that it is smaller than $20.)

What is needed, then, is for the system to include a process (or processes) for enabling the secure transfer of an EVP certificate. We give a process below and then elaborate upon it.

Procedure for Transferring an Expected Payment

We will assume that anyone who has the password to the certificate can unlock the certificate (see Section 4) and change the recipient. Thus, to transfer payment, Reece only has to give Juan the search criteria for finding the certificate and the password for unlocking the certificate.

Assuming that Juan has entered to proper criteria for finding the certificate, such as the certificate ID number, and presuming Juan has entered the proper password for unlocking the certificate, then Juan can press the "transfer payment" option button on the EVP certificate.

The system will then enable Juan to enter his name into a field for designating the new recipient to whom ownership of the EVP certificate is being transferred. After Juan submits his name through this field, the system stores his name as the current recipient. To protect against unauthorized, additional transfers of the certificate, Juan could change the password (as explained in Section 4, a user who can unlock the certificate can change the password).

Further, the system maintains a record of Reece's previous ownership and timestamps the transfer. Thus, the system maintains a history file that records all changes to the certificate from the time it is created to the time it is redeemed. The system will also have a history button on the certificate to enable a user to call up the ownership records of the certificate.

Making the Transfer Irrevocable

One reason the transfer process above may be inconvenient is that it forces Juan to change the password in order to insure his security. But he may not want to enter a new password each time he receives an EVP certificate. So, the system can include a command for designating that the transfer is irrevocable, meaning that the EVP certificate cannot be transferred to another party. That way, Juan and only Juan can take ownership of the certificate, as far as the system records are concerned. Once this command has been entered, the system stores the entry and blocks any further attempts to change the recipient.

Making the Payment Transfer Procedure More Convenient

In order to transfer ownership, the recipient name does not have to be changed. Reece can simply give Juan the password and then Juan can change the password. That way he has control of the EVP certificate.

Extending this principle, the EVP certificate does not even have to be made out to a recipient, it can be a "bearer bond" in the sense that any user who knows the password can dictate who the certificate is transferred to or dictate who is to collect the payoff, if there is any.

In other words, the recipient field of the EVP certificate does not have to be made out to any recipient, unless the EVP bet result is revealed and the certificate is a winner. In other words, the user who has unlocked the certificate can enter the Execute bet command, and if the certificate is a winner, the system can output a form for entering the recipient's legal name for the purpose of collecting the payoff.

The system can even enable people to use passwords as search criteria for accessing an EVP certificate. In this way the system can enable people to transact payment by simply using words and phrases. For example, the phrase, "Call me Ishmael" might be used to find an EVP certificate and to unlock it as well. Being able to pay using words and phrases may be of great convenience, especially when people feel insecure about carrying cash or feel insecure about the currency of their country. They can use the system to transact payment in a stable currency, such as the dollar.

Making the Payment Transfer Process More Secure

The processes above may be insecure in certain situations where Reece does not trust Juan. Juan may take the password and never give Reece any money. If Reece has no proof then Juan can commit a fraud. One way to protect Reece is for the system to incorporate a "double password" process in which one password enables Reece to endorse the EVP certificate to Juan while the second password is required for Juan to take ownership. Until this second password is entered, no party may transact the certificate; it is frozen so to speak.

Thus, the system can include a process for locking the certificate with one password and enabling the certificate to be endorsed in its unlocked state. Once the endorsee, the new recipient name, has been submitted, the system requires that a second password be entered to enable any future transactions to take place with the certificate.

Section 6: Bank Features

The system is an online database system for enabling EVP bets. If it includes payment transfer functionality, it can be thought of as a kind of bank. While the term "bank" is imprecise, we will describe some additional features that the system can incorporate that might be associated with a bank. Thus we call them bank features.

Payment Account Features Revisited

Let us first review the payment account features that the system can include because these are necessary if the system is to be a "bank".

As noted, the system can include means for creating payer accounts where Paul can deposit and accumulate money that can be applied to multiple EVP bets (multiple expected payments, that is). For example, a government agency might have an account with $1,000,000 in it for making thousands of expected payments.

Likewise, as noted, the system can include means for creating recipient accounts where Reece can accumulate expected payments. For example, a government agency might have an account where thousands of expected payments can be accumulated.

The system can, of course, enable a user to have an account through which he can make payments and receive payments. A user's account will have a balance and the user will have the following options in handling his balance. He can deposit a definite payment into the account, can make an expected payment, he can deposit an expected payment into the account, he can pay the balance to himself through an EVP bet to himself.

(The system can also enable the user make definite payments out of the account but the system would normally assess a higher service charge for a definite payment than for an expected one.)

The system could also enable a user to set account preferences. The most important preference is the default payoff for EVP bets that the user was engaging in. He can set a different payoff for making and receiving expected payments.

The system can also enable a user to accumulate interest on the balance in his account.

Foreign Exchange Functions

The system could also incorporate various exchange rate functions so that the user could make a payment from one currency to another.

The system could include well known functionality for displaying the service charges and exchange rate costs associated with such a payment.

The system can also include functions for displaying the costs and savings of a definite foreign exchange payment compared to an expected one.

Proposal for the Formation of the Bank of Occam

"Entities are not to be multiplied beyond necessity" is what William of Occam is famous for saying. In the spirit of that epigram, we propose a new kind of bank called the Bank of Occam.

This bank only takes in definite deposits denominated in $1000 units and sends out definite payments in $1000 units. Any expected payment amount is allowed but the penny, nickel, dime, quarter, dollar, ten dollar, and hundred dollar units are banished from definite payment. Every payment is "rounded" to the thousand dollar using an EVP bet. But, this kind of bank is not practical at this time.

What is practical is a modified Bank of Occam where deposits are taken into the bank in any amount, but payments going out of the bank are all denominated in $1000 units. Such a bank has advantages over banks that do not use the expected value payment method. We discuss three such advantages below. For the sake of concreteness, we will assume that payoffs can be made only in $1000 units. Thus, any expected payment under $1000 will have a payoff of $1000.

A. Expected Interest Can Be Paid Based on the Payoff Amount

Interest in a user's account can be paid based not upon the balance but upon the default payoff amount (or an even lager amount). There are various ways to calculate expected interest. We will give just one.

Balances under $ 1000 can be agglomerated into $ 1000 units daily just for the purpose of paying daily interest.

Each user with a balance under $ 1000 is allotted a set of numbers equal to the balance's share of $1000, e.g., a $50.13 balance gets 5013 winning numbers out of 100,000 numbers (the number of pennies in $1000).

Then an RN is supplied from 1-100,000. The user who has the winning number wins the interest on the $1000. This interest is added to the user's balance.

In that way, expected interest can be paid based upon $1000 rather than the balance. Other similar or equivalent methods can be implemented.

B. Charges and Savings Can Be Given to Payers

As noted, there can be various transactional savings associated with expected payments as compared to definite payments. Thus, the Bank of Occam can be more efficient compared to a conventional bank. The savings can be passed along to payers. Moreover, because of the nature of expected payments, where a recipient gets nothing or a large payoff, a recipient can be charged for receiving a payoff. The service charge associated with this definite payment could be split between the bank and the payer. For example, if Paul paid Reece through the bank and Reece won the EVP bet, and the bank paid her $1000, it could charge her, say, $30, of which, say, $15 could go to Paul.

By giving Paul a share of the charge assessed to Reece, the Bank can encourage depositors in a way that conventional banks cannot. Other similar scheme are possible, but the point is that the Bank of Occam could enjoy a substantial advantage in attracting deposits. Thus, the system can include functions for assessing charges to a recipient of a payoff and crediting a part of those charges to the payer.

C. Paper (and Electronic) Check Transaction Costs Can Be Cut

The Bank could save steps in the chain of processing of paper checks. For these savings to be realized, the banks and merchants that re part of the chain must cooperate. A paper check payment process could go as follows.

1. Customer gives check to Merchant.

2. Merchant gives check to Routing Entity.

3. Routing Entity gives check to Customer Bank (Bank of Occam).

4. Bank of Occam debits customer account for the amount of the check.

5. Bank of Occam executes and EVP bet with the merchant where the EV is the amount of the check payment.

6. If Bank of Occam loses, pays merchant bank the amount of the payoff, and the merchant bank credits the merchant account by the payoff.

Steps are saved compared to normal check processing because the merchant does not deposit his checks into his bank but instead sends them to a routing entity (such as the Federal Reserve) which sends them to the customer's bank. The merchant's bank only deals with a check if the customer's bank loses an EVP bet on the check. (The same principles apply in credit card and debit card processing. These points have also been made in US Patent 5,269,521.)

Claims

ClaimsI claim:

1. an online database system that performs the following steps:

—Input payer's (a)name, (b) e-mail address, (c) recipient's legal name, (d) the payment amount, $100 and (e) the payoff then

—input recipient's e-mail address and a password user can use to verify her identity, then

—input payer's credit card number, then

—register command to calculate and then show the payer the total charge, which is the payoff amount plus a service charge, then

—register a commaned to execute and then check if the payer has adequate funds in his credit card account to cover the total charge and, if no, rejects transaction, outputs a rejection and stops if yes,

(a) runs the credit card for the total charge and credit the funds to a system account,

(b) records the expected payment and the service charge,

(c) timestamp the transaction and creates a transaction ID,

(d) executes an expected value payment (EVP) bet,

(e) stores the transaction record,

(f) outputs the result to the payer in a webpage and send the result to the payer's e-mail address, and sends the result to recipient's e-mail address, then

—If the recipient has won the EVP bet, the system: a. debits the payoff amount from the system bank account, b. credits the payoff to a temporary account identified by the recipients name and the payer's name and by the password the payer has entered for the transaction, then

—Receives a redemption request from the recipient through a redemption webpage, a. authenticates the recipient, b. sends payment data to a paper check creation agent directing the payment agent to make a paper check payable to recipient in the payoff amount.