New! View global litigation for patent families

CA2354408A1 - Amusement and premiums network - Google Patents

Amusement and premiums network

Info

Publication number
CA2354408A1
CA2354408A1 CA 2354408 CA2354408A CA2354408A1 CA 2354408 A1 CA2354408 A1 CA 2354408A1 CA 2354408 CA2354408 CA 2354408 CA 2354408 A CA2354408 A CA 2354408A CA 2354408 A1 CA2354408 A1 CA 2354408A1
Authority
CA
Grant status
Application
Patent type
Prior art keywords
field
id
bytes
long
bin
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA 2354408
Other languages
French (fr)
Inventor
John Klayh
Original Assignee
John Klayh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/352Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/12Video games, i.e. games using an electronically generated display having two or more dimensions involving interaction between a plurality of game devices, e.g. transmisison or distribution systems
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/79Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers

Abstract

A system for controlling a medium of exchange comprising: plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of the identity of the person and of the activity, a first database for storing predetermined exchange values for the activity, a second database for storing separate medium of exchange accounts for various persons including at least one of customers and merchants, apparatus for detecting the signals, for accessing the first database and for crediting an exchange value related to the activity to an account of a person carrying out the activity or on whose behalf the activity was carried out, in the second database, and an administration terminal in communication with the first database for generating and downloading to the first database parameters indicative of the predetermined exchange values for various activities, from time to time.

Description

FIELD OF THE INVENTION
This invention relates to the field of data S communications, and in particular to a method and a system for on-line global distribution and redemption of loyalty points anal coupons, control of directed advertising and control of parameters related to various operations, activity software, etc.
BACKGROUND TO T$E INfVENTION
Electronir_ transaction processing and awarding of loyalty points by bank card issuers, airlines, etc. have come into widespread use. For example, retailers commonly use card swipe terminals which read information IS stored on a magnetic stripe carried by the card. The information is received by telephone line at an administration office, where a computer checks the credit of the customer identified by the information from a database, and provides an authorization number or denial of the transaction. Because credit is to be provided by the issuer of the card, such as a bank, the transaction is associated specifically with and is controlled by the issuer of the credit card.
As another example, when a debit card of a customer is swiped, a transaction value is keyed in by the retailer, andl a PIN number is additionally keyed in by a user. The bank account of the user, the identity of which having been previously stored in association with the PIN number and card number, is accessed, and the transaction value is debited from the bank account of the customer. This amount (less a transaction charge) is credited to the bank account of the merchant identified when the debit card reader dials an administration office SUBSTITUTE SHEET (RULE 26) which is in association with the bank. In this case as well, the transaction is associated specifically with and is controlled by the issuer of the debit card.
It is common that some credit card issuers record S loyalty points, for example a point for each dollar purchased on the credit card. These points are accumulated by the credit card issuer to the credit of the credit card user, and can be redeemed for merchandise or services typically advertised in a catalogue. In some cases, loyalty points are awarded by a vendor such as an airline, wherein the loyalty points can be used for airline travel with that airline. The vendor retains its own database of loyalty points accumulated against particular customers which have joined the loyalty point program.
In addition, identity cards rather than credit cards are sometimes used in the awarding of airline miles based on purchases from certain vendors. In this case as well, the card issuer retains a single database of airline points against customers.
In all such cases, the card issuer or the vendor (e. g. the airline) retains a simple database to keep track of the value of points accumulated or retained after redemption.
There is a single authority which has issued the card, and tie-ins of a single card with a limited number (often only one, and in some cases a large number) of merchants. For example, a card issuer may have a tie-in with several merchants to provide a discount on merchandise or services. In such a case, no loyalty points tied to a particular merchant are awarded to the customer for patronizing the merchant, but loyalty points are awarded based on use of the card per se.
SUBSTITUTE SHEET (RULE 26) Further, the systems are not capable of dispensing or redeeming premiums or loyalty points "on-the-spot" for certain actions taken by customers, for example for patronizing certain merchants. Thus in this case as well, a single loyalty point database is associated with the card issuer, but not with the merchants. A merchant has no way of knowing whether a particular customer repeatedly purchases from that merchant.
In other words, such systems provide and record loyalty points related to use of a card, or to a single merchant, or to a single program (such as airline points), but do not provide loyalty points that can be traded between merchants or programs, and do not give incentive to patronize particular merchants as distinct IS from incentive to use a single card. The airline points programs which are not associated with a particular credit card also require the use of a single card, and loyalty points cannot be traded between merchants.
The systems are also not capable of accumulating prize values or loyalty points won on games played on game terminals, nor of dispensing prizes to players, e.g.
loyalty points, premiums or plays on the games.
The systems are not capable of displaying advertising directed to specific customers who have identified themselves or have been identified at a terminal or to classes of such customers, nor of tracking what advertising has been displayed to particular customers, nor for controlling what advertising should be shown to such identified customers or classes of customers.
Neither are the systems capable of allowing the loyalty points won or otherwise acquired to be used as a medium of exchange between member merchants, e.g.
SUBSTITUTE SHEET (RULE 26) exchanging points won playing a video game for premiums which can be redeemed for goods or services by various merchants.
SUMMARY OF THE INf~7ENTION
S The present invention is an integrated on-line system which can accumulate and decrement exchange values associated with .any customer from any merchant which has authorized access to the system or by an administrator or by plural authorized administrators. The system provides means for the awarded exchange values for any transaction to be controlled by an administrator or by authorized plural administrators, and can in addition be varied by location of the customer, by customer activity, by time and/or date, and by past history of either the activity IS itself or of the actions of the customer or of changing demographics of the customer.
In addition, the system provides means for the administrator to vary the characteristics of a software program the customer, merchant, etc. is interacting with, so that loyalty ;points, advertisements, premiums, scores, game difficulty, characteristics of a game and reward brackets, pricing by currency and/or loyalty point exchange, etc. can be controlled and varied. The program can involve scoring of sporting events, scoring of school tests, operate applications such as email, etc. or it can be a video game such as one operating in a system of the type described in U.S. patent 5,083,271 issued January 21, 1992, or on a personal or public computer (public PC). A user interface to the program can be displayed on a video terminal which can be one of the games described in the aforenoted U.S. patent, or on a personal or public computer, a display type or video telephone, a network computer interacting and communicating via a private SUBSTITUTE SHEET (RULE 26) network, the Internet, cable or the equivalent, a telephone line, etc. The advertisement can be shown in one or more frames (windows) which share the display with a game frame, or can occupy the entire display area. The S advertisement can be directed to a particular player, or to a class of customer to which the player belongs, and/or can be scheduled based on time and/or date and/or location at which it is to be presented. The advertisement can be changed based on various criteria, such as the location of the display, how many times the advertisement ha:~ been run, how many times the advertisement has been directed to the customer or class of customer at a particular display or display location or at a class of locations or at plural particular or IS classes of locat_'Lons or based on advertisements which have been shown i.o the customer in the past. Loyalty points (i.e. exchange values, which can include coupons, etc.) can be awarded based on an activity of the customer at least partly on the basis of his exposure to certain advertisements which may be displayed on the aforenoted displays.
Game programs can be changed and varied as to degree of difficulty and currency or exchange value price to participate, competition brackets can be set up and varied, thresholds for prizes can be established and varied, prize and premium values can be accumulated for various activities such as plays, purchases, loyalty, and/or timing, customers or players can be authorized or disqualified, advertising can be directed to certain customers or classes of customers, premiums can be accumulated and dispensed and prizes awarded across any kind of commercial or non-commercial activity with SUBSTITUTE SHEET (RULE 26) controllable interchangeability, preferably from an administration terminal.
As an example, a customer can receive a coupon at a gasbar (or can read an announcement in a newspaper) S containing a question to be answered, and if answered correctly at a terminal used in the system of the present invention, a prize (e. g. a coupon for $1000 off the price of a purchase, or the awarding of loyalty points which can be exchanged for merchandise or service at participating or at all merchants) can be awarded by the system, and the accounts of the customer, merchants and administrator incremented or decremented as required.
The present invention thus provides for the first time an efficient way of combining loyalty point and IS premiums of any (rather than restricted) merchants, allows interchange of loyalty points, and at the same time gathers activity information and/or demographic information about. the customers of those merchants as an effective commercial measurement tool, and so that advertising may be targeted and efficiently delivered to those exact customers which can best benefit from the advertising and those exact customers desired by the advertisers.
By the use of the term merchants, included are merchants not on7.y of merchandise, but also of services including the services of play of various games and contests.
In this specification, the term customer and subscriber will be used synonymously, since a customer which has been registered into the system becomes a subscriber, and it is the registered customer which can accumulate loyalty points.
SUBSTITUTE SHEET (RULE 26) In accordance with an embodiment of the present invention, a system for controlling a medium of exchange comprises:
(a} plural terminals at various locations for S detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of the identity of the person and of the activity, (b) a first database for storing predetermined exchange values for the activity, (c) a second database for storing separate medium of exchange accounts for various persons (which can include either or both of customers and merchants), (d) apparatus for detecting said signals, for accessing the first database and for crediting an exchange value related to the activity to an account of a person carrying out the activity or on whose behalf the activity was carried out, in the second database, and (e) an administration terminal in communication with the first database for generating and downloading to the first database parameters indicative of the predetermined exchange values for various activities, from time to time.
In accordance with another embodiment, a system for controlling a medium of exchange comprises:
(a) terminals for determining the presence of a person, and of an activity carried out by the person, (b) display apparatus located adjacent to the terminal, (c) a regional server in communication with the terminals and display apparatus, (d) a first database accessible by the regional server, SUBSTITUTE SHEET (RULE 26) (e) a support server in communication with the regional server, (f) an administration terminal on which control parameters can be input, S (g) apparatus for receiving control parameters relating to medium of exchange values for activities carried out by the person from the administration terminal and for downloading the control parameters to the support server, (h) apparatus for transferring those control parameters which relate to media of exchange functions controlled by the regional server, to the first database, and (i) apparatus for transferring those control IS parameters which relate to functions carried out at the display apparatus and the terminals, from the first database to control apparatus for the display apparatus, whereby the presence and activity of said person can be determined and messages can be controlled to be ZO presented on the display apparatus directed to the identified person of class of person, and exchange values credited to the person.
In accordance with another embodiment, a system for controlling a medium of exchange comprises:
25 (a) plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of at least the activity, (b) a first database for storing predetermined 30 demographic information related to the activity, (c) apparatus. for detecting the signals, for accessing the first database and for storing data related to the SUBSTITUTE SHEET (RULE 26) activity in a record related to a class of persons carrying out the activity, in the second database, and (e) an administration terminal in communication with the first database for receiving the stored data, and for S generating and downloading to the first database parameters controlling the provision of offers to persons of the same class from time to time.
In accordance with another embodiment, a system for controlling a medium of exchange comprises:
(a) plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of at least the activity, (b) a first database for storing predetermined demographic information related to the activity, (c) apparatus for detecting said signals, for accessing the first database and for storing data related to the activity in a record related to a class of persons carrying out the activity, in the second database, (e) an administration terminal in communication with the first database for receiving the stored data, and for generating and downloading to the first database parameters for controlling the provision of advertising, for display on display apparatus which is part of the terminal or is adjacent the terminal, to the person or to persons of the same class, or for controlling the printing of premiums on a printer which is part of the terminal or is adjacent the terminal, from time to time.
~tRTFF DESCRIPTION OF THE DRAWINGS
A better understanding of the invention will be obtained by a consideration of the detailed description below, in conjunction with the following drawings, in which:
SUBSTITUTE SHEET (RULE 26) Figure 1 is a block diagram of a preferred embodiment of a :system on which the present invention can be implemented, Figure 2 is a flow chart of call initialization 5 and loyalty pointy or coupon data interchange, Figure 3 is a histogram of player scores against number of plays, Figure 4 is an illustration of a database format for specifying advertisements to be played under various 10 circumstances, aIld Figure 5 is an illustration of an exclusion code signal.
gF'.TATL~ED DESCRIPTIC~r1 OF EMBODIMENTS OF THE INVENTION
U.S. Patent 5,083,2'71 is incorporated herein by reference. This patent describes plural game arcades which are in communication with a central computer, or with one of plural regional computers which communicate with a central computer. The regional computers receive game score data and compute tournament winners, downloading both winner information and advertising to local games at the game arcades.
Turning two Figure 1, in place of the regional computers, regional servers lA, 1B...1N, etc. are used.
Each regional server is located at a separate regional data center, although for convenience of illustration they are all shown in this Figure in data center 3.
Each regional server has a memory containing a corresponding database 5A, 5B...5N coupled to it. In the aforenoted patent, the corresponding memory stores not only score data, but also values of money on deposit to be credited against the playing of a game, and handicaps of players and/or games. If an activity other than playing a game is to be rewarded, the user activity can SUIBSTITUTE SHEET (RULE 26) similarly be handicapped (for example, awarding of variable numbers of points for use of a particular long distance telephone supplier). In accordance with an embodiment of the' invention, the databases 5A, SB...SN also S store specialized data relating to parameters used in a game or activity, such as difficulty levels, points to be awarded for certain game activities, and other functions to be described in more detail below, as well as parameters and content relating to advertising, premiums, loyalty points, etc.
The data to be stored in databases 5A..5N is loaded by a decision support server 7, from data stored in a database 9 with which it communicates.
Validation and redemption terminals 11 are in IS communication with the regional servers 1A..1N. Each of the terminals 11 is comprised of a card reader 13 and preferably a bar code reader 14, smart card reader, or the equivalent, coupled to a printer 15. The card reader is preferably also a card writer for writing the magnetic stripe on a card and/or for updating, debiting or crediting one or more values stored on a smart card (a card which carries a processor or the equivalent and a memory). The team card reader is used in a general sense, since it pan include a keypad or keyboard which can be used by the customer and/or merchant. The customer can also or alternatively be identified by a voice identifier, an eye iris reader, a fingerprint reader, a palmprint reader, a keyed-in identity code such as a PIN number, etc. The printer is used to print receipts and coupons, preferably including a bar code or the equivalent. The card reader can be based on the type made by Verifone Corp. for swiping cards and dialing a credit or debit card administration office.
SUBSTITUTE SHEET (RULE 26) A terminal 11 should be located at the premises of each associated merchant authorized to use the system, and can be located at one or plural arcades 17 or other single or multi-terminal system. A system, which can be, S but is not limited to arcade 17 which is similar to the system described in the aforenoted patent is in communication with a corresponding server, in a manner as will be described later. However, rather than each game 19 communicating directly with a regional server via its own interface, it is preferred that it communicate with a regional server t:hrough a master game 21, via shell software which u:~es a particular communication protocol which can encrypt: data. This will be described in more detail later. A database 23 is also coupled to the master game 21.
A computer 25, referred to below as a public PC
25, can be in communication with an associated regional server 1A..1N. Preferably a card reader 13, bar code reader 14 and pr~.nter 15 are coupled to the computer, as well as a displa~r 27, keyboard 28, game controls (e.g. a joystick, mouse, trackball, pedals, etc.) a CD ROM player 29, and a DVD (digital versatile disk) player 32.
An administration office 41 contains a computer terminal 43 prefE:rably operating in a Windows'"' software 15 environment, with a display 45. Rather than a Windowst'"
software environment, any type of operating system can be used, such as one which will operate under control of applets downloaded from the Internet or any other network, Maclntosh, OS/2, etc. The terminal 43 includes a database and a processor for controlling parameters of software used in the system, and can communicate with the decision support server 7 as will be described below.
SUBSTITUTE SHEET (RULE 26) In operation, games, advertising and parameters relating to loyalty points and/or coupons are downloaded under control of the decision support server 7 to database 9, then are distributed to regional servers S 1A..1N, then are downloaded to database 23. Alternatively the games, parameters and/or advertising are stored at the arcade 17 on local mass storage devices such as hard disk drives, digital versatile disks (DVDs) or CD ROMs (or can be stored in a semiconductor or any other form of mass storage memory), and are enabled from data stored in the decision support server 7 and preferably downloaded to the database 23. The games, parameters and/or advertising can be provided via applet if desired. In the description below, and only for this example, the games and advertising will be described as being stored on DVDs (in database 23) at the arcade. The database will be considerE:d for this example to be a combination of the local mass storage and semiconductor memory, but it should be understood that the data can alternatively be downloaded from database 5A to 5N coupled to the regional server, and stored for use as needed in the database 23.
It is preferred that the games themselves should be written within a shell, with software "hooks" between the games and shell. The shell should be responsible for starting and stopping the game, altering its parameters, controlling the display of the game that is to be played, and communicating both with other games and with the regional server :LA..1N. It is preferred that each of the games should communicate with the regional server only under control of the master game 21. The software operated by the master game 21 should in addition be designed to communicate with each of the games of the SUBSTITUTE SHEET (RULE 26) arcade, and with a designated regional server using a communications manager program, in accordance with a predetermined protocol.
Customer accounts are retained in the database 9, and are preferably comprised of the following fields:
1. Account data (customer name and PIN), 2. Balance of account (in currency), both current balance and pending balance (the latter being the expected balance after an ongoing transaction has been completed) , 3. The identity and value of coupons and premiums allocated to the customer, 4. The balance value of loyalty points associated with the customer., e.g. as incremented or decremented by IS a device such as by an input device at a merchant location (for example by inputting via a keypad connected to the card reader 13 at a validation and redemption terminal 11) or by an administrator via terminal 43 at the administration location 41, or by operating an automatic terminal such as a coin telephone having a swipe card reader in administrative communication with regional server :LA to 1N, a game machine, etc., 5. Game ratings, such as skill level of the customer for variously played games, handicap values of the customer for variously played games, profiles (e.g. how much time is allocated to the player to complete various games), 6. Viewing history of advertising (e.g. a record of the most recent time that the customer has viewed a particular advertisement), 7. Images displayed for this customer, 8. The identities of identification cards issued to the player, SUBSTITUTE SHEET (RULE 26) 9. Merchandise orders, e.g. the identity and loyalty point, premium or currency cost of merchandise that has been ordered, the date ordered, the date the order was sent to the supplier, the date the order was shipped, S etc., 10. The game play history, e.g. for each game played, the rank achieved, number of players in a game or tournament, etc., 11. Data regarding membership of the customer in 10 competitions or 'teams, 12. Records of payments of fees made by the customer, and 13. Records of customer premiums and/or prizes awarded (which can be used e.g. for tax computation) 15 The administrator characterizes each game and activity relating to merchant products and services with certain parameters, and downloads these parameters from terminal 43 to server 7. For example:, the administrator establishes game formulae for each game, loyalty points !or none) for playing each game, for patronizing particular merchants, etc.
When a customer is issued an identity (ID) card, a PIN number is issued in a well known manner, and information re its issuance is uploaded from a validation terminal 11 to the associated regional server lA to 1N.
A record in the database 9 relating to this customer is established by server 7. The record is seeded by the parameters provided by the administration terminal to the server 7. For example, upon first initiation of the 30 record, a number of loyalty points can be deposited to the customer, and recorded in the database in field 4.
The customer then pays currency to play say, 5 video games. The payment value is entered by swiping the SUBSTITUTE SHEET (RULE 26) ID card in a local card reader in the arcade, and by then entering the PIN number of the customer and the number of games to be played, or a currency amount into a local keypad. This amount is stored (deposited) in database S field 1 (see the above field list) of database 9, after uploading from the arcade 17 via master game 21.
The customer then goes to the game and swipes his card in a card reader associated with the game. The request to initiate the game is sent to the game from the card reader, and value of the game play is sent to the decision support server 7. Server 7 addresses database 9, and selects the record of the customer from the card number read and provisionally decrements the amount on deposit, storing the resulting pending balance. If the IS game is not played (e.g. if there is a power outage), the pending balance :Ls again incremented back to the previous balance after a predetermined amount of time. By using a central decision support server 7 and database 9 to store the customer accounts, the customer can be provided with service at any location which communicates with any regional server. A duplicate account is established and retained in the regional support server database 5A..SN, the records being mutually updated (synchronized) from time to time.
At the time of establishment of the record in database e.g. 5A, the server 7 would also store values in the remaining fields of the record. For example, it would store an advertisement value, to be described in more detail below, in field 6, indicating that no ads have been presented to the customer.
After they customer has swiped his card at a game, and thus identifies himself, the local database provides a data message to a the local system which enables the SUBSTITUTE SHEET (RULE 26) selected game. 7:f it is the first time the customer has identified himself to the local system, the regional server e.g. lA sends a data message which enables the selected game. 7:t also enables a DVD to run an S advertisement to the game via its shell, which overlays the game in a window, or is presented prior to or with the initial, intermediate or final screens of the game.
For example, the initial screen can be a "welcome to a new player" screen, with an advertisement relating to one or another of the associated merchants. The advertisements to be run are pre-established at the administration terminal 43.
The fact of running a particular advertisement and of the customer being located at a particular game 1S (determined from his ID card) is then stored in the lOt"
field of the record. When the game has been completed, the score is uploaded to the regional server and the rank of the player is established and is stored in the lOt"
field. The number of plays of the player of that game, and of other games, axe also stored in the lOt" field. On the basis of this, depending on the administrator, loyalty points. coupons or premiums can be provided to the customer.
For example, if the customer has achieved a 2S particular score,, a predetermined number of loyalty points can be awarded, and added to those in the balance in the 4t" field of the database record. A printer 15 can dispense a coupon to the customer e.g. for a discount on a food item at a fast food outlet, the serial number and value of which is recorded in the 3rd field of the record.
The printout can also record the score and the game that was played.
SUBSTITUTE SHEET (RULE 26) The identity of the advertisement which was run is recorded in the 6'" field of the record.
The customer in achieving a particular amount of expertise can be handicapped by the software in the regional server 1.A, and the handicap value recorded in the 5t" field of the record, the rank achieved recorded in the lOt" field, arid all of this information can be printed on the same ticket as the coupon, or another ticket.
Now assume that the player attends a different arcade, and wishes to play a game. He will swipe his ID
card in the local card reader, press a button to command the start of or t:he identity of the game if necessary, and his identity, a command to play a game and the cost to play is uploaded to the associated regional server, say server 1B. Server 1B searches its database 5B for a record of the identified customer, and doesn't find it.
It then sends an inquiry to the server 7, which sends an inquiry to each of the other regional servers. Server 1A
responds, and provides an indication to server 1B that the customer record is stored in a database associated with server lA.
Server lA then sends the record of the customer to server 1B via server 7. Server 1B checks whether the second field has sufficient balance to pay for the game.
On the indication that it does, a provisional decrement is done as described earlier, and server 1B sends a signal to the master game of the arcade to enable the game.
The server 1B also checks the ad view history and image last viewed, and enables the DVD at the arcade to run the next advertisement in the predetermined sequence of advertisements to the game to be played, via the game SUBSTITUTE SHEET (RULE 26) shell. The entire process is repeated as described earlier.
In the event the customer has used the local system before, and his identity data, etc. is stored in S the local database, the above process can be carried out using the data stored in the local database, rather than using the data stored in the server.
The score can result in loyalty points or premiums being awarded to the player, which are stored in the account of the p:Layer.
Assume now that the customer wishes to redeem loyalty points or premiums. The customer can visit a validation and redemption terminal, which can be at the location of a merchant, a public PC, or at an arcade.
IS The ID card of the customer is read, and an attendant types in a request on a local keyboard such as 28 to obtain the number of loyalty points, or the identities of coupons or premiums held by the customer. This request is uploaded to the regional server, which reads the database e.g. 5A and accesses the record of the customer identified by the card (and PIN number, if desired). On verification by the regional server, the data stored in the fields of the information requested by the attendant are then downloaded to the local terminal, such as computer 25, and is displayed on display 27.
The customer can ask for redemption of the value of the coupon. For example, if the validation and redemption center is at a fast food outlet, and the coupon is for a discount on a hamburger from the fast food outlet, the merchant can sell the hamburger at the required discount, take the coupon from the customer, and key in the coupon on a keypad or read a barcode or magnetic stripe or the equivalent carried by the coupon, SUBSTITUTE SHEET (RULE 26) to identify it arid record it as having been redeemed. ..
The local computer or the equivalent then uploads this data to the regional server lA, which records that the coupon has been rendered.
S While this transaction is going on, there could be a display adjacent the redemption equipment. The regional server, in learning of the presence of the customer at that location from the ID card swipe, can then look up the advertisement viewing history from the 10 6t" field of the customer's record in the database, and send a control signal to the computer or the equivalent at the redemption center, to enable a local DVD 31 to run the next advertisement in a predetermined sequence to the display which is adjacent the customer. Loyalty points 15 can be awarded to the identified customer based on viewing a particular advertisement, and stored in the database as described earlier.
In a similar manner, loyalty points can be redeemed. The customer can attend a redemption center 20 which can be a merchant, or a special catalog store.
After swiping the ID card of the customer and keying in a request to display the number of loyalty points accrued to the customer, the regional server~e.g. lA accesses the record of the customer using his ID and PIN number in database e.g. 5A, and downloads the information to a local display. 'Following redemption of a particular number of loyalty points for the merchandise or services requested, the 4'=" field of the record of the customer is decremented by t,ne value of the loyalty points redeemed.
It should be noted that the system is global, in that any merchant can have a redemption terminal. Upon redeeming loyalty points which have been accrued by the customer by playing games, viewing advertisements, or SU13STITUTE SHEET (RULE 26) using services of other merchants, etc., the redeeming merchant can be owed a certain value based on the redemption. This value or the equivalent in loyalty points, can be stored (credited) in a database SA related S to the merchant. When a customer purchases goods from that merchant, a certain number of loyalty points can be awarded the customer, and the balance debited from the balance of the merchant. Administrator service fees in the form of loya:Lty points can be accrued to an account of the administrator for each transaction. In this manner, loyalty ~?oints become a medium of exchange for the customer, the merchants and the administrator.
Loyalty points or a monetary amount can be decremented from an account of each merchant for each play of its advertisement.
At the end of a predetermined period, for example quarterly, yearly, etc., the administrator and merchants can settle the accounts, e.g. collecting a prescribed monetary value for negative balances of merchant loyalty point accounts, and paying a prescribed monetary value for positive balances of merchant loyalty point accounts.
Loyalty points can also be redeemed by the customer for any merchandise or service at any merchant location or venue at which a service terminal is located, or for game play at an arcade.
Two types of data interchange are preferably used in the system: synchronous and asynchronous. In synchronous interchanges, the client initiates a connection to a server, sends a request, and await a reply, in a manner similar to credit card authorizations in retail stores. An example of this type of interchange in the present invention is the validation of a prize receipt. Asynchronous interchanges are used for database SUBSTITUTE SHEET (RULE 26) synchronization. They allow events that have been queued by clients to be sent to servers, and allow servers to add or update information in a client's database.
Four modes of communication between clients and servers are preferred to be used:
- Queries from clients to servers for specific information, - Events .being transmitted from clients to servers, - Record and file system synchronization transmitted from servers to clients, and - Interactive on-line traffic, allowing on-line services in which processing is done in real-time by the server, or through a proxy process on the server.
IS Because of the short duration and unpredictability of query calls, t=hey are preferably implemented with a point-of-sale, packet type transaction type network, with dial-in connections from various client locations using a global toll-free number.
The remaining types of calls are more predictable in nature and duration, typically lasting one or more minutes, and preferably use full duplex stream-oriented communications. 'this can be implemented using a dedicated or non--dedicated dial-up line between client and server, using TCP/IP ports (internet or intranet).
Thus each server can initiate two types of connections to client servers: asynchronous dial-in to the transaction network at relatively low speeds (e. g.
2400 baud or higher) for short duration queries, or via a dial-in PPP connection (e.g. 28.8 kbaud or higher) or ISDN to perform sockets-based communication.
The data transmission protocol used is preferred to be bi-directional full-duplex asynchronous SUBSTITUTE SHEET (RULE 26) communication using X.25-based packet switching, but other communications technologies, e.g. ADSL can be used, as they become widely available. Prior to application to the network, the event data should be packetized, S inserted into variable length telecommunication packets, compressed and encrypted using the encryption key of the location. Other fields in the telecommunication packet need not be compressed or encrypted. The received packets should be decrypted, decompressed, and extracted from the telecommunication packets.
The transmissions are preferably initiated from the transmitting entity (dial-in) rather than being polled. The calls can be normal (e.g. to pass data re start, game plays, alarms, meters, etc. to and from the IS client, stored in a queue at that location for subsequent transmission), urgent (e. g. such as customer information when a card is swiped), and receipt validation (e.g. to verify calls used by validation terminals).
Terminals communicating within a single location can use lObaseT twisted pair wiring and 802.3 (Ethernett"') standard for data link management, or higher speed Ethernet or other technologies, as they become available.
The regional servers can accept connections from either the point-of-sales transaction network or from a TCP/IP
internet/intranei: connection (using Berkeley sockets).
The same application-layer protocols operate over each connection, with the possible exception of synchronization, which can operate only over TCP/IP
connections, if desired.
The four types of packets referred to above can have a number of subtypes, as follows:
SUBSTITUTE SHEET (RULE 26) Packet Possible Subtypes Type:

Control Acknowledgment (ACK) Negative Acknowledgment (NAK) Context Negotiation Ping Ping Response Open Query Link Close Query Link Open IP Link Close IP Link Link Status Request Link Status Response Suspend Processing Suspend Processing ResponseResume Processing Resume Processing ResponseSynchronize Synchronize Response Query Test Test Response Receipt Validation Receipt Validation Response Subscriber Information Subscriber Information Response Account Withdrawal Account Withdrawal Response Account Deposit Account Deposit Response Subscriber Account Data Subscriber Account Data Response Request winning uedemption Play Winning Redemption Play Response Subscriber ID Request Subscriber ID Response Credit/Debit Request Credit/Debit Response Save State Request Save State Response Restore State Request Restore State Response New Subscriber Card RequestNew Subscriber Card Response Reserve Merchandise Reserve Merchandise Response Purchase Merchandise Purchase Merchandise Response Release lMerchandise Release Merchandise Response Subscriber Ranking RequestSubscriber Ranking Response Event Alarm Tournament Play Redemption Play Meter Readings Ad Statistics Service Accesses Down Times New Subscriber New Team Issued Coupons Loyalty Point Awards Synchron-Inventory Table Download ization File Initial Download File Next Download File Initial Upload File Next Upload When a call is connected over the point of sale network or either of the TCP/IP ports, the client and server exchange context negotiation packets to configure the session communications as shown in Figure 2. When both parties have acknowledged the context negotiation, data packets can begin.
The client sends a context negotiation packet with the settings it wishes to use for the call (including the encryption and compression parameters). This packet also tells the server what type of call this is (e. g. events, SUBSTITUTE SHEET (RULE 26) queries, etc.). The server examines the context negotiation packet and determines whether the values are acceptable. If so, it sends a context negotiation packet with the same settings to the client. The client 5 acknowledges this packet to the server, and the call is considered to be established.
If the server cannot use the context provided by the client, it sends its own context negotiation packet back to the client with its preferred settings (e.g. a 10 "lower" standard for compression or encryption). If the client agrees with these settings, it sends an acknowledgement t:o the server, and the call is considered to be established.
The contents of the context packet are sent IS uncompressed, but. encrypted using the terminal's 16 byte license key and ~i TEA encryption algorithm. The terminal cannot operate unless the license key entered at the machine matches the key entered through the server administrative application.
20 If a device receives a context packet for an encryption method it can perform, it can NAK
(unacknowlege) the packet. The server should retransmit session key packets, working from best to worst encryption (retrying a number of times in case of 25 communications faults) until the client returns an acknowledgement. If the client never acknowledges the packet, the server should close the connection.
Likewise, if the server never acknowledges the packet from the client, the client can close the connection.
The client is free to retry with a new socket on the same call.
When a connection is established over the asynchronous point of sale link, the client may SUBSTITUTE SHEET (RULE 26) immediately begin transmitting data packets to the server. Then a PPP connection is established, the client should create a socket connection to one of the TCP ports listed above. Packets can then be sent over this socket connection. Multiple socket connections can be opened to allow parallel processing of synchronization, event and query traffic.
Query exchanges preferably occur in lockstep over a single connection. When a terminal issues a query, it waits on the same connection for a matching query response to arrive. The terminal then processes the query response, sends an acknowledgement, then closes the connection or continues with other query exchanges.
If a query initiates the download of table and/or file information to the client. the downloads should take place before the server sends the query response. When the query response is received at the client, it can assume that all downloads are complete.
Event transfer from clients to servers follows a lockstep acknowledgement cycle in which the client sends event packets and the server sends acknowledgement or nonacknowledgement packets in response. Events should remain in the client's event queue until an acknowledgement has been received from the server. When all events have been sent and acknowledged, the client can close the connection.
When a client makes a synchronization call, the client and server_ begin by exchanging inventory packets.
The client sends an inventory of all data currently loaded, and the server sends an inventory of what the client should have (including table records and files?.
The client should use the server's inventory to delete all records and files that are not present at the SUBSTITUTE SHEET (RULE 26) server. The server should use the client's inventory to build a set of table and file download packets to send new information t:o the client.
Once the inventories have been exchanged, the server should begin sending table and file download packets. The client should respond to these with either an acknowledgment or nonacknowledgement packet. When the server has sent all records, it should send a table download packet with 0 records to indicate the end of data. The client: is free to close the connection at this point.
All packets should be framed with a consistent header and trailer, to allow the protocol processor in the receiving sex-ver or terminal to distinguish between different versions of requests. A preferred packet is as follows:
Offset: Field Size: DESCRIPTION
0 byte Packet type - the following values are defined:
0x80 = Control packets 0x81 = Query packets 0x82 = Event packets 0x83 = Synchronization packets Note that the high bit is used to distinguish these packets from earlier version packets.
1 byte Subtype - the following values are de; f fined Control packets:
0 = Acknowledgement 1 = Negative Acknowledgement 2 = Context Negotiation 3 = Ping 4 = Ping Response 5 = Open Query Link 6 = Close Query Link 7 = Open IP Link 8 = Close IP Link SUBSTITUTE SHEET (RULE 26) 9 = Request Link Status = Link Status Response 11 = Suspend Processing 12 = Suspend Processing Response 13 = Resume Processing 14 = Resume Processing Response = Synchronize 16 = Synchronize Response Query packets:
0 = Test 1 = Test Response 2 = Receipt Validation 3 = Receipt Validation Response 4 = Customer Information 5 = Customer Information Response 6 = Account Withdrawal 7 = Account Withdrawal Response 8 = Account Deposit 9 = Account Deposit Response 10 = Customer Account Data Request 11 = Customer Account Data Response 12 = Winning Redemption 13 = Winning Redemption Response 14 = Customer ID Request 15 = Customer ID Response 16 = Credit Debit Request 17 = Credit Debit Response 18 = Save State Request 19 = Save State Response = Restore State Request 21 = Restore State Response 22 = New Customer Card Request 23 = New Customer Card Response 24 = Reserve Merchandise = Reserve Merchandise Response 26 = Purchase Merchandise 27 = Purchase Merchandise Response 28 = Release Merchandise 29 = Release Merchandise Response = Customer Ranking Request 31 = Customer Ranking Response Event packets:
0 = Alarm 1 = Tournament Play 2 = Redemption Play 3 = Meter Readings 4 = Ad Statistics 5 = Service Accesses 6 = Down Times 7 = New Customer SUBSTITUTE SHEET (RULE 26) 8 = New Team 9 = Issued Coupons 10 = Loyalty Point Awards Synchronization packets:
0 = Inventory 1 = Table Download 2 = File Initial Download 3 = File Next Download 4 = File Initial Upload = File Next Upload 2 2 bytes Packet size (in bytes, including the type, subtype, size and CRC fields), LSB first 4 N bytes Data (see individual packet descriptions for format) 4+N 2 bytes CRC; of packet Acknowledgement packets indicate the successful receipt of information. The total size of the framed packet will be 5 bytes Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x00 2 bytes Packet size = 6 2 bytes CRC
Negative Acknowledgement (NAK) Negative ;Acknowledgement packets indicate that a transmission was unsuccessful or that the receiver encountered an error processing the data. The total size of the framed packet will be 7 bytes.
Field Size: Description:

1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x01 2 bytes Packet Size = 7 1 byte Failure Code 0 Generic failure 1 System error 2 Allocation failure 3 Invalid request 4 Communications error 2 bytes CRC

SUBSTITUTE SHEET (RULE 26) WO 0013$089 PCT/CA99/01201 Context Negotiation Context Negotiation packets have the following data structure Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x02 2 bytes Packet Size = 40+

4 bytes Location ID (LSB first) 6 bytes Terminal ID

[BEGIN RYPTED AREA]
ENC

16bytes License Key 1 byte Connection type 1 byte Encryption type 1 byte Transmission Sequencing 2 bytes Key Length (in bytes, LSB first) N bytes Key Data (Pad encrypted area to even 8 byte boundary with zeros) [END ENCRYPTED AREA]

2 bytes CRC

Location ID will be 0 in packets from the client.
It will be filled in with packets from the server with the location ID configured for the terminal ID from the client, or 0 if l.he terminal is not configured in any S location. Terminals that are not configured in any location can sti:L:L access the server for some limited functions. However, if the licensing information is not correct, the server will never send a Context Negotiation packet to the client.
10 The license key is a value entered through the user interface ai. the terminal, and entered by the operator when configuring the machine in the administrative application. It is used to encrypt the encrypted area of the Context Negotiation packet. When IS the packet is received, the receiving node decrypts the encrypted area with its stored license key, then compares that key with the decrypted version from the packet. If the two do not match, the machine is not licensed SUBSTITUTE SHEET (RULE 26) correctly and the Context Negotiation will not succeed until this is corrected. At the terminal, a message indicating incorrect license information should be displayed or printed. At the server, the event will be logged for reporting and/or alarming.
The connection type will be one of the packet type codes (0x80 through 0x83) indicating the type of connection being made. This will indicate to the server which protocol processor to launch for the connection.
Note that if more than one type of activity needs to occur on one connection, the client can send a Context Negotiation packet during the call to renegotiate the call type (and other parameters of the connection as well). When this occurs, all in-progress operations are completed, then renegotiation occurs.
The Encryption type field will be one of the following values:
Value Description 0 No en,~r i nn 1 FOR of kP,~r and plain text 2 Earlier Protocol Version encryption 3 TEA (see Appendix A for algorithm) Transmission sequencing will be one of the values below:
Value Description 0 Lockstep ( send packet, wait for Ack, send next packet) The contents of the key data will depend on the encryption type, as shown here:
SUBSTITUTE SHEET (RULE 26) Encryption Type Key Length and Key Data 0 data will be included 1 ~y length wil bP 0, and no 2 Key length and key data can vary 3 Key length and key data can vary 4 Key length is 16, key data can vary 5 KeY lenq~h is 5. key data pan vary Key length and key data can vary For connections between terminals within a single location, or between processes on a single terminal, the terminal ID and :Location ID are both set to 0. The contents of the packet will not be encrypted and should have the following values:
Encryption type = 0 Transmission Sequencing = 0 Key length = 0 This type of connection is only valid on LAN
segments or between processes on a single machine.
The license key field will be filled by the terminal's license key. This allows the server process to enforce unique license keys and prevent services from establishing their own connections to the server without their own valid license keys.
Ping Ping packets are used to test communications to the server. The total size of the framed packet will be 6 bytes .
Field Size Description 1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x03 2 bytes Packet Size = 6 2 bytes CRC
Upon receipt of a Ping packet, the server will immediately generate a Ping Response packet and send it SUBSTITUTE SHEET (RULE 26) to the client. This does not require any database or file system access, and can be used to test the basic connection between client and server processes.
Ping Response S Ping Response packets are sent in reply to a Ping packet. The total size of the framed packet will be 6 bytes.
Field Size: Description:
1 byte Packet Type = 0x80 10 1 byte Packet Subtype = 0x04 2 bytes Packet Size = 6 2 bytes CRC
Open Query Link 15 A request that a link to the server be created that is capable of supporting query traffic (or increases the reference count of an existing link). The total size of the framed packet will be 6 bytes.
Field Size: Description:

20 1 byte Packet Type = 0x80 1 byte Packet Subtype - 0x05 2 bytes Packet size = 6 2 bytes CRC
ZS This operation is intended for use between slave and master terminals within a location or between processes on a single terminal. On receipt of this packet, the recipient should establish a connection to the server suitable for query traffic. This may mean 30 forwarding a similar request to the next higher server in the hierarchy.
If there is already a link established, its reference count is incremented.
Close Query Link 35 A request that a link to the server established by an Open Query Link request be closed (or the reference SUBSTITUTE SHEET (RULE 26) WO 00/38089 PCT/CA99/0120i count of the link be decremented). The total size of the framed packet will be 6 bytes.
Field Sixe: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x06 2 bytes Packet Size = 6 2 bytes CRC
Open IP Link A request. that a link to the server be created that is capable of supporting IP traffic (or increases the reference count of an existing link). The total size of the framed packet will be 6 bytes, Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x07 2 bytes Packet Size = 6 2 bytes CRC
This operation is intended for use between slave and master terminals within a location or between processes on a single terminal. On receipt of this packet, the recipient should establish a connection to the server suitable for all types of traffic. This may ZS mean forwarding a similar request to the next higher server in the hierarchy.
If there is already a capable link established, its reference count is incremented.
Close IP Link A request: that a link to the server established by an Open IP Link request be closed (or the reference count of the link be decremented). The total size of the framed packet will be 6 bytes.
SUBSTITUTE SHEET (RULE 26) Fisld Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x08 2 bytes Packet Size = 6 S 2 bytes CRC
Request Link Status A request. for the current link status. The total size of the framed packet will be 6 bytes.
10 Field Sixe: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x09 2 bytes Packet Size = 6 2 bytes CRC
IS
When a server receives this request, it should respond with the status of the link to the main ADMIN
server group. This may mean forwarding a similar request to the next higher server in the hierarchy.
20 Link Status Returns the current link status. Sent in response to a Request Link Status packet. The total size of the framed packet will be 6 bytes.
25 Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = OxOA
2 bytes Packet Size = 7 1 byte Link Status 30 Low order nibble is current link status:
0x00 Link state unknown (indicates an error) OxO:L Link is idle 0x02 Connecting asynchronous 0x03 Connecting asynchronous, IP request 35 pending 0x04 Connecting IP
OxO~ Connected asynchronous 0x06 Connected asynchronous, IP request pending 0x0'7 Connected iP
40 High order nibble is modem state (if applicable) 0x00 Modem idle (or no modem in link) Oxl~O Modem is dialing 0x20 Modem is waiting for answer 0x30 Modem is connected SUBSTITUTE SHEET (RULE 26) 0x40 Modem is authenticating High bit indicates processing is suspended Ox80 Processing suspended 1 byte Query status S High bit is one if a query is in progress Bits 0-6 indicate the percentage complete 1 byte Event status High bit is one if an event exchange is in progress Bits 0-6 indicate the percentage complete 1 byte Synchronization status High bit is one if a database synchronization is in progress Bits 0-6 indicate the percentage complete 2 bytes CRC

The fields in the response packet relating to query, event and synchronization status are relevant only when the server process is running on a master terminal within a location. All other servers will return 0 for these three fields.
Suspend Processing Requests that the communications process on the master terminal suspend any activity that could impact ZS system performance. This prevents service degradation to ensure fair tournament play. The total size of the framed packet wil_1 be 10 bytes.
Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = OxOB
2 bytes Packet Size = 10 4 bytes Time-out (seconds) 2 bytes CRC

Suspend Processing Response Sent by the communications process on a master terminal in response to a Suspend Processing request packet, indicating that the processing will be suspended as soor.~ as possible. The client can use Get Link Status to determine when processing has been SUBSTITUTE SHEET (RULE 26) suspended. The total size of the framed packet will be 6 bytes .
Field Size: Description:
1 byte Packet Type = 0x80 5 1 byte Packet Subtype = OxOC
2 bytes Packet Size = 6 2 bytes CRC
Resume Processing Informs the communications process on a master terminal that normal processing can be resumed. This should be performed after a time-critical operation has completed, and should balance each Suspend Processing 15 packet. The total size of the framed packet will be 6 bytes .
Field Sixe: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = OxOD
2 bytes Packet Size = 6 2 bytes CRC
Resume Processing Response 25 Sent by the communications process on a master terminal in response to a Resume Processing request packet, indicating that normal processing will be resumed. The total size of the framed packet will be 6 bytes.
Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = OxOE
2 bytes Packet Size = 6 2 bytes CRC
Synchronize Requests that the communications process on a master terminal initiate a synchronization with its SUBSTITUTE SHEET (RULE 26) server. Different levels of synchronization can be requested in the flags field. Note that the communications process should perform a full synchronization on startup and again every few hours S automatically (depending on the dialing interval configured for the location). The total size of the framed packet will be 7 bytes.
Field Size: Description:
1 byte Packet Type = 0x80 byte Packet Subt ype = OxOF

2 bytes Packet Size = 7 1 byte Flags Defined bits include:

0x01 Scan file system and update W
CONTENT
CACHE table 0x02 _ _ Synchronize the database with the server 0x04 Synchronize subscriber records in cache OxFF Do full synchronization 2 bytes CRC

Synchronize Response Sent by t:he communications process on the master terminal in response to a Synchronize packet, indicating that 'the process will begin the synchronization as soon as possible. The total size of the framed packet will be 6 bytes.
Field Size: Description:
1 byte Packet Type = 0x80 1 byte Packet Subtype = 0x10 2 bytes Packet Size = 6 2 bytes CRC
Receipt Validation Receipt validation packets are traditionally sent by validation terminals, but can be sent by any authorized ADMIN terminal. Receipt IDs are printed on all receipts or coupons generated at ADMIN terminals.
SUBSTITUTE SHEET (RULE 26) The receipt ID is printed in two formats - a bar-code symbol using the Code 39 symbology, and a 15-digit numerical string, printed in 5 groups of 3 digits.
This pacls:et is also used to redeem receipts and loyalty points the subscriber has on account. This is typically done by game terminals. following a Subscriber Account Information query to gather the current account information.
Receipt validation packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x02 IS 2 bytes Packet Size = 30 [BEGIN ENCRYPTED AREA]
6 bytes Validating Terminal ID
1 byte Receipt ID length (10 or 15) N bytes Receipt ID
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA) 2 bytes CRC
The length of the receipt data governs its format. The formats supported, and their lengths, are shown here:
Length: Format:

10 10 Code-39 Bar-code symbols, as read from the printed receipt 14 4-byte value representing the loyalty program I D

4-byte value representing the number of points being redeemed 4-byte value representing the subscriber ID

2-byte value representing the PIN

15 15 decimal digits, as printed on the receipt 16 10 Code-39 Bar-code symbols, as read from the printed coupon 4-byte value representing the subscriber ID

2-byte value representing the PIN

21 15 digit receipt ID of coupon being redeemed 4-byte value representing the subscriber ID

2-byte value representing the PIN

SUBSTITUTE SHEET (RULE 26) The receipt ID should appear in the packet in the same order as entered or scanned from the receipt. For numeric IDs, send the ASCII code for each digit. For bar-code format, send the ASCII codes for the bar-code S symbols as defined in the Code 39 bar-code symbology.
Receipt Validation Response When the server receives a Receipt Validation query, it will attempt to validate the receipt ID in the packet, and will return this response packet with 10 the results.
Receipt validation response packets have the following data structure:
Field Size: Description:

1 byte Packet Type = 0x81 IS 1 byte Packet Subtype = 0x03 2 bytes Par_ket Size = 14 or 22 [BEGIN ENCRYPTED
AREA) 1 byte Status indicator 0 = Coupon valid-payment authorized 20 1 = Coupon not found on server 2 = System error 3 = Coupon already redeemed 4 = Insufficient loyalty points 5 = Invalid loyalty program 25 6 = Subscriber not found 7 = Invalid PIN

8 = Subscriber account frozen 15 bytes Authorization code (only present if status=0) 30 (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED
AREA]

2 bytes CRC

The authorization code will be an ASCII string consisting of digits only. It will always contain 15 35 digits .
Subscriber Information Subscriber_ information queries are sent by clients when a subscriber logs on to a terminal and that subscriber's information is not in the local SUBSTITUTE SHEET (RULE 26) database cache. This query will cause table and file downloads between the query and the response.
Subscriber information request packets have the following data structure:
S Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x04 2 bytes Packet Size = 38 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID requesting the information 1 byte Card type used in the request 1 = NANI card 2 = Credit card 3 = Debit card IS 4 = Name 5 = Name and SSN
16 bytes Card data 2 bytes PIN
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
If the card type is 1 (ADMIN Cards), the card data should be filled with the 10-digit ID read from the NANI card followed by 6 spaces.
15 If the card type is 2 or 3 (Credit or Debit card), the card data field should be the data read from the PAN field on the card stripe (either track or track 2) .
If the card type is 4 (Name), the card data field should be filled with 14 characters of the player's name followed by 2 spaces.
If the card type is 5 (Name and SSN), the card data field should be filled with 10 characters of the player's name fo~_lowed by a 4-byte representation of 3S the players SSN ;treated as an integer, stored LSB
first), followed by 2 spaces. This is the only case in which non-ASCII data is stored in the card data field.
SUBSTITUTE SHEET (RULE 26) Subscriber Information Response When the server received a request for subscriber information, it will collect the information about the subscriber (if found) into table and file download S packets, and transmit them to the client. When all downloads are complete, this response packet will be sent to the client. If there is an error or if the subscriber is not found in the server's database, this response will be transmitted right away.
Subscriber- information response packets have the following data structure:
Field Size: l7escription:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x05 IS 2 bytes Packet Size = 14 or 22 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID requesting the information 1 byte Status Indicator 0 = Information found - subscriber ZO valid 1 = Information not found 2 = System error 3 = Invalid PIN
4 bytes Subscriber ID (only present if status 25 -- 0 ) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes C;RC
If status is 0 or 3, this packet will be preceded 30 by a one or more table and/or file download packets containing the subscriber information. When the response packet :is received, all subscriber data will have been downloaded to the terminal. Responses with status codes 1 or 2 will be returned right away.
35 Account Withdrawal This query is sent by clients when a subscriber requests a withdrawal of money currently on account.
Account withdrawal packets have the following data structure:
SUBSTITUTE SHEET (RULE 26) Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x06 2 bytes Packet Size = 22 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID requesting the transaction 4 bytes Subscriber ID
2 bytes PIN number entered by subscriber 4 bytes Amount to be withdrawn (in US cents) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
The server will enforce limits on the maximum and minimum amounts f'or which a withdrawal can be made.
IS Account Withdrawal Response When an account withdrawal request is made, the server will attempt to perform the withdrawal, then will send this response packet to the client with the results.
Account withdrawal response packets have the following data structure:
Field Size: Description:

1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x07 2 bytes Packet Size = 22 or 38 [BEGIN ENCRYPTED
AREA]

6 bytes Terminal ID performing the withdrawal 4 bytes Subscriber ID

1 byte Status indicator 0 = Withdrawal authorized 1 = Insufficient funds 2 = Subscriber not found on server 3 = Invalid PIN

4 = Account frozen 5 = System error 6 = Invalid amount 15 bytes Authorization ID for withdrawal (only present if status = 0) 4 bytes New account balance, in US cents (only present if status = 0) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AP,EA]

2 bytes CRC

SUBSTITUTE SHEET (RULE 26) Account Deposit This query is sent by the clients when a subscriber requests a deposit of money to his or her own ADMIN account.
Account deposit packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte ~?acket Subtype = 0x08 2 bytes Packet Size = 22 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID requesting the transaction 4 bytes Subscriber ID
2 bytes F?IN number entered by subscriber IS 4 bytes l~rnount to be deposited (in US cents) [END ENCRYPTED AREA]
2 bytes C:RC
Account Deposit Response When an account deposit request is made, the server will attempt to perform the deposit, then will send this response packet to the client with the results.
Account deposit response packets have the following data structure:

Field Size: Description:

1 byte F?acket Type = 0x81 1 byte F?acket Subtype = 0x09 2 bytes F?acket Size = 22 or 38 [BEGIN ENCRYPTED
AREA]

6 bytes Terminal ID performing the withdrawal 4 bytes :subscriber ID

1 byte ;>tatus indicator 0 = Deposit accepted 1 = Account limit exceeded 2 = Subscriber not found on server 3 = Invalid PIN

4 = Account frozen 5 = System error 6 = Invalid amount 15 bytes Authorization ID for deposit (only present if status = 0) 4 bytes New account balance, in US cents (only present if status = 0) SUBSTITUTE SHEET (RULE 26) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
Subscriber Account Data Request 5 This query is sent by clients when a subscriber requests a full report on his or her current account status.
Subscriber account data request packets have the following data structure:
10 Field Size: Description:
1 byte 1?acket Type = 0x81 1 byte 1?acket Subtype = OxOA
2 bytes Packet Size = 22 [BEGIN ENCRYPTED AREA]
15 6 bytes '.Germinal ID
4 bytes Subscriber ID
2 bytes PIN
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
20 2 bytes <:RC
Subscriber Account Data Response When the server received an account data request, it collects the .information about the subscriber's account and sends this response packet.
15 Subscriber account data response packets have the following data structure:
Field Size:
Description:

1 byte Packet Type = 0x81 1 byte Packet: Subtype = OxOB

30 2 bytes Packet. Size = 22 or 38+

[BEGIN ENCRYPTED AREA]

6 bytes Terminal ID

4 bytes Subscriber ID

1 byte Status Indicator 35 0 = Success 1. = Account 1:'rozen 2 = Subscriber not found 3 = Invalid PIN

9 = System error 40 4 bytes Account balance (in US cents)(on success) 4 bytes Amount: withdrawn pending confirmation (in US

cents)(on success) 2 bytes Number of outstanding orders (on success) 6 bytes Order ID (on success) 45 40 bytes Item name (on success) SUBSTITUTE SHEET (RULE 26) 4 bytes Date and time order received (on success) 4 bytes Date and time order sent to supplier (on success) 4 bytes Expected ship date and time (on success) 4 bytes Date and time order shipped (on success) 4 bytes Date and time order canceled (on success) 2 bytes Number of coupons (on success) 4 bytes C:aupon ID (on success) 40 bytes Description (on success) 6 bytes Receipt ID (on success) 4 bytes Face value (on success) 4 bytes Expiration date (on success) 2 bytes Number of loyalty programs (on success) 4 bytes Loyalty program ID (on success) IS 40 bytes Loyalty program name (on success) bytes Loyalty point label (on success) 4 bytes Number of points (on success) (Pad encrypted are to even 8-byte boundary with zeros) (END ENCRYPTED AREA]
20 2 bytes CRC
Winning Redemption Play When a redemption game has been played that awards a prize, and the prize has a limited number of units available (a non--zero value for the NUM REMAINING field in the database), or that wins a prize that includes a pool amount, the terminal should immediately issue this query to update :its local prize information.
This packet permits prize pools to be maintained across several locations, without the chance that more prizes that are available will be given out. It also allows the server to update the local pool value so players can see pool contributions from multiple locations.
Winning redemption play packets have the following data structure:
Field Size: Description:
1 byte Packet: Type = 0x82 1 byte Packet: Subtype = OxOC
2 bytes Packet: Size = 38+
[BEGIN ENCRYPTED AREA]
4 bytes Subscriber ID playing the redemption game (LSB
first) 6 bytes Terminal ID on which the redemption game was played SUBSTITUTE SHEET (RULE 26) 4 bytes Service ID on which redemption game was played (LSB first) 1 byte Player Station(B bit flags, position 0 = station 1, etc.) S 1 byte Active Stations (8 bit flags, position 0 =
station 1, etc.) 4 bytes Start Date and Time (UTC format, LSB first) 4 bytes End Date and Time (UTC format, LSB first) 1 byte Flags 0x01 Equipment failed during game Ox02 Score is invalid 1 byte Number of statistics (n) [BEGIN REPEATING LIST]
4 bytes Statistic ID (LSB first) IS 4 bytes Statistic Value (LSB first) [END REPEATING LIST]
1 byte Number of redemption games entered with the play (m) [BEGIN REPEATING LIST) 4 bytes Redemption ID (LSB first) 2 bytes Par level beaten (LSB first) 4 bytes I?ar score beaten (LSB first) 4 bytes Derived score achieved by subscriber (LSB
first) 4 bytes I?rize ID awarded (LSB first) [END REPEATING LIST]
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
The subscriber ID may be 0 if the redemption game is unidentified.
Winning Redemption Play Response When a winning redemption play query is received at the server, it will adjust the number of the awarded prizes remaining (if that number is limited), and/or it will calculate the pool amount to award to the player based on the current value of the collective prize pool. (If the pair level has an associated pool amount).
It will send this response packet back to the terminal, indicating the amount of the pool the player should be awarded and updating the pool value and number of prizes remaining as appropriate.
Winning redemption play response packets have the following data structure:
SU$STITUTE SHEET (RULE 26) .~

Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxOD
2 bytes Packet Size = 14+
S [BEGIN ENCRYPTED AREA]
4 bytes Current pool value (LSB first) 1 byte Number of par levels being updated (n) [BEGIN REPEATING LIST]
4 bytes Redemption ID being updated (LSB
first) 2 bytes Par level being updated (LSB first) 4 bytes New pool value (after award)(LSB
first) 4 bytes Pool amount to award (LSB first) IS 4 bytes Number of prizes remaining (LSB
first) (END REPEATING LIST]
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA) 2 bytes CRC:
Subscriber ID Request A subscriber ID request is used when a terminal needs to register a new player who does not have a NANI
card. It generates a unique, unassigned subscriber ID
that the player's card data can be associated with.
Subscriber ID request packets have no data. The packet header is sufficient to convey the request.
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxOE
2 bytes E'acket Size = 6 2 bytes C;RC
Subscriber ID Response Upon completion, this request will have registered this ID as "allocated but unassigned". When the player registers, the terminal should send in a New Subscriber Event to assign the ID to the player.
Subscriber ID response packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxOF
SUBSTITUTE SHEET (RULE 26) 2 bytes Packet Size = 14 [BEGIN ENCRYPTED AREA]
1 byte Status Code 0 = Success S 1 = Failure 4 bytes Subscriber ID (only present on success) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
Credit/Debit Request This request is issued by a terminal when a player presents a credit or debit card and requests that money be transferred on to the terminal for play, or into the player's account.
IS Credit/debit request packets have the following data structure:
Field Size: Description:

1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x10 2 bytes Packet Size = 46 [BEGIN ENCRYPT ED AREA]

6 bytes Terminal ID requesting the transaction 4 bytes Subscriber ID

2 bytes PIN (LSB first) 15 1 byte Card format (FC from track 1 stripe) 16 bytes Card data (PAN code from track 1 stripe) 4 bytes Expiration date (4 bytes of addition data from track 1 stripe) 2 bytes I>ebit PIN (LSB first, zero for credit cards ) 4 bytes Amount to be withdrawn (in US cents, LSB

first) 1 byte Disposition 0 = Place in subscriber account 1 = Credit local terminal (pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]

2 bytes CRC

The card format, card data and expiration date fields should al.l appear exactly as read from the magnetic strip e on the card. The PIN should be entered by the player fo:r debit cards only.

SUBSTITUTE SHEET (RULE 26) .~
SO
Save State Request This request is used when a player wants to save the state of a game or other service (including the user interface shell) for later restoration (on this or S another terminal).
Save State :request packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 10 1 byte Packet Subtype = 0x12 2 bytes Packet Size = 46 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID on which the state is being saved IS 4 bytes Subscriber ID
2 bytes PIN
4 bytes Service ID
1 byte Slot Number 20 bytes Save State Name 20 (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
This packet :is sent to the server to obtain a File ID. That file ID can then be used to upload the save 25 state file to the server.
Restore State Request This request. is issued when a player wants to restore a state that was saved previously on this or another terminal. The server will return the File ID
30 of the save state file, and if the download flag indicates a download is required, it will download the save state file between the request and the response.
Restore State request packets have the following data structure:
35 Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x14 2 bytes Packet Size = 30 [BEGIN ENCRYPTED AREA] - 17 SUBSTITUTE SHEET (RULE 26) SI
6 bytes Terminal ID on which the state is being restored 4 bytes Subscriber ID
2 bytes PIDI
S 4 bytes Sez-vice ID
1 byte Slot number 1 byte Download flag 0 = Do not download the save state file 1 = Download the file if it exists (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC:
Even if the file exists on the local machine, this request should be, made before the player is allowed to load it, to assure the player is authenticated as the owner of the data, and also to verify the File ID of the save state file as stored in the SUBSCRIBER SAVE STATE table.
ZO Restore State Response When the server received a restore state request, it will search for the saved state data, validate the integrity of the file, and return the file ID to the client. If the client requested a download of the file, the file will be transmitted before the response is returned.
Restore State response packets have the following data structure:
Field Size: Description:

1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x15 2 bytes Packet Size = 14 [BEGIN ENCRYPTED EA) AR

1 byte Status Indicator 0 = Permission to use save state granted 1 = Requested save state not found on server 2 = Subscriber not found on server 3 = Invalid PIN

4 = Service not found on server 5 = Account frozen System error SUBSTITUTE SHEET (RULE 26) 4 bytes File ID (only present if status = 0) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
New Subscriber Card Request This request is used to associate a new card number with an existing subscriber. This allows players to use multiple cards (including their name or name/SSN
combination) to :identify themselves to the network.
This request will succeed only if the new card ID
is unique throughout the entire ADMIN network.
New Subscriber Card request packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x16 2 bytes Packet Size = 38 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
2 bytes PIN
1 byte Card Type J. = ADMIN card 2 = Credit card ~s = Debit card ~! = Name :i = Name and SSN
16 bytes Card Data (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AI~EA]
2 bytes CRC
New Subscriber Card Response When a new subscriber card request is received by the server, it wall validate the uniqueness of the card data and create a new card record for the subscriber, returning the result in this packet.
New Subscriber Card response packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x17 SUBSTITUTE SHEET (RULE 26) 2 bytes Packet Size = 22 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
S 1 byte Status indicator 0 = Card added successfully 1 = Card is registered to another subscriber 2 = Subscriber not found on server 10 3 = Invalid PIN
4 = Card already registered to this subscriber 5 = Account frozen 6 = System error IS (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CR.G
Reserve Merchandise Reserve merchandise request packets are used to 20 reserve an item of merchandise. The requester can specify attribute values for the item, which the server will try to match.
Reserve merchandise request packets have the following data structure:
2S Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x18 2 bytes Packet Size = 38+
[BEGIN ENCRYPTED AREA]
30 6 bytes Terminal ID
9 bytes Subscriber ID
2 bytes PIN
4 bytes Item ID to reserve 4 bytes Quantity to reserve 3S 4 bytes Price offered 1 byte Number of attributes 1 byte Attribute ID
2 bytes Attribute data size Variable: Attribute data 40 (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CR.C
SUBSTITUTE SHEET (RULE 26) Reserve Merchandise Response Reserve Merchandise response packets indicate to the requester whether the reservation was successful, and if so, what: the actual attribute values of the 5 reserved item is. If the requested quantity could not be met, the largest quantity that could be reserved is returned.
Reserve Merchandise response packets have the followi ng data structure:

Field ize: Description:
S

1 byte Packet Type = 0x81 1 byte Packet Subtype = 0x19 2 bytesPacket Size =- 38+

[BEGIN ENCRYPTED AREA]

6 bytesTerminal ID

4 bytesSubscriber ID

4 bytesItem ID being reserved 1 byte Status code 0 Reservation successful ZO 1 No items remain in inventory 2 Invalid request 3 System error 4 bytesQuantity reserved (on success) 4 bytesPrice of reserved items (on success) ZS 6 bytesReservation ID (on success) 1 byte Number of attributes 1 byte Attribute ID

2 bytes Attribute data size Variable Attribute data 30 (Pad crypted area to even 8-byte boundary with zeros) en [END
ENCRYPTED
AREA]

2 bytesCRC

Purchase Merchandise Purchase merchandise request packets are used to 35 purchase merchandise that was previously reserved with a Reserve merchandise query. The requester can specify attribute values for the item, which the server will try to match.
Purchase merchandise request packets have the 40 following data structure:
SUBSTITUTE SHEET (RULE 26) Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxlA
2 bytes Packet Size = 30+
S [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
2 bytes PIa~
6 bytes Reservation ID (on success) 10 4 bytes Purchase price (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
Purchase Merchandise Response 15 Purchase Ma_rchandise response packets verify to the requester that the purchase has been processed by the server and that the money should be deducted from the player's funds (either account fees or cash).
Purchase merchandise response packets have the 20 following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxlB
2 bytes Packet Size = 22 or 30 25 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
1 byte St<~tus code 0 Purchase successful 30 1 No items remain in inventory 2 Invalid request 3 System error 6 bytes Order ID (on success) (Pad encrypted area to even 8-byte boundary with zeros) 35 [END ENCRYPTED AREA]
2 bytes CRC
Release Merchandise Release merchandise request packets are used to release merchandise that was previously reserved with a 40 Reserve merchandise query. The requester can specify attribute values for the item, which the server will try to match.
SUBSTITUTE SHEET (RULE 26) Purchase merchandise request packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 S 1 byte Packet Subtype = OxlC
2 bytes Packet Size = 30 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
10 2 bytes PIN
6 bytes Reservation ID (on success) (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
IS Release Merchandise Response Release merchandise response packets verify to the requester that reserved merchandise has been released.
Purchase merchandise response packets have the following data structure:
20 Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxlD
2 bytes Packet Size = 30 [BEGIN ENCRYPTED AREA) 25 6 bytes Terminal ID
4 bytes Subscriber ID
6 bytes Reservation ID
1 byte Status code 0 Release successful 30 1 Invalid request 2 System error (Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
35 Subscriber Ranking Request A request for a subscriber's current ranking in one or more tournament brackets. This can be used to request ranking in brackets that have ended and are beyond their posting period.
40 Subscriber ranking request packets have the following data structure:
SUBSTITUTE SHEET (RULE 26) Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxlD
2 bytes Packet Size = 30+
5 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID
4 bytes Subscriber ID
2 bytes PIN
1 byte Number of tournament brackets 10 4 bytes Tournament ID
1 byte Bracket ID
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA) 2 bytes CR.C
IS Subscriber Ranking Response The response to the subscriber ranking request packet. This packet contains the subscriber's current position and ranking score in each of the requested tournament brackets that the subscriber has 20 participated in. If the subscriber has not yet played in one of the i_-equested brackets, or the bracket is not found on the server, it will not be included in the list.
Subscriber ranking response packets have the 25 following data structure:
Field Size: Description:
1 byte Packet Type = 0x81 1 byte Packet Subtype = OxlE
2 bytes Packet Size = 22 30 [BEGIN ENCRYPTF',D AREA) 1 byte Status 0 = Query succeeded 1 = Account frozen 2 = Subscriber not found 35 3 = Invalid PIN
4 = System error 4 bytes Subscriber ID
1 byte Number of tournament brackets 4 bytes Tournament ID
40 1 byte Bracket ID
2 bytes Rank 4 bytes Score 4 byte, Score Date and Time (Pad encrypted area to even 8-byte boundary with zeros) SUBSTITUTE SHEET (RULE 26) [END ENCRYPTED AREA]
2 bytes CRC.
Event Packets Event packets are transmitted on sockets connected S to the Event services IP port, or over an asynchronous POS network connection. In either case, they use a transmit-ack lockstep exchange. The client transmits an event packet, the server responds with an Ack. If the server does not respond within 1 second, the client 10 resends the evE:nt packet up to 5 times, then fails and moves on to its next event. If the server sends a Nak, the packet should be resent right away. These timeouts may need to be tuned for Internet-based transmission.
The entire data portion of the event packet is 15 encrypted using the encryption parameters negotiated for the connection.
Alarm Alarm event packets have the following data structure:

20 Field Size: Description:

1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x00 2 bytes Packet Size [BEGIN ENCRYPTED
AREA]

2S 6 bytes Terminal ID of the machine reporting the alarm 2 bytes Alarm code being reported (LSB first).

Currently defined values are shown below.

4 bytes Time the alarm was reported (UTC format, 30 LSB first) 1 byte Flag indicating whether the alarm was handled by the terminal (1 if the terminal handled the alarm with a local handler) 35 2 bytes Alarm data size (LSB first) Variable Alarm data. The content of this field depends on the alarm type. The formats for each defined alarm code are shown below.

(Pad data portion of packet to even 8-byte boundary 40 with zeros) [END ENCRYPTED
AREA]

SUBSTITUTE SHEET (RULE 26) 2 bytes CRC
Alarm Code: Meaning: Data:

1 Hard reset (power up) None S 2 Soft re~~et None 3 Hardware failure ASCII diagnostic message (optional) 4 Firmware failure ASCII diagnostic message (optional) 5 Bill acceptor full None 6 Coin jam None 7 Bill jam None 8 Network disabled None 12 Game time-out None 1S 13 Hard drive full None 18 Printer error None 19 Printer paper low None 22 Cable disconnected ASCII diagnostic message (optional) 23 Security alarm Binary position of switch positions (use 32 bits) 24 Enabled by technician Technician ID enabling terminal 2S 25 Disabled by technician Technician ID

disabling terminal 26 Immediate call requested None 27 Queue entry aged None 29 Serial number changed None Alarm the server as soon as events are queued to they are detected. Alarms of the following types are considered critical and should be transmitted right away:
Hardware failure Firmware failure 3S Bill acceptor full Coin jam Bill jam Printer error Cable disconnected Security alarm Immediate call request Tournament Play Tournament play event packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x01 4S 2 bytes Packet Size SUBSTITUTE SHEET (RULE 26) (BEGIN
ENCRYPTED
AREA]

4 bytes Subscriber ID playing the tournament game (LSB first) 6 bytes Terminal ID on which the tournament game S was played 4 bytes Service ID on which tournament game was played (LSB first) 1 byte Player Station (8 bit flags, position 0 =

station 1, etc.) 10 byte Active Station (8 bit flags, position 0 =

station 1, etc. ) 4 bytes Start Date and Time (UTC format, LSB first) 4 bytes End Date and Time (UTC format, LSB first) 1 byte Flags 1S OxO~. Equipment failed during game 0x02 Score is invalid 0x04 Player should be disqualified 20 byte Number of statistics (n) 4 bytes Statistic ID (LSB first) 4 bytes Statistic Value (LSB first) 1~byte Number of tournament games entered with the 2S play (m) 4 bytes Tournament ID entered (LSB first) 1 byte Bracket ID entered 4 bytes Derived score achieved by subscriber (LSB first) 30 ...
(Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
3S Redemption Play Redemption play event packets have the following data structure;;
Field Description:
Size:

1 byte Packet Type = 0x82 40 byte Packet Subtype = 0x02 2 bytes Packet Size [BEGIN
ENCRYPTED
AREA]

4 bytes Subscriber ID playing redemption game (LSB

first) 4S bytes Terminal ID on which redemption game was played 4 bytes Service ID on which redemption game was played (LSB first) SUBSTITUTE SHEET (RULE 26) 1 byte Player Station (8 bit flags, position 0 =
station 1, etc. ) 1 byte Active Stations (8 bit flags, position 0 =
station 1, etc. ) S 4 bytes Start Date and Time (UTC format, LSB first) 4 bytes End Date and Time (UTC format, LSB first) 1 byte Flags 0x01 Equipment failed during game 10 0x02 Score is invalid 1 byte Number of statistics (n) 4 bytes Statistic ID (LSB first) 4 bytes Statistic Value (LSB first) IS 1 byte Number of redemption games entered with the play (m) 4 bytes Redemption ID (LSB first) 2 bytes Par level beaten (LSB first) 4 bytes Par score beaten (LSB first) 10 4 bytes Derived score achieved by subscriber (LSB first) 4 bytes Pool amount awarded (LSB first) (Pad data portion of packet to even 8-byte boundary 2S with zeros ) [END ENCRYPTED AREA) 2 bytes CRC
Meter Readings Meter readings event packets have the following 30 data structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x03 2 bytes Packet Size 3S [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID on which the meters were collected 4 bytes The date and time meters were collected (in UTC format, LSB first) 40 2 bytes Number of terminal meters included (LSB
first) (n) 4 bytes Terminal Meter ID (LSB first) 4 bytes Terminal Meter Value (LSB first) 4S 2~bytes Number of service meters (LSB first) (m) 4 bytes Service ID of the meter (LSB first) 4 bytes Meter ID of the meter (LSB first) 4 bytes Meter Value of the meter (LSB first) SUBSTITUTE SHEET (RULE 26) (Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CR.G
Terminal manufacturers should support as many of the following pre-defined terminal meter IDs as possible, as well as any additional meters available:
Meter ID: Meaning:

1 Left slot coins in 2 Right slot coins in 3 3rd slot coins in 4 4t" slot coins in 5 Paid credits 6 Total collection (in cents) 7 Service credits 8 Total plays 9 Total uptime (minutes) 10 Number of hard resets 10 11 Number of soft resets Terminal meters should never reset to zero. They should accumulate in 32-bit fields over the lifetime of the terminal. Relative values will be computed between two consecutive readings at the database.
Ad Statistics Ad statistics event packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x82 30 1 byte Packet Subtype = 0x04 2 bytes Packet Size {BEGIN ENCRYPTED AREA]
6 bytes Terminal ID on which the statistics were collected 4 bytes Th.e date and time statistics were collected (in UTC format, LSB first) 2 bytes Number of unidentified ads (n) 4 bytes Target ID (LSB first) 4 bytes Number of plays ...
2 bytes Number of identified ad exposures (LSB
first) (m) 4 bytes Target ID (LSB first) 4 bytes Subscriber ID (LSB first) SUBSTITUTE SHEET (RULE 26) 4 bytes Date and time the ad was played (UTC
format, LSB first) (Pad data portion of packet to even 8-byte boundary S with zeros) [END ENCRYPTEI) AREA]
2 bytes CRC
Ad statistics are accumulated on each terminal and queued at midrGight each night (or whenever the terminal detects the current day has changed, in case it is powered off at: midnight). The packet reports all ad plays for the day. As soon as this packet is queued, the ad play records can be deleted from the terminal, and a new day's record keeping begun. The queued entry must not be deleted until successfully received at the server and acknowledged.
Service Accesses Service accesses event packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x05 2 bytes Packet Size [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID on which the statistics were collected 4 bytes The date and time statistics were collected (:in UTC format, LSB first) 2 bytes Number of service accesses being reported (IaSB first) (n) 9 bytes Service ID being accessed (LSB first) 1 byte Profile used 4 bytes Start date and time of access (UTC
format, LSB first) 4 bytes End date and time of access (UTC format, LSB first) 4 bytes Subscriber ID (LSB first) 4 bytes Cash funds used (LSB first) 4 bytes Account funds used (LSB first) ...
(Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
SU1BSTITUTE SHEET (RULE 26) 2 bytes CRC
This packet tracks all accesses to any service on the terminal. Each time a player plays a game or engages in a session in any other service, the data S should be stored. This packet should be generated each evening at midnight for the day's service accesses (or whenever the terminal detects the current day has changed).
Down Time Down time event packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x06 1S 2 bytes Packet Size [BEGIN ENCRYPTED AREA) 6 bytes Terminal ID on which the down times are being reported 4 bytes The date and time down times were reported (in UTC format, LSB first) 2 bytes Number of down times being reported (LSB
first) (n) 4 bytes Technician ID responsible for the down time (LSB first) 2S 4 bytes Start date and time of down time (UTC
format, LSB first) 4 bytes End date and time of down time (UTC
format, LSB first) (Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREAJ
2 bytes CRC
This packet tracks all down times experienced by a 3S terminal. Games should periodically update some non-volatile timest~amp while they are running, and then test this valuE: on powerup to see how long the power outage was, and report this as down time. When a technician administratively takes the game down through a service menu, this is also logged in this packet.
SUBSTITUTE SHEET (RULE 26) WO 00/38089 PCT/CA99l01201 b5 This packet should be generated each evening at midnight for the day's down times (or whenever the terminal detects the current day has changed).
New Subscriber New subscriber event packets have the following data structure:
Field Size: Description:

1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x07 2 bytes Packet Size [BEGIN ENCRYPTED
AREA]

6 bytes Terminal ID on which the subscriber registered 4 bytes Subscriber ID being registered (LSB first) 26 bytes Alias entered by the subscriber 26 bytes Street address entered by the subscriber 10 bytes Postal code entered by the subscriber 10 bytes Phone number entered by the subscriber bytes First name entered by subscriber 20 20 bytes Last name entered by subscriber 2 bytes Middle initial entered by subscriber 1 byte Birth day entered by subscriber 1 byte Birth month entered by subscriber 2 bytes Birth year entered by subscriber (LSB

first) 1 byte Gender entered by subscriber (0 = male, 1 - female) 9 bytes SSN entered by subscriber 2 bytes PI:~1 entered by the subscriber 1 byte Number of cards to register 1 byte Card Type 1 = ADMIN card 2 = Credit card 3 = Debit card 4 = Name 5 = Name and SSN

16 bytes Card Data (Pad data porti.an of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
New subscriber events are queued when players register a new card. They are queued at the time the data is entered, but do not need to be sent right away.
SUBSTITUTE SHEET (RULE 2b) However, if the player subsequently plays any games that generate queue entries, the terminal must ensure that this event. is transmitted to the server before any game plays for that player. This is to ensure that the 5 server has established an account for the player before attaching a game play to it.
Any of the registered cards that are included in the packet than already exist on the server or fail for some other reason will be skipped, but the subscriber 10 will be created regardless. A card of type "NANI Card"
with a card ID equal to the value of the subscriber ID
will be created automatically.
New Team New team event packets have the following data 15 structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x08 2 bytes Packet Size 20 [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID on which the subscriber registered 4 bytes Subscriber ID of team being registered (LSB
first) 25 26 bytes Alias entered by the team 2 bytes PIN entered for team 1 byte Number of members 4 bytes Subscriber ID
1 byte Flags 30 ...
(Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC

New team events are queued when teams register.
They are queued at the time the data is entered, but do not need to be sent right away. However, if the team subsequently plays any games that generate queue SUBSTITUTE SHEET (RULE 26) entries, the terminal must ensure that this event is transmitted to~ the server before any game plays for that team. This is to ensure that the server has established an account for the team before attaching a 5 game play to it.
Issued Coupons Issued coupons event packets have the following data structure:
Field Size: Description:

10 1 byte Packet Type = 0x82 1 byte Packet Subtype = 0x09 2 bytes Packet Size [BEGTN ENCRYPTED
AREA]

6 bytes Terminal ID on which the down times are IS being reported 2 bytes Number of coupons being reported (LSB

first) (n) 4 bytes Coupon ID issued (LSB first) 4 bytes Subscriber ID coupon was issued to (LSB

20 first) 4 bytes Date and time coupon was issued (UTC

format, LSB first) 6 bytes Receipt ID

1 byte Flags 25 ...

(Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED
AREAJ

2 bytes CRC

30 This packet tracks all coupons issued by a terminal. his packet should be generated each night T

at midnight for the day's coupons (or whenever the terminal det ects the current day has changed).

Loyalty Point Awards 35 Loyalty point award event packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x82 1 byte Packet Subtype = OxOA
40 2 bytes Packet Size [BEGIN ENCRYPTP;D AREA]
SUBSTITUTE SHEET (RULE 26) 6 bytes Terminal ID on which the awards are being reported 2 bytes Number of awards being reported (LSB first) (n) S 4 bytes Subscriber ID receiving the award (LSB
first) 4 bytes Loyalty Program ID (LSB first) 2 bytes Number of points awarded (LSB first) 4 bytes Date and time the award was made (UTC
10 format, LSB first) (Pad data portion of packet to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
15 2 bytes CRC
This packet tracks all loyalty points awarded by a terminal. This packet should be generated each evening at midnight for the day's awards (or whenever the terminal detects the current day has changed).
20 Synchronization Packets Inventory Inventory packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x83 25 1 byte Packet Subtype = 0x00 2 bytes Packet Size [BEGIN ENCRYPTED AREA]
6 bytes Terminal ID issuing the request (or 0 for server inventories) 30 2 bytes System software version (LSB first) 2 bytes Number of records (LSB first) (n) 1 byte Table ID the record belongs to 4 bytes Record ID
35 2.bytes Ntunber of files (LSB first) (m) 4 bytes File ID (LSB first) 2.bytes Number of content objects (LSB first) (m) 4 bytes Content ID (LSB first) 40 ...
(Pad encrypted area to even multiple of 8 bytes) [END ENCRYPTED AREA]
2 bytes CRC
SUIBSTITUTE SHEET (RULE 26) Data is guaranteed to be in order of ascending table ID, but not necessarily in order of ascending record ID within each table ID.
Table Download S Downloaded. table records are inserted directly into the database, using the record ID as a key. Any existing records with the same record ID are overwritten. A table download packet with 0 records is used to indicate no more data.
10 Table download packets have the following data structure:
Field Size: Description:
1 byte Packet Type = 0x83 1 byte Packet Subtype = 0x01 15 2 bytes Packet Size [BEGIN ENCRYPTED AREA]
1 byte Table ID being downloaded 2 bytes Number of records (LSB first) (n) 6 bytes Record ID of a record in the table (LSB
20 first) 2 bytes Record data size (in bytes, LSB first) Variable Record data (Pad encrypted area to even multiple of 8 bytes) 25 [END ENCRYPTED AREA]
2 bytes CR.C
File Initial Download File Initial Download packets have the following data structure:
30 Field Size: Description:
1 byte Packet Type = 0x83 1 byte Packet Subtype = 0x02 2 bytes Packet Size [BEGIN
ENCRYPTED
AREA]

35 bytes File ID being downloaded (LBS first) 9 bytes Total file size (LSB first) 4 bytes File flags (compression info, permissions, etc. - TBD) 2 bytes Number of segments (LSB first) 40 byte Path length Variable pathname on local machine (Pad encrypted area to even multiple of 8-bytes) SUBSTITUTE SHEET (RULE 26) [END ENCRYPTED AREA) 2 bytes CRC
File Next Download File Next Download packets have the following data S structure:
Field Size: Description:
I byte Packet Type = 0x83 1 byte Packet Subtype = 0x03 2 bytes Packet Size 10 [BEGIN ENCRYPTED AREA]
4 bytes File ID being downloaded (LBS first) 2 bytes Segment number (LSB first) 2 bytes Segment data size (LSB first) Variable Segment data 15 (Pad encrypted area to even multiple of 8-bytes) [END ENCRYPTED AREA]
2 bytes CF;C:
File Initial Upload File Initial Upload packets have the following data ZO structure:
Field Size: Description:

1 byte Packet Type = 0x83 1 byte Packet Subtype = 0x04 2 bytes Packet Size ZS [BEGIN ENCRYPTED
AREA]

4 bytes File ID being uploaded (LBS first) 4 bytes Total file size (LSB
first) 4 bytes File flags (compression info, permissions, etc. - TBD) 30 2 bytes Number of Segments (LSB first) 1 byte Filename length Variable Filename (Pad encrypted of 8-bytes) area to even multiple [END ENCRYPTED
AREA) 35 2 bytes CRC

Retrieve File A request to transfer a file to a client if the client's version of the file is missing or out of date.
Retrieve file s-equest packets have the following data 40 structure:
Field Size: Description:
1 byte Packet Type = 0x81 SUBSTITUTE SHEET (RULE 26) 1 byte Packet Subtype = OxlF
2 bytes Packet Size = 22 [BEGIN ENCRYPTED AREA]
1 byte File Type S 0 = Content 1 = Service file 4 bytes File ID
4 bytes Current file size 4 bytes Current file modification date 10 2 bytes Current file CRC
(Pad encrypted area to even 8-byte boundary with zeros) [END ENCRYPTED AREA]
2 bytes CRC
Retrieve File Response IS This packed is sent to the client immediately if the requested file is up to date, or does not exist, or after a series of file download packets if the file needs to be downloaded.
Retrieve Bile request packets have the following 20 data structure:
Field Size: Description:

1 byte Packet Type ~- 0x81 1 byte Packet Subtype = 0x20 2 bytes Packet Size = 22 25 [BEGIN ENCRYPTED
AREA]

1 byte Status 0 = File downloaded successfully 1 = Current file is up to date 2 = Error downloading 30 3 = File not found 4 = System error 4 bytes File ID

4 bytes Current file size 4 bytes Current file modification date 35 2 bytes Current file CRC

(Pad encrypted to even 8-byte boundary with zeros) area [END ENCRYPTED
AREA]

2 bytes CR.C

40 For the synchronization function, assuming that the inventory of a customer is being downloaded, e.g. from a database associated with a regional server to a database associated with an arcade, public PC or SUBSTITUTE SHEET (RULE 2G) validation and redemption terminal, the packets can add a field (e. g. 4 bytes) which identifies the customer.
The administration terminal 43 contains a database which specifies the entire system, in subdatabases S which can be specified as classes. The content of the complete database, or the content of each subdatabase can be specified by a single administration entity, or any can be specified by authorized suppliers. In the latter case, the content of the subdatabases can be filled by communication between the terminal 43 and suppliers' terminals, using the system shown in Figure 1.
Subdatabases are preferred to relate to the following:
Suppliers Locations Game Machines Game Software Redemptions Tournaments Merchandise Categories Pricing Prizes Alarms Schedules Manufacturers Customers Technicians Advertising Content Coupons Loyalty Programs Promotions Services Profile Descriptor (e. g. VALs) VALT"' is a standard profile descriptor which has been adopted by some companies. VALs or class systems used by other companies can be stored and used in addition to or as a replacement for the demographic classification described herein.
Game Software is an example of the above. A
field of the above can be the identification of a game which is located on a CD ROM, hard disk drive, DVD or SUBSTITUTE SHEET (RULE 26) mass semiconductor or other storage means at a game location. Another field can be an algorithm which controls the parameters of the game. Another field can store score brackets which a player must reach in order to win a prize. Another field can store timing information which can be used to modify the brackets.
Other fields can be filled with other data required for the game.
The other subdatabases can be similarly filled with data to specify the operation of each parameter of the system. For example, a merchant can specify a premium related to the merchant's store as a prize to the player of a game at an arcade nearby to the store.
A field in the prize or coupon subdatabase can point to IS the game or games for which the premium or coupon is to be distributed, another can specify a score bracket to be achieved (which can be >0) by the player in order to win the premiwn or coupon, etc.
Once the database has been completed to a required level, the subdatabases are downloaded to the decision support server 7, which stores it in its database 9. The decision support server then downloads the data as re:Lated to the various peripheral terminals to the associated regional servers, which in turn stores required data in their respective databases 5A
to 5N, and downloads the data related to the respective terminals to those of concern.
As a further example, regional server 5A
downloads initialization parameters to the master games 21 in the arcades in which authorized game machines are located which c:an communicate with the regional server 5A. It also downloads initialization parameters to the software at the' public PCs with which it can SUBSTITUTE SHEET (RULE 26) communicate, which have been authorized at the administration location.
For example, the initialization parameters may initialize or authorize operation of particular video S games, with particular score brackets, at the arcade 17 and at the public PC. The initialization parameters may also initialize a program at the public PC which controls acceptance of payments, and/or acceptance of orders for merchandise, and/or redemption of premiums, etc., and also controls transmission of data to the regional server which updates the account of the customer in currency or other media of exchange such as loyalty points, etc.
Table 1 which is attached at the end of this 1S specification describes preferred subdatabases to be established initially at the administration terminal, which specify games, software, advertisements and other matters, and their parameters, which are downloaded to the terminals i.n a manner as described above. Each of the subdatabase~s is headed by a table name, and each of the fields describes the content of the field; its content and uses are self evident from the name chosen.
It was noted above that parameters can be downloaded for the operation of a game. The shell of a 2S game can have a. requirement for score formulae to be inserted. The score formulae can be determined at the administration terminal, and downloaded as noted earlier, as one or more parameters of the game.
For example, consider the Pacmant"' game. Key graphical elements of the game are. dots, fruits, ghosts, and the game requires a scope. These elements can be used in formulae; for example the dots can be SUBSTITUTE SHEET (RULE 26) given a statistic 500, the fruits a statistic SO1, the ghosts a statistic S02 and the scope a statistic S03.
A formula can be determined, e.g. (S00 + 5) S03 to determine an output score for dots, for example.
5 The formulae can be modified by a player rating, the player having been identified by his ID card that has been swiped. The formulae can be modified by the time of day, the number of games played in a certain time interval, the score brackets achieved by players in a 10 certain time interval, etc.
Indeed, a game can be refreshed by formulae which change the object of a game. An easy game can be made more difficult or different based on the formulae for a particular player profile.
15 Loyalty points, coupons or other prizes can be awarded based on different formulae. These can be specified by different suppliers' terminals interacting with the administration terminal, or solely at the administration terminal.
ZO Prizes can be awarded based on a history of plays at a particular location. Par level and score brackets can b~e automatically adjusted. With reference to Figure 3, a histogram is shown of scores of a game against the number of plays achieving the scores.
ZS Within the region A, the top 10$ of scores occur.
Within the region B, the next 20$ of scores occur, and within the region C, the next 30$ of scores occur. A
supplier determines, through the administration terminal, that the best prizes should be awarded for 30 the scores in :region A, the next best prizes for the scores in region B, and the lowest prize for the scores in region C.
SUBSTITUTE SHEET (RULE 26) The software can store the scores, and supply the scores to t:he game shell software to adjust the regions A, B and C, depending on how well and how many players play, wind the history of prize redemptions at ~S the particular game location, as specified by parameters input at the administration terminal. This can consist of adding the scores together, and if there have been prize redemptions in excess of a predetermined number established at the administration 10 terminal, skewing the scores, or multiplying the scores, by a number or game handicap value. This process of skewing, in effect varies the shape and placement of tree curve shown in Figure 4, and provides an automatic par or bracket adjustment for the game.
15 The software can also keep track of a player's score on a particular game and store it in the player's database. and c;an forbid the awarding of a prize to the player for a particular game within a certain time interval or within a certain arcade. This will stop a 20 good player from collecting too many prizes or too large a prize on a single machine if the number of players is low, or if the player monopolizes a game.
A key aspect of the system is to control the advertising she>wn to specific subscribers. Advertising 25 can be shown in "slots", e.g. frames on a video game or public PC display. The administrator can specify advertisement types as indicated in the matrix of Figure 4 as "Act Target Types to Play", i.e. types of ads for specific matched demographic player types. The 30 first column in the matrix specifies "When To Play".
For example, when no player is present, advertisement types "0x00" followed by "Location Attract", follc9wed by "Terminal Attract (for this SUBSTITUTE SHEET (RULE 26) terminal's ID or a broadcast ID)" are specified. When an unidentified player is present (e.g. by detecting a body using an infrared detector), but no service has been selected, an additional advertisement "0x01" is run immediately following advertisement "0x00".
The entire matrix is filled out at an administrative location and is stored at the administration terminal 43 database, and once complete, it is downloaded to the decision support server 7, and stored in its database 9. It is then downloaded to the regional server, where it is stored in database 5A, and is downloaded 1:o the master game 21, where it is stored in database 23.
The master game 21 then controls the local DVD
or CD ROM in accordance with the local condition (when to play), to run the advertisements identified in the matrix.
One of the parameters that can be used in an advertisement subdatabase is a demographic limit. For example, a field parameter can specify that playing of an advertisement for a toy doll can be logically nulled in the event that the location of the game, or the location of the: identified player, is in a bar. This information can be downloaded with the initialization data for an advertisement and/or for a player.
Once playing is initialized, the advertisement specified in the database matrix or the equivalent stored at the database 23 of the master game 21 is indicated to the game shell to be loaded from the DVD
or CD ROM. The' game shell inserts the advertisement into a time slot and window (or full screen) on the game (or public: PC or other form of) display. Unless the presence of a player, identified or not, has been SUBSTITUTE SHEET (RULE 26) detected (e.g. detected by an infrared detector, by swiping of a p7Layer's card in a card reader, by detection of a bar code of a coupon or premium by a bar code reader at a validation and redemption center, or by detection of a personal characteristic such as handwriting, voice, fingerprint, palmprint, iris, etc.) once display oi= the advertisement has been completed, the master game (or public PC) software accesses the database matrix; or the equivalent and causes the next advertisement t:o run via the shell and be displayed.
In the event the presence of a subscriber, or of an identified :>ubscriber, is detected, the master game (or public PC) software accesses the advertisement matrix in the database 23, and determines that a different schedule of advertisements should be run. It then indicates which is the first of the advertisements in this schedule, and causes it to run via the shell, as described above.
It will be recognized that a player will typically interrupt an attraction mode advertisement by indicating that: he wishes to play a game, e.g. by swiping his card in the card reader of a game, or by depositing coins in the coin acceptor of the game and keying in an identification code. The game software will then indicate this to the master game, which stores an indication in the indicated subscriber's database the identity of the last complete advertisement that the subscriber has seen. This is stored in the gable "SUBSCRIBER AD", under "AD ID" (See Table 1 located at the end of this specification).
When the subscriber is next indicated as being present at a viewabie location, and is not playing a game, the next advertisement in the sequence indicated on the SUBSTITUTE SHEET (RULE 26) matrix is controlled by the master game or public PC to be displayed.
It will be noted from Table 1 that the record:
table = "Ad Target" contains fields which specify the S minimum and maximum daily exposures, and the minimum and total daily exposures of an advertisement. These values can be based on sales of the advertisement, and are specified by the administrator.
Considering the tables of the database relating to the advertising, in the table AD, - the first field RECORD-ID stores the record number, - the field AD~_ID stores the identity of the advertisement, - the field CODITENT ID identifies the files) that make 1S up the advertisement (video clips, audio, image, etc.), - the field PRECEDING AD ID identifies the advertisement to be run immediately preceding this one, - the field NEhT AD ID identifies the advertisement to be run immediately following this one, - the field MA~:VVIEWS-PER PERSON specifies the maximum number of timea the present advertisement should be shown to an identified subscriber, - the field FLAGS can be used to for various purposes, such as inhibiting a specified ad from playing e.g.
2S inhibiting plays from bars, casinos, arcades, general audiences, men, women, male teens, female teens, etc.
With the above detailed explanation of the first table, the remaining tables (records) and fields are believed to be self-explanatory from the names given to the tables and to each of the fields.
It should also be noted that advertisements can be selected based on an algorithm. For example, a random number (e.g. between 0 and 9, say 5) can be SUBSTITUTE SHEET (RULE 26) obtained from a random number generator. That random number 5 can identify e.g. a video or slide advertisement to be run. Following running, that random number can be added to another predetermined 5 number (e.g. 3)~, to identify the next advertisement to be run, e.g. advertisement number 8. Following running of advertisement number 8, that number can be added to another predetermined number (e.g. 7), to identify the next advertisement to be run, e.g. advertisement number 10 15, etc. The selection of which advertisement to run can cycle back to the beginning, or once a predetermined highest number has been reached, another random number c:an be selected and the process started again.
IS It may :be seen that the identity of advertisements that are selected for playing have been filtered through a schedule of particular advertisements. It is preferred that they should also be filtered by exclusions, for unsuitable 20 advertisements. For example, cigarette advertisements or advertisements containing unsuitable subject matter can be excluded from certain locations, and competitor's products can be excluded from certain locations. These exclusions (URCs) can be stored in 25 the table = AD URC.
The field RECORD ID in this table stores the record identity. The field AD_ID stores the identity of the advertisement against which the URC is to be applied. The U~RC can be comprised of a data field 30 illustrated in Figure 5.
The numeric value indicates the URC restriction code number. The bit in the flag indicates IS or N0, depending on whether it is set or not. The code (e. g.
SUBSTITUTE SHEET (RULE 26) the number 1, 2, etc.) indicates the restriction. For example, the code 1 can mean "underage". Thus for example, if the advertisement indicated in the field AD ID in the table AD URC is unsuitable for a person S under the age o~f 19, the flag is set (i.e. indicates IS). If an underage person such as age 17 years (as can be indicated by his identity on e.g. the swipe card and his age statistic taken when the subscriber is first registered) is indicated as being at a particular location by him swiping his card at a validation and redemption center, a public PC or at a game in an arcade, for example, the advertisement is filtered through the URC, and is not shown for a time period.
The time period can be a predetermined interval, or until a game played by the subscriber has been terminated, or can last for a time following termination of the game.
It will be recognized that rather than advertisements, messages of any type can be provided for presentation to a person, and the URCs described above are equa:Lly applicable against such messages. In this specification, the term advertisements should thus be construed to include messages of any type, and presented in any way, such as by still picture, video, audio, etc. The term display should also be construed to include any form of presentation, including audio, video, tactile,, odor dispersion, etc.
A customer may attend a validation or redemption terminal location at the location of a merchant, or at an arcade, or at the location a public PC, and wish to enter credits, or wish to be registered in the system.
Entering of credits can be effected by an attendant keying in relevant information to a terminal, SUBSTITUTE SHEET (RULE 26) sufficient to identify the person, e.g. name and address, etc., or the customer can perform the same function via an automatic terminal such as a card vending machine which provides instructions how to proceed. If there are no credits to be entered, the customer should choose a PIN number, which is recorded in a hidden manner (such as in a magnetic stripe or in the memory of a "smart card" carried on the card), and the card is di~~pensed or personally given to the customer. If ~~ currency credit is to be posted, the customer will pay the attendant or deposit money into the card vending machine, which is recorded against the identity of then customer. The data entered into the terminal is then uploaded to the regional server e.g.
lA, and is stored in its associated database SA.
The customer now will undertake certain activities, such as purchasing goods or services from any of the merchants registered in the system, or play games at the arcade. If the customer plays games at the arcade, and wishes to use the credit balance in his account to pla~r, he will swipe his card in a card reader at the game, which identifies him and the value to be debited from his balance. If he wishes to purchase goods or services against his credit, or purchase a different service offered at the public PC
(e.g. purchase printing or communication services) his card will be swiped in a card reader at the location of the merchant where he wishes to purchase the goods or services or at the public PC.
In any such case, the identity of the customer, the location o:f the customer, the identity of the merchant, game or public PC, and the amount of the debit will be uploaded into and stored in the database SUBSTITUTE SHEET (RULE 26) 5A after being recorded at the location (e.g. in database 23 if the transaction occurred at the arcade).
The administrator had already entered into its database using terminal 43 loyalty point values for certain activities, which had been downloaded and stored at database 9, and then loaded to databases 5A..5N. Therefore for each activity undertaken by the customer for which loyalty points are to be awarded, they are credited to the customer's account stored in the customer's database of the regional server. These loyalty points can then be used as a form of scrip by the customer, apart from, or with cash deposits.
In addition, the administrator can specify and store records in the aforenoted databases that premium IS coupons should :be dispensed for the customer at the determined location of the customer via a local printer, for defined activities undertaken by the customer.
Loyalty points, game credits for future play ZO and/or coupons can also be awarded to the account of the customer and/or dispensed when predetermined scores or score brackets are achieved on the games (whether due to individual play or in tournaments) by the identified customer player.
25 The amounts of the loyalty points, game credits or coupons can be varied by time, by location, by number of players having played the game or tournament within a certain time interval or within certain clock times, by number of players, by demographic of the 30 player, by difficulty of the game, by game handicap, etc. All such variations can be established at the administration location by means of a matrix (or form) to be filled in, such as shown in Table I attached SUBSTITUTE SHEET (RULE 26) hereto and forming part of this specification, and stored in the databases as described above. Indeed, the administrator can indicate a conversion of loyalty points to currency, for redemption or for use to S purchase goods of particular ones or of any goods or services provided by member merchants.
When a customer wishes to redeem a coupon, the customer presents it to a merchant, public pc operator, public pc, etc., its bar code is read by a bar code 10 reader at a validation and redemption terminal, and the customer's identification is read from his card by a card reader, at the validation and redemption terminal.
The identification (and value, if desired for greater security) of the coupon is uploaded to the regional 15 server, and the database is accessed using the identification of the customer. The identity of the coupon is then checked in the customer's record, and if the coupon had been validly recorded, a message is sent to the validation and redemption terminal acknowledging 20 the validity of the transaction. An acknowledgement is entered into the terminal and is uploaded to the regional server, which either marks the coupon record as having been used, or deletes it from the customer's record. In either case, information of the awarding, 25 and subsequently of the redemption of the coupon, is entered to database 9 via the decision support server, to provide a statistical report to terminal 43 either immediately or from time to time as to volumes and identities of services used by the customer or by 30 groups of customers, by demographics, etc. and coupons and loyalty points awarded and redeemed, and the identity of the merchant or terminal performing the redemption.
SUBSTITUTE SHEET (RULE 26) These statistics provide a good measure for the administrator to be able to use for reporting and/or advertising of the benefits of the system to prospective merchants and others which may wish to S advertise on the system or which may wish to include their goods, services and locations as part of the system. In addition, it provides the information to the administrator for settling the merchants' accounts, as described earlier. The loyalty points thus have 10 been used as a medium of exchange separate from currency.
It should be noted that while the description herein is to a client-server type system which communicate in a particular manner, the equivalent 15 function and structure of the invention could also be realized by persons skilled~in the art understanding this invention 'via one or more browsers which interface one or more web pages, either via the Internet or on one or more intranets which are either self-contained 20 or which communicate via the Internet or via private network.
A person understanding this invention may now conceive of alternate embodiments and enhancements using the principles described herein. All such 25 embodiments and enhancements are considered to be within the spirit and scope of this invention as defined in the claims appended hereto.
SUBSTITUTE SHEET (RULE 26) # initdb.ini # NOTES:
# 1. Database name cannot exceed 23 characters # 2. Allowed data type are LONG, SHORT, BIN, VARBIN
# 3. Table names cannot exceed 23 characters # 4. Field names cannot exceed 23 characters # 5. Arrays of SHORT and LONG are not supported (set size = 1) # 6. Variable binary fields as primary keys is not supported # 7. Each table can have only one variable binary field # 8. Variable binary field must be last field in table # 9. Variable binary field must be preceded by SHORT
size field # 10. File created will be database name with ".db"
appended # 11. Tables cannot exceed 32 fields DATABASE = nani TABLE - AD

FIELD ID . BIN . 6 .
- RECO1~D PK

FIELD _ . LONG . 1 ID
- AD

FIELD _ . LONG . 1 - CONTENT_ID

FIELD - PRECEDING_AD . LONG . 1 ID

FIELD _ . LONG . 1 - NEXT AD_ID

FIELD VIEWS_PER . SHORT . 1 PERSON
= MAX

FIELD _ . BIN . 1 _ - FLAGS

TABLE SCHEDULE
- AD

FIELD _ . BIN . 6 .
- RECORD_ID PK

FIELD - AD . LONG . 1 ID

FIELD _ . BIN . 6 ID
- TERM:INAL

FIELD _ . LONG . 1 - SCHEDULE_ID

FIELD - FLAG;S . BIN . 1 TABLE T.'~RGET
- AD

FIELD _ . BIN . 6 .
- RECORD_ID PK

FIELD - TARGET_ID . LONG . 1 FIELD I:D . LONG . 1 - AD

FIELD _ . BIN . 1 TYPE
- TARGET

FIELD _ . LONG . 1 - TARG:ET_EVENT_ID

FIELD - TARG:ET_SERVICE ID . LONG . 1 FIELD - SLOT . BIN . 1 SUBSTITUTE SHEET (RULE 26) FIELD PRIORITY . BIN .
= 1 FIELD - MIN_DAILY_EXPOSURES . SHORT .

FIELD - MAX_DAILY_EXPOSURES . SHORT .

FIELD - MIN TOTAL . LONG .

FIELD _ . LONG .
- MAX_'.~OTAL_EXPOSURES I

FIELD - FLAGS . BIN .

TABLE - AD
TARGET
DEMOGRAPHIC

FIELD _ . BIN . .
_ 6 PK
- RECORD_ID

FIELD - TARGET_ID . LONG .

FIELD - DEMOGRAPHIC . LONG .

FIELD - FLAGS . BIN .

TABLE - AD
TARGET PROMOTION

FIELD _ . BIN . :PK
- RECOFtD_ID~ 6 FIELD - TARGET_ID . LONG .

FIELD - PROMOTION ID . LONG .

FIELD - FLAGS ~ . BIN .

TABLE - AD
URC

FIELD _ . BIN . .
- RECORD_ID 6 PK

FIELD - AD . LONG .
ID Z

FIELD _ . LONG .

FIELD - FLAGS , BIN .

TABLE - ALARM
HANDLER

FIELD _ . HIN . .

ID

FIELD _ . LONG .

ID

FIELD _ . BIN .

CODE

FIELD _ . BIN .

FIELD - PROCESS . BIN .

FIELD _ . BIN
- FLAGS

FIELD PROCESS . SHORT .
= DATA Z
SIZE

FIELD _ . VARBIN .
= _ 1 PROCESS DATA

TABLE - BRACKET

FIELD - RECORD . BIN . .
ID fi PK

FIELD _ . LONG .
= TOURN1~MENT 1 ID

FIELD _ . BIN .
= BRACICET ID 1 FIELD - SHOR'r . BIN .

FIELD __ . BIN .

FIELD - STAR'r_DATE . LONG .

FIELD _ . LONG .

- END
DATE

FIELD _ . LONG .
_ 1 - SCORE POSTING
TIME

FIELD _ . LONG .
- ENTR'Y 1 ~PRICE

FIELD _ . SHORT .
- PREP~AID_PLAYS 1 FIELD PLAYER . SHORT .

GAMES
PER

FIELD _ . SHORT .
_ 1 _ PLAYER
= MAX
GAMES
PER

FIELD _ . SHORT .
_ 1 _ - MIN GAMES
TEAM
PER

FIELD _ . SHORT .
_ 1 = MAX GAMES PER TEAM

SUBSTITUTE SHEET (RULE 26) FIELD - LEADERBOARD_ID . LONG . 1 FIELD - SPONSER . BIN . 40 FIELD - ICON . LONG . 1 FIELD - SPLASH_SCREEN . LONG . 1 FIELD - FLAGS . BIN . 1 FIELD - RANKING ALGORITHM . BIN . 1 TABLE - BRACKET_ADVANCE

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD = TOURNAMENT_ID . LONG . 1 FIELD - BRACKET_ID . BIN . 1 FIELD - ADVANCE_TYPE . BIN . 1 FIELD - FROM_TOURNAMENT_ID . LONG . 1 FIELD - FROM_BRACKET_ID . BIN . 1 FIELD = FROM_LOW . LONG . 1 FIELD - TO_HIGH . LONG . 1 FIELD - SERVICE_ID . LONG . 1 FIELD - PROFILE . BIN . 1 FIELD - FLAGS . BIN . 1 TABLE - BRACKET
MEMBERSHIP

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - TOURNAMENT_ID . LONG . 1 FIELD - BRACKET_ID . BIN . 1 FIELD - SUBSCRIBER . LONG . 1 ID

FIELD _ . BIN . 1 - FLAGS

TABLE - BRACKET_PRIZE

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD = TOURNAMENT_ID . LONG . 1 FIELD ID . BIN . 1 - BRACKET

FIELD _ . LONG . 1 - PRIZE_ITEM
ID

FIELD = _ . BIN . 1 PRIZE_PERCENT_OF
POOL

FIELD _ . BIN . 1 - WINNING_PLACE

FIELD NAME . BIN . 20 - PLACE

FIELD _ . LONG . 1 = NUM_WINNERS

FIELD - EXPIRATION_DATE . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - BRACKET_PROMOTION

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TOURNAMENT_ID . LONG . 1 FIELD - BRACKET_ID . BIN . 1 FIELD = PROMOTION_ID . LONG . 1 FIELD - FLAGS . BIN . 1 FIELD - MIN RANK . SHORT . 1 TABLE - BRACKET_RULE
SCREEN

FIELD _ . BIN . 6 PK
= RECO~RD .
ID

FIELD _ . LONG . 1 - TOURNAMENT ID

SUBSTITUTE SHEET (RULE 26) FIELD = BRACKET_ID . BIN . 1 FIELD - SERV:ICE_ID . LONG . 1 FIELD - SCREEN_INDEX . BIN . 1 FIELD - CONTENT_ID . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - BRACKET_SCHEDULE

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TOURNAMENT_ID . LONG . 1 FIELD - BRACKET_ID . BIN . 1 FIELD - TERMINAL ID . BIN . 6 ~

FIELD - SCHEDULE . LONG . 1 _ID

FIELD - FLAGS . BIN . 1 FIELD - NUM (LOCAL LEADERS . SHORT . 1 TABLE - BRACKET_SERVICE

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TOURNAMENT_ID . LONG . 1 FIELD - BRACI:CET_ID . BIN . 1 FIELD - SERV:ICE_ID . LONG . 1 FIELD - PROF;ILE . BIN . 1 FIELD - PRIC:ING_ID . LONG . 1 FIELD - FLAGS . BIN . 1 FIELD I~ATING . BIN . 1 - MIN
ALLOWED

FIELD _ . BIN . 1 - _ - MAX DATING ALLOWED

TABLE - CAT.A:GOG_CATEGORY

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - CATEIaORY ID . LONG . 1 r FIELD - CATEL;ORY . BIN . 40 NAME

FIELD _ . LONG . 1 - PAREIVT_CATEGORY_ID

FIELD - ICON . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - CATA:LOG_CATEGORY_URC

FIELD ID . BIN . 6 PK
- RECORD .

FIELD _ . LONG . 1 - CATEGORY_ID

FIELD - URC . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - CONTENT

FIELD - RECORD . BIN . 6 PK
ID .

FIELD _ . LONG . 1 - CONTENT_ID

FIELD - FORMAT . BIN . 1 FIELD - DURATION . LONG . 1 MS

FIELD _ . BIN . 60 - PATHNAME

FIELD - FILE SIZE . LONG . 1 ~-FIELD - CRC . SHORT . 1 FIELD TIMESTAMP . LONG . 1 - FILE

FIELD _ . BIN . 1 - FLAGS

SUBSTITUTE SHEET (RULE 26) TABLE - COUPON

FIELD - ID . BIN . 6 RECORD

FIELD - _ LONG . 1 COUPON-ID .

FIELD - DESCRIPTION . BIN . 40 FIELD - TD . LONG . 1 CONTENT

FIELD - _ . BIN . 12 SYMBOL
UPC

FIELD - _ . LONG . 1 FACE
VALUE

FIELD - _ . SHORT . 1 PER PLAYER
~ISSUED
MAX

FIELD - _ . BIN . 1 _ FLAGS

TABLE - ITEM
SCHEDULE
COUPON

FIELD - _ . BIN . 6 PK
_ .
RECORD
ID

FIELD - _ . LONG . 1 ID
COUPON

FIELD - _ . LONG . 1 ID
ITEM

FIELD - _ . BIN . 6 TERMINAL
ID

FIELD - _ . LONG . 1 ID
SCHEDULE

FIELD - _ . LONG . 1 CASH
VALUE
COUPON

FIELD - _ . LONG . 1 _ COUPON
PRICE

FIELD - _ . SHORT . 1 ITEMS
PER
COUPON
NUM

FIELD _ . SHORT . 1 _ _ REDEEMED
- MAX

FIELD _ . BIN . 1 - FLAGS

TABLE SERVICE
SCHEDULE
- COUPON

FIELD _ . BIN . 6 PK
_ .
- RECORD
ID

FIELD _ . LONG . 1 ID
- COUPON

FIELD _ . LONG . 1 - SERVICE
ID

FIELD _ . BIN . 6 - TERMINAL ID

FIELD ID . LONG . 1 - SCHEDULE~

FIELD _ . LONG . 1 VALUE
- COUPON CASH

FIELD _ . LONG . 1 PRICE
- COUPON~

FIELD _ . SHORT . 1 PER
COUPON
PLAYS
- NUM

FIELD _ . SHORT . 1 _ _ REDEEMED
- MAX

FIELD _ . BIN . 1 - FLAGS

TABLE INFO
- FILE

FIELD _ . BIN . 6 PK
ID .
- RECORD

FIELD _ . LONG . 1 ID
- FILE

FIELD _ . LONG . 1 ID
- FILESET

FIELD _ . BIN . 60 - PATHNAME

FIELD - FILE SIZE . LONG . 1 FIELD - CRC ~ . SHORT . 1 FIELD TIMESTAMP . LONG . 1 - FILE

FIELD _ . BIN . 1 - FLAGS

TABLE - ITEM

FIELD ID . BIN . 6 PK
- RECORD .

FIELD _ . LONG . 1 ID
- ITEM

FIELD _ . LONG . 1 ID
- CATEGORY

FIELD _ . BIN . 40 NAME
- ITEM

FIELD _ . LONG . 1 - MIN PRICE

SUBSTITUTE SHEET (RULE 26) FIELD - MAX_PRICE . LONG . 1 FIELD - ICON . LONG . 1 FIELD - FLAGS . BIN . 1 FIELD - ITEM COST . LONG . 1 FIELD - RETAIL_PRICE . LONG . 1 FIELD - QUAN'.CITY_ON_HAND . LONG . 1 FIELD - MIN_QUANTITY_ON_HAND . LONG . 1 FIELD - DISTRIBUTION LOCATION . BIN . 40 TABLE - ITEM ATTRIBUTE

FIELD - RECOItD_ID . BIN . 6 .
PK

FIELD ITEM ID . LONG . 1 =

FIELD - ATTR:EBUTE ID . BIN . 1 ~

FIELD - ATTR:CBUTE . BIN . 40 _NAME

FIELD - DATA TYPE . BIN . 1 FIELD - MINIMUM . LONG . 1 FIELD - MAXIMUM . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - ITEM_ATTRIBUTE
VALUE

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - ITEM ID . LONG . 1 FIELD - ATTR:LBUTE . BIN
ID

FIELD _ . BIN . 1 - VALUE INDEX
~

FIELD - VALUI: . BIN . 30 TEXT
~

FIELD - FLAG:a . BIN . 1 TABLE - ITEM PROMOTION

FIELD - RECO1ZD_ID . BIN . 6 PK
.

FIELD - ITEM ID . LONG . 1 FIELD - PROMOTION . LONG . 1 ID

FIELD _ . BIN . 1 - FLAGS

TABLE - ITEM_SCHEDULE

FIELD ID . BIN . 6 PK
- RECORD .

FIELD _ . LONG . 1 - ITEM ID

FIELD - TERM:INAL_ID . BIN . 6 FIELD - SCHEDULE_ID . LONG . 1 FIELD - FLAG:3 . BIN . 1 TABLE - ITEM SCREEN

FIELD ID . BIN . 6 PK
- RECORD .

FIELD _ . LONG . 1 - ITEM ID

FIELD INDEX . BIN . 1 - SCREEN

FIELD _ . LONG . 1 - CONTENT_ID

FIELD - FLAGS . BIN . 1 TABLE - ITEM URC

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - ITEM ID . LONG . 1 SUBSTITUTE SHEET (RULE 26) FIELD - URC . LONG .

FIELD - FLAGS . BIN .

TABLE - LEADERBOARD

FIELD - RECORD_ID . BIN . PK

.

FIELD - LEADERBOARD LONG .
ID . 1 FIELD _ LONG .
= LEADERBOARD 1 DATE
TIME .

FIELD _ BIN .
_ 1 - FLAGS .

FIELD - MAX LEADERS . SHORT .

TABLE - LEADERBOARD
LEADER

FIELD _ BIN . PK
- RECORD_ID . 6 .

FIELD - LEADF;RBOARD_ID . LONG .

FIELD - SUBSC:RIBER ID . LONG .

FIELD - ALIA:i ~ . BIN .

FIELD - LOCA7CION BIN .
NAME . 26 FIELD _ BIN .

CITY
STATE .

FIELD _ BIN .
_ 26 - PRIZI;
NAME .

FIELD _ LONG .
- SCORE . 1 FIELD - SCORE DATE LONG .
TIME . 1 FIELD _ BIN .
- FLAG;i~ . 1 TABLE - LEADERBOARD
RANKING

FIELD _ . BIN . PK

- RECORD .

FIELD _ . LONG .
- LEADERBOARD_ID 1 FIELD - RANK . SHORT .

FIELD - SUBS(:RIBER_ID . LONG .

FIELD FLAG~~ . BIN .
= Z

TABLE - LOCAT ION

FIELD - RECOI~D_ID . BIN . PK

.

FIELD - LOCATION . LONG .

FIELD _ . BIN .
- SHOR'.P NAME 26 FIELD - NAME ~ . BIN .

FIELD - SHOR'.r . BIN .

STATE

FIELD _ . BIN .
_ 72 STATE
- CITY

FIELD _ . BIN .

- TIME

FIELD _ . LONG .

PAYOUT
- MAX

FIELD _ . LONG .
_ 1 - DIAL:IN
INTERVAL

FIELD _ . SHORT .

CODE

FIELD _ . SHORT .
- COUN'TRY CODE 1 FIELD - FLAGS ! . BIN .

FIELD - TOKEN PRICE . LONG .

TABLE - LOCA'rION_ATTRACT
SCREEN

FIELD _ . BIN . PK

- RECORD .

FIELD _ . LONG .
- LOCATION_ID 1 FIELD - SCREEN . BIN .

FIELD _ . LONG .
- CONTENT_ID 1 FIELD - FLAGS . BIN .

SUBSTITUTE SHEET (RULE 26) TABLE LOCATION_COUPON
- SCHED

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD ID . LONG . 1 - LOCATION

FIELD _ . LONG . 1 - COUPON
ID

FIELD _ . LONG . 1 - SCHEDULE_ID

FIELD COUPON_PRICE . LONG . 1 -FIELD FLAGS . BIN . 1 -TABLE LOCATTON_LOYALTY
- SCHED

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD LOCATION_ID . LONG . 1 -FIELD LOYALTY_PROGRAM_ID . LONG . 1 -FIELD SCHEDULE_ID . LONG . 1 -FIELD POINT PRICE . LONG . 1 - ~

FIELD FLACaS . BIN . 1 -TABLE LOCF~TION
- URC

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD LOCATION_ID . LONG . 1 -FIELD URC . LONG . 1 -FIELD FLAGS . BIN . 1 -TABLE LOYALTY_PROGRAM
-FIELD RECORD . BIN . 6 = ID

FIELD _ . LONG . 1 - LOYALTY
PROGRAM
ID

FIELD _ . BIN . 40 - _ NAME:

FIELD POINT . BIN . 20 - LABEL

FIELD _ . BIN . 1 - FLAGS

TABLE ITEM
SCHED
- LOYALTY

FIELD _ . BIN . 6 PK
- _ .
RECORD
ID

FIELD _ . LONG . 1 - LOYALTY
PROGRAM
ID

FIELD _ . LONG . 1 _ - ITEri ID

FIELD _ . BIN . 6 - TERMINAL
ID

FIELD _ . LONG . 1 ID
- SCHEaDULE

FIELD _ . LONG . 1 VALUE
- POINT
GASH

FIELD _ . LONG . 1 _ - POINT_PRICE

FIELD - POIrJT PER . SHORT . 1 ITEM

FIELD _ . SHORT . 1 - ITEMS
~PER
POINT

FIELD _ . SHORT . 1 _ PER
- MAX USED
ITEM

FIELD _ . BIN . 1 _ - FLACaS

TABLE SERVICE
SCHED
- LOYALTY

FIELD _ . BIN . 6 PK
_ .
ID
- RECORD

FIELD _ . LONG . 1 ID
- LOYALTY PROGRAM

FIELD _ . LONG . 1 ID
- SERVICE~

FIELD _ . BIN . 6 - TERMINAL
ID

FIELD _ . LONG . 1 - SCHP:DULE
ID

FIELD _ . LONG . 1 - POINT
CASH
VALUE

FIELD _ . LONG . 1 _ - POINT PRICE

SUBSTITUTE SHEET (RULE 26) FIELD - POIN'PS_PER_PLAY . SHORT . 1 FIELD - PER_POINT . SHORT . 1 PLAYS

FIELD - _ . SHORT . 1 MAX_1:TSED_PER_PLAY

FIELD = FLAG: . BIN . 1 TABLE - PRICING

FIELD - ID . BIN . 6 PK
RECORD .

FIELD - _ . LONG . 1 PRIC:ING_ID

FIELD - PRICE TO . LONG . 1 START

FIELD - _ . LONG . 1 PRICE~TO_CONTINUE

FIELD - STAR'T~ . LONG . 1 DURATION

FIELD - _ . LONG . 1 CONT:INUE DURATION
~

FIELD - FLAG;S . BIN . 1 TABLE - PROMOT I ON

FIELD - ID . BIN . 6 PK
RECORD .

FIELD - _ . LONG . 1 PROMOTION_ID

FIELD - FLAGS . BIN . 1 TABLE - PROMOTION_COUPON

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - PROMOTION_ID . LONG . 1 FIELD TO AWARD . LONG . 1 - COUPON
ID

FIELD _ . BIN . 1 _ - FLAGS s TABLE LOYALTY
- PROMOTION

FIELD _ . BIN . 6 PK
= RECORD_ID .

FIELD = PROMOTION_ID . LONG . 1 FIELD - LOYALTY_PROGRAM_ID . LONG . 1 FIELD POINTS . SHORT . 1 TO
AWARD
- NUM

FIELD _ . BIN . 1 _ _ - FLAGS

TABLE - REDEMPTION

FIELD - RECO:RD . BIN . 6 PK
ID .

FIELD _ . LONG . 1 - REDEIMPTION
ID

FIELD _ . BIN . 1 - FLAGS

FIELD ALLOWED . BIN . 1 RATING
- MIN

FIELD _ . BIN . 1 _ - MAX_RATING_ALLOWED

FIELD - SERVICE ID . LONG . 1 FIELD - PROFILE~ . BIN . 1 FIELD - SHORT NAME . BIN . 28 FIELD - NAME ~ . BIN . 72 FIELD ID . LONG . 1 - PRICING

FIELD _ . LONG . 1 DATE_TIME
- START

FIELD _ . LONG . 1 TIME
- END
DATE

FIELD _ . BIN . 40 _ - SPONSER

FIELD - ICON . LONG . 1 FIELD SCREEN . LONG . 1 - SPLASH

FIELD _ . BIN . 1 MONEY
TO
POOL
- PERCENT

FIELD _ . LONG . 1 _ _ - CURRENT POOL VALUE

SUBSTITUTE SHEET (RULE 26) FIELD - VALUE OF AVAIL . LONG . 1 PRIZES

FIELD - _ . LONG . 1 PLAYS~_TO_~DATE

FIELD - LAST UPDATE DATE TIME . LONG . 1 TABLE - REDEMPTION
PAR LEVEL

FIELD - _ . BIN . 6 PK
RECORD_ID ~ .

FIELD - REDE1~PTION_ID . LONG . 1 FIELD - PAR . BIN . 1 LEVEL

FIELD - _ . LONG . Z
PAR_SCORE

FIELD - TARGFT_PAY PERCENT . BIN . 1 ~

FIELD - PRIZI:._ITEM . LONG . 1 _ID

FIELD - PERCENT_OF_POOL_APPLIED . BIN . 1 FIELD - EXPI3ZATION_DATE . LONG . 1 FIELD - NUM REMAINING . LONG . 1 ~

FIELD - MIN . LONG . 1 WIN INTERVAL

FIELD - FLAG;a , BIN . 1 FIELD - MIN J?RIOR PLAYS . LONG . 1 TABLE - REDEMPTION_PROMOTION

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - REDEMPTION_ID . LONG . 1 FIELD - PROMOTION_ID . LONG . 1 FIELD - FLAGS . BIN . 1 FIELD - PAR LEVEL . BIN . 1 TABLE - REDEMPTION
RULE
SCREEN

FIELD _ . BIN . 6 PK
_ .
- RECORD_ID

FIELD - REDEMPTION_ID . LONG . 1 FIELD - SCREEN . BIN . 1 INDEX

FIELD _ . LONG . 1 - CONTENT
ID

FIELD _ . BIN . 1 - FLAGS

TABLE - REDEMPTION
SCHEDULE

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - REDEMPTION . LONG . 1 ID

FIELD _ . BIN . 6 - TERM:INAL
ID

FIELD _ . LONG . 1 - SCHEDULE
ID

FIELD _ . BIN . 1 - FLAGS

TABLE - REDEMPTION
URC

FIELD _ . BIN . 6 PK
- RECORD .
ID

FIELD _ . LONG . 1 - REDEMPTION_ID

FIELD - URC . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - SCHEDULE

FIELD - RECORD . BIN . 6 .
ID PK

FIELD _ . LONG . 1 - SCHE:DULE
ID

FIELD _ . LONG . 1 - START_DATE_TIME

FIELD - END :DATE TIME . LONG . 1 SUBSTITUTE SHEET (RULE 26) FIELD - WEEKDAYS . BIN .

FIELD - START_TIME_OF_DAY . LONG .

FIELD - END_'TIME_OF_DAY . LONG .

FIELD - FLAGS . BIN .

TABLE - SERVICE

FIELD - RECORD_ID . BIN . PK

.

FIELD - SERVICE_ID . LONG .

FIELD - SERVICE_TYPE . BIN .

FIELD - FLAGS . BIN .
Z

FIELD - SHOR'T NAME . BIN .
~ 30 FIELD - NAME . BIN .

FIELD - ICON . LONG .

FIELD - ATTR~1CT_SCREEN . LONG .

FIELD = SW_CAPABILITIES . BIN .

FIELD - HW_R1EQUIREMENTS . BIN .

FIELD - FILE;SET_ID . LONG .

FIELD - EXECUTABLE FILE ID . LONG .

TABLE - SERVICE PROFILE

FIELD - RECORD_ID . BIN . PK

.

FIELD - SERVICE_ID . LONG .

FIELD - PROFILE . BIN .

FIELD - PROFILE_NAME . BIN .

FIELD - FLAGS . BIN .

FIELD - SCORE FORMULA_LENGTH . SHORT .
~ 1 FIELD - SCOR:E . VARBIN .

TABLE - SERVICE
PROFILE
SETTING

FIELD _ . BIN . PK
_ 6 - RECORD_ID .

FIELD - SERVICE_ID . LONG .

FIELD = PROFILE . BIN .

FIELD - SETTING ID . LONG .
~ 1 FIELD VALUE . LONG .

FIELD - FLAGS . BIN .

TABLE - SERVICE_PROMOTION

FIELD - RECORD . BIN . PK

.

FIELD _ . LONG .

ID

FIELD _ . LONG .
- PROMOTION_ID 1 FIELD = FLAGS . BIN .

TABLE - SERVICE
RATING

FIELD _ . BIN . PK

ID .

FIELD _ . LONG .
- SERVICE_ID 1 FIELD - RATING . BIN .

FIELD - DESCRIPTION . BIN .

FIELD - FLAGS . BIN .

SUBSTITUTE SHEET (RULE 26) TABLE - SERV:ICE_SCHEDULE

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SERV:ICE_ID . LONG . 1 FIELD - TERM:INAL_ID . BIN . 6 FIELD - SCHEDULE_ID . LONG . 1 FIELD - PROF:ILE . BIN . 1 FIELD - PRIC:ING_ID . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - SERV:ICE_SETTING

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SERVICE_ID . LONG . 1 FIELD - SETTaNG ID . LONG . 1 ~

FIELD - SETT:ING . BIN . 32 _NAME

FIELD - TYPE . BIN . 1 FIELD - FLAGS . BIN . 1 TABLE - SERV:CCE
SLOT

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - SERV:LCE_ID . LONG . 1 FIELD - SLOT . BIN . 1 FIELD - SCHEDULE_ID . LONG . 1 FIELD - NUM_AD_PLAYS . BIN . 1 FIELD - FLAGS . BIN . 1 TABLE - SERV:ICE
STATISTIC

FIELD _ . BIN . 6 PK
- RECOItD_ID .

FIELD - SERV:ICE_ID . LONG . 1 FIELD - STAT:ISTIC_ID . LONG . 1 FIELD - STAT:ISTIC . BIN . 20 NAME

FIELD _ . LONG . 1 - LOWEIZ_LIMIT

FIELD - UPPER LIMIT . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - SERVICE_TERMINAL

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SERVICE_ID . LONG . 1 FIELD - TERM:INAL . BIN . 6 ID

FIELD _ . BIN . 16 - LICENSE_KEY

FIELD - FILESET ID . LONG . 1 V

FIELD - FLAGS . BIN . 1 TABLE - SERV:ICE
TYPE

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - TYPE . BIN . 1 FIELD - PAREIVT_TYPE . BIN . 1 FIELD - TYPE NAME . BIN . 16 FIELD - FLAGS . BIN . 1 SUBSTITUTE SHEET (RULE 26) TABLE - SERV:ICE_URC

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SERV:ICE_ID . LONG . 1 FIELD - URC . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - SUBSCRIBER

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SUBSCRIBER_ID . LONG . 1 FIELD - ALIAS . BIN . 26 FIELD NAME . BIN . 20 - FIRST

FIELD _ . BIN . 20 - LAST
NAME

FIELD _ . BIN . 2 - MIDDLE_INITIAL

FIELD - STREET_ADDRESS . BIN . 40 FIELD - POSTAL_CODE . BIN . 10 FIELD - PHONE NUMBER . BIN . 10 -FIELD - BIRTH . BIN . 1 DAY

FIELD _ . BIN . 1 - BIRTH MONTH
~

FIELD - BIRTH . SHORT . 1 _YEAR

FIELD = GENDER . BIN . 1 FIELD - FLAGS . BIN . 1 FIELD - DEMOGRAPHIC . LONG . 1 FIELD - LAST UPDATE DATE TIME . LONG . 1 TABLE - SUBSCRIBER AD

FIELD - RECORD_ID ~ . BIN . 6 PK
.

FIELD - SUBSCRIBER_ID . LONG . 1 FIELD - AD . LONG . 1 ID

FIELD _ . LONG . 1 - VIEW DATE
TIME

FIELD _ . BIN . 1 - FLAGS

TABLE - SUBSCRIBER_AVATAR

FIELD ID . BIN . 6 PK
- RECORD .

FIELD _ . LONG . 1 - SUBSCRIBER_ID

FIELD - AVATAR_TYPE . BIN . 1 FIELD = CONTF~NT_ID . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE - SUBSCRIBER_BRACKET

FIELD - RECORD . BIN . 6 PK
ID .

FIELD _ . LONG . 1 - SUBSCRIBER
ID

FIELD _ . LONG . 1 - TOURNAMENT_ID

FIELD - BRACKET_ID . BIN . 1 FIELD - GAMES PLAYED . SHORT . 1 ~

FIELD - FLAG~S . BIN . 1 FIELD = RANK . LONG . 1 FIELD - RANK DATE_TIME . LONG . 1 FIELD - RANK-_SCORE . LONG . 1 FIELD - AVERAGE SCORE . LONG . 1 SUBSTITUTE SHEET (RULE 26) TABLE - SUBSCRIBER
CARD

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - SUBSCRIBER_ID . LONG . 1 FIELD - CARD_TYPE . BIN . 1 V

FIELD DATA . BIN . 16 - CARD

FIELD - FLAGS . BIN . 1 TABLE - SUBSCRIBER
RATING

FIELD _ . BIN . 6 PK
- RECORD_ID .

FIELD - SUBSCRIBER_ID . LONG . 1 FIELD - SERV:CCE_ID . LONG . 1 FIELD - PROF:LLE . BIN . 1 FIELD - RATING . BIN . 1 FIELD HANDICAP . LONG . 1 =

FIELD - PLAY3 TO_QUALIFY . BIN . 1 ~

FIELD - FLAG;3 . BIN . 1 TABLE - SUBSCRIBER SAVE STATE
~

FIELD - RECORD_ID . BIN . 6 PK
~ .

FIELD - SUBSCRIBER_ID . LONG . 1 FIELD - SERV:ICE_ID . LONG . 1 FIELD - SLOT NUMBER . BIN . 1 FIELD - PROF:ILE . BIN . 1 FIELD - SAVE_STATE . BIN . 20 NAME

FIELD _ . LONG . 1 - DATA FILE
ID

FIELD _ . BIN . 1 - FLAG.

TABLE - SUBSCRIBER_URC

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - SUBSCRIBER . LONG . 1 ID

FIELD _ . LONG . 1 - URC

FIELD - FLAGS . BIN . 1 TABLE - TEAM MEMBER

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TEAM SUBSCRIBER . LONG . 1 ID

FIELD _ . LONG . 1 - SUBSCRIBER
ID

FIELD _ . BIN . 1 - FLAG,3 TABLE - TECHNICIAN

FIELD - RECORD . BIN . 6 PK
ID .

FIELD _ . LONG . 1 - TECHNICIAN ID

FIELD - NAME ~ . BIN . 26 FIELD - PIN . SHORT . 1 FIELD - FLAGS . BIN . 1 TABLE - TECHNICIAN
TERMINAL

FIELD _ . BIN . 6 PK
ID .
- RECORD

FIELD _ . LONG . 1 - TECHNICIAN
ID

FIELD _ . BIN . 6 - TERMINAL ID

SUBSTITUTE SHEET (RULE 26) FIELD - AUTHORTZATION FLAGS . BIN . 1 TABLE - TERMINAL

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TERMINAL_ID . BIN . 6 FIELD - LOCATION_ID . LONG . 1 FIELD - LAN_ADDRESS . BIN . 4 FIELD - FLAG;S . BIN . 1 FIELD - SERIAL_NUMBER . BIN . 20 FIELD - HW_CAPABILITIES . BIN . 10 FIELD = ATTRACT_SCREEN . LONG . 1 FIELD - SYSTEM FILESET ID . LONG . 1 TABLE - TOURNAMENT

FIELD - RECORD_ID . BIN . 6 PK
.

FIELD - TOURNAMENT_ID . LONG . 1 FIELD - SHOR'T NAME . BIN . 28 -FIELD - NAME . BIN . 72 FIELD - START_DATE_TIME . LONG . 1 FIELD - END_.DATE_TIME , LONG . 1 FIELD = TOURNAMENT_SCOPE . BIN . 1 FIELD - FLAGS . BIN . 1 FIELD - SPONSER . BIN . 40 FTELD - ICON . LONG . 1 FIELD - SPLA~SH_SCREEN . LONG . 1 FIELD - PERC:ENT_MONEY_TO . BIN . 1 POOL

FIELD _ . LONG . 1 - CURR:ENT_POOL_VALUE

FIELD - PLAYS_TO_DATE . LONG . 1 FIELD - LAST UPDATE DATE TIME . LONG . 1 TABLE - TOURNAMENT URC
~

FIELD - RECORD . BIN . 6 PK
ID , FIELD _ . LONG . 1 - TOURNAMENT_ID

FIELD - URC . LONG . 1 FIELD - FLAGS . BIN . 1 TABLE 'VALUE
- URC

FIELD _ , BIN . 6 PK
- RECO:RD ID .
~

FIELD - URC . LONG . 1 FIELD - RESTRICTED_STRING . BIN . 30 FIELD - FLAGS . BIN . 1 # Working tables - not replicated from EDS server TABLE - W AD EXPOSURE

FIELD - RECORD_ID . LONG . 1 .
PK

FIELD - TARGET . LONG . 1 ID

FIELD _ . LONG . 1 - SUBSCRIHER_ID

FIELD - PLAY DATE TIME . LONG . 1 SUBSTITUTE SHEET (RULE 26) TABLE - W_AD_EXPOSURE
COUNTS

FIELD _ . LONG . PK
- RECORD_ID 1 .

FIELD - TARGET_TD . LONG .

FIELD - TOTAL_PLAYS_TODAY . SHORT .

FIELD - TOTAL PLAYS TO DATE . LONG .

TABLE - W
CONTENT
CACHE

FIELD _ . LONG . PK
_ 1 - RECORD_ID .

FIELD - CONTENT_ID . LONG .

FIELD - LOCAL_PATH_SIZE . SHORT .

FIELD - LOCAL PATH . VARBIN .

TABLE W
- COUPONS_ISSUED

FIELD _ . LONG . PK
- RECORD_ID 1 .

FIELD COUPON_ID . LONG .

FIELD RECEIPT_ID . BIN .

FIELD TERMINAL_ID . BIN .

FIELD SUBSCRIBER_ID . LONG .

FIELD ISSUE_DATE_TIME . LONG .

FIELD FLAGS . BIN .

TABLE W DOWN TIME
-FIELD RECORD_ID . LONG . PK

.

FIELD START_DATE_TIME . LONG .

FIELD END_DATE_TIME . LONG .

FIELD TECHNICIAN ID . LONG .

TABLE W
- FILE
CACHE

FIELD _ . LONG . PK
- _ 1 RECORD_ID .

FIELD FILE_ID . LONG .

FIELD LOCAL_PATH_SIZE . SHORT .

FIELD - LOCAL PATH . VRRBIN .

TABLE - W
LEADERBOARD

FIELD _ . LONG . PK
- RECORD_ID 1 .

FIELD LEADERBOARD_ID . LONG .

FIELD - LEADERBOARD_DATE . LONG .

FIELD _ . BIN .

FIELD - MAX LEADERS . SHORT .

TABLE W
- LEADERBOARD
LEADER

FIELD _ . LONG . PK
_ 1 - RECORD_ID .

FIELD - LEADERBOARD . LONG .

FIELD _ . LONG .

FIELD - ALIAS ~ . BIN .

FIELD - LOCATION_NAME . BIN .

FIELD - LOCATION . BIN .

STATE

FIELD _ . BIN .
_ 26 - PRIZE_NAME

FIELD - SCORE . LONG .

SUBSTITUTE SHEET (RULE 26) FIELD - SCORE: DATE TIME . LONG .

TABLE - W_LEADERBOARD_RANKING

FIELD - RECORD_ID . LONG . PK

.

FIELD - LEADE:RBOARD_ID . LONG .

FIELD - RANK . SHORT .

FIELD - SUBSC;RIBER ID . LONG .

TABLE - W_LOC;AL
LEADERBOARD

FIELD _ . LONG . PK
- RECORD_ID 1 .

FIELD - LEADE:RBOARD_ID . LONG .

FIELD - LEADE:RBOARD_DATE_TIME . LONG .

FIELD - MAX LEADERS . SHORT .

TABLE - W_LOC:AL LEADER

FIELD - RECORD_ID . LONG . PK

.

FIELD - LEADERBOARD ID . LONG .
~ 1 FIELD - RANK . SHORT .

FIELD - SUBSC:RIBER_ID . LONG .

FIELD - ALIAS . BIN .

FIELD - SCORE: . LONG .

FIELD - SCORE: DATE TIME . LONG .

TABLE - W_LOYALTY_POINT AWARDS

FIELD - RECORD_ID ~ . LONG . PK

.

FIELD - SUBSC:RIBER_ID . LONG .

FIELD - LOYAI~TY_PROGRAM . LONG .

FIELD _ . SHORT .
- POIN7.'S_AWARDED 1 FIELD - AWARI> DATE TIME . LONG .

TABLE - W QUEUE

FIELD - RECORD_ID . LONG . PK

.

FIELD - TERM7:NAL_ID . BIN .

FIELD - AGE . SHORT .

FIELD - QUEUE:_TIME . LONG .

FIELD - EVENT TYPE . BIN .
~ 1 FIELD - EVEN7.' . SHORT .
DATA_SIZE 1 ~

FIELD - EVENT . VARBIN .

TABLE REI>EMPTION HISTORY
- W

FIELD _ . LONG . PK
- RECORD_ID ! 1 .

FIELD - REDEMPTION ID . LONG .
i 1 FIELD = TIMESTAMP . LONG .

FIELD - SCORF: . LONG .

FIELD - PAR_LEVEL_PAID . BIN .

FIELD - SUBSC:RIBER_ID . LONG .

FIELD - CASH AMOUNT PAID . LONG .

TABLE - W REDEMPTION LOCAL POOL

SUBSTITUTE SHEET (RULE 26) FIELD - RECORD_ID . LONG . PK

.

FIELD - REDEMPTION_ID . LONG .

FIELD - LOCAL POOL VALUE . LONG .

TABLE - W
REDEMPTION
PAR
LEVEL

FIELD _ LONG . PK
_ 1 _ .
- RECORD_ID .

FIELD = REDEMPTION . LONG .

FIELD _ . BIN .

- PAR

FIELD _ . LONG .
= ADJUSTED PAR SCORE 1 TABLE SERVICE
ACCESSES
- W

FIELD _ . LONG . PK
_ 1 - RECORD_ID .

FIELD - SERVICE . LONG .

FIELD _ . BIN .

FIELD - START_DATE_TIME . LONG .

FIELD - END_LiATE_TIME . LONG .

FIELD - SUBSCRIBER ID . LONG .
' 1 FIELD - CASH:_FUNDS . LONG .

FIELD _ . LONG .

TABLE - W
SERVICE LEADERBOARD, FIELD _ . LONG . .

ID~

FIELD _ . LONG .
- SERV'ICE_ID 1 FIELD - PROFILE . BIN .

FIELD - LEADERBOARD ID . LONG .

TABLE - W_TGURNAMENT LOCAL_POOL
s FIELD - RECORD_ID . LONG . .

FIELD - TOUPNAMENT_ID . LONG .

FIELD - LOCP.L POOL VALUE . LONG .

SUBSTITUTE SHEET (RULE 26)

Claims (26)

1. A system for controlling a medium of exchange comprising:
(a) plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of the identity of the person and of the activity, (b) a first database for storing predetermined exchange values for the activity, (c) a second database for storing separate medium of exchange accounts for various persons including at least one of customers and merchants, (d) apparatus for detecting said signals, for accessing the first database and for crediting an exchange value related to the activity to an account of a person carrying out the activity or on whose behalf the activity was carried out, in the second database, and (e) an administration terminal in communication with the first database for generating and downloading to the first database parameters indicative of the predetermined exchange values for various activities, from time to time.
2. A system as defined in claim 1 in which the terminals are comprised of a person identifier for detecting an identity of a person, and a display, apparatus for accessing the second database to determine a medium of exchange balance for an identified person and for causing display of the balance on the display, apparatus generating a redemption signal relating to redemption of an exchange value for a product or service, and for decrementing the account of the identified person in the second database by the value of the redemption exchange value.
3. A system as defined in claim 2, in which the person identifier is a reader of an identity indication carrier comprised of at least one of a bar code reader, a printed identity code reader, a magnetic strip reader, a smart card reader, or a voice recognizer, an eye iris reader, a fingerprint reader, a palmprint reader and a keyed identity code reader.
4. A system as defined in claim 3 in which the display is comprised of a video display of at least one of a public computer, a computer game terminal and a validation terminal.
5. A system as defined in claim 3 including plural displays located in proximity to each other.
6. A system as defined in claim 3 including at least one electronic games, each associated with a display, the game or games and displays being coupled in a network, a memory coupled to the network for storing a plurality of advertisements, a database coupled to the network for storing control parameters for the advertisements, and apparatus responsive to the control parameters for controlling display of any of the advertisements on any of the displays.
7. A system as defined in claim 5, including plural electronic games, each associated with a display, the games and displays being coupled in a network, the database also for storing game parameters, and apparatus responsive to the game parameters for controlling operation of various ones of the games.
8. A system as defined in claim 6 including plural electronic games, each associated with a display, the games and displays being coupled in a network, the database also for storing game parameters, and apparatus responsive to the game parameters for controlling operation of various ones of the games, the game parameters being related to at least one of speed of games, speed. of tokens comprising the games, characteristics of tokens comprising the games, point values achievable for operation of the games, algorithms used for operation by the games, and medium of exchange values to be awarded to a player of games for play or achievement in playing games.
9. A system as defined in claim 6, including apparatus for providing at least one of advertisement and game parameters from an administration terminal.
10. A system as defined in claim 9 including a regional server for receiving at least one of the game and exchange value parameters from the administrative terminal, for storing said parameters in a regional server and for downloading particular ones of said parameters relating to the games and advertisements located at the arcade, to the database located at the arcade.
11. A system as defined in claim 10, in which the parameters relating to display of advertisements are contained in a matrix which correlates sequences of predetermined advertisements to be displayed in the absence of or the detection of the presence of a detected identity of a particular person or class of person, content of the matrix being stored in the regional server.
12. A system as defined in claim 11, in which the medium of exchange accounts are stored in the regional server.
13. A system as defined in claim 11, further including plural regional servers, and a support server in communication with the plural regional servers for storing a master copy of the exchange accounts and said parameters, for providing to regional databases in communication with the regional servers, those parameters and exchange accounts which relate to arcades and terminals associated with the respective regional servers.
14. A system as defined in claim 1, in which the plural terminals are comprised of point of sale terminals.
15. A system as defined in claim 1, including apparatus for storing data relating to demographics of persons which may be identified by the terminals, apparatus for generating an offer based on detecting the presence of an identified person at a terminal and the demographics of that person, and apparatus for displaying the offer at a terminal adjacent to which the person has been identified.
16. A system as defined in claim 15, including apparatus for presenting the offer on one of a video display and a printed ticket.
17. A system as defined in claim 15, including apparatus for detecting activities undertaken by the identified person and updating the demographic data accordingly.
18. A system as defined in claim 17, including apparatus for updating the demographic data on a real-time basis.
19. A system for controlling a medium of exchange comprising:
(a) terminals for determining the presence of a person, and of an activity carried out by the person, (b) display apparatus located adjacent to the terminal, (c) a regional server in communication with the terminals and display apparatus, (d) a first. database accessible by the regional server, (e) a support server in communication with the regional server, (f) an administration terminal on which control parameters can be input, (g) apparatus for receiving control parameters relating to medium of exchange values for activities carried out by the person from the administration terminal and for downloading the control parameters to the support server, (h) apparatus for transferring those control parameters which relate to media of exchange functions controlled by the regional server, to the first database, (i) apparatus for transferring those control parameters which relate to functions carried out at the display apparatus and the terminals, from the first database to control apparatus for the display apparatus, whereby the presence and activity of said person can be determined and messages can be controlled to be presented on the display apparatus directed to the identified person of class of person, and exchange values credited to the person.
20. A system as defined in claim 19, including apparatus for requesting updated parameters from time to time by the control apparatus for the display apparatus from the regional server, for comparing parameters at the control apparatus with those stored in the first database, and for updating the control parameters at either one of the first database and the control apparatus for the display apparatus.
21. A system as defined in claim 20, including apparatus for storing at at least one of person accounts, merchant accounts and demographic data relating to persons in the first database, and means for automatically updating the person accounts, merchant accounts and demographic data from the terminals from time to time.
22. A system as defined in claim 21 including means for gathering activity information relating to a person from the terminals and under control of said control parameters, storing the activity information at the control apparatus for the display apparatus, whereby the at least one of the person accounts, merchant accounts and demographic data in the first database can be updated from time to time.
23. A system as defined in claim 19, including receiving various control parameters at the administrative terminal from plural remote administrative terminals for provision to the support servers.
24. A system as defined in claim 8 in which loyalty points form the medium of exchange.
25. A system for controlling a medium of exchange comprising:
(a) plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of at least the activity, (b) a first database for storing predetermined demographic information related to the activity, (c) apparatus for detecting said signals, for accessing the first database and for storing data related to the activity in a record related to a class of persons carrying out the activity, in the second database, (d) an administration terminal in communication with the first database for receiving the stored data, and for generating and downloading to the first database parameters controlling the provision of offers to persons of the same class from time to time.
26. A system for controlling a medium of exchange comprising:
(a) plural terminals at various locations for detecting the presence of a person and of an activity carried out by the person, and for providing signals indicative of at least the activity, (b) a first database for storing predetermined demographic information related to the activity, (c) apparatus for detecting said signals, for accessing the first database and for storing data related to the activity in a record related to a class of persons carrying out the activity, in the second database, (d) an administration terminal in communication with the first database for receiving the stored data, and for generating and downloading to the first database parameters for controlling the provision of advertising for display on display apparatus which is part of the terminal or is adjacent the terminal, to the person or to persons of the same class, or for controlling the printing of premiums on a printer which is part of the terminal or is adjacent the terminal, from time to time.
CA 2354408 1998-12-22 1999-12-16 Amusement and premiums network Abandoned CA2354408A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US21801898 true 1998-12-22 1998-12-22
US09/218,018 1998-12-22
PCT/CA1999/001201 WO2000038089A3 (en) 1998-12-22 1999-12-16 Amusement and premiums network

Publications (1)

Publication Number Publication Date
CA2354408A1 true true CA2354408A1 (en) 2000-06-29

Family

ID=22813426

Family Applications (1)

Application Number Title Priority Date Filing Date
CA 2354408 Abandoned CA2354408A1 (en) 1998-12-22 1999-12-16 Amusement and premiums network

Country Status (3)

Country Link
EP (1) EP1145175A2 (en)
CA (1) CA2354408A1 (en)
WO (1) WO2000038089A3 (en)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6565435B2 (en) * 1999-11-30 2003-05-20 Midway Amusement Games, Llc Method of authorizing free play of an amusement game
WO2002008969A1 (en) * 2000-07-24 2002-01-31 Voyager Media Ltd A method and a system for providing a reward for viewing advertisements
JP2002133017A (en) * 2000-10-30 2002-05-10 Aruze Corp Point management system
US7918738B2 (en) * 2001-03-27 2011-04-05 Igt Interactive game playing preferences
US7946917B2 (en) * 2001-08-10 2011-05-24 Igt Flexible loyalty points programs
US6575832B1 (en) * 2001-09-28 2003-06-10 Acres Gaming Incorporated Method for implementing scheduled return play at gaming machine networks
US8157644B2 (en) 2001-09-28 2012-04-17 Igt Apparatus and methods for implementing bonuses in gaming machine networks using weighted pay tables
US6884173B2 (en) * 2002-05-14 2005-04-26 Atronic International Gmbh Configuration technique for a gaming machine
US8979646B2 (en) 2002-06-12 2015-03-17 Igt Casino patron tracking and information use
US7909699B2 (en) 2002-06-27 2011-03-22 Igt Scan based configuration control in a gaming environment
US7526649B2 (en) * 2003-12-30 2009-04-28 Intel Corporation Session key exchange
US8602882B2 (en) 2004-10-04 2013-12-10 Igt Jackpot interfaces and services on a gaming machine
US20070060302A1 (en) 2005-08-17 2007-03-15 Igt Scan based configuration control in a gaming environment
WO2009117385A1 (en) * 2008-03-19 2009-09-24 Richard Albert Ferdinand Game-based advertising system and method
WO2009124360A1 (en) * 2008-04-11 2009-10-15 G5 Enterprizes Pty Ltd Systems and methods for managing carbon credit data
US8162737B2 (en) 2009-05-27 2012-04-24 Igt Contactless player card with improved security

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1245361A (en) * 1984-06-27 1988-11-22 Kerry E. Thacher Tournament data system
US5811772A (en) * 1989-12-19 1998-09-22 Scotch Twist, Inc. Gaming machine system operable with general purpose charge cards
US5231568A (en) * 1992-01-16 1993-07-27 Impact Telemedia, Inc. Promotional game method and apparatus therefor
GB9320479D0 (en) * 1993-10-05 1993-11-24 Barcrest Ltd Credit-operated machines
US5823879A (en) * 1996-01-19 1998-10-20 Sheldon F. Goldberg Network gaming system

Also Published As

Publication number Publication date Type
EP1145175A2 (en) 2001-10-17 application
WO2000038089A3 (en) 2000-11-09 application
WO2000038089A2 (en) 2000-06-29 application

Similar Documents

Publication Publication Date Title
US7008320B2 (en) Gaming machine with receipt generation capabilities
US7416485B2 (en) Methods and apparatus for managing an account to fund benefits for a player
US6965868B1 (en) System and method for promoting commerce, including sales agent assisted commerce, in a networked economy
US6306035B1 (en) Graphical user interface for providing gaming and prize redemption capabilities
US7874906B2 (en) Systems and methods for allocating an outcome amount among a total number of events
US6266647B1 (en) Methods and apparatus for electronically storing and retrieving value information on a portable card
US5902983A (en) Preset amount electronic funds transfer system for gaming machines
US6666768B1 (en) System and method for tracking game of chance proceeds
US7722453B2 (en) Interactive game playing preferences
US7493267B1 (en) Method and apparatus for compensating participation in marketing research
US6758755B2 (en) Prize redemption system for games executed over a wide area network
US20060248025A1 (en) Systems, methods and apparatus for offering an extension of a flat rate play session based on an ending credit balance
US20040015423A1 (en) Method and apparatus for managing performance of multiple games
US20050009600A1 (en) Gaming environment including portable transaction devices
US6800029B2 (en) Gaming environment including portable transaction devices for rating players
US20040148224A1 (en) Method and apparatus for electronic support and delivery of multiple lottery and sweepstake programs, in substantially off-line environments
US20070105617A1 (en) Methods, systems and apparatus for facilitating cashout options at a gaming device
US6688976B1 (en) Systems and methods wherein a lottery number combination is associated with a limited number of occurrences
US7008321B2 (en) Method and system for issuing and using gaming machine receipts
US5674128A (en) Cashless computerized video game system and method
US7351142B2 (en) Method and apparatus for facilitating play of fractional value lottery games
US20050198318A1 (en) Wireless/wired token access distributed network and system for using same
US20040002386A1 (en) Wireless casino information management system and method
US20050107156A1 (en) System and method for integrated player tracking and cash-access
US6049778A (en) Method and apparatus for administering a reward program

Legal Events

Date Code Title Description
FZDE Dead