Systems and Processes for Affixing and Redeeming E-stamps Background-Field of the Invention This invention relates to systems and processes for affixing and redeeming e-stamps.

Background-The Prior Art This patent application describes how the expected value payment method (of US Patent 5,269,521) can be used to enable e-stamps. In other words, it describes systems for affixing lottery tickets e-mail and for redeeming those tickets. Rivest in Electronic Lottery Tickets as Micropayments (currently available at rivest@theory. lcs. mit. edu) has pointed out the efficiency of lottery tickets as payment vehicles. The purpose of affixing these lottery tickets is to enable "sender-pays"e-mail. There have been numerous advocates of sender-pays e-mail but no one, to the inventor's knowledge, has disclosed the methods and systems taught here.

Summary of the Invention Multiple, highly related inventions that employ the expected value payment. First, a system for affixing e-stamps to e-mail. This invention can include means for enabling receivers to redeem these e-stamps. Second, a system only for redeeming e-stamps on e-mail. And third, a system for enabling the transaction of micropayments for information provided by servers. Variations on these three systems are also disclosed.

DESCRIPTION OF THE INVENTION Introduction E-mail lends itself to abuse because, through automation, the cost of sending messages to millions of addresses is negligible. Therefore, mass e-mail (spam) can lead to a deluge of junk mail for receivers. However, if e-mail includes micropayments to receivers then e-mail is not free and many problems associated with spam disappear.

An expected micropayment can be affixed to an e-mail message. It is"affixed"in the sense that it is a message-more specifically, a contract-that is added to the main message of the e-mail.

Expected micropayments affixed to e-mail will be called l-stamps. The"I"stands for"lottery" because l-stamps are equivalent to lottery tickets with a specified expected value. (The use of 1- stamps is an application of the expected value payment method of US patent #5,269,521.) L- stamps are far more efficient than conventional payment vehicles. This specification describes multiple systems for enabling users to affix l-stamps to e-mails.

Modular Approach This specification takes a modular approach in that it describes modules that can be put together.

There are a three reasons for this approach. First, each module is designed to achieve a certain objective. In most cases, multiple ways exist to achieve the objective. For example, there are many ways to create and affix an L-stamp, just as there are many ways for produce conventional lottery tickets. Using distinct modules (procedures) we cover several basic ways without committing to a single method. Second, while the modules can be combined to form larger systems, there is no best combination of modules. Further, the modules do not have to be combined into a single system. Most of the modules can be considered independent inventions. For example, a system for affixing L-stamps does not have to be combined with a system for redeeming L-stamps; the two can be considered separate inventions. So, we describe a variety of stand-alone modules and then explain how they can be combined. Third, the ability to create e-stamps, leads to a variety of useful, dinstinct features that can be added to e-mail sending and reciving systems. These featues are usually best explained individually, as modules.

Systems for Affixing and Redeeming L-stamps Chapter 1 Definitions In this chapter we give some definitions that will be used throughout this specification. Some of these will be elaborated on as the discussion progresses. New definitions will be added as needed.

E-mail. Also called an e-mail message. For our purposes, an e-mail message will mean information that is sent from one computer to another and that is seen by senders and receivers and that"arrives"in an e-mail box. Thus, for our purposes, this information includes what is known as the headers and the body and includes attached files.

Headers. The part of an e-mail that is seen initially when an e-mail arrives in a receiver's e-mail box. The headers may be made up of several fields, including but not restricted to: sender, receiver and subject fields. We sometimes refer to the headers-multiple header fields-as the header.

Body. The content of an e-mail that must be"opened"by a receiver. In other words, the content that is not seen initially when an e-mail arrives in the receiver's e-mail box. Files attached to an e- mail, including audio and graphics files, will be considered part of the body.

L-stamp. A lottery ticket, with a specified expected payment value, affixed to an e-mail. Also referred to as a stamp.

EV. The expected payment value of an L-stamp.

Payoff. The amount of money that can be won in an L-stamp bet.

RN. A random number that is used to decide an L-stamp bet.

RNS. An RN supplier. Also called an RNG (RN Generator).

L-mail. E-mail that has an L-stamp affixed to it. By"affix"we mean that L-stamp information is added to an e-mail message. With physical mail the common term for adding a stamp is to say that a stamp is"affixed". We adopt that usage but also use add as a synonym for affix.

Server. A computer-processor, memory, input/output means, and programming means- connected to a network.

L-stamp server (LS). A server with programming means for sending e-mails and affixing L- stamps to those e-mails. Also called an L-mail server.

Redemption server (RS). A server with programming means for redeeming L-stamps.

Full L-stamp system (FLS). A system that combines the functions of an LS and an RS. In other words, a computer that both sends out e-mails with L-stamps and that enables people to get paid for winning stamps.

Sender. The party responsible for sending an L-mail. Also called Seneca.

Payer. The party responsible for paying off a winning L-stamp. (Usually, we will assume that the sender is also the payer, although the payer can be the agent of the sender.) Receiver. The party that receives an L-mail. Also called the recipient. Also called Reece. Note: An L-stamp will usually be made out to an addressee rather than to a person's real name. Although not always valid, the assumption is that the person who accesses an e-mail box is the person who has the rights to any L-stamp sent to that box.

Sender and Receiver Names. A sender's or receiver's name will usually mean his or her return address, his or her"cyber-name", that is. As necessary, we distinguish between actual names and e-mail addresses.

E-mail Receiving Program: The program or set of programs that make up a receiver's mail client and/the mailserver (mail transfer agent). In other words, the program or programs, on a host machine and/or a mailserver, that process a receiver's incoming and outgoing e-mail. Also called the receiver's e-mail program.

Procedure. A series of steps executed by a computer to do a defined task.

What Is an L-stamp ? An L-stamp is a lottery ticket. But what is a lottery ticket? A lottery ticket is a kind of payment contract. So, an L-stamp is a message, added to an e-mail, that describes a commitment by the sender to pay an amount of money to the receiver, under specified conditions.

Therefore, an L-stamp is not one single thing. L-stamps vary according to the payment terms they contain.

An L-stamp is also a payment vehicle, like a check, that denotes an amount of money and contains various pieces of identifying information to make payment possible. This kind of information can vary depending on the terms of payment.

The greatest area of differences in L-stamps is in their conditions of redemption-the actions a recipient must take in order to get paid for a winning stamp. The potential variety of L-stamps can be seen in their analogs, conventional lottery tickets, which incorporate all manner of matching number games and take a variety of forms including straight lotto tickets, scratcher tickets, progressive pot tickets, pari-mutuel tickets, send-in tickets and instant-win tickets. Like conventional lottery tickets, L-stamps take different forms and include different information depending on their rules for paying off recipients.

Minimum Information to Be Affixed At minimum an L-stamp will state its EV, the recipient and the payer. The payer and recipient may or may not be implied. For example, a set of symbols, such as"L$. 10", in the subject header of an e-mail may mean that the EV of the stamp is $. 10 for the addressee of the e-mail and that the sender (or some designated third party) will pay off the stamp.

At minimum an L-stamp will also contain an identifier that we will call an L-stamp ID.

At minimum an L-stamp will also contain instructions for redemption. These would be included in the body of the e-mail or signified by a credential in the header.

An L-stamp can include its payoff and its odds of paying off. For simplicity in this specification, we usually omit this information because it is not essential (the payoff can be standardized).

However, in practice, an L-stamp will often state its payoff and/or its odds of paying off.

An L-stamp normally would include an expiration date or period. For simplicity, we omit this information. The stamp may state the expiration date or the expiration period may be implied by the stamp credential.

An L-stamp may or may not include its result (winner/loser). Whether it states its result depends on the type of L-stamp that it is.

What Is an L-stamp Server? An LS is a computer that includes programming means for adding to an e-mail a set of information defining an L-stamp. The information affixed depends on the kind of L-stamp that is involved. Thus, an LS is not one machine but a type of machine. Particular LS's will differ depending on the kind of L-stamps they affix. Again, physical lottery tickets provide a direct analogy. The machines that produce these tickets vary depending on the kind of tickets involved.

Likewise, the machines that affix L-stamps will vary depending on the kind of L-stamps involved.

(The term LS can refer to a computer that is on a network but does not serve the network in the typical sense of a"server". An LS can refer to anything from a PC to a mainframe. It is the functional ability to add an L-stamp to an e-mail that defines an LS.) What Is a Redemption Server? Like an LS, an RS is not one machine but a type of machine. RS's will vary depending on the kind of L-stamps they redeem. It is the functional ability to redeem an L-stamp that defines an RS.

Ambiguity in the Term E-mail In this specification we describe how an LS adds L-stamp information to an e-mail. As discussed, we will think of an e-mail message as the header and the body content that receivers see. When we add the L-stamp information to either, we will sometimes refer to the header or body as the modified header or modified body.

At what point does the e-mail become an L-mail? There is no clear dividing line. Even when all the L-stamp information is added to an e-mail, thereby making it an L-mail, we can still call it an e- mail that has been stamped with certain payment information. Because more than one piece of information defines an L-stamp, it is sometimes easier to visualize an e-mail with pieces L-stamp information added to it rather than think of an L-mail. So we often refer to an e-mail that has L- stamp information affixed to it. Note, then, that there is sometimes ambiguity when the term e- mail is used. It is left the reader to interpret the meaning from the context.

The Reason for Defining and Naming Files In this specification we define and name several kinds of files. In giving these definitions and names, we are not trying to say exactly how L-stamp systems would store information. Our goal is just to explain the kinds of information that L-stamp systems would store. Those skilled in the art will easily see alternative ways of referring to this information.

Chapter 2 Preface How the L-Stamp Systems and Processes Are Presented L-stamps are payment vehicles that are created and redeemed in a multi-stage process. These stages can take place on one server or on different servers. As an analogy we can think of systems for dispensing and redeeming shopping coupons. At one extreme are in-store coupons. These are created and redeemed by the store's central computer (which uses registers as input/output means).

At the other extreme are manufacturer coupons. These are initiated by a manufacturer who contracts to have them printed. The coupons are then redeemed by consumers at stores. The coupons are then redeemed again by the stores who send them to a redemption center that tallies the coupons and redeems them once again, this time by sending the tally to the manufacturer.

As with shopping coupons, the stages involved in creating and redeeming L-stamps can be performed on a single system controlled by one party or on different systems controlled by different parties. These stages correspond to the functions of the LS, RNS and RS, which means that the functions of the LS, RNS and RS can be performed by separate machines.

In this Part, for simplicity, we usually assume that an LS and RS are combined in the same machine. And, with the important exceptions of Chapters 6 and 7, we incorporate the RNS into the LS.

In Chapter 9 we sometimes split the LS, RNS and RS. In any case, the LS affixes the L-stamp information to a piece of e-mail. The RS works off information supplied by the LS. And the RNS selects winners according to the instructions of the LS.

In this Part, for simplicity, we only discuss two parties, the sender and the receiver. Things get more complicated in Chapter 9 when we describe anti-cheating measures because then it becomes important who controls the RNS, LS and RS. Neutral third parties are introduced. In this Part we do not delve into who controls the RNS or LS or RS. Our goal is just to describe basic computer implemented procedures for affixing and redeeming L-stamps. When we introduce new parties in Chapter 9, these procedures may be modified in the sense that the functions described may be performed on separate machines controlled by different parties.

As discussed, L-stamp systems can take a variety of forms. In this Part we will describe several different forms. All these forms share certain procedures. So, to avoid repetition each time we describe a different form, we describe those common procedures in the next two chapters then we refer to those procedures as needed.

Coding Efficiency Not the Goal of This Specification We are not concerned with describing efficient coding methods. We are concerned with what kind of information comprises an L-stamp, how that information is affixed to an e-mail, where that information is affixed on an e-mail, and how that information is stored for keeping records. We give illustrative procedures but by no means claim that they are best. Those skilled in the art will see better ways.

Procedures Given for Mass L-mailing and Individual L-mailing L-stamps can be applied to mass e-mail and to personal, individual e-mail. Procedures for affixing L-stamps to mass e-mail will differ from those for affixing L-stamps to personal e-mail, yet the core information that is affixed remains the same.

Most of the procedures described in this Part are tailored to mass e-mailing. However, with minor modifications, they can be incorporated into personal e-mail programs, such as the Eudora e-mail client, to affix L-stamps to individual e-mails. Though we focus on mass L-mailing, we also explain, especially in Chapter 6, how the procedures discussed can be applied to personal L- mailing.

Chapter 3 Core Procedures for Affixing L-stamps What Information Is Added The basic procedure for affixing an L-stamp to an e-mail involves adding certain separate pieces of information to the e-mail. This basic procedure can be split into sub-procedures corresponding to each kind of information that needs to be added. We will describe these sub-procedures in this chapter. There is no best sequence of steps for sub-procedures. The ones we set forth can be done in different ways and by separate servers. What we are trying to explain are the functions that an LS must perform.

As discussed, an LS adds the following information to an e-mail (recall that the payer and receiver are taken to be understood): the EV, the L-stamp ID, the terms of redemption, and the result (possibly).

The information in an L-stamp gives the probability that the stamp will win or lose. But deciding the L-stamp bet and showing the result can be part of affixing or redeeming that stamp. In this chapter, we will usually assume that adding the result is part of affixing an L-stamp (in Chapters 6 and 7 we describe an LS that does not add the result. In these cases, the result is revealed by the RS).

Types of L-stamps L-stamps are distinguished by where and how the information above is specifically placed in e- mails-and thus, how the results of the L-stamps are revealed, and how the L-stamps are redeemed. In this chapter we do not delve into the specifics of where and how the information is placed, we give sequences of steps for adding the pieces of information that constitute any L- stamp. In later chapters we describe different types of L-stamps by explaining different ways of placing this information in e-mails.

E-Mail Templates and Template ID's As noted, we will be describing systems for sending mass e-mails where an identical e-mail message is sent to a list of addresses. We call this identical message the e-mail template or template and call it's parts the header template (or subject template) and the body template.

(A template is not useful in personal e-mail systems where the e-mail message is not meant to be re-used.) Sometimes, rather than use the term template, we will simply say that the LS adds information to an e-mail, or to the header, or to the subject header, or to the body. We let the context dictate the meaning. We use the term template because in the procedures below we say that an e-mail message has information added to it. We want to get across the idea of an original message that is re-used for each address in a list.

Sometimes we use the terms modified header and modified body to refer to header and body templates that have had information added to them.

Each template will have an identifier called the template ID.

The Boilerplate The boilerplate is contract information that states the terms of payment for an L-stamp, the redemption instructions that is. If the payoff amount is standard then the boilerplate will include that figure as well. We will assume that the boilerplate is added to the body of an L-mail.

However, it is also possible to signify the boilerplate with a symbol in the header-e. g.,"L$"in the header might denote a set of payment terms.

(In practice, some kind of credential symbol will probably be affixed along with the EV to aid in the screening of L-mail. The EV will tell the expected value of the L-stamp while the credential will signify who will make the payment and how. We mostly omit discussion of such a credential because it is not mandatory.) Different boilerplates will be needed for different types of L-stamps, and so, the LS can include means for entering multiple boilerplates and for letting the LS operator select the boilerplate to add to an L-mail.

L-stamps As ID#'s It is possible for L-stamps to be simply ID#'s that are not associated with any particular piece of L- mail or any particular receiver. We can think of a bank issuing such L-stamps. The bank keeps a record of the stamps and sells them to parties who want to affix them to e-mails. The stamps can then be redeemed at the bank by simply sending in the L-stamp ID#. (The stamps can be"one time pads"in the sense that the first redeemer is the one who is the presumed recipient.) However, if a mailing party buys such stamps and affixes them to e-mails, we can assume that the LS would keep a record of which L-stamps were affixed to which e-mails. Thus, we will not elaborate on L-stamps that are independent of pieces of L-mail. We will assume that an LS associates an L-stamp with a unique piece of L-mail.

L-Mail List If an LS enables Seneca to affix L-stamps to personal L-mails then it affixes the L-stamps one at a time per L-mail that Seneca sends. The programming means of the LS are then incorporated into Seneca's personal e-mail program. They enable him to affix L-stamps individually, much as he would affix stamps to physical mail.

But if an LS enables Seneca to send mass L-mails then it includes means for automating the stamping process. A set of instructions is needed that tells the LS how to apply L-stamps to a large number of e-mails. Further, a file of the mailing is needed. The set of instructions and the file can be the same entity. We will call this entity an L-mail list.

An L-mail list is a list of records, a table, in which each record-each row-corresponds to one L- stamp being sent to one address. We will call each record an L-stamp record or an L-mail record.

We use both terms because a record can been seen both ways, as a record for a stamp or a piece of mail. Each record is a set of fields. We present the main fields below (in no order of importance) and tell who fills information into them.

1) The L-mail list can include a field for the payer of the stamps. If the sender is responsible for paying the stamp this field is unnecessary. However, the LS may be operated by an agent of the sender so this field can be critical in practice. If the payer is not the sender then the identity of the payer can be added to the boilerplate.

2) The next field is for the address that an L-stamp (L-mail) is to be sent to.

(So, an L-mail list really begins with a raw list of addresses that is entered into an LS. The list is "filled out"by adding L-stamp information to each record in the list. Some of the information is entered into the LS and some is created by the LS.) 3) The next field is for the template ID which tells what template is to be sent to the address in the second field. Seneca enters a template into the LS and the LS creates an ID for that template. The template can be specified by a text description as well an ID, of course, in which case the record also incudes a field for a text description of the template.

4) The next field is for the L-stamp ID. The LS creates the L-stamp ID.

5) The next field is for the type of L-stamp. The type tells how the L-stamp information is to be added to the e-mail template. The type is entered by Seneca. When the LS applies the L-mail list, the LS checks the Type field and then calls the corresponding procedure. Procedures for different types of stamps are discussed in Chapters 5-7.

6) The next field is for the boilerplate ID which tells which boilerplate is to be affixed to the template. (The boilerplates will depend on the type of L-stamps, therefore the type might imply the boilerplate.) Seneca selects the relevant boilerplate.

7) The next field is for the EV. The EV is entered by Seneca.

8) The next field is for the payoff. The payoff is entered by Seneca.

9) The next field is for the expiration date. The date is entered by Seneca.

10) The next field is for the result. The result is filled in by the LS after it picks the winning and losing stamps (unless the RS determines the results).

11) Final field denotes the time the L-stamp (L-mail) is sent. The time is filled in by the LS.

Thus, a single record in an L-mail list might include the following: Payer: Seneca. Address: Reece@zip. org, Template#: 1234, L-stamp#: 666, Type: BCD, EV: $. 10, Boilerplate: BCD, Expiration: 11/22/97, Result: Winner, Time Sent: 11/9/97,10: 30 pm.

Not all these fields are mandatory for an L-mail list. Some may be taken to be understood. If an LS affixes only one type of L-stamp, for instance then the Type and Boilerplate fields are unnecessary. Obviously, a record does not have to include all these fields if a given piece of information applies to all the L-stamps in the list. For example, if the same EV and boilerplate apply to all the L-stamps it is wasteful to repeat the information in each record. We say that a record is made up of all these fields because it is easier to explain how the LS functions, what information it applies.

L-mail List Operations The fields in an L-mail list denote instructions that call procedures for creating, affixing and sending L-stamps. We describe these procedures below. We go into detail as necessary but keep most descriptions brief as they are either self-explanatory or have been discussed previously.

Where the procedures are particularly short we call them operations.

1) Payer If the sender is the payer, the boilerplate will state that fact. If the payer is another party who is using the sender as a mailing agent, then the payer field is important. The LS then adds the information in that field to the template (e. g., the payer's identity can be put in the boilerplate).

2) Address The address is where the L-stamp is to be sent and so the address tells the LS where to send the stamp and records where a given stamp was sent.

3) Template ID As discussed, a template is used by the LS to do a mass mailing. The template ID# tells the LS what template to get from memory. (There could be separate template ID's for the subject and body templates.) We will call the corresponding operation getting the template.

4) L-stamp ID As we said, an L-stamp needs to include some kind of identifier. There are, of course, many ways that an L-stamp can be identified. Although standard header information can uniquely identify an L-mail-and hence its L-stamp-we will assume that, in most cases, an extra ID# is added to an L-mail as part of its L-stamp. The extra number is what goes in the L-stamp ID field. The extra number may be used along with header information to constitute an L-stamp ID or the extra number itself may be enough to constitute the L-stamp ID.

Either way, when we say that the LS adds an ID we mean that it pulls the ID# from the L-stamp ID field and applies it to a template before sending. (We are not saying that this method is the best one for identifying an L-stamp. Other methods are well known, including cryptographic authentication protocols.) The LS would normally add the L-stamp ID to a template just before sending an L-mail to a given address. Thus, when we say that an LS adds an ID and sends out an L-mail, we will take it to be understood that the ID is actually added to a modified e-mail template at the time of sending. We call this operation adding the ID. As noted, adding the ID is not necessarily essential, since headers can identify an L-stamp.

5) Type of L-stamp The information in the type field defines the operations for affixed L-stamp information to an e- mail-how the result is revealed in particular, and how the stamp is redeemed. We discuss various types of stamps in Chapters 5-7.

6) Boilerplate ID An LS might have multiple boilerplates in memory, corresponding to different types of L-stamps.

The LS uses the boilerplate ID to get the corresponding boilerplate from memory and adds it to the body template, unless the boilerplate is abbreviated in a symbol placed in the header template, in which case the LS simply adds the corresponding symbol to the header template. We will call this operation adding the boilerplate.

7) EV When sending an L-mail, the LS checks the EV in an L-stamp record and adds it to the subject header. We call this operation adding the EV.

The LS could add the EV to another visible part of the header just as well. The main idea is that the EV is added so that the receiver can see it before opening the L-mail. A separate EV field may be included in an e-mail.

Of course, if the same EV applies to all the L-mails in an L-mail list then the LS could add the EV to the subject template and re-use that modified template for all the L-mails sent to that list.

As noted, the LS can also add the payoff amount and the odds of winning.

8) Payoff When affixing an L-stamp, the LS checks the payoff field in an L-stamp record and adds the payoff to the body (or header) template. We call this operation adding the payoff.

Adding the payoff may not be necessary because the payoff may be standard and understood. For example, a given payment credential might imply a standard payoff of $10.

The odds of an L-stamp winning are the EV/Payoff. These odds are automatically calculated by the LS and may be included in the L-stamp.

9) Expiration Date If the LS includes an expiration date in an L-stamp, the LS checks the expiration date field and adds the corresponding information to the body template. The RS checks this date when receiving a redemption e-mail.

10) Result The LS can add a result to an L-mail. If so, the LS includes a procedure for deciding the winners of L-stamp bets (the procedure will be some variant of the method taught in US patent #5,269,521).

Thus, the LS includes means for setting the EV and the payoff and a calculating the range of winning numbers such that the chances of a stamp winning are EV/Payoff. Then the LS gets a random integer in the range of 1-payoff amount. If the random integer is less than or equal to the EV then the stamp is a winner. Otherwise it is a loser. The LS then adds the result to the L-stamp record. We call this general procedure picking the winners.

Randomly selecting winning stamps can be done in various ways and needs no elaboration here.

However, for illustration's sake in this part, we give a procedure for selecting winning L-stamps that is suited to mass L-mailing. It is called spin the wheel. The LS executes the following steps when it spins the wheel: --Takes the L-mail list.

--Calculates the receiver's probability (EV/Payoff) of winning (we'll assume the probability is a fraction, 1/X, where X is an integer).

--Divides the list into sub-lists that have X addresses each and numbers each sub-list from 1 to X (if the original list does not divide evenly by X evenly the remainder list is numbered as well).

--Generates a random integer (N) in the range 1-X.

--Takes each record in the Nth position in each sub-list and sorts it into a new sub-list called Winners. Enters the result"Winner"in the result field of each record in this list.

--Sorts the all the remaining records into a new sub-list called Losers and enters the result"Loser" in the result field of each record in this list.

In other parts, we will not use spin the wheel and we will not go into detail about randomly selecting winners because such methods are well known. (We will discuss methods for preventing cheating but those have to do with insuring fair random selection, which is a different matter.) (Note: as discussed previously, the LS may not decide the L-stamp bets. That task may be done by the RS, in which case the RS adds the result to an L-stamp record.) 11) Time of Sending This field needs no elaboration.

Running the L-mail List, Running the Records In Chapter 5 we will discuss how the LS can use the L-mail list to affix L-stamps. To affix L- stamps, the LS runs the L-mail list. By this we mean that the LS applies the information in each record to create an e-mail that has an L-stamp affixed to it. We say that the LS runs a record when it applies an L-stamp to a single e-mail. The L-mail list is, in effect, a program and each record is a mini-program. (As noted, we are not concerned with coding efficiency. In fact the procedure will seem inefficient since we assume that steps are repeated for each record in an L-mail list.) We will assume in later discussions that the list is"filled in"-that Seneca, the LS operator, has entered the EV and the boilerplate ID and the template ID, the payoff amount, the expiration date, and that the LS has filled in the rest (has created L-stamp ID's, has spun the wheel, has entered L- stamp results).

When the LS"runs"an L-mail list it executes the following steps for each record in the list: --Gets the template corresponding to the template ID, --Adds the EV, --Adds the Payoff, --Adds the boilerplate corresponding to the boilerplate ID, --Adds the ID, --Checks the type field and follows the instructions for revealing the result, as dictated by the type (these instructions are shown in Chapter 5), --Sends the L-mail to the address in the record.

An LS for Sending Individual L-mails As noted in the Preface, we have focused on describing the core procedures of an LS for mass mailing. Where an LS (e-mail client) for sending individual 1-mails is concerned, an L-mail list is unnecessary. We can think of the LS using an L-mail list with one record. But let us simplify.

The user fills out an e-mail as he normally would. In addition, he will add an EV figure and a payoff figure. Further, he will add a credential indicating that he is sending an L-stamp. The LS may automatically affix this credential, upon a command from the user.

Now, as noted, there are many type of L-stamps, and so the LS will default to affixing one type (as described in Chapter 5) or the LS will enable the user to select the type of stamp. The LS will then affix it in the manner described in Chapter 5 (a simpler version is described in Chapter 6).

Now, the LS needs to spin the wheel. Thus, when sending the e-mail, the LS invokes an RNS to pick an integer from 1-Payoff amount. If the number is less than or equal to the EV, the receiver wins and the LS adds a winning message to the e-mail. If the RN is greater than the EV, the receiver loses and the LS affixes a losing message to the e-mail.

If the LS is run by a third party, such as a web service like Hotmail, then the RN will be assumed fair. But it the user can affect the RN selection, anti-cheat measures will need to be employed (see Chapter 9).

Chapter 4 Core Procedures for Redeeming L-stamps In this chapter, we give two core procedures for redeeming L-stamps and discuss a few features that any RS can include. a) Verifying a Winning Stamp When a recipient tries to redeem an L-stamp, she might be cheating. She might be trying to redeem a losing stamp or she might be trying to redeem the same stamp twice. The RS requires a procedure-which we call verifying the stamp-for stopping such cheats. To verify a winning L- stamp, the RS executes the following steps: Receives a redemption e-mail, Captures the L-stamp ID, Checks the L-mail list to see if the L-stamp ID is a Winner, If no, sends back a message saying that the receiver has lost, If yes, checks to see if this is the first time the receiver has tried to redeem the L-stamp, If no, sends back a message saying that the receiver is ineligible to collect more than once, If yes, follows the procedure for paying off the stamp.

(Here we are assuming that the RS is part of the same machine as the LS. If the RS is separate from the LS then the RS must input the L-mail list that is created by the LS. Thus, a prerequisite step for an independent RS is inputting the L-mail list, if the L-stamp results are decided by the LS.) b) Paying Off the Stamp For most L-stamps, part of the redemption procedure is standard, the part after an L-stamp has been verified as a winner. We call this part paying off the stamp. An RS executes the following steps when it pays off the stamp: Registers that the L-stamp for the original e-mail is being redeemed for the first time, and checks to see if the receiver's name and physical address are in stored in memory, If yes, outputs a check and mailing label for the receiver, If no, sends receiver a message telling her to send back her personal ID information by e-mail. The RS then takes this information and outputs a mailing label and check for her.

(A check can be electronic, if electronic funds transfer exists as an option.) Rather than sending checks or processing electronic fund transfers, the RS can simply output a list of people or addresses to whom checks should be sent. Another party can then take this list and do the actual paying. Thus, rather than outputting a mailing label for the receiver, the RS can simply add the receiver's name to a"redeemed"list and output the list.

Reply Procedures When an L-stamp is redeemed in most of the procedures described in this specification, the recipient must reply in some way to the L-mail she receives. Now, when we describe replying we usually assume the simplest course, meaning that the recipient replies in the way that people usually reply to e-mails, which is to hit the Reply or Forward button of their e-mail program. But there are alternative ways of replying and reasons why the simplest way is not always best. We discuss some alternatives below. We will assume that these alternatives are possible although, for the sake of brevity, we do not explicitly say so when describing those RS's.

Privacy Concerns When Replying When Seneca asks Reece to reply back to him that does not raise privacy concerns because Seneca already knows the content of the original L-mail. But, if Seneca asks Reece to reply to a third party RS that can raise a privacy problem because the RS can read the original L-mail if Reece hits her "Forward"button and sends the original e-mail to the RS.

To prevent this problem, the RS can include functions for automatically deleting the main message of an L-mail and leaving the key L-stamp information intact.

Of course, another alternative is to have Reece delete the main message herself and reply with just the L-stamp information. Depending on the redemption method involved, replying may simply be a matter of sending the L-stamp ID to the RS.

Replying to a Webform Replying to an e-mail address is only one way of replying to an L-mail. An alternative is for the RS to enable Reece to reply to a webform. Of course, this method is usually less convenient for Reece but it may be reasonable if she is responding to a winning L-stamp. Further, a winning L- stamp can be hypertext linked to the redemption webform.

Capturing ID Numbers, Automatically Parsing a Redemption E-mail When Reece tries to redeem an L-stamp, the RS needs to capture the L-stamp ID. If the ID number is simply the subject header and the address of the original L-mail the L-stamp was affixed to then all the necessary information is in standard e-mail headers. But, if the L-mail includes an additional ID number, the RS requires means for capturing that ID number automatically. These means are simple. The ID can be put in a standard position or it can be made up of a distinctive set of symbols that are distinguishable from the rest of the redemption e-mail.

In the rest of this specification, we will assume that the RS includes means for automatically capturing an L-stamp ID number when Reece tries to redeem an L-stamp by replying to an original L-mail.

Checking for a Payment Credential An RS may include means for automatically checking for a payment credential that is included as part of an L-stamp. If the credential is not present then the stamp is rejected.

When an RS is controlled by a third party (not the L-stamp sender, that is) a payment credential may be needed, as a practical matter. However, for convenience, we will usually omit credential checking means from the discussion and assume that they can be part of an RS.

Chapter 5 Categorizing L-stamps, L-Stamp Servers and Redemption Servers How the result of an L-stamp is revealed defines the L-stamp and defines how an LS and RS operate. Thus, we will categorize L-stamps, LS's, and RS's according to the conditions involved for revealing the results of the L-stamps and the conditions involved for redeeming the stamps.

Revealing results and redeeming stamps are operations that go hand in hand because, in most cases, a recipient finds out the result of an L-stamp as part of the process of redeeming the stamp.

There are several generic ways that the result of an L-mail is revealed: 1. The result can be revealed by just sending money to winners.

2. The result can be revealed in the header of the L-mail.

3. The result can be revealed in the body of the L-mail.

4. The result can be revealed in a follow-up e-mail or L-mail.

5. The result can be revealed by redeeming the L-mail (in this last way, the result is not revealed anywhere in the L-stamp).

In the rest of this chapter we will describe implementations of the first four ways. In Chapters 6 and 7 we will describe the fifth way.

Note: In each implementation we refer to the operations described in running an L-mail list (Chapter 3). To keep the discussion focused on the differences in implementations, we certain common operations already described-e. g., we omit the steps of adding an expiration date and checking that date, as these can be inferred from the previous discussion.

5a Just Sending Money to Winners One way that L-stamp results can be revealed is just to send the winners money. Everyone who gets money will know that they won and everyone who doesn't will know that they lost. In this method we assume that the FLS incudes a database linking legal names and physical addresses with e-mail addresses, so that recipients can be sent checks.

To affix such L-stamps, the FLS executes the following steps for each record in an L-mail list: 1) Gets the template, 2) Adds the EV. 3) Adds the boilerplate. 4) Adds the ID. 5) sends the modified template (not including result) to each address.

To redeem such L-stamps, the FLS executes the following steps: 1) Checks the L-mail list to find the names and addresses of each winner.

2) To each winner whose legal name and address it finds in the database, sends a check to and includes the L-stamp ID.

3) To each winner whose legal name and address it does not find in the database, sends an e-mail message telling the winner to mail in her personal ID data so she can be paid.

5b Reveal in Header One way that an L-stamp result can be revealed is to put it in the header of an e-mail. For example, (W) can mean"you won"and (L) can mean"you lost."Redemption instructions can be put in the body of the e-mails that are sent to winners. To affix such L-stamps, the LS executes the following steps for each record in an L-mail list: 1) Gets the template, 2) Adds the EV. 3) Adds the boilerplate. 4) Adds the ID. 5) Checks the result, --If the record shows a losing result, adds the losing message, (L), to the header template.

Sends the body template and modified header to the address in the record.

--If the record shows a winning result, adds the winning message, (W), to the header template, adds redemption instructions to the body template. Sends the modified body and header templates to the address in the record.

To enable receivers to redeem such L-stamps, the FLS executes the following steps: 1) Receives a redemption e-mail (a reply to the original L-mail sent to the receiver by the FLS). 2) Identifies the original L-mail by its L-stamp ID. 3) Verifies the stamp. 4) If the stamp is a legitimate winner, pays off the stamp.

5c Reveal in Body One reason for Seneca to pay Reece to receive an e-mail can be to give her an incentive to examine the contents of the e-mail. To this end, Seneca can have the result of an L-stamp revealed in the body of the L-mail it is affixed to, which forces Reece open the L-mail if she wants to find out the result. Thus, a class of L-stamps are those where the result is announced in the body of the L-mail.

Below we set forth various procedures that an LS can perform for affixing such stamps to e-mails.

The reason we give various procedures is that just putting the result in the body does not guarantee that Reece will open the L-mail. Additional tricks may have to be employed.

5cl Simple Reveal One procedure for redeeming an L-stamp is simply to have Reece reply to the L-mail, if and only if it contains a winning stamp. The reply is then taken as confirmation that Reece has seen the result and is trying to redeem a winning stamp.

The problem with this procedure is that Reece can cheat. She can reply to every L-mail in the hopes of redeeming winning stamps without having to actually open any L-mail. But, this cheat can be easily stopped. First of all, Reece may not know that she is able to redeem an L-stamp just by hitting the Reply button on her e-mail program. Second, her program may force her to open her e- mail in order to reply to it. Third, and most important, the RS can include means for checking whether she has tried to falsely redeem L-stamps in the past, and can penalize her for doing so.

(In verifying a winning stamp the FLS includes means for checking whether Reece has submitted a losing stamp. An FLS simply has to also include means for keeping track of how many times Reece tries this cheat.) So, given that cheating seems easy to stop, a simple way to encourage Reece to open an L-mail is to affix an L-stamp whose result is revealed in the body of the L-mail, and allow her to redeem a winning stamp by using the automatic Reply or Forward command of her e-mail program.

To affix such L-stamps, the LS executes the following steps for each record in an L-mail list: 1) Gets the template, 2) Adds the EV. 3) Adds the boilerplate. 4) Adds the ID. 5) Checks the result, --If the record shows a losing result, adds the losing message ("You lost") to the body template. Sends the modified template to the address in the record.

--If the record shows a winning result, adds the winning message ("You won") to the body template. Adds redemption instructions telling the recipient to redeem the winning L-stamp by replying to the L-mail. Sends the modified template to the address in the record.

The FLS executes the following steps for redeeming this kind of L-stamp: 1) Receives a redemption e-mail (a reply to the L-mail sent to the receiver by the FLS). 2) Identifies the original L-mail by its L-stamp ID. 3) Verifies the stamp. 4) If the stamp is a legitimate winner, pays off the stamp.

5c2 Revealing the Result by the Answer to a Yes/No Question The previous method has a vulnerability which is that it is mechanical, therefore an e-mail receiving program can potentially have enough intelligence to discover whether or not the L-stamp is a winner. The program can then automate the process of redeeming stamps without Reece ever opening her L-mails. So, it may become necessary to reveal the result in such a way that only human intelligence can determine whether an L-stamp is a winner or a loser.

The result can be given in a code that requires human intelligence to decipher. A simple code is one where Reece answers a yes/no question. For example a result can be revealed at the bottom of an L-mail in the following way, Result: If Mary is a girl's name, you win. Or, Result: If Harry is a girl's name, you win. Reece will understand such coded messages but a machine will not. A coded result message does not have to be in the form of a yes/no question. Other kinds of code questions can be used. For example, a coded message might be, What's the opposite of losing? Lucky you.

The key is that only a human can decipher the code and thus learn the result.

To enable the use of coded results in L-stamps, the LS includes means for entering coded text messages that substitute for Win and Lose. The LS then adds those codes to the template instead of the plain"Win"and"Lose"described above. Otherwise all the procedures are the same as above.

5c3 Spreading the Result Throughout the Body of the L-mail A way to make the result hard to find and to give Reece an incentive to look at the entire content of an L-mail is to spread the result throughout the content. Here the result is also in the form of a code. In this case, the code is a set of puzzle pieces (usually pieces of text) that are placed in various position in the body. For example, the result can be four words, each at the end of a paragraph, and the code can be,"You Have Not Won."A separate word can be put at the end of each paragraph.

To"spread the result"throughout the body of an L-mail requires that the FLS include means for entering the result as a text messages and then cutting it up and placing the pieces throughout the body. The positions of the pieces can be determined manually by the creator of the body message and placed automatically in the modified e-mail template. The puzzle pieces can also be specially formatted.

(Of course, there are two results, winning and losing. These may have puzzle pieces which can be placed in different positions.) The FLS will also include means for putting instructions in the body telling Reece how to assemble the puzzle pieces.

5c4 Redeeming With R-codes An R-code is a number or other identifier that Reece must capture and send back to the RS to prove that she has seen at least part of the content of the L-mail. An R-code does not tell the L- stamp result but it is necessary to redeem a winning stamp. It's purpose is to encourage Reece to open the L-mail and be exposed to it's content. An R-code can be put in the body of an e-mail in numerous ways. We will describe a few basic procedures for affixing and redeeming L-stamps with these codes.

Redeem by Replying to Special E-mail Address (or Special Website) One kind of R-code can be a special e-mail address for redeeming winning L-stamps. The only way Reece can find out where to send a winning L-stamp is by opening the L-mail and seeing the special address. The FLS executes the following steps for affixing this kind of L-stamp: 1) Gets the template, 2) Adds the EV. 3) Adds the boilerplate. 4) Adds the ID. 5) Checks the result, --If the record shows a losing result, adds the losing message ("You lost") to the body template. Sends the modified template to the address in the record.

--If the record shows a winning result, a. Associates the L-stamp ID in the record with a redemption e-mail address (adds a redemption address field to each winning L-mail record). b. Adds the winning message ("You won") to the body template and inserts instructions telling the recipient to redeem the winning L-stamp by sending a reply to the redemption address. c. Sends the modified template to the address in the record.

The FLS executes the following steps for redeeming this kind of L-stamp: 1) Receives an e-mail at the redemption address. 2) Identifies the original L-mail by its L-stamp ID. 3) Verifies the stamp. 4) If the stamp is a legitimate winner, pays off the stamp.

Redeem by Supplying R-Code An R-code does not have to be an e-mail address. It can be a number (or other identifying code) in the body of the e-mail that must be included when redeeming an L-stamp. For example, the FLS can insert, You Have Won! Your R-code is"Ed Wood". You can redeem your winning ticket by sending this R-code to redeem@L-mail. com.

1) Gets the template, 2) Adds the EV. 3) Adds the boilerplate. 4) Adds the ID. 5) Checks the result, --If the record shows a losing result, adds the losing message to the body template. Sends the modified template to the address in the record.

--If the record shows a winning result, a. Adds the winning message to the body template. b. Associates the L-stamp ID in the record with an R-code. c. Inserts an R-code in the body of the e-mail. d. Inserts redemption instructions in the body telling the recipient to redeem the winning L- stamp by sending a reply to an e-mail redemption address and to include the R-code with the reply. b. Associates the R-code with the L-stamp ID. e. Sends the modified template to the address in the record.

The FLS executes the following steps for redeeming this kind of L-stamp: 1) Receives a redemption e-mail including an R-code.

2) Identifies the original L-mail by L-stamp ED.

3) Finds the R-code.

4) Verifies the stamp (in this case by checking whether the R-code is associated with the Winners list).

5) If the stamp is a legitimate winner, pays off the stamp.

(We assume that the RS includes means for automatically capturing an R-code, if one is included, from Reece's reply e-mail.) No Point In Making the R-code Hard to Find Just as it is possible to make the result"hard"to find, it is possible to make the R-code hard to find by splitting it into pieces or by making it the answer to a question. But, usually these methods serve no point where an R-code is concerned because the R-code is used when stamps have won.

There is no use searching for an R-code if one's stamp has lost, which will be the case with over 90% of stamps.

5c5 Multiple L-stamps When the content of an e-mail is a long text piece or an audio or video clip, Seneca may want to take extra measures to insure that Reece is exposed to the whole message.

One way to encourage Reece to pay attention to the whole e-mail is to intersperse multiple L- stamps throughout the body of the e-mail. For example, Seneca's LS can insert an L-stamp for every page of text, every graphic image or every 15 seconds of a video, whichever applies.

Each L-stamp will consist of the same information as discussed previously-an EV amount, an L-stamp ID, a payer, and a recipient (and usually a payoff amount and probability of winning).

With more than one stamp per piece of L-mail, each stamp must have its own ID. (Recall the L- stamp ID can be made up of header information and an extra number that is added to an L-mail.) We will assume here that the extra number is the L-stamp ID although the full number might include Reece's address and other header information.

The L-mail subject header can tell the total EV of all the L-stamps affixed to the L-mail. The subject header can also tell how many L-stamps are in the body of the L-mail. Or that fact can be announced in the body of the L-mail. Or, it does not have to be announced at all.

The EV can be given along with each L-stamp. Or one message in the beginning of the body can suffice, if all the L-stamps have the same EV (e. g., Each L-stamp in this L-mail has an EV of $. 25).

If the EV is the same for each L-stamp then Reece will perceive an L-stamp as the ID that identifies it. The ID may be formatted for emphasis.

Moreover, when multiple L-stamp ID's are placed in the body, the result of each L-stamp can be given next to the ID. (If more than one L-stamp is included in an L-mail, there can be more than one winning stamp.) Reece can redeem a winning stamp by sending the whole L-mail to the RS. The RS can then parse the L-mail and find the winning ID or ID's. Alternatively, Reece can capture the winning ID or ID's and send it or them to the RS.

The LS places multiple stamps in the body as specified by the creator of the template. So, the LS enables the creator to place symbols in the template that signify where L-stamps go. We will call these symbols place-holders. The LS replaces the symbols with L-stamp ID's when the L-mails are sent.

If an LS is to add multiple stamps to an e-mail, the records of the L-mail list will contain fields for more than one ID. When the LS sends an L-mail to Reece, it pulls the ID's from the record identified by her address.

To affix multiple L-stamps to an e-mail template that is sent to multiple addresses, an FLS executes the following steps for each record in an L-mail list: (Note, we do not use the same set of steps below as we used before for picking winners, but the essential function of this procedure remains. We assume that an L-mail list is used in which each record has extra fields for multiple L-stamp ID's and L-stamp results. We assume that the LS has picked winning stamps with a probability of EV/Payoff and that a result has been filled into the result field for each ID. For simplicity, we assume that each L-stamp has the same EV and Payoff).

1) Gets template.

2) Multiplies the number of L-stamps in the record by their EV to get the Total EV.

3) Adds the Total EV to the subject header of the template.

4) Adds the number of L-stamps to the subject header.

5) Inserts a message into the body template stating the EV of each L-stamp.

6) Finds each place-holder in the body template and replaces each with a different L-stamp ID from the record.

7) For every winning L-stamp ID, adds a parenthetical winner's message ("You Won") next to the ID. For every losing L-stamp ID, adds a losing message ("You lost") next to the ID.

8) Sends the L-mail (modified body and header) to the address in the record.

The FLS executes the following steps for redeeming these L-stamps: 1) Receives a redemption e-mail including an L-stamp ID (there may be more than one winning ID but we'll assume that there is just one).

2) Registers (captures and stores) the L-stamp ID.

3) Checks the L-mail list to see if the L-stamp ID is a winner, If no, sends back a message saying that the receiver has lost, If yes, checks to see if the receiver has already tried to redeem the L-stamp, If yes, sends back a message saying that the receiver is ineligible to collect more than once, If no, pays off the stamp.

5c6 Two-Type Stamps An LS can also include means for affixing a"reveal in the header"stamp and a"reveal in the body stamp"to the same L-mail. The reason to have one of each type is that the first stamp pays Reece just for receiving the L-mail. The second stamp pays her for opening the L-mail.

5d Reveal Result in a Second E-mail One way that L-stamp results can be revealed is to send the winners a second e-mail. The first e- mail sets the terms of the L-stamp bet. The terms would name a neutral RNS and a time that the RN for the bet is to be selected. The time, of course, would be after the first e-mail is sent. Then, after the RN is selected, the LS would get the RN, determine whether the L-stamp was a winner or loser and then would send the result to Reece. This method is discussed further in the next Part on methods for insuring fair L-stamp bets.

Chapter 6 System for Redeeming L-stamps That Do Not Reveal Their Results A basic kind of 1-stamp is one that does not reveal its result to the recipient. To find out the result of this kind of stamp, Reece must send it to a redemption server (RS) that decides the result and then tells her if the stamp is a winner. We will call this kind of stamp a latent l-stamp.

This method of revealing results is inefficient compared to the others we have described because every stamp needs to be sent to the RS for redemption rather than just winning stamps. Yet this method is useful because it gives Reece the choice of finding out the result. She may not want to reveal the result as, for example, when a friend sends her a stamp. On his part, Seneca may want Reece to have the choice because he might expect, or hope, that she will not redeem the stamp he sends her.

Moreover, this method is useful because, as shown below, it enables Seneca to affix an I-stamp using an e-mail program that has no special means for affixing stamps. The RS can do all the work, so to speak. In fact, an RS for latent 1-stamps is a machine that does not have to have any connection to an LS.

This chapter is a specification for this kind of machine which we will call a Bet Executing Redemption System (BERS). For easier reading we will refer to it as simply BERS rather than a BERS or the BERS.

Note on Terminology For brevity, BERS will often be referred to anthropomorphically, though it is understood that BERS is a computer system that must include computer based means for executing its tasks. The aim, of course, is to reduce verbiage and describe what is new. Thus, when we say that BERS does something, or enables the user to do something, we mean that BERS includes means for performing these tasks. When we say that BERS includes a procedure we mean that the program that operates BERS includes the procedure. All the means we refer to can be readily implemented by those skilled in the art.

Considerable Space Describing a Machine for Redeeming Latent L-stamps We will spend considerable space, relatively, describing BERS because it may be very important commercially and because a"full featured"BERS involves a combination of many, different but integrated processes.

Recent history has shown that the major obstacle to the adoption of new electronic payment vehicles has been the perceived need to implement the vehicles through additional software, such as an"e-wallet", loaded onto a user's client machine. People have resisted adding such software.

BERS solves this problem, enabling people to affix 1-stamps using only their existing e-mail software. To add a stamp to an e-mail Seneca can, in the subjecgt header, simply type a credential denoting an 1-stamp contract, such as"U$", and an EV figure, such as. 05, (i. e.,"U$. 05"). These pieces of information signify an 1-stamp payment promise.

When Reece gets the e-mail, she can forward it to BERS which parses it, detects it's stamp (if any), decides the stamp's result, and, if the stamp is a winner, records the result and notifies the parties to the 1-stamp bet so that the bet can be paid off. BERS can act as a central redemption station performing this core process for a large community of users. Thus BERS can overcome the problem of making people add payment transaction software to their computers. Yet, in order to make 1-stamps practical and versatile payment vehicles in the markletplace, many functions should be added to this core process.

Core and Modules Approach We will first describe this core process in more detail and then describe features that can be added to it. The features are grouped according to their functions, as shown in the Contents below. We can think of these features as modules in the sense that they perform well defined tasks, and in the sense that they can be added to the core. (Note, we often use the terms module, process, procedure, feature, and function synonymously when referring to a set of steps that the invention performs to accomplish a well defined task.) BERS is a fundamental form of machine for enabling 1-stamps and, consequently, it can be adapted to handle a range of payment tasks. We focus on how it can be built to make the simplest 1-stamps into practical payment vehicles, but we will also explain how it can be adapted to handle more complex 1-stamps.

Contents of this Specification for a Bet Executing Redemption System (BERS) Section 1: Core Redemption Process of BERS Section 2: Features for Preventing Multiple Redemptions Section 3: Sign-Up Features Section 4: Features for Enabling Custom Payoffs Section 5: Billing and Payment Transfer Features Section 6: Features for Enforcing Payment Section 7: Features for Processing Credit Stamps Section 8: Miscellaneous Features Appendix: Processing L-Stamps on Fax and Voice Messages Section 1 Core Process for a Bet Executing Redemption System for L-stamps To redeem a latent 1-stamp, Reece forwards the e-mail the stamp is on to BERS. She hits the "Forward"command of her e-mail program so that the identity of the original sender is preserved in the header information.

Information identifying the original sender (or purporting to identify the original sender) must be included in a redemption e-mail so that money can be collected if the stamp is a winner.

Below we will give the core process for BERS. But first, let us give our assumptions for this minimal process while recognizing that they can be modified in practice.

Assumptions We assume that an 1-stamp is in the subject header of the stamped e-mail. Alternatively, it could be in a custom header field, specifically for e-stamps. Alternatively, it could be in the body of the e- mail, put in a standard place, or set off by a standard credential. The object is for the 1-stamp to be automatically parsable, and further, for it to be easily added to an e-mail and easily seen by the recipient. Hence, in general, the 1-stamp is best put in the sujbect header (until such time as e- postage headers become popular).

Although BERS could be controlled by Seneca, we will assume that it is controlled by a third party, and that it is used by a community of senders as a central redemption station.

We assume that Seneca sends Reece an e-mail with an 1-stamp in the header and that Reece forwards this e-mail to BERS.

We assume that the 1-stamp is signified by a payment credential.

We assume that the payoff amount is standard and signified by the payment credential, although in practice the amount could be variable.

We assume that the EV is variable, although it is possible for the credential to specify a standard EV along with a standard payoff.

A. The Minimal Core Process of BERS Given the assumptions above, BERS executes the following steps for redeeming a latent 1-stamp: --Receives a forwarded e-mail, --Parses the header to capture information defining an L-stamp: the address of the original sender of the e-mail, the address of the original receiver of the e-mail, a payment credential and an EV amount, If any 1-stamp information is missing, deletes the e-mail and stops.

If all the L-stamp information is present, Calculates the probability of the stamp winning as EV/Payoff (where Payoff is predetermined and stored in memory), Generates a random integer in a range from 1-Payoff (where the Payoff is denominated in the same units as the EV), If the random integer is greater than the EV, declares the stamp a loser, deletes the e-mail and stops.

If the random integer is less than or equal to the EV: declares the stamp a winner, registers in an internal database that the original receiver is owed the Payoff and that the original sender owes the Payoff, stores the e-mail (including all header information), sends an e-mail to both the sender and receiver notifying them of the bet result.

B. Using Time Stamp Data, Enforcing an Expiration Period for L-stamps Since timestamps are part of e-mail header data, BERS stores them as part of the data set it stores for a winning stamp. Timestamps can be useful for a variety of reasons, e. g., for authenticating an 1-mail. Another use of timestamps is to enforce an expiration period, if any, for latent 1-stamps. A standard expiration period may be part of the meta-rules of BERS, such as"expires if not received by BERS within one week from the time of original sending to the recipient". Or the expiration period may be a custom period explicitly stated in the 1-stamp.

Whether an 1-stamp is expired can be checked as the first step in processing a forwarded e-mail. If expired, the stamped e-mail would be deleted. However, since most 1-stamps will be unexpired, it more efficient for BERS to check for expiration after a stamp is declared a winner. Thus, after declaring that an 1-stamp is a winner, BERS can execute the following steps for enforcing the expiration date of the 1-stamp: --checks the time that the e-mail was originally sent to the recipient, --checks the time the e-mail was received by BERS, --checks whether the difference in the two times is greater than the standard I-stamp expiration period, If yes, deletes the e-mail, If no, executes the storing and notifying steps spelled out above.

If the expiration period can be determined by the sender, and is therefore added to the 1-stamp, BERS will include means for detecting that expiration period and for checking whether the period has expired.

C. Implementing Rules for Defining Who Is Liable for Payment Rules for defining who is liable for an 1-stamp are variable. The key question is: if Reece receives an 1-mail and then forwards it to Sally, is Reece sending a new 1-stamp to Sally? The meta-rules of the system can hold Reece responsible, or they may say that an 1-stamp cannot be forwarded to a new party, that an 1-stamp must be created fresh and sent in a new e-mail. Either way the rule is set, BERS can include steps for implementing it.

Thus, we said above that BERS detects the original sender and receiver of an e-mail. By these terms we meant the first party to send the 1-mail and the first party to receive it.

It is a simple matter to register, instead, the last party to receive an 1-mail, and the party who sent the 1-mail to the last recipient. The last recipient then becomes eligible to win the 1-stamp bet and the last sender becomes the party that is responsible for paying off the 1-stamp bet.

Thus, if its meta-rules specify it, BERS can register the last sender and the last recipient of a stamped e-mail. These may or may not be the same as the original sender and the original recipient.

D. Addressing a Privacy Concern What if Reece does not want BERS to receive the full stamped e-mail because she does not want to send the body content to a third party? In this case, she can delete the body content and forward just the header data. This data suffices as the 1-stamp.

(Alternatively, she can copy the 1-stamp information and send a new message to BERS. In this case, BERS requires means for parsing the body content to detect the 1-stamp and the original sender.) Minimal Functionality In it minimal role, BERS not only executes 1-stamp bets, it stores a stamped e-mail only when the stamp is a winner. It also notifies the two parties to the bet in this case. (It is possible for BERS to store data about all the e-mails it gets, but the object is to reduce storage and processing costs through the EVPM, through probabilistic processing that is.) After BERS notifies the parties, they can settle up payment. If there is a dispute, they can consult BERS which keeps the winning results for the purpose of providing evidence in case of payment disputes. Thus, BERS would have a database interface for users and administrators to could check its database in order to resolve disputes.

These operations of the core process define the minimal BERS. Yet, as noted, many features can be added to the core process to extend BERS beyond this minimal role. The next sections explain these features.

Important Note: Alternative Method for Redeeming Latent L-stamps An alternative redemption method can be used in cases where the RS is operated in concert with an LS (or LS's). In this case, the RS does not have to be BERS; it can use an L-mail list created by the LS in which winners have already been selected.

In this case, when the RS receives an e-mail, it parses the header to capture the L-stamp ID, and then checks against the L-mail list to see if the L-stamp is a winner. After finding out whether the stamp is a winner or loser, the RS can follow the relevant procedures discussed previously.

It is still an RS for latent 1-stamps because the stamps themselves have not revealed their results to the recipients.

Obviously, the"check against the 1-mail list"method differs fundamentally from the one above, in which BERS executes a bet for each e-mail that is received. Still, a central RS can employ both redemption methods.

The critical thing in the method using an 1-mail list, of course, is that the 1-mail list is stored in the RS (or is accessible to the RS). This condition is not feasible in the operation of a central RS that serves a public community of senders because the senders, especially individuals, will not universally submit 1-mail lists to the RS. Thus, we focus the specification on a bet executing RS, while recognizing that many of the features we describe can easily be incorporated into this alternate RS for latent 1-stamps.

Section 2 Features for Preventing Multiple Redemptions An implicit rule of latent 1-stamps is that the recipient can only get one chance at winning meaning that she is only allowed to redeem a stamp once. Thus, one seeming flaw in the core process is that it does not prevent a person from trying to redeem a stamp multiple times. But, multiple redemptions are revealed if the same stamp wins more than once, so the BERS database implicitly stores the evidence that can reveal this cheat.

To stop this cheat, then, BERS would include a procedure for checking whether a stamp has been declared a winner more than once. Thus, when BERS declares a stamp a winner, it then checks its database to see if the stamp has won before. If yes, BERS cancels the designation of winner, stores the e-mail, and BERS outputs a message notifying the system administrator of the fact.

Of course, a cheater can get away with redeeming a stamp more than once if the stamp does not win more than once. But, if the penalties are severe enough, it will not be worthwhile to take the risk that his stamp will win twice or more.

Still, a cheater may have one way of taking advantage of the core process. He can wait for BERS to notify him that he has won and if he does not get such a notification, he can try again to redeem the stamp.

To thwart this cheat, BERS can send a notification of winning to a recipient only after an 1-stamp has expired. If she redeems it after the expiration period, of course, she gains nothing. If she tries to redeem the stamp more than once before the expiration period ends, she cannot avoid the risk of winning more than once.

(Although the winning result would be hidden from Reece until the expiration period was over, BERS could notify Seneca immediately so that he would know of his debt obligation.) If BERS notifies winners immediately then, to stop the multiple redemption cheat, it must keep a log of Reece's redemptions. By this we mean that each time BERS receives a forwarded 1-mail from Reece, BERS stores the stamp in a redemption log for her, regardless of whether the stamp is a winner or loser (BERS does not likewise store the content).

When BERS stores a redemption, it also checks the log to see if the stamp has been redeemed before. If no, it continues and executes the bet for the stamp. If yes, it cancels the bet and writes in the log that Reece redeemed the stamp more than once. (BERS can also alert Seneca and the system administrator of the fact.) BERS can also keep a tally of how many times Reece has tried to redeem the same stamp (which is a useful thing it do if the meta rules of the system dictate that Reece gets penalized for multiple redemptions).

It is possible for BERS to execute a bet and store in a redemption attempt in parallel. In this case, if BERS finds a double redemptions attempt, and if BERS the stamp is a winner, BERS would cancels winning designation.

We should note that if Reece wins on the first redemption attempt and tries to redeem the stamp again, BERS can maintain the winning designation for that first redemption, while canceling any other winning results. The idea is that Reece has the right to redeem the stamp once. Yet doing so more than once is futile because of the redemption log checking procedure outlined just above.

To reduce the storage requirements of the redemption log, BERS can store a redemption attempt for a stamp for a short period of time, such as, until the expiration period of the stamp runs out.

Another way to keep this log light is to store stamps on a probabilistic basis. That way a cheater who tries to redeem a stamp multiple times will still run a probabilistic risk of being revealed.

However, a redemption log does not store much data so it can be feasible for BERS to store all of a user's redemption attempts made over a long period of time. Section 8 discusses the uses of keeping a long term redemption log.

Section 3 Sign-up Features: Establishing User Accounts Accounts for Senders of L-stamps For many reasons, it can be useful for BERS to include a sign-up procedure for creating user accounts for senders of 1-stamps. We will call these sender accounts. BERS will thus include a database of sender accounts. BERS will include a registration procedure for enabling a user to set up a sender account, presenting a user with a form, such as a webform for entering data. Such procedures are well known and need no elaboration.

Yet, what should be noted is that BERS is a system that may not require senders to sign-up in order to use the system. Using an 1-stamp credential may be enough to imply that the sender accepts BERS's terms of service. Moreover, any time a sender loses an 1-stamp bet, BERS records the event, whether or not the sender has signed up. At this point, BERS automatically creates a sender account. (This account will not contain as much information as an account that Seneca opens himself because Seneca does not enter data into the account. Of course, BERS can enable Seneca to add to the data that BERS automatically stores in the account. If an account is created without a registration process BERS will note that in the account.

One reason for having Seneca open an account is that the registration process can include a step for accepting BERS's terms of service. This step is not essential for enforcing 1-stamp contacts, but may be desirable.

Another reason is to register ID and payment data (such as a credit card number) so that Seneca can pay off a winning stamp. In addition, BERS can give Seneca a password so that he can access the records that BERS keeps about him. When creating a sender account BERS can also register data for authenticating Seneca (which can help enforce actual payment).

Another key reason to have Seneca open an account is to enable him to enter preferences for how his 1-stamps are to be redeemed. These preferences can include: a) The payoff amount of his stamps specifying the payoff he is risking in every 1-stamp bet (see Section 4). For example, a typical individual may accept BERS default payoff which is, say, $5, whereas IBM might specify a payoff amount of $500. b) A limit on the EV of his stamps. Seneca may be concerned that someone will forge his stamps with a large EV amount. Or, if Seneca is a corporation, he might be concerned that an employee might use stamps with too high a value. Thus, Seneca may want to limit the EV off his stamps (see Section 5). c) A limit on the total value of 1-stamps he can send in a day. While Seneca might limit the EV on his stamps, large numbers of stamps can easily be sent, defeating the purpose of setting a limit on the individual stamps. The trouble with limiting the total value is that, since 1-stamps are lottery tickets, no one can know in advance the total actual liability for a given number of stamps.

Therefore, this limit can specify the maximum number of stamps he will pay off that are sent on any given day. d) The type of payment account, e. g., credit or debit. BERS can include means for enabling users to set up different kinds of accounts, that involve different methods of transferring actual payment (see Section 5). One important kind of account is a group account that lets multiple senders be billed under the same name, such as a corporate name.

A sender account will also include a sender payment file where BERS stores information about the sender's payments (see section 5).

A sender account can be considered a single file or a grouping of linked sub-files: a sender ID file, a sender preferences file, a sender payment file. The point is that BERS includes means for creating and maintaining sender accounts that contain fields for storing: 1. sender ID data, 2. sender preferences that include: a. the payoff amount of his stamps, b. a limit on the EV of his stamps, c. a limit on the number of stamp he will pay off sent on a given day, d. the type of payment account, e. g., credit, debit, group.

3. sender payment data.

BERS can make this data available through any well known interface.

Accounts for Receivers of L-stamps BERS can also include a sign-up procedure for creating user accounts for receivers, which we will call receiver accounts.

(A sender and receiver account for the same person can, of course, be combined into a single user account.) Depending on the meta-rules of BERS, a receiver account could be set up only when a person wins an 1-stamp bet. That way, receivers would not have to waste their time doing a pre-sign-up process.

Once Reece has won an 1-stamp bet, she needs to be paid, therefore it is useful for BERS to have a procedure for creating an account for her. The account is particularly useful if she wins more than once.

As with a sender account, a receiver account can be considered a single file or a grouping of linked sub-files. The point is that BERS includes means for creating and maintaining receiver accounts that contain fields for holding the following kinds of data about a receivers of 1-stamps: Thus, a receiver account can include fields for storing: 1. receiver ID data, 2. receiver preferences: the key preference being the payoff amount of the stamps she receives (see parlay option in Section 4), 3. receiver payment data (see Section 5).

Section 4 Features for Enabling Custom Payoffs In the core procedure we assumed that a latent 1-stamp had a standard payoff amount. For example, Seneca might have to pay Reece $5 if he lost the 1-stamp bet. Yet, higher payoffs are transactionally more efficient and, therefore, senders with a higher tolerance for losses would like to set a higher payoff than the minimum standard payoff. So, BERS can include procedures that enable senders to set the payoff amount. There are three basic ways of accomplishing this goal.

We describe these below.

A. Using Standard Credentials to Denote Standard Payoff Amounts One simple way to accomplish this goal is to have a variety of latent 1-stamps, each signified by a different credential, each credential denoting a different payoff amount.

BERS can include means for detecting more than one kind of payment credential. Likewise, it can include means for assigning a particular payoff amount to a credential. Thus, when BERS receives an e-mail and detects an 1-stamp payment credential, BERS sets the payoff for the 1-stamp bet to correspond to the payoff for that credential.

B. Using a Payoff Field to Denote the Payoff Amount A second way of accomplishing this goal is to enable senders to specify the payoff amount, just as they specify the EV amount.

BERS can have meta-rules that define a field-a standard position placement in an e-mail-for denoting the payoff amount of an 1-stamp, just as they would for the EV. Accordingly, BERS can include means for parsing the e-mail to find that payoff amount. Upon finding the amount, BERS sets the payoff for the 1-stamp bet to that amount.

Now, the meta-rules may also set a limit on how high and how low a payoff amount can be.

Accordingly, BERS can also store a default payoff amount for an 1-stamp that displays an amount that is above the maximum, and a default for an 1-stamp that displays an amount that is below the minimum.

C. Letting the Sender Set the Payoff Amount Through His Sender Account A third way of accomplishing this goal is to let Seneca set the payoff amount as a preference in his sender account (as noted in Section 3 of this chapter). If BERS includes such means then, upon detecting an 1-stamp credential, BERS checks its sender account database to find the payoff amount that corresponds to the sender. If it finds that Seneca set an amount, it sets the payoff in the 1-stamp bet to that amount. Otherwise, it sets the payoff amount in the bet to the default amount.

Now, in order to process stamps more efficiently, BERS can first execute an EVPM bet where the payoff amount is the standard amount, which we will assume is the minimum payoff amount allowed under BERS's meta-rules. Then, after provisionally declaring the I-stamp a winner, BERS would check its sender account database to find out whether Seneca set a custom payoff amount higher than the standard amount. If no, BERS would follow the procedure already described for registering a winning stamp. If yes, BERS would execute another EVPM bet where the payoff is set at the custom amount and where Seneca's odds of losing are: (standard payoff)/ (custom payoff). If Seneca loses again, BERS declares the stamp a winner and registers that Seneca owes Reece the higher payoff amount.

Recipient Sets Payoff (Parlay Option) Now, it is also possible to enable Reece to set the payoff amount. In order to do this, BERS can include a parlay option for winners. By that we mean that Reece specifies that she will parlay her winnings in a second EVPM bet where her odds of winning are (initial payoff)/ (larger payoff).

BERS can enable Reece to select this larger, custom payoff.

As noted in Section 2, BERS can enable Reece to set up a receiver account where she can state that she prefers to parlay her winnings. Thus, when she wins an 1-stamp bet, BERS checks its receiver account database to see if she wants to parlay her winnings. If yes, BERS executes a bet where her odds of winning are (initial payoff)/ (custom payoff).

The parlay option is natural if BERS acts as a payment transfer agent that collects payment from Seneca and disburses it to Reece. In this case, BERS would execute this second EVPM bet after receiving payment from Seneca for the initial payoff debt. BERS would then take the risk of losing this second bet, and would pay off if Reece won the bet. BERS would take this risk, of course, to increase the efficiency of paying recipients.

We note that BERS might automatically act as a payment transfer agent that takes an EVPM bet risk for efficiency's sake. In this case, Reece will have no choice but to engage in some kind of parlay option. Thus, Seneca might face a maximum liability per bet of, say $5, while Reece would have the chance of winning, say $500. See Section 5. Even in this case, BERS can enable Reece to set a payoff amount that is higher than a default amount.

Section 5 Payment Transfer Agent Features: Registering Debts and Credits, and Collecting and Disbursing Funds As described in Section 1, BERS notifies the loser and winner in an 1-stamp bet and keeps evidence-the stamped e-mail-of the debt. BERS can include additional billing functions, such as the tallying of debts.

Given that BERS is a central redemption station for a community of users, it can also be very useful for BERS to include payment transfering functionality. Centralizing payment saves users from trying to collect payment from each other. Moreover, it enables reliable credit data to be gathered, and offers various other efficiency gains.

In this section we will describe means BERS can include for billing and for transferring payment.

We describe these two different kinds of means in the same section because they operate hand in hand (although it's possible for BERS to only do billing while communicating with an independent entity that handles payment transfers).

BERS can also include means for enforcing payment. In fact, the debt records it keeps, discussed in Section 1 and elaborated on in this section, are essential for enforcing payment. We delve into enforcement means in the next section, building upon the features described in this section.

Paying Off Winning Stamps To pay off a stamp-to pay off Reece if she wins an I-stamp bet-BERS needs to collect money from Seneca and transfer it to her.

(In previous descriptions of RS's we assumed that the RS is controlled by Seneca, or a party associated with Seneca, such that the RS"has"the money to pay off winners. We did not delve into collection issues as they were subsidiary. But, if BERS is a central redemption station for a large community of Seneca's then collection mechanisms become crucial.) Collecting money from Seneca can be done in two basic ways. a) Seneca can establish a debit account with BERS (say, by registering a credit card number). He can pre-pay an amount to cover losing bets. Or, if his account is backed up by a credit card, the card can be charged when he loses a bet. Alternatively, if he pre-pays, BERS can deduct the EV of every stamp sent by him and forwarded by Reece, regardless of whether the stamps are winners or losers. In this case, BERS takes the bet risk, paying off those stamps that are winners. b) Seneca can be extended credit by BERS (by Reece really). If he loses a bet, BERS sends him a bill. If he does not pay the bill then BERS registers a bad debt to him. The advantage of this method is that Seneca does not have to pre-register an account. Of course, some people will welsh, but penalties can make most people pay up (see Section 6).

Defining Credit and Debit (Pre-registered) Accounts Obviously, various kinds of accounts can be established, secured by various kinds of promises and financial instruments. We distinguish between a debit account (a pre-registered payment account) and a credit account.

A credit account is one that is secured only by Seneca's promise to pay, which he makes to Reece and BERS when he affixes a latent 1-stamp.

A pre-registered payment account or debit account is one that is secured by a deposit or a secondary credit instrument, such as a credit card. We might call it a secured payment account.

This kind of account requires pre-registration. Also, it potentially enables payment to be transferred automatically to Reece by BERS.

We could distinguish between accounts that are secured by a deposit from accounts secured by a credit card but we will not since the distinction we want to make is between credit accounts that are not secured and debit accounts that are secured in some way and that require pre-registration.

The Focus Is on Credit Accounts Below, and in Section 6, we describe the features of a BERS that extends credit on behalf of Reece's who are owed money. We focus on describing this system, rather than a debit account system, because it involves novel features tailored to redeeming latent 1-stamps, and because we guess that it will be more successful in the marketplace.

Another reason to focus on credit accounts has to do with the kinds of 1-stamps that BERS processes. If these stamps are cryptographically secure, using undeniable signatures, for example, then a debit account can be used without confirming a debt with Seneca. When a stamp with Seneca's signature is declared a winner, then Seneca's account is debited.

But, if stamps are used that are easily forged, then BERS needs to confirm with Seneca that a debt is valid, regardless of whether Seneca has a debit account or not. Thus, the debit account will not necessarily operate in the way that conventional debit accounts operate. In a sense, it is really very much like a credit account because Seneca's account will not automatically be debited, and he will have the option of refusing to pay an 1-stamp debt.

Note, then, that most of the procedures described below and in the Section 6 can be included in a system that uses debit accounts. Modifications for enabling debit accounts are easily implemented by those skilled in the art. On occasion, we will describe features tailored for debit accounts.

We also note that BERS can include escrow accounts. The reason for these is that 1-stamp debts may be disputed. Thus, escrow accounts can assure payment, especially if payment is overseen by independent judges who determine whether a debt is valid or not.

Registering, Tallying and Sending Bills If BERS extends credit it needs functions for totaling up a sender's debts. Here we supply a set of steps not only for sending a bill-as described in Section 1-but also for tallying debt totals.

Thus, BERS executes the following steps for billing when it declares an 1-stamp a winner: --checks if an account has been established for the sender, if no, establishes an account identified by the sender's address, registers that the sender owes the Payoff to the receiver, sets the sender's Debt Total to the Payoff, and sends a bill to the sender for the Payoff. if yes, registers that the sender owes the Payoff to the receiver, adds the Payoff to the Debt Total for the sender, sends a bill to the sender for the Payoff, and checks whether the sender's Debt Total is above a threshold, if no, stops. if yes, sends a bill for the Debt Total to the sender's address.

(It is possible, of course, for BERS to send a bill only when Seneca's Debt Total reaches a threshold, rather than per losing 1-stamp.) Receiving and Transferring Payment Naturally, in order to pay off a stamp, BERS requires procedures for registering the receipt of payments from senders and for transferring payments to receivers. A payment may be by paper check, in which case a system operator would enter the payment into BERS. Or, the payment might be sent by electronic funds transfer. We assume that BERS can receive and disburse payment by any commercially available means. Thus, upon receiving payment from a sender, BERS can execute the following steps for transferring this payment to a receiver or receivers: --registers the Payment Amount in the sender's account, --deducts the Payment Amount from the Debt Total, --to each receiver listed in the sender's account, allocates a share of the Payment amount equal to her share of the Debt Total, --registers a credit to each receiver of her share of the Payment Amount.

(Note, when Seneca owes money to multiple Reece's, and when he makes a payment that does not cover his full debt total, then Seneca's payment can be apportioned among the Reece's in various ways. Above, we simply assume that each Reece gets a share equal to her share of the Debt Total.

Later in the discussion we will assume, differently, that payments are made for designated debts- i. e. to designated Reece's.) If Reece is not registered with BERS, as will often be the case, BERS needs to find out her legal name so that it can send her a check. To find out her name, it can notify her by e-mail that she has won the 1-stamp bet and ask her to send her legal name to a redemption address. BERS can include a registration form in the e-mail it sends her.

The fact that she responds to the e-mail can be taken as evidence of her identity-evidence that she controls the e-mail box that the 1-stamp was originally sent to. (Stronger authentication methods can be employed, should they prove necessary.) Thus, BERS will also include means for receiving and verifying e-mails that are responses to the e-mail notifications sent to winners. BERS will also include means for parsing these e-mails to capture the ID data necessary for making payment.

BERS can also include means for enabling winners to register through a webform on a webpage.

Having captured her ID data for payment, BERS can then output a check to her or pay her by electronic funds transfer (or BERS can delegate the task to a payment agent).

As discussed in Section 3, BERS can also create an account for Reece where it lists and tallies the credits due to her from different Seneca's. When payment is made to Reece, BERS credits the relevant sender and deducts the payment from the total amount owed her.

Additional Features to Be Described Below we describe additional billing and payment transfer features that BERS can include. Where these are concerned, BERS performs five general functions that we can think of as stages in a process that begins after BERS declares a stamp a winner.

In stage 1, BERS registers data about the winning stamp (which represents a purported debt owed by Seneca to Reece).

In stage 2, BERS communicates the stamp result to Seneca and Reece.

In stage 3, BERS registers Seneca's and Reece's reactions, if any, to the result ("react" encompasses various actions, including paying the debt).

In stage 4, BERS uses the data registered in stages 1 and 3 to create statistics about Seneca and Reece regarding their payment histories.

In stage 5, BERS uses the statistics of stage 4 to enforce payment.

Below we describe features that fall under these general headings. Note, in this section we describe features of stages 1-3, and in the next section we describe features of stages 4 and 5. (For clarity's sake, and because we have preserved parts of the parent above, the discussion below repeats some of the discussion above.) Stage 1: Registering Data About a Winning Stamp In this sub-section we will discuss the kinds of data that BERS can register about a winning stamp-about the debt that the stamp purportedly represents (we say"purportedly"because the stamp may be bogus).

As explained in Section 1, BERS stores a winning stamp and its associated e-mail content in a database. Let us now discuss in more detail the records and files that BERS can create and maintain for inputting and outputting data about debts, credits and payments. These kinds of records are well known, and are implied above, yet we delve into them briefly so that we can disclose novel features that enhance BERS's capability to act as a central redemption bureau for latent 1-stamps.

As usual, we are not concerned about coding efficiency. We give one scheme for storing data about winning 1-stamps but realize that many other equivalent schemes are possible. The key thing we are trying to describe are the kinds of useful information that BERS can register.

Debt Records Defined BERS stores information about a winning 1-stamp in a record we call a debt record. We could call it an winning l-stamp record, of course, but the name signifies that the record is about the purported debt that a winning l-stamp represents. A debt record, then, is the"atom"of the BERS database of payment information.

A debt record is a file (table) composed of debt description fields that contain information that describes the debt.

At minimum, these fields contain the 1-stamp data previously described: the original EV, the amount of the debt (the payoff amount of the stamp), the debtor (the sender of a winning 1-stamp) and the creditor (the recipient of a winning stamp), the time of sending and receiving. The debt record will also contain an identifier for retrieving the stored content of the e-mail that the stamp was on.

A debt record can contain more information, supplied by users. We will elaborate on this additional information as the discussion progresses.

Debt Records Mirrored in Payment Files BERS stores debt records in a payments database.

We will also say that BERS creates a sender payment file where BERS mirrors the information from all of the debt records for a given sender. In other words, a sender payment file is the file where BERS lists debt records for a given sender and where BERS stores statistics about the sender's payment history. We can think of this file as a sender's debtfile because it concerns the debts that the sender owes. A sender's payment file is a sub-file of a sender's account.

Likewise, BERS creates a receiver payment file where BERS mirrors the information from all of the debt records for a given receiver. In other words, a receiver payment file is the file where BERS lists debt records for a given receiver and where BERS stores statistics about the receiver's payment history. We can think of this file as a receiver's payoff file because it concerns the payoffs that the receiver is owed. A receiver's payment file is a sub-file of a receiver's account.

(Note: BERS does not have to create actual payment files, it can create them as necessary from the data in the payments database. Payment files then are, essentially, groupings of payment data, as described above.) More Operations in the Registration Stage Thus far we have described the basic operations that BERS performs when it registers data about a wining stamp. BERS can perform additional operations as explained below.

Storing a Debt Under a Group Account As discussed in Section 3, BERS can enable a company or organization to establish a group account, and to create a list of authorized users. In the group payment file, BERS lists the individual payment files of authorized users, and tallies the debt totals in each file to arrive and a debt total for the group. Thus, if Seneca's account is part of a group account, then when BERS reflects a debt record in Seneca's payment file, it ultimately reflects that record in a group payment file.

Methods for implementing group payment accounts are well known and need no elaboration here, but we note that the capacity to create and maintain group accounts is a highly useful functionality for BERS to have.

Checking the EV of a Stamp As discussed in Section 3, BERS can enable Seneca to set an EV limit for his stamps. To operationalize this limit, BERS executes the following steps as after declaring an 1-stamp a winner: --checks the sender's preferences file to see if there is an EV limit set, if no, writes nothing extra in the debt record, if yes, checks whether the EV of the stamp is greater than the limit, if no, writes nothing extra in the debt record, if yes, writes that the EV of the stamp exceeds the limit and writes the amount in excess of the limit.

Now, depending on the meta-rules of the system, the 1-stamp may be nullified if its EV is greater than the limit. But BERS will keep the debt record, and write in a field in the record that the EV was too high, and notify both Seneca and Reece that the EV is too high.

(Note, it is possible for BERS to check an I-stamp's EV against Seneca's limit before BERS executes the 1-stamp bet. That way every stamp is checked rather than just winning stamps. Doing this test before executing the bet can more quickly reveal that Seneca or someone else is cheating, but is inefficient. In this scenario, if BERS finds that the EV of a stamp is above Seneca's limit then BERS registers the fact in Seneca's payment file. Thus, a sender payment file can include fields for registering each time that BERS receives a losing stamp whose EV is too high.) Enforcing a Stamp Limit Set by the Sender As discussed in Section 3, BERS can enable Seneca to set a limit on the number of stamps, sent per day, that he will pay off. To operationalize this limit, BERS executes the following steps as after declaring an 1-stamp a winner: --checks the sender's preferences file to see if there is a stamp limit set, if no, writes nothing extra in the debt record, if yes, checks the date that the stamp was sent and puts the stamp in a log for that date, tallies the payoff value of the stamps in the log, if the total payoff value is greater than the stamp limit: --writes in the debt record that the stamp is over the sender's limit for that date, --notifies the sender and receiver that the stamp is a winner but that it is over the sender's stamp limit.

(BERS can also include means for checking every stamp that Seneca sends and that is redeemed.

In this way, BERS can enforce a definite limit on the total number of stamps, sent per day, that Seneca will allow to be redeemed. We have assumed, of course, that BERS executes an 1-stamp bet before doing other processing of a stamp, but it is possible to do this pre-processing as well.) Checking the Whether a Guaranteed Stamp Is Genuine As noted, we are focusing this description on a BERS that extends credit to Seneca on behalf of Reece. But Reece may not want to accept stamps that are backed only by Seneca's promise to pay.

Reece may want to accept only guaranteed stamps that are backed up by some kind of additional assurance that Reece will be paid if the stamp she receives is a winner. One such guarantee is that Seneca has already deposited funds with BERS in an escrow account to pay off winning stamps.

A stamp can come with a credential that signifies this guarantee.

Thus, when processing this kind of stamp, BERS can check whether Seneca indeed has the funds in his account to cover the payoff. If not, BERS can register in the debt record that Seneca did not have the funds in his account to cover the debt. And BERS can notify both Seneca and Reece of this fact, and can write the fact in the debt record.

It is possible for BERS to perform this test before executing a bet. In this case, if BERS find that Seneca did not have the funds in his account to pay off a potential loss, BERS registers the fact in Seneca's payment file but not necessarily in a debt record (BERS still executes the bet but if the stamp is a loser no debt record is created).

Stage 2: Communicating Payment Data to Users As discussed, BERS notifies Seneca and Reece of the result of a winning stamp. In addition, with every notification sent to Seneca, BERS can check Seneca's current Debt Total and send that in the notification as well. Alternatively, BERS can send Seneca his Debt Total only when it goes over a threshold.

If BERS includes means for checking whether the EV of a stamp is too high it will also include means for automatically notifying Seneca and Reece if it finds that the EV is over Seneca's limit.

Likewise, if BERS includes means for checking whether a guaranteed stamp is supported by adequate funds, BERS will include means for notifying Seneca and Reece if it find that a guaranteed stamp is bogus.

BERS will also include an interface or interfaces for enabling Seneca and Reece to access their payment files. These interfaces are well known and need no elaboration. We simply point out that if BERS acts as a central billing and payment transfer agent, then it is very useful for BERS to include functionality for enabling users to access their payment data.

As will be explained in Section 6, BERS can also enable third parties to search it's payment database.

Stage 3: Registering Reactions to a Debt BERS can register various reactions to a debt. We begin by dividing the reactions into two kinds: payments and comments.

Registering Payments As noted, BERS can include means for registering the receipt of payment. Above we said that when Seneca makes a payment BERS divides the payment in a fair proportion among Seneca's creditors. From here on out, though, we will assume for simplicity's sake that when Seneca makes a payment that the payment goes to pay off a single, designated debt.

Thus, BERS will include means for enabling Seneca to identify the debt that his payment is meant to satisfy. BERS captures the identifier, finds the corresponding debt, and writes in the debt record that the debt is satisfied. And BERS time stamps the payment. The payment is then reflected in Seneca's and Reece's payment files.

Conversely, if a debt is unpaid, the debt record (and user payment files) will show that by the absence of a payment.

(Now, it is clear that in the real world senders will submit underpayments. We recognize that and point out that all the accounting functions discussed in this specification can be easily modified to accommodate partial payments. Of course, a debt record can include fields for indicating what percentage of a debt has been paid off and when. We simplify by assuming that a debt is either fully satisfied or not paid at all.) Paying Reece by the Expected Value Payment Method When Reece is owed less than a threshold amount, and when BERS has collected the money owed from Seneca, BERS can pay Reece by the EVPM. For example, if BERS collects $5 from Seneca for Reece, BERS can make a bet where Reece can win, say, $100. If Reece wins the bet, BERS pays her $100. In fact, paying Reece through the EVPM may be the standard procedure because of its efficiency.

As noted, BERS can enable Reece to specify that she wants to parlay her winnings in a bet where she sets the payoff. If this option exists, then upon receiving payment from Seneca, BERS checks Reece's preference file to see whether she has chosen the parlay option. If so, BERS executes an EVPM where she can win the payoff she has set.

Aside: Delegating Payment Handling Functions It is possible for BERS not to handle the actual transferring of payment but to rely on a third party payment agent or agents. This scenario may well be the one preferred in the marketplace. Under this scenario, BERS would still communicate with the agent and, hence, the records that BERS would keep would essentially be the same. Instead of registering payments that it receives, BERS would simply register payments that agents received, as reported to BERS by those agents.

Likewise, BERS would register disbursements made by agents.

Thus, while we assume that BERS handles payment collections and disbursements, we recognize that it can be configured, with minor modification, to delegate the payment handling task to third party agents.

Registering Comments As a redemption station for 1-stamps that may be easy to forge, and that usually have a low EV, it is useful for BERS to include means for enabling debtors and creditors to state whether a debt is valid or not, and to state what to do about the debt. We will call such statements comments and will describe standard comments that BERS can enable Seneca and Reece to make about an 1-stamp debt.

BERS can provide e-mail and/or webform means for enabling users to enter comments. BERS writes the comments in a debt record in named fields for that purpose. Whenever one party enters a comment, BERS notifies the other party of the comment.

When BERS sends a bill or other notification, it can include an e-mail form for entering comments. For example, BERS can enable Seneca to enter his objection to a debt on a form that is part of a bill for the debt. The bill can include a debt record identifier so that Seneca does not have to identify the debt. BERS can include this identifier with every notification it sends.

When enabling a user to enter a comment in a debt record, BERS verifies that the user is the credit or debtor for that debt record. Importantly, BERS can also enable third parties-authorized judges and debt collectors, that is-to enter comments. BERS can transmit their comments to Seneca and Reece as well.

1. Forgiving a Debt BERS can enable Reece to say that she forgives a debt. When Reece enters this comment BERS writes the comment in the debt record. Alternatively, BERS can erase the debt record altogether.

Further, BERS erases the debt from Seneca's payment file and erases the corresponding credit in Reece's payment file.

2. Asserting That a Debt Is Valid BERS can also enable Reece to assert that a debt is valid. Reece may want to express that she feels that a debt is valid and should be collected on. BERS can also enable her to select from a set of reasons why the debt is valid, e. g.,"obvious spam". BERS registers the reason as well and can also enable her to enter a text explanation.

The reason this feature is especially useful is that I-stamp debts, often being small, may not be worth collecting on. Moreover, 1-stamps debts can be denied for a variety of reasons, e. g., because of forgery. So, if human collection agents are to try to collect on a small debt, they will want evidence that the debt is valid. Other than the sender, the receiver is in the best position to know if an e-mail has genuinely been sent from the address it purports to be from and by the party it purports to be from. Thus, the comment of the receiver can be pivotal evidence in this regard.

3. Assigning a Debt BERS can enable Reece to assign her debt to a collection agency. BERS might list a default agency or it may let her to pick from a set of agencies. There may be competition among agencies offering different payouts to Reece. Thus, BERS can enable Reece to see not only a selection of agencies but their offers to Reece as well. (We note that the meta-rules of BERS may be that a debt is assigned by system operators to a particular agency or that the debt is sold to the highest bidder.) 4. Denying a Debt BERS can enable Seneca to deny a debt. BERS can also enable him to select a from a standard set of reasons why the debt is invalid, such as,"my address was forged". BERS can also enable him to enter a text explanation. Upon registering a denial in the debt record, BERS notifies Reece that Seneca has denied the debt. Reece can then respond.

5. Challenging a Debt Denial BERS can enable Reece to challenge a denial through the means described above for asserting that a debt is valid.

6. Judging the Validity of a Debt BERS can enable an authorized judge to enter into a debt record a determination as to whether the debt is valid. Thus, BERS will include means for authenticating judges and creating user accounts for judges (judges can be considered a separate class of user).

BERS can also enable Seneca or Reece to enter a request for a judge to decide the validity of a debt. BERS can include, then, a list of such judges. Payment for the judge can be handled in a variety of ways and there is no point elaborating on those, except to say that BERS can include means for effecting payment to a judge.

For example, let us say that IBM is the victim of identity theft and that is has a large number of alleged debts. A judge may find these invalid and enter"invalid"into the debt records for all these debts. BERS then would mark the debts as invalid. The would still be maintained in order, potentially, to prosecute the actual, fraudulent sender of the stamps in question. But BERS would erase the debts from IBM's payment file and erase the corresponding credits from the payment files of the Reece's who received the fraudulent stamps.

Conversely, of course, if a judge finds that a debt is valid, BERS enables him to enter"valid"into the debt record. This comment gives Reece ammunition to collect on the debt.

7. Showing the Interest of Collection Agents As will be explained in Section 6, BERS can enable collection agents to buy or bid on a debt.

Thus, BERS can write in a debt record that a collection agent has paid an amount of money for the right to collect the debt. In addition to this simple fact, BERS can register the amount of money that has been paid. This second fact is important because it indicates the validity of the debt.

Presumably, the collection agent will pay an amount based upon whether he thinks that the debt is valid and whether he thinks that he will be able to collect. The amount of money paid, relative to the debt, can be a strong indicator of whether the debt is indeed valid.

However, a collector will usually buy a package of Seneca's debt, an agglomeration of his debts, and therefore, the collector's investment does not necessarily indicate much about an individual debt. Still, the fact that a collection agent has paid for a package of Seneca's debts is reflected in each debt record that is part of the package. The investment in a debt package can still be a strong evidence that Seneca is a welsher.

Of course, everything depends on the circumstances, and so, when a collector pays for the right to collect a debt, BERS can also enable his to enter a text explanation as to why he thinks that the debt is valid. BERS can enable him to enter the same reason once for a package of debts.

8. Making a Bet About a Debt Bets can be excellent credibility devices. Thus, BERS can enable Seneca and Reece to make a bet about whether a debt is valid. The bet does not have to be between them. We assume that the bet is decided by a neutral judge.

Seneca can pledge a given amount of money that he will forfeit if the judge finds that the debt is valid.

Likewise, Reece can pledge a given amount of money that she will forfeit if a judge finds that the debt is invalid.

It is also possible for the bet to be between Seneca and Reece where the loser of the bet pays the winner an amount of money.

The possibilities for these bets are various.

One key question is who will accept the bet. The simplest option is for Reece to accept Seneca's bet and vice versa, where each party puts up an amount of money at risk. Another possibility is for an independent investigator (such as a debt collector) to accept the bet.

BERS writes in the debt record that a bet was made and writes the result of the bet. Further, BERS transfers payment from the winner to the loser.

Section 6 Features for Enforcing Payment Introduction In order for latent 1-stamps to be practical payment vehicles, recipients must believe that senders will pay off winning stamps. Recipients won't expect all senders who lose bets to honor their debts but the welsh rate cannot be too high. Therefore, it can be useful for BERS to include features for enforcing payment. Such features need not be perfect, they only need to lead to a welsh rate that users are satisfied with.

Three general approaches can be taken to stop people from welshing: 1) the authentication approach-using identification techniques in the sending of a stamp such that the sender cannot deny he sent the stamp.

2) the pre-payment approach-making a sender deposit money to cover any losses from stamp bets.

3) the credit bureau approach-keeping a record of a sender's payments and non-payments and then using that record to penalize the sender if he has welshed on too many bets.

BERS can include features that embody all three approaches. Before discussing how such features can be included in BERS, let us discuss the goals of the system so we can see what approach or combination of approaches is most suitable to achieve those goals.

Goals: No Upfront Costs and the Enablement of Minimal L-stamps BERS will have more than one object, but if we have to pick one, let us say that it is to enable people to affix reliable 1-stamps with no upfront costs. This goal implies another: to enable people to use their existing e-mail software to affix minimal 1-stamps that are reliable payment vehicles.

By minimal l-stamp we mean that Seneca has added only an EV amount and a credential that denotes an I-stamp bet contract (stipulating that BERS will decide the I-stamp bet under BERS's meta rules). The payoff amount may be standard, or it can be added as well. Seneca's return address and Reece's address-automatically part of an e-mail-make up the rest of the information that is needed for a minimal 1-stamp.

To enable such stamps to be trusted, a credit bureau approach is needed because it involves no special authentication software or other authentication mechanisms. Thus, the idea is to let Seneca easily add 1-stamps to his e-mail and then track his performance in honoring those stamp contracts.

If he welshes, he will be penalized, but he is presumed honorable until he proves otherwise.

Accordingly, we assume that Seneca does not have to deposit money in advance to pay for stamps. Pre-payment is possible, yet it defeats the goal of having no upfront costs for users. A critical advantage of the credit bureau approach is that it does not require pre-payment.

Focus Is On"Credit Bureau"Features Given the primary goal of the system, this section focuses on how BERS can include features that implement the"credit bureau approach". These features are described in Part 1 of this section, which is divided into Sub-parts A and B. Sub-part A is concerned with the registration and generation of payment history data. Sub-part B is concerned with how to use that data to enforce payment.

Authentication Features Discussed As Well Minimal 1-stamps can be enhanced by authentication measures. So, in Part 2 of this section, we discuss how BERS can include mechanisms for authenticating stamps. (The discussion is very brief.) BERS is a fundamental kind of machine for enabling 1-stamps and, therefore, it can be used to enable more than just minimal 1-stamps. It can be adapted to a range of payment tasks, such as the transacting of large payments that require high levels of authentication.

Part 1: Incorporating Welsh Bureau Functionality Into BERS A Welsh Bureau Rather than say that BERS includes"credit bureau"functionality, we will say that it includes welsh bureau functionality. The term"welsh bureau"is chosen to connote the idea that this functionality includes novel features for enforcing latent 1-stamp (bet) contracts. For brevity below, we say BERS includes a welsh bureau, rather than includes WB functionality.

Philosophy of Enforcement: It's Not Worth It to Welsh The philosophy behind using a WB is that welshing on 1-stamp bets is not worthwhile if a public record is kept of a person's debts and pay offs. Presuming Seneca has legitimate business purposes in sending 1-stamps, the cost of being known as a welsher will, in most cases, outweigh the benefit of not paying off losses in 1-stamp bets.

Of course, a certain percentage of people will not pay their debts. Furthermore, if minimal 1- stamps are used, a certain percentage of people will forge them, leading to debts being assigned to innocent parties. Nevertheless, while welshers can reduce the expected value of stamps, the probability that Reece will get paid for a winning stamp should be high enough to satisfy her.

Sub-Part A Storing, Registering and Generating Payment Data As discussed, BERS stores winning stamps and the e-mails they are affixed to, and it can register other pieces of payment data, and it can also generate payment statistics. In Section 5 we discussed the kinds of raw data that BERS can register. In this sub-part, we elaborate a little on why it is useful to register this data. Mainly though, we are concerned with the kinds of statistics that BERS can generate with this data. Then, in Sub-Part B, we describe procedures BERS can include for using these statistics to enforce payment.

A1. BERS Stores Evidence of Debts As part of its core process, BERS saves winning 1-stamps and the e-mails they are affixed to.

These saved stamps and e-mails are used as evidence of a debt. Evidence, the foundation of a welsh bureau, is the reason for keeping the content of an e-mail. The content can indicate whether the purported sender really sent the e-mail.

If an 1-stamp includes supplementary authentication data, such as a digital signature, BERS captures that as well. This kind of data, obviously, is powerful evidence that a sender is responsible for a debt.

A2. BERS Registers Payments and Non-Payments In order to detect that Seneca has reneged on a debt, BERS must be able to detect that he has not paid the debt. Thus, like a conventional credit bureau, BERS can include means for receiving and storing reports of non-payment, and can thereby compile a record of unpaid debts for Seneca. Yet, as noted, we will assume that BERS acts as a central payment transfer agent that handles the collection of money from 1-stamp losers and the disbursing of money to 1-stamp winners. In this role, BERS inherently detects both payment of a debt and non-payment.

Registering payment as well as non-payment is useful where a system for minimal 1-stamps is concerned because it can reveal Seneca's"welsh rate". Moreover, if he is the victim of identity theft-where someone has forged stamps using his return address-he can show that he does not always deny a debt (he will have paid off legitimate debts).

So, we assume BERS includes the payment transfer agent functionality described in Section 4.

Accordingly, for each 1-stamp bet that Seneca loses, BERS registers whether the debt is paid or not, and how many days it is past due, if it is not paid.

(Note: If BERS enables Seneca to set a limit on the EV amount of his 1-stamps, then a kind of non-payment is to affix a stamp with an EV over that limit. As discussed in Section 5, BERS can detect and register that Seneca has affixed an 1-stamp with an EV that is over the limit he set.) A3. BERS Generates Payment History Statistics In order to enforce payment, BERS can generate"payment history statistics"from the raw data it registers regarding Seneca's 1-stamp. These statistics can be used to show whether or not Seneca is a"welsher". Let us define some terms before discussing how such statistics can be used.

Payment History Statistic. For our purposes, this will refer to a number that results from applying an algorithm to a set of payment data in a user's payment file. The number is meant to describe some aspect of the user's payment history. A payment history statistic is produced by applying what we will call a pay-stat formula to a set of payment data.

Welsh Statistic (Welsh Stat). This is a kind of payment history statistic. We give it a special name to connote the idea that a welsh statistic is supposed to describe some aspect of a user's record of non-payment. But the idea is broader: welsh stat also encompasses statistics indicates whether a set of debts is fraudulent or genuine. Thus, welsh stats are a broad category. A welsh statistic is produced by applying what we will call a welsh-stat algorithm to a set of payment data about a user.

Welsh Measure. This is a kind of welsh statistic. The idea here, and hence the name, is that the statistic is supposed to measure (define) whether a user is a"welsher". The term welsh rating also gets across the idea of a welsh measure. As with the statistics above, there is no precise definition of a welsh measure. A welsh measure can be a set of statistics. A welsh measure is produced by applying what we will call a welsh measure algorithm to set of payment data.

Welsh Threshold. This is a value that is applied to a welsh measure for deciding, according to the measure, whether a user is a welsher.

Definition of a Welsher. By this we will mean an algorithm that defines a user as a welsher or not according the a measure or measures are arrived at by operating on a set of payment data in the user's payment file.

Illustrations of Payment History Statistics BERS will pay-stat algorithms and welsh stat algorithms and welsh measure algorithms for generating the statistics described above, as needed (see Sub-Part B). Below we illustrate some kinds of payment history stats that BERS can generate. a. The total uncollected debt.

This statistic is important for indicating whether or not it is worthwhile to try to collect on Seneca's debt using legal means outside BERS. b. The percentage of debts that have been paid off.

This statistic indicates Seneca's"welsh rate"but it can be misleading because he may rightfully dispute debts he is accused of welshing on. A similar welsh rate statistic BERS can calculate is: (total amount of non-payments)/ (total amount of payments + total amount of non-payments). c. The number of different debts, identified by e-mail content, that Seneca has welshed on.

If Seneca has welshed on a significant number of different people then he is either a deadbeat or the victim of identity theft. Thus, the statistic above can indicate, whether or not it is worthwhile to investigate Seneca. d. The number of different e-mails involved in Seneca's welshes.

One inherent property of minimal 1-stamps is that they are easy to forge. A mass cheater might forge Seneca's return address when sending an e-mail to a large number of people. One way to detect this cheat is to compare the content of the stored e-mails. If the stored e-mails have the same content then the mailing was a mass mailing. Seneca, then, is either the victim of identity theft by a mass mailer or is himself a mass mailer. e. The number of different parties who have been paid off.

This statistic, especially taken in conjunction with others, can indicate whether Seneca is trustworthy in paying his debts. If he has paid off to a large number of different parties then he may be"good for his debts", even though he might have reneged on certain debts. f. The rate at which Seneca exceeds his 1-stamp EV limit.

As noted above, each time Seneca exceeds his EV limit, it is a welsh. Thus, BERS can generate statistics about the number of times he has welshed and his rate of doing this welsh-i. e., (number of stamps whose EV is over the limit)/ (number of stamps whose EV is within the limit).

(We should note that BERS can develop similar statistics for a group account. An organization may generate large volumes of e-mail. Accordingly, group payment statistics can then indicate the probability of a welsh from a member of the group.) Using Comment Data In Creating Welsh Statistics Useful payment history statistics will take into account the comments of debtors and creditors. For example, a welsh stat can be created by applying the condition that a debt total is calculated by adding up all of Seneca's debts that he does not dispute. This total may be very different from a total of all his purported debts. Likewise, a debt total can be created by tallying all of Seneca's debts that Reece's have asserted are valid.

In other words, BERS can generate the same kinds of statistics as described above, but screened according to debts that have been denied and not denied, and debts whose validity has been asserted or not asserted. For example, although Seneca may not have paid a number of purported debts, he may have denied them all and no Reece may have challenged any of the denials. In this case, these debts may be considered null by viewers of Seneca's payment history.

As another example, Seneca's record for paying undenied debts may be spotless. This kind of statistic can indicate that he is not a welsher.

In the same fashion, BERS can create welsh stats by screening according to whether bets have been made, whether third party collectors have bought the debts. The possibilities are endless, and cannot be covered here. The general idea has been given: welsh-stats will be more revealing if they take into account comments (defined in Section 5).

Sub-Part B Using Payment Statistics to Enforce Payment The main reason for generating the payment statistics described above is to use them to enforce payment. BERS can make use of them in five general ways: 1) It can open its payment database to the public.

2) It can enable debts to be assigned to collection agents.

3) It can inform recipients about a sender's payment history.

4) It can enable mailservers to use welsh statistics to screen e-mail.

5) It can directly penalize a welsher.

We describe these uses in turn below.

B1. Enabling the Public to Search the Payment Database One way to discourage Seneca from welshing it to make his payment history public. Thus, BERS's payment database can be opened up to the public so that Reece can look up Seneca's payment history data.

Moreover, BERS will include well known functions that enable users to search the database using a variety of criteria and algorithms to create an endless variety of payment statistics. Users can then create simple or sophisticated screens for analyzing a sender's payment history. Such search functions are useful especially for debt collectors who can use them to find debts worth investigating.

Debt collectors may be important to the success of BERS and we can think of them as a distinct class of user.

B2. Enabling Debts to Be Legally Assigned In order to facilitate the collection of debts by third parties, BERS can include means for legally assigning debts.

There are various ways that a collection agent can be chosen. One way is to sell a debt entirely.

Another is to sell the right to collect a debt (the money collected can then be split between the collection agent and the creditors). Alternatively, the meta rules of BERS can dictate some non- market method of assigning debts to be collected.

The point here is that BERS can include mechanisms for assigning a debt, and further for agglomerating debts. The simplest way to agglomerate debts is to group them according to sender.

So, if Seneca owes debts to multiple Reece's, BERS can present them as a group, and can assign all of them as a group to a collection agent. That gives the collector a greater a incentive to pursue Seneca. If BERS assigns all of Seneca's debts to a collector, then BERS will write in each separate debt record that the debt is assigned to that collector.

So, as discussed above, collectors can search BERS's payment database to find senders whose debt totals merit investigation. BERS can also enable collectors to enter an offer to buy the right to collect the debt, or an offer to buy the debt, depending on the meta rules for collection of 1-stamp debts. BERS registers this information in Seneca's payment file, for other collectors to see. Or, BERS simply assigns the debt according to a default.

Once BERS assigns a debt to a given collector, BERS blocks the debt from being assigned to another collector.

BERS can also enable an auction to be conducted for the debt. To enable an auction, BERS writes, in Seneca's payment file, that a collection agent has entered the intent to buy, and can write the offer for the debt. BERS can then enable other collectors to enter bids and can conduct an auction by any of a number of well known procedures.

B3. Alerts Recipient About Welshers BERS can alert Reece when she redeems a stamp from a welsher. In order to do operationalize this idea, of course, BERS must apply an algorithmic definition of a welsher to a sender's payment file data.

BERS can include its own default algorithm for defining a welsher.

Additionally, BERS can include a variety of welsh measure algorithms and welsh thresholds that apply to those measures. BERS can, in this case, enable Reece to select from a standard set of welsh measures to create her own custom definition of a welsher. She would select a welsh measure and threshold and then BERS would store these in her preferences file.

Alternatively, BERS can enable her to use the BERS default formula. Likewise, BERS can enable her to use the BERS default algorithm but apply her own threshold, which can BERS can express to her in colloquial terms, such as"strict enforcement of welsher","loose enforcement", and so on.

Of course, the BERS welsh measure algorithm and corresponding thresholds will operationalize this kind of colloquial definition.

Assuming that BERS has an default definition of a welsher, BERS can pre-flag the payment files of senders who it calculates are welshers.

Thus, when Reece forwards a stamped e-mail to BERS, BERS can capture the original sender's address and check that sender's payment file to see if the sender has been flagged as a welsher. If so, BERS still executes a bet for the stamp as usual, but would also send a welsh alert to Reece, regardless of the result of the stamp.

So, under this procedure, BERS checks every 1-mail to see if the sender is a welsher. After checking the welsh status of the sender, BERS still performs the core procedure for executing the 1-stamp bet.

The reason for checking every stamp to see if it was sent by a welsher is that Reece may prefer to know every time she has been sent a stamp by a welsher. Further, checking every stamp provides a greater deterrence to welshers because they know they will be caught each time, rather than just for winning stamps. (It is possible, of course, for BERS to perform a"welsh check"only on winning stamps, i. e., after executing the 1-stamp bet.) In the procedure above, we assume that BERS uses its own definition of a welsher. But, if BERS enables Reece to select or create her own definition, then BERS will, upon receiving an stamp, check Reece's preferences file to see how she has defined welsher. BERS will then check the Seneca's payment file and apply Reece's definition. If Seneca is a welsher under Reece's definition, BERS sends her a welsh alert.

Aside: Other Alerts BERS Can Send While we do not delve into a debit system for paying off latent 1-stamps, we can see that BERS can send an insufficient funds alert, if it finds that a sender has committed to pay off an 1-stamp bet, even though he does not have sufficient funds in his account to cover the bet. Seneca's commitment would be indicted by a special 1-stamp that has a credential indicating this commitment. BERS can include means for detecting such a stamp.

BERS can also alert Reece if Seneca does not have a license to send latent 1-stamp. BERS can check this fact by checking Seneca's account, if any exists. An account may exist, but Seneca may not be an authorized, registered user. As discussed in Section 3, accounts are set up even if a sender is not licensed. We also note that, in a debt record, BERS can write whether Seneca is an authorized, licensed user of BERS.

B4. Enabling Mailservers to Use Welsh Statistics to Screen E-mail It is also possible for BERS to enable Reece's mailserver to screen her 1-mail according to welsh statistics. The idea, of course, is that Reece will be able to set a screen that will stop welshers from sending her e-mail. This screen is best implemented through the machine that serves e-mail to her client. (It is possible for welsh screening to be done at the client level, but it seems simpler to do it at the mailserver level.) We assume, then, that the mailserver enables Reece to set a welsh screen on her e-mail account. A welsher screen requires an operational definition of welsher (discussed above). Therefore, a mailserver will enable Reece to select or create a definition. This definition will have to be checkable by BERS as well. For simplicity let us assume that there is one statistic that is used, such as a delinquency rate on 1-stamp debts where those debts are asserted to be valid by recipients. In this case, Reece would be able to set a level of delinquency rate the she finds unacceptable. For example, she might set a rate of 50%, such that she will accept no e-mail from a sender who has not paid 50% of his debts where those debts are asserted to be valid by the receivers. The mailserver stores this measure in her account.

The goal, of course, is to prevent welshers from being able to send Reece e-mail. This kind of screen can be a powerful enforcement tool. If Seneca wants to get his mail through, he will have to pay his debts (or will have to convince a judge that the debts are invalid).

Now we come to the role of BERS: to tell the mailserver whether Seneca is a welsher. The mailserver, upon receiving a latent 1-stamped e-mail from Seneca to Reece, stores the e-mail to correspond to Reece's account. It then finds Reece's welsh screen definition. (We note that the definition may be to default to BERS's definition of a welsher.) It then sends a request to BERS asking BERS to apply Reece's definition to the data in Seneca's payment file. When we say"apply the definition"we mean that the algorithm that actually is the definition is applied to the data set, yielding a"welsher"or"no welsher"result.

(The mailserver and BERS can communicate by any of a number of communications protocols, such as TCP/IP.) BERS finds Seneca's payment file, applies the definition, gets the result, and, if the result is "welsher", sends the result to the mailserver. (BERS only needs to respond back when it finds that Seneca is a welsher.) If the result is"welsher"the mailserver deletes the e-mail. For example, if Seneca's delinquency rate is 55% %, and Reece's definition specifies a 50% maximum, then BERS will send a"welsher"response, and Seneca's e-mail will be deleted. (The mailserver then may, or may not, alert Seneca that his e-mail has been deleted and why.) (It is also possible for the mailserver to ask BERS to return a measure to which the mailserver uses to determine whether Seneca is a welsher. But it is more efficient for BERS to return a welsher result.) B5. Assessing Fines, Canceling Privileges If we assume that senders use latent 1-stamps under a license with BERS, then BERS can cancel the license of any user who has a welsh rate, as defined by the system's meta-rules, above a threshold. Alternatively, BERS can assess a fine. To do these things, BERS will have means for checking whether the sender has a valid license, and for sending notices of fines and other penalties. BERS can include also means for receiving payment and registering whether the fine has been paid.

We can think of this use of payment data as the"public library"approach to enforcement.

Everyone is initially allowed to use the system and is trusted to observe the rules. Records are kept of the users'behavior. Users who break the rules are assessed fines and possibly suspended from the system.

Endnote About Welsh Bureau Adaptability We note that the BERS welsh bureau can be used for enforcing 1-stamp debts that are for other types of 1-stamps besides latent 1-stamps. Where other stamps are concerned (i. e., those explained in Chapter 5), the results are revealed by the stamps themselves. Yet a winning stamp is a winning stamp. It represents a debt from the sender to receiver. Thus, with minor modification, the BERS welsh bureau can process debts represented by these stamps. Virtually all the functions described can apply to enforcing these debts.

To do process other types of latent 1-stamps, BERS must include means for receiving unpaid 1- stamp debts for other kinds of stamps. BERS can have a dedicated e-mail address for accepting these kinds of stamp. The 1-mails that these winning stamps were affixed to can simply be forwarded to this address. BERS treats the stamps on these 1-mails just as it would winning latent 1-stamps. It can be understood that the debts represented by these stamps are unpaid.

BERS can also include means for parsing a stamp to detect the type of stamp. If it is not a latent 1- stamp, and if it is a wining stamp, BERS simply stores it as a purported debt, as discussed at length in this chapter.

Part 2: Incorporating Authentication Procedures Authenticating the Sender Thus far we have spent little space discussing how BERS can utilize conventional authentication mechanisms, such as digital signatures. We have focused on how senders could be"authenticated" using various pieces of circumstantial evidence. We also assumed that in most cases welshing would be more trouble than it was worth.

It is clear that conventional, cryptographic authentication methods can be useful as well. We do not have anything novel to add where these mechanisms are concerned. As noted above, BERS can store a digital signature or other cryptographic evidence of who the sender of a stamp is. We do not specify the kind of signatures that can be added to an 1-stamp. We only repeat that the use of signed stamps can, obviously, make enforcement of 1-stamps contract an easier matter.

Additionally, should BERS register that Seneca denies a debt, BERS can automatically check the signature on the corresponding 1-stamp by sending a"check message"to third party server that verifies signatures. Alternatively, BERS can include a verification database as part of its memory, and can thereby perform the checking internally.

BERS can also issue the keys to be used to create signatures.

BERS can also issue 1-stamp signature algorithms whereby a sender is issued a unique algorithm to be incorporated into the sender's mail client. The algorithm converts the time/date a stamp is sent, the sender's address, and possibly the receiver's address into a number that is added to the stamp. This number can act as the stamp's signature. BERS can then check this signature by calling up the appropriate signature algorithm that has been issued to Seneca, and feeding in the appropriate numbers.

In case of dispute, if BERS finds that a signature genuinely corresponds to the sender, then it registers that fact in the debt record. Likewise, if BERS finds that the signature is bogus, BERS registers that fact. These facts, of course, can be useful in enforcing payment.

Authenticating the Receiver Thus far we have assumed that the receiver is authenticated by the simple fact that she presumably controls her mailbox. In other words, the person who responds to the notification of a winning 1- stamp (by giving a legal name and other ID data for payment) is assumed to be the true mailbox holder. This assumption is reasonable where small amounts of money are concerned. Yet where large sums are involved, it can be useful, even necessary, to apply additional authentication techniques.

For example, Seneca can send Reece a codeword through a secure channel or by encrypted e-mail.

To collect payment, Reece must present the codeword. BERS can, therefore, enable Seneca to send the codeword to BERS and associate it with Reece so that BERS can authenticate Reece.

Reece can also be required to provide legal ID data such as a social security number, a driver's license or fingerprint. BERS include means for registering such ID data when it registers that a payment has been made to Reece. To add to the authentication process, Seneca can write out the name of the legal recipient of the 1-stamp, as he would in a paper check. BERS (and/or its system operators) can then check this name against legal ID data that Reece supplies.

(Where payments are registered with the aid of humans, the system operators who interact with the machine to effect the payments can be thought of as another class of user.) Section 7 Features for Processing Credit Stamps Context and Definitions In a world where e-stamps are used there will also exist software filters that screen e-mail according to the amount of money that is affixed to it.

One such filter is a general admission price (GAP) screen that blocks all e-mail that does not have postage equal to or greater than the user's general admission price.

In a world where GAP screens are used, there will also exist mechanisms for granting custom admission prices to designated senders. Custom admission prices can be granted by Reece.

Depending on how the pricing system works, she can grant free passes, credits and discounts.

These grants are contracts that specify terms of use.

A credit is a grant that allows the user to add a credit stamp in a specified amount that will enable Seneca's e-mail to get through Reece's GAP screen. The credit stamp may by itself be equal to or greater than the GAP amount. Otherwise, the value of the credit stamp will have to be added to a normal stamp in order for the e-mail to have enough postage to get through the screen. So, a credit stamp is a kind of pseudo-postage whose use is governed by a credit grant.

A credit can be granted to a specified sender. It can be granted for a particular period of time. It can be granted for a particular number of uses. It can also be granted to any sender who sends e-mail that is about a specified subject.

A free pass is a grant that allows Seneca to send an e-mail through Reece's GAP screen without paying. We can think of a free pass as a stamp that is equivalent to a credit stamp that has a value equal to Reece's GAP.

A discount is a grant that allows Seneca to get an e-mail through Reece's GAP screen with postage that is less than the GAP. We will focus on credits and discuss discounts at the end of this section.

In a world of credit grants there will also exist a directory where users can post their GAP's and their credit grants. We will call this directory a mailbox admission price server (MAPS). MAPS can be used by senders who want to find out Reece's GAP. Moreover, it is a neutral registry of credit grants. For example, Reece may give a credit grant to USAir such that USAir can send Reece an e-mail with credit stamp worth 50 cents for the purpose of getting through her GAP screen. She can register this credit with MAPS. Certain senders might falsely claim to have the right to send an e-mail to Reece with a credit stamp attached to it. MAPS can show whether that is true or not.

In this section, we describe features that BERS can include for processing credit stamps and for utilizing MAPS.

Form of a Credit Stamp We will assume that, like an 1-stamp, a credit stamp is denoted by a credential and value. The value signifies an amount of credit. We will further assume that, like an 1-stamp, the credit stamp is included in the subject header of an e-mail. We will abbreviate a credit stamp as a c-stamp.

Key Assumption: Credit Stamps Equal Cash If They Are Misused When legitimately used, the purpose of a c-stamp is to enable Seneca to get an e-mail through Reece's GAP screen. The value of the c-stamp is added to the value of an 1-stamp, if any, to get through the screen.

But Seneca may misuse a c-stamp. For example, he may have received no grant from Reece. Or, his grant might have expired. Or, his grant might have allowed him to use a c-stamp to be affixed only to e-mails about a specified subject, and he may have affixed it to an e-mail about a different subject. There are several basic ways that Seneca can misuse a c-stamp.

We will assume that if a c-stamp is misused that Reece can convert the value of the stamp to actual money, meaning that Seneca owes her the amount of the stamp in money if Seneca misuses the stamp. Thus, a c-stamp, if misused, is an obligation to pay Reece the amount that the stamp displays. For example, if a c-stamp is worth $1 in credit, and it is misused, then it obligates Seneca to pay Reece $1.

We will further assume that these obligations are transacted by the EVPM and so we can think of c-stamps as credit l-stamps.

Of course, there can be disputes about whether a c-stamp has been misused or not. BERS can include features for dealing with such disputes. Before discussing these features, we will discuss how BERS can simply store c-stamps just as it stores l-stamps.

1. Features for Storing Credit Stamps When BERS receives an e-mail that contains an 1-stamp along with a c-stamp, BERS executes a bet based upon the value of the 1-stamp. In other words, BERS assumes that the c-stamp has no monetary value.

If BERS declares the 1-stamp a winner, then BERS stores it, as described in the core process.

However, BERS can also include means for storing the c-stamp data in designated fields in a debt record. If BERS includes such fields, it will also include means for parsing the 1-mail to detect the c-stamp, and the c-stamp amount. BERS will then store the c-stamp amount in the debt record.

The reason for storing the c-stamp in designated fields is that BERS can also enable Reece to claim that the c-stamp represents a payment obligation (see below). Therefore, it is useful, for the purpose of applying the accounting and enforcement procedures described in Sections 5 & 6, to write c-stamp data in specially designated fields, rather than leave the data in the plain text subject header of its corresponding, stored e-mail. In other words, just as BERS includes means for applying accounting and enforcement procedures to 1-stamp debts, it can apply analogous procedures to c-stamp debts.

2. Features for Registering Complaints About Credit Stamps Now, if Reece thinks that Seneca has misused a c-stamp, she will want to claim that he owes her money in the amount of the credit displayed on the stamp. There can be many ways of deciding the issue, but she must first state her claim.

Hence, BERS can enable Reece to enter her claim. A simple way to do this is for BERS to have a separate e-mail address, such as complaints@bers, where Reece can send e-mail that Reece contains a c-stamp that, according to Reece, is misused. Or, Reece can write a complaint message in the forwarded e-mail that BERS can then parse to detect the complaint.

When BERS receives an e-mail and registers a complaint, it can execute a bet based upon the value of the l-stamp. If the stamp is a loser, BERS deletes the e-mail, as per the core process. If the stamp is a winner, BERS stores the e-mail and l-stamp data, and also writes in the debt record that Reece claims that the credit signifies a debt.

Now, let us digress a moment to spell out the possibilities for executing an EVPM bet when Reece thinks that a c-stamp has been misused.

If, as stated above, the bet is based upon the I-stamp EV, the stored c-stamp represents a debt that equals the c-stamp's original credit amount multiplied by the reciprocal of the probability in that l- stamp bet, (I-stamp EV)/(Payoff). Why? Because the 1-stamped e-mail (including the supplemental c-stamp) is only saved with that probability. So, the value of the winning I-stamp (and the supplemental c-stamp) is multiplied by the reciprocal of the probability of winning. For example, if the probability of winning is 1/10 then a winning stamps are worth lOx of their original, pre-bet value. That is the basic idea of the EVPM.

If the forwarded 1-mail contains both an 1-stamp and a c-stamp, BERS notifies Seneca and Reece of the result of the winning 1-stamp, and also includes in the notification a bill for the c-stamp. In other words, BERS sends a bill that includes an 1-stamp a c-stamp charge.

Yet, this approach poses a problem because the forwarded e-mail may contain no 1-stamp. It may contain only a c-stamp. That's because Seneca often will only use a c-stamp to get through Reece's GAP screen. So, in this case, we assume that BERS executes a bet where the EV is the value of the c-stamp credit as discussed just below.

It is also possible to do two separate bets, one for the I-stamp and one for the c-stamp, each bet having odds based upon the displayed value of each stamp. This approach has advantages because it can make it easier for users to treat the 1-stamp and the c-stamp as separate matters.

If this approach is used, the c-stamp process is directly analogous to the 1-stamp process. The EV of the c-stamp bet is equal to the amount of the c-stamp credit. If the c-stamp is a winner, then BERS creates a debt record, as it does in the case of a winning 1-stamp, but in this case no 1-stamp data is contained in the record, just c-stamp data (which is essentially the same as 1-stamp data but held in differently named fields). BERS stores the corresponding e-mail if the c-stamp is a winner.

And, BERS notifies Seneca and Reece of the result, just as it does in the case of an I-stamp.

It is also possible for BERS to combine the values of the two stamps and to do one bet where the odds are based on the combined values-that is, the EV of the 1-stamp and the credit value of the c-stamp. In this case, the original, pre-bet value of each is multiplied by the reciprocal of the (combined EV)/ (combined payoff). We do not elaborate on this possibility, as it involves minor modifications in the processes in this section.

BERS will also include means, directly analogous to those already described in Sections 5 and 6, for enabling Seneca to deny a c-stamp debt and for enabling Reece to re-assert its validity (she asserts its validity by sending her e-mail to the complaints@ bers address, but in case she has made a mistake, BERS can give her the option of re-asserting the validity of the debt). Likewise, as discussed in Sections 5 and 6, BERS can enable Reece to forgive a debt. And it can enable Seneca and Reece to make a bet about the debt. And it can enable a judge to enter a comment, and a debt collector to buy the debt. In other words, a c-stamp debt can be treated just like an 1-stamp debt, with virtually all the same mechanisms.

Yet in the case of a c-stamp debt, BERS can include one extra feature not relevant to 1-stamp debts.

BERS can verify in certain cases whether the c-stamp is valid or not. We elaborate below.

3. Features for Verifying Complaints About Credit Stamps As explained, if c-stamps are used there will be a MAPS directory for posting the grants that define a sender's right to use the c-stamp. Certain conditions of a c-stamp grant are mechanically checkable such as whether it has been granted to a sender at all, such as the amount of the grant, and such as the expiration period of the grant.

Thus, upon receiving a forwarded e-mail at its complaint address, BERS can automatically send a request to MAPS to verify the credit. BERS will first parse the header to capture the c-stamp data, including the sender, receiver, date of sending, and amount of the credit. BERS can also parse and include the subject header. MAPS will then check this data against the underlying grant, if any, and send back a response stating whether the c-stamp is valid or not.

Seneca may have been granted a credit in a certain amount but he may have exceeded that amount in the c-stamp he affixed. Thus, MAPS can also report the amount, if any, of the excess. BERS will capture the"valid"or'invalid"designation, and the amount of the excess, and then store these epics of information in designated fields in the debt record.

BERS and MAPS can communicate by an protocol (e. g., TCP/IP) chosen by the system operators. We note one other important possibility: MAPS can be incorporated into BERS, meaning BERS can verify credits internally.

MAPS can also report the reason why the grant is invalid: namely, it never existed, it was expired, the c-stamp was for a greater value than allowed by its grant. BERS captures the reason and writes it in the debt record.

We digress a moment to discuss grants based upon subject matter. As mentioned, one kind of grant is for sending e-mails about a specified subject. We assume that the grant is given a title that describes the subject. Further we assume that a stipulation of sending an e-mail with a c-stamp governed by this grant is that the subject header of the e-mail must contain the title of the grant.

That allows the credit to be checked mechanically in MAPS and allows Reece to recognize the grant.

For example, a credit grant to send e-mails about"Cheap Hotels in Rome"can stipulate that an e- mail with a credit stamp, backed up by this grant, must contain a subject header with the line "Cheap Hotels in Rome"and that the subject of the body content must genuinely be about cheap hotels in Rome. This first condition is mechanically checkable. The second is not, given current technology. Thus, MAPS can check for the first condition and report whether it has been violated or not.

But, Reece may be complaining because she feels that the spirit of the subject grant has been violated, namely that the subject line implies that the e-mail is about one subject but in fact it is about another. This is a basic cheat where c-stamps are concerned-Seneca will lie in the header about what his e-mail is about. To enable this cheat to be registered easily, BERS can include another e-mail address where Reece can send an e-mail if she feels that the subject condition of her grant has been violated in a way that cannot be checked mechanically. Equivalently. BERS can enable her to write her complaint in the forwarded e-mail. Either way, BERS can detect this specific complaint and then register it in it the debt record.

(We will assume, as well, that MAPS contains a complaint database as well, where Reece can send complaints. To save Reece time, MAPS can store the complaints forwarded to it by BERS.) Note About Discounts Now, people may use discount grants rather than credit grants. Where BERS is concerned, discounts are a littel more complicated. BERS can still register a discount, but BERS must somehow be told that a discount has been given. With a credit the fact is implicit in the presence of a c-stamp.

(If a discount stamp is affixed that is the same as a credit stamp, really.) If a discount is given without a stamp then BERS cannot detect the discount unless Reece informs BERS. BERS can enable Reece to do so, by having a mailing address where Reece can send an e- mail if she feels that her discount grant has been violated. In this case, Reece must state the amount of the discount. Or, BERS can automatically check with MAPS to see what discount Seneca was given, if any.

Assuming Reece or MAPS tells BERS what the discount was, BERS can register this amount, and then, like a credit amount, the discount amount can be claimed as an obligation by Reece. The same accounting and enforcement procedures, described above, can be applied to this obligation, as are applied to 1-stamp and c-stamp obligations.

Section 8 Miscellaneous Features Functions for Charging Users BERS can also include means for charging senders and receivers for its services. Various charging schemes can be implemented within BERS. To give but one example, BERS can include means for taking a percentage of any payment that it transfers from a sender to a receiver.

Reducing the Cost of Sending a Latent L-stamp When Seneca sends a latent 1-stamp, he adds an 1-stamp credential to the header of an e-mail and adds an EV amount-for example,"L$. 50". However, he might not want to bother adding an EV figure each time he sends an e-mail. To save him and other senders time that is spent adding an EV, the credential (L$) could denote a standard amount of money in the absence of an EV figure.

To make this default operational, BERS must register a default amount if BERS does not detect an EV figure along with the credential.

Deleting Most of a Winning L-mail BERS stores the content of a winning 1-mail as evidence of the 1-stamp debt in case Seneca refuses to pay, claiming that he did not send the 1-mail. Since the point is to keep evidence, BERS does not have to store all of an 1-mail. It can delete most and keep a fraction. For example, BERS may keep only the essential header information and a few lines of body content.

The reason to delete information, of course, is to save storage costs, which may be significant if BERS serves a large community of senders and receivers. The selection of content to store depends upon what the system operator thinks is necessary for the purposes of evidence. (The parts that are stored can be randomly chosen to thwart cheaters who, knowing what parts are kept, might put non-traceable junk in those parts.) Thus, BERS can execute the following procedure for storing an 1-mail: --Inputs thresholds specifying the amount of information to be stored from a text attachment, a GIF attachment, an AVI attachment, and from the body content of an 1-mail, --When storing an 1-mail, stores pre-specified header fields, deletes the rest of the header, and checks the body content, Stores the threshold amount of the body, and deletes the rest.

If the 1-mail has an attachment, checks the type, stores the threshold amount for that type, and deletes the rest.

Reducing Fraud: One Protection Against Fake Return Addresses Certain senders of mass e-mail, also called spammers, might try to use fake return addresses in order to avoid being billed. A fake address may not do a spammer any good because an investigator may be able to track an e-mail back to its source. Yet, an investigator will be prompted to examine the matter only if a debt total reaches a threshold that makes it worthwhile to track the debtor down. So, spammers might try to evade the tallying of bills by using large numbers of fake sender addresses in order to keep debt thresholds under the amount that will trigger an investigation.

To stop this fraud, BERS can match the content (subject header, body and attachments, if any) of winning 1-mails that are in stored in accounts that have debt totals less than a threshold. If the number of matches exceeds a match threshold, BERS can create a new account for the matching content. For example, say a spammer was sending an ad, White hot sex talk at 800-555-5555, to 100,000 people. And say, for argument's sake, that all the ads were sent with fake addresses.

BERS could then match the content of the winning 1-mails-assume there are 1,000 of them-and group them under a fictitious account name.

Thus, BERS can perform a procedure whereby it: --takes a list of sender accounts that have Debt Totals below a threshold, --takes each 1-mail in an account and checks the content against the content of all the 1-mails in all the accounts in the account list, --if the number of matches for a given 1-mail exceeds a threshold, BERS sets up a new account for the matching content, and outputs a flag.

(As usual we do not have any comments to make about coding efficiency, except to say that various techniques can be employed for making the matching task above manageable. When we say that BERS matches an L-mail against all the other 1-mails in a set of accounts, we are referring to any efficient algorithm that can take a piece of content and search for matches in a large set of files.) Employing a Log of a User's Redemption Attempts In Section 2, we defined a redemption log that BERS can keep in order to stop Reece from trying multiple redemption attempts. This log, which can be a sub-file of a receiver's account, is for non- probabilistically registering redemption attempts.

(In its core process, BERS only registers data about winning stamps. In this sense the registration of redemption attempts is probabilistic. But, it is possible for BERS to keep a log that records every redemption attempt made by Reece, whether the stamps turn out to be winners or losers.) As discussed in Section 2, such a log will include fields for recording the envelope/header data previously described that defines an 1-stamp.

It may also be useful to identify the particular e-mail that the stamp is affixed to. Thus, the redemption log can also include a field for storing the subject line of the e-mail, or some other identifier. (Alternatively, the time of sending and the sender may suffice to identify the content of an e-mail.) A log that contains every one of Reece's redemption attempts can help advertisers judge whether it is worthwhile to send Reece e-mail ads. An advertiser will want to know what the chances are that Reece will redeem a stamp. If Reece has the choice of redeeming a stamp or not, she may choose not to redeem stamps from advertisers who she thinks have sent her useful information.

Conversely, she may want to redeem stamps from advertisers who have sent her useless information. Thus, she can penalize advertisers who send her junk and reward advertisers who send her information she wants.

A redemption log is necessary, but not sufficient-to enable advertisers to see Reece's redemption rate-the number of redemptions compared to the total number of stamped ads sent. Of course, in order to find this rate, advertisers will have to know how many ads were sent to Reece. This can be done if advertisers use a central mailing service.

Since the redemption log can be used for advertising feedback, it can also be useful to identify an e-mail as being a certain kind of ad. Thus, an advertiser can add a tag to an 1-stamped e-mail to identify it as being a certain kind of ad. BERS can capture this tag and also store it in the redemption log (which can include a field or fields for this kind of tag).

Procedures for Redeeming L-stamps With Verification Codes If Seneca sends an e-mail ad with an 1-stamp on it, he may want to have some assurance that the e- mail will at least be examined cursorily. Yet as described above, BERS simply allows Reece to forward the e-mail to BERS without showing that she has paid any attention to it. Moreover, Reece could potentially instruct her e-mail client to automatically forward all e-mail with a latent 1-stamp to BERS.

To address this problem, Seneca can include a codeword in the ad and stipulate that in order to collect the payoff on a winning stamp that Reece must include the code word in forwarded e-mail.

Seneca can include a symbol in the header of the e-mail that signifies this stipulation. Likewise, BERS can include a special address for receiving such e-mail. If an e-mail is specially designated in this way, BERS can store this designation along with other 1-stamp data.

Then, BERS can send all winning I-stamps, and their associated e-mail content, to Seneca who can handle the actual payment transfer.

For BERS to verify the codeword, it must check it against a set of data (a list of addresses and associated codewords) supplied by Seneca. We note this possibility but do not pursue it as we have discussed these matters above, in the description of other kinds of redemption servers.

Procedures for Converting an Unpaid Debt into a Larger Debt The premise of 1-stamps, of course, is to use the EVPM to make payment efficient. A similar application of the EVPM can be used where debt collection is concerned. One of the conditions of an 1-stamp contract may be that if the debt on a winning stamp is not paid within a certain time period, then the holder of the debt can execute an EVPM bet with a specified payoff. The debtor would be responsible for this payoff. This amount normally would be more efficient to collect.

We presume that an 1-stamp includes such a condition as a standard condition or that the condition is indicated by a credential that BERS can detect. Given this assumption, and assuming the BERS has recorded a debt and that BERS has detected that the debt has been unpaid past its deadline, BERS can execute an EVPM bet with the specified payoff.

If the creditor loses (that is, if the stamp is, in effect, a winner again) the creditor will owe the higher payoff. BERS will register the higher debt in the debt record and in the sender's (debtor's) and receiver's (creditor's payment files. If the creditor wins (if the stamp is a loser this time) then BERS erases the debt from the sender's payment file and the corresponding credit from the receiver's payment file. BERS can still keep the debt record for the purpose of compiling welsh statistics. Thus, instead of fully erasing the debt from the sender's payment file, BERS can simply mark the debt canceled, along with the reason the debt is canceled. The debt record can include the corresponding fields for recording these facts.

Procedures for Performing Billing for Content Selling Servers BERS is an adaptable machine for transacting micropayments. It can be modified to handle payments made by users to servers that are selling content. We assume that payment is made by the EVPM.

Normally, a server would present the user with a charge for a given piece of content, execute an EVPM bet, and then tell the user the result. Alternatively, the server could delegate to BERS the tasks of executing the EVPM bet and of billing the user.

Now, all this can be done in real time in the sense that the server can send the charge and other billing information to BERS. BERS can execute the bet and send the result to the server. The server can then present the result to the user. The advantage is that BERS can include, as discussed, a welsh bureau. Thus, in addition to executing the EVPM bet, BERS can verify whether the user is a welsher. If the user is a welsher, BERS can send that information to the server which can then deny the content to the user.

As discussed in Section 6, BERS can enable people to set operational welsh definitions that BERS can use. Likewise, BERS can enable a server operator to establish an accounts that give the server's definition of a welsher. BERS can apply that definition when the server sends it a charge to be transacted.

Now, when BERS does 1-stamp billing, the billing information is contained in the stamp, namely the sender's e-mail address. Hence, the server can capture this address before selling content to a user, and can include this address when it sends the charge to BERS.

Alternatively, the server can send BERS an IP number. This can identify the buyer rather than an e-mail address. Now, in order to transfer payment BERS will also need to have stored a legal billing name and address to correspond to the IP number of course.

The point is that BERS can perform many of the key functions described in this specification to bill micro-amounts. The charge that a buy incurs when going to a server is like the buyer sending the server an 1-stamp, in effect.

Looked at that way, it is clear that the features that comprise BERS can be modified easily to accommodate micro-charges that are recorded by servers and relayed to BERS for processing.

BERS will simply capture all the necessary information, as it does with 1-stamps. Of course, the buyer (sender) can be identified with an IP number and the server (receiver) can be identified by an IP number as well. The fields are directly analogous.

Appendix to Chapter 6 L-stamps for Voice and Fax Messages Latent 1-stamps can be applied to voice and fax messages. These can then be converted into e-mail messages which can be transmitted to BERS. However, these 1-stamps will be slightly different than those that we have been discussing above because senders of the stamps will be identified not by e-mail addresses but by phone numbers.

We will not delve much into the modifications that need to be made to BERS to enable it to process these 1-stamps. The modifications are slight and easily seen by those skilled in the art.

Instead, we briefly describe a machine for receiving 1-stamps on fax messages and then a machine for receiving 1-stamps on voice messages.

L-stamps for Fax Messages In order for a fax machine to receive an 1-stamp, there must be a fax machine that sends the stamp.

This machine is briefly described in Addendum 2.

Assuming, then, that a machine can send a fax with an 1-stamp-we can call this message an 1- fax-the receiving machine can include means for parsing the 1-stamp data from the 1-fax, and for storing the content of the 1-fax message. We assume that the receiving machine can store fax messages and communicate via e-mail over the Internet.

In the case of an 1-fax, the sender ID data is the phone number of the sending machine (unless the sending machine includes means for adding, to the 1-fax, an e-mail address for the owner of the fax machine).

The receiving machine then converts the 1-fax into an e-mail message with the 1-stamp data in the header and with the caller phone number-for identifying the owner of the sending machine-in a standard position in the e-mail. The receiving machine then sends this e-mail to BERS upon a command from Reece. BERS can then parse the e-mail as it would a normal, forwarded 1-mail.

In order to bill Caleb, BERS needs to notify him. Notification can be done by automated outbound calling means, using the caller's phone number, after the caller's debt total reaches a threshold.

Alternatively, BERS may be able to communicate with a directory that lists phone numbers and corresponding e-mail addresses. BERS can then find the e-mail address that corresponds to Caleb's phone number, and then send a notification by e-mail. (If 1-stamps for phone messages are common, we can imagine that such a directory would exist.) As one of it's features, BERS can even include this directory.

L-stamps for Voice Messages In the case of a voice message, the sender is a caller who we'll call Caleb.

Where a voice message is concerned, the key issues are how to identify the caller and how to capture the caller's assent to the terms of paying the owner of the phone to receive a call. Below we describe a machine that does these two things.

An"intelligent"phone/answering machine (phone), connected to the Internet, can be constructed from well known elements such that the machine executes the following procedure upon receiving a call: 1. checks for the caller's phone number by caller ID, ANI or other equivalent means.

2a. if the caller's phone number cannot be captured, plays a message stating that the phone cannot accept calls from blocked numbers, hangs up.

2b. if the number is capturable, captures the number and stores it, 3. plays a message to the caller telling the caller that he must pay a specified EV amount to the receiver through an 1-stamp, according to the terms of an 1-stamp contract, and asking the caller to press an assent key if he accepts the terms.

(For example, the message might say,"In order to leave a message or speak to the owner of this phone, you will have to pay 10 cents, payable by the expected value payment method, where you risk losing $10, and where the bet is executed by BERS. Press"I"if you accept these terms.") 4. waits for the assent tone, if no assent tone is received, hangs up. if an assent tone is received, lets the call ring through (by"let's the call ring through"we mean that the phone rings such that a person can pick it up or the caller can leave a message on the answering machine), 5. upon a command from the operator of the phone, composes e-mail message that includes the caller's phone number and the EV that the caller agreed to pay, sends the e-mail message to BERS for redemption.

BERS then receives the e-mail and processes it just as it would a normal 1-mail, except that instead of capturing the sender's e-mail address, BERS captures the sender's phone number. (If the caller loses the 1-stamp bet, BERS can notify him by the means discussed above.) Now, since disputes can arise, it may be useful to get evidence that Caleb actually made the call to Reece. To get this evidence, the phone can record a snippet of the message left by Caleb or of the conversation Caleb had with Reece, and can send this snippet as part of the content of the e-mail to BERS. BERS stores this snippet as the content of the e-mail message.

L-stamp for Reaching a Person by Phone Caleb may only want to pay to reach a person, preferably the owner of the phone. And so the phone can include means for enabling Caleb to agree to pay only if he reaches a person. The phone may can thus include two assent keys, one for paying to leave a message, and one to pay to reach a person.

The price for reaching a person can be higher, of course, than for reaching the answering machine.

In order to provide evidence that a person was reached, the phone can record a snippet of the conversation, as discussed.

If the assent key for reaching a person is pressed, and a person does not pick up the phone does, then the phone will not send an e-mail to BERS for charging Caleb.

L-stamp for Paying to Have a Person Call Back Caleb may leave a message and may want to pay to have the owner of the phone get back to him.

Now to do this, a phone can execute the following steps upon receiving a call: 1. plays a message: a. stating the price (an EV amount) for getting a call back, b. asking the caller to leave a message telling the caller's name, c. asking the caller to press and assent key if he agrees to the terms, 2a. if an assent tone is not received, hangs up, 2b. if an asset tone is received: a. records that the caller will pay the price to get a call back, b. records a voice message from the caller (in which the caller leaves his name, at minimum), c. captures the caller's phone number and stores it, 3. upon a command from its operator, phone dials the caller back, 4. if a person is reached, records the a snippet of the conversation with the person who answers the callback, 5. if caller is reached then the operator of the phone enters a command and the phone sends message to BERS (as described above), with the caller's ID data, the phone's e-mail address, and the EV amount that the caller agreed to pay to get a call back.

Chapter 7 Revealing the Result by Going to a Website Yet another type of 1-stamp is one that is affixed to an e-mail and whose result is revealed by going to a website. We will call this kind of 1-stamp a website l-stamp.

In most cases, the purpose of such a stamp is to pay a recipient for going to the website, rather than for reading an e-mail. Still, an e-mail bears such a stamp. The main message of the e-mail can simply alert Reece that she will get paid an expected amount-paid the I-stamp amount-for going to a specified website. She reveals the result of the stamp by going to the website, and can cash a winning stamp at the website as well. Thus, the website acts as an RS while an LS sends the stamp. The website server may also be the LS, in which case the server is an LSRS.

For example, an e-mail with a website 1-stamp could include an EV of, say, $. 10 in the header and following message in the body: Pep Boys Announces a Sale. Check it out at pepboys. com. We're so confident that you will be interested that we will pay you 10 cents to go to our website. To redeem your payment, go to pepboys. com and enter your e-mail address in the l-stamp webform.

You can win $1000. Your odds are 1/10,000. Good luck.

(As noted, an e-mail can be stamped with more than one kind of stamp, and thus, a website 1- stamp can be affixed in addition to a"regular"I-stamp whose purpose is to pay the recipient just for reading the e-mail.) Affixing a Website L-stamp To affix a website l-stamp to an e-mail, an LS adds, at minimum, all the essential L-stamp information previously described except the result. In addition, the LS adds: 1) A URL for a website. The URL can be just text or text and a link to the site signified by the URL. (Thus, an L-mail list can include a standard field for storing the URL of the website where the l-stamp result is revealed.) 2) Instructions for entering a redemption ID into a form at the website. The instructions can state the redemption ID or it can be standard and understood. It may be the ID of the stamp or it can be something simpler. For example, a user's e-mail address might be a standard redemption ID.

Thus, in the case of website stamps, if the stamp is redeemed with a redemption ID using only header information, the operation of adding an ID, as defined in Chapter 3, may be especially unnecessary.

(An 1-mail list can include a field for the redemption ID of each website 1-stamp. Such a field may be unnecessary if the ID is a standard piece of information that is already in the 1-mail list, such as an e-mail address.) 3) Possibly, a symbol signifying that the 1-stamp is a website I-stamp. This symbol can be added to the e-mail header.

Redeeming a Website L-stamp A website 1-stamp is redeemed at the website designated in the stamp. Thus, this website acts as an RS.

There are two basic methods of redemption. One is to check a redemption ID against an 1-mail list to see if a stamp is a winner or loser. The other way is the determine the result of the stamp at the time of redemption. This second way may be most prevalent given the requirements for stopping cheating (see Chapter 2.4).

Either way, the RS stores (or accesses) an 1-mail list, or lists, in order to check redemption ID's that are submitted through the site's redemption webform. Thus, the LS and the RS work in concert, and can be the same machine (an LSRS).

We will first describe the method of simply checking an 1-mail list to see if a stamp is a winner or not. Then we will describe the method of determining the result of the stamp at the time of redemption.

(We note that the website might include means for insuring that Reece looks at a certain number of pages on the website before she can get paid-can get a chance to win the payoff, that is. We do not dwell on this point.) Revealing Pre-Determined L-stamps Results A recipient of a website I-stamp goes to the designated URL (webpage) specified in the stamp and enters the redemption ID into a webform. The RS then checks the ID against the 1-mail lists stored in its memory to see whether or not the ID corresponds to a genuine, unexpired stamp.

If a stamp is genuine and unexpired, the RS checks to see whether or not the ID corresponds to a winning or losing stamp. After finding the result, the RS outputs the result to Reece's browser.

If the stamp is a winner, the RS also outputs a payoff form to Reece's browser which include fields for entering Reece's legal name and physical address so that a check can be sent to her. The RS, of course, captures the data that Reece submits through the form.

(Note: in Chapter 4 we described how a user can redeem a winning I-stamp by going to a webform that is tied into an RS database. The method above is nearly the same. The main difference is that the result of the 1-stamp is not revealed to Reece until she goes to the website and enters a redemption ID into a webform.) Determining and Revealing the Result at the Time of Redemption This method is the same as the one above in the sense that the RS inputs a redemption ID and then checks against an 1-mail list to see if the ID corresponds to a valid, unexpired stamp. But, in this case, the result of the 1-stamp has not been determined by the LS, the result is not in the 1-mail list, that is. Hence, the RS must determine the result.

Therefore, if the 1-stamp is genuine and unexpired, the RS then checks the relevant 1-mail list to find the EV and the payoff, so that the RS can determine the stamp's probability of being a winner (if all the 1-stamps being redeemed at the site have a standard EV and payoff then this step is unnecessary, of course).

Once the RS has the EV and payoff, it determines the result of the stamp by using an RN, as has been discussed previously. (The procedure for generating the RN needs to be cheat-proof. We discuss methods of generating a cheat-proof RN in Chapter 2.4.) Having generated the RN, the RS determines the result and outputs the result to Reece's browser.

If Reece has won, the RS also outputs a payoff form to Reece's browser and captures her payment data after she submits the completed form.

Stopping Multiple Redemption Attempts We should note also that if an e-mail address (or other non-unique identifier) is the redemption ID then there can be problems if the recipient is sent more than one stamp. That's because the redemption ID can correspond to more than one stamp. For example, if pepboys. com sends Reece two website I-stamps, each announcing a different promotion, and each using Reece's e-mail address as a redemption ID, how will the pepboys website know which 1-stamp is being redeemed when Reece goes to the site and enters the ID? To prevent this problem, the LS and RS can employ further steps to insure that a redemption ID corresponds to only one stamp at a time. The LS can send out stamps with expiration dates (eligibility periods) that do not overlap. Thus, Reece can only redeem one stamp per period of time. When Reece goes to redeem a stamp, the RS can check its 1-mail lists and restrict the search to unexpired 1-stamps. Another time-based step is to only let Reece make one redemption attempt per period of time. Thus, the RS can register the time of every redemption attempt-when Reece enters a redemption ID, that is-and can output a"you are ineligible"message, if she has tried more than once during the predetermined period of time.

Aside: Redeem by Answering a Question As noted in sub-section Se9, an 1-stamp's conditions of redemption may stipulate that Reece answer questions about the content of the L-mail. One way to submit the answers is through a webform that is part of an LSRS.

To affix such L-stamps, the LSRS includes functions for adding questions to the body of an e-mail or just instructions that questions must be answered at a website.

To redeem such L-stamps, the LSRS must include means for enabling Reece to enter answers into an automated form or by e-mail. The answers can be checked for correctness automatically (as is done currently by cybergold. com). Reece's 1-stamp can then be redeemed by the methods explained above.

Chapter 8 Extra Header Fields and Messages As noted in the introduction, the purpose of adding L-stamps to e-mails is to enable Reece to sort and/or screen those e-mails. To that end, the LS affixes an EV amount to the header of an L-mail.

The header can be the subject header or a new header field especially for the EV.

The LS can include functions for automatically adding other header messages. These too can have their own fields or be part of the subject field. E-mail receiving programs can parse the subject field (or other header fields) and sort and/or screen e-mail based on these messages.

EV Per Word In addition to (or instead of) the EV-which denotes a total expected payment-an LS can add a header value that tells the expected payment per word of an L-mail. In order to do this, the LS must also include functions for inputting (or counting) the number of words in an e-mail body message and for dividing the EV by the number of words.

Effort Required to Redeem (the Type of L-stamp Affixe) An LS can also add qualitative classifiers to a header that describe the effort required to find the result of the L-stamp. For example, an LS can include a function for adding E ("easy to redeem") or H ("hard to redeem") to a header. Such classifiers help Reece decide whether or not to examine the contents of L-mail. An LS can also include functions for adding classifiers that identify the method of redeeming the L-stamp-that identify the type of L-stamp that has been affixed to the e- mail, that is.

Class of L-mail An LS can also add symbols to a header that denote particular classes of L-mail. For example, one class might be an L-mail"business reply card"that is kept under a certain number of words.

Payment Guarantee An LS can also add a credential to a header denoting the guarantor of the L-stamp payoff.

Matching Guarantee An LS can also add a credential to a header signifying that the body content genuinely matches a request made by Reece. This kind of header information might be useful because certain senders might falsely claim that their L-mail is about a subject that Reece has requested information about.

Thus, a sender can be credentialed (licensed) to send L-mails that match subject requests. This kind of credential is like a credential signifying that a company is part of a trade association and adheres to the standards and practices of the association.

Chapter 9 Anti-cheat Methods for L-stamp Systems In order for L-stamps to be practical, recipients have to be sure that the L-stamp bets are fair. Many methods exist for insuring that random number bets are fair. Below we will discuss different methods that can be integrated into systems for affixing and redeeming L-stamps. Most of these methods involve a third party. So, as needed, we introduce third parties and servers controlled by third parties.

As noted in Chapter 1, the RNG can be separate from the LS-the LS can simply affix the terms of an L-stamp bet contract, while the RNG supplies the RN that decides the bet.

The process of selecting winners-the process of generating the RN's that determine winners-is where cheating needs to be prevented so we organize the discussion according to which party controls the RNG. We first describe methods that apply when Seneca controls then RNG, then when Seneca and Reece jointly control the RNG, and then when a third party, Ted, controls the RNG.

(Note: For brevity's sake, we omit the details of setting the range from which the RN is selected.

Likewise, we omit the details of determining whether a stamp is a winner or loser, given the RN that is selected to decide the bet. We take these processes to be understood. Our goal in this chapter is only to describe processes for insuring that the RN selection process does not involve cheating.) 9.1 When Seneca Controls the LS and RNG When Seneca controls the RNG we will assume that he also controls the LS. If Seneca controls the LS and RNG then the only way to insure that Seneca is deciding bets fairly is for Reece or a third party to inspect the RNG process. Direct inspection is impractical but auditing is possible. Thus the RNG process can be inspected indirectly by a third party audit server.

In one audit method, the audit server receives L-stamps from Reece and other recipients of Seneca's L-stamps. The audit server includes means for subjecting the L-stamps to statistical tests to see if the EV's advertised on the L-stamps correspond to the actual odds of winning. The actual odds can be roughly revealed statistically if enough L-stamps, both winning and losing, are sent on a random basis to the audit server.

In another audit method Seneca's LS sends the audit server an L-mail list which includes a result for each L-stamp. The audit server then checks that the random number generation is fair-i. e., that the actual results do not deviate too far, in favor of Seneca, from the probability stated in the stamps. (Means for evaluating the deviation in a probabilistic process are, of course, well known in the field of statistics.) The audit server can also combine results from multiple L-mail lists that Seneca has sent in the past, in order to develop statistics based on a larger set of bets.

Seneca may cheat an audit server by having his LS send winning stamps to confederates. To stop this cheat, an audit server can include means for doing statistical analyses that check whether a person has won an improbable amount of times. Again, these means are well known in the art. To perform such checks, the audit server must keep records (at least short-term records) about the results of stamps sent to individual recipients.

Seneca can also have a rule, which the audit server can check, that no one can win more than once for a certain period of time. With these measures, if Seneca's LS sends tens of millions of L- stamps, cheating by confederates will be hard, unless the payoff amounts are very large.

Seneca can also cheat by not sending Reece a winning stamp that she was supposed to get. To stop this cheat, the audit server can include means for selecting a sample of winning recipients and then sending them e-mail messages, called check messages, that ask each recipient if she has indeed received a winning L-stamp, as she was supposed to, from Seneca. The check message will, of course, include information identifying the original L-mail that was supposed to have been sent.

This information can be taken from the L-mail list and from the body template associated with that list.

(Note: check messages are used in other anti-cheat methods described later. The definition above applies those methods as well.) If the audit server finds that the RN generation is fair, it can send a certification number to the LS which the LS can affix to the audited stamps to assure Reece's that the RN generation is fair. The audit server can store the certification number as part of the record it keeps of its audit.

To recap, then, an audit server can perform the following steps to prevent cheating in L-stamp bets: 1) Gets L-mail list and associated header and body templates from an LS, 2) Groups the stamps according to their stated probability of winning, each group corresponding to a single probability figure, 3) For each group, checks the actual frequency of winning results, 4) --If the actual frequency of winning results is greater than the stated probability (in other words, if the actual frequency favors the receivers), generates a certification number, sends the certification number to the LS.

--If the actual frequency of winning results is less than the stated probability (in other words, if the actual frequency favors the sender), calculates the probability of the favorable deviation occurring, If the probability of the favorable deviation occurring is less than a threshold, outputs an alarm, If the probability of the favorable deviation occurring is greater than a threshold, generates a certification number, stores the certification number with the L-mail list, and sends the certification number to the LS.

A General Weakness of Certification Servers A weakness of this scheme is that Seneca can send fake stamps without submitting them to the audit server. The stamps can have a zero probability of winning and the recipients will be none the wiser. The audit server will not be able to catch the cheat because it will not have been able to check those stamps.

The weakness above is inherent in anti-cheat methods where a third party certifies stamps.

Whenever a third party is relied on for certification, Seneca can potentially fake that certification (unless certain cheat-proof cryptographic methods are used).

A way to stop fraudulent certification is to have recipients send stamps randomly to the certification server. That way, if Seneca sends fake stamps, he will be caught. Thus, a certification server can include means for registering stamps submitted by recipients and for verifying that those stamps are genuinely certified.

These means can be included in an audit server and in the other kinds of certification servers described in this chapter.

9.2 When Seneca and Reece Combine RN Inputs One way to insure that L-stamp bets are fair is for the RN generation to be done by both Seneca and Reece through a combined input method. A combined input method is a protocol in which both parties contribute an input and the inputs are combined to create the RN. Here we discuss a couple ways of doing combined inputs.

Combined input methods aren't well suited to most L-stamps unless the protocol is completely automated. To completely automate the protocol the LS and the e-mail receiving program must have compatible software.

(Website 1-stamps are the main exception, as these are suited to combined input methods. See Section 9.4) We should also note that with combined input methods the result is not revealed in the header of body or an L-mail. It is revealed by a secondary message that announces the result.

Using Tagged VIDRN Inputs A verifiably independently determined random number (VIDRN) is an RN that verifiably comes from a neutral source. One way an RN can be a VIDRN is for a neutral party to generate a list of RN's and identify each with a number called a tag that can be used to verify that the RN was generated by the neutral party. We will call this kind of VIDRN a tagged VIDRN. To verify a VIDRN, Reece contacts the RN source and submits the tag. The source can then reveal which VIDRN corresponds to that tag.

Normally, the source would only reveal the VIDRN after a pre-set date, called a release date (which may be set by a generally understood rule) or provided that a release code is supplied. The code would correspond to the RN and would be stored by the LS, which would output the code to Reece once her input has been submitted.

Below is a combined input protocol in which the LS uses a tagged VIDRN 1) The LS gets a list of tagged VIDRN's from a neutral RN server.

2) The LS affixes an L-stamp that shows Reece: a) the EV, b) the bet amount, c) the ID data for the RN server, and d) the tag and release date for the VIDRN 3) Reece acknowledges the terms of the bet by returning an input by e-mail.

4) The LS takes its VIDRN input (which corresponds to the tag) and combines its input with Reece's input and determines the winner.

5) The LS alerts Reece by e-mail if she has won.

Using a VIDRN Formula A VIDRN formula is a random number generating formula that uses a seed value to create an RN.

The VIDRN formula is constructed by a neutral party (the source of the VIDRN) and is identified with an ID number. The LS can use a VIDRN formula to generate a fair RN that decides a bet. If the seed value comes from Reece the LS cannot influence the resulting RN If Reece suspects cheating she can contact the source of the VIDRN formula to check which RN corresponds to the seed value she entered and the VIDRN formula that was used. The formula is known only to the LS and the independent server that stores the formula. Reece only needs to know the VIDRN ID# and the server to verify that the RN generation is fair. After a pre- determined date she could send a verification request to the server (which would include functions for handing such requests).

Thus, a combined inputs protocol for using a VIDRN formula is: 1) The LS gets a VIDRN formula from the RN server.

2) The LS affixes an L-stamp that shows Reece: a) the EV, b) the bet amount, c) the ID data for the RN server and d) the ID# of the VIDRN formula.

3) Reece accepts the terms of the bet by returning a seed value by e-mail.

4) The LS plugs the seed value into the formula and gets the RN.

5) The LS determines the winner.

6) The LS alerts Reece by e-mail if she has won.

In this protocol, Reece can possibly cheat by trying to submit various seed values to the source of the formula. Thus, the source can reveal an RN only after a release code is given.

Automating Reece's Response The problem with the two protocols above is that they require Reece to respond manually. It is possible to automate these protocols further at step 3 by having Reece's e-mail program enter Reece's input or seed value.

Putting the Main Body Content in the Second L-mail Another problem with the two protocols above is that the LS sends the result in a second e-mail message. If Reece's response is automated, then she has no incentive to open the first L-mail. She may have to open the second one, but it does not contain the e-mail body copy. Thus, Seneca's LS can simply set the bet terms in the first e-mail message while including the body content and the result in the second L-mail. That means that the second message is sent to Reece regardless of whether she has won or lost.

Note on Blum Type of Interactive RN Selection Zero-knowledge proof type of fair coin flipping, such as Blum's protocol, and public key type protocols (see Schneier's Applied Cryptography) are possible as well if the LS and Reece's e-mail program have compatible protocol software.

9.3 Third Party Anti-Cheat Methods There are many ways that a trusted third party can control the RN generation for deciding L-stamp bets. We give several ways in this subsection. In all these ways, the RN's we refer to are verifiably independently determined random numbers (VIDRN's), meaning that they not only come from the third party's RNG but that they are identified to enable Reece to verify that they have come from that RNG. We will call the third party Ted.

9.31 Using Time Delayed VIDRN's from a Public RN Source One way that an RN can be a VIDRN is for a neutral party to generate the RN publicly at a time after the bet terms are set. For example, the terms of a bet can be set on Monday and the RN can be selected on Tuesday by, say, the California State Lottery. We will call this kind of RN a time delayed VIDRN.

The LS can get such VIDRN's automatically by being connected to a public RN server. (Or, humans can enter the VIDRN's into the LS manually.) The LS can get a VIDRN per L-stamp from the RN server. However, it is more efficient to use one RN to decide multiple bets. The problem with doing so is that if all the L-stamps have the same terms then the results will be uniform, they will all be winner or all be losers.

One way of solving this problem is simply to have different RN's decide results for different mailings. That way multiple RN's will be used and, over time, the results will average out.

Another solution to this problem, in a single mailing, is to give each L-stamp with the same probability of paying off a different range of winning RN's. For example, say two L-stamps have a 1/10 chance of paying off. And say that the RN is selected from 1-100. Then one L-stamp might have a winning range of 1-10 and another might have a winning range of 21-30. When affixing the L-stamps, the LS can insert the winning range variably per L-stamp, rather than have the same range for every stamp.

Alternatively, a single range can be used if the RN varies. A single, public RN can be used and it can be made to vary by adding a number to it. This extra number can vary according to a public rule that links the variable to a recipient's address. For example, the extra number can be 5 if the first letter of an address is A, 10 if B, 15 if C, and so on. Thus, the LS can add the same redemption instructions to each L-stamp, telling the recipient how an extra number, based on the recipient's address, is added to the public RN.

The main problem with the time delay method is that it requires that two e-mails are sent to the recipient per bet. The first e-mail sets the terms of the bet before the VIDRN is revealed. The second e-mail tells the result of the bet after the RN is revealed.

The first e-mail message can be a full L-mail that includes the subject and body templates along with the L-stamp bet terms. The purpose of the second message then is simply to announce the result. So, one way of doing a time delay VIDRN method is as follows: 1) The LS sends Reece an L-mail with an L-stamp stating: a) the EV, b) the payoff amount, c) data identifying a public RN server, d) the time/date the RN will be selected by the RN server (the time must be after the time that the bet terms are presented).

2) The LS gets the VIDRN from the RN server after the RN is selected.

3) The LS determines whether Reece's L-stamp is winner or loser.

4) The LS sends Reece an e-mail telling her the result.

(For efficiency, the LS only needs to tell Reece if she has won. But, if Seneca wants to insure that Reece opens her L-mail, his LS would send result e-mails to Reece whether or not she wins or loses. She would find out the result by opening the second e-mail.) The problem with sending two-messages this way is that Reece has no incentive to open the first L-mail because the result will be revealed in the second e-mail. Reece may have an incentive to open the first e-mail if she has no idea how the result is going to be revealed. But still, she is not compelled to open the L-mail in order to redeem a winning stamp.

Thus, an alternate way to send two-messages is to only set the terms of the bet in the first e-mail and then send the result and the body template in the second e-mail. In this way the L-stamp is duplicated in two e-mail messages. The first e-mail message also includes information identifying the L-stamp to be sent in the second e-mail. Correspondingly, the second e-mail will contain information identifying the first L-mail.

So, another way of doing a time delay VIDRN method is as follows: 1) The LS sends Reece a first L-mail with no body content except L-stamp information stating: a) the EV, b) the bet amount, c) data identifying a public RN server, d) the time/date the RN will be selected by the RN server, e) information identifying a second L-mail that will be sent at a future date, whose L-stamp will have the same terms and whose result will be revealed in that second L- mail.

2) The LS gets the VIDRN from the RN server after the RN is selected.

3) The LS determines whether Reece's L-stamp is winner or loser.

4) The LS sends Reece an L-mail that includes: a) the L-stamp described in the first L-mail, b) body content, c) information identifying the first L-mail, d) the result of the L-stamp.

Using a Witnessing/Verifying Server There is a way to avoid sending Reece two e-mails when using time delayed VIDRN's. This way involves setting the bet terms before the RN is revealed by sending the terms for the L-stamps to a witnessing/verifying server (WVS) controlled by Ted.

By this we mean that Seneca's LS sends Ted's server an L-mail list and corresponding body and header templates that Seneca will be using in for a future mailing. The L-mail list does not include L-stamp results because the results are to be determined by an RN to be generated in the future by a public server.

The L-mail list, in this method, will also include data identifying the RN that will be generated by the public server, including the name/address of the public server, the time/date of the RN generation, and whatever other information is needed to identify the particular RN that will be used. This RN ID data is a record for Ted's WVS and instructions telling when and where to get the RN. For example, the L-mail list LS can specify that the RN is to be the PowerBall lotto number for a given day.

After the RN is selected, Seneca's LS gets the RN, determines the L-stamp results, and adds the results to the L-stamps. Then the LS sends out the set of L-mails with L-stamps as dictated by the L-mail list that Seneca's LS sent to Ted's WVS. The LS can also affix a credential to each L-stamp identifying the WVS that is monitoring the RN generation.

Seneca might try to cheat by not sending L-mails to winning Reece's but that cheat can be stopped by having Ted's WVS send check messages to a sample of the winners (check messages were defined in section 9.1). Thus, the L-mail list will also include the date that Seneca intends to send the L-mails so that Ted's WVS knows when to send the check messages.

A WVS protocol for insuring fair bets executed by an LS is as follows: 1) Seneca's LS sends Ted's WVS an L-mail list that does not include L-stamp results but does include: a) a set of information identifying an RN to be generated at a future time/date by a public RN server, b) the date that the L-mails described in the list will be sent.

2) After the time/date of the RN generation arrives, Seneca's LS and Ted WVS get the RN from the public server.

3) Seneca's LS and Ted's WVS use the RN to determine the results of the L-stamps in the L-mail list.

4) Seneca's LS sends the L-mails with the L-stamps affixed, including results and a credential identifying Ted's WVS.

5) After the date of sending, Ted's WVS sends check messages to a sample of winning Reece's.

We can look at the WVS as its own entity of course. Looked at this way, the WVS executes the following steps for insuring fair bets by an LS: 1) Gets an L-mail list that does not include L-stamp results but does include: a) a set of information identifying an RN to be generated at a future time/date by a public RN server, b) the date that the L-mails described in the list will be sent.

2) Stores the L-mail list.

3) After the time/date of the RN generation arrives, gets the RN from the public server.

4) Using the RN, determines the results of the L-stamps in the L-mail list.

5) Selects a sample of the winning recipients.

6) Sends check messages to the sample, asking each recipient to reply if she has not received a winning stamp from Seneca, as dictated by the information in the L-mail list.

7) Checks for replies; and if any replies are received, stores them outputs an alarm identifying those replies.

9.32 Neutral Randomizing/Verifying Server A cheat prevention method that is nearly identical to using a witness server is one where the witness server also selects the winning L-stamps. We will call such a server a randomizing/verifying server (RVS). In this method, the LS still sends the L-mails. And the affixed L-stamps are the kind that state their results. But these results are decided by Ted's RVS.

The RVS may supply a single RN for all the L-stamp bets, if all the stamps have the same payoff amount. Alternatively, the RVS can generate an RN for each L-stamp that has a different payoff amount. Or the RVS can generate a separate RN for each L-stamp bet, regardless of the payoff.

The RVS will supply an RN that is selected from a range of integers that is appropriate for each L- stamp bet. The range can be dictated by prefatory instructions that accompany the L-mail list. Or, the RVS can check the payoff for each L-stamp (the RN range is dictated by the L-stamp payoff).

One method for using an RVS is as follows: 1) The LS first sends an L-mail list (without results) to Ted's RVS.

2) The RVS reads each L-stamp record in the list.

3) The RVS, gets the probability of winning for each L-stamp.

4) The RVS generates an RN for each L-stamp.

5) The RVS uses the RN to determine the result of each L-stamp.

6) The RVS enters the result for each L-stamp into the L-mail list.

7) The RVS stores the modified L-mail list and sends it back to the LS.

8) The LS then sends out the L-mails as dictated by the modified L-mail list.

9) At a pre-specified time, the RVS sends check messages to a sample of the addresses that were supposed to get winning stamps.

10) Checks for replies; and if any replies are received, stores them outputs an alarm identifying those replies.

9.33 Neutral Direct L-Mail House In this"method"Seneca delegates the entire job of sending L-mail to Ted, a direct e-mail house specializing in L-mail. Seneca supplies Ted with an e-mail template and a list of addresses (or asks Ted to supply the addresses) and tells Ted how much he wants the L-stamps to be worth to recipients. Reece trusts the L-stamp she gets because its result is determined by Ted.

(In this method, we assume that Ted's LS would pay off the stamp, with money supplied by Seneca.) 9.34 Neutral Re-mail/Randomizing Server In this method, Seneca's LS does not send L-mails directly to a list of recipients. Instead it sends them through a neutral re-mail/randomizing server (RRS) that forwards the L-mails to their intended addresses and also selects winners for the L-stamp bets. Each piece of L-mail has an L- stamp that specifies its probability of winning. The RRS selects winners according to that probability.

(In this method, the 1-mail list does not include stamps results, of course.) The L-stamp can include an instruction specifically for the RRS telling the RS to decide the L- stamp bet. Or, the RRS can default to the assumption that a bet needs to be decided if the RRS detects an L-stamp credential on an incoming e-mail.

So that Reece knows that a neutral third party has decided the L-stamp bet, Seneca's LS can add the name of the RRS to the L-stamps it affixes. Or the RRS can add its name to the L-stamps.

The RRS can reveal results by simply adding an RN to the body of each e-mail. (The RRS can rely on the RN range implicit in each L-stamp or the LS can send instructions to the RRS telling the RRS what RN range to select from is.) In this way, Reece can see, by the terms in the body of the L-mail, whether or not the L-stamp is a winner.

Alternatively, the RRS can decide the bets for each L-mail and add winning and losing messages to the L-mails. The winning/losing messages are inserted in the subject template or in the body template of the L-mails, depending on the instructions from Seneca's LS.

The RRS records the winning and losing L-stamps and sends a list of the results back to the LS.

(The RRS can append the results to the L-mail list, if the LS has sent that list to the RRS.) Of course, an RRS can also be used by LS's for relaying individual L-mails. In this case, the RRS does not need to send a list of results back to Seneca every time it relays one of his 1-mails.

However, the it can sending a message back to him if the stamp on the 1-mail he has sent is declared a winner (since Seneca will presumably want to know about the debt).

The RRS will also need means for capturing the intended, ultimate receiver (s) of the 1-mail (s).

Thus the RRS can include means for parsing the e-mails sent through it to detect the ultimate destination address. Correspondingly, the LS can add the ultimate address in a pre-specified field in the e-mail.

Thus, an RRS executes the following steps for insuring fair L-stamp bets: 1) Receives an L-mail (with an L-stamp).

2) Captures the address of the intended, ultimate destination.

3) Detects an instruction telling the RRS to decide the L-stamp bet.

4) Captures the EV and Payoff amounts and the ultimate intended destination of the L-mail, 5) Generates an RN from 1-Payoff, 6) Generates an ID number for identifying the L-stamp, 7) To the body of the L-mail, adds the RN, the ID number, and data (a credential) identifying the RRS.

8) Stores data identifying the L-mail.

9) Forwards the L-mail to its ultimate intended destination.

9.35 Third Party Redemption Server In this method, Seneca sends an e-mail to Reece and Reece has the choice of forwarding it to an RS controlled by Ted where the bet is decided (as discussed in Section 1.5e).

If Reece wins the bet, the RS sends notice to Seneca and Reece.

The RS can collect and payoff as described in Section 1.5e.

9.4 Anti-Cheat Methods for Website L-stamps Where website 1-stamps are concerned, we'll assume that the anti-cheat method used is a combined inputs method. As discussed, combined input method is a protocol whereby both parties contribute an input and the inputs are combined to create the RN for deciding the 1-stamp bet.

The advantage of such a method is that a fair RN can be generated quickly. The other anti-cheat methods discussed in the previous sections have disadvantages. Of course, if the website RS is controlled by a neutral party, then special techniques for insuring a fair RN are unnecessary.

However, we assume that the website in not controlled by a neutral party.

We'll repeat some definitions from Section 9.2 but the combined input methods described here will vary slightly from those in 9.2.

Definitions Destination website. The website where a receiver redeems a website 1-stamp. Also called the redemption server (RS).

Verifiably independently determined random number (VIDRN). A VIDRN is an RN that verifiably comes from an independent source. Either party in a bet can verify that the other party has no control over the VIDRN.

VIDRNformula. A formula for generating pseudo-random numbers that verifiably is constructed by an independent source. Either party in a bet can verify that the other party has no control over the VIDRN formula.

Independent random number (IRN) server. A server that provides VIDRN's or VIDRN formulas.

Additional definitions are given below, as needed.

Using Tagged VIDRN Inputs One way an RN can be a VIDRN is for a neutral party (an IRN server) to generate a list of RN's and identify each with a number called a tag that can be used to verify that the RN was generated by the neutral party. We will call this kind of VIDRN a tagged VIDRN.

In a bet then, a destination website shows Reece a tag for a VIDRN. Reece then enters her RN input. The site then combines the inputs to yield the combined input RN for deciding the bet.

To verify a tagged VIDRN, Reece contacts the IRN server and submits the tag. The IRN server then reveals which VIDRN corresponds to that tag.

The flaw in this method is that Reece might be able to find out which VIDRN the tag corresponds to before she enters her input. Thus, a tagged VIDRN can also correspond to a release code which is required by the IRN server in order to reveal which RN the tag corresponds to. The code would be stored by the IRN server and the RS. The RS would output the code to Reece once her input has been submitted.

A protocol follows that uses a tagged VIDRN input from the RS: 1. The RS gets a list of tagged VIDRN's from an IRN server. (Each RN in the list has a corresponding tag and a corresponding release code).

2. Reece arrives at the RS website ready to enter her redemption ID.

3. The RS shows Reece: a) the EV, b) the payoff, c) the ID data for the IRN server, and d) the tag for the VIDRN, e) an explanation of how the inputs are to be combined.

4. Reece acknowledges the terms of the bet by entering her redemption ID and an input.

5. The RS: a) reveals its VIDRN input (which corresponds to the tag), b) combines its input with Reece's input to yield the RN for deciding the bet, c) determines the result of the stamp.

6. The RS outputs the VIDRN, the result and the VIDRN's release code as well. If the stamp is a winning stamp, the RS also outputs a payoff form which enables Reece to enter legal ID data which the RS registers (so that she can be paid). For RN verification purposes, we assume that the RS website outputs all the terms of the bet when it outputs the result.

Using a VIDRN Formula A VIDRN formula is a random number generating formula that uses a seed value to create an RN.

The VIDRN formula is constructed by a neutral party and is stored in an IRN server.

The formula has an ID# so it can be identified by the IRN server.

The RS can use a VIDRN formula to generate a fair RN for deciding a bet. If the seed value comes from Reece the RS cannot influence the RN.

If Reece suspects cheating she can contact the source of the VIDRN formula to check which RN corresponds to the seed value she entered and the VIDRN formula that was used. The formula is known only to the RS and the IRN server that stores the formula. Reece only needs to know the VIDRN ID# and the IRN server to verify that the RN generation is fair.

The flaw with this method is that Reece may to find out the RN that corresponds to her seed value before she actually enters the value at the website. Or, she may use a successful seed value that someone else used. This cheat can be stopped if website contributes its own seed which is added to Reece's seed. The RS's seed would be shown along with the VIDRN ID#. But, again, Reece might use take this extra seed value and use it to check the RN that would be generated with it and her seed value.

Thus, an additional measure to stop Reece from cheating is to use a release code. This release code is different from the kind above. In this case, the release code is taken from the VIDRN that is generated by the formula. We assume that the full RN that is generated is longer than the number of digits needed to decide the bet. We assume that it is truncated for purposes of the bet. For example, if the RN needed to decide the bet is from 1-100, the full RN might be actually be dozens of digits long. Thus, certain pre-specified digits, that are lost in the truncation, can be used as the release code. The IRN and the RS will be able to generate this release code, but Reece will not because she does not know the formula. Thus, when the RS reveals the RN, it also reveals the release code. Reece can then use the release code to verify that the RN was properly generated.

A combined inputs protocol using a VIDRN formula is: 1. The RS gets a VIDRN formula from the IRN server. The formula comes with an ID# that identifies it in the IRN's memory.

2. Reece arrives at the RS website ready to enter her redemption ID.

3. The RS shows Reece: a) the EV, b) the payoff, c) the ID data for the IRN server and d) the ID# for the formula, e) the RS's seed value.

4. Reece acknowledges the terms of the bet by entering her redemption ID and a seed value.

5. The RS: a) combines its seed value with Reece's seed value, b) plugs the combined seed value into the formula, c) calculates the RN for deciding the bet and calculates the release code, d) determines the result of the stamp.

6. The RS outputs the VIDRN, the result and the release code for that VIDRN as well. If the stamp is a winning stamp, the RS also outputs a payoff form which enables Reece to enter legal ID data which the RS registers (so that she can be paid). For RN verification purposes, we assume, that the RS website outputs all the terms of the bet when it outputs the result.

Entering an Input or Seed Value Can Be Quite Easy We should note that entering an input or seed value can be just a matter of clicking on a number out of a set of numbers. For example, the destination site can present numbers from 1-100 and Reece can click on one of these.) Fully Automating the Protocols It is possible to automate the combined input protocols further at step 4 by having the RS get Reece's input or seed value automatically. Reece's input could be her IP number of some random number supplied by her browser (and shown to her as well when entered automatically by the browser).

IRN Server Verification Process As noted above, an IRN server acts as a verifying website. For convenience, the IRN can be linked to an RS website so that Reece can jump to the IRN website to verify the result RN generation.

Thus, the RS website can also output a link the IRN site along with the results of the bet.

Rather than have Reece enter the bet terms and her RN input or seed value, the IRN can include means for pulling the bet terms from the page that Reece jumped from to verify that the RN generation was properly done or not. The IRN server then: --checks the formula Nid#, --if a corresponding formula is not in memory, outputs a message telling Reece that the formula is bogus, --if a corresponding formula is in memory, takes the seed values and plugs them into the formula, yielding a VIDRN, --checks the VIDRN against the VIDRN that is from the RS website, if the two number are different, outputs a message telling Reece that the RN generation is flawed. if the two number are the same, outputs a message telling her that the RN generation is fair.

Moreover, it is possible for the IRN to enable her to verify an RN only by jumping from the RS's linked result page. That way, the IRN server can prevent Reece from finding out ahead of time the RN that will result from a given pair of inputs or seed values.

Methods and Systems for Server Billing To date, the inefficiency of billing amounts under $2 has stymied efforts to sell information on the Internet. The expected value payment method (EVPM) of US patent #5,269,521 can be used to bill microamounts efficiently. However, the EVPM does not deal with collection issues.

Therefore, internet systems that implement the EVPM also require means for efficient collection of payments. The key requirement of collecting money is identifying the buyer. Here we present billing systems for internetworked servers using the EVPM and simple identification means.

The Parties The specification describes three parties: a buyer, a server and a credit bureau. The server and the credit bureau are, obviously, computers. The buyer is both a person and a computer. When we refer to a buyer taking an action, such as requesting information, we are usually also referring to the computer that the buyer is using-because the computer must implement the action. We take it to be understood that the buyer is at a computer that is connected by an internet to a server.

However, when we say that the buyer pays a bill, we do not necessarily mean that the buyer's computer has anything to do with the process. The buyer may send a check to the owner of a server who then enters this fact into the server. Thus, in certain cases, it is taken to be understood when actions are taken outside the system which are then entered into one of the system's computers by humans.

Billing To E-mail Addresses Here we present a billing system using e-mail addresses to identify buyers. In this system, there are three parties connected by an internet: The buyer, the party that wants to buy information, The server, the party that is selling information, The C-bureau, the party that verifies the credit of buyers.

For illustration's sake, we say that the information being sold is an article.

In this method, called e-mail billing (EMB), the buyer, the server and the C-bureau execute the following steps: 1. (On a webpage) The server shows the buyer a button to be pressed (or other such means) for entering a request for an article; the server shows the buyer the price of the article and payment terms; the server asks for the buyer's e-mail address (we assume that by entering his e-mail address, the buyer agrees to pay for the article).

2. The buyer enters his e-mail address.

3. The server registers his request and his address.

4. The server sends the address to the C-bureau.

5. The C-bureau checks the address against its database of e-mail accounts with unpaid bills.

6. If the address is in the database, the C-bureau sends that information to the server, which registers it.

7. If the the server regsiters that the address is in the C-bureau database, the server sends the buyer an e-mail message saying that his request has been refused due to bad credit, If the C-bureau does not send a message, within a certain period of time, saying that the address is in the database, the server sends the article to the buyer's e-mail address and registers a charge (for the article) to correspond to the buyer's e-mail address.

8. The server executes an EVPM bet to determine what the buyer actually pays.

9. If the buyer loses the EVPM bet, the server sends a bill to his e-mail address.

10. If the buyer does not pay his bill, the server sends that information to the C-bureau, which registers an unpaid bill for that address account.

What is nice about this method is not just the use of the EVPM for efficiency but also the collections aspect. Rather than have the buyer enter conventional payment information, like a credit card, before buying, the method uses the strengths of the EVPM to get such information from users only when they lose bets. Further, the buyer is extended credit until he loses a bet, in which case he must pay up. This means that the buyer does not have to do anyhting, except enter his e- mail address, until he loses an EVPM bet. When he loses, he can pay by check or credit card (or by some current or future electronic means).

(Another possibility, of course, is for the buyer to register a credit card number with the C-bureau before he buys. Then, when he loses, the server can contact the C-bureau which can run a charge on his card. However, advance sign-up of credit card information has proved to be a major obstacle to getting people to pay for information. On the other hand, the EVPM lessens the costs of advance sign-up because no charges are run until a user loses an EVPM bet.) Note: it is also possible for the C-bureau to register every new address and to send the server positive information, confirming that a buyer's e-mail address has no unpaid bills. However, we are trying to give the minimum number of steps. Positive confirmation seems to be superfluous.

These comments apply with IP Billing and with Centralized Billing as well.

IP and Cookie Billing In EMB, when a user buys information, it is sent to his e-mail address. This method can work in certain situations but it is more generally desirable to let users pay for information that is downloaded to their browsers. But, if we don't send the information to the user's e-mail address we can run into problems of verifying the user's identity. With EMB, we can be confident that the user's address is genuine because the user must pick up the desired information there.

We now discuss a system, called IP Billing (IPB), that enables servers to bill for information downloaded to browsers. IPB is very similar to EMB. The main difference is that charges are registered to the IP number of the machine that the user is at rather than to the user's e-mail address. The user's e-mail address is still captured so that bills can be sent but the enforcement mechanism is an IP number credit list.

(Important note: below we describe IP billing where a buyer is identified by his IP address. A cookie mechanism can be substituted for IP number, as an identification means. So, when we refer to IP billing we will also have in mind cookie billing. The systems described are essentially the same.) As in EMB, IPB involves three parties connected by an internet: The buyer, the party that wants to buy information, The server, the party that is selling information, The C-bureau, the party that verifies the credit of buyers.

We will call the information being bought a page transfer. For illustration's sake, we will think of the server as a website, although IPB is not restricted to billing for website information.

Rather than the"shopping cart"approach taken in EMB, we will assume that the server has a"pay area"that users can enter. Upon entering this area, any page transfer is charged at a given rate. (The buyer might even be charged according to the time that he spends in the area.) In the IPB, then, the buyer, the server and the C-bureau execute the following steps: 1. The server shows the buyer an area where all pages are for sale. The server shows the buyer the price of the pages (the price for browsing the pay area) and the payment terms. The server asks for confirmation that the buyer is willing to pay.

2. If the buyer confirms, he first enters his e-mail address, the server registers the address and allows him to browse the area.

3. The server starts transferring pages in the pay area to the buyer's browser and registers charges to the buyer's IP number. The server also sends the buyer's IP number and e-mail address to the C-bureau.

4. The C-bureau checks the IP number against its database of IP numbers with unpaid bills.

5. If the IP number is in the database, the C-bureau sends that information to the server, which registers it.

6. If the IP number is in the database, the server interrupts any current page transfer, and sends a message to the browser saying that the page request has been refused due to bad credit.

(As long as the C-bureau does not send a message saying that the address is in the database, the server continues to transfer pages and register charges to the buyer's IP number.) 7. When the buyer leaves the pay area, the server totals up the charges and executes an EVPM bet to determine what the buyer actually pays.

8. If the buyer loses the EVPM bet, the server sends a bill to his e-mail address.

9. If the buyer does not pay his bill, the server sends that information to the C-bureau, which registers an unpaid bill for that IP number.

Note, as with e-mail billing, we assume that no message from the C-bureau within a given period of time means that the IP number has no unpaid bills. OF course, it possible for the C-bureau to send the server a message saying the IP number has no unpaid bills.

Note also, we assume above that the server gives the buyer the benefit of the doubt by transferring pages even before finding out if the IP number has any unpaid bills. Of course, it is possible for the server to delay pages transfers until receiving a message from the C-bureau saying that the IP number has no unpaid bills.

An automatic step that the C-bureau can also perform upon registering that an IP number has an unpaid bill is to send a message to the network administrator for that IP saying the IP has an unpaid bill.

Some Extra Conveniences The server can post a running total of the charges the user sees at all times.

The server can enable a buyer to jump out of the pay area and back in without having the buyer re- enter his e-mail address. A grace period can be set during which the server assumes that a user from a given IP address is the same user who visited from that address at an earlier time. The server can wait until the end of the grace period to execute an EVPM bet.

The server can also enable the buyer to initiate an EVPM bet on the spot, if the buyer so desires.

The server can include means for checking whether a buyer has bought information from the server before. Thus, the server can save the buyer from entering his e-mail address by simply prompting him to confirm whether his e-mail address is the one that was previously registered for the IP number he is at.

Extra Check-Step for Shared IP Number Under the system above, multiple people can share the same IP number. They just have different e-mail accounts and are sent bills separately.

But, what if multiple people share the same IP number and one person does not pay his bill? Under the system above, all the users will be denied service. To overcome this problem, the C- bureau can verify the credit not just for an IP number but for the combination of an e-mail address and an IP number. Thus, the C-bureau would check not only if there was an unpaid bill that corresponded to the IP address but if there was an unpaid bill that corresponded to the IP and the e- mail address of the buyer.

Another problem crops up: a cheater can set up numerous e-mail addresses (even fake ones) for a given IP number and thus have a"clean"e-mail address at all times. To stop this cheat, the server actually can insist that if an unpaid bill is associated with an IP number then any buyer using that IP number must submit a deposit before he can get any information.

Aside On Charging for Service IPB can be used for more than just billing for information. It can also be used to bill for specific services. For example, IPB can be used to bill users for getting priority service in downloading webpages. From the point of view of billing, selling a service enhancement is no different than selling a piece of information. A price is set, the user can accept or reject it, and the billing is the same.

This use of the IPB should not be underestimated. To expand to the range of services offered by a server, an efficient method for microcharging people is necessary. Even a sum as small as 1/10 of a cent for priority in downloading a webpage can be of critical importance (consider the 1 million hits at 1/10 of a cent each is $1,000).

Further, with a way to do usage sensitive pricing, servers can implement better schemes for allocating network resources. The current first-come-first serve schemes are inadequate.

Moreover, enabling server owners to charge for service also enables them to pass a percentage of their revenue through to the owners of routers and fiber. Router and fiber owners can then enable server owners to deliver enhanced services, such as guaranteed paths for video delivery.

Credit Checking by Servers In the EMB and the IPB above, the server sends a credit check request to the C-bureau for every transaction. It would be more efficient for the C-bureau to send the server a database of bad credits so that the server could do real-time credit checking without relying on the C-bureau. The C-bureau could broadcast updates of the credit database periodically.

In a such a system, it is still essential that the C-bureau be a central credit bureau that servers report bad credits to.

We picture the sequence of message sending in a system where the C-bureau sends an initial credit database to servers and regular updates.

E-mail Billing With Server Credit Checking In this variation of EMB, there are still the same three parties: the buyer, the server and the C- bureau. They execute the following steps: 0. The C-bureau sends the server a credit database of e-mail addresses that have unpaid bills. The server stores the database.

1. (On a webpage) The server shows the buyer a button to be pressed (or other such means) for entering a request for an article; the server shows the buyer the price of the article and payment terms; the server asks for the buyer's e-mail address (we assume that by entering his e-mail address, the buyer agrees to pay for the article).

2. The buyer enters his e-mail address.

3. The server registers his request and his address.

4. The server checks his address against the credit database.

5. If the address is in the database, the server sends the buyer an e-mail message saying that his request has been refused due to bad credit, If the address is not in the database, the server sends the article to the buyer's e-mail address and registers a charge (for the article) to correspond to the buyer's e-mail address.

6. The server executes an EVPM bet to determine what the buyer actually pays.

7. If the buyer loses the EVPM bet, the server sends a bill to his e-mail address.

8. If the buyer does not pay his bill, the server sends that information to the C-bureau, which registers an unpaid bill for that address.

9. The C-bureau sends the server an update of the credit database, which the server uses to update its existing credit database.

IP Billing With Server Credit Checking In the IPB, then, the buyer, the server and the C-bureau execute the following steps: 0. The C-bureau sends the server a credit database of IP numbers that have unpaid bills. The server stores the database.

1. The server shows the buyer an area where all pages are for sale. The server shows the buyer the price of the pages (the price for browsing the pay area) and the payment terms. The server asks for confirmation that the buyer is willing to pay.

2. If the buyer confirms, he first enters his email address, the server registers the address (the server will also have registered the IP number that the buyer is at).

3. If the IP number is in the database, the server sends a message to the browser saying that the page request has been refused due to bad credit.

If the IP number is not in the database, the server transfers pages from the pay area and registers charges to the buyer's IP number.

4. When the buyer leaves the pay area, the server executes an EVPM bet to determine what the buyer actually pays.

5. If the buyer loses the EVPM bet, the server sends a bill to his email address.

6. If the buyer does not pay his bill, the server sends that information to the C-bureau, which registers an unpaid bill for that IP number.

7. The C-bureau sends the server an update of the credit database, which the server uses to update its existing credit database.

Centralizing Collections In EMB and IPB, the server executes EVPM bets and collects money from buyers. A central collection station performs these functions, as well as performing the function of a credit bureau.

Here, then, we present two billing systems using a central collection agency: one E-mail address based and the other IP address based.

Centralized E-mail Billing The first system will be called centralized e-mail billing (CEMB). In CEMB there are three parties connected by an internet: The buyer, the party that wants to buy information, The server, the party that is selling information, The C-station, the party that verifies the credit of buyers, executes EVPM bets, collects money from buyers and transfers it to server owners.

In CEMB, the parties execute the following steps: 1. (On a webpage) The server shows the buyer a button to be pressed (or other such means) for entering a request for an article; the server shows the buyer the price of the article and payment terms; the server asks for the buyer's e-mail address (we assume that by entering his e-mail address, the buyer agrees to pay for the article).

2. The buyer enters his e-mail address.

3. The server registers his request, his address, and a charge (for the article) to correspond to his address.

4. The server sends the address to the C-station and sends the corresponding charge and order ID data, such as the title of the article.

5. The C-station registers the charge and the order data and checks the address against its database of e-mail adreeses that have unpaid bills.

6. If the address is in the database, the C-bureau sends that information to the server, which registers it.

7. If the address is in the database, the server sends the buyer an e-mail message saying that his request has been refused due to bad credit, If the C-bureau does not send a message, within a certain period of time, saying that the address is in the database, the server sends the article to the buyer's e-mail address.

8. The C-station executes an EVPM bet to determine what the buyer actually pays.

9. If the buyer loses the EVPM bet, the C-station sends a bill to his e-mail address and alerts the server.

10. If the buyer pays his bill, the C-station alerts the server.

11. If the buyer does not pay his bill, the C-station registers an unpaid bill for that address and alerts the server.

(A problem with CEBM is that a sender often will not know for a long period of time whether the information sent arrived satisfactorily. Policies may be implemented whereby a charge is not sent to the C-station until the buyer confirms the successful delivery of the article.) Centralized IP Billing The second system will be called centralized IP billing (CIPB). In CIPB there are three parties connected by an internet: The buyer, the party that wants to buy information, The server, the party that is selling information, The C-station, the party that verifies the credit of buyers, executes EVPM bets, collects money from buyers and transfers it to server owners.

In CIPB, the parties execute the following steps: l. The server shows the buyer an area where all pages are for sale. The server shows the buyer the price of the pages (the price for browsing the pay area) and the payment terms. The server asks for confirmation that the buyer is willing to pay.

2. If the buyer confirms, he first enters his email address, the server registers the address and allows him to browse the area.

3. The server starts transferring pages in the pay area to the buyer's browser and registers charges to the buyer's IP number. The server also sends the buyer's IP number and email address to the C-bureau.

4. The C-bureau checks the IP number against its database of IP numbers with unpaid bills.

5. If the IP number is in the database, the C-bureau sends that information to the server, which registers it.

6. If the IP number is in the database, the server interrupts any current page transfer, and sends a message to the browser saying that the page request has been refused due to bad credit.

(As long as the C-bureau does not send a message saying that the address is in the database, the server continues to transfer pages and register charges to the buyer's IP number.) 7. When the buyer leaves the pay area, the server registers the total charge and sends that information and order ID data to the C-station.

8. The C-station executes an EVPM bet to determine what the buyer actually pays.

8. If the buyer loses the EVPM bet, the C-station sends a bill to his email address and alerts the server.

9. If the buyer pays his bill, the C-station alerts the server.

10. If the buyer does not pay his bill, the C-station registers an unpaid bill for that IP number and alerts the server.

Now, one more convenience that the C-station can offer is to do EVPM bets with the server owners, if the servers are owed only a small amount, say, under $100. Further, the C-station could assume the collection risk and could finance the receivables of a server. These conveniences, however, are just noted. They are not the point of this specification.

Anti-cheat Methods for EMB and IPB If a trusted third party is not being used to decide EVPM bets, the EMB and IPB require means for making these bets cheat-proof. We now describe some cheat prevention methods and protocols suited to the EMB and IPB. We will assume that the two parties engaged in a bet are the buyer and the server. (The methods also apply to bets between buyers and the C-station.) The methods apply to both EMB and IPB.

Audits One way to prevent cheating is to do audits. A neutral party would initiate hundreds of bets with a server and see how far the results deviated from the expected results. An auditing authority could then certify a server.

Definitions In the anti-cheat methods below, we add an RN server to the internet system. (In some of the methods below, an RN server is not essential. RN's can be supplied via a data storage medium such as a CD-ROM.) In the discussion below, we will use the term VIDRN, so let us define it. VIDRN stands for verifiably independently determined random number. By this we mean that an RN comes from an independent source, and that either party in a bet can verify that the other party in the bet has no control over the RN.

One way that an RN can be a VIDRN is for a neutral party to generate the RN at a time after the bet terms are set. For example, the terms of a bet can be set on Monday and the RN can be selected on Tuesday by, say, the California state lottery. We will call this a time delayed VIDRN.

Another way an RN can be a VIDRN is for a neutral party to generate a list of RN's and identify each with a number called a tag. The tag can be used to verify that the RN was generated by the neutral party. We will call this a tagged VIDRN.

Another way an RN can be a VIDRN is for a neutral party to create a pseudo-random number generating formula and identify it with a number. Different RN's can be created by plugging different seed values into the formula. We will call this a VIDRN formula.

Using Time delayed VIDRN's from a Central Source The server can be connected to a trusted source of time delayed VIDRN'seen RN server. The server can get a VIDRN per transaction from the RN server. However, it is more efficient to use on RN to decide multiple bets.

(There can be a mixing function so that the server does not win or lose all the bets. For example, the terms of a bet can say that an extra pre-specified number will be added to the time delayed VIDRN. The bets can have different extra numbers so that individual bet results will vary.) A protocol for using time delayed VIDRN's is: 1. The server shows the buyer: a) the charge, b) the bet amount, c) ID data for the RN server, d) the time the RN will be selected (the time must be after the time that the bet terms are presented).

2. The buyer acknowledges the terms of the bet.

3. The server gets the VIDRN from the RN server after the RN is selected.

4. The server determines the winner and alerts the buyer if he has lost.

Combined Input Methods A combined input method is a protocol whereby both parties contribute an input and the inputs are combined to create the RN. Here we discuss a few ways for doing combined inputs.

Using Tagged VIDRN Inputs A protocol follows that uses a tagged VIDRN input from the server: 1. The server gets a list of tagged VIDRN's from the RN server.

2. The server shows the buyer: a) the charge, b) the bet amount, c) the ID data for the RN server, and d) the tag for the VIDRN.

3. The buyer acknowledges the terms of the bet by entering an input.

4. The server reveals its VIDRN input (which corresponds to the tag) and combines its input with the buyer's input.

5. The server determines the winner and alerts the buyer if he has lost.

It is possible to automate this protocol further at step 3 by having the buyer's browser (or whatever program is communicating with the server) enter the buyer's input.

Using a VIDRN Formula In this combined inputs method, the server uses a VIDRN formula to generate the RN that decides the bet. The seed value comes from the buyer and so the server cannot influence the resulting RN.

If the buyer suspects cheating he can contact the source of the VIDRN formula to check what RN corresponds to the seed value he entered and the VIDRN formula that was used. The formula is known only to the server and the RN server. The buyer only needs to know the RN server ID data and the formula ID no. to verify that the RN generation is fair.

Thus, a combined inputs protocol for using a VIDRN formula is: 1. The server gets a VIDRN formula from the RN server.

2. The server shows the buyer: a) the charge, b) the bet amount, c) the ID data for the RN server and d) the tag for the VIDRN.

3. The buyer acknowledges the terms of the bet by entering a seed value.

4. The server plugs the seed value into the formula and gets the RN.

5. The server determines the winner and alerts the buyer if he has lost.

It is possible to automate this protocol further at step 3 by having the server get the seed value automatically from the buyer.

The seed value can be the user's e-mail address or IP number plus some other standard piece of information.

A second, standard piece of information is needed because otherwise the same seed value would yield that same RN every time. The key to the standard piece of information is that it cannot be controlled by the server. The standard piece of information can be the date of purchase, the data and a time interval, such as the hour of purchase. To digress a moment, the exact time of purchase is not a good seed value because it can be manipulated by the server, while a reasonably long time interval cannot. If a time interval is used, the server can post the time interval of the purchase, so that the buyer can verify that the time interval is correct.

Other standard pieces of information might be a URL of a webpage or the title of an article bought or the number of visits that a buyer has made to the server in a day. The main problem with any extra piece of information is to insure that the server cannot manipulate it and further that it is easy for the buyer to verify. This is not so easy to do. The number of times a buyer has visited a server can be subject to interpretation and argument. Likewise, the titles of articles can be manipulated. It might be best to use time interval inputs as the extra, standard pieces of information.