WO2003092838A2

WO2003092838A2 - System and method for processing sport events data

Info

Publication number: WO2003092838A2
Application number: PCT/GB2003/001778
Authority: WO
Inventors: Ram Mylvaganam; Neil Ramsay
Original assignee: Prozone Holdings Limited
Priority date: 2002-04-29
Filing date: 2003-04-25
Publication date: 2003-11-13
Also published as: WO2003092838A3; GB0209742D0; AU2003229940A8; AU2003229940A1

Abstract

Electronic data processing methods and apparatus which can be used to enable a gaming scheme based on an actual sporting event held over a playing area. Event data identifying at least one winning event is stored and stored actual event data and associated event location data corresponding to actual events that occurred during the actual sporting event is searched to determine the location in the playing area in which the at least one winning event occurred. From the event location data associated with the winning event data a zone identifier corresponding to a zone in the playing area is determined and the zone identifier is used to obtain an owner identifier associated with the zone so as to identify a person.

Description

Sports Data Processing System and Method

The present invention relates to electronic data processing systems and methods, and in particular to sporting data processing systems and methods for processing data relating to events from an actual sporting event.

During an actual sporting event a number of individual, definable events can occur which are characterisable by their location and also by their time of occurrence. For example, in a game of cricket, the position on the boundary crossed by the ball is associable with the event of a four or a six being hit. In a game of tennis, the position in the service box where the ball lands is associable with the event of a service. In soccer, or association football, the position of a player is associable with the event of a pass, free kick, shot, etc. Similarly in ice hockey.

The exact nature of an event will vary from sport to sport, but from the above discussion it will be apparent what can be considered an event and how it can be associated with a location in a playing area and also a time during a game, match or event at which the event occurs. A playing area can include a playing surface, such as a pitch, court, field or track, or any other area, such as a body of water, e.g. a pool for water polo, a lake for windsurfing, the sea for surfing, or even a space, e.g. a volume of sky for aerobatics or diving.

Sporting events have been used as the basis for betting and other gaming activity. However, such gaming activities trend to have been based on the occurrence of only a single easily identifiable event, such as the winner of a race or the scorer of a goal. Hence, there is a restricted number of events for which a participant may win and often a single 'winning' event, even though there are a large number of distinguishable events which could be used as 'winning' events .

Typically, event location data is not used for identifying winning events. 'Spot the ball' is one gaming activity in which the position of the ball within a picture is used. However, the location of the occurrence of an event on pitch is not used to determine the winning event.

Further, during a sporting event there can be hundreds of individual events of different types and occurring at different locations and different times, and generally in an unpredictable manner. Data relating to the nature and location of an event can be collected and recorded manually in real time, for instance by a spectator marking boundaries on a picture of a cricket pitch. However, the accuracy of the marked location is not verifiable. In a game of football there may be so many passes, and at a high rate, that it is not practicable to record all the potential events, their locations and ancillary data such as the person associated with the event. While some data may be recorded it will not necessarily be accurate, complete or in anyway verifiable, in order to ensure its veracity.

The present invention therefore relates to sporting event data processing systems and methods that can be used to enable gaming based on event locations. The invention also allows accurate and verifiable data to be generated and on the basis of which gaming can carried out.

According to a first aspect of the present invention, there is provided a electronic data processing method for enabling a gaming scheme based on an actual sporting event held over a playing area, comprising the steps of: storing event data identifying at least one selected event; searching stored actual event data and associated event location data corresponding to actual events that occurred during the actual sporting event and determining a location in the playing area associated with the at least one selected event; determining from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area; and determining using the zone identifier an owner identifier associated with the zone so as to identify a person.

The data processing method allows a person associated with a zone in which an actual sporting event occurred to be identified. The actual sporting event is the event which corresponds to at least one of a set of selected sporting events: ie special events from the set of all possible events which have previously been selected and which within the context of the gaming scheme can be considered 'winning' events. This data can then be used to enable a gaming scheme to be provided based on the location at which events occur during an actual sporting event .

The selected event can be a simple event or a compound event. A simple event is an event in which an event occurred at a single location, for example the position at which a pass is made or a shot is taken. A compound event has a single location associated with it but the location is an average of the actual locations over which the event occurred. Examples of compound events could be, the average position of a player who had the most shots on target, or the average position of the player who had the highest average speed. Any events which a player is involved in and which can have a specific or an average position determined can be used as simple or compound selected events. The method can include determining from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area for every selected event. In this way the persons associated with all the zones in which the selected events occurred can be determined.

The event data can include an event type identifier and an associated parameter which together define a selected event. The event type identifier indicates the nature of the event (e.g. a goal kick) and the parameter provides a qualifier (e.g. the fourth, all, the last) . This provides a simple way in which selected events can be defined.

The actual event data can be searched using the event type identifier. An event type identifier can be provided for every different type of event in the set of all possible events. This provides a simple way of determining which of the actual events correspond to selected events .

The method can include the step of receiving and storing contact data associated with a person. The contact data can be received over a telecommunications network, including a computer network, such as the Internet.

The method can include the step of transmitting a notification to the person using stored contact data. The notification can be automatically generated. The notification can be transmitted over a telecommunications network, including a computer network, such as the Internet

The method can include an auction process by which owner identifiers are associated with zone identifiers. The actual event data and associated event location data can be derived from video images of actual events. This allows accurate event data to be collected and also ensures that all events that occurred are recorded and are available to the method.

The actual event data and associated event location data can be read from a database table. The database table can store actual event data and associated event location data for every event that occurred in the actual match or game.

The method can be provided to a website. The website can access the method so that the results of the method can be made available to interested parties over the Internet.

According to a further aspect of the invention there is provided electronic data processing apparatus for enabling a gaming scheme based on an actual sporting event held over a playing area, comprising processing means in communication with storage means, the storage means storing event data identifying at least one selected event, actual event data and associated event location data corresponding to actual events that occurred during the actual sporting event, zone identifiers corresponding to zones in the playing area and owner identifiers associated with the zones, and the processing means being programmed to identify an owner identifier associated with a zone including a location associated with an actual event corresponding to at least one selected event.

The processor can be programmed to determine from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area for every selected event. The event data can include an event type identifier and an associated parameter which together define a selected event. The actual event data can be searched using the event type identifier .

The apparatus can include data receiving means for receiving contact data associated with a person. The data receiving means can be a part of a website.

The apparatus can include a messaging process for generating and transmitting a notification to the person using stored contact data. The messaging process can generate e-mail messages and/or SMS messages. The messaging process can be automatic .

The apparatus can include an auction process by which owner identifiers are associated with zone identifiers. The auction process can use a messaging service to notify auction participants of results of the auction.

The actual event data and associated event location data can be derived from video images of actual events .

The actual event data and associated event location data can be stored in a database table. Preferably actual event data and associated event location data for every event, of the set of all possible events, that occurred during the actual sporting event is stored in the database.

The apparatus can also host a website. The results generated by the apparatus can be made available to users via the website .

According to a further aspect of the invention, there is provided a method for collecting data for use by a data processing method enabling a gaming scheme based on an actual sporting event held over a playing area, comprising the steps of: collecting video images of all actual events occurring during the actual sporting event; analysing the video images to identify the type and location of every event; and storing data items identifying the type and location of every event in a database.

In this way accurate and complete event data can be obtained for use by the method and apparatus according to previous aspects of the invention.

According to a further aspect of the invention there is provided a data structure for storing data items useable by electronic data processing apparatus for use in a gaming scheme based on an actual sporting event held over a playing area, the data structure comprising a plurality of tables which between them store: event data items identifying at least one selected event; zone identifiers and associated owner identifiers; and at least one owner identifier associated with at least one selected event.

According to a further aspect of the present invention, there is provided a data structure for storing data items useable by electronic data processing apparatus for use in a gaming scheme based on an actual sporting event held over a playing area, the data structure comprising data items identifying the type and location of every event, of a set of possible events, that occurred during the actual sporting event.

According to a further aspect of the invention, there is provided computer program code executable by electronic data processing apparatus to provide method aspects of the invention or apparatus aspects of the invention. An embodiment of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

Figures la and lb respectively show a flowchart illustrating the steps of an auction phase and the steps of a gaming phase of a gaming scheme which can be enabled by data processing methods and systems of the invention; Figure 2 shows a schematic block diagram illustrating a data processing system of the invention;

Figure 3a and 3b respectively show a schematic block diagram illustrating the architecture of a part of the data processing system and a database used by the system of Figure 2;

Figure 4 shows a flow chart illustrating aspects of the auction phase;

Figure 5 shows a flow chart illustrating the purchase of a zone during the auction phase; Figure 6 shows a flow chart illustrating the selection of a zone;

Figure 7 shows a flow chart illustrating bidding for a zone;

Figure 8 shows a flow chart illustrating administration of bids;

Figure 9 shows a flow chart illustrating login and registration processes;

Figure 10 shows a flow chart illustrating zone purchase processes; Figure 11 shows a flow chart illustrating zone trading processes; and

Figure 12 shows a flow chart illustrating a zone identification process. Similar items in different Figures share common reference numerals unless indicated otherwise.

The data processing system and methods to be described can be used to implement gaming for a wide range of sporting events. The following detailed description of an embodiment of the invention will be made with reference to soccer, but it is not limited to the sport of soccer alone and it is considered to be apparent to a person of ordinary skill in the art how the present invention would need to be adapted to enable gaming for other sports and similar activities.

A general overview of the gaming scheme enabled by the data processing systems and methods of the present invention will be given before proceeding to a detailed description of the invention itself.

Figure la shows a flow chart 100 illustrating pre-season auction and trading activities. The gaming scheme is based on the ownership by participants of zones of a 'virtual' football pitch corresponding to a real football pitch. Before the football season starts, the zones of the pitch are acquired by participants through an auction process 110. A number of zones are made available for acquisition through an auction for a fixed period of time. After at least one zone has been acquired by a participant, the participant can offer that zone for sale to other participants in an optional zone trading step 112. The auction is continued until it is determined 114 that all the zones have been offered for acquisition through the auction process 110 at which time the pre-season auction is completed and ends 116.

Figure lb shows a flow chart 120 illustrating a gaming phase of the gaming scheme. Both prior to the start of the football season and during the football season participants may trade pitch zones which have been acquired either as a direct result of an auction or as a result of trading. This is illustrated by steps 112 and 122 in Figures la and lb respectively. For each match on the football pitch during the season, a set of match events is nominated 124 by users. For instance one set of match events could be: first goal, fourth corner kick, second throw in and tenth tackle. Each event is characterised by having a unique location on the pitch associated with the occurrence of that event.

Different sets of events are used for each match. Multiple sets of events are proposed for each match and then a particular one of the proposed sets of event is selected by user nominations as the set of events to be used.

The football match occurs on the actual pitch and event data relating to all of the events of a set of possible events is collected 126 using video cameras to record all areas of the pitch for the entire duration of the match and a computerised video data processing system to analyse the recorded video images. The set of possible events is predefined so as to cover events that could occur in a match, even if they do not occur in practice, and having definitions allowing the events to be clearly distinguished and identified. This results in a data set comprising the time and location on the pitch of each actual occurrence of all of the events from the set of all possible events.

The collected event data is then processed to collate 128 the raw event data into a suitable format. The nominated event data and collated event data are then processed to identify the locations on the pitch corresponding to winning events. The zones including those locations and the owners of the pitch zones in which the winning events occurred are then determined 130. The owners are then notified 132 of their win and resulting prizes. The process is then repeated for each match of the season 134 and participants have the opportunity to trade zones 122 during the season. At the end of the season, a new pre-season auction is initiated 136 according to the method 100 illustrated in Figure la.

Figure 2 shows a schematic diagram illustrating a computer system 200 according to the present invention. Unless indicated otherwise, the Figures are intended merely to illustrate the architecture of the computer systems and software and the functionalities supported to implement the invention. The different functionalities may be implemented on one or several physical computing devices and the division of functionalities is merely for the purpose of aiding the clarity of description.

The computer system 200 includes a server 210 hosting a website 215 accessible by a user 218 over the Internet 220, or any other suitable telecommunications system or network. The web server 210 hosting the website has access to secondary storage 225 storing data used by the system and the data required for processing during execution of website procedures . The pages of the website are viewed and accessed by the user using suitable browser software running on a personal computer, or any other Internet enabled device, such as a set-top box, digital television or WAP, G3 or similar telephone.

The website 215 is constructed and implemented using any suitable Internet technology, such as HTML, XML, Java Script or any other such technologies, or later technologies, as will be appreciated by a man of ordinary skill in this art. (Java is a trade mark of Sun Microsystems Inc, which may be registered in some countries). Computer system 200 also includes a gaming engine 230 which is executed on the web server 210, or could be executed by a separate computer in communication with the web server over a suitable network connection. The gaming engine also has access to secondary storage 225.

A messaging service 240 is also provided by which winners are notified of results 242. Winners are notified using a number of telecommunications technologies, such as, and for example, by e-mail, by Short Messaging Service (SMS) ("texting") or by post.

Figure 3a shows a schematic diagram of the architecture 300 of the processing and operations provided by the web server 210 to the user 218 via the website 215. Processes to handle login and/or registration 302, zone bidding 304, zone trading 306 and payment 308 are provided. An auction engine 320 provides processing for the zone bidding and zone trading processes and has access to secondary storage 225. Secondary storage 225 includes a database 310 comprising a number of tables of data used by the website processes, the gaming engine processes and the results messaging processes as will be described in greater detail below.

Database 310 includes a number of tables storing data items which are used by the website, results messaging and gaming engine processes. Each table has a plurality of entries and each entry has a number of fields storing different types of data items. A Bidders table 312 stores data items relating to bidders for each zone of the pitch. It includes a number of types of data items, including: a BIDDER_REF item providing a reference number for a bidder; a BIDDER_USER item providing a username for the bidder, a BIDDER_PASSWORD item providing a password for the user; and data items providing full name and contact details, including postal and e-mail addresses .

A Users table 314 has a number of fields storing data items the same as those stored in the bidders table, but with different variable names . The users table stores information about customers who have successfully obtained a zone rather than merely participated in the auction as a bidder. A CUSTOMER_REF item indicates the reference number for the zone, a CUSTOMER_BIDDER_REF item provides a bidder reference, and user username, password and name and address data items are also provided.

A Bids_Data table 320 stores data items used to keep track of actual bids (reserve bids) submitted by users. The data item types provided include: BIDS_REF providing a bid reference; BIDS_ZONE_REF identifying the zone that is being bid for; BIDS_BIDDER_REF identifying the person bidding (and corresponding to the BIDDER_REF data item from the Bidders table) ; BIDS_RESERVE_BID giving the amount of the reserve bid submitted by a bidder who enters the value when he makes the initial bid in the appropriate currency; BIDS_BID_DATE giving the date the bid was submitted; and

BIDS_TRANSACTION_REF which is a reference passed bake to the system by a credit card authorising company as part of a bid payment transaction.

A Bid_List table 322 stores data relating to all bids that have been made so as to allow for auditing. It includes the following data types: BID_REF providing a bid reference; BID_ZONE_REF identifying the zone being bid for; BID_BIDS_REF which is a reference to where the bid has originated from in the Bids_Data table; BID_AMOUNT indicating the amount that the bid was for; and BID_DATE indicating the date that the bid was made. A Zones table 324 stores data items relating to each of the zones and includes data items of the following types: ZONE_REF providing the reference number for a zone; ZONE_BID_INCREMENT indicating the increment value for bids for the zone; ZONE_START_PRICE indicating the auction starting price for bids for this zone; ZONE_RESERVE_PRICE indicating the auction reserve price for the zone; and ZONE_AVAILABLE indicating the whether the zone is available for bidding or not .

A Zone_Offer table 326 stores data relating to offers for the purchase of zones, and includes the following data item types: OFFER_REF which is a reference number for the offer; 0FFER_ZONE_REF which is a reference number for the zone for which an offer has been made; OFFER_CUSTOMER_REF which is a reference number for the customer that made the offer; OFFER_AMOUNT which is the amount of the offer for the zone; OFFER_TEXT which is a free text entry; and OFFER_DATE which is the date when the offer was made.

A Zone_Sales table 328 stores data relating to actual sales of zones, and includes the following data items: SALES_REF which provides a reference number for the sale; SALES_CUST_REF which provides a reference number for the customer involved in the sale; SALES_ZONE_REF which is a reference number for the zone involved in the sale; SALES_AMOUNT which is the amount the zone is sold for; SALES_TEXT which is a free text entry; and SALES_DATE which is the date of the sale.

A Nomination table 330 includes data relating to all the nominations made for sets of winning events. It includes data items of the following types: NOMINATION_REF providing a reference for the nomination; NOMINATION_CUSTOMER_REF providing the reference for the customer making the nomination; NOMINATION_OPTION indicating which of the sets of winning events has been nominated; NOMINATION_DATE indicating the date and time of the nomination; and NOMINATION_MATCH indicating the date of the match that the set of events has been nominated for.

A Winzone_Events table 332 stores a list of all events that occurred during a particular match of the type corresponding to the winning events, but not just the actual winning events. For example if the eighth tackle is a winning event, then the winzone events table stores data items relating to all the tackles that occurred during the game. It includes the following data types : WINZONE_REF providing a reference for a winning zone; WINZONE_FRAME which indicates the number of the video frame in which the event occurred and provides timing information; WINZONE_EVENT which is a code number for the event that occurred; WINZONE_PLAYER which provides an indication of the player or players involved in the event; WINZONE_HALF which indicates whether the event occurred in the first or second half of the game; WINZONE_CO-ORDINATE which provides the cartesian co-ordinates of the location of the event on the pitch in metres from an origin; WINZONE_DATE which indicates the date of the match; and WINZONE_DESCRIPTION which provides a text description of the type of the event.

An Events_List table 334 stores data relating to the set of all possible events recognised by the system. It includes data items of the following types: EVENT_CODE which is a unique code number for each event; and EVENT_DESCRIPTION which is a description of the nature of the event. It is used as a lookup table at various times by the data processing system. A Winners_List table 336 stores data relating to the winners identified by the system, and includes the following data types: WINNER_REF providing a reference number for a particular winner; WINNER_CUST_REF which is the reference number for the customer or user who is the winner; and

WINNER_WINZONE_REF which is a reference for the winning zone for this winner and corresponds to the WINZONE_REF item from the Winzone_Events table.

A This_Weeks_Events table 338 stores data items relating to the set of events that have been nominated as winning events for a particular match and is used as a lookup table. It includes fields for storing the following data items: EVENT_CODE, which identifies the type of event and correspond to the short codes used in the Event_List table; EVENT_PARAM is a parameter, where applicable, which qualifies the event; and EVENTS_BIN is an identifier for the set of winning events that has been nominated.

Figure 4 shows an overview flow chart 350 illustrating the steps carried out by a user or customer 218 in purchasing a zone over the Internet during the pre-season zone auction phase and illustrating step 110 of Figure la. The user 218 browses 352 website 215. The user selects a zone 354 and is presented with information on that zone. The user then decides 356 whether to place a bid. If the user decides to place a bid for that zone then the website determines 358 whether the user is registered, and if not initiates a registration protocol 360 under registration process 302.

If the auction engine determines that the bid is successful, then the user confirms 362 their bid and the payment process 308 handles payment for the zone via a credit card transaction 364. If the payment is authorised 366 then the purchase of the zone by the user is confirmed 368. Otherwise, the details of the credit card are checked or the opportunity to enter new card details is provided at step 370 and the option to have the transaction details re-issued is provided at step 372.

The option of bidding for another zone 374 is provided after which the user can exit from the auction process 376 and finally from the website at step 378.

Figure 5 shows a flow chart 380 illustrating the process of bidding for and acquiring a zone during the zone auction in greater detail. Various features of the process are provided by the login/registration 302, bidding 304, payment 308 processes and auction engine 320. The user 218 is provided with a graphical representation of the virtual football pitch. The entire playing surface area of the football pitch is covered by a plurality of individual zones which are also organised into different regions, e.g. the penalty area. The code displaying the virtual pitch has access to zone references for every zone from the zones table .

The user browses a map of the pitch 382 to select a zone for which he wishes to place a bid. The user enters an indication of a selected zone, for example by placing a cursor over the graphical representation of the pitch and transmitting a control character to the computer. Bidding process 304 recognises the select zone command and identifies the zone which has been selected.

The auction engine then reads bid information from the Bids table of the database relating to the current status of the bid for that zone, and uses the zone reference, present bid value, minimum incremental values from the Zones, Bid_Data and Bid_List table, to display the present bidding data for the zone to the user 386. The user is then presented with the option of placing a bid 388 for the zone or not. If the user places a bid, then it is determined 340 whether the user is registered with the website. Whether the user is registered can be determined by a login protocol or alternatively by detecting 389 the presence of a cookie placed on the user's machine as a result of previously registering. If the user is determined not to be registered then the registration process 302 is invoked and the user is registered.

The user then enters a bid for the zone 392 and the bidding process 304 of the auction engine determines 394 whether the bid is successful. The bid data entered by the user is stored in the Bid_Data and Bid__List tables. If it is determined that the bid is successful then payment process 308 is invoked to authorise 396 the bidders credit card for eventual payment for the bid should that bid prove to be ultimately successful. After completion of authorisation of the bid, the bidding process 304 up-dates 398 various aspects of the bid data in a bid house keeping process to be described below. Finally a summary of the transaction is displayed 400 to the bidder, using the zone reference, bid amount, transaction reference (BIDS_TRANSACTION_REF) from the Bids Data table which is returned once the credit card has been authorised, and bidder contact details from the Bidders, Bid data and Bid List tables.

Figure 6 shows a flow chart 410 illustrating the bid selection and display stages of Figure 5 in greater detail. A graphical representation of the virtual pitch is displayed 422 to the user as described previously. The pitch is split into 10 regions each of which contains 700 zones. The user can then select 424 a one of the regions, such as the penalty area. The website then displays 428 all of the zones in that region and accesses the database 310 when requested to generate and display 428 the current status of bids for selected zone in the selected region as described above. The user can input an indication 430 of a different selected region of the pitch at any time.

If the user inputs 432 an indication of a particular selected zone, then the web server accesses the database 310 to display 386 the current bidding information for the selected zone as described above so that the user can determine whether they wish to place a bid for the selected zone. The user can input an indication of a selection 436 of a different zone from the region at any time so as to have the current bid information for that zone displayed.

In order to actually place a bid 342, then a user must be registered with the website. Figure 7 shows a flow chart 490 illustrating operation of the login and/or registration process 302. When a user first accesses the website, the login/registration process 302 determines whether a cookie has previous been installed on the users machine. If a cookie is present then the user identity data is retrieved from the cookie and used to access the users table entry for the user to provide login details 494 for the user. If the user is determined to be authorised 496, as the users identity data from the cookie is found 494 to correlate with the username and password as stored in the users table, then the user id (CUSTOMERJEF) from the user table allows an active session for the user to be initiated so that the user is now authorised to make a bid.

If the user authorisation fails 496 then the user is prompted to enter a username and password 502 and if the password is found to match 506 that for the username as stored in the user table 310 then the user is authorised and an active session is created with the user id. If the username is determined 508 not to be correct, then the user is prompted to re-enter 502 the user name and password. If at 492 the user is detected to be a new user by virtue of the absence of any cookie, then the user enters the registration option and is directed to a new user login page 510. The user inputs 512 various details such as their name, user name, password, address, telephone numbers and e- mail address. The user name and password are checked 514 to ensure that they are more than 6 characters long and also, by reference to the bidders table, that the same user name is not already in existence, ie that it is unique. If the username and password are acceptable, then the user details are registered 520 in the bidders table 312, and a cookie is added 522 to their machine if requested.

If the username is not determined to be unique at step 516, then the user is prompted to enter 512 a new username which is again checked 514. If the user name is determined 516 to be acceptable then the process proceeds as described above. The login details from the cookie file are used to authorise 496 the newly registered user.

If a registered user forgets their password then they can request a reminder at step 502 and enter their username at step 526. The user name is used to retrieve the users e- mail address and password from the bidders table and a reminder of the users password is e-mailed 530 to the user.

A registered user (bidder) can now place a bid 342 which is processed according to the bid process 304 illustrated by flow chart 440 of Figure 8. Current bid information (as described previously) for the selected zone is displayed 386 to the user. The user then inputs their bid 444 and the bid is checked 446 by calling a bid checking process carried out by a Java Script routine 446 interpreted by the user's web browser software.

The auction uses a proxy bid method which allows bidders to enter a reserve bid amount. The bid checking process 446 determines the new status of the zone being bid on. It takes a new bid value (i.e. the bid value entered by the user at step 392/444) and cross-references that with any active reserve bids and determines how many times the value of the zone needs to be incremented until the maximum bid value has been reached.

When a new bid arrives for a zone (eg Zone A1F4), it has to be greater than what the current bid for the zone is. For instance if the current bid for Zone A1F4 is £40, then with a zone increment of £5, the minimum amount for the next bid to be successful will be £45. When a new bid is made, the user enters an amount providing a RESERVE_BID which is the maximum bid that they are prepared to make for the zone. If a user indicates that they are prepared to pay up to £70 for Zone A1F4, then that user's bid is accepted as it is greater than the current bid value of £40 and so supersedes it to becomes the current bid.

The bid checking or bid housekeeping routine checks to see if there are other bidders who also have a higher RESERVE 3ID than £45 for Zone A1F4. If, for example, there are two other users with RESERVE_BIDs of £50 and £55, then the housekeeping process increments the £45 by the £5 increment for the zone, so that the value becomes £50, and then £55 and finally stops at £60 as there is nobody else with a RESERVE_BID more than £55. In this way £60 becomes the current bid for Zone A1F4. Active reserve bids are those reserve bids which at any time are greater than the current bid value. The bid housekeeping/checking routine is described in greater detail below with reference to Figure 10.

If it is determined 448 that the bid is valid, then the zone reference and bid amount are stored in the Bid_Data and Bid_List tables for subsequent processing.

It is then determined if the bid is invalid 448 and if it is less than the current bid 452 for the zone, or if the bid data was un-recognised 454 by the bidding process 304. If the bid was too low then a message is generated and displayed 456 to the user together with information on the rules and instructions 458 relating to the bidding process. If the bid is un-recognised 454 then a message that the bid is invalid is generated and displayed 460 and bid rules and instructions displayed 458 to the user.

Figure 9 illustrates the payment authorisation process 308 used to handle the authorisation of payment for ultimately successful bids. Payment for a zone is only actually made at the end of the auction, however the method obtains authorisation to obtain payment for a bid, once that bid is currently successful, in order to prevent bidders subsequently pulling out. Once a successful bid has been made payment authorisation processing 540 occurs based on the bid amount 542 obtained from the database. Payment information is displayed 544 to the user by a purchase screen summary page and the user and selects and enters 546 a currency in which to pay. A currency convertor process 548 automatically generates an equivalent amount for the bid value using current currency exchange rate data items 550. A new summary screen is generated and displayed 552 including the equivalent amount in the chosen currency. If it is determined that the user does not want to proceed with having payment for the bid authorised, then the user is returned 556 to the bidding screen. If the user indicates that they do wish to purchase the bid, then the users account details are obtained and displayed 558 together with details of the bid amount.

The user' s credit card data is then transmitted to an online secure merchant banking facility and the card details are input 560 to an authorisation procedure 562. If it is determined 564 that the results of the authorisation procedure were negative, then a message is displayed 566 to the user so that their credit card details can be re- submitted or changed. If the transaction was authorised then the user is notified 568 of a successful purchase of the zone and the payment process terminates, although actual payment for the zone is deferred until the auction is completed so that each zone is only actually paid for once.

Figure 10 illustrates various administrative zone "house keeping" 298 or bid checking processes 446 carried out by the web server both after payment for a successful bid has been authorised and during the bidding process 394. Active bidders for the zone are determined using data from the Bid_Data, Bid_List, Bidders and Zones tables and the bid checking procedure 446 is used to insert the bid amount, bidder reference and time stamp entry in the Bid_List table, until a highest current bid for the zone is arrived at.

Firstly, the customer reference, bid amount and zone reference relating to the successful bid are registered 464 into the Bid_Data table and Bid_List table. The Bid_Data table is used to keep track of all bids and the bid value that a bidder is prepared to go up to. The Bid_List table is used to store details of bids as they happen. The value of the bid written into the Bid_List table supercedes all previous bids and is the current highest bid for that zone.

It is then determined 468 using the Bid_Data table whether somebody else has placed a higher reserve bid for the particular zone than the current bid by comparing the current highest bid value with a reserve bid value stored in the Bid_Data table. If there is a higher reserve bid, then that bid value is passed 469 to be used to calculate a new highest bid. The higher reserve bid has a bid increment value added to it 470 (derived from the Zones table) and this bid becomes the new highest (active) bid 472 (ie new current bid) for the zone and is stored in the bid list table, together with its associated data.

If there is nobody with a higher reserve bid, then the current bid is passed 474 and has a bid increment value added to it 476 using the bid increment data item from the Zones table. This bid value is then identified as the new highest (active) bid 472 (ie the new current bid) and is stored in the Bid_List table, together with its associated data .

The bid checking routine 446 operates for as many iterations as are necessary based on the existence of potentially acceptable bids in the Bid_Data table until the highest bid for the zone has been identified. The BID_REF data item in the Bid_Data table is the unique identifier for a bid and is entered into the Bid_List table together with the amount, time stamp and identity of the zone. The bid checking routine determines, whenever a new bid arrives, if there are any active reserve bids that outbid the new bid and if so the highest is inserted in the Bid_List table. At the end of the process there is only one active reserve bid (current bid) left, which is the highest bid that has been entered .

Once the new current bid has been established 472, then all the bidders other than the owner of the current bid are identified 474 using data in the Bidders and Bid_Data tables, so as to inform them that their otherwise valid bid for the zone is not the highest. Messages are assembled and dispatched to all the unsuccessful bidders by e-mail or SMS 402. Contact details for the owner of the current highest bidder are also obtained 484 from the Bidders table and they are notified that they are the owner of the current highest bid 404. This completes the bid housekeeping procedure, the result of which is that a current highest bid for a zone is identified, irrespective of whether the zone reserve bid price has been exceeded, and the unsuccessful bidders and successful bidder have been notified accordingly.

At the end of the period during which a zone is available in the auction, for example one week, the auction for that zone is closed, and payment from the bidder with the current bid is completed so that they are the owner of the zone and their details are copied into the Users table of the data base. The Users table contains actual zone owners rather than mere bidders.

Figure 11 shows a flow chart 570 illustrating the selling and buying parts of an optional trading process 306. The process determines 572 whether a user who owns a zone wishes to place their zone on a virtual "trading floor". The user enters a sale price 574 for their zone. The sale price and associated data items are stored in the zone sales table 580 and the zone is made available for purchase on the trading floor . If a user wishes to purchase a zone then they enter 582 an indication of the zone selected for purchase. The webserver determines 584 whether the selected zone is available for sale by checking the appropriate ZONE_AVAILABLE field in the Zones table 324. If the zone is available, then the user is presented with the zone sale price in the trading floor and can purchase the zone using an electronic payment facility.

According to the above methods, the zones for the football pitch are initially auctioned and the owners of the zones may then place the zones onto a virtual trading floor so that they may be purchased by other users. Trade in zones can continue both during the pre-season period and during the football season itself. The website therefore has a database containing data items detailing the owners of all of the zones purchased during the auction phase. How the data gathered via the website is used by the gaming engine will now be described.

As illustrated by the flow chart shown in Figure 12, the gaming engine 230 includes a routine 600 to determine the owners of winning events. Firstly, the set of winning events that has been nominated for the match are determined using the Nominated Events table. During a nomination phase 124, users nominate which of several sets of winning events they want to be the winning events for a particular match. The sets of winning events are displayed to the users on a website over the internet and the users choose their preferred set of winning events. The selection data is stored in the Nominations table and a script is run to determine which of the sets has been nominated as the set of winning events for the match.

The Nominated Events table includes an indication of the date of the match and so all the nominations for the match concerned are identified by the script and the set of winning events identified as that having the greatest number of nominations. The set of winning events so identified is then used to extract winning zones which are the stored in a Winning_Zones table which are cross referenced with the owners of the zones to determine who the winners are.

Events list table 334 is a table that contains short codes for the event names and acts as a look uptable. An EVENTS_CODE data item is the short code for each of all the possible events. An EVENT_DESCRIPTION data item gives the text description of the event corresponding to the short code .

The nominated set of winning events is used to populate the This_Weeks_Events table. For instance the nominated set of winning events could include the events of: the last goal kick; the fifth dribble; and all clearances. The first of these events is indicated in the This_Weeks_Events table by the event code for goal kicks together with parameter 0 indicating the last of such events. The event code for dribbles would have the parameter 5 associated with it, indicating that the winning event is the fifth dribble. The event code for clearances would have the parameter -1 associated with it indicating that all clearances are winning events .

The winning events are loaded 602 from the This_Weeks_Events table and the routine 600 then searches 606 through a table of actual match events 608 to find all events matching the events loaded from the events list. The table of actual match events contains details of every event out of the set of possible events that actually happened during a real football match. The data is obtained using a computerised data processing system which is used to analyse video images covering every part of the football pitch for the entire duration of the match. Video images of the same part of the pitch are captured from cameras at different positions so that the position of an event can be determined by reverse triangulation . Also as the whole match is recorded it is possible to identify each and every event that actually occurred with accuracy.

The Match_Events_Table 608 includes an entry for every event that occurred and fields for storing data items of the following types: event code, identifying the type of event and the same as the event codes used in the events list table; an indication of the half of the match that the event occurred in; the number of the video frame in which the event occurred, which provides timing information; the x and y co-ordinates on the pitch at which the event occurred; an identification of the player or players associated with the event (eg who made the pass); any other information associated with the event (eg who was passed to) ; and the match date.

For each winning event from the This_Weeks_Events table 338, the match events table is searched 606 based on the event code and parameter to find the event in the match that corresponds to the winning event. For instance, and using the above examples, the table is searched for all goal kicks that occurred until the last goal kick is identified. When the actual event corresponding to the winning event is found, then the position on the pitch data for that event and the associated data 312 are copied 610 from the match events table into the Winzone_Events table 332, which is similar to the match events table.

The routine then uses the x, y co-ordinate data to determine 612 in which of the zones covering the pitch the co-ordinate data lies. Once the zone has been identified then the reference for that zone is written 314 to the WINZONE_REF field for that event. In this way the zone in which a winning event occurred has been identified. The routine then determines 316 if all the winning events in the

This_Weeks_Events table have been searched for and if not continues searching for the next type of winning event, eg dribbles .

After searching for winning events has been completed, the routine carries out an archiving step 318, in which the data for all the actual events for a match are written to an archive table having the same structure as the Winzone_Events table for quality control, market research and audit trail purposes. The routine then identifies winners 614 by obtaining the reference for each winning zone from Winzone_Events and looking up the owners of those zones in the users table. The Winners__List table is then populated with a reference for the winner, the winner's user reference and the winning zone reference.

The results service 215 can then notify each winner by accessing the winners list table and the users table to obtain contact details. The results service also determines what prize each winning event corresponds to from a table detailing the prize associated with each of the winning events in the this weeks events list. In this way winners are identified 130 and notified 132 of their prizes.

After the winners for a match have been identified and notified, the same process is used for the next match using the next set of winning events as determined by a next nominations process. This continues for each match of the season until the season is completed at which time a new pre-season auction process is carried out. It will be appreciated that some of the features described above are merely preferred and some of the sequences of actions can be varied.

Claims

CLAIMS :

1. An electronic data processing method for use in a gaming scheme based on an actual sporting event held over a playing area, comprising the steps of: storing event data identifying at least one selected event; searching stored actual event data and associated event location data corresponding to actual events that occurred during the actual sporting event and determining a location in the playing area associated with the at least one selected event; determining from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area; and determining using the zone identifier an owner identifier associated with the zone so as to identify a person .

2. A method as claimed in claim 1 and including determining from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area for every selected event.

3. A method as claimed in claim 1, in which the event data includes an event type identifier and an associated parameter which together define a selected event.

4. A method as claimed in claim 3, in which the actual event data is searched using the event type identifier.

5. A method as claimed in claim 1, and including receiving and storing contact data associated with a person.

6. A method as claimed in claim 5, and including the step of transmitting a notification to the person using stored contact data.

7. A method as claimed in claim 1, and including a auction process by which owner identifiers are associated with zone identifiers .

8. A method as claimed in claim 1, in which the actual event data and associated event location data are derived from video images of actual events.

9. A method as claimed in claim 1, in which the actual event data and associated event location data are read from a database table.

10. A method as claimed in claim 1, in which the method is provided to a website.

11. Electronic data processing apparatus for use in a gaming scheme based on an actual sporting event held over a playing area, comprising processing means in communication with storage means, the storage means storing event data identifying at least one selected event, actual event data and associated event location data corresponding to actual events that occurred during the actual sporting event, zone identifiers corresponding to zones in the playing area and owner identifiers associated with the zones, and the processing means being programmed to identify an owner identifier associated with a zone including a location associated with an actual event corresponding to at least one selected event.

12. Apparatus as claimed in claim 11, in which the processor determines from the event location data associated with the selected event data a zone identifier corresponding to a zone in the playing area for every selected event.

13. Apparatus as claimed in claim 11, in which the event data includes an event type identifier and an associated parameter which together define a winning event.

14. Apparatus as claimed in claim 13, in which the actual event data is searched using the event type identifier.

15. Apparatus as claimed in claim 11, and including data receiving means for receiving contact data associated with a person.

16. Apparatus as claimed in claim 15, and including a messaging process for generating and transmitting a notification to the person using stored contact data.

17. Apparatus as claimed in claim 11, and including an auction process by which owner identifiers are associated with zone identifiers.

18. Apparatus as claimed in claim 11, in which the actual event data and associated event location data are derived from video images of actual events.

19. Apparatus as claimed in claim 11, in which the actual event data and associated event location data are stored in a database table.

20. Apparatus as claimed in claim 11, and which also hosts a website.

21. A method for collecting data for use by a data processing method enabling a gaming scheme based on an actual sporting event held over a playing area, comprising the steps of: collecting video images of all actual events occurring during the actual sporting event; analysing the video images to identify the type and location of every event; and storing data items identifying the type and location of every event in a database.

22. A data structure for storing data items useable by electronic data processing apparatus for use in a gaming scheme based on an actual sporting event held over a playing area, the data structure comprising a plurality of tables which between them store: event data items identifying at least one selected event; zone identifiers and associated owner identifiers; and at least one owner identifier associated with at least one selected event.

23. A data structure for storing data items useable by electronic data processing apparatus for use in a gaming scheme based on an actual sporting event held over a playing area, the data structure comprising data items identifying the type and location of every event, of a set of all possible events, that occurred during the actual sporting event .

24. Computer program code executable by electronic data processing apparatus to provide a method as claimed in any of claim 1 to 10 or apparatus as claimed in any of claims 11 to 20.

25. An electronic data processing method for use in a gaming scheme based on an actual sporting event held over a playing area, substantially as hereinbefore described.

26. Electronic data processing apparatus for use in enabling a gaming scheme based on an actual sporting event held over a playing area, substantially as hereinbefore described .