WO2001003048A1

WO2001003048A1 - A transaction system

Info

Publication number: WO2001003048A1
Application number: PCT/AU2000/000811
Authority: WO
Inventors: Steven Arthur Michener
Original assignee: Eventsmarket Pty Ltd
Priority date: 1999-07-06
Filing date: 2000-07-05
Publication date: 2001-01-11
Also published as: GB2368946A; AUPQ143499A0; GB0202537D0

Abstract

A transaction method, including receiving and communicating an order from a first party for a coupon at a price less than a predetermined value, the coupon having the value if an event occurs and no value if the event does not occur, receiving an acceptance of the order from a second party, issuing the coupon to the first party, decreasing an account of the first party by the price, and decreasing an account of the second party by the value less the price. The method allows event coupons to be established and traded on a communications network, such as the Internet.

Description

A TRANSACTION SYSTEM

The present invention relates to a transaction system for event coupons, and a transaction method executed by the system.

Most systems for handling betting transactions adopt a methodology which has applied to betting for centuries. Whilst the event bet upon may vary considerably, the transaction has traditionally involved one party placing a bet for an event to occur wάth another party or system operator and paying a certain amount to place the bet. The party that accepts the bet retains the amount until the event is determined, and if the event occurs the betting party will receive a winning amount that depends on the odds given for the event occurring. The accepting party retains the original amount if the event does not occur. The odds which determine the winning amount may be fixed at the time of the transaction or determined immediately prior to determination of the event by the accepting party, if the accepting party is for example a system operator.

Systems that operate as described above generally do not allow a betting party any further flexibility with regard to the transaction. For example, normally the betting party cannot determine the odds, nor is any subsequent trading of the transaction allowed. The transaction is also normally restricted to being between a betting party and a system operator for such systems.

In accordance with the present invention there is provided a transaction method, including: receiving and communicating an order from a first party for a coupon at a price less than a predetermined value, said coupon having said value if an event occurs and no value if said event does not occur; receiving an acceptance of said order from a second party; issuing said coupon to said first party; decreasing an account of said first party by said price; and decreasing an account of said second party by said value less said price. Advantageously, the order may be for a plurality of said coupon. Preferably the method also includes issuing a counter coupon to said second party, said counter coupon having said value if said event does not occur and having no value if said event occurs. Preferably if a plurality of said coupons are issued, the method involves issuing a plurality of said counter coupons corresponding thereto.

Advantageously, the method includes receiving and communicating an offer from a party to sell at least one coupon at a price. The price may be the same or different to that at which the coupon issued, and is determined by said party. The method may then include receiving acceptance of said offer from another party, increasing an account of said party by said price, and decreasing an account of said another party by said price.

Advantageously, once issued, the method allows coupons to be traded by parties prior to determination of said event. Parties may therefore trade coupons and/or counter coupons at various prices.

The present invention also provides a transaction method, including: receiving and communicating a request from a first party for a coupon at a price less than a predetermined value, said coupon having said value if an event occurs and no value if said event does not occur; receiving an acceptance of said request from a second party; transferring said coupon from said second party to said first party; decreasing an account of said first party by said price; and increasing an account of said second party by said price.

The present invention also provides a transaction method executed on a computer system connected to a communications network, including executing trades of event coupons between parties, said coupons having a predetermined value if an event occurs and no value if the event does not occur, said trades being conducted at prices less than said predetermined value.

The present invention also provides a transaction system for event coupons, including: a web server for communicating information to parties to trade event coupons, said coupons having a predetermined value if an event occurs and no value if said event does not occur; a transaction engine for executing transactions between said parties to complete trades, such as buying and selling of said coupons at prices less than predetermined value; and a database system for maintaining data on said parties, such as account data.

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a transaction system connected to a network;

Figure 2 is a block diagram of the transaction system;

Figure 3 is a flow diagram illustrating a coupon issuing process of the transaction system; Figure 4 is a block diagram of a coupon sale process of the transaction system; and

Figure 5 is a flow diagram of a determination process of the transaction system.

A transaction system for event coupons is provided by a computer system 2 which includes a database 4, as shown in Figure 1. The computer system 2 includes the components shown in Figure 2 and is able to communicate with equipment 10 of members or users of the system over a communications network 6 using standard communications protocols. The equipment 10 of the members may be a variety of communications devices, such as a computer, a telephone or an interactive television. The communications network 6 may include the Internet, telecommunications networks and/or local area networks. The components of the transaction system can be configured in a variety of ways. The components may be implemented entirely in software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer or hardware units distributed over various locations, some of which may require the communications network 6 for communication. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs). It will be apparent from the description of the transaction system and its operation below, that the most efficient implementation of the components of the computer system 2 is a software implementation. The computer system 2 includes web server software 12 to allow the computer system 2 to function as a web server which provides access to web pages created and stored on the system 2 for access by members. The web pages published by the web server 12 are dynamic and are populated by data provided by a transaction engine 14 of the system 2. Alternative methods of providing system displays and information can also be used, for example WAP pages for mobile telephones, and interactive voice response (IVR) systems. The transaction engine 14 accesses data from a database server 16 of the system 2 that accesses, maintains and stores data for the transaction system of the database 4. The transaction engine 14 also processes data received by the web server 12 and is able to store data on the database 4 using the database server 16. The database server 16 maintains data in the database on all of the members of the transaction system, including for each member:

(i) Personal details, such as contact and credit card details.

(ii) Coupons held, which includes coupons and counter coupons. (iii) Account information, such as an account balance, for the transaction system.

(iv) Coupons offered for sale.

(v) Coupons ordered.

The computer system further includes a payment system 18 which is able to communicate over the network 6 with institutions, such as banks, to obtain payment from and effect payment to members on the basis of changes in the balances of the accounts maintained by the transaction system. For example, the payment system 18 may execute EFTPOS transactions. As discussed below, the system ensures the account balances of members are always in credit. The web server 12, the database server 16 and the payment system 18 can be established utilising the tools provided by commercially available web server, database server and payment system software. The transaction engine 14 communicates with the other components 12, 16 and 18 to execute all of the transactions of the transaction system and provide the dynamic content for the web pages to display the state of the market for the coupons and provide access for members. The transaction engine 14 is configured so that the transaction system is able to establish an interactive trading market for the coupons and operate as described hereinafter. A coupon is the basic trading unit of the transaction system. A coupon has a set value if an event occurs and no value if the event does not occur. Another type of coupon is a counter coupon, which corresponds to a standard coupon, and has the set value if the event does not occur and no value if the event does occur. In other words, coupons are certificates that entitle the owner to a payment, say $ 1 , if it stipulates the correct outcome of an event, and entitles the holder to nothing if it does not. The coupons can therefore be considered to represent binary options, i.e. having two possible values. Coupons are only created when an order by one member is accepted by another. Once created, the coupons can then be bought and sold through the transaction system at a price, or odds, to be determined by supply and demand. The actual set or face value of the coupon never alters, and is described hereinafter as being $1.

An operator of the transaction system does not actively participate in the coupon trade, except in particular circumstances as described below, and simply administers the system and charges a percentage commission for each trade.

The transaction engine 14 generates coupons by executing an order process as shown in Figure 3. A member logged on to the system is able to order a coupon for an event at a particular price, and this order is received and processed by the transaction engine at step 20. The price will correspond to the odds selected by the ordering member, and Table 1 below shows the prices in cents, as they correspond to the odds for an event. The number of coupons ordered for the event and the price for each coupon is then communicated to all members logged on to the system by placing the details concerning the coupon order in a web page for the event with details of the corresponding counter coupons that are now for sale, at step 22. For instance, if the member wishes to purchase coupons at a price of 250 for the event then this is displayed, together with a display advising that counter coupons for the event at 750 are for sale. Another member can then satisfy the order by selling existing coupons for the event at the requested price of 250 or by buying the counter coupons at 750. The former is a coupon sale or transfer, described below with reference to Figure 4, whereas the latter results in issuance of ordered coupons. All web pages, displays or interactive interfaces may be generated using standard techniques, such as the use of applets, asp, wml, etc. Acceptance is monitored at step 24 by polling for selection of an acceptance icon and transmission of a form giving details of the transaction the other member wishes to execute. If it is determined at step 24 that account balances permit and the order is to be accepted by buying the corresponding counter coupons, this is processed by the engine at step 26 which causes the displays for the coupon order and the corresponding counter coupon sale to be removed from the page for the event. As the order has been accepted by the sale of corresponding counter coupons, the transaction engine 14 issues a number of new coupons corresponding to the order to the first member and issues the same number of counter coupons to the other member, at step 28. The accounts for the two members are decreased based on the number of issued coupons and counter coupons and their respective prices.

0 ø 0 0 <2

1 100.00 to 1 21 4.76 to 1 41 2.44 to 1 61 1.64 to 1 81 1.23 to 1

2 50.00 to 1 22 4.55 to 1 42 2.38 to 1 62 1.61 to 1 82 1.22 to 1

33.33 to 1 23 4.35 to 1 43 2.33 to 1 63 1.59 to 1 83 1.20 to 1

4 25.00 to 1 24 4.17 to 1 44 2.27 to 1 64 1.56 to 1 84 1.19 to 1

5 20.00 to 1 25 4.00 to 1 45 2.22 to 1 65 1.54 to 1 85 1.18 to 1

6 16.67 to 1 26 3.85 to 1 46 2.17 to 1 66 1.52 to 1 86 1.16 to 1

7 14.29 to 1 27 3.70 to 1 47 2.13 to 1 67 1.49 to 1 87 1.15 to 1

8 12.50 to 1 28 3.57 to 1 48 2.08 to 1 68 1.47 to 1 88 1.14 to 1

9 1 1.1 1 to 1 29 3.45 to 1 49 2.04 to 1 69 1.45 to 1 89 1.12 to 1

10 10.00 to 1 30 3.33 to 1 50 2.00 to 1 70 1.43 to 1 90 1.11 to 1

1 1 9.09 to 1 31 3.23 to 1 51 1.96 to 1 71 1.41 to 1 91 1.10 to 1

12 8.33 to 1 32 3.13 to 1 52 1.92 to 1 72 1.39 to 1 92 1.09 to 1

13 7.69 to 1 33 3.03 to 1 53 1.89 to 1 73 1.37 to 1 93 1.08 to 1

14 7.14 to 1 34 2.94 to 1 54 1.85 to 1 74 1.35 to 1 94 1.06 to 1

15 6.67 to 1 35 2.86 to 1 55 1.82 to 1 75 1.33 to 1 95 1.05 to 1

16 6.25 to 1 36 2.78 to 1 56 1.79 to 1 76 1.32 to 1 96 1.04 to 1

17 5.88 to 1 37 2.70 to 1 57 1.75 to 1 77 1.30 to 1 97 1.03 to 1

18 5.56 to 1 38 2.63 to 1 58 1.72 to 1 78 1.28 to 1 98 1.02 to 1

19 5.26 to 1 39 2.56 to 1 59 1.69 to 1 79 1.27 to 1 99 1.01 to 1

20 5.00 to 1 40 2.50 to 1 60 1.67 to 1 80 1.25 to 1

Table 1

Once issued following acceptance of a coupon order, the coupons can be traded up to determination of an event at any price determined by the members. To achieve this the transaction engine 14 executes a sale process, as shown in Figure 4, which begins at step 30 when the engine 14 receives and processes an order or offer to sell an existing coupon at a price selected by the member holding the coupon. The engine 14 then places the details of the offer in the web page for the event, at step 32, so that members can obtain a display on their equipment 10 of the best price at which coupons and counter coupons for the event are for sale. When the transaction message 14 receives an acceptance message, at step 34, relating to the sale offer from another member, the engine then processes this acceptance at step 36, and at step 38 transfers the coupons between the members' records and adjusts their accounts accordingly, if the account balances of the members permit. The account balance of the purchasing member is decreased and the account balance of the selling member is decreased.

The transaction engine 14 also executes a determination process, as shown in Figure 5. where for each event the engine 14 polls for a determination message advising that the determination of the event is imminent. The determination message may be entered directly by the system operator or received from an external system via the network 6. On determining that the determination message has been received at step 40, the transaction engine 14 generates messages and changes web pages to close all trading in the coupons for that event at step 42. Following determination of the event, the members' accounts are either increased or decreased based on the coupons and counter coupons that they hold for the event, at step 44. The members are then provided access to pages generated by the transaction engine 14 which communicate determination of the event and can also advise of any new events, at step 46.

Any given time, the account balance of a member is divided between cleared funds that are not committed to any existing coupons or counter coupons and funds that are associated with coupons or counter coupons and cannot be used by the member. Depending on configuration, the system may only allow the cleared funds to be visible to a member or both may be visible with a distinction clearly delineated. Funds associated with any coupons or counter coupons are not available for any transactions and are effectively frozen or held awaiting the outcome and determination of the events corresponding thereto.

The operation of the transaction system and the procedures executed by the transaction engine 14 are described below in more detail with reference to particular examples.

For example, for a Sydney versus Melbourne match in the Australian Football League a transaction system member could purchase Sydney coupons if they wish to back Sydney to win. Each coupon will pay $1 if Sydney wins and nothing otherwise. The coupon price might be 660, which corresponds to odds of 3 to 2.

When members view "trading floor" web pages of the system and do not see a coupon on offer at the price they are prepared to pay they may make an order or bid, say, for Sydney coupons at 64ø. The system will then post two "paired" orders: a buy order for Sydney coupons at 640 and a sell order for counter Sydney coupons at 360.

The transaction, as described above, can be completed by one of two ways: (a) If another member already holds Sydney coupons he or she may sell these to the first member at 640. In this case the 640 transfers to the second member and the coupon is then owned by the first member. (b) If a member does not own Sydney coupons he or she may buy the counter

Sydney coupons at 360. In this case the 640 from the first member and the 360 from the second member are retained by the system to redeem the coupon. On this transaction both a Sydney coupon and counter Sydney coupon are created.

The first member owns the Sydney coupon and the second member owns the counter Sydney coupon.

Where there are only two possible outcomes for an event, for example, in the case of a Sydney versus Melbourne football match where draws may counted as a "non-event" by the rules of the system, the name of the counter Sydney coupons can be changed to "Melbourne coupons", and traded as such.

Whichever way the transaction is completed the remaining "paired" order is cancelled.

The transaction system therefore acts essentially as a clearing house for coupon transactions.

For example, if Bob buys a coupon from Sally for 33ø, there is actually two transactions, Bob buys a coupon from the system for 330 and the system sells a coupon to Sally for 33ø. As all transactions are actually with the system, the buy and sell transactions will cancel out as far as the system is concerned. If Sally buys 100 Melbourne coupons from

Bob and sells 50 Melbourne coupons to Fred, she has, in effect, bought 100 coupons from the system and sold 50 coupons to the system, leaving her with 50 coupons. The system holds the "stakes" for coupons from the time they are created until they are "closed out" or the event is determined.

Table 2 below illustrates the correspondence between basic coupon and counter coupon pricing:

Coupon Counter Coupon

Price Cents Approx Price Cents Approx

Odds Odds

90 10 to 9 10 lO to l

89 9 to 8 11 9 to l

88 8 to 7 12 8 to l

86 7 to 6 14 7 to l

83 6 to 5 17 6 to l

80 5 to 4 20 5 to l

75 4 to 3 25 4 to 1

67 3 to 2 33 3 to l

50 2 to l 33 2 to l

Table 2

Anyone wishing to participate in the transaction system must become a registered transaction system member and each member has a cash account and a coupon account. The cash account records the amount of money a member has on deposit. When the member buys a number of coupons, an amount equal to the price times the number of coupons is debited from the account. When the member sells a number of coupons an amount equal to the price times the number of coupons are credited to the account. When an event is determined coupons are redeemed by the system by depositing funds into the account of the member holding the coupon. The coupon account is a list of the member's coupons. Commissions are deducted from members' cash accounts and costs associated with payments into and out of the cash account. If members want to buy or offer to buy coupons, they are unable to unless they have sufficient unrestricted funds in their cash account. They will not be able to sell coupons unless they have already purchased such coupons. The advantage of this is that members cannot buy or sell on credit and there is no risk of default. Members cannot commit resources, coupons or money, which are not in their accounts.

The system operator does not act as a principal in any transaction, except to create a market as described below. The operator simply provides the market and charges a commission for its use. The system operator cannot lose money as a result of the outcome of an event. Proper trust management of the member's accounts and the operation of the system ensures the members are properly paid.

The commission levied on each trade is a small amount per trade, such as one cent per coupon, or a percentage of the total purchase price. Either method may be graduated. The commission is payable by both the buyer and the seller. The commission could be levied entirely on the vendor, entirely on the purchaser or on both parties. It is well established economic principal that the selection does not matter as prices will adjust to give the same outcome anyway. For this reason, the system charges both parties half the commission to make it appear fairer. This stream of trading commissions is the income of the system operator. As the operator does not take a position as bookmaker and doesn't have any risk of default, this money is fully available to cover the costs of running the system and to provide profits.

The operator may however become involved in the coupon trade if it is necessary to create a market for an event. For instance, if the event is a horse race with 10 runners where only long odds are being offered for 9 of the runners, and none of the corresponding counter coupons are being purchased, the system operator can accept the counter coupons at no risk. This can be achieved by the system operator buying the same number of counter coupons, n, for each horse in the race across the board as long as the prices of each coupon for each horse add up to a total of $1 or more. That way if any of those horses corresponding to the counter coupons do actually win, the operator will need to pay out $1 xn, but the operator has collected greater than or equal to $1 xn.

In the following examples a commission of 50 per coupon per trade, on each side, is assumed. They all relate to one event, a football match between Sydney and Melbourne. All trading is in Melbourne coupons, coupons that pay $1 if Melbourne wins the match. When a member calls up the prices for a particular coupon, they see the best available bid and ask prices, with quantities. For example, for Melbourne coupons, the best order might be for 100 coupons at 250 and the best sell might be for 50 coupons at 260. These prices do not include the trading commission. The identities of the other parties are not disclosed. The total number of coupons at a particular price might be the accumulation of several orders. The 100 coupons at 25 ø might be two lots of thirty coupons and one lot of forty coupons. Members are not able to tell the breakdown and have no reason to know.

Members have two options. First, they can either offer to buy or sell coupons at the posted price. The transaction will be done automatically and the various accounts updated. If there are more than one lot of coupons at a particular price, the earliest transaction is the first to be filled. For example, assume that Sally offered 30 Melbourne coupons for sale at 250 at 1 :00 pm, Bob offered another 50 coupons at the same price at 1:01 pm and Fred offered another 40 at 1 :02 pm. If, Jane checks the price at 1 : 03 pm, she will see 120 coupons for sale at 250. If she buys 70 coupons, she will buy all of Sally's and thirty of Bob's coupons.

The second option is to offer to buy coupons at a lower or equal price than the current best price or to sell coupons at a price higher or equal to the current best price. In this case, the order cannot be executed right away. Instead it is maintained on the system until another member takes it out. Using the above example, the best offer for Melbourne coupons is 250. If Jane enters an offer to sell 50 Melbourne coupons at 250, the number of coupons she has to offer will be added to the outstanding total available at this price. If Jack offers to sell 40 Melbourne coupons at 26ø, they will be added to a transaction queue but they will not be displayed until all the coupons for sale at 260 have been sold. Unfilled orders remain on the system until the member withdraws them or they are taken out.

For a standard transaction example, there are two parties involved, Sally and Bob. The two parties put $ 100 into their accounts with the system.

Sally calls up the price for the Melbourne coupons. The following is displayed:

Sally buys 100 coupons at 270. She pays $27. She is charged a 500 transaction commission for making the trade, giving an overall cost of $27.50. Her cash account is debited $27.50 and her coupon account is credited with the 100 coupons. Of the $27.50, the system passes $26.50 to the vendor and keeps $1.

Bob calls up the display and decides to buy 100 counter coupons at 750. $75 is deducted from his account, and deposited in trust with the $25 from the seller in the system's trust account. In addition, he is charged a transaction commission of 500, giving him a net cost of $75.50. His cash account is debited with $75.50 and his coupons account is credited with the 100 counter coupons just created. The pair for Bob's counter coupons, 100 coupons have been paid for at 250 per coupon or $25 overall. In addition, the purchaser has paid a transaction commission of 500. Of this $25.50, the system puts $25 into the trust account and retains 50ø, as a commission.

Sally calls up her account. It is as follows:

Bob calls up his account. It is as follows:

The price display now reads:

If Melbourne wins the game, the Melbourne coupons pay off $1 each. Sally has 100 coupons and so she receives $100. Bob has 100 counter coupons so he receives nothing. The system takes $100 from the trust account and puts $100 in Sally's account. Sally now has $172.50 in her account and Bob has $24.50 in his account.

If Melbourne loses the game, the Melbourne coupons pay off nothing. Sally is left with $72.50. Bob has 100 counter coupons and so he receives $100 giving him a balance of $124.50. The operator has made $2, $1 from each transaction.

For an illegal transaction example, assume Jane has $100 in her account. She calls up the price for Melbourne coupons:

She offers to buy 200 counter coupons at 75ø. The system calculates this will cost her $150 but as there is only $100 available, Jane is informed that the transaction cannot be completed and nothing happens.

For a relatively complex transaction example, assume David has $100 in his account.

He calls up the price for Melbourne coupons:

He offers to buy 200 coupons at 270. As there are only 110 coupons available at this price, he buys all of them. The new price table is:

He decides that he still wants more coupons so he places an order for 90 coupons at 28ø. The new price table is:

His account will list 200 Melbourne coupons. The fact that he paid 270 for some and 28ø for others is irrelevant. They are the same coupons and all will pay off $1 if Melbourne wins and nothing otherwise.

Instead of buying the remaining 90 coupons at 280, David could have put up an offer to purchase at 270 to see if he could obtain some more coupons at this price. If he did this, the price table display is:

The orders for 258 coupons at 250 are still active but they will not become the leading order until someone sells 90 coupons to David at 270 or he withdraws this order. David has jumped to the front of a purchasing queue by posting the highest bid price but there is no guarantee that he will be able to buy coupons at this price. If he wanted to guarantee a purchase, he would have had to offer 280.

In this case, a restriction is placed on David's account to ensure that he has enough money available to honour his purchase should someone offer to sell to him. His member account reads as follows:

If someone sells 90 coupons to David, the $24.75 will be taken out of the restricted portion of his cash account, he will have 90 Melbourne coupons credited to his coupon account and the pending order will be removed from his account. If he choses to withdraw the order, the order will be withdrawn from the system and his account and the restriction will be lifted from his cash account. Of course, part of his order might be taken and the remainder will stay active. Pro rata adjustments are made to his accounts in this case.

In another example, Sally calls up the price for Melbourne coupons. The following is displayed:

She buys 100 coupons at 270 and pays $27.50, taking into account the trading commission. After a few days, the odds have shortened dramatically due to an injury to a Sydney player. She calls up the price table and gets the following:

She decides that the odds have shortened too much and so she sells her coupons at 430.

She receives $42.50, after the trading commission. This is a profit of $15. This ability to take a profit before the event is one particular advantage the system has over prior art betting system. Furthermore, if she was convinced that the odds were too short, she could buy counter coupons, allowing her to make more profits when the odds move back.

The transaction system can be applied to any event. In the sporting field, the market created by the system is most applicable to situations where there are only two possible winners. This makes it particularly applicable to team sports such as football, rugby, soccer and cricket.

Events where there are more than two outcomes are easily supported by the system but there must be at least some reasonable chance of the outcome occurring for there to be an effective market. For example, if coupons were to be offered on the French Open tennis, they would only be offered on the favourites, not all competitors. Of course, if an outsider makes the quarter finals, new coupons can be created for this player. It would also be easy to create coupons over multiple occurrences, such as both Sydney and Hawthorn winning in the same round. Another possibility would be coupons over sports awards, such as the Brownlow or Coleman medals.

The trading system, described above is easily transferable to any other market provided it meets a few conditions. These are that there must be an easily and objectively identifiable event on which coupons can be created. There must also be a reasonable chance of the event happening and not happening. If the chance of the event happening, or not happening, is too great, there will not be enough traders on one side of the market or the other. Given these restrictions, a whole range of possible markets can be established, as follows:

(a) Betting on the outcome of political elections. This has already occurred in the U.S. and it will bring in a different category of people from those who bet on sports.

(b) Betting on the outcome of awards, such as the best Actor Oscar. Again, this will bring in a different class of person.

(c) Betting on the advance or decline of a stock market index. This is likely to be popular as many investors are interested in the stock market but are not willing to take the risk of buying a future or a futures option. A simple coupon which pays off if the market goes up/down and doesn't if it goes the other way will give investors the ability to play the market in an easy to understand form with limited risk.

(d) Custom betting markets. It would be possible for members to set up a market on any event they choose. All that would be required is for a member to be willing to offer/buy coupons and for the event to be such that the result can be independently verified. For example, a member might be willing to buy/sell coupons on the results of their local football team. The market could be set up for them with very little effort.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. A transaction method, including: receiving and communicating an order from a first party for a coupon at a price less than a predetermined value, said coupon having said value if an event occurs and no value if said event does not occur; receiving an acceptance of said order from a second party; issuing said coupon to said first party; decreasing an account of said first party by said price; and decreasing an account of said second party by said value less said price.

2. A transaction method as claimed in claim 1, including issuing a counter coupon to said second party, said counter coupon having said value if said event does not occur and having no value if said event occurs.

3. A transaction method as claimed in claim 2, wherein said order is for a plurality of said coupon.

4. A transaction method as claimed in claim 3, wherein when said plurality of coupons are issued, a plurality of said counter coupon corresponding thereto are issued.

5. A transaction method as claimed in claim 1, including receiving and communicating and an offer from a party to sell at least one coupon at a sell price.

6. A transaction method as claimed in claim 5, including receiving acceptance of said offer from another party, increasing an account of said party by said sell price, decreasing an account of said another party by said sell price, and transferring said at least one coupon from said party to said another party.

7. A transaction method as claimed in claim 1 , including receiving and communicating an offer from a party to buy at least one coupon at a buy price.

8. A transaction method as claimed in claim 7, including receiving acceptance of said offer from another party, decreasing an account of said party by said buy price and increasing an account of said another party by said buy price and transferring said at least one coupon from said another party to said party.

9. A transaction method as claimed in claim 1 , including allowing trading in said coupons before determination of said event, and increasing the account of a party by said value for each coupon held by said party when said event occurs.

10. A transaction method as claimed in claim 2, including allowing trading in said counter coupons before determination of said event, and increasing the account of a party by said value for each counter coupon held by said party when said event does not occur.

11. A transaction method, including: receiving and communicating a request from a first party for a coupon at a price less than a predetermined value, said coupon having said value if an event occurs and no value if said event does not occur; receiving an acceptance of said request from a second party; transferring said coupon from said second party to said first party; decreasing an account of said first party by said price; and increasing an account of said second party by said price.

12. A transaction method as claimed in any one of the preceding claims executed by a server system connected to a communications network for communicating with said parties.

13. A transaction method executed on a computer system connected to a communications network, including executing trades of event coupons between parties, said coupons having a predetermined value if an event occurs and no value if the event does not occur, said trades being conducted at prices less than said predetermined value.

14. A transaction system having system components for executing the steps of the transaction method as claimed in any one of the preceding claims.

15. Transaction software stored on computer readable storage media having code for executing the steps of the transaction method as claimed in any one of the preceding claims.

16. A transaction system for event coupons, including: a web server for communicating information to parties to trade event coupons, said coupons having a predetermined value if an event occurs and no value if said event does not occur; a transaction engine for executing transactions between said parties to complete trades, such as buying and selling of said coupons at prices less than predetermined value; and a database system for maintaining data on said parties, such as account data.

17. A transaction system as claimed in claim 16, wherein said account data represents a cash account of funds for a party and a coupon account of coupons held by said party.

18. A transaction system as claimed in claim 17, including a payment system for executing payment transactions over said communications network to place funds in said cash account.