A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
This invention pertains generally to management systems and methods. More particularly, the present invention relates to a computerized method and system for downloading gaming software and configuring gaming machines.
Various networked gaming systems have been developed over the years beginning at least in the 1980's. With acceptance and utilization, users such as casino operators have found it desirable to increase the computer management of their facilities and expand features available on networked gaming systems. For instance, there are various areas in the management of casinos that is very labor intensive, such as reconfiguring gaming machines, changing games on the gaming machines, and performing cash transactions for customers.
In accordance with one or more aspects of the invention, a computerized download and configuration server-based system and method for use with game devices, systems, and methods is provided to enable users to monitor, control, and modify game devices and other related activities.
Further aspects, features and advantages of various embodiments of the invention will be apparent from the following detailed disclosure, taken in conjunction with the accompanying sheets of drawings.
Various embodiments are directed to a networked gaming system including one or more download and configuration servers, one or more game and player monitoring components, and at least one user control station enabling the monitoring and modification of networked gaming machines. The embodiments are illustrated and described herein, by way of example only, and not by way of limitation. Referring now to the drawings, and more particularly to
Scheduler Panel
Referring to
The Scheduler Panel is implemented as a GUI (graphical user interface) which may be integrated with a Control Panel, such as a Bally Technologies Control Panel, which may include a display, keyboard, and mouse for use by a casino operator. The Scheduler Panel is meant to provide an easy, intuitive way for operators to view, monitor status and manipulate the job assignments for download and configuration. Each assignment job is presented on the timeline showing when they start. There is a vertical lime-green bar indicating the current time as a reference. The entire content can be scrolled in any direction, however when scrolling vertically, the header showing the dates and hours will always remain visible.
The Toolbar:
Operating similarly to conventional toolbars, such as those provided in a Microsoft Windows Operating System, the toolbar has three filters and the cancel jobs button.
Zoom—Controls how much detail is shown on the timeline. Anticipated choices would be; Hour, Day and Week view.
Date Range—Allows user to specify how much time before and after the current time, data should be displayed. Anticipated choices would be; Today Only, Plus or Minus One Day, Plus or Minus One Week, Plus or Minus One Month. The user would use a report look at activity in the past outside of this range.
Job Status—Allow the user to only show jobs matching the status criteria. Anticipated choices would be; All, Active, Running, Pending
Cancel Jobs—The user will be able to select assignments that have not yet been completed, and cancel them. This is the same functionality we support in Release-1.
Assignment Jobs:
Each of the assignment jobs are color coded to indicate their status, such as green, amber, red. They use the same icon as in the assignment navigator to show their type. The title is derived from the assignment's name. The start time is indicated by the vertical black bar on the left ending in the diamond. If the assignment is an override, then the duration of the override is indicated by the horizontal line heading to the terminator with the second diamond.
Referring to
Hovering the mouse cursor over an assignment will bring up a tool tip with additional details. It is expected that there will be more detail in the tooltip than shown in this screen shot, such as progress of particular gaming machines associated with the assignment. In the event that some gaming machines have completed the assignment or some have not, this information may be obtained by clicking the assignment graphic bar to obtain a summary of the status of the EGMs affected.
Linked Assignment Jobs:
Two new (for R2) concepts are displayed in this screen shot using the curved blue lines, recurring schedules, and assignments that run multiple jobs based on templates. The first row of assignment jobs represent a recurring schedule. Each blue line links the previous job with the next occurrence. The Multi-Job Assignment shown at about 3:30 am on Monday represents an assignment that was set up to run two jobs in sequence. In this case it is showing two downloads, but it might be a download followed by a Config, or any combination of two or more jobs.
In R2, assignments will be changed so that they schedule one or more job templates describing what to do. In this way that actual instructions about what to Config or download can be shared at different times or for different EGMs without doing the clumsy copy step used in R1.
Double-Clicking or Opening a job will open a detail window with a view much like the existing R1 expandable grid, but focused only on the job in question. You'll be able to see the individual status for each EGM and in the case of configurations, for each option. Two or more of these can be opened at once to aid in comparing results.
Coding:
Some care must be taken when locating the jobs so as to keep the display compact while at the same time avoiding overlaps. It is anticipated that all recurring jobs scheduled during the time period of interest will be displayed near the top as shown so that they can be horizontally aligned. Then each job will be taken in start time order and displayed beginning at the top left corner. Each job is displayed one row below the ones already displayed until the start time has shifted forward far enough that it can be drawn in a new column without overwriting the previous ones. At this point, we reset the current row to the top and begin again.
Additional Features: Each job rectangle will also have one or more ‘progress’ indicators that will show how much of the job has completed. Because a ‘job’ could involve more than one EGM, the percentage shown could be the average percent complete for all EGMs, or the percent complete for the one that is least complete (in order to give operator some idea of how much longer it will take to complete the job), or some other useful measure of completion. The GUI will also provide some obvious indicator that a job has had some kind of error. One will be able to click on that indicator to see details of the error, such as identify one or more EGMs (gaming machines) that have been unable to receive or have encountered delays in receiving a download or reconfiguration or have refused the download or reconfiguration because of an incompatibility issue.
Referring to
Referring to
Download and configuration server system 201 enables the transmission of software files, packages or modules to one or more clients, such as gaming machines or tables, via, for example, a casino network using the Gaming Standard Association's (GSA's) Game to System (G2S) message protocols. The configuration portion of server system 201 enables the selecting of specific settings and options on one or more clients using GSA's G2S message protocols, such as to modify the Alpha operating system on conventionally available gaming machines or third party gaming machine or table operating systems. The respective subsystems of server system 201 connect to control station 203 which includes a common user interface application, such as a Control Panel (BCP) software application, so that a user can request data and issue commands for the processing of download and configuration operations throughout the network.
Download and configuration server system 201 provides for the following G2S download class features:
The G2S download class provides a standardized protocol to manage the downloaded content on all G2S compliant gaming machines or tables (EGMs) from all G2S compliant host systems.
The G2S download class enables installation of downloaded packages.
The G2S download class enables the removal of software (uninstall).
The G2S download class enables scheduling of installation and/or removal of software including enabling scheduling options that relate to a specific time, EGM state, or interaction with a host server or technician.
The G2S message class supports reading an inventory of downloaded packages and installed modules. This provides the capability to effectively manage the content on the EGM.
The G2S message class enables recording transaction logs for packages and scripts on a transaction database accessible through control station 203. This feature provides an audit capability or transaction tracer for determining how content came to be on an EGM.
The Download and configuration server system also provides the following G2S option configuration (optionConfig) class features which allows for the selection of various configuration options:
The optionConfig class provides a convenient and efficient mechanism to remotely configure EGMs.
The G2S optionConfig class provides for downloading options available from within an EGM.
Download and Configuration server system 201 implemented G2S classes (optionConfig, download, and scheduler) are also integrate-able through secondary displays, such as the iView, by incorporating, for example an iView transaction server. Thus, download, configuration, and configuration options may be implemented at selected EGMs 213 through their respective MPU (Main Processor Unit) or iViews. In the case of using the Bally iViews for network communications, a separate processor board is provided along with a display and user interfaces. Communication channels are connectable between the iViews and the MPU to enable the download, configuration, and configuration option processes. Some definitions of terms and components follow:
Databases—The databases return information based on the results of a stored procedure call. By example, the following databases, which are descriptively named, may be utilized: Core; Configuration; Download; Activity; and Schedule.
BCP (Control Panel)—As an example, the control panel application, such as a Control Panel application, can be a smart client implemented on control station 203 encapsulating all the functionality to support the command and control portions of the download and configuration features of a facility or facilities. Downloads and configuration options can be remotely scheduled or deployed immediately by a user through control station 203. Notifications, approvals, searches, and reports produced through server system 201 can be viewed by a user through a display or through hardcopy provided by a connected printer to control station 203.
Control station 203 can be utilized for remote downloading and configuration of games and game operating systems of connected EGMs 213. Also, control station 203 can be utilized to download content to or to configure the iView (or similar components) and second game displays or monitors (for instance, in cases in which an EGM 213 has two or more major displays) (which may also include an additional processor unit such as for example in the case of multiple games operable on a single EGM 213 on separate displays), as well as peripheral software for components in the games like bill validators and ticket printers.
Control station 203 can be utilized for the throttling of system resources based on the requested changes. For example if the user requests several high bandwidth consuming jobs be initiated concurrently, the control station 203 would advise the user that this would utilize more than allocated bandwidth and require changes to the proposed schedule. It is also contemplated that the control station could 203 could recommend changes to the schedule to ease the work requirement for the user.
Control station 203 can be utilized for the broad based change to gaming floors to support special events. For example on Halloween a specialized background or theme could be downloaded or configured on all capable games and devices for the duration of the event. This concept can be further extended to enabling specialized bonus games on other player centric activities relating to the special event or holiday. This allows a user of control station 203 to fully customize the property without the manual effort required with current systems and technologies.
Control station 203 can be utilized to fully view in a graphical fashion gaming floor configurations that have occurred in the past or are proposed for the future. This will allow the user of control station 203 to easily and quickly compare past gaming floor configurations to configurations proposed for the future in an easy to understand graphical manner. It is contemplated that these configurations be animated in a manner that realistically depicts the activity on the gaming floor over a period of time allowing the user of control station 203 to ‘watch’ the impact of the proposed changes.
Control station 203 can be utilized to view machine utilization information over time to determine where certain groups of players spend their time while at the property. For example if certain demographic groups are inclined to utilize machines configured at 0.25 per play and this control station 203 capability can illustrate the fact that during certain times of the day this machine configuration is completely utilized and that a large group of this demographic is scheduled to visit the property, the casino manager could opt to enable more of this type of game so players are not waiting for an opportunity to play. It is contemplated that this feature is presented in an animated fashion such that the user of control station 203 may select a date range and analyze in real time game usage by time of day and by player demographic. This features also requires control station 203 have access to and have the capability to process information from the player marketing system or have access to the data stream feeding the player marketing system.
Control station 203 has the capability to allow groups of gaming devices be identified and operated upon via a number of query options. This will aid the user in quickly and effectively finding the machines to apply changes to. It is contemplated that advanced selection criteria such as performance over the last 30 days be considered as a query parameter. The control station 203 can provide the capability to utilize a graphical representation of the gaming floor. This will allow selected groups of games to graphically represented on this floor map as well as in a list form.
Control station 203 can utilize historical slot game performance data to provide guidance for new floor configuration options. The historical data may be accessed in the download system data stores or from an external business intelligence system. It is contemplated that the control station 203 may be programmed to allow for automated floor configuration changes based on the historical performance data. This capability may be applied automatically or via an interface requiring only approval from the user prior to applying the changes.
Database Web Services—These are world-wide Web (Web) services that are conventionally available to be re-used by other user interfaces and service applications connected to slot management system 101. In other words, this is a secure closed system network using web services connected on demand with the slot management system.
Handlers—These are the logic libraries that are responsible for executing the business logic of the system.
Network Components—The following list of network components, or portions thereof, may be implemented and/or required by server system 201: Certificate Server; DNS; DHCP, Application Firewalls, Hardware Firewalls, Network Load Balancers
Third Party Software Applications—the following list of 3rd party applications my be utilized or required by the server system 201: IIS, MSMQ, SQL Server, SQL Server Reporting Services, Active Directory, Microsoft Windows 2003 Server.
G2S Engine—This service will receive G2S messages directly from EGMs 213 and dispatch them to the respective subsystem of server system 201 based on the message component type.
EGMs—Electronic Gaming Machine, which may include tables with processor and/or display components.
iView—For example, a conventional apparatus providing a player user interface and display at EGMs 213 connected to the network including the player tracking server and enabling a player to request and receive information, to receive award notifications, to transfer credits, and to conduct such activities through the apparatus as is enabled on slot management system 110. One usage of an iVue-type apparatus may be to display marketing and player tracking information and various shows on the occurrence of an award or win by a player. Such apparatuses may also be utilized as vessels for gaming, such as with server-based games or even independent games stored on their respective processor boards. Thus, separate games may be implemented through the iView-type device, apart from the main game of EGM 213 controlled by the MPU. In turn, the content of the iView may be separately modified as through downloads or configurations or configuration options. Control station 203 is able to retrieve from the database and view all login attempts to the server both successful and failed. A user may be locked out of access to the control panel application at control station 203 after too many failed login attempts. The recorded transaction log may include the login ID, data, time of login and duration.
The Web services may support functionality between control station 203 and database block 207. The Web services may also support unsolicited messages between the G2S handlers and control station 203.
Server system 201 may maintain a record or transaction log of login attempts to the server both successful and failed. The log may include the login ID, data, time of login and duration. Server system 201 may also maintain a transaction record or log of all events and activity occurring on server system 201. The log may include a record of which login session in which the event occurred.
Server system 201 may also maintain a log of communication events with any EGM 213. Server system 201 may also maintain the status of each EGM 213 including: Game history data; Download status (available, requested, downloading, applied, rejected); Package information (available for install, requested, being downloaded, downloaded, installed); Hardware information; Software Module Information; and/or Error conditions.
Server system 201 may dynamically build packages to be downloaded based on EGM 213 inventory and available updates, fixes and new data for EGMs 213. Server system 201 may verify requests from EGM 213 including whether or not EGM 213 is valid and that it is in a state to make the request. All requests will be logged and contain EGM 213's identification number, time and date, specific request, and EGM status. Server system 201 may communicate with Software Distribution Point servers (SDDP) to maintain a list of packages that are available for supported EGMs 213. Server system 201 may supply the location of the SDDP when instructing EGM 213 to add a package. Server system 201 may verify that all required hardware and software for a package to be sent to an EGM exists before instructing EGM 213 to retrieve the package. Server system 201 may support multiple EGMs 213 in multiple sites and/or facilities and EGMs 213 produced by multiple manufacturers. Server system 201 may verify, using the information in the package header and the information stored about selected of EGM 213, that a software package can be installed on a selected EGM 213 before instructing EGM 213 to add a package. Server system 201 may be able to track which packages are installed on any given EGM 213 and verify the data by requesting a selected EGM 213 to send package install information. Server system 201 may report bad images and errors and log them when failed package installation information is received from an EGM 213. Server system 201 and SDDP may be used to control all network pacing, bandwidth, error recovery, and monitoring. Server system 201 may be utilized for maintaining the location of all SDDP and the packages available on each.
Software Download Distribution Point (SDDP) server may be utilized to maintain all downloaded software packages in a secure library with the required number of secure backups defined by a jurisdiction. The SDDP server may be used to restrict access to the library that stores all software download packages to only authorized personnel. The access may limit access, such as to only allow write access to those authorized to add, delete, and update packages and read access for all others authorized to access the library. The SDDP server may provide secure software level firewalls to restrict access to everything saved on the server. The SDDP server may maintain a log of login attempts to the server both successful and failed. The log may include the login ID of a user, data, time of login and duration. The SDDP server may maintain a log of all events and activity occurring on server system 201. The log may include which login session in which an event occurred.
Software packages added to the software library may be verified from the package data using an MD5 or SHA1 hashing algorithm to validate the data or some other verification tool. The verification string may be added to a package header and used to re-verify the package when it is downloaded to the EGM 213.
All verification failures and related errors may be logged and the log entry may contain the date and time, the ID of the person running the process at the time, and the specific type of error that occurred. They may also be displayed on the correct display area.
The SDDP server may be utilized to provide selected EGMs 213 with the communications port location and IP address used for sending software package data to the EGM 213. All data within a download package may be compressed using conventional compression techniques and transmitted in compressed format. On receipt, EGM 213 may decompress the downloaded software package.
Referring to
The Download and Config Software utilized together with the apparatuses as shown in the figures may be used to enable a casino Slot Operations staff to schedule and change a game(s) on the casino floor from a keyboard.
Using the Control Panel (BCP) interface, the staff may be able to schedule, configure, download and activate changes to games on the floor, without touching an EGM on the floor. Download and Config software application may be loaded on control station 203 to enable the sending of information over the casino network using G2S & HTTPS standardized message protocols that manage the downloaded content. From control station 203, a user, such as casino staff, can change cabinet or game options, or games in EGMs. There are numerous selections that the staff can schedule to configure or make a minor change. Some examples of the types of software that may be downloaded or options which may be re-configured are:
In order to implement the download and configuration features, one approach is to install slot management system 101 at a facility, such as the Bally_Live slot management system. The implementation of the download and configuration features further contemplates the implementation of server hardware and related equipment as shown in the figures, and particularly
An example process for using the Download and Config server network is as follows: a casino operator decides to change game themes on the Alpha V20D-20 EGMs. The software game themes are located on the SDDP Server. The Download management tools are located on the Application/Database Server System. One or more servers separate from the SDDP Server contain the game theme software, such as for security or redundancy purposes. The Alpha EGMs are identified on the casino floor using the BCP. A Download management tool, such as the BCP scheduler may be used through a menu to identify: the date and time to download the game packages; the game packages to send to the specific EGMs; the date and time to automatically activate the games on the EGMs after the download. At the selected date and time, the EGM may open communication with the Download Database. The EGM request software from the SDDP server. The SDDP server downloads the specified game information to the EGM using a secure transmission protocol such as HTTPS. The download to the EGM may occur in the background operation of the Alpha OS, so that gameplay is not interfered with. The EGM may de-activate game operation a pre-determined amount of time subsequent to the last play on the EGM, such as five minutes, and issue a message on one of its display panels that it is temporarily offline, at which point the EGM can initiate installation of the downloaded software. A record of the transmissions and corresponding activity of the EGM is relayed to a retrievable storage on the network, such that a privileged user may operate the BCP to run the reports identifying the old and new games, date changed, and by whom. User privileges may be restricted as discussed previously to provide additional levels of security and flexibility within the system and for the casino operator or users of slot management system 101 and download and configuration server network 201.
Example Download and Config components that are shown in
In an example embodiment, the following apparatuses and software are incorporated:
Discovery Method to Dynamically Find Gaming Networked Components Using DHCP, DNS, LDAP, and Active Directory to Locate Services within the Gaming Network that are Available in a Casino.
Referring to
The following process mechanism takes advantage of the network infrastructure available on a Windows network, such as the Bally One slot management system:
Step 1. The application finds the DNS server referred to by the network setup. This setup may have been manual or by DHCP.
Step 2. The application then does a look-up of a specific name of an LDAP server in a scope guaranteed to be at all casinos if the service is available.
Step 3. From there, the application queries the LDAP server for the Assigned name of the resource (database entry, or web service entry).
Step 4. The Application then uses that information to connect either to the database or the web service. The entry may include the user name and password to use to connect to the database or may specify that the user is to use their own credentials.
There may be any number of DNS or LDAP servers to handle this task. Also, the data returned back from the LDAP or DNS servers may be different from results returned to other machines based off of information obtained from the network card connecting to the network. For example, the north-east portion of the casino may force all requests to a different web service than the South-east portion. The LDAP server may be implemented by a third party vendor (such as Microsoft) or by the system vendor (such as Bally Technologies). The same is true of the DNS server. The results may also be returned by the version of the software the client is able to support. A different server can be returned for version 1.0 of a protocol and version 2.0 of the same protocol.
Benefits and features of the discovery process and mechanism may include one or more of the following:
Benefit 1.
Currently every server and workstation has to be configured manually thus causing the casino significant work and the potential for mis-configuration that may cause serious side effects including system downtime.
Benefit 2.
This discovery method allows for dynamic configuration based on server availability and load. The system can report into the LDAP server the performance information about load and server availability. The LDAP server can then make decisions based on this information to route new connections to servers better able to handle the load.
Benefit 3.
Allows for upgrading a small part of the casino to a new version of code and not have everyone go to it until the code has proven itself in a live environment. This provides a staged deployment capability that does not require the casino to be down during an upgrade process. It also allows for field trial capability without risking the entire casino operation.
Benefit 4.
Resources can be spread throughout the casino. Not all servers need to be in the server room. There can be several closets on the floor with servers running. The servers can handle a section of the floor. This prevents a disaster in the computer room from downing the entire casino.
Benefit 5.
If a closet handling a section of the floor is no longer available, a different closet can then take over.
System and Method for One-Way Delivery of Notifications from Server-to-Clients Using a Modified UDP Multicast.
Architecture:
Use of the Notification System begins with a Client application (in this scenario the BCP) sending a registration message to the DCM with its IP address in the message. It could also include what types of notifications it wants to receive; see
Example Benefits and Aspects of the modified UDP Broadcast process and mechanism may include:
EGM Group Collection Management
The ability to associate an Electronic Gaming Machine (EGM) to a group of EGMs. An EGM can belong to any number of groups, and an EGM group can be assigned to another EGM group allowing for ‘nested’ collections.
Within the Download and Configuration Management (DCM) Bally Control Panel (BCP), a user can associate an EGM with an EGM Collection Group. An EGM group is simply a collection of EGMs. An EGM group can contain other EGM groups. I.e. nested grouping. An EGM can belong to 0 or more EGM groups.
The user of the Bally Control Panel will be able to:
Create/Modify/Remove an EGM group.
Add/Remove EGMs and EGM collections of an EGM group.
Make a copy of an existing EGM group.
Associating a group of EGMs to a collection allows for the system to accomplish dynamic configuration assignments that can be applied concurrently, along with dynamic download assignments that can be scheduled independently of the configuration assignments.
For example, a new O/S version download can be scheduled to occur during off-peak hours for Sunday night. A configuration assignment can be scheduled to decrease the payout percentage of the bar top machines during happy hour each day of the week, and the Stars and Stripes configuration can have other configuration changes when a scheduled upcoming tournament is to be sponsored.
All of these assignments can be scheduled and allows for the casino manager to look at his casino from different perspectives and manage the casino effectively.
Referring to
By selectively grouping, a casino operator can download software specific to gaming machines having a particular operating system (O/S), location on the floor, or game theme, to name a few examples.
Method and System for Providing Download and Configuration Job Progress Tracking and Display Via Host User Interface.
The introduction of download and configuration capabilities in the gaming environment creates considerable operational challenges. Download will likely require a considerable volume of gaming content to be transferred over the network. Many casinos are open 24/7 which will require download to take place without disrupting normal gaming activities. In order to not tax the network resources it may be necessary to limit the download bandwidth at the expense of download time. It will not be unusual for some download jobs to take 30 minutes or more. Thus, a way of easily monitoring download progress would be invaluable to casino operators.
A Download system can be centralized and “push” the data down to the games. In this case, the content server knows how much has been downloaded at any time. However, in a “pull” system, where the games are told where to go for the data and the games are taking (‘pulling’) the data from the content server, the server generally does not know how much data a given game has downloaded. Thus, a way is needed for the games to keep the Download management system apprised of how far along they are in the download process.
Background:
Until recently, the gaming industry has been a collection of proprietary systems and communication protocols. In many cases, a casino had to buy the entire system (games, controllers and backend system) from one company. Most casinos would prefer to use a mix of manufacturers games on the gaming floor, and then pick the best backend system that suits their needs. Until recently, this was not a realistic expectation.
A few years ago, several gaming entities came together and created the Gaming Standards Association (GSA) in order to define standardized protocols by which games, gaming controllers and backend systems could communicate. This allows interoperability of different manufacturers equipment, as well as giving the casinos the freedom to choose whatever manufacturers they want for the various components of a gaming system. One of the GSA protocols is the Game-to-System (G2S) protocol, and is meant to define the messages between a gaming machine and a backend system. This protocol does include messages for handling software download and configuration of the gaming machines.
Diagram Explanation:
The Bally Download and Configuration system is using standard G2S messages to convey progress information from the EGMs to the G2S Host (see diagram). In this case, it uses the G2S ‘packageStatus’ message. The G2S Host then puts that message into a message queue. The Download and Configuration Manager (DCM) application reads the message from the message queue and processes it. So far in this communication chain, message structure and protocol is standard G2S, and uses standard Microsoft Message Queues (MSMQs).
The vast majority of communication between a Bally Control Panel (BCP) client (the GUI) and the DCM server is via a standard communication protocol, SOAP, which is a true client-server architecture where the server never initiates any communication. Therefore, if there is any information (like job progress info) that needs to be asynchronously sent to the BCP, the normal communication channel cannot be used. An inefficient method would have the BCP (a client) poll (ask) the DCM for any possible notification messages. Instead, a mechanism was devised that would allow for one-way messages from the server (DCM) to the clients (BCPs); this is the UDP Broadcast Processor (to be disclosed in a subsequent Initial Disclosure).
Solution:
Referring to
This feature provides the ability to view the percentage download progress in the Host UI (part of BCP) using a messaging scheme which overcomes the BCP-initiated protocol used for all other messaging between BCP and DCM (Client-Server). The Host UI displays the progress bar based on the percentage download communicated from the gaming device (downloading entity) to the DCM engine. All downloading gaming devices will also send a ‘download complete’ message. This information can also be used by the DCM and BCP to estimate future download time and bandwidth requirements.
A Method for Validating a Download or Configuration Assignment for an EGM or EGM Collection.
Using the Bally Control Panel (BCP) in a Bally Floor System (BFS) environment, a casino manager can schedule downloads or configuration settings to occur. Any number of assignments can be applied to an EGM. With this flexibility comes a potential for sending conflicting or contradictory assignments.
An example would be that a bank of EGMs may be scheduled to receive a new game theme to add to the list of games a player can choose from. It may, however, require that the EGMs also contain a specific version of the O/S in order to support the new game theme. In this case, the tool would validate the download assignment of the new game theme, displaying that the game theme requires an O/S download that has not yet been scheduled.
This feature would obviously save the casino manager the headache of downloading code that would not be able to either install and/or execute correctly once installed.
This feature helps the user in planning better in configuring the floor.
Basically, there two types of validations that are used, one for validating a download assignment and one for validating a configuration assignment.
Download Assignment Validation:
This feature validates a download assignment and calculates the chances of its success based on the current information. It verifies if the assignment would apply the changes successfully on the EGM at its execution time and inform the user about any reasons that would cause it to fail. The basic validation checks that would be performed are:
Configuration Assignment Validation:
This feature validates a configuration assignment and calculates the chances of its success based on the current information. It verifies if the assignment would apply the changes successfully on the EGM at its execution time and inform the user about any reasons that would cause it to fail. The basic validation checks that would be performed are:
With (in some cases), thousands of possible configuration options that can be modified and the way a casino manager may want to “manage” their floor, the potential for conflicting configurations to occur frequently. This feature can help the manager in planning floor configurations.
Profile Driven Device Configuration
The goal is affect configuration or content download changes on a device based on a pre-defined profile which may be time based.
Gaming machine configuration changes such as denomination, reel speed, game volume, bets per line and number of available lines and content download changes can be pre-defined on a time based schedule, called a profile. A slot manager or other authorized personnel can use a tool to select the gaming machine that is to be changed, select the configuration or content that should be changed, select the values for the configuration or the game theme to be changed, and the time and date profile for the change(s) and then implement that profile driven set of changes. A profile driven configuration change instruction set is comprised of a schedule and a set of machines assigned to that schedule.
For example, a slot manager may want to eliminate all penny and nickel denominations from games every Friday night at 5 pm and then add back the nickel denominations on Saturday morning at 9 am but continue to eliminate all penny denominations. The slot manager would create a time based profile that would affect that change precisely at 5 pm on every Friday and at 9 am on Saturday. This profile could be created and implemented in advance for one or more machines and then set to run.
Technical Challenges
There are several technical and operational challenges that must be overcome to be able to create a configuration change profile that will be executed in the future on a wide variety of device types.
First, you cannot set absolute values for configuration changes when each device doesn't handle or implement the configuration change in the same way. If you want to set the reel spin speed on a gaming device to low; that setting value may be completely different on a Bally machine compared to an IGT machine. A Bally machine may have a scale of 1-5 for reel speed with 1 being slow and 5 being fast compared to an IGT machine that has a scale of 1-10 with 1 being slow and 10 being fast. Instructing the system to change the reel speed to high across all machines on the floor would require a different configuration value for reel speed on a Bally machine and an IGT machine. So, there has to be a way to instruct the system to change the reel speed to low and then be able to translate that to the specific value for the machine that is being changed. Most of the profile driven changes will instruct the machine to change to a low, medium or high setting instead of an absolute setting like change to volume 3.
Second, because there are different machines from different manufacturers on the floor, each machine uses a different scale or value range for some configurable options and the type of machine or its settings may have changed between the time the profile was created and the change occurs, the machine has to be interrogated for its current configuration at the time of the configuration change. This is the only way to be able to know how to make the change in the correct way; by knowing exactly how the machine is configured at the time of the change. The system must be able to provide a dynamic machine “inventory” at the time that a configuration change is to occur.
Third, there must be some sort of lookup or translation table for each game theme/manufacturer that correlates the low, medium and high settings to a specific setting value. To use the reel speed example again, the profile will show a value of low, medium or high over a time period for one or more gaming devices. These gaming devices may be a combination of different manufacturers that have a different setting value for medium reel speed. When the system implements a profile driven change, it first must ask the machines what they are; “what manufacturer and game theme are you?” Once the system knows what kind of machine it is, it will refer to a lookup table (all in real-time) and lookup what reel speed value it needs to send to that machine to make it change to medium reel speed. It's possible that each machine may be different. Another scenario is that each Friday night, the reel speed is to be set to high. On one Friday night, the machine is a Bally Winning Times game but during the next week someone has gone and changed the chips in the machine and made it a Bally Fixin' 2 Win game with a different reel speed range. This can be handled with this interrogation method because the system will know what is on the machine when the change is to be done by getting its inventory.
Market
This product will work on a variety of games in the casino or arcade market for class 2 or 3, lottery or central determination.
What is Required to do Profile Driven Device Configurations from a Command and Control System?
Time Based Configuration Change Profile
Referring to
The horizontal axis shows time, in this case a week. The time duration can be any duration that you want. The vertical axis shows the value that is to be set on the machine relative to time. Note how we are not instructing the volume to be set to a specific number like 3 but instead to a low, medium or high level.
Note that the volume level indicators on the vertical axis are labeled as low, medium and high and not specific values such as volume 3. This is done because each gaming machine or game theme can have a different definition of low volume. For example, a Bally machine has a volume scale of 0-10. An IGT machine might have a volume scale of 0-100 and the command and control system would need to know what to set the volume to when instructed to set the volume to low based on what is on the machine when the change is due to occur.
Referring to
The different configurations to be set could be:
Low, Medium and High Configurations
Absolute Configurations
In the case of an absolute configuration like denomination, there is no need for a low, medium or high level. The profile can instruct the machine to convert to a specific denomination.
What is needed is a lookup table for each machine on the system that is accessible by the command and control system when a profile driven change instruction set is scheduled to be made.
For volume, this is what a lookup table would look like. As you can see, when a volume change is requested by the profile driven schedule, the command and control system gets the machine characteristics and can use the lookup table to determine what game volume setting value to use when it wants to switch to low game volume.
Slot managers and manufacturers will need to create these tables one time on installation of the command and control system and then only make changes if there are new settings that they want.
For instance, the system would attempt to change the game volume on floor machines to high on Friday at noon, if the user adjusts the settings. If the change was to be made on a WMS, Bluebird Stepper that was running the Top Gun game theme, then the game volume level setting would be 45 as may be noted in the table above.
There are hundreds of cabinets on the floor and each may need to be changed so the command and control system would need to know what manufacturer, cabinet type, game theme and volume level to set to and then use the lookup table to make the correct change.
Another example of a profile driven change would be minimum bet. In this case, the operator would want to control the minimum bet that a customer could make on each machine. One way to control minimum bet on a slot titles is by setting the number of lines on the game and the minimum coins to be bet per line.
Here is an example of a lookup table for minimum bet. In this case, only Bally and WMS are show for one of each of their games but other manufacturers would be added as they are connected to the command and control system.
Real-Time Inventory and Interrogation
The command and control system uses G2S to communicate with the gaming devices and has the capability to perform a complete interrogation of the gaming device and get all settings including game theme, current denominations, current game volume, current game reel speed, current bet options and line options, current host settings and almost all other machine settable parameters. The system can request and get these values in real-time.
XML Data Structure—Use of XML For Messages
The basic idea is to let the user, or an external system, specify a profile to modify any of the available options, or meta options like Minimum Bet. The bet profile input file which you currently use to set bet amount can easily be formatted to specify a series of times and a list of options and values for any options as shown below:
When the system executes the profile, it uses the table you've outlined to resolve what each item means on a per EGM basis. The table would be made more generic so that it had columns for OptionName, OptionValue, G2S_DeviceClass, G2S_OptionGroup, G2S_OptionItem, and G2SOptionValue.
When the system creates a job, it will look up the OptionItem Name in the table for the given EGM's theme, paytable, and denom. If one or more matching rows exists we can map it to the actual G2S options and send the appropriate command. (for example MinBetAmount becomes Bal_MinBetPerLine and Bal_MinNumberOfLines) If no rows match, we can still send the command if it happens to match a actual G2SOption for that game. (Like BAL_GameSpeed). If there is still no match, it would be logged as an error.
In addition, wildcards in the Table may be supported so we can reduce the number of rows. For instance, if we would do the same thing for every pay table, then instead of have rows for each payTable, we would just put a * in that column.
A manufacture column may be added to the Table. In this way we get support for meta options that we can display in the UI and allow customers to make generic assignments that work across disparate manufacturers. These meta options could be displayed in the standard configuration wizards as well as the special profile wizard.
The system would use the XML data in the format above to build a visual representation of the profile curve as shown in figures above.
Referring to
Referring to
Meta-Options
Electronic slot machines combine hardware and software to deliver gaming applications to customers. The software is comprised of operating system and game software both of which have configurable parameters or options. Each configurable option has a variable name and one or more valid values that can be set; only valid values can be set in the software. The Table below illustrates some examples of configurable options, valid option values and the option variable name:
The available configurable options, the valid option values and the option variable names are a unique set to each electronic slot machine manufacturer's operating system and game software. Further, each of the games from a single manufacturer can have a completely different configurable option list with unique option values and option variable names so there is a unique set of this data for each manufacturer and game combination.
The operation of the electronic slot machine can be changed by making changes to the configurable options within the permitted or valid configurable option values. For example, the game volume can be changed to low by changing the G_Vol option variable to 1 or changed to high by changing the G_Vol option variable to 9. As you can see, the game volume is controlled by a single configurable option just as the Bill Stacker Limit or Bet Per Line is. Changing those individual configurable options to one of the valid option values would have an affect on the electronic slot machine.
However, there are several issues that need to be overcome to efficiently change configurations on a gaming floor.
First, for many slot floor changes, casino slot directors does not think in terms of absolute values of configuration options; they think in terms of low, medium and high. As an example, they think of game volume as low, medium and high. On a busy Friday night, they want the volume on all electronic gaming machines to be set to high but after midnight they want to have the game volume set to low. The slot floor director wants to set options like game volume, minimum bet, game speed and other game settings to an subjective value and does not think in terms of the absolute valid option values. There needs to be a way to direct the entire floor to switch to high volume, for example.
Second, the slot floor director wants to make changes to the floor as a whole, not as individual gaming machines. The slot floor director wants to set the entire floor game volume to high with one command. The problem is that the slot floor is composed of a wide variety of electronic gaming machines from different manufacturers each with multiple game themes on the electronic gaming machines. Each of the manufacturers will provide a means of setting game volume but there is no guarantee that the valid option values or the option variable name will be consistent between games from different manufacturers or even different games within the same manufacturer. There needs to be a way to create a “look-up” table for each manufacturer and game combination that defines. The Table below illustrates a look-up table for game volume for different manufacturers and different games from the same manufacturer:
This invention introduces the concept of a meta-option. A meta-option is a configuration option that does not use an absolute option value as the setting but instead uses a subjective value such as:
A meta-option is an arbitrary way of identifying a configuration option(s) change that is tied by business logic to a set of pre-defined configuration option values. The meta-option tie to specific configuration option values must be done in advance and stored in the database of the system in schema before a meta-option change can occur. An example of a low, medium and high volume meta-option change tie to the game volume configuration option value is shown below.
This table shows how a tie is made between low, medium and high volume meta-option and specific valid configuration option values. The slot floor operator can set a meta-option change to set all game volumes to low and the system uses this table (a table in the database) to know what valid configuration option value to set which machine to. Note that the system must have the ability to interrogate the electronic gaming machine when it wants to make a meta-option change so it can use that data to look up the valid configuration option value to use.
For example, if the meta-option change sets the volume across the floor to low, the system would interrogate the floor to know what is on the floor. When it interrogates the first machine and detects that it is an Aristocrat-Queen of the Nile game, it uses the lookup table to know that it should set the Game_Vol_Level variable to 2. When it interrogates the next machine and detects that it is a Bally-Winning Times game, it uses the lookup table to know that it should set the G_Vol variable to 1.
Another use of meta-options is setting minimum bet. Setting minimum bet can be accomplished by changing the number of lines and bet per line that define the minimum number of credits that can be wagered on a single game play. A meta-option for minimum bet could be constructed and then defined for every different combination of manufacturer and game theme on the floor. The Table below illustrates the creation of a meta-option table for minimum bet:
This table shows how a tie is made between low, medium and high minimum bet meta-option and two specific valid configuration option values. The slot floor operator can set a meta-option change to set all game minimum bets to low and the system uses this table (a table in the database) to know what valid configuration option value to set which machine to. Note that the system must have the ability to interrogate the electronic gaming machine when it wants to make a meta-option change so it can use that data to look up the valid configuration option value to use.
For example, if the meta-option change sets the minimum bet across the floor to low, the system would interrogate the floor to know what is on the floor. When it interrogates the first machine and detects that it is an IGT-Fort Knox-94%-Penny Game game, it uses the lookup table to know that it should set the Bet variable to 2 and Lines variable to 1. When it interrogates the next machine and detects that it is a Bally-Winning Times-90%-Nickel game, it uses the lookup table to know that it should set the B_Lines variable to 2 and the Num_Lines variable to 9.
It is important to note that the slot floor director must build these meta-option tables for each meta-option that they want to set and must include all of the possible manufacturer and game theme combinations in the table because this table data is the only way to index a subjective meta-option setting to a specific configuration option(s) valid value and variable name.
The meta-option solves the issues noted above with traditional configuration options.
First, the meta-option is more intuitive and understandable to the slot floor director.
Second, the meta-option is the only practical way to set an option across a diverse floor with machines that 1) have different valid option values and 2) name the option variable in different ways.
Third, the meta-option allows the slot floor director to set floor wide parameters that are not necessarily defined by one single configuration option. The meta-option allows the slot floor director to make up a configurable option and then bundle a collection of different individual configuration options into one meta-option. For example, setting volume across the entire floor would require knowledge of each manufacturer's valid game volume option value and the variable name for each option.
Referring to
Step 1: In this step, a meta-option is defined. The meta-option is the change that will be applied to one or more electronic gaming machines. Examples of meta-options are volume level, slot game reel speed, game mix and minimum bet.
Step 2: In this step, the meta-option is named so that it can be referenced in the future.
Step 3: In this step, the values of the meta-option are established. These values are the subjective values of the meta-option. Examples of the meta option values are low, medium and high or slow or fast or % of current value.
Step 4: In this step, an inventory of all possible manufacturer and game theme combination is compiled.
Step 5: In this step, compile a list of all possible configuration options and all valid configuration option values and variable names for each configuration value.
Step 6: In this step, choose which of the specific configuration options will be changed on each electronic gaming machine to achieve the desired change effect. For example, if the meta-option change is to set all volumes to low, the specific configuration option would be game volume. If the meta-option change is to set all game speeds to fast, the specific configuration option would be reel speed. If the meta-option change is to set all minimum bets to high, the specific configuration options would be bets per line and number of lines.
Step 7: In this step, a table is made that cross-references the value of the meta-option (e.g. low, medium and high volume) to the actual configuration option values for each manufacturer and game theme combination. For example, if you have a Bally, Winning Times you would set the game volume to 2.
Step 8: In this step, the table is committed to the database for future use by an application like the profile driven egm configurator.
Referring to
Download and Configuration Engine for a Gaming System
The DCM Engine is the main component which enables the command and control of the DCM system. Clients command and control the DCM system by consuming/using the API extended by the DCM Engine. This API is exposed to clients via many different protocols (UDP, SOAP, TCP, Named Pipes, custom protocols) which are all callable at the same time. This allows the DCM System to interface with many different systems, technologies and platforms.
It facilitates communication between the G2S Host & DCM system Databases, manages the execution of assignments and their status, and contains most of the system's business logic.
DCM Engine is a Component of SOA architecture which delivers solutions to business agility and with flexibility. Because this service exists independently of one another as well as of the underlying IT infrastructure, they can be combined and reused with maximum flexibility.
DCM Engine's functionality is been made available for access (consumption) by other systems, clients. The goal of the consumption process is to deliver new, dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including Web portals, rich clients, various business applications, complex services, or cross-functional business processes.
DCM Engine is well defined by XML messages & invokable Interfaces. Each interaction is independent of each and every other interaction and the interconnect protocols of the communicating devices (i.e., the infrastructure components that determine the communication system do not affect the interfaces). Because interfaces are platform-independent, a client from any device using any operating system in any language can use the service.
Referring to
Due to the decoupled nature of the system, the DCM engine needs to maintain DCM system state information during processing and system interactions. It does this by persisting state information using a key/value dictionary. The main purpose and function of the DCM engine state management is to persist and maintain the state of DCM operations even after a communication failure.
The DCM Engine, which runs as a Microsoft Windows service, is able to run by itself on a separate server. This server does not run any G2S Hosts or any Databases. The DCM Engine is physically disconnected from the G2S Host and runs on its own process and connects to the G2S host remotely which runs on its own process. Because of this, there is a need for the DCM engine to maintain state information about the status of the DCM jobs scheduled for the system. Whenever there is a change in the status of a Download, Install or Configuration on any EGMs, the G2S Host gets updated by the EGM through G2S messages. These G2S messages are based on the operations, and when their corresponding messages have been validated, the Status of the various operations is known. These messages are stored to a database by the G2Shosts for persistence (see
Referring to
The DCM Engine processes each message from the DCM Job status message queue. It identifies the Job ID from the message and gets the Job bundle information from the Database. Then it parses through the Job bundle identifying the next job to be run which is dependant on the on error conditions of the previous job. The Work Flow then calls the JobCreator passing in the new Job ID that has to be executed. This cycle is executed for each job in that bundle until all the jobs are executed.
The DCM Engine offers intelligence which manages multiple client requests to ensure that execution of requests are guaranteed, efficient, and prioritized based on a predetermined priority schedule.
Use of Assignment Templates in a Gaming Configuration and Download System.
Chris Arbogast, Farshid Atashband, Rajesh Swarna
An Assignment Template is a reusable Download and Configuration Manager (DCM) assignment describing what G2S download or configuration options are to be used.
This functionality allows the user of the DCM system to save commonly created assignments as reusable Assignment Templates for later use. This saves time by preventing the user from having to routinely create common assignments. This also reduces the complexity associated with creating assignments with advanced configurations which require additional effort in comparison with common assignments. An assignment template may apply to any download and configuration assignment for any G2S enabled gaming device regardless of the manufacturer.
The following example demonstrates the use of an Assignment Template named ‘Fast Reel Speed’. The saved Assignment Template has been reopened and becomes an “assignment under construction”. Now changes can be made before it is submitted for approval and executed.
Referring to
Referring to
Referring to
Referring to
Referring to
Another novel feature when scheduling an assignment is that one can make the assignment ‘temporary’. This is a mechanism by which a DCM operator can schedule option changes that will be in effect for a limited period of time. When the time expires, the system automatically runs a job to restore the EGM's options to their previous state. This saves the operator from having to schedule two jobs, and also relieves them of the burden of knowing what to do to restore the previous state.
One example of the use of the GUI display panel would be to Configure the attract sound for the Halloween weekend to be ‘spooky’ across many game themes. When the override expires, the system will restore the sound to each of them correctly without the operator needing to know in each case what that value was. This is accomplished in part by keeping track of each option change the system makes in the DCM engine programming, such as with modules for an Option Item Assigned Value and Configuration.
Assignment Bundle
Referring to
This Assignment Bundle can be applied to multiple gaming devices on the floor. Workflow is configured in such way that once the DCM Engine picks up a job from a Queue and it has been processed on the EGM, based on the status of that job, it is intelligent enough to pick the next job from the same Queue to be processed on those EGMS.
User Authorization System
Referring to
The Client:
The AuthWeb:
The Interaction:
The User Authorization System offers a single role based authorization security solution for multiple systems, platforms, and technologies.
Referring to
Configuration assignments may be run in order by schedule type: Permanent, Permanent with start date, Re-occurring Override, One Time Override. Within a schedule type, the assignment with the earlier start date may be initiated first. Within matching start dates, assignments having static collections may be initiated before dynamic; if still tied, those assignments with earlier create dates may be initiated first. Configuration assignments of permanent and permanent with start date may only contain static collections.
Download Scheduling gets the start date that download process begins. It may take an indeterminate amount of time for the downloaded package to be ready to be installed on a given EGM. Also, to avoid download conflict, if multiple download assignments exist for the same module type on an EGM, the assignment with the latest creation date takes precedence.
The Scheduler may be reliant upon the Schedule database.
An example Scheduler Composition may include:
Subcomponent Description
Error Handlers Process and gracefully handle exceptions
Logging Output of event and diagnostics
Example Interactions may include:
The Web Service may require a Windows Server version 2000 or 2003 (hereby incorporated by reference) with the following Windows components running:
Processing—The Scheduler Service may query the Schedule database for jobs that are scheduled to be run. The Scheduler may initiate the processing of the jobs by notifying the GUI Download Web Service or the GUI Configuration Web Service.
Interface/Exports—The Scheduler Service may consume the Activity Web Service to log its processing events. It also interacts with the Schedule SQL database with ActiveX Data Objects (ADO) commands.
Referring to
Classification—Web Service
Definition—The purpose of this Web Service is to expose Web Methods to consuming components to allow the interaction with the Download database. The data access logic required for the BCP to interact with the Download database may be contained within the Download Web Service.
The GUI Download Web Service may responsible for interacting with the Data Tier for those components that are consuming its exposed methods.
The BCP will consume this Web Service and utilize its Web Methods to create and read necessary Download data in the database.
The intent is for the GUI Download Web Service to be used explicitly by the BCP as communication layer with the Download database.
Example Constraints may include:
Consuming components will need to communicate via the Simple Object Access Protocol (SOAP) in order to consume the Web Service
The Web Service will publish a Web Service Description Language (WSDL) to describe the Web service, the message format and protocol details.
The Web Service will return its requested results in the form of a Serialized DataSet.
An example Composition may include:
Example Interactions may include:
The GUI Download Web Service may interact specifically with the Control Panel (BCP) via Simple Object Access Protocol (SOAP).
The GUI Download Web Service may interact with the Download SQL database with ActiveX Data Objects (ADO) logic.
The Web Service may require a Windows Server version 2000 or 2003 with the following Windows components running:
Processing—The GUI Download Web Service may process requests made by consuming components. The requests are made by the consuming component calling the GUI Download Web Services exposed Web Methods. A successfully request is dependent upon the consuming component calling a Web Method by supply the appropriate query parameters as dictated by the Web Service Description Language (WSDL) file. The Web Service processes the request by executing its embedded Business Logic while logging exceptions and events. The resulting output is returned to the consuming component.
Interface/Exports
The GUI Download Web Service may consume the Activity Web Service to log its processing events. It also interacts with the Download SQL database with ActiveX Data Objects (ADO) commands. Its capabilities are exposed as Web Methods which are accessed via the Simple Object Access Protocol (SOAP).
While the example embodiments have been described with relation to a gaming environment, it will be appreciated that the above concepts can also be used in various non-gaming environments. For example, such rewards can be used in conjunction with purchasing products, e.g., gasoline or groceries, associated with vending machines, used with mobile devices or any other form of electronic communications. Accordingly, the disclosure should not be limited strictly to gaming.
The foregoing description, for purposes of explanation, uses specific nomenclature and formula to provide a thorough understanding of the invention. It should be apparent to those of skill in the art that the specific details are not required in order to practice the invention. The embodiments have been chosen and described to best explain the principles of the invention and its practical application, thereby enabling others of skill in the art to utilize the invention, and various embodiments with various modifications as are suited to the particular use contemplated. Thus, the foregoing disclosure is not intended to be exhaustive or to limit the invention to the precise forms disclosed, and those of skill in the art recognize that many modifications and variations are possible in view of the above teachings.
The various embodiments described above can be combined to provide further embodiments. All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet, including but not limited to U.S. Provisional Patent Application No. 60/987,338, filed Nov. 12, 2007, are incorporated herein by reference, in their entirety. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.
Number | Name | Date | Kind |
---|---|---|---|
4339798 | Hedges et al. | Jul 1982 | A |
5007649 | Richardson | Apr 1991 | A |
5083800 | Lockton | Jan 1992 | A |
5275400 | Weingardt et al. | Jan 1994 | A |
5321241 | Craine | Jun 1994 | A |
5324035 | Morris et al. | Jun 1994 | A |
5326104 | Pease et al. | Jul 1994 | A |
5398932 | Eberhardt et al. | Mar 1995 | A |
5472194 | Breeding et al. | Dec 1995 | A |
5505449 | Eberhardt et al. | Apr 1996 | A |
5562284 | Stevens | Oct 1996 | A |
5605334 | McCrea, Jr. | Feb 1997 | A |
5605506 | Hoorn et al. | Feb 1997 | A |
5613912 | Slater | Mar 1997 | A |
5643086 | Alcorn et al. | Jul 1997 | A |
5655961 | Acres et al. | Aug 1997 | A |
5707287 | McCrea, Jr. | Jan 1998 | A |
5741183 | Acres et al. | Apr 1998 | A |
5745110 | Ertemalp | Apr 1998 | A |
5759102 | Pease et al. | Jun 1998 | A |
5770533 | Franchi | Jun 1998 | A |
5779545 | Berg et al. | Jul 1998 | A |
5800268 | Molnick | Sep 1998 | A |
5813912 | Shultz | Sep 1998 | A |
5823879 | Goldberg et al. | Oct 1998 | A |
5830067 | Graves et al. | Nov 1998 | A |
5830068 | Brenner et al. | Nov 1998 | A |
5851149 | Xidos et al. | Dec 1998 | A |
5890963 | Yen | Apr 1999 | A |
5911626 | McCrea, Jr. | Jun 1999 | A |
5957776 | Hoehne | Sep 1999 | A |
5971851 | Pascal et al. | Oct 1999 | A |
5999808 | LaDue | Dec 1999 | A |
6001016 | Walker et al. | Dec 1999 | A |
6047322 | Vaid et al. | Apr 2000 | A |
6068553 | Parker | May 2000 | A |
6077161 | Wisler | Jun 2000 | A |
6080063 | Khosla | Jun 2000 | A |
6089980 | Gauselmann | Jul 2000 | A |
6093103 | McCrea, Jr. | Jul 2000 | A |
6102799 | Stupak | Aug 2000 | A |
6110041 | Walker et al. | Aug 2000 | A |
6110043 | Olsen | Aug 2000 | A |
6117012 | McCrea, Jr. | Sep 2000 | A |
6135887 | Pease et al. | Oct 2000 | A |
6146273 | Olsen | Nov 2000 | A |
6149522 | Alcorn et al. | Nov 2000 | A |
6152824 | Rothschild et al. | Nov 2000 | A |
6168523 | Piechowiak et al. | Jan 2001 | B1 |
6183366 | Goldberg et al. | Feb 2001 | B1 |
6185184 | Mattaway et al. | Feb 2001 | B1 |
6186892 | Frank et al. | Feb 2001 | B1 |
6210277 | Stefan | Apr 2001 | B1 |
6217447 | Lofink et al. | Apr 2001 | B1 |
6219836 | Wells et al. | Apr 2001 | B1 |
6244958 | Acres | Jun 2001 | B1 |
6251014 | Stockdale et al. | Jun 2001 | B1 |
6254483 | Acres | Jul 2001 | B1 |
6254484 | McCrea, Jr. | Jul 2001 | B1 |
6264561 | Saffari et al. | Jul 2001 | B1 |
6287202 | Pascal et al. | Sep 2001 | B1 |
6302793 | Fertitta, III et al. | Oct 2001 | B1 |
6312332 | Walker et al. | Nov 2001 | B1 |
6346044 | McCrea, Jr. | Feb 2002 | B1 |
6362836 | Shaw et al. | Mar 2002 | B1 |
6383076 | Tiedeken | May 2002 | B1 |
6389126 | Bjornberg et al. | May 2002 | B1 |
6394900 | McGlone et al. | May 2002 | B1 |
6400272 | Holtzman et al. | Jun 2002 | B1 |
6401099 | Koppolu et al. | Jun 2002 | B1 |
6409602 | Wiltshire et al. | Jun 2002 | B1 |
6443839 | Stockdale et al. | Sep 2002 | B2 |
6459882 | Palermo | Oct 2002 | B1 |
6464584 | Oliver | Oct 2002 | B2 |
6490285 | Lee et al. | Dec 2002 | B2 |
6503147 | Stockdale et al. | Jan 2003 | B1 |
6505772 | Mollett et al. | Jan 2003 | B1 |
6508710 | Paravia et al. | Jan 2003 | B1 |
6516350 | Lumelsky et al. | Feb 2003 | B1 |
6527638 | Walker et al. | Mar 2003 | B1 |
6607441 | Acres | Aug 2003 | B1 |
6609978 | Paulsen | Aug 2003 | B1 |
6629184 | Berg et al. | Sep 2003 | B1 |
6638170 | Crumby | Oct 2003 | B1 |
6645077 | Rowe | Nov 2003 | B2 |
6652378 | Cannon et al. | Nov 2003 | B2 |
6656048 | Olsen | Dec 2003 | B2 |
6675152 | Prasad et al. | Jan 2004 | B1 |
6676522 | Rowe et al. | Jan 2004 | B2 |
6682421 | Rowe et al. | Jan 2004 | B1 |
6682423 | Brosnan et al. | Jan 2004 | B2 |
6685564 | Oliver | Feb 2004 | B2 |
6685567 | Cockerille et al. | Feb 2004 | B2 |
6699128 | Beadell et al. | Mar 2004 | B1 |
6702291 | Grebler et al. | Mar 2004 | B2 |
6712695 | Mothwurf et al. | Mar 2004 | B2 |
6718361 | Basani et al. | Apr 2004 | B1 |
6722985 | Criss-Puszkiewicz et al. | Apr 2004 | B2 |
6743102 | Fiechter et al. | Jun 2004 | B1 |
6746330 | Cannon | Jun 2004 | B2 |
6755741 | Rafaeli | Jun 2004 | B1 |
6800029 | Rowe et al. | Oct 2004 | B2 |
6811488 | Paravia et al. | Nov 2004 | B2 |
6817948 | Pascal et al. | Nov 2004 | B2 |
6823419 | Berg et al. | Nov 2004 | B2 |
6837789 | Garahi et al. | Jan 2005 | B2 |
6848994 | Knust et al. | Feb 2005 | B1 |
6866581 | Martinek et al. | Mar 2005 | B2 |
6884173 | Gauselmann | Apr 2005 | B2 |
6884174 | Lundy et al. | Apr 2005 | B2 |
6896618 | Benoy et al. | May 2005 | B2 |
6899627 | Lam et al. | May 2005 | B2 |
6908387 | Hedrick et al. | Jun 2005 | B2 |
6971956 | Rowe et al. | Dec 2005 | B2 |
6972682 | Lareau et al. | Dec 2005 | B2 |
6993587 | Basani et al. | Jan 2006 | B1 |
6997803 | LeMay et al. | Feb 2006 | B2 |
7013469 | Smith et al. | Mar 2006 | B2 |
7025674 | Adams et al. | Apr 2006 | B2 |
7050056 | Meyringer | May 2006 | B2 |
7062470 | Prasad et al. | Jun 2006 | B2 |
7086947 | Walker et al. | Aug 2006 | B2 |
7099035 | Brooks et al. | Aug 2006 | B2 |
7100184 | Kahn | Aug 2006 | B1 |
7112138 | Hedrick et al. | Sep 2006 | B2 |
7147558 | Giobbi | Dec 2006 | B2 |
7168089 | Nguyen et al. | Jan 2007 | B2 |
7186181 | Rowe | Mar 2007 | B2 |
RE39644 | Alcorn et al. | May 2007 | E |
7291068 | Bryant et al. | Nov 2007 | B2 |
7297062 | Gatto et al. | Nov 2007 | B2 |
7309065 | Yoseloff et al. | Dec 2007 | B2 |
7311605 | Moser | Dec 2007 | B2 |
7329185 | Conover et al. | Feb 2008 | B2 |
7330822 | Robson et al. | Feb 2008 | B1 |
7331520 | Silva et al. | Feb 2008 | B2 |
7337330 | Gatto et al. | Feb 2008 | B2 |
7346682 | Basani et al. | Mar 2008 | B2 |
7349920 | Feinberg et al. | Mar 2008 | B1 |
7351147 | Stockdale et al. | Apr 2008 | B2 |
7356770 | Jackson | Apr 2008 | B1 |
7363342 | Wang et al. | Apr 2008 | B1 |
7364510 | Walker et al. | Apr 2008 | B2 |
7370282 | Cary | May 2008 | B2 |
7384339 | LeMay et al. | Jun 2008 | B2 |
7419428 | Rowe | Sep 2008 | B2 |
7427236 | Kaminkow et al. | Sep 2008 | B2 |
7434805 | Grauzer et al. | Oct 2008 | B2 |
7438643 | Brosnan et al. | Oct 2008 | B2 |
7455591 | Nguyen | Nov 2008 | B2 |
7460863 | Steelberg et al. | Dec 2008 | B2 |
7465231 | Lewin et al. | Dec 2008 | B2 |
7473178 | Boyd et al. | Jan 2009 | B2 |
7483394 | Chang et al. | Jan 2009 | B2 |
7484207 | Sato | Jan 2009 | B2 |
7515718 | Nguyen et al. | Apr 2009 | B2 |
7534169 | Amaitis et al. | May 2009 | B2 |
7537216 | Soltys et al. | May 2009 | B2 |
7549576 | Alderucci et al. | Jun 2009 | B2 |
7566274 | Johnson et al. | Jul 2009 | B2 |
7575234 | Soltys | Aug 2009 | B2 |
7585217 | Lutnick et al. | Sep 2009 | B2 |
7611407 | Itkis et al. | Nov 2009 | B1 |
7611409 | Muir et al. | Nov 2009 | B2 |
7617151 | Rowe | Nov 2009 | B2 |
7618317 | Jackson | Nov 2009 | B2 |
7648414 | McNutt et al. | Jan 2010 | B2 |
7670225 | Nishimura | Mar 2010 | B2 |
7674179 | Baerlocher et al. | Mar 2010 | B2 |
7682249 | Winans et al. | Mar 2010 | B2 |
7699703 | Muir et al. | Apr 2010 | B2 |
7702719 | Betz et al. | Apr 2010 | B1 |
7706895 | Callaghan | Apr 2010 | B2 |
7730198 | Ruppert et al. | Jun 2010 | B2 |
7747741 | Basani et al. | Jun 2010 | B2 |
7769877 | McBride et al. | Aug 2010 | B2 |
7778635 | Crookham et al. | Aug 2010 | B2 |
7780526 | Nguyen et al. | Aug 2010 | B2 |
7780529 | Rowe et al. | Aug 2010 | B2 |
7785204 | Wells et al. | Aug 2010 | B2 |
7805719 | O'Neill | Sep 2010 | B2 |
7841946 | Walker et al. | Nov 2010 | B2 |
7846020 | Walker et al. | Dec 2010 | B2 |
7850528 | Wells | Dec 2010 | B2 |
7862425 | Cavagna | Jan 2011 | B2 |
7867081 | Schneider et al. | Jan 2011 | B2 |
7874920 | Hornik et al. | Jan 2011 | B2 |
7874921 | Baszucki et al. | Jan 2011 | B2 |
7886288 | Breckner et al. | Feb 2011 | B2 |
7898679 | Brack et al. | Mar 2011 | B2 |
7901294 | Walker et al. | Mar 2011 | B2 |
7908486 | Gatto et al. | Mar 2011 | B2 |
7918735 | Inamura | Apr 2011 | B2 |
7937464 | Ruppert et al. | May 2011 | B2 |
8025574 | Hilbert | Sep 2011 | B2 |
8028046 | Elliott et al. | Sep 2011 | B2 |
8051180 | Mazzaferri et al. | Nov 2011 | B2 |
8073657 | Moore, III et al. | Dec 2011 | B2 |
8100753 | Soltys | Jan 2012 | B2 |
8117461 | Bigelow, Jr. et al. | Feb 2012 | B2 |
8197344 | Rathsack et al. | Jun 2012 | B2 |
8201229 | Ruppert et al. | Jun 2012 | B2 |
8280777 | Mengerink et al. | Oct 2012 | B2 |
8285740 | Graham et al. | Oct 2012 | B2 |
8308554 | Rowe et al. | Nov 2012 | B2 |
20010019966 | Idaka | Sep 2001 | A1 |
20020004824 | Cuan et al. | Jan 2002 | A1 |
20020062375 | Teodosiu et al. | May 2002 | A1 |
20020111213 | McEntee et al. | Aug 2002 | A1 |
20020113371 | Snow | Aug 2002 | A1 |
20020115487 | Wells | Aug 2002 | A1 |
20020142825 | Lark et al. | Oct 2002 | A1 |
20020142844 | Kerr | Oct 2002 | A1 |
20030004871 | Rowe | Jan 2003 | A1 |
20030032474 | Kaminkow | Feb 2003 | A1 |
20030042679 | Snow | Mar 2003 | A1 |
20030064798 | Grauzer et al. | Apr 2003 | A1 |
20030075869 | Breeding et al. | Apr 2003 | A1 |
20030078103 | LeMay et al. | Apr 2003 | A1 |
20030090064 | Hoyt et al. | May 2003 | A1 |
20030130024 | Darby | Jul 2003 | A1 |
20030182414 | O'Neill | Sep 2003 | A1 |
20030206548 | Bannai et al. | Nov 2003 | A1 |
20030224858 | Yoseloff et al. | Dec 2003 | A1 |
20030228912 | Wells et al. | Dec 2003 | A1 |
20030232651 | Huard et al. | Dec 2003 | A1 |
20040002386 | Wolfe et al. | Jan 2004 | A1 |
20040002388 | Larsen et al. | Jan 2004 | A1 |
20040029635 | Giobbi | Feb 2004 | A1 |
20040043815 | Kaminkow | Mar 2004 | A1 |
20040043820 | Schlottmann | Mar 2004 | A1 |
20040048671 | Rowe | Mar 2004 | A1 |
20040068654 | Cockerille et al. | Apr 2004 | A1 |
20040082385 | Silva et al. | Apr 2004 | A1 |
20040106452 | Nguyen et al. | Jun 2004 | A1 |
20040110119 | Riconda et al. | Jun 2004 | A1 |
20040127291 | George et al. | Jul 2004 | A1 |
20040133485 | Schoonmaker et al. | Jul 2004 | A1 |
20040142744 | Atkinson et al. | Jul 2004 | A1 |
20040166918 | Walker et al. | Aug 2004 | A1 |
20040166940 | Rothschild | Aug 2004 | A1 |
20040185936 | Block et al. | Sep 2004 | A1 |
20040229684 | Blackburn et al. | Nov 2004 | A1 |
20040254010 | Fine | Dec 2004 | A1 |
20040254993 | Mamas | Dec 2004 | A1 |
20050043094 | Nguyen et al. | Feb 2005 | A1 |
20050054438 | Rothschild et al. | Mar 2005 | A1 |
20050054445 | Gatto et al. | Mar 2005 | A1 |
20050055113 | Gauselmann | Mar 2005 | A1 |
20050070358 | Angell et al. | Mar 2005 | A1 |
20050080898 | Block | Apr 2005 | A1 |
20050114534 | Lee | May 2005 | A1 |
20050119052 | Russell et al. | Jun 2005 | A1 |
20050143166 | Walker et al. | Jun 2005 | A1 |
20050153778 | Nelson et al. | Jul 2005 | A1 |
20050181856 | Cannon et al. | Aug 2005 | A1 |
20050181864 | Britt et al. | Aug 2005 | A1 |
20050192099 | Nguyen et al. | Sep 2005 | A1 |
20050221882 | Nguyen et al. | Oct 2005 | A1 |
20050222891 | Chan et al. | Oct 2005 | A1 |
20050239542 | Olsen | Oct 2005 | A1 |
20050240663 | Wolber et al. | Oct 2005 | A1 |
20050282626 | Manfredi et al. | Dec 2005 | A1 |
20060004618 | Brixius | Jan 2006 | A1 |
20060009282 | George et al. | Jan 2006 | A1 |
20060015716 | Thornton et al. | Jan 2006 | A1 |
20060026499 | Weddle | Feb 2006 | A1 |
20060035707 | Nguyen et al. | Feb 2006 | A1 |
20060035713 | Cockerille et al. | Feb 2006 | A1 |
20060066444 | Steeves | Mar 2006 | A1 |
20060079310 | Friedman et al. | Apr 2006 | A1 |
20060116208 | Chen et al. | Jun 2006 | A1 |
20060121970 | Khal | Jun 2006 | A1 |
20060183541 | Okada et al. | Aug 2006 | A1 |
20060195847 | Amano et al. | Aug 2006 | A1 |
20060196686 | Gatto et al. | Sep 2006 | A1 |
20060205508 | Green | Sep 2006 | A1 |
20060247013 | Walker et al. | Nov 2006 | A1 |
20060247057 | Green et al. | Nov 2006 | A1 |
20060248161 | O'Brien et al. | Nov 2006 | A1 |
20060253702 | Lowell et al. | Nov 2006 | A1 |
20060259604 | Kotchavi et al. | Nov 2006 | A1 |
20060277487 | Poulsen et al. | Dec 2006 | A1 |
20060281556 | Solomon et al. | Dec 2006 | A1 |
20060287077 | Grav et al. | Dec 2006 | A1 |
20060287098 | Morrow et al. | Dec 2006 | A1 |
20070006329 | Morrow et al. | Jan 2007 | A1 |
20070015583 | Tran | Jan 2007 | A1 |
20070026935 | Wolf et al. | Feb 2007 | A1 |
20070032288 | Nelson et al. | Feb 2007 | A1 |
20070033247 | Martin | Feb 2007 | A1 |
20070054740 | Salls et al. | Mar 2007 | A1 |
20070057469 | Grauzer et al. | Mar 2007 | A1 |
20070060259 | Pececnik | Mar 2007 | A1 |
20070060307 | Mathis et al. | Mar 2007 | A1 |
20070060365 | Tien et al. | Mar 2007 | A1 |
20070077990 | Cuddy et al. | Apr 2007 | A1 |
20070077995 | Oak et al. | Apr 2007 | A1 |
20070082737 | Morrow et al. | Apr 2007 | A1 |
20070093298 | Brunet | Apr 2007 | A1 |
20070105628 | Arbogast et al. | May 2007 | A1 |
20070111775 | Yoseloff | May 2007 | A1 |
20070111791 | Arbogast et al. | May 2007 | A1 |
20070111794 | Hogan et al. | May 2007 | A1 |
20070117608 | Roper et al. | May 2007 | A1 |
20070124483 | Marples et al. | May 2007 | A1 |
20070129145 | Blackburn et al. | Jun 2007 | A1 |
20070150329 | Brook et al. | Jun 2007 | A1 |
20070155490 | Phillips et al. | Jul 2007 | A1 |
20070167235 | Naicker | Jul 2007 | A1 |
20070191102 | Coliz et al. | Aug 2007 | A1 |
20070192748 | Martin et al. | Aug 2007 | A1 |
20070198418 | MacDonald et al. | Aug 2007 | A1 |
20070207850 | Darrah et al. | Sep 2007 | A1 |
20070208816 | Baldwin et al. | Sep 2007 | A1 |
20070214030 | Shear et al. | Sep 2007 | A1 |
20070218998 | Arbogast et al. | Sep 2007 | A1 |
20070235521 | Mateen et al. | Oct 2007 | A1 |
20070243925 | LeMay et al. | Oct 2007 | A1 |
20070243927 | Soltys | Oct 2007 | A1 |
20070243935 | Huizinga | Oct 2007 | A1 |
20070259709 | Kelly et al. | Nov 2007 | A1 |
20070259711 | Thomas | Nov 2007 | A1 |
20070287535 | Soltys | Dec 2007 | A1 |
20070298868 | Soltys | Dec 2007 | A1 |
20080004108 | Klinkhammer | Jan 2008 | A1 |
20080009344 | Graham et al. | Jan 2008 | A1 |
20080026832 | Stevens et al. | Jan 2008 | A1 |
20080026848 | Byng | Jan 2008 | A1 |
20080038035 | Shuldman et al. | Feb 2008 | A1 |
20080045341 | Englman | Feb 2008 | A1 |
20080045342 | Crowder, Jr. et al. | Feb 2008 | A1 |
20080045344 | Schlottmann et al. | Feb 2008 | A1 |
20080064501 | Patel | Mar 2008 | A1 |
20080065590 | Castro et al. | Mar 2008 | A1 |
20080076572 | Nguyen et al. | Mar 2008 | A1 |
20080085772 | Iddings et al. | Apr 2008 | A1 |
20080090651 | Baerlocher | Apr 2008 | A1 |
20080096659 | Kreloff et al. | Apr 2008 | A1 |
20080102919 | Rowe et al. | May 2008 | A1 |
20080108405 | Brosnan et al. | May 2008 | A1 |
20080108433 | DiMichele et al. | May 2008 | A1 |
20080113764 | Soltys | May 2008 | A1 |
20080113773 | Johnson et al. | May 2008 | A1 |
20080119284 | Luciano, Jr. et al. | May 2008 | A1 |
20080127174 | Johnson | May 2008 | A1 |
20080146337 | Halonen et al. | Jun 2008 | A1 |
20080153599 | Atashband et al. | Jun 2008 | A1 |
20080153600 | Swarna | Jun 2008 | A1 |
20080154916 | Atashband | Jun 2008 | A1 |
20080155665 | Ruppert et al. | Jun 2008 | A1 |
20080162729 | Ruppert | Jul 2008 | A1 |
20080171588 | Atashband | Jul 2008 | A1 |
20080171598 | Deng | Jul 2008 | A1 |
20080200255 | Eisele | Aug 2008 | A1 |
20080243697 | Irving et al. | Oct 2008 | A1 |
20080244565 | Levidow et al. | Oct 2008 | A1 |
20080261701 | Lewin et al. | Oct 2008 | A1 |
20080287197 | Ruppert et al. | Nov 2008 | A1 |
20080293494 | Adiraju et al. | Nov 2008 | A1 |
20080311971 | Dean | Dec 2008 | A1 |
20080313282 | Warila et al. | Dec 2008 | A1 |
20080318685 | Oak et al. | Dec 2008 | A9 |
20090005176 | Morrow et al. | Jan 2009 | A1 |
20090005177 | Kishi et al. | Jan 2009 | A1 |
20090011833 | Seelig et al. | Jan 2009 | A1 |
20090029775 | Ruppert et al. | Jan 2009 | A1 |
20090069076 | Silvestro | Mar 2009 | A1 |
20090115133 | Kelly et al. | May 2009 | A1 |
20090117994 | Kelly et al. | May 2009 | A1 |
20090118001 | Kelly et al. | May 2009 | A1 |
20090118005 | Kelly et al. | May 2009 | A1 |
20090118006 | Kelly et al. | May 2009 | A1 |
20090124329 | Palmisano | May 2009 | A1 |
20090124392 | Ruppert et al. | May 2009 | A1 |
20090124394 | Swarna | May 2009 | A1 |
20090125603 | Atashband et al. | May 2009 | A1 |
20090131144 | Allen | May 2009 | A1 |
20090131163 | Arbogast et al. | May 2009 | A1 |
20090132720 | Ruppert et al. | May 2009 | A1 |
20090170594 | Delaney et al. | Jul 2009 | A1 |
20090176556 | Gagner et al. | Jul 2009 | A1 |
20090176580 | Herrmann et al. | Jul 2009 | A1 |
20090181776 | Deng | Jul 2009 | A1 |
20090253483 | Pacey et al. | Oct 2009 | A1 |
20090270170 | Patton | Oct 2009 | A1 |
20090275394 | Young et al. | Nov 2009 | A1 |
20090275400 | Rehm et al. | Nov 2009 | A1 |
20090275401 | Allen et al. | Nov 2009 | A1 |
20090275402 | Backover et al. | Nov 2009 | A1 |
20090276341 | McMahan et al. | Nov 2009 | A1 |
20090298583 | Jones | Dec 2009 | A1 |
20090307069 | Meyerhofer | Dec 2009 | A1 |
20100016067 | White et al. | Jan 2010 | A1 |
20100016068 | White et al. | Jan 2010 | A1 |
20100029385 | Garvey et al. | Feb 2010 | A1 |
20100048291 | Warkentin | Feb 2010 | A1 |
20100058320 | Milligan et al. | Mar 2010 | A1 |
20100093440 | Burke | Apr 2010 | A1 |
20100093441 | Rajaraman et al. | Apr 2010 | A1 |
20100124990 | Crowder | May 2010 | A1 |
20100125851 | Singh et al. | May 2010 | A1 |
20100130280 | Arezina et al. | May 2010 | A1 |
20100131772 | Atashband et al. | May 2010 | A1 |
20100151926 | Ruppert et al. | Jun 2010 | A1 |
20100161798 | Ruppert et al. | Jun 2010 | A1 |
20100234104 | Ruppert et al. | Sep 2010 | A1 |
20100248842 | Ruppert | Sep 2010 | A1 |
20110009184 | Byng | Jan 2011 | A1 |
20110124417 | Baynes et al. | May 2011 | A1 |
20110179409 | Yoseloff et al. | Jul 2011 | A1 |
20110269534 | Kelly et al. | Nov 2011 | A1 |
20120110649 | Murphy | May 2012 | A1 |
20120203692 | Olliphant et al. | Aug 2012 | A1 |
Number | Date | Country |
---|---|---|
199 40 954 | Mar 2001 | DE |
1 074 955 | Feb 2001 | EP |
1 463 008 | Sep 2004 | EP |
2 380 143 | Apr 2003 | GB |
8255059 | Oct 1996 | JP |
2001-0084838 | Sep 2001 | KR |
2002-0061793 | Jul 2002 | KR |
2003-0091635 | Dec 2003 | KR |
0205914 | Jan 2002 | WO |
2005035084 | Apr 2005 | WO |
2007033207 | Mar 2007 | WO |
Entry |
---|
“BOB and LDAP,” Gaming Standards Association, Fremont, California, 7 pages, Oct. 26, 2003. |
“GSA Point-to-Point SOAP/HTTPS Transport and Security Specification v1.0.3,” Gaming Standards Association Transport Technical Committee, 16 pages, Jun. 5, 2007. |
Olesiejuk, “Discovery Services for Gaming Devices on a Casino Floor,” Gaming Standards Association, 3 pages, Mar. 12, 2007. |
Bally Technologies, Inc., iVIEW, http://ballytech.com/systems/product.cfm?id=9, download date Nov. 6, 2007, 2 pages. |
Bally TMS, “MP21—Automated Table Tracking/Features,” 2 pages, Nov. 2005. |
Bally TMS, “MPBacc—Specifications/Specifications,” 2 pages, Nov. 2005. |
Bally TMS, “MPLite—Table Management System/Features,” 2 pages, Nov. 2005. |
Burke, A., “Tracking the Tables,” reprinted from International Gaming & Wagering Business, Aug. 2003, 4 pages. |
Gros, R., “All You Ever Wanted to Know About Table Games,” reprinted from Global Gaming Business, Aug. 1, 2003, 2 pages. |
MagTek, “Port Powered Swipe Reader,” Technical Reference Manual, Manual Part No. 99875094 Rev 12, Jun. 2003, 20 pages. |
Mikohn, “Mikohn Tablelink—The Industry's Premier Table Tracking Solution Delivers Improvements Straight to the Bottom Line,” 2 pages, before Jan. 1, 2004. |
Terdiman, D., “Who's Holding the Aces Now?”, reprinted from Wired News, Aug. 18, 2003, 2 pages. |
Winkler, C., “Product Spotlight: MindPlay,” reprinted from Gaming and Leisure Technology, Fall 2003, 2 pages. |
Singh et al., U.S. Appl. No. 12/271,337, filed Nov. 14, 2008, 35 pages. |
Crowder, U.S. Appl. No. 12/271,736, filed Nov. 14, 2008, 35 pages. |
Atashband et al., U.S. Appl. No. 12/620,402, filed Nov. 16, 2009, 46 pages. |
Ruppert et al., U.S. Appl. No. 12/620,404, filed Nov. 16, 2009, 70 pages. |
Bulavsky, J., “Tracking the Tables,” Casino Journal, May 2004, pp. 44-47, accessed Dec. 21, 2005, URL = http://www.ascendgaming.com/cj/vendors—manufacturers—table/Trackin9162004111411AM.htm, 5 pages. |
Requirements document, “Game Authentication Terminal Program (GAT3),” to Gaming Standards Association, Aug. 2005, 27 pages. |
Standards document, “Technical Standards for Gaming Devices and On-Line Slot Systems,” to Nevada Gaming Commission and State Gaming Control Board, Aug. 17, 2005, 15 pages. |
Hung et al., “Performance Evaluation of the Least Conflict Sharable Spreading Code Assignment Algorithm,” IEEE, 1996, 5 pages. |
Gwyddion User Guide, “False Color Mapping: Chapter 3. Getting Started,” retrieved from URL=http://sourceforge.net/projects/gwyddion/files/user-guide/2007-06-28/gwyddion-user-guide-xhtml-2007-06-28.tar.gz/download, retrieved on Nov. 21, 2012, 2 pages. |
Number | Date | Country | |
---|---|---|---|
20090163279 A1 | Jun 2009 | US |
Number | Date | Country | |
---|---|---|---|
60987338 | Nov 2007 | US |