Mobile data access

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. provisional application 60/439,084 entitled “System for Realtime Game Network Tracking”, filed Jan. 8, 2003, and “Mobile Data Access”, filed Jun. 10, 2003, (attorney docket number 4164-272), the contents of both of which are expressly incorporated herein for all purposes.

TECHNICAL FIELD

[0002] This disclosure relates to networks of gaming devices, and, more particularly, to accessing data from the networks in a secure manner over a wireless network.

BACKGROUND OF THE INVENTION

[0003] Gaming networks are communication networks of interconnected gaming devices. Typically, gaming networks include a collection of gaming devices, or EGMs (Electronic Gaming Machines) that are linked to a central server. As the EGMs are played, events occur that are tracked by the EGM, such as coins being deposited, buttons pressed, handles pulled, jackpots won, etc. The EGMs also store data in meters, such as value of coin in, total games played, total payout, etc.

[0004] The central server or servers can also store large amounts of data on databases, such as a player's history, (i.e., what games the player has played, at what times, etc.) number of loyalty points accumulated, accounting information about single and groups of EGMs, data about special promotions and bonuses, etc.

[0005] As can be seen, there are vast amounts of data present on the gaming network to be managed, logged and accessed.

[0006] Presently, data stored on the gaming network is typically accessed by logging onto a computer terminal that is wired to the network. Once logged in, different applications can be run that access data from the databases and elsewhere on the gaming network. Additionally, log files and summaries are prepared and, in some instances, printed for review by the gaming network operators.

[0007] Operating the terminal to retrieve data from the gaming network requires physical presence of an authorized user at the appropriate terminal. Because these terminals are relatively large, and are coupled to the gaming network through a cable, the terminals are fixed and not movable. Therefore, data from the gaming network can only be accessed in particular locations on a gaming floor. Although wireless data networks are becoming more widespread for some applications, like email, because of strict data privacy and security issues in gaming networks, no viable solution involving wireless networks is presently available.

[0008] Embodiments of the invention address these and other deficiencies in the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The description may be best understood by reading the disclosure with reference to the accompanying drawings.

[0010]FIGS. 1A and 1B together are a block diagram showing components of a gaming network according to embodiments of the invention.

[0011]FIG. 2 is a block diagram showing example components of a secure wireless network operating in conjunction with a gaming network, according to embodiments of the invention.

[0012]FIG. 3 is a chart illustrating different forms of security used in establishing and conducting wireless communication of data.

[0013]FIG. 4 is an example flow diagram illustrating an example flow for establishing communication between a wireless device and a wireless host on a gaming network.

[0014]FIG. 5 is a block diagram illustrating components of an example redemption server.

[0015]FIG. 6 is a screenshot of an example screen that can be shown on the redemption server of FIG. 5.

[0016]FIG. 7 is a screenshot of an example log screen that can be shown on the redemption server of FIG. 5.

[0017]FIG. 8 is an example flow diagram illustrating an example flow for redeeming tickets using embodiments of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Embodiments of the invention are directed to a gaming network that supplies data that can be accessed by devices over a secure wireless network. Wireless servers or hosts generate communication and data channel signals that are sent to wireless receivers used by casino operators or employees. Users of the wireless receivers establish a secure session with a wireless server running on the gaming network. Once the secure session is established, applications on the wireless servers can request data from the server and/or provide data to the server. For some applications, the data can be requested to service users of games on the gaming network.

[0019] One such gaming network is illustrated in FIGS. 1A and 1B. In a gaming network <b>5</b>, a number of EGMs <b>10</b> are organized in groups called banks. Individual banks <b>20</b>, <b>22</b>, and <b>24</b>, can contain almost any number of gaming devices <b>10</b>. Additionally, any number of banks is possible in a gaming network <b>5</b>.

[0020] Each bank is controlled by a bank controller <b>30</b>, which is coupled to each EGM <b>10</b> by a communication cable <b>12</b>. The bank controller <b>30</b> facilitates data communication between the gaming devices <b>10</b> in its associated bank and the other components on the gaming network <b>5</b>. In some embodiments, the bank controller <b>30</b> need not be present, and the EGMs <b>10</b> communicate directly with the other portions of the gaming network <b>5</b>.

[0021] Configuration data for the gaming network <b>5</b> is stored in one or more network data repositories <b>61</b>, <b>67</b>. In some embodiments, the data repositories <b>61</b>, <b>67</b> are made of battery backed-up non-volatile SRAM (Static Random Access Memory), which provides dual advantages of having extremely fast data input and output, and having a power source that is independent from the network <b>5</b> or the gaming devices <b>10</b>. The data repositories <b>61</b>, <b>67</b> may also be mirrored, i.e., duplicate copies are made in real-time. This prevents data from being lost if one of the battery sources should fail or other catastrophic event. Data is stored in the data repositories <b>61</b>, <b>67</b> using CRCs (Cyclic Redundancy Checks) and timestamps to ensure the data is valid and non-corrupt.

[0022] Configuration data is created at a configuration workstation <b>44</b> and stored in the data repositories <b>61</b>, <b>67</b>. Configuration data includes message data for players as well as for promotions such as bonuses. Player message data is stored in the data repository <b>61</b>, where it can be accessed by a player server <b>60</b>. Player message data can include welcoming messages, card-in/card-out messages, and special messages about current promotions, for instance. The player server <b>60</b> reads the message data from the data repository <b>61</b> and sends a properly formatted message back to the bank controllers <b>30</b> and EGMs <b>10</b>. These player messages may be displayed on a screen <b>32</b> for an entire bank, or may be shown on a screen directly mounted to the EGM <b>10</b> (not shown).

[0023] Other configuration data created at the configuration workstation <b>44</b> and stored in the data repositories <b>61</b>, <b>67</b> includes casino configuration data, such as identification of each EGM <b>10</b> on a casino floor. Additional parameters stored in the data repository <b>67</b> are parameters used in promotions, such as bonus promotions. These parameters include such items as what EGMs <b>10</b> are included in the promotion, how to fund a bonus, i.e., if a bonus is funded by a portion of the coin-in amount of the EGMs <b>10</b>, whether a paid bonus is to be taxed or un-taxed, and other parameters.

[0024] As players play the EGMs <b>10</b> in the gaming network <b>5</b>, the EGMs send data from their coin meters, or meter values. One or more bonus server <b>66</b> stores these meter values, or summaries of the meter values, in its associated data repository <b>67</b>. The bonus servers <b>66</b> can also operate based on the present and stored meter values to determine an amount of money being wagered on the EGMs in near real-time. The bonus servers <b>66</b> can use the amount of money being wagered to calculate bonus pools that are funded as a percentage of the coin-in of participating EGMs <b>10</b>. For instance, the bonus servers <b>66</b> can calculate a present amount of a bonus pool that is funded at one-half of one percent of the coin-in for the participating EGMs <b>10</b>. An example of bonus promotions that can be operated from the bonus servers <b>66</b> includes LUCKY COIN and progressive bonuses, for example.

[0025] Of course, the servers <b>60</b>, <b>66</b>, could be embodied in a single device, or in other configurations, and do not have to appear in FIG. 1A, which is only a functional representation. Likewise, the data repositories <b>61</b>, <b>67</b> could be embodied in a single device.

[0026] As data is generated by the EGMs <b>10</b>, data is passed through communication hardware, such as Ethernet hubs <b>46</b>, and a concentrator <b>48</b>. Of course, switches or bridges could also be used. The concentrator <b>48</b> is also coupled to a translator <b>50</b>, which includes a compatibility buffer so that the data from the EGMs <b>10</b> can be used by a server cluster <b>56</b> (FIG. 1B), and other parts of the gaming network <b>5</b>.

[0027] The server cluster <b>56</b> (FIG. 1B) may, of course, be embodied by more than one physical server box. In practice, including multiple server boxes with dynamic load sharing and backup capabilities of one another ensures the gaming network <b>5</b> is nearly always operational.

[0028] The server cluster <b>56</b> is attached to and manages several databases, such as a slot accounting database <b>90</b>, a patron management database <b>92</b>, a ticket wizard database <b>94</b>, a “Cage Credit and Table Games” (CCTG) database <b>96</b>, a player tracking database <b>98</b>, and a cashless database <b>99</b>. These databases are collectively referred to as the databases <b>100</b>. Of course these databases <b>100</b> are only exemplary, and more or fewer databases can be part of the gaming network <b>5</b>. In some embodiments, particular servers in the server cluster <b>56</b> manage a single database. For example, a single server in the server cluster <b>56</b> may manage the slot accounting database <b>90</b>, while another server manages the patron management database <b>92</b>. Such implementation details are well within the expertise of one skilled in the art. However, for ease of illustration, FIG. 1 shows a single server cluster <b>56</b> that is coupled to all of the databases <b>100</b>.

[0029] In operation, the slot accounting database <b>90</b> receives and stores statistical and financial information about the EGMs, such as dates, times, totals, game outcomes, etc. The patron management database <b>92</b> stores information regarding identified players, such as how often and which games they play, how often they stay in the casino, their total loyalty points, past awards, preferences, etc. The ticket wizard database <b>94</b> stores data about tickets that are issued by the EGMs, such as payouts and cashout tickets, as well as promotional tickets.

[0030] The CCTG database <b>96</b> stores information about non-EGM <b>10</b> data in a casino. That data is typically generated by a client station (not shown) coupled to one of the bank controllers <b>30</b>. The client station can be located in a casino cage or at a table game, for instance, and data generated by the client station is forwarded to the CCTG database <b>96</b> where it is stored. For example, data such as when and how many chips a customer buys, when a customer creates or pays off markers, when a customer cashes checks, etc. is stored in the CCTG database <b>96</b>.

[0031] The player tracking database <b>98</b> is a subset database of the patron management database <b>92</b>, and is used when data retrieval speed is important, such as for real time promotions and bonusing. The cashless database <b>99</b> stores information about payment options other than bills, coins, and tokens.

[0032] Application clients <b>80</b> and <b>82</b> couple to the server cluster <b>56</b>, and can retrieve data from any or all of the databases <b>100</b>. Application programs run on an application client <b>80</b>, <b>82</b> to provide users information about the gaming network <b>5</b> and the casino in which the network is established and to cause functions to operate on the gaming network <b>5</b>. An example application client <b>80</b> could include, for instance, an accounting server that allows queries and provides reports on financial and statistical information on single or groups of EGMs <b>10</b>.

[0033] A data interface <b>88</b> presents a uniform interface to other applications and servers (not shown), and grants access to retrieve data from the databases <b>100</b>. Typically these other clients or servers would not be controlled by the same entity that provides the other components of the gaming network <b>5</b>, and therefore the data interface <b>88</b> grants only guarded access to the databases <b>100</b>. Other components of the gaming network <b>5</b> of FIG. 1 are discussed in detail below.

[0034]FIG. 2 is a block diagram of components of the gaming system according to embodiments of the invention. In FIG. 2, a gaming floor <b>118</b> is illustrated. The <b>5</b> gaming floor includes banks <b>120</b> of gaming machines. Several banks <b>120</b> are illustrated, although the number of banks on a gaming floor <b>118</b> could be as few as one (or simply a single EGM <b>10</b> not associated with any bank) or as many as is practical. Illustrated in FIG. 2 are five banks <b>120</b>.

[0035] Also shown in FIGS. 1 and 2 are a number of wireless servers <b>130</b>, also referred to as wireless access points (WAPs). The wireless servers <b>130</b> transmit and receive RF (Radio Frequency) signals over the gaming floor <b>118</b>, thereby communicating with one or more wireless devices <b>140</b>. Example wireless servers <b>130</b> are those that adhering to IEEE 802.11b, 802.11a, or 802.11g protocols, but any acceptable communication protocol could be used. The wireless servers <b>130</b> are connected to each other via wires or wireless links, as is known in the art. The wireless servers <b>130</b> and wireless devices <b>140</b> illustrated in FIG. 1 may be implemented as a same set of wireless servers <b>130</b> and wireless devices <b>140</b>, or may, in fact, be separate systems, where the wireless devices <b>140</b> only communicate with a particular, and not all, wireless servers <b>130</b> in the game network <b>5</b>. The wireless devices <b>140</b> both receive and transmit information to the wireless servers <b>130</b>, as is known in the art.

[0036] The wireless servers <b>130</b> are distributed around the gaming floor <b>118</b> so as to cover as much of the gaming floor <b>118</b> with the RF signals as possible. In some instances, areas of the gaming floor <b>118</b> are covered with RF signals from more than one wireless server <b>130</b>. In such a case, the wireless devices <b>140</b> typically automatically establish communication with the wireless server <b>130</b> that is nearest the particular wireless device <b>140</b>.

[0037] The wireless servers <b>130</b> may be separated from the gaming network <b>5</b> by a firewall <b>150</b>. A firewall is hardware and software operating to protect resources of a network. Specifically, the firewall <b>150</b> can be a tunneling firewall that encapsulates and encrypts data packets traveling between the wireless servers <b>130</b> and the firewall <b>150</b>. An application server <b>110</b> can be used in conjunction with the wireless servers <b>130</b> on the gamefloor <b>118</b>. Additionally, a switch <b>160</b> could be used to partition particular IP (Internet Protocol) or other addresses so the partitioned addresses are only available by the wireless servers <b>130</b>, or the wireless devices <b>140</b> that couple to the wireless servers <b>130</b>. Although illustrated outside of the gaming floor <b>118</b>, the firewall <b>150</b>, server <b>110</b>, and switch <b>160</b> could all also be within the gaming floor <b>115</b>. Their physical location is unimportant.

[0038] With reference back to FIG. 1, the application server <b>115</b> of FIG. 2 could be embodied by a Mobile Data Access. (MDA) server <b>108</b>. The firewall <b>150</b> of FIG. 2 is not present in FIG. 1 but could, of course, be added between the MDA server <b>108</b> and the rest of the gaming network <b>5</b>. In FIG. 1, the MDA server <b>108</b> connects to the gaming network <b>5</b> through a communication hub <b>102</b>. The communication hub <b>102</b>, in turn, is connected to the translator <b>50</b> and to an event monitor <b>104</b>. The event monitor <b>104</b> is also coupled to the server cluster <b>56</b>, which was described above.

[0039] The communication hub <b>102</b> collects data from the floor <b>118</b> as “events” when they happen and when they are reported by, for example, an EGM<b>10</b>. Events include, for example, doors to the EGMs <b>10</b> being opened, jackpots or other large amounts being awarded, etc. The event monitor <b>104</b> is connected between the connection hub <b>102</b> and the server cluster <b>56</b>. In operation, the event monitor <b>104</b> combines live data from the communication hub <b>102</b> with historical data from one or more of the databases <b>100</b>, and generates warnings, indications, and signals for someone monitoring the gaming network <b>5</b>. For instance, the event monitor <b>104</b> will create a warning if the door to a particular EGM <b>10</b> is opened but no employee identification card has been inserted in that EGM<b>10</b>.

[0040] Operation of the wireless servers <b>130</b> and wireless devices <b>140</b> is described with reference to FIGS. 1, 2, and <b>3</b>. Illustrated in FIG. 3 are different example levels of providing secure communication between a wireless server <b>130</b> or application server <b>110</b> and a wireless device <b>140</b>. Of course, as described above, a wireless server <b>130</b> can communicate with many wireless devices <b>140</b> at the same time, as can the application server <b>110</b>.

[0041] The lowest communication layer illustrated in FIG. 3 is a hardware connectivity layer. Any or all of the wireless servers <b>130</b> distributed about a game floor <b>118</b> can be a DHCP (Dynamic Host Control Protocol) server, or the DHCP server could be a program running on the application server <b>110</b>. DHCP is a protocol that allows network administrators to centrally manage and automate the assignment of IP (Internet Protocol) configurations on a computer network. When IP protocols are used, each computer coupled to the gaming network uses a unique IP address. Therefore each wireless server <b>130</b> and each wireless device <b>140</b> has its own separate and unique IP address. Having a DHCP server alleviates the necessity to manage each individual IP address, and lets the DHCP server dynamically allocate the IP addresses when requested by devices attaching to the gaming network <b>5</b>. The DHCP server makes IP configurations that are valid for a specific time period, called a lease period. During the lease period, those devices that are authorized to attach to the gaming network <b>5</b> are dynamically given an IP address to establish the communication.

[0042] In operation, the wireless network and the DHCP wireless units are assigned an ESSID (Extended Service Set Identifier), which identifies a wireless LAN. The ESSID of the wireless devices <b>140</b> must match the ESSID of the wireless servers <b>130</b> to establish communication. Typically, an ESSID is a 32-character case-sensitive string.

[0043] Further, the wireless server <b>130</b> and wireless devices <b>140</b> all operate on a particular frequency, or channel. As mentioned above, there are particular protocols on which wireless devices operate. Selection of a channel determines on which particular frequencies of a protocol the devices will operated. The wireless servers <b>130</b> and wireless devices <b>140</b> can all operate on the same channel.

[0044] An additional hardware connectivity level uses MAC (Media Access Control) addressing. A MAC address is a physical hardware address that uniquely identifies each computer node on the gaming network. When the wireless servers <b>130</b> are set up by the gaming network manager, they are set up to only establish communication with particular (known) MAC addresses. For instance, the MAC addresses of the wireless devices are entered into an authorized MAC address list in the wireless server <b>130</b>. Only wireless devices <b>140</b> having MAC addresses that are on such a list are allowed to establish communication with the wireless servers <b>130</b>. In this way, unauthorized wireless devices cannot communicate to the wireless servers <b>130</b> and are prohibited from receiving any data from the gaming network <b>5</b>.

[0045] Furthermore, the wireless servers <b>130</b> and wireless devices <b>140</b> are configured with a particular WEP (Wired Equivalent Privacy) key codes. WEP is a security mechanism defined within the IEEE 802.11 standard and is designed to make the security of the wireless medium equal to that of a wired communication. The gaming network administrator defines a WEP key and all of the wireless devices <b>130</b>, <b>140</b> are set with the same key. Access is denied to any wireless device that does not have the assigned key. WEP keys come in different lengths, such as 40, 64, and 128-bit key lengths. The longer the key lengths, the more secure the code.

[0046] In addition to hardware connectivity, the server <b>110</b> communicates to the wireless devices <b>140</b> through a secure data connectivity layer. Specifically, the server <b>110</b> and the wireless device <b>140</b> can be connected through a VPN (Virtual Private Network). VPNs typically use a tunneling procedure, which places a data packet within another packet. The outer packet provides particular routing information for the embedded packet. Additionally, the embedded packet can be encrypted for additional security. In such systems, only the VPN server and the client know the proper “keys” to unlock the packets. Even if unauthorized wireless devices could gain access to a data packet, because the data within the outer packet is additionally encrypted, the unauthorized device could not read any of the data.

[0047] In addition to secure hardware and secure data layers, the server <b>110</b> communicates to the wireless device <b>140</b> through secure data application layers, such as XML (Extensible Markup Language), HTTP SSL (HyperText Transfer Protocol Secure Sockets Layer), and using MFC (Microsoft Foundation Classes).

[0048] In operation, when a wireless device <b>140</b> communicates to one of the wireless servers <b>130</b>, it must first have the proper frequency, channel settings, ESSID, WEP keys, and MAC address. If any of these settings are not correct, the wireless server prohibits access and, if possible, creates a log of the event. In some embodiments, the wireless device <b>140</b> can create an alert for casino personnel to investigate if someone is trying to hack into the secure network. Such an alert can be sent to an operator terminal at one of the bank controllers (FIG. 1), for example.

[0049] If the wireless device <b>140</b> has the proper frequency, channel settings, WEP key and MAC address, the DHCP server determines if the particular device should be allowed onto the wireless portion of the gaming network <b>5</b>. A particular wireless device may only be authorized to log onto the gaming network <b>5</b> during particular times. The DHCP server monitors these actions and only allows the wireless device <b>140</b> to log in when so authorized. For instance, a particular device can be checked out to a particular employee. The DHCP server can be set up to allow a log in for that device only when that employee is scheduled to work. Or, the DHCP server can be set up to only allow a log in during the first 15 minutes of that employees shift. If the employee did not log in during that time period, the DHCP server could block any log in of that wireless device <b>140</b> until the employee met with a manager, who could re-enable the DHCP server to allow login. additionally, the DHCP server can be set up to automatically log out a previously logged in user who does not use the wireless device <b>140</b> for a period of time, for instance, for over 20 minutes. That prevents an unauthorized person from finding a misplaced wireless device <b>140</b> and taking advantage of the gaming network <b>5</b>. Other detailed examples of using a wireless device are given below.

[0050] Further to those methods described above, data traffic from the wireless device <b>140</b> can be defined by its source, destination, protocol, and port, as is known in the art. Filtering, either by the DHCP server, or the server <b>110</b> itself can provide an additional level of security. For example, if the destination address of a packet is not an authorized destination, the server <b>110</b> can log out the particular wireless device <b>140</b> with the inaccurate destination address. Doing so provides additional security.

[0051]FIG. 4 is an example flow diagram illustrating processes that can be used in the gaming network <b>5</b> according to embodiments of the invention. A flow <b>400</b> begins at a process <b>410</b> where a wireless device <b>140</b> sends signals to the wireless server <b>130</b> to log into the gaming network <b>5</b>. The wireless device <b>140</b> automatically sends its ESSID, WEP key, and MAC address over the proper frequency and channel to the wireless server <b>130</b>. If these codes do not match what the wireless server <b>130</b> is expecting in a process <b>420</b>, the wireless server <b>130</b> denies login of the wireless device <b>140</b> in a process <b>430</b>. Additionally, an error log entry or alert may be generated (not shown). Otherwise, the wireless server <b>130</b> checks the particular wireless device <b>140</b> against the lease reservation times for when it should be accessing the gaming network <b>5</b>. If the lease reservation time does not match the present time in a process <b>440</b>, i.e., the wireless device is not pre-arranged to be on the gaming network at that time, the login is denied in the process <b>430</b>.

[0052] If the reservation time matches the present time in the process <b>440</b>, the wireless server <b>130</b> accepts the login and password information in a process <b>450</b>. If that information is correct, the login is allowed in a process <b>460</b>. Otherwise, the login is denied in the process <b>430</b>.

[0053] Once the wireless device <b>140</b> logs into the network in the process <b>460</b>, the flow <b>400</b> proceeds to a timeout loop process <b>470</b>. If the wireless device never times out, i.e., it is accepting some type of input from an operator during every timeout period, the flow <b>400</b> will remain in the loop process <b>470</b>, and the wireless device <b>140</b> will remain logged into the gaming network <b>5</b>. If however, the wireless device times out, then the wireless server <b>130</b> or other server <b>110</b> on the gaming network <b>5</b> automatically logs out the wireless device in a process <b>480</b>, and the flow <b>400</b> returns to the beginning. In this way, the gaming network <b>5</b> always maintains only those wireless devices that are authorized to be on the network, and that are continuously communicating with the gaming network <b>5</b>.

[0054] A standard procedure for providing employees with wireless devices <b>140</b> in a casino gaming network <b>5</b> could be as follows, as described with reference to FIGS. 1, 2, <b>5</b>, and <b>6</b>. In FIGS. 1 and 5, an exemplary application server <b>115</b>, termed a “redemption” server, is shown. The redemption server <b>115</b> could be an embodiment of the generic server <b>110</b> of FIG. 2. Although only a single server <b>110</b> is illustrated in FIG. 2, in practice any number of servers <b>110</b> could be implemented. The redemption server <b>115</b> can couple to the gaming network <b>5</b> (FIG. 1) as shown in FIG. 2. Specifically, the redemption server <b>115</b> can couple to the server cluster <b>56</b>, which provides access to the databases <b>100</b>. In one embodiment, the redemption server <b>115</b> only couples to the slot accounting database <b>90</b> and the ticket wizard database <b>94</b>.

[0055] The redemption server <b>115</b> primarily functions to redeem tickets or other redeemable rewards. Referring back to FIG. 5, included in the redemption server <b>115</b> are two NIC (Network Interface Cards) cards connected by a software bridge. One of the NIC cards, for example NIC <b>1</b> is coupled to and communicates with the gaming network <b>5</b>, including being able to access the data stored on databases <b>100</b>, for instance. The other NIC card, NIC <b>2</b>, communicates with the wireless communication portion of the network. The NIC <b>2</b> is coupled to a wireless access point <b>130</b>, which is also illustrated in FIGS. 1 and 2. A software bridge communicates requests and data from one network portion to the other.

[0056] Additionally included in the server <b>115</b> are two serial ports, port <b>1</b> and port <b>2</b>. Serial port <b>1</b> is coupled to a magnetic strip reader <b>157</b>, while serial port <b>2</b> is coupled to a docking station <b>159</b>. The docking station <b>159</b>, or cradle, can store one or more wireless devices <b>140</b>. When a wireless device <b>140</b> is docked in the docking station <b>159</b>, it can communicate to the server <b>115</b> through serial data communication through the serial data port <b>2</b>.

[0057] Generally, for security and privacy reasons, an employee is assigned an individual wireless device <b>140</b> that they would “check out” at the beginning of a shift, or at other times. In one example checkout procedure, an employee would swipe their employee identification card at the magnetic strip reader <b>157</b>. Of course, any identification procedure, such as bioinformatics, or a manual identification check by a manager could similarly be performed. Next the employee would remove the wireless device <b>140</b> from the docking station <b>159</b>. A program running on the wireless device requests the employee to enter a PIN number, such as their employee PIN number or other number. The server <b>115</b> would match the PIN number to the strip code read from the strip reader <b>157</b> in a database stored on the server <b>115</b> or elsewhere on the gaming network <b>5</b>. If the identification numbers match, the server <b>115</b> notes that the particular wireless device <b>140</b> is checked out to the employee.

[0058] In some embodiments, the server <b>115</b> can send an encryption key to the wireless device <b>140</b> through the serial port <b>2</b>, while the wireless devices is docked in the docking station <b>159</b>. In one embodiment, the encryption key is sent after the employee swipes their ID card in the swipe station <b>157</b>, and before the employee removes the wireless device <b>140</b> from the docking station <b>159</b>. The encryption keys are unique to each wireless device <b>140</b>, of course.

[0059]FIG. 6 illustrates a checkout screen <b>156</b> that can be shown in a window on the redemption server <b>115</b>. Data reflecting a status of each wireless device <b>140</b> (illustrated as station <b>130</b>, <b>132</b>, and <b>135</b>) is shown. Data such as whether a particular wireless device <b>140</b> is docked in the docking station <b>159</b>, whether the device is checked in or checked out, and whether the device is communicating with the wireless server <b>130</b> (FIG. 2) can be shown on the screen <b>156</b>. A wireless device <b>140</b> can be checked out using the process as described above, for instance. Once the PIN code is correctly entered on the wireless device <b>140</b>, the checkout screen <b>156</b> updates the window to show that the particular wireless device had been correctly checked out. Similarly, once the wireless device <b>140</b> begins communicating with the wireless server <b>130</b>, the checkout screen <b>156</b> reflects that the particular wireless device <b>140</b> is “online.” On the checkout screen <b>156</b>, a color indicator signifies which state each wireless device <b>140</b> is in. For instance, a color indicator could show ‘red’ if a wireless device <b>140</b> is offline, ‘yellow’ if a device is either online or checked out, and ‘green’ if the device is both online and checked out. Of course, other color schemes are possible.

[0060] One way to check-in a wireless device <b>140</b>, for example at the end of a shift, is for the employee to enter the wireless device back into the docking station <b>139</b>, and swipe their ID card in the strip reader <b>157</b>. The docking station <b>159</b> need not be the same station from which the wireless device <b>130</b> was originally checked out. Once finished, the checkout screen <b>156</b> would reflect the wireless device <b>140</b> as docked (because it was in the docking station <b>159</b>), offline (because it was not communicating with the wireless server <b>130</b>), and checked-in, because the check-in process had been completed.

[0061] Once a wireless device <b>140</b> is checked out, the device logs into the server <b>110</b>. When logging into the server <b>110</b> from the wireless device <b>140</b>, such as described above with reference to FIG. 4, a unit ID and network ID is associated within the gaming network <b>5</b> to the individual wireless device <b>140</b>. This could be stored on the server <b>110</b> (FIG. 2), or elsewhere on the gaming network <b>5</b>, for instance. After the employee has logged into the gaming network, a name, employee ID, session ID etc., could be linked to the previously stored data of the wireless device <b>140</b>.

[0062]FIG. 7 illustrates a sample log table that can be generated for events relating to a wireless device <b>140</b>. For instance, a timeline of a particular wireless device <b>140</b>, which in FIG. 7 is labeled station <b>132</b>, is illustrated. First, at 17:09:51, the station <b>132</b> is docked in the docking station <b>159</b> and then checked in at 17:09:57. The check-in was in response to the user (in this case “Ryan Schaeffer”) swiping his employee ID card at the magnetic strip reader <b>157</b>. At 17:10:07, the user “Kevin Niles” swiped his employee ID card at the magnetic strip reader <b>157</b>, indicating that he is going to check out the station <b>132</b>. At 17:10:09 the station <b>132</b> is removed from its cradle, and at 17:10:15, the check out is completed by Kevin Niles keying in his PIN code into the station <b>132</b>.

[0063] Because of its mobile ability, there are many ways to use embodiments of the invention in conjunction with a gaming network in a casino setting. One such way is to provide redemption of previously issued tickets. Tickets are printed forms of value, typically a cash representation, but they can also represent other forms of value, such as a coupon for goods or services, machine or bonus credits, or for other types of value.

[0064] Presently, to redeem a ticket a patron must present a valid ticket at a customer center, where there could be long lines. Using embodiments of the invention, a patron can redeem a ticket with a casino employee who has a portable ticket validator. The ticket validator could be an application or process operating on the wireless device <b>140</b>.

[0065] For instance, with reference to FIG. 8, a flow <b>800</b> begins at a process <b>810</b> by presenting a ticket to a casino employee, or cashier, who has a handheld or wireless device, such as the wireless device <b>140</b> described above. As mentioned above, the wireless device <b>140</b> operates a redemption process or program. In a process <b>820</b>, the cashier begins the redemption process. In some embodiments, the cashier takes an action on the wireless device <b>140</b>, such as by pressing a button or tapping a touch screen to initiate the ticket redemption.

[0066] Once the redemption process is begun, the employee enters the ticket number in a process <b>830</b>. For instance, the wireless device <b>140</b> may have or be connected to a bar code reader, magnetic strip reader, or some other reader that can read a code on the ticket to be redeemed. Additionally, the cashier may be able to type in code numbers directly on the wireless device <b>140</b> to enter the ticket number. Other methods for entering ticket information could also be used.

[0067] Process <b>840</b> determines if the ticket number is a valid ticket number to be redeemed, i.e., is a valid entry in a ticket database, and a message is sent to the wireless device. If the ticket number is not valid, the cashier notifies the ticket holder in a process <b>845</b>. If the ticket number is valid, an entry in a database holding the ticket information is changed from “not-redeemed” or an equivalent to “pending”, in a process <b>850</b>. This event may also be logged, as illustrated in the entry at 17:10:20 in the log file of FIG. 7.

[0068] One problem that could prevent the entered ticket number from being validated is if the bar code or other type of reader was not operating properly at the wireless device <b>140</b>. Of course, there is also the possibility that the ticket was made fraudulently, and therefore the ticket number cannot be validated by a corresponding database entry. Also, a player may unscrupulously try to photocopy, or otherwise made multiple copies of a ticket. Because, as described below, once a ticket has been redeemed it is marked as such in the gaming network <b>5</b>, presenting a ticket that has already been redeemed is also another reason that a ticket number would not be validated.

[0069] If the cashier has multiple tickets to redeem, he or she can enter another ticket number before finishing redeeming the first ticket. That way, if a patron has several tickets they wish redeemed, the ticket numbers can be entered singularly, and then redeemed at the same time. A process <b>860</b> determines if there are additional numbers to enter. If there are additional numbers, the flow <b>800</b> loops back to enter the additional numbers.

[0070] A process <b>870</b> determines if any tickets already in the process of being redeemed are to be cancelled. If so, data concerning the cancellation is recorded, such as the date and time. In some embodiments, the database entry for the ticket number is never changed back to “cashable” from “redemption pending” or from “redeemed.” Preventing records from ever being updated in this manner prevents tickets from being redeemed multiple times, if an unscrupulous employee who had access to the database were to change the database entry back to “cashable.”

[0071] When the cashier is ready to proceed, he or she identifies the particular tickets to be redeemed and makes an indication to complete the redemption, such as by pressing another button or clicking another icon. The flow <b>800</b> then exits the loop formed by the process <b>880</b>, and updates the ticket status as “redeemed” in the database in a process <b>885</b>. Other information, such as date and time of the redemption as well as the cashier performing the redemption is also recorded and stored. A sample log file entry is shown at time 17:10:35 of FIG. 7.

[0072] A receipt of the redemption is printed in the process <b>890</b>, and in a process <b>895</b>, the redemption is completed by paying the customer and giving them a receipt of the transaction. The handheld wireless device <b>140</b> could have a receipt printer built in, for instance. The receipt could include information such as the date, time, amount, location, wireless device identification, casino employee information, batch session, for example.

[0073] In some embodiments, the ticket redemption system described above works in parallel with hand ticket redemption. For instance, in the process <b>840</b> if the ticket number is not validated, but the cashier knows that it is a valid ticket, then the cashier could redeem the ticket as a “manual pay.” In such a situation, the cashier would maintain a copy of the manual pay receipt, as well as the redeemed ticket, and the transaction could be reconciled at the end of the shift with proper accounting.

[0074] Other scenarios in which such a system as described above could include redeeming jackpots, either with or without a ticket. In one embodiment, when a customer wins a jackpot, a jackpot ticket prints. A casino employee could go directly to the machine that had the jackpot and process the jackpot ticket as described above with reference redeeming a ticket in FIG. 8. If the amount of jackpot winnings were above the threshold where the government requires documentation, such documentation could be entered by the cashier at the machine itself, using the handheld wireless device. Then, in addition to printing a receipt for the transaction, as described in the process <b>890</b> of FIG. 8, the wireless device <b>140</b> could also print any necessary tax forms at the same time, and give the appropriate forms to the winning player.

[0075] To redeem a jackpot without the gaming device having had printed a ticket, the cashier having a wireless device <b>140</b> could go to the gaming device that won the jackpot. Then, the cashier could enter all of the necessary information, received directly from the player or from the gaming device itself. Once authorized by the gaming network <b>5</b> over the wireless device <b>140</b>, the cashier could pay the jackpot, give any necessary receipts, and retain appropriate accounting transaction receipts.

[0076] Totals for tickets processed, time spent logged into the network, etc., can be stored on the server <b>110</b> (FIG. 2) or elsewhere on the network, which could allow casino management to measure the performance of particular casino employees.

[0077] Although examples of machines and processes have been described herein, nothing prevents embodiments of this invention from working with other types of machines and processes. Implementation of the secured mobile data access is straightforward in light of the above description. As always, implementation details are left to the system designer. The specific circuits, functions, and procedures used to securely access data from the gaming network may be implemented in any way, with any components, without deviating from the spirit of the invention.

[0078] Thus, although particular embodiments for accessing data using mobile devices in a secure manner have been described, it is not intended that such specific references be considered as limitations upon the scope of this invention, but rather the scope is determined by the following claims and their equivalents.