US20070202955A1

US20070202955A1 - N-tier architecture for a casino management system and method

Info

Publication number: US20070202955A1
Application number: US11/742,214
Authority: US
Inventors: Gary Frerking; Phillip Blanton; Lattamore Osburn; Jeffrey Topham; Robert DelRossi; Kent Reisdorph
Original assignee: Individual
Current assignee: Individual
Priority date: 2003-09-08
Filing date: 2007-04-30
Publication date: 2007-08-30
Also published as: WO2005026909A3; AU2010202290A1; CA2538170A1; EP1667776A2; US20050054448A1; AU2004272182A1; US20110263337A1; WO2005026909A2; AU2004272182B2; EP1667776A4

Abstract

The present invention provides a system and method for gaming system configuration and control in a gaming environment. Certain embodiments include receiving a request for an application to execute at a gaming system, and routing the request to an appropriate application server to provide the application at the gaming system. The request may be routed based on a status of a plurality of application servers, for example. The method may also include verifying that the gaming system is authorized to execute the application. In an embodiment, the method includes distributing a request for data among a plurality of database servers. The method may further include updating an application at the gaming system prior to execution of the application. In an embodiment, the application is automatically updated prior to execution. The method may also include detecting alteration of an application prior to execution of the application.

Description

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 10/935,514, filed Sep. 7, 2004, which is related to, and claims priority from, U.S. Provisional Application No. 60/501,098, filed on Sep. 8, 2003, with inventors Gary Frerking, Phillip Blanton, Lattamore Osburn, Jeff Topham, Robert DelRossi, and Kent Reisdorph, and entitled “Three Tier Architecture for Casino Management System.”

BACKGROUND OF THE INVENTION

The present invention generally relates to a gaming system network. In particular, the present invention relates to a configuration and control system that allows one or more gaming systems to dynamically request applications and/or services from one or more servers.
Gaming machines, such as slot machines, fruit machines, or poker machines, have in recent years become one of the more popular, exciting, and sophisticated wagering activities available at casinos and other gambling locations. At the same time, gaming machines have also become a source of greater revenue for gaming establishments. Thus, competition between manufacturers of gaming machines has intensified as competitors vie for business from gaming establishments.
A gaming machine providing entertaining and enticing features for players would be highly desirable to attract both new and returning players to a gaming establishment. Additionally, a gaming machine that allows customization and dynamic modification by an operator would be highly desirable to provide new features to customers.
Current gaming machines are difficult to reconfigure and offer the same game to multiple users at multiple gaming establishments. Certain games may become old or unattractive to players and need updating or replacing. Changing a gaming machine to a different game or format involves time-consuming and difficult procedures by an operator. Thus, an improved system and method for updating or replacing games or other applications on a gaming machine or other gaming system would be highly desirable.
Additionally, configuration of a gaming machine by an operator raises concerns regarding security of data and integrity of a game on the gaming machine. That is, gaming establishments and legal authorities place high priority on the integrity of a game, such as a slot or poker game. Thus, there is a need for a configurable system that does not disturb sensitive game or prize data.
Current systems are often susceptible to reduced performance during peak periods of activity caused by overburdened servers providing applications to gaming machines or gaming workstations. Additionally, failures in current gaming environments often lead to play stoppage or other gaming problems. Casinos and other gaming establishments seek to avoid such delays and system failures to maintain player enjoyment and encourage repeated play and repeated visits. Thus, a system and method that improves gaming reliability and efficiency would be highly desirable.
Thus, there is a need for a configuration and control system and method for a gaming environment that allows one or more gaming systems to dynamically request applications and/or services from one or more servers.

BRIEF SUMMARY OF THE INVENTION

The present invention provides a system and method for a configurable gaming system. Certain embodiments provide an improved gaming network for providing applications to one or more gaming systems. The gaming network includes a plurality of application servers servicing requests from at least one gaming system and a load balancer distributing requests from the at least one gaming system among the plurality of application servers. The application servers may host a plurality of applications and/or web services for the gaming system(s).
In an embodiment, the application servers include a multi-tiered architecture. The multi-tiered architecture may include an application programming interface, at least one application, an operating system, and/or a data access interface layer, for example. The plurality of application servers may transmit information to the gaming system(s) that are subscribed to the plurality of application servers. In an embodiment, the application servers include different applications. In an embodiment, the application server(s) respond to a request if the gaming system(s) bear a valid license token for the requested application and/or service. The plurality of application servers may provide local live update of one or more applications on one or more of the plurality of application servers.
In an embodiment, the load balancer distributes the requests based on a status of the plurality of application servers. The system may further include a database server storing data for retrieval by the plurality of application servers. The load balancer may balance requests among a plurality of database servers. A request from a gaming system may include a request for a downloadable game, for example.
Certain embodiments provide an updatable gaming network including an application server servicing requests from at least one gaming system, where the application server includes a local live update application for updating an application on the application server. The local live update application may automatically update one or more applications on the application server. The local live update application may update an application on the application server at execution of the application.
The updatable gaming network may also include a stub/loader running at a gaming system, where stub/loader queries the local live update application to update an application to be executed at the gaming system. The stub/loader may detect alteration of an application prior to an execution of the application. The stub/loader may detect alteration of the application in conjunction with the local live update application. In an embodiment, the stub/loader verifies the application and stores an indication of verification of the application. The stub/loader may verify a license for use of the application at the gaming system.
In an embodiment, the gaming network also includes a load balancer distributing requests from the gaming system(s) among a plurality of application servers. The load balancer may balance requests among a plurality of database servers. The network may also include a database server storing data for retrieval by the application server. In an embodiment, the application includes a downloadable game, for example.
Certain embodiments provide a method for gaming system control in a gaming environment including receiving a request for an application to execute at a gaming system, and routing the request to an appropriate application server to provide the application at the gaming system. The request may be routed based on a status of a plurality of application servers, for example.
The method may also include verifying that the gaming system is authorized to execute the application. In an embodiment, the method includes distributing a request for data among a plurality of database servers. The method may further include updating an application at the gaming system prior to execution of the application. In an embodiment, the application is automatically updated prior to execution. The method may also include detecting alteration of an application prior to execution of the application.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of a casino management system in accordance with an embodiment of the present invention.
FIG. 2 is a block diagram of an embodiment of a portion of the casino management system of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 3 is a block diagram of an embodiment of a portion of the casino management system of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 4 is a block diagram of an embodiment of a portion of the casino management system of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 5 is a block diagram of an embodiment of a portion of the casino management system of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 6 is a block diagram of an embodiment of a portion of the casino management system of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 7 is a flow diagram for a method for satisfying execution requests in accordance with an embodiment of the present invention.

DESCRIPTION OF THE INVENTION

Referring to FIG. 1, a casino network system 11 includes a plurality of gaming machines 13, 15, and 17 interconnected across a network 19 to an applications server 21. Applications server 21 is connected to a database server 23 via a communication link 25 which is separate from network 19.
System 11 also includes a casino workstation 31 connected to network 19. In addition, one or more external systems 33, for example workstations from remote casinos, may be connected to network 19.
Gaming machines 13, 15, 17, workstation 31 and external systems 33 utilize the applications or web services of application server 21. In addition, gaming machines 13, 15, 17, workstation 31 and external systems 33 may communicate with one another via network 19 using standard protocols. Communication between a gaming machine and network 19 may occur with or without a smart communications interface, for example. However, database server 23 can only be accessed via communication link 25.
Communication link 25 is a high speed data link, and provides considerably faster communication than that across network 19. Link 25 may be formed from fiber optic cabling using lower layer protocols such as 100BASE-T, Gigabit Ethernet, and FDDI (fiber distributed data interface).
Referring to FIG. 2, each gaming machine 13, 15, 17 includes a smart communications interface (SCI) 101, 103, 105, respectively, which communicates with a respective game controller 107, 109, 111 using a particular protocol, for example, a Slot Accounting System (SAS) protocol, a Slot Data System (SDS) protocol, or other protocol. SCI 101 communicates directly onto network 19, whereas SCI's 103, 105 communicate through a data port unit (DPU) 113 and a poller 115, in the particular embodiment of FIG. 2. In another embodiment, a game controller may incorporate SCI functionality and communicate directly with network 19.
DPU 113 continually polls SCI's 103, 105 along lines 121, 123, respectively. DPU 113 may communicate with other gaming machines (not shown) via one or more lines 125. Each SCI 103, 105 collects data from its associated game controller and then buffers the data for transmission to DPU 113. Communication between SCIs 103, 105 and DPU 113 may use an RS485 serial communication standard, for example.
Poller 115 communicates with DPU 113 along line 114. Poller 115 may communicate with other DPUs (not shown) via one or more lines 116. Poller 115 communicates with an addressed DPU 113, sending information to DPU 113 as well as retrieving information buffered by DPU 113. Polling by poller 115 occurs in a serial protocol fashion. Poller 115 communicates with one DPU 113 at a time. Each DPU 113 listens for a polling message from poller 115. When poller 115 has obtained data from a DPU 113, poller 115 packages the data and places it onto network 19.
In an embodiment, SCI 101 is not polled. Instead SCI 101 places information directly onto network 19. SCI 101 retrieves data from game controller 107 and transmits said data across network 19 to a destination specified by SCI 101. For example, when the protocol message of controller 107 indicates a meter change, SCI 101 reads the meter data and determines the meter change. SCI 101 then packages the data for placement onto network 19.
When SCI 103 retrieves data from game controller 109, for example, bill data indicating that a $50.00 bill has been inserted into the gaming machine's bill accepter, the bill data is stored in the buffer memory of SCI 103. After transmission of the bill data to SCI 103, the data is erased from or allowed to be overwritten in the buffer memory of controller 109.
DPU 113 then polls SCI 103 and the bill data is sent to DPU 113. However, SCI 103 does not immediately delete the bill data from its buffer memory in response to sending the data. DPU 113 stores the received bill data in its buffer memory. Thereafter, DPU 113 sends a confirmation signal to SCI 103 indicating that DPU 113 has successfully retrieved and stored the bill data. In response to receiving the confirmation signal, SCI 103 erases the bill data from its buffer memory (or allows the memory space to be overwritten with new data). This procedure guarantees delivery of data.
Poller 115 then polls DPU 113 and the bill data is next sent to poller 115. However, the DPU 113 does not immediately delete the data from its buffer memory in response to sending the data to poller 115. Poller 115 stores the received bill data in buffer memory. Thereafter, Poller 115 sends a confirmation signal to DPU 113 indicating that poller 115 has successfully retrieved and stored the data. In response to receiving the confirmation signal, DPU 113 erases the data from its buffer memory (or allows the memory space to be overwritten with new data). Poller 115 packages the data and places it onto network 19. Alternatively, the confirmation signal which is sent to DPU 113 may be sent after the data is written to a local disk (not shown) or to database 45.
Referring again to FIG. 1, applications server 21 is designed to be run on a network platform and to service requests from gaming machines 13, 15, 17, as well as from workstation 31 or external systems 33. Casino network system 11 provides a network environment in which, for example, Microsoft Corporation's .NET™ framework is used. Applications server 21 hosts various applications or web services that may be accessed from network 19, through standard protocols, such as XML (extensible markup language), SOAP (simple object access protocol), WAP (wireless application protocol), HTTP (hypertext transport protocol), SMTP (simple mail transfer protocol), etc.
Applications server 21 has a multi-tiered architecture that includes a number of software layers including one or more applications 35, an application program interface (API) 37, an operating system (OpSys) 39, and a data access interface layer 47. Applications 35 provide a number of different services, including accounting services, player tracking services, progressive game services, browsing services, cashless play services, etc. Applications 35 may be written in various languages including, for example, C#. Operating system 39, for example, is a Windows® brand operating system which provides conventional functions.
Applications server 21 can push out, i.e., publish, information to various subscribers including but not limited to gaming machines 13, 15, 17, workstation 31 or external systems 33. Likewise, poller 115 (FIG. 2) could be a subscriber for receiving information from applications server 21.
For example, applications server 21 may learn that a jackpot event has occurred. Server 21 then publishes that information to workstation 31, or for example, to a jackpot server (not shown). Workstation 31 subscribes to this jackpot notification service by a communication request sent over network 19 to applications server 21. The request asks server 21 to notify the specific workstation 31 whenever a jackpot event occurs. Workstation 31 makes use of this notification, for example, by (1) notifying casino personnel that a jackpot has occurred, (2) determining whether a jackpot fill of the particular gaming machine 13 is required, etc.
As another example, gaming machine 13 may subscribe to a “bonus time” alert. Applications server 21 notifies gaming machines that have subscribed that a bonus period has started and that jackpots are to be paid out at twice the pay table, for example. This bonusing service for particular gaming machines can be subscribed to, for example, using casino workstation 31. Workstation 31 may communicate a request to applications server 21 to publish to specifically-identified gaming machines that a bonus period is to begin. The request may also provide additional information as to the amount of the bonus, the type of bonus, a bonus multiplier, etc. The request may also ask server 21 to publish the end of the bonus period as well. The applications server 21 may provide such a bonus service in real time with the bonus event, or merely provide a scheduled command for future bonus events.
In another example, applications server 21 may publish to certain gaming machines that a tournament has ended. Using the method taught in U.S. Pat. No. 6,039,648, assigned to Casino Data Systems, server 21 may communicate the end of a tournament play, so that appropriate pay tables and displays at the gaming machines may be activated.
API 37 includes a plurality of functions that can be called by other systems or devices connected to network 19. Such functions include conventional method or function calls as well as remote calls, e.g., proxy and SOAP/XML invocations. For example, API 37 may be called by slot machines 13, 15, 17. Also workstation 31 includes software applications 55 which when executed make calls to API 37. Likewise, applications on external systems 33 are able to use the functions of API 37 by presenting calls over network 19.
For example, API 37 processes a publication request. Meter data is received by applications server 21 which indicates that a jackpot has occurred. API 37 stores the meter data and then publishes the data to all subscribers.
In another example, external system 33 may be a news reporting server located at an internet e-mail address. The news reporting server may request notification of all jackpot events that exceed $1,000,000.00.
Referring again to FIG. 1, database server 23 is a relational database server, for example, a Microsoft® Structured Query Language (SQL) server, or an Oracle® database server, or the like. Database server 23 includes a database (DB) 45 and software 53 which is executed to handle requests for particular services. The request is made by applications server 21 and typically the service requested is to provide data to or retrieve data from database 45. Examples of services provided by database server 23 include (1) database storage of gaming activity, player account information, advertisements, ticketing, etc. and (2) database retrieval of player information, accounting data, application programs, etc.
Data access interface 47 is a database access technology, for example, Microsoft's® ADO.NET software. Data access interface layer 47 interfaces with database server 23 to perform various tasks, for example, retrieving data from database server 23 in cached form.
Interface 47 provides SQL queries to execute stored procedures in software 53. For example, a fill procedure is called to fill a data set with data from database 45. The data set serves as a container that stores the data from database 45 in a cached form. The data set is transferred to applications server 21, and the server 21 is then disconnected from database server 23.
Referring to FIG. 3, other application servers, for example applications server 49, may be added to network 19 to service additional gaming machines as more and more gaming machines are added to system 11. Applications server 49 may likewise service casino workstation 31 (FIG. 1), external systems 33 (FIG. 1) and gaming machines 13, 15, 17 (FIG. 1), for example.
Applications server 49 is connected to database server 23 via communication link 25. Connections to database server 23 are made and broken, as requested data is cached for use by the particular applications servers 21, 49 requesting the data.
As shown in FIG. 3, a load balancer 20 may be connected between applications servers 21, 49 and network 19. Load balancer 20 shares the workload between applications server 21 and applications server 49. When a service request is received by load balancer 20, balancer 20 distributes the request to either applications server 21 or 49 as appropriate. If applications server 21 is turned OFF, or incorrectly drops out of the system, load balancer 20 makes use of application server 49 instead. The other network components are blind to the number of applications servers which are providing services. Each applications server 21, 49 may contain identical applications 35 to enable load balancing. More than one load balancer 20 may provide additional system redundancy and scaling.
Alternatively, poller 115 (FIG. 1), for example, may identify the specific applications server (21 or 49) which is to service the poller's request.
API 37 of applications server 21 may respond to a request only if the request bears a valid license token. Thus, an unauthorized external system 33 (FIG. 1) would be prevented from seeking services from applications server 21 without such a token.
Referring to FIG. 4, a licensing server 61 may be connected to network 19 for supplying license tokens. Workstation 31 places a service request onto network 19, which is received by licensing server 61. Licensing server 61 responds back to workstation 31 providing a license token to workstation 31 for the particular service request. Workstation 31 attaches the license token to its request and places the request and token onto the network for receipt by applications server 21.
As an example, a casino may be licensed such that ten (10) jackpot fill client applications may receive services from applications server 21. When the eleventh jackpot fill client application begins requesting license tokens from server 61, that event is noticed by licensing server 61. One option for responding to this unlicensed situation is to provide the license token, but store this event in memory for subsequent retrieval by a service technician of the systems company. Upon retrieval, the technician will note that the casino needs to be licensed for the eleventh jackpot fill client application and then informs the casino management accordingly. Another option for server 61 responding to this unlicensed situation is not to provide the license token.
In an embodiment, licensing server 61 may be used to enable or disable features or behaviors according to jurisdictional regulatory requirements. As an example, application 55 on workstation 31 may request services related to harm minimization. Licensing server 61 may refuse a license token in jurisdictions that do not use harm minimization functionality. As another example, application 55 on workstation 31 may request services with jurisdiction-specific behavior, such as services related to ticket expiration. The license token provided by licensing server 61 may include jurisdiction-specific licensing information to enforce such behavioral requirements.
In addition, the owner of the casino system 11 may have a number of suppliers which are authorized (licensed) to gain access and obtain services from applications server 21. Those suppliers may be registered on license server 61 so that tokens will be dispensed to the listed supplier.
As will suggest itself, the functions of license server 61 may be carried out by an application 35 of applications server 21. In such an event, a separate server 61 is not utilized.
To provide security to system 11, encryption may be provided throughout the system, although encryption may be unnecessary for communication on link 25. In addition, licensing server 61 may include a hardware key 63, e.g., a USB “dongle plug”. Hardware key 63 is removably pluggable into licensing server 61. When the hardware key 63 is removed from server 61, server 61 may not be modified or changed. Alternatively, the hardware key 63 may contain licensing information such that if the key 63 is removed, server 61 may no longer be capable of issuing licenses to applications that are subsequently launched. Similarly, a hardware key 65 may be provided in workstation 31 and a hardware key 67 may be provided at an external system 33.
Referring to FIG. 5, applications server 21 accesses data primarily from database server 23. However, one or more other data providers 51 may be connected to communication link 25 in order to permit access by applications servers 21 (as well as server 49, shown in FIG. 3). A data provider 51 may be a second database server similar to server 23, or a remote casino network system, or a third party web service, or an external vendor system. For example, a casino employee at workstation 31 may request information as to the availability of a hotel room from a third party database server 51.
Where an additional database server 51 is added to system 11, for example to scale out the system, a load balancer, similar to balancer 20, may be disposed between applications server 21 and database servers 23, 51. In such a case, a cluster fault tolerant database solution may be used such that applications server 21 is blind as to the number of database servers it is accessing.
Referring to FIG. 6, casino workstation 31 includes a number of applications 55. From time to time, one of applications 55 may need to be updated by a new version of the software which forms the application 55. A Local-Live-Update software application (“LLU”) 601 on applications server 21 updates the software applications 55. This takes place by LLU 601 downloading a fresh copy of the files associated with application 55 to workstation 31. The files may include the executable image of application 55 itself as well as any supporting files used by application 55 including but not limited to executable modules, configuration files, stored procedures, data files, help files, image files and the like. The fresh application files are retrieved from database 45. Alternatively, instead of placing the fresh application files in database 45, the files may be stored in separate memory, i.e., an application repository comprised of a hierarchy of file system folders, for example, separate from database server 23.
An application 55 may be updated, for example, in response to workstation 31 making a specific request to applications server 21 to provide an update. Alternatively, LLU 601 may automatically provide the software update without request from workstation 31. The automatic update may occur at a scheduled time, e.g., midnight on the last day of each month. Also, LLU 601 may update an application 55 each time the application 55 is to be run. LLU 601 may provide similar application update services to any system or workstation accessible via network 19 or communication link 25 including, for example, gaming machines 13, 15, 17, and external systems 33 of FIG. 1.
In an embodiment, LLU 601 may facilitate web-based application deployment from a web server to a gaming system, such as workstation 31 and/or gaming machine 13, 15, 17 (FIG. 1). Web-based gaming applications, services, and/or customized interfaces may be downloaded to and/or executed on the gaming system via LLU 601.
In an embodiment, application deployment does not interfere with a dependent application's normal operation and proceeds in a pseudo platform-independent fashion. Additionally, LLU 601 may validate file(s) against known good files when an application is launched to determine if a file should be replaced and/or updated.
In an embodiment, LLU 601 provides password protection or other authentication method to prevent unauthorized access to client applications. The LLU 601 may validate each application file against a known good file when the application is launched to prevent people from editing an application's file and running the application in an unknown state. To prevent a bypassing of the system, the LLU 601 may create a mutual exclusion object (MUTEX) which allows multiple application threads to share a common resource but not simultaneously. Thus, each client checks the MUTEX upon initialization to determine if an application may be accessed.
In addition, an application 55 or any of its supporting files may be downloaded from applications server 21 because the particular application 55 on workstation 31 has been altered or because some tampering has occurred with the software. For example, when a particular application 55 is to be run on workstation 31, the alteration is detected, and the fresh application files are then downloaded.
The detection of the altered files associated with application 55 occurs at the time that the application 55 is to be launched. A stub/loader application 603 is run on workstation 31 prior to each launching of an application 55. Stub/loader application 603 controls the launching of all client applications 55 on workstation 31. When stub/loader 603 is started, it queries the web service LLU 601 of applications server 21 for details of the particular application 55 which is to be launched. Stub/loader 603: (1) examines the local directory structure of the to-be-launched application 55, (2) determines the presence of each of the files of the to-be-launched application 55, (3) installs or updates each file as needed, and (4) launches the executable of the to-be-launched application 55.
For example, stub/loader 603 queries LLU 601 for the directories of each of the application's files. The LLU 601 returns to stub/loader 603 a data structure containing the directory names and hierarchy. The stub/loader 603 then compares the information in the returned data structure with the existing directories of the to-be-launched application 55.
Stub/loader 603 also queries LLU 601 for the file names of each of the to-be-launched application's dependent files. Stub/loader 603 compares the returned file names with the names of the files in the to-be-launched application 55.
Stub/loader 603 also queries LLU 601 for a hash value, such as an MD5 Hash value, for a specific file. LLU 601 does not hash the file; rather, the file is hashed at the time the file is added to the system. The hash value is stored in database 45 or other suitable location such as hardware key 63 associated with licensing server 61 (FIG. 4). Stub/loader 603 compares the returned hash value with the hash value obtained by the stub/loader hashing the file in the to-be-launched application 55. Using an MD5 hash routine, for example, stub/loader 603 inspects each file in the to-be-launched application 55.
Stub/loader 603 may also query LLU 601 for other details and information of the to-be-launched application, such as data related to the date and time the file was created, data related to when the file was last modified, etc. Stub/loader 603 may use this information to inspect the to-be-launched application 55 and its associated files. Other information that may be used includes, for example, the size in bytes of the specified file.
After inspecting the to-be-launched application with the information and data supplied by LLU 601, stub/loader 603 determines whether to install a new file, or replace an outdated file. In response to its determination that a new file is necessary or desired, stub/loader 603 queries LLU 601 for a data structure containing the entire file. Stub/loader 603 creates a file, writes the returned data structure into the file and dumps the file to the disk of workstation 31.
Once stub/loader 603 has updated the to-be-launched application, stub/loader 603 queries LLU 601 for the file name of the to-be-launched application's executable file. Upon return of the executable file's name, stub/loader 603 launches the executable file.
The stub/loader application 603 stores a unique identifier into memory 605 to indicate that the application 55 has been approved. When application 55 is finally launched, the application 55 looks for the unique identifier in memory 605. If it is found, the identifier is erased from memory 605, and the application 55 is launched. If the unique identifier is not found in memory 605, indicating that the application 55 has not been approved, the application 55 is not launched.
In addition to verifying that application 55 has not been altered, the stub/loader application 603 may also verify that there is a license to permit use of the application 55. Stub/loader 603 requests this service from licensing server 61 (FIG. 4).
As shown in FIG. 6, a casino administrator station 607 is connected to network 19. Station 607 is used by authorized personnel to install new applications and updates to the system, and to remove old applications.
For example, station 607 includes an administrator application 609 which queries LLU 601 to add new files to database 45 or to update existing files in database 45. Administrator application 609 transmits new file data to LLU 601 with a request to install or update a specified file in a specified application. In addition, administrator application 609 may (1) add a new application record to the database 45, (2) update the details of a specified application, (3) remove a specified file from database 45 and (4) remove a specified application and all of its files from database 45. Also, administrator application 609 may obtain information from database 45, as for example, (1) a data structure containing the file name of each of a specified application's files, (2) a data structure containing the details of a specified application, (3) a data structure containing the name of each application stored in database 45, (4) a data structure containing all of the information on a specified file, and (5) the number of files which belong to a specified application.
It is anticipated that regulatory requirements may dictate special access control for sensitive portions of casino network system 11 such as station 607. Examples of special access control may include but are not limited to locating station 607 in a physically secure and monitored room, requiring biometric identification, or requiring more than one authorized employee to be present in order to access system 607. It is further anticipated that casino network system 11 may be adapted as necessary to meet such regulatory requirements.
For purposes of simplicity, only three gaming machines 13, 15, 17 are shown in FIG. 1. In actuality, a casino may contain hundreds, or even thousands, of gaming machines. In addition to gaming machines, a casino may include various non-gaming machine locations, such as craps and blackjack. Such locations may include an SCI, similar to SCI 101 or 103, which is connected to network 19.
Each gaming machine will require its own particular services from application server 21. For example, some but not all gaming machines will be included in a progressive game and thus require a progressive service from applications server 21. Typically, all gaming machines will require an accounting service from server 21 which will account for coins and bills inserted into the gaming machine as well as an accounting of coins cashed out of the gaming machine to the player.
Other services, such as player tracking and cashless play services, can be provided by server 21. A typical player account may be stored in database 45 for tracking of the player. The player accounts are updated by server 21 as player information is sent to server 21 from gaming machines 13, 15, 17, workstation 31 or an external system 33. For example, a restaurant acting as an external system 33 may request server 21 to add loyalty points to the player's account in database 45 based on the amount of money spent by the player at the restaurant. As another example, a player at gaming machine 13 may request applications server 21 to convert 1000 points of the points balance in the player's account to credits on the credit meter of gaming machine 13. As another example, applications server 21 may provide game programs or other parameters to a particular gaming machine.
More specifically, gaming machine 13 sends a service request to applications server 21. SCI 101 (FIG. 2) packages the request in a proper protocol and places the request onto network 19. Various switches and/or routers may be included in network 19 in order to route the service request to applications server 21. The request may include (1) data, (2) a message request, and (3) the network address of applications server 21. The message request seeks a particular service to be performed by execution of an application 35. Application 35 is run in connection with the data, if any, in the request. Application 35, if required, then generates a message back onto network 19 addressed to machine 13. SCI 101 (FIG. 2) receives the message and responds accordingly, as for example, adjusting the credit meter, generating a display of information to the player, etc.
Alternatively, SCI 101 or 103 may be connected to a hub for wireless communication of the service request to the network 19. The service request is received by the hub, repackaged and then broadcast to a receiving device that is connected to the network. The receiving device packages the service request and places the service request onto the network.
Thus, as described above, certain embodiments facilitate execution of requests from gaming systems in a gaming environment. FIG. 7 is a flow diagram for a method 700 for satisfying execution requests in accordance with an embodiment of the present invention. First, at step 710, a request workload is identified. That is, a number of requests for applications and/or data from one or more gaming systems in a gaming environment, such as a casino, is determined. Then, at step 720, a number of available servers is identified. For example, server workload and applications and/or data available on each server may be determined.
Next, at step 730, pending request(s) are routed to one or more servers able to handle the request(s). For example, data requests are routed to appropriate data servers, and application requests are routed to appropriate application servers. Optionally, at step 740, a license or license token, for example, may be authenticated to verify that a requesting system is authorized to access a server, application, and/or data. In an embodiment, at step 750, a server responding to a request may optionally determine if an update to a requested application and/or data is appropriate. For example, as described above, a server may verify application integrity and/or check for an updated version of the application and install a corrected/updated version of the application before execution of the application for the requesting gaming system. Then, at step 760, requests are fulfilled by appropriate server(s).
Thus, certain embodiments of the present invention provide a load balancing system for a gaming environment. Certain embodiments provide a system and method for local live update of applications in a gaming environment. Certain embodiments facilitate web-based deployment of applications and services independent of gaming system platform. Applications may be validated for proper license and/or file integrity prior to execution and/or download.
Certain embodiments simplify application update cycles and ensure that all client systems in a gaming environment may be using the same version of an application. Certain embodiments provide for easy application roll-back in the event of a bad application release or other error. Certain embodiments minimize support and maintenance through load sharing, redundancy, and updatability. Certain embodiments prevent an application from running in an unknown or erroneous state.
While the invention has been described with reference to one or more preferred embodiments, those skilled in the art will understand that changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular step, structure, or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of this application.

Claims

1. An improved gaming network for providing applications to one or more gaming systems, said gaming network comprising:

a plurality of application servers servicing application requests from at least one gaming system, wherein each of said plurality of application servers includes a multi-tiered architecture having a plurality of software layers; and

a load balancer automatically distributing application requests from said at least one gaming system among said plurality of application servers.

2. The gaming network of claim 1, wherein said plurality of application servers host a plurality of applications or web services for said at least one gaming system.

3. The gaming network of claim 1, wherein said multi-tiered architecture includes at least one of an application programming interface, at least one application, an operating system, and a data access interface layer.

4. The gaming network of claim 1, wherein said plurality of application servers transmit information to said at least one gaming system subscribed to said plurality of application servers.

5. The gaming network of claim 1, wherein application servers within said plurality of application servers include different applications.

6. The gaming network of claim 1, wherein said plurality of application servers respond to said request if said at least one gaming system bears a valid license token.

7. The gaming network of claim 1, wherein said plurality of application servers provide local live update of one or more applications on one or more of said plurality of application servers.

8. The gaming network of claim 1, wherein said load balancer distributes said requests based on a status of said plurality of application servers.

9. The gaming network of claim 1, further comprising a database server storing data for retrieval by said plurality of application servers.

10. The gaming network of claim 9, wherein said load balancer balances requests among a plurality of database servers.

11. The system of claim 1, wherein request comprises a request for a downloadable game.

12. An updatable gaming network, said gaming network comprising:

an application server servicing requests from at least one gaming system, said application server including a local live update application for automatically updating and validating an application on said application server, wherein said application server includes a multi-tiered architecture having a plurality of software layers.

13. The gaming network of claim 12, wherein said local live update application automatically updates one or more applications on said application server.

14. The gaming network of claim 12, wherein said local live update application updates an application on said application server at execution of said application.

15. The gaming network of claim 12, further comprising a stub/loader running at a gaming system, said stub/loader querying said local live update application to update an application to be executed at said gaming system.

16. The gaming network of claim 15, wherein said stub/loader detects alteration of an application prior to an execution of said application.

17. The gaming network of claim 16, wherein said stub/loader detects alteration of said application in conjunction with said local live update application.

18. The gaming network of claim 15, wherein said stub/loader verifies said application and stores an indication of verification of said application.

19. The gaming network of claim 15, wherein said stub/loader verifies a license for use of said application at said gaming system.

20. The gaming network of claim 12, further comprising a load balancer automatically distributing requests from said at least one gaming system among a plurality of application servers.

21. The gaming network of claim 20, wherein said load balancer balances requests among a plurality of database servers.

22. The gaming network of claim 12, further comprising a database server storing data for retrieval by said application server.

23. The gaming network of claim 12, wherein said application comprises a downloadable game.

24. A method for gaming system control in a gaming environment, said method comprising:

receiving a request for an application to execute at a gaming system; and

automatically routing said request to an appropriate multi-tiered application server to provide said application at said gaming system.

25. The method of claim 24, further comprising verifying that said gaming system is authorized to execute said application.

26. The method of claim 24, wherein said request is routed based on a status of a plurality of application servers.

27. The method of claim 24, further comprising distributing a request for data among a plurality of database servers.

28. The method of claim 24, further comprising updating an application at said gaming system prior to execution of said application.

29. The method of claim 28, wherein said updating step further comprises automatically updating said application.

30. The method of claim 24, further comprising detecting alteration of an application prior to execution of said application.