WO2001044895A2

WO2001044895A2 - Computer-based techniques for storing and processing data

Info

Publication number: WO2001044895A2
Application number: PCT/US2000/042793
Authority: WO
Inventors: Marek Tadeusz Dubek; Marcin Karczmarczyk; Irena Szrek
Original assignee: Gtech Rhode Island Corporation
Priority date: 1999-12-14
Filing date: 2000-12-13
Publication date: 2001-06-21
Also published as: WO2001044895A3; AU4718401A

Abstract

A transaction based system (10) including a data center (11) with a host computer (12) and a front-end processor (13), communication stations (14), terminals (16), extract files (18) and database system (20). Data is arranged in a compressed format in a plurality of records that are related to each other. The records are stored in memory in the form of a plurality of database tables. A link is established between related records. Data from the stored records is accessed by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

Description

COMPUTER-BASED TECHNIQUES FOR STORING AND. PROCESSING DATA Background of the Invention

The invention relates to acquiring, storing, organizing, accessing and searching data, and in particular storing data in a compressed format and associating related data. In this age of ever-increasing volumes of information, databases are used to store and organize data. Databases allow data to be stored and accessed in an orderly manner. Databases may also be used in retrieving data in desired display formats. For example, selected categories of data contained in a database may be retrieved and displayed for analysis, leaving undesired data not retrieved or displayed. Ideally, an unlimited amount of data could be stored, accessed instantaneously, and displayed in any one of a number of formats as desired by a user seeking to view or analyze the data.

Although it is possible to handle increasing amounts of data using faster computer processors, and higher- capacity storage media allow increasing amounts of data to be stored in database, there are still practical limits to the amount of data that may be stored and accessed. There are also practical limits to the amount of data that it is desirable to store, given the processing times associated with processing large amounts of data. In particular, the larger the number of bits representing the data, the more expensive the storage of the data and the longer the processing times for storing, organizing, retrieving, and otherwise processing the data.

Summary of the Invention In general, in one aspect, the invention features a computer-based method for storing and accessing data by a user, the data being obtained from a series of transactions. The data are arranged in a compressed format in a plurality of records that are related to each other based upon the series of transactions. The records are stored in a memory in the form of a plurality of database tables, each database table having at least one record. A link is established between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables. Data is accessed from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

Implementations of the invention may also include one or more of the following features. The method may include displaying the accessed data or preparing a text report using the accessed data. The method may also include creating the filter operation at the request of the user or creating a filtered table using the accessed data.

The step of arranging the data in a compressed format may further include inserting a pointer in a record of a first database table to a value in a record of a second database table. The database tables may include a transaction table linked to all other database tables. The link may relate records that are historically related to each other.

In general, in another aspect, the invention features a computer-based method for storing data, the data being obtained from a series of transactions. The data are arranged in a compressed format in a plurality of records that are related to each other based upon the series of transactions. The records are stored in a memory in the form of a plurality of database tables, each database table having at least one record. A link is established between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables.

Implementations of the invention may also include the following feature. The step of arranging the data in a compressed format may further include inserting a pointer in a record of a first database table to a value in a record of a second database table.

In general, in another aspect, the invention features an apparatus for storing and accessing data by a user, the data being obtained from a series of transactions. A condensed file memory stores the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions. A database system including a database memory stores the records in the form of a plurality of database tables, each database table having at least one record. A processor establishes a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables and accesses data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

Implementations of the invention may also include one or more of the following features. The apparatus may include a display to display the accessed data, or a graphical user interface by which the user specifies the condition for the filter operation and displays the accessed data. In general, in another aspect, the invention features a computer-based method for storing and accessing gaming data by a user, the gaming data being obtained from a series of gaming transactions. The gaming data are arranged in a compressed format in a plurality of records that are related to each other based upon the series of gaming transactions. The records are stored in a memory in the form of a plurality of database tables, each database table having at least one record. A link is established between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables. Gaming data is accessed from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating gaming data in the related records based on the link.

Implementations of the invention may also include one or more of the following features. The method may further include displaying the accessed gaming data or preparing a text report using the accessed gaming data. The method may also include creating the filter operation at the request of the user or creating a filtered table using the accessed gaming data. In general, in another aspect, the invention features a computer program product for use with a system for storing and accessing data by a user from a series of transactions. The computer program product includes instructions for causing a computer to arrange the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions and to store the records in a memory in the form of a plurality of database tables, each database table having at least one record. The computer program product also includes instructions for causing the computer to establish a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables, and to access data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link. Implementations of the invention may also include one or more of the following features. The computer program product may further include instructions for causing the computer to display the accessed data or to prepare a text report using the accessed data. The computer program product may also include instructions for causing the computer to create the filter operation at the request of the user or to create a filtered table using the accessed data .

Various aspects of the invention may provide one or more of the following advantages. The present invention has the advantage that large numbers of detailed transactions may be stored, accessed, and manipulated, e.g., using a personal computer. The present invention has the further advantage that it is feasible to retain and retrieve large quantities of data within reasonable data storage parameters and access speeds. The present invention has the additional advantage that the number of input and output operations required to store and access data may be reduced, and as a result data retrieval speeds may be increased. Other features and advantages of the invention will become apparent from the following detailed description, and from the claims.

Brief Description of the Drawings FIG. 1 is a block diagram of a transaction-based system according to the present invention.

FIG. 2 is a block diagram of the database system of FIG. 1. FIG. 3 is a schematic diagram illustrating the flow of data through and processed in the database system of FIG. 1.

FIG. 4 is a block diagram showing a process of displaying and navigating through data in a database table. FIG. 5 is a schematic diagram of summary tables displayed in block data windows.

FIG. 6 is a block diagram showing a process of producing and modifying a filter. FIG. 7 is an example of three-dimensional yearly report for keno wagers .

FIG. 8 is a block diagram showing a process of producing history links between transactions.

FIG. 9 is an example of a wager transaction record. FIG. 10 is an example of a record from an agent table.

Description of Preferred Embodiments The invention provides computer-based techniques for acquiring, storing, organizing, searching and displaying transaction-based data, such as gaming data collected at a central lottery site. Such gaming data may include, e.g., transaction data, sales data, and information about agents, terminals, cities, regions and other gaming entities. The data may be filtered, transaction histories may be tracked, and reports may be produced based on the data. Although the following description relates to the invention's applicability to gaming systems, the invention is not limited to gaming systems. The invention has a wide range of applicability to transaction-based systems and data processing.

FIG. 1 shows a transaction based system 10 including a data center 11 with a host computer 12 and a front-end processor 13, communication stations 14, terminals 16, extract files 18 stored in a memory, and a database system 20. System 10 may be a gaming system, in which case data center 11 may be a central lottery site and terminals 16 may be gaming terminals for carrying out gaming transactions. Host processor 12 communicates with stations 14 via front-end processor 13. Data center 11 may further include any number of host computers and front -end processors. In addition to front -end processor 13, host computer 12 is connected to database system 20, to which extract files are sent. Database system 20 is independent of host processor 12, the memory containing the extract files being the only interface between them. The memory for the extract files may be any computer-readable memory such as RAM, ROM, cache, or a disk drive such as a hard disk drive. Although FIG. 1 shows three stations 14, many stations distributed locally and/or remotely may communicate with data center 11 over a digital network. In the case of a gaming system, stations 14 may be computers located at authorized gaming locations such as casinos, each station communicating and cooperating with a group of terminals 16. Terminals 16 may be, e.g., interface units including displays, touchpads, and reading and printing devices for entering and printing information regarding bettors' wagers. Although FIG. 1 shows one station 14 in communication with three terminals 16, the number of terminals connected to a station may vary, as long as each terminal is connected to at least one station.

Terminals 16 handle the operation of games, e.g., at authorized gaming locations. Terminals 16 may control the scheduling and operations of games such as keno and lotto by communicating with stations 14, e.g., to control when wagers may be placed and to issue tickets to bettors evidencing the bettors' wagers. Terminals 16 may perform the games, such as by randomly selecting winning keno and lotto numbers. Terminals 16 may also be used to validate winning tickets, cancel losing tickets, and indicate whether or not the game has concluded. Terminals 16 communicate with stations 14, which in turn communicate with front-end communication processor 13 and host computer 12 to provide data concerning gaming transactions such as wagers placed at terminals 16, results of games, and ticket validation and cancellation information. For example, the data sent from terminals 16 to data center 11 may include wager amounts, identities and times and types of games, as well as information concerning whether a ticket presented for verification was validated or cancelled. Data relating to gaming activities at various gaming locations is sent from terminals 16 to host processor 12 to be compiled and processed. Host processor 12 may include one or more computers under the control of computer-readable data management software, which includes instructions to control the operation of the computers that make up host processor 12. In particular, the instructions instruct host processor 12 to pack and code data received from terminals 16 into a binary format and store the data in a transaction log file. Other instructions retrieve the data from the transaction log file, decode it, and pack it into extract files 18.

Host processor 12 may pack data in data records in a variety of ways to reduce the amount of storage required in extract files 18. However, the packed, coded data include all of the information contained in the unpacked, uncoded data sent from terminals 16, so that there is no unintentional or undesired loss of transaction-level granularity or specificity of information. Some data, such as bet data, may be stored in_, extract files 18 without packing to save time in subsequent production of data files. Irrelevant data, as determined by individual gaming jurisdictions, may also be eliminated from records before storage.

Calculatable data may be stored as pointers to other storage locations containing the actual data or algorithms or other methods of calculating the data. Other data common to many records, such as the day and time of a transaction, may be moved to other storage locations. Recurring data may also be referred to by a pointer or may be stored as an incremental difference from a previous data record. For example, storing a "1" to indicate that the transaction of a current data record occurred one second after the transaction of the previous record saves storage in comparison to storing the month, day, year, hour, minute, and second of the transaction of the current record.

Known limits on possible data are also used to reduce data storage requirements. For example, if a fixed number of responses, such as wager types, wager amounts, or agent or terminal numbers, are possible, then the data may be stored in external lists, while only pointers to the lists are stored in the transaction records themselves. For example, a "1" in the wager amount field of a transaction record may point to a wager amount of $100 stored in the first position in a wager amount list, without having to store the number "100".

In addition, the number of bits used to store each piece of information may be manipulated to reduce the number of bits used, rather than requiring the use of a predetermined number of bits sufficient to store every data item within an anticipated or possible range of data, as is the case with records made up of character strings. Thus, the quantity of bits required may be reduced to only those bits actually needed. Descriptions may also be placed at the beginning of the records in the stored files to indicate which bits in the records provide which information. This allows database system 20 to determine how to use the information in the records, e.g., for extracting and manipulating data.

Extract files 18 contain packed, coded data usable by database system 20 for organizing and presenting data in useful ways to a user of database system 20. As shown in

FIG. 2, database system 20 includes a database system memory 22, a processor 24, and three graphical user interfaces (GUIs) 26, although there is no limit on the number of possible GUIs. Memory 22 may include a variety of types of computer-readable memory such as ROM, RAM, floppy disk drives, hard disk drives, and ZIP drives. One or more of these types of memory may store data such as data produced by or imported into database system 20, e.g., from extract files 18, and may also store instructions for controlling processor 24. GUIs 26 may be any one of a variety of interfaces, e.g., computer monitors with accompanying keyboards and mouses.

As shown in FIG. 3, data flows from the extract files 18 through database system 20 to GUIs 26. The instructions stored in memory 22 may instruct processor 24 to process data, which are stored in extract files 18 or stored or produced within database system 20, in several ways. For example, processor 24 may retrieve, store, decode, filter, track, link, and display data. The blocks shown in FIG. 3 comprise an integrated set of functional units for processing data within database system 20. As indicated by block 28, database system 20 may perform preprocessing operations on extract file data. Such preprocessing may include reading data from the extract files, decoding the data, packing the data, performing any other preliminary preprocessing on the data, and sending the preprocessed data to memory 22 (FIG. 2) for storage in one or more internal database tables 34. In particular, the preprocessing operation relates to arranging the data in a compressed format. At block 28, summary tables that summarize data in the other tables may also be produced, and configuration files 30 and auxiliary data files 32 may be read by processor 24.

Processor 24 reads configuration files 30 upon startup of the system and each time database system 20 runs the preprocessing operations. Configuration files 30 include parameters that both are and are not specific to a particular site where database system 20 runs. Information specific to the site includes system parameters, file names, path names, and a data dictionary describing database tables 34, i.e, names and structures, including width and type, as well as links between the database tables. Such site- specific data may be stored in both text and binary formats. Configuration files 30 may also include text data for interpreting extract files from the host computer.

Auxiliary data files 32 contain supplementary information not included in the extract files, such as data about cities and their populations and terminal numbers associated with appropriate city names. Information from files 30 and 32 may also be stored in database tables 34. The packing performed in block 28 further reduces the resources needed to store transaction data. Such packing may include one or more of the techniques described above. For example, known limits on data fields may be used to reduce data storage requirements. This technique may be used in producing the extract files or with respect to the operations of block 28, or both. In addition, further packing or coding of data, e.g., for specific wager transactions, may be performed in block 28. Transactions or other forms of user-selected data may also be packed using techniques such as interval coding, bitmapping, and reference number assignment, which are described below.

Database tables 34 form a database of information from which data may be extracted and displayed. Each table is a set of structured records containing fields of data stored in a packed, space-saving format. In the context of a gaming system, examples of tables 34 include a transaction table, an agent table, and a terminal table. The transaction table, or master table, includes records representing individual transactions, such as wagers, validations, and cancellations, that are made on a particular day.

Database tables 34 may be accessed, for filtering or otherwise, by internal data access functions 36. Data from tables 34 may also be displayed as a data grid or as a single record and navigated on a display screen, e.g., by moving a cursor among displayed records under the control of processor 24, which implements data display and navigation functions 38.

Data from database tables 34 may be accessed, as indicated by block 36, and selectively retrieved or filtered, as indicated by block 40. A user of GUI 26 employs filter editing tools 46 to produce, modify, name, store, and retrieve filter expressions or user-defined filters 48 that the processor implements at block 40. Filtered data are those stored data that satisfy conditions defined in a query created by the user. Filtered data are stored in the form of binary data files 42 or text data 44. Processor 24 may display text data 44 on a monitor 50 by implementing character data display functions 52, or by printing text data 44 or importing it into a software program such as Excel. Binary filtered data have the same format as database tables 34 and may be accessed by internal data access functions 36 for further filtering 40 or display, as indicated by blocks 38 and 40.

The preprocessing operations of block 28 further include establishing table links between records in database tables 34. Table links are internally-coded pointers that connect records of one table to related or otherwise relevant records of another table. For example, a record representing a transaction in the transaction table may be linked to a record in the agent table representing the agent that issued the transaction. All database tables 34 may be accessed through a sequence of table links starting at the transaction table. Table links are stored in database tables 34 in fields called indexes. In addition, each link need only be stored as an index in one transaction table, not both of the tables which are being linked. The table links also include default links. If more than one link points to a table, then preferably one of the links is specified as a default link for that table. Default links also simplify the syntax of filtering expressions that define the filters. If a filtering expression lacks a necessary link to a database table, then database system 20 provides an appropriate default link. Default link specifications are preferably stored in a configuration file.

History links connect two different records in the transaction table and facilitate wager history tracking, as indicated by block 54. A wager history refers to a set of transactions related to a common bet. For example, the sale of a multi-draw ticket, a validate-with-exchange transaction, and a final validation of the exchanged ticket, may form the history of a particular bet. History links connect different transactions in a wager history. These links are logical operators that are calculated when needed using internal temporary data structures. For example, validation-wager and cancellation-wager links may direct a user of database system 20 to a wager transaction from a corresponding validation transaction or cancellation transaction, respectively, and a wager-validation link may direct a user of database system 20 to a validation transaction from the corresponding wager transaction if the wager has been validated and paid.

Having provided a general overview of portions of database system 20, the following is a more detailed description of the components and operation of the system. Database tables 34 may store gaming data in a variety of different formats to evaluate various aspects of the gaming system. Database tables 34 may fit into one or more of the following categories of tables: transaction, summary, one-dimensional, two-dimensional, and single- record. Every record of a one-dimensional table, such as the agent table or the terminal table, represents a single object, such as an agent or a terminal, involved in gaming activities. Every record of a two-dimensional table contains data that refer to a pair of objects. For example, every record of an agent -by-game table represents an agent - game pair, storing total amounts of transactions placed by a particular agent and related to a particular game. Names of two-dimensional tables refer to the two objects with which each record is associated. Further, every two-dimensional table is logically coupled to a one-dimensional table. For example, the agent -by-game table is coupled with the agent table. Thus, a screen displaying the records of a one- dimensional table may be accompanied by the associated two- dimensional table, and both tables may be displayed in a compound, two-pane window.

Transaction tables, or master tables, contain records representing individual transactions registered on a particular day to any of terminals 16 known to system 10 (FIG. 1) . Each transaction table may store all data for transactions made during a single day. Further, each record in any table is made up of individual fields, each field having an associated bit count or size and a range or permissible set of values which may be entered in the field.

FIG. 9 shows an exemplary wager record 200 in a transaction table. Each record in any transaction table, such as record 200, contains certain common fields. The common fields store the type 202, status 204, time 206, and size 208 of a transaction and also store an error code 210 and game index 212 and terminal index 214 links. The transaction types include wager, cancellation, internal cancellation, validation, and claim transactions. The transaction status may include good, void, rejected, cashed, exchanged, and internally-cancelled transactions. The transaction time represents the number of seconds since the first transaction of the day to the current transaction. The transaction size is expressed in ranges established by the particular gaming jurisdiction. The error code identifies an error category for unsuccessful transactions, and has a no error (NOER) value if a transaction was completed successfully. The game index provides a link to an appropriate record in a game table and is displayed as a game name. The terminal index is stored as a numerical code and provides a link to a terminal table for finding a terminal record relevant to a particular transaction. Transaction records also store transaction-specific fields. Depending on the transaction type, transaction records may differ in the number of fields and the type of data stored. For example, validation records include a field describing a validation method, but wager records do not include this field. Only wager records include board count (indicating the number of game boards on a ticket) and wager method fields. A kicker flag field (indicating that a ticket has a particular characteristic) occurs in wager and cancellation records, but not in validation records. An agent index field occurs in all records except records relating to types of system commands. In the wager record example of FIG. 9, the wager record includes fields for an agent index 220, terminal delay 222, number of draws 224, kicker flag 226, amount 228, board count 230 and wager method 232.

In general, excluding unnecessary fields from records helps to reduce the required storage space. For example, a serial number is assigned to each transaction by an algorithm, and a pointer may point to the algorithm instead of storing the serial number itself in the record.

Fields of records such as transaction records may be grouped together. In particular, if information for a field is associated with specific data for another field, the data from the two fields may be grouped. For example, if a particular agent is associated with a particular terminal, then the agent and the terminal may be grouped. Grouping^' of combinations of fields also helps to reduce the required storage space. Bet data associated with transactions are stored in files called board data files in packed, coded form. Separate files exist for each game and day, with records having fields including a game name code and a continuous date counter indicative of the number of days since the beginning of the game. The board data files contain bet information, each bet including a sequence of numbers selected by a bettor. The sequences of numbers are stored in packed formats as discussed above. Database system 20 may also associate bet data records with appropriate transaction records by storing the bet data in the board data files in the same order as the stored transaction records. Thus, database system 20 may determine the bet data for a transaction by accessing the bet data of the record in the board data file having the same place in the board data file that the corresponding transaction record has in the transaction table. The accessed bet data may also require uncoding, such as with the application of an appropriate algorithm.

Packed formats for bet data reduce storage space requirements, reduce data input and output time and operations, and increase access rates to the stored data. The packed format of bet information may vary, for example for different games.

Transaction records may also store links that support the finding of corresponding records in other database tables. For example, transaction records may include links to summary table records representing objects involved in the transaction, such as the agent issuing the transaction or the terminal at which the transaction occurred. Agent, terminal, and game indexes are numbers of agent, terminal, and game table records representing, respectively, the agent who entered the transaction, the terminal at which it was entered, and the game to which a particular transaction relates.

Summary tables contain data records referring to various objects involved in gaming transactions. These objects include agents, terminals, cities and games. Generally, object data stored in summary tables fall within one of four categories: object identity, numerical totals, auxiliary characteristics, and table links. Object identity data identifies an object, e.g., by name or identification number, such as agent number, game number, or city name. Table records are also ordered according to these data fields. Numerical totals refer to all transactions performed by a particular object such as the total value of tickets sold by an agent, the total number of cancellations performed at a terminal, and the total number of claims made in a particular city. Auxiliary characteristics are various numerical and non-numerical characteristics of an object such as city population, number of on-line terminals in a region, agent privileges, and agent commission groups.

Table links also reference related objects such as an index of a region to which a city belongs or an index of a terminal used for invoicing an agent.

Summary tables are generally either one-dimensional tables or two-dimensional tables. One exception is a global values table, which is a single-record table. The global values table contains only one record which stores data referring to the total daily results of gaming transactions in the gaming jurisdiction. Fields in this table store the total values and volumes of various transaction types such as wagers amount, wagers count, cancels amount, and cancels count. Other fields store time indications such as the day, month, year, and week number. Still other fields contain the times at which sales reached thresholds of 1/10, 1/8, 1/6, . . ., 9/10 of the daily total.

A default link of a database table 34 is an incoming link to that table from another table and is used if a filtering expression does not contain a table link name. The default table link is an implicit access path to a table. The configuration files contain the default table links .

Transaction totals may be stored as sets of fields, which vary little from table to table. For example, the agent table may include transaction total fields for the following: agent wagers amount, agent wagers count, agent cancellations amount, agent cancellations count, agent validations amount, agent validations count, agent claims amount, agent claims count, agent ticket charge amount, and agent wager fee amount. Other tables include similar fields, with "agent" in the field names replaced appropriately, e.g., with "terminal" in the terminal table. FIG. 10 shows an example of an agent table 300. Agent table records are identified by agent number 302 and contain agent-related information. Data stored in the agent table include agent's transaction daily totals 304, agent's commission group 306, and agent's first and last transaction times 308 and 310. Table links for the agent table include agent's commission terminal index 312, agent's invoice terminal index 314, agent's region index 316, and agent's last terminal index 318. The commission terminal is the terminal at which the agent may print the agent's commission reports, and the invoice terminal is the terminal dedicated to printing invoices for that agent. The first two indexes listed are used in particular, e.g., with certain lottery systems such as that of Poland, and might not be needed for lottery systems in other gaming jurisdictions. The present invention may accommodate different jurisdictions by editing appropriate fields in the configuration files to customize database system 20. The agent's last terminal index refers to the terminal at which the agent last logged in on that day. The only two-dimensional table associated with the agent table is the agent -by-game table. The agent default link is the transaction agent index starting at the transaction table (FIG. 9) .

City table records are identified by the city name field and store information referring to cities. The city table stores data including city-based transaction totals summed from all terminals- in the city, the average amount of work time of agents and terminals in the city, and the numbers of active terminals and on-line terminals. The city table's only link, city region index, refers to the region to which the city belongs. The city table default link is the terminal city index starting at the terminal table. Both city-by-game and city-by-minute tables are associated with the city tables. Region table records are identified by region name or number and store information describing regions representing groups of cities. Data stored in the region table include region population, region-based transaction totals summed over all terminals in the region, the average amounts of work time of agents and terminals in the region, and the number of active terminals and on-line terminals. This table has no links to other tables, and the default link is the terminal region index stored in the terminal table. Both region-by-game and region-by-minute tables are associated with the region table.

Terminal table records are identified by a terminal number field and contain terminal-related information (Fig. 1) . Data stored in the terminal table include terminal - based transaction totals, an agency identifier corresponding to the agency identified with the terminal's location, a drop address and port numbers associated with the terminal, enable/disable flags, e.g., for reporting winning numbers and ticket message printing, and first and last transaction times. The terminal table includes table links of agent's invoice terminal index, a terminal region index, a terminal city index, a terminal station index, and a terminal communication processor index. The default link of the terminal table is the transaction terminal index from the transaction table. Of the two-dimensional tables, only the terminal -by-game table is associated with the terminal table.

Station table records are identified by a station number field and store information relating to stations 14

(FIG. 1) . The station table stores information for station- based transaction totals, which are summed over all terminals 16 communicating with station 14, statistics related to technical aspects of station activity, e.g., number of retries, and terminal statistics and totals, e.g., average terminal work time. The station table has one link, the station communication processor index, that refers to the communication processor 13 with which the station communicates. The default link for the station table is the terminal station index stored in the terminal table. The station table has no associated two-dimensional tables.

Communication processor table records are identified by a communication processor number field and contain information related to communication processor 13 (FIG. 1) . The communication processor is located at data center 11 and communicates with terminals 16 through stations 14. Data stored in the communication processor table include communication processor-based transaction totals summed over all terminals 16 communicating with communication processor 13, the number of stations 14, and the number of active terminals and the on-line terminals. This table has no outgoing links, and its default link is the terminal communication processor index stored in the terminal table. The communication processor table has only one associated two-dimensional table, the communication processor-by-minute table.

Game table records are identified by a game number field and store information related to individual games, e.g., keno, lotto and powerball, operated by data center 11. Data stored in the game table include game-based transaction totals summed over all transactions pertaining to a game, game characteristics such as bet price, current draw number, ticket charge and claim period, and the numbers of active, on-line and configured terminals. The game table has one outgoing link, the lottery index, that refers to a lottery company running the game. The default link for accessing game records is the transaction game index stored in the transaction table. Associated with the game table are four two-dimensional tables, namely game-by-minute, game-by- board, game-by-draw, and game-by-system.

Lottery table records are identified by a lottery identifier field and contain totals of particular lotteries operated by data center 11, which may be running several games. Data stored in the lottery table include lottery- based transaction totals summed over all transactions concluded on behalf of a gaming company, and the numbers of configured, active and on-line terminals operating for a particular lottery. This table has no outgoing links, and its default link is a game lottery index stored in the game table. The lottery-by-minute two-dimensional table is associated with the lottery table.

Minute table records store total transactions count and total sales amounts broken down by single minutes.

Records are identified by a minute number field. The first minute of an operation day is labeled number 1, and the numbers grow by 1 each minute. These minute numbers are used in the city-by-minute, game-by-minute, and other "xxx- by-minute" tables. Data stored in the minute table include a time stamp of every minute (stored in the form HH:MM:SS representing hour, minute and second) , a minute transaction count, and a minute sales amount. This table has no links to other tables, and no two-dimensional tables are associated with the minute table.

Two-dimensional tables provide data associated with object pairs. Two-dimensional tables may be displayed on GUIs 26 with appropriate one-dimensional tables in block data windows, or they may be displayed by producing filter- based reports using the filters. The agent-by-game table records contain transaction totals computed separately for every agent -game pair. The terminal -by-game table is constructed in a similar way, but its records correspond to terminal-game pairs. The city-by-game table contains transaction totals computed separately for every city-game pair, and the region-by-game table contains similar totals computed for region-game pairs. The city-by-minute table records contain transaction counts and wager amounts computed separately for every city-minute pair. The communication processor-by-minute table contains similar values for communication processor-minute pairs. The game- by-minute, terminal -by-minute, and region-by-minute tables are also constructed in the same way. The game-by-board table contains only wager counts accumulated separately for every game coupled with a number of boards played by bettors. The game-by-draw table contains only wager counts for the number of draws for which bets were made. Similarly, game-by- system tables contain wager counts for all gaming systems.

Configuration files 30 may affect the appearance and operation of database system 20. These files contain information corresponding to a data dictionary of industry- standard database systems. This information affects both the internal structure of database system 20 and the way information is presented to a user at GUI 26. Both the internal structure and the presentation of information may be customized by the user by modifying the configuration files. For example, the user may customize data table names (allowing for addition of new data tables) , data categories (whether a table is one-dimensional, two-dimensional or a single-record table) , fields belonging to particular data tables, field details including size and type, short field names used as headers of data grids and as captions of single-record display forms, long field names used in making or modifying a filter and used in field selection lists, and default table link definitions specifying which tables are linked by which index fields. The transaction data grid, e.g., may also be customized on-line, without editing configuration files, by manipulating column options, e.g., when deciding how to display data. A user interacts with database system 20 through

GUIs 26 to display and navigate data using the data display and navigation functions 38 and to manipulate the filters. The display and navigation functions use the internal data access functions 36 as needed to obtain the desired data from database tables 34 or filtered binary data files 42.

Database system 20 provides a menu-driven interface on GUIs 26 for the user. By selecting options presented to the user in the different menus, the user may produce, name, and modify filters, display data such as tables, and navigate through displayed data as desired. The menu-driven interface is designed to be simple and easy to learn and use, yet provide the user with many options for manipulating data. The user may also display filtered data in text format 44 on a monitor 50, which may be part of GUI 26, using character data display functions 52.

For example, FIG. 4 shows a process 60 of displaying and navigating data from a transaction table. Process 60 is similar for displaying and navigating data from other tables 34. In each of the stages shown, the user interacts with database system 20 through one or more GUIs 26 using the menu-driven interfaces of the GUI. At stage 62, the transaction table is produced if it does not already exist. This may be accomplished by the user's selecting a preprocessing option from the menu interface, causing database system 20 to perform preprocessing operations 28 to produce the transaction table. By further selecting a file open/display option and entering the name of the desired transaction table at stage 64, the user causes database system 20 to initiate the opening and displaying of the transaction table. At stage 65, data referred to in the table by pointers or which needs to be calculated is accessed and/or calculated to fill in the data for the table. The complete table is displayed on GUI 26.

Transaction table records, representing every transaction known to database system 20 for a given day, are displayed as rows of a data grid. These records contain detailed transaction data and links to other database tables containing bet data and details of agents and associated objects involved in gaming transactions.

At stage 66, the user navigates through the displayed transaction table. As one option., the user may move within the transaction table grid by pressing arrow keys, i.e., the PgUp, PgDown, Ctrl-PgUp, Ctrl-PgDown, Home and End keys, of a standard keyboard of GUI 26. The user may also navigate through the grid by selecting command options, such as line up and line down, from a navigate menu. Other options of the navigate menu enable the user to move to a specified record or find the next record that conforms to a user-defined condition. The user may further specify search conditions as data filters using filter editing tools 46.

All transaction rows are labeled with time stamps displayed in the leftmost column. The user may move to a row with a requested time stamp, record number or internal serial number. Navigate menu options also allow the user to move records using time interval jumps by specifying a time interval and then jumping to a row separated from the current row by the specified time interval. Alternatively, the time of a transaction may be stored according to a mapping, without storing the actual time information in the transaction record. For example, a pointer may be used to point to a stored time, where the pointer requires fewer bits than the stored time. This may be especially useful where many transactions have the same time data, so that the full time data need only be stored once. The user may customize the transaction data grid.

Customizing options include adding or removing grid columns, linking grid columns to selected columns of underlying data tables, defining grid column names that are not necessarily identical to names of underlying table columns, inserting relevant fields from non-transaction data tables into transaction rows, which supports data readability and is made possible by default links, and associating multiple data table columns with a single grid column. The last option allows a single column to be used for displaying non-colliding transaction-specific fields, i.e., fields that do not occur together in a single record, to reduce the number of grid columns. The user may also display a column definition. This may be done, for example, from a menu produced in response to pressing the right-hand button of a mouse. The column definition allows the user to easily find out which data fields are associated with a selected column. Column definitions help the user avoid ambiguities in data interpretation that may result from using arbitrarily- defined column headers and associating multiple table fields with a single grid column. Transaction details may be scrambled before being stored, as is the case with full bet information, or may require re-calculation every time they are to be displayed, such as with transaction serial numbers. Scrambling and recalculating data are done to decrease the volume of memory needed. Scrambled transaction details and data requiring re-calculation do not show up in the transaction data grid, but are displayed on demand when the user invokes an option from an appropriate menu such as a view menu.

A process similar to process 60 may be used to display and navigate summary tables containing data about agents, terminals, cities and other entities involved in gaming transactions. Summary tables may also be accessed by building and applying filters, as discussed below. For instance, all summary tables related to a particular day may be stored in one file.

As shown in FIG. 5, summary tables are displayed in block data windows that are two-pane windows showing a single record 70 of a summary data table together with a multi -record grid 72 composed of relevant records from an associated two-dimensional summary table. For example, if the agent table is displayed, its associated two-dimensional table agent-by-game is also displayed. The single record 70 contains a single agent's record, and the grid 72 is a grid of records automatically selected from the agent-by-game table related to the selected agent. The grid 72 thus contains data related to the selected agent for all games known to database system 20. If the user selects a record of another agent from the agent table, then database system 20 automatically selects records for this agent and the known games such as lotto, keno, and powerball, and places them in grid 72. The same principle of displaying relevant data records in a data grid applies to all other one-dimensional tables and their associated two-dimensional tables. For example, a terminal record is coupled with its terminal -by-game records, and a city record is coupled with its city-by-game records. Data grids displayed as part of block data windows respond to arrow keys on the keyboard and scroll bars of GUI 26 for data navigation.

One-dimensional tables of block data windows are displayed one record at a time. Records are selected and navigated, e.g., by clicking on data movement buttons, such as Previous or Next, or by using a mouse of GUI 26. Two record- search functions provide further navigation of one- dimensional tables in block data windows. A go-to-value function and a go-to-record function find and display records that contains a specified value or record identifier entered by the user. The data in database tables may be filtered as desired by the user. In particular, data may be filtered into binary-coded filtered data sets or ASCII-coded filtered data sets. Binary-coded filtered data sets are permanent objects that may be viewed as data grids, and have a structure resembling that of transaction tables with records containing fields. Single filtered tables may contain fields from several data tables, including both transaction tables and summary tables. ASCII-coded filtered data sets are text reports containing data selected from one or more of database tables 34.

As shown in FIGS. 1-3, filters 48 are represented by expressions that instruct database system 20 as to which records and fields to select from database tables 34 and insert into filtered data sets 40 and 42. Filters 48 are stored in memory such as on hard disk, are reusable and may be modified.

FIG. 6 shows how filters 48 may be produced and modified with filter editing tools 46 using a process 80. Editing tools 46 include a filter builder and a filter editor that use common screen forms on GUI 26 and closely cooperate with each other. At stage 82, the user selects a filter builder/editor option using GUI 26. The filter editor and filter builder may be displayed together, such as with a builder option in an editor window.

At stage 84, the user selects either the filter builder or the filter editor. If the user selects the filter builder, then the filter builder displays field names, transaction types, transaction status codes and other text items out of which filtering expressions may be built. The user defines the filter by selecting desired fields at stage 86. The selected text items are automatically placed in an editing area when selected by the user for editing of the filter at stage 90, as described below. The selected items form a filter expression for implementing the filter to select the desired data from database tables 34 or filtered tables 42.

If at stage 84 the user selects the filter editor, then at stage 88 the user selects by name a stored filter for editing. At stage 90, the filter built in stage 86 or selected in stage 88 is provided by the filter editor for editing. The filter editor is an editing window where filters may be entered as text strings or edited. The filter editor includes a test utility that checks filter syntax, a filter selection list for selecting predefined filters, and a help list containing field names displayed together with their types and descriptions. At stage 90, the user edits a filter as desired using GUI 26 and stores the user-defined filter for future use, if desired. Examples of user-defined filters are (1) find all transactions completed at a terminal whose invoiced agent has the number 1028, (2) find all lotto wagers entered at a terminal whose index is 3762, and (3) find all transactions concluded at a terminal at which more than 2000 keno wagers have been issued. These examples are descriptions of data to be filtered, with the data being filtered by implementing filter expressions.

At stage 92, the user invokes the filter, as indicated by a filter expression from stage 90. Filter expressions need not specify the table 34 or 42 from which to select data records. The table name in a filter expression may be entered in a separate text field or assumed to be the transaction table by default. In filtering expressions, the data fields are referred to by their short names. These names are abbreviations of meaningful and readable long names. The filter builder may display a type of help window containing both full names and their abbreviated forms, so the user need not remember the short names. Referring to the three exemplary filters listed above, the first filter expression would have the transaction type set equal to "wager, " and the number field of the agent record referred to by the agent index field of the transaction record set equal to 1028. Using the fact that the agent index field is the default transaction-agent link, the expression may omit reference to the agent index. Referring to the second exemplary filter, the filter expression would set the transaction type to "wager, " the game index to "10" (assuming this corresponds to lotto) , and the number field of a terminal record linked by the terminal index stored in the transaction table to 3762. Instead of specifying the index of lotto as 10, the filter expression may tell database system 20 to use the game name stored in the game table as indicated by the game index. For the third exemplary filter above, the expression would use the terminal -by-game table and seek the terminal, as indicated by the terminal index, corresponding to a listing for keno whose count exceeds 2000.

Upon filter invocation 40 (FIG. 3) at stage 92, a filter is applied to succeeding transaction table records or a non-default table, if specified, and to the records in summary tables that are referred to in those transaction records by table links. If no particular link field is named, then a default link is assumed. Filtered data are in the form of either binary data files 42 or text 44. Database system 20 may process filtered data in text format into text reports using character data display functions 52 (FIG. 3) . These functions supply tools for defining report formats and producing text reports. The reports may be displayed, e.g., using ordpad^® or imported, e.g., by Excel^® without additional processing. The reporting tools allow for rapid production of customized reports ranging over long time periods, including monthly and yearly reports and reports covering other arbitrarily selected time intervals. Reports may also be produced based on predetermined report definitions. The definitions are specified by the user with a report tool invoked, e.g., from a report menu as part of the menu-driven user interface. Report definitions contain a filter, dimension descriptions and cell descriptions. A report's filter determines which data records will be taken into account while producing the report. Report filters have the same form as filters used for producing filtered data tables.

Reports are collections of uniform data units called cells. A cell is either a single data item or a set of data items such as single values derived from database fields, e.g., totals or counts. For example, a cell may include two data items such as the number of transactions related to a game and the total amount of those transactions. Data item descriptions specify processes of computing values of the items. These processes determine whether a data item is a logical flag, a counter, a total or an accumulated expression.

Report dimensions facilitate defining data groups in produced reports. A dimension corresponds to a series of neighboring data cells, arranged sequentially and ordered according to values assigned to each cell. These ordering values are referred to as indexes, which are not necessarily the same as the indexes which provide links. Horizontal and vertical dimensions determine how data cells of a report are arranged in rows and columns. A row of data cells corresponding to five games known to the system is an example of a dimension, with game numbers being the indexes. Another example is a column of cells corresponding to regions, with the cells ordered by region numbers.

A dimension description specifies the lowest and highest index values of the dimension and an indexing expression. The indexing expression may be a field name or a formula for calculating succeeding index values.

To support grouping and ordering data in more than two ways (in rows and columns) , there may be a third dimension, which is called a tabled dimension. Using the tabled dimension, the cells are arranged into separate tables, with all cells in a table having the same index with respect to the third dimension. The tables are ordered according to this index. Cells inside a single table are arranged in rows and columns according to their vertical and horizontal indexes.

FIG. 7 shows a sample three-dimensional yearly report 100 for keno wagers. Each cell 102 of the report contains two items, i.e., sales count and sales amount. The report's vertical dimension 104 represents distribution of sales among multi -draw wagers for games numbered 1 through 12. The horizontal dimension 106 corresponds to spots on a game card corresponding to the bettor's selections for which bets were made. The third dimension of the keno report 100, implemented as a series of three tables 108, 110, and 112, represents distribution of sales among three methods of wagering, namely manual, betslip and quick pick. All headers and side labels may be manually added using, e.g., Excel^®. The ability of producing headers and summary fields may also be incorporated into database system 20.

As shown in FIG. 3, database system 20 implements ticket history tracking using wager history and tracking functions 54. Database system 20 allows navigation through transaction history chains, the chains being sequences of transactions having something in common with a particular bet. The user may navigate through history chains to see events related to a given bet or transaction.

History links track the history of a bet. The tracking functions 54 include three kinds of history links, namely forward wager-validation links, backward validation-wager links, and backward cancellation-wager links. The wager-validation links are called "forward" links because they link a wager transaction to a validation transaction that occurs later in time, so that the link links the wager forward in time to the validation. Conversely, the "backward" links link validation and cancellation transactions backward in time to corresponding wager transactions.

History links may speed up a search for a transaction related to a transaction already selected in a data grid. These links are calculated when needed, and stored using internal temporary data structures, e.g., a file, and thus need not be, and preferably are not, stored in the transaction records.

As shown in FIG. 8, a process 120 for linking transactions begins at stage 122, where the user navigates within database table 34 to a desired transaction such as a wager transaction. The user may focus on a selected transaction, such as by moving a cursor to the selected transaction. At stage 124 the user selects a desired link such as a wager-validation link, e.g., by pressing "enter" on a keyboard or clicking .a mouse of GUI 26. At stage 126 database system 20 attempts to find a validation transaction related to the same transaction and having validation in its type field. Upon finding a related transaction, processor 24 forms and stores a link between the serial numbers of the two transactions. At stage 128, a check is made as to whether the attempted link was successful. If the link is not successful, then at stage 130 an appropriate error procedure is followed, such as displaying an error message. If the link is successful, then at stage 132 database system 20 opens a new transaction grid and focuses on the row of the linked field, i.e., the validation transaction field in this example. The history links may also connect transactions concluded on different days. Other history links may be used in a similar manner.

Other embodiments are within the scope of the appended claims. For example, database system 20 need not include graphical user interfaces; any type of interface that permits communication between database system 20 may be used. Moreover, the invention is applicable to data processing generally, and is not limited to gaming systems.

What is claimed is:

Claims

1. A computer-based method for storing and accessing data by a user, the data being obtained from a series of transactions, the method comprising: arranging the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions; storing the records in a memory in the form of a plurality of database tables, each database table comprising at least one record; establishing a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables; and accessing data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

2. The method of claim 1 further comprising displaying the accessed data.

3. The method of claim 1 further comprising preparing a text report using the accessed data.

4. The method of claim 1 further comprising creating the filter operation at the request of the user.

5. The method of claim 1 further comprising creating a filtered table using the accessed data.

6. The method of claim 1 wherein the arranging the data in a compressed format further comprises inserting a pointer in a record of a first database table to a value in a record of a second database table.

7. The method of claim 1 wherein the database tables include a transaction table linked to all other database tables.

8. The method of claim 1 wherein the link relates records that are historically related to each other.

9. A computer-based method for storing data, the data being obtained from a series of transactions, the method comprising: arranging the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions; storing the records in a memory in the form of a plurality of database tables, each database table comprising at least one record; and establishing a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables.

10. The method of claim 9 wherein the arranging the data in a compressed format further comprises inserting a pointer in a record of a first database table to a value in a record of a second database table.

11. Apparatus for storing and accessing data by a user, the data being obtained from a series of transactions, the apparatus comprising: a condensed file memory to store the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions; and a database system comprising a database memory to store the records in the form of a plurality of database tables, each database table comprising at least one record, and a processor to establish a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables and to access data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

12. The apparatus according to claim 11, further comprising a display to display the accessed data.

13. The apparatus according to claim 11, further comprising a graphical user interface by which the user specifies the condition for the filter operation and displays the accessed data.

14. A computer-based method for storing and accessing gaming data by a user, the gaming data being obtained from a series of gaming transactions, the method comprising: arranging the gaming data in a compressed format in a plurality of records that are related to each other based upon the series of gaming transactions; storing the records in a memory in the form of a plurality of database tables, each database table comprising at least one record; establishing a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables; and accessing gaming data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating gaming data in the related records based on the link.

15. The method of claim 14 further comprising displaying the accessed gaming data.

16. The method of claim 14 further comprising preparing a text report using the accessed gaming data.

17. The method of claim 14 further comprising creating the filter operation at the request of the user.

18. The method of claim 14 further comprising creating a filtered table using the accessed gaming data.

19. A computer program product for use with a system for storing and accessing data by a user from a series of transactions, the computer program product comprising instructions for causing a computer to: arrange the data in a compressed format in a plurality of records that are related to each other based upon the series of transactions; store the records in a memory in the form of a plurality of database tables, each database table comprising at least one record; establish a link between related records in the database tables by inserting a pointer in at least one of the database tables to at least one other of the database tables; and access data from the stored records by applying a filter operation based on at least one condition specified by the user, the filter operation associating data in the related records based on the link.

20. The computer program product of claim 19 further comprising instructions for causing the computer to display the accessed data.

21. The computer program product of claim 19 further comprising instructions for causing the computer to „prepare a text report using the accessed data.

22. The computer program product of claim 19 further comprising instructions for causing the computer to create the filter operation at the request of the user.

23. The computer program product of claim 19 further comprising instructions for causing the computer to create a filtered table using the accessed data.