U.S. patent application number 11/938746 was filed with the patent office on 2008-07-17 for gaming browser manager client system and method.
This patent application is currently assigned to BALLY GAMING, INC.. Invention is credited to Robert W. Crowder, Anthony E. Green, Bryan M. Kelly, John E. Link, Pravinkumar Patel, Mettu Ramakrikshna.
Application Number | 20080171602 11/938746 |
Document ID | / |
Family ID | 23720433 |
Filed Date | 2008-07-17 |
United States Patent
Application |
20080171602 |
Kind Code |
A1 |
Patel; Pravinkumar ; et
al. |
July 17, 2008 |
GAMING BROWSER MANAGER CLIENT SYSTEM AND METHOD
Abstract
A browser manager server is able to initialize and configure one
or more browser windows on a gaming device display screen. The
browser manager has the ability to configure specific URLs for each
browser window, configure and Z-order depth for each window, set
window size and position, and call functions on the browser pages.
A browser client side application on a gaming device is capable of
creating multiple windows on an electronic gaming device and
responding to said server configuration or browser message
commands.
Inventors: |
Patel; Pravinkumar; (Las
Vegas, NV) ; Crowder; Robert W.; (Las Vegas, NV)
; Kelly; Bryan M.; (Alamo, CA) ; Link; John
E.; (Manteca, CA) ; Green; Anthony E.;
(Henderson, NV) ; Ramakrikshna; Mettu; (Las Vegas,
NV) |
Correspondence
Address: |
STEPTOE & JOHNSON, LLP
2121 AVENUE OF THE STARS, SUITE 2800
LOS ANGELES
CA
90067
US
|
Assignee: |
BALLY GAMING, INC.
Las Vegas
NV
|
Family ID: |
23720433 |
Appl. No.: |
11/938746 |
Filed: |
November 12, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09915929 |
Jul 26, 2001 |
|
|
|
11938746 |
|
|
|
|
09433516 |
Nov 3, 1999 |
6645068 |
|
|
09915929 |
|
|
|
|
09040654 |
Mar 17, 1998 |
6007426 |
|
|
09433516 |
|
|
|
|
08746755 |
Nov 14, 1996 |
5816918 |
|
|
09040654 |
|
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
G07F 17/3276 20130101;
G07F 17/3253 20130101; G07F 17/34 20130101; G06Q 20/04 20130101;
G07F 17/3248 20130101; G07F 17/3262 20130101; G07F 17/3225
20130101; G07F 17/32 20130101; G07F 17/3244 20130101; A63F 3/081
20130101; G07F 17/3297 20130101; G07F 17/3272 20130101; G07F
17/3239 20130101; G07F 17/323 20130101 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 13/00 20060101
A63F013/00 |
Claims
1. A method of using a browser manager to present and control one
or more browsers on one or more gaming machines from a server via a
network, wherein each gaming machine includes a primary display and
a secondary display, the method comprising: establishing a
communication link to at least one of the one or more gaming
machines; establishing a communication link with a game provider to
securely download content; receiving and packaging the content;
transmitting the content to the secondary display; managing the
browser layouts and active sessions; and accepting wagers from the
player and confirming wagers to the player.
2. The method of claim 1, wherein the browser manager regulates
content from third party servers and configures corresponding
browsers on one or more gaming machines, and wherein the browser
manager communicates said content as messages to the browsers of
one or more gaming machines.
3. The method of claim 1, wherein the servers can only communicate
with the one or more gaming machines through the browser
manager.
4. The method of claim 1, wherein the browser manager adds a
security layer by only authorizing pre-registered servers, web
pages, and URL to communicate with the one or more gaming
machines.
5. The method of claim 1, wherein transmitting the content to the
secondary display comprises the browser manager pulling content to
the secondary display.
6. The method of claim 1, wherein transmitting the content to the
secondary display comprises the server pushing content to the
secondary display.
7. A method of using a browser manager to present and control one
or more browsers on one or more gaming machines from a server via a
network, wherein each gaming machine includes a primary display and
a secondary display, the method comprising: establishing a
communication link to at least one of the one or more gaming
machines; establishing a communication link with a game provider to
securely download content; receiving and packaging the content;
providing the secondary display with a URL to the content; managing
the browser layouts and active sessions; and accepting wagers from
the player and confirming wagers to the player.
8. The method of claim 7, wherein the browser manager regulates
content from third party servers and configures corresponding
browsers on one or more gaming machines, and wherein the browser
manager communicates said content as messages to the browsers of
one or more gaming machines.
9. The method of claim 7, wherein the servers can only communicate
with the one or more gaming machines through the browser
manager.
10. The method of claim 7, wherein the browser manager adds a
security layer by only authorizing pre-registered servers, web
pages, and URL to communicate with the one or more gaming
machines.
11. A method of using a browser manager to present and control one
or more browsers on one or more gaming machines from a server via a
network, wherein each gaming machine includes a primary display and
a secondary display, the method comprising: creating one or more
browser windows on a display of a gaming machine from the server;
positioning one or more browser windows next to each other on a
display of a gaming machine from the server in an X-Y plane of a
coordinate system; and positioning an order of two or more browser
windows on top of each other on a display of a gaming machine from
the server along a Z axis of the coordinate system.
12. The method of claim 11, wherein one of the one or more browser
windows is linked to a universal resource locator (URL).
13. The method of claim 11, wherein each of the one or more browser
windows is linked to a different universal resource locator
(URL).
14. The method of claim 11, wherein one of the one or more browser
windows is linked to an application.
15. The method of claim 11, wherein each of the one or more browser
windows is linked to an application.
16. The method of claim 11, wherein one of the one or more browser
windows is a parent browser window and remaining browser windows
are child browser windows, and wherein browser layout management
incorporates prioritization of the parent browser window.
17. The method of claim 11, wherein parent browser window maintains
the highest Z axis position on the display.
18. The method of claim 11, wherein parent browser window status
can be changed to child browser window status by the server via the
network, and wherein child browser window status can be changed to
parent browser window status by the server via the network.
19. The method of claim 11, wherein child browser window
positioning is based off of parent window position as a frame of
reference.
20. The method of claim 11, wherein a new browser window is
creatable on the display screen at the highest Z axis position,
relative to other browser windows, to alert a player of priority
information.
21. The method of claim 11, wherein a new browser window is
creatable on the display screen of a gaming machine to deliver a
message to a player.
22. The method of claim 9, wherein a child browser window is
emphasized on the display screen to alert a player of priority
information relating to the child browser window, and encourage a
player to re-designate the child browser window as the parent
browser window.
23. The method of claim 11, wherein a button is emphasized on the
display screen that is associated with a particular browser window
to alert a player of priority information relating to that browser
window.
24. The method of claim 23, wherein a button is emphasized on the
display screen that is associated with a particular browser window
by flashing.
25. The method of claim 24, wherein a button is emphasized on the
display screen that is associated with a particular browser window
by flashing a specific color.
26. The method of claim 24, wherein a button is emphasized on the
display screen that is associated with a particular browser window
by flashing one of a variety of colors, wherein each color
corresponds to a different message or announcement.
27. A method of using a Transaction Manager as a mediator and
negotiator between an application/game provider and one or more
electronic gaming machines, wherein the Transaction Manager may
also act as a Banker in order to facilitate the placement,
acceptance and disposition of wagers, the method comprising: (1)
enabling a service discovery method (SDM) that detects the presence
of playable games in the casino; (2) enabling a registration method
that allows the game provider to enroll with Transaction Manager;
(3) enabling a registration method that allows the electronic
gaming machine to enroll with Transaction Manager; (4) interpreting
of the services and parameters of the game provided; (5)
authorizing the player to place wagers based on player's
permissions (using player-tracking system); (6) accepting wagers by
negotiating with the game provider; (7) confirming wagers by
printing a receipt at the gaming machine; (8) enabling disposition
of the bet by confirming the win or loss through a cashier or
cash-out booth; (9) mediating with the Browser Manager to authorize
content from the game provider; and (10) logging all
transactions.
28. The method of claim 27, wherein the game provider that provides
the gaming content is a third party, wherein the first and second
party are a casino and a gaming machine manufacturer.
29. The method of claim 27, further comprising receiving a wager
placed by a player on a gaming machine.
30. The method of claim 27, further comprising sending a message to
the originating game server acknowledging the received wager.
31. The method of claim 27, further comprising instructing the game
server to ask the transaction manager if the credits wagered are
available for game play.
32. The method of claim 27, further comprising instructing the
transaction manager to send a message to the player terminal asking
for the wagered credits.
33. The method of claim 27, further comprising instructing the game
manager to deduct the wagered credits and sends status to the
transaction manager.
34. The method of claim 27, further comprising instructing the
transaction manager to record a transaction in its database and
send a Yes or No message to a game server.
35. A method of generating charts based on game data of individual
gaming machines that are viewable on their respective individual
gaming machine via a network from a server, the method comprising:
establishing a user interface for a player showing recent win/loss
activity on the gaming device through the browser interface, in
response to a player selection; transmitting game data from an
individual gaming machine to the server via the network; generating
one or more charts based on game data of individual gaming
machines; and displaying the one or more charts on a browser window
on the gaming machines.
36. The method of claim 35, wherein the gaming data includes money
played, money won, games played, games won, and combinations
thereof.
37. The method of claim 35, wherein the gaming data is sent to a
server that records the data in a database with a timestamp.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 09/915,929 filed Jul. 26, 2001, which is a
continuation of U.S. patent application Ser. No. 09/433,516 filed
Nov. 3, 1999, now U.S. Pat. No. 6,645,068 issued Nov. 11, 2003,
which is a continuation-in-part of U.S. patent application Ser. No.
09/040,654 filed Mar. 17, 1998, now U.S. Pat. No. 6,007,426 issued
Dec. 28, 1999, which is a continuation of U.S. patent application
Ser. No. 08/746,755 filed Nov. 14, 1996, now U.S. Pat. No.
5,816,918 issued Oct. 6, 1998, all of which are hereby incorporated
by reference herein in their entirety.
COPYRIGHT NOTICE
[0002] 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.
FIELD OF THE INVENTION
[0003] These disclosed embodiments pertain generally to gaming
systems and methods. More particularly, the disclosed embodiments
relate to a browser method and system for managing, monitoring,
controlling, and modifying game- or gaming-related activities.
BACKGROUND
[0004] For some time, casino kiosks have been used to bring
server-based content to users. Additionally, games on browsers have
been utilized in the online and arcade markets. U.S. Pat. No.
5,816,918 by Kelly, entitled Prize Redemption System For Games,
discloses a browser on a pay to play gaming machine for use in both
arcades and casinos. Moreover, U.S. Pat. No. 6,645,068 by Kelly,
entitled Profile Driven Network Game And Prize Redemption System,
discloses further enablement of games and advertising for browser
based gaming devices.
SUMMARY
[0005] Briefly, and in general terms, disclosed herein are systems
and methods for providing one or more gaming machines having a
primary display and a secondary display, as well as a browser
manager operating system and method. A browser manager server is
able to initialize and configure one or more browser windows on a
gaming device display screen. The browser manager has the ability
to configure specific URLs for each browser window, configure and
Z-order depth for each window, set window size and position, and
call functions on the browser pages. A browser client side
application on a gaming device is capable of creating multiple
windows on an electronic gaming device and responding to said
server configuration or browser message commands.
[0006] Typically, the primary display is used to present the
primary game of the machine, while the secondary display is used to
present other applications including, by way of example only, and
not by way of limitation: (1) pay-tables related to the primary
game; (2) other games, such as Bingo, Keno, Sports book; (3) group
play or group bonus games; (4) web pages, animation and graphics;
and (5) player statistics, and game statistics.
[0007] Other content may be provided by a central server, such as
entertainment content in which the secondary display hosts a
browser linked to the central server. All of these applications may
be displayed and accessed from a single display using
multi-sessions browser technology.
[0008] In one embodiment, the gaming machine is transformed into a
multi-application device capable of playing a primary game, while
multiple secondary games may be accessed and played on the
secondary display. In one particular non-limiting embodiment, the
primary game is a video poker game, while the secondary playable
application is live Bingo connected to the casino's bingo room. In
another embodiment, the secondary display is used to present video
or audio feeds of the bingo room. In addition, the player
preferably is able to use his existing credits on the primary game
to place wagers on the secondary game. In this regard, the player
may use his player card to gain (previously authorized) access to
the secondary game.
[0009] This embodiment provides the player with more play and
gambling options without having to leave the gaming machine, which
is turn translates into increased revenues for the casino. Such an
embodiment also provides the platform configuration to transform a
gaming machine into a full multi-media device.
[0010] In one embodiment, a browser manager operating system and
method 10 for use with game devices, systems, and methods is
disclosed that enables users to perform browser activities from a
gaming machine. In such embodiments, a system and method are
described that include the downloading, packaging, and presenting
server-side content, including 3.sup.rd party application content,
to the gaming machine, and specifically to its secondary display.
One embodiment of the browser manager operating system 10 includes
two main modules or components: a Browser Manager (BrowserMgr) and
a Transaction Manager (TM).
[0011] In an aspect of one embodiment, the Browser Manager
communicates with the game provider on one hand to receive and
package content, and communicates with the electronic gaming
machine on the other hand to display this content and interact with
the player through the browser window. By way of example only, and
not by way of limitation, major functions of the Browser Manager
include: (1) establishing a direct link to the electronic gaming
machine; (2) establishing a direct link with the game provider to
securely download content; (3) receiving and packaging the content;
(4) transmitting the content to the secondary display or providing
a URL to the content; (5) managing the browser layouts and active
sessions; and (6) accepting wagers from the player and confirming
wagers to the player.
[0012] In another aspect of one embodiment, the Transaction Manager
functions as a mediator and negotiator between the application/game
provider and the electronic gaming machine. The Transaction Manager
may also acts as a Banker in order to facilitate the placement,
acceptance and disposition of wagers. By way of example only, and
not by way of limitation, major functions of the Transaction
Manager include: (1) enabling a service discovery method (SDM) that
detects the presence of playable games in the casino; (2) enabling
a registration method that allows the game provider to enroll with
Transaction Manager; (3) enabling a registration method that allows
the electronic gaming machine to enroll with the Transaction
Manager; (4) interpreting the services and parameters of the game
provided; (5) authorizing the player to place wagers based on
player's permissions (using player-tracking system); (6) accepting
wagers by negotiating with the game provider; (7) confirming wagers
by printing a receipt at the gaming machine; (8) enabling
disposition of the bet by confirming the win or loss through a
cashier or cash-out booth; (9) mediating with the Browser Manager
to authorize content from the game provider; and (10) logging all
transactions.
[0013] In one embodiment involving a player at an electronic game
machine, when the player inserts his player card, the Transaction
Manager determines which applications the player is permitted to
see. In this regard, the screen may be physically organized
accordingly, and the content may be distributed to each player and
session by the Browser Manager.
[0014] In another aspect of one embodiment, the permissions to
access the different games or applications are based on the
player's preferences or on prior authorization obtained from a
casino game host. When the player selects a certain session, the
application in that session may be brought to the foreground in a
ready state. Thus, some embodiments may have multiple active
sessions; therefore, the player can potentially play multiple games
or browse multiple applications. However, if a certain application
has not been played for a certain period of time, the session may
become inactive and the application dropped. In some embodiments,
the player may be able to re-activate the application by pushing an
"enroll" or "log in" button.
[0015] For example, in one specific, non-limiting embodiment, a
player engages in a game of video poker using the primary display.
If the player is authorized to access tournament games, bingo,
keno, and sports wagering, the display shows four different
sessions hosting each of the different applications represented by
four tabs at the bottom of the screen, which are labeled
Tournament, Bingo, Keno, Sports, thus allowing the player to switch
between the sessions and place wagers.
[0016] In another embodiment that implements a standard casino game
(e.g., video poker, slots, and the like), a player is able to play
the casino game just like the primary game. However, in the case of
a group play game (e.g., tournament, bingo, keno, and the like),
the player may be able to place a wager and get a confirmation
ticket printed at the electronic gaming machine. In such an
embodiment, the Transaction Manager may confirm the wager and send
a bar-coded confirmation to be printed on the electronic gaming
machine's printer. The player may then place another wager or
continue playing at the primary game or secondary game.
[0017] In still another embodiment, after a certain period of time,
when the game for which the player has placed a wager is over, the
player can take the ticket to a cashier who may verify the win or
loss by scanning the bar-coded ticket using a scanner linked to
Transaction Manager. If the ticket is a winner, the Transaction
Manager may authorize the cashier to payout the amount of the win.
In another embodiment, the player may be able to take the ticket to
a kiosk station linked to Transaction Manager to verify the win or
loss, and cashout in the case of a win. In yet another embodiment,
the player may be able to insert the ticket into the electronic
gaming machine's bill validator to verify the win or loss. In this
case, the electronic gaming machine may communicate with the
Transaction Manager to verify the claim, and if a win, dispense a
bar coded voucher that may be claimed like any other cash voucher.
In still another variation of this embodiment, the amount of the
win may be credited onto the electronic gaming machine on either
the primary game or the secondary game.
[0018] Further aspects, features and advantages of various
embodiments of the disclosed embodiments may be apparent from the
following detailed disclosure, taken in conjunction with the
accompanying sheets of drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 is a screenshot of the browser client graphic user
interface shown to a user on the gaming device, which enables a
player to navigate from one browser screen to another using the
buttons across the bottom of the screen, as well as view their
patron account and/or the base game screen or a combination of
both;
[0020] FIG. 2 is a block diagram of the various communication
between a main game CPU, a Top Box Monitor, browser-based
applications, and middleware application managers/transaction
servers that allow the data to flow between all devices;
[0021] FIG. 3 is a block diagram that displays various components
inside the gaming cabinet and how those components interconnect and
communicate;
[0022] FIG. 4 is a block and logical flow diagram that displays
various components inside a gaming machine and those components
interconnect and communicate to each other and the servers;
[0023] FIG. 5 is a logical flow diagram that displays communication
between all clients and servers using the browser manager and
browser client software and protocol;
[0024] FIG. 6 is a block diagram of a preferred broadcast server
and its interconnections to the electronic gaming machine, overhead
signage, and the tournament manager server;
[0025] FIG. 7 is a block diagram of the system and client
components and the JavaScript bridge that enables communication
between the gaming device OS and the Browser page without going
through the G2S browser class, which allows for direct and nearly
instantaneous updates of the browser screen without having to do
round trips to the server;
[0026] FIG. 8 is a block diagram that displays various servers in
the network and how those servers communicate to the various client
viewing devices or browser clients (e.g., iVIEW, Bally Alpha Gaming
cabinet, and Plasma signs throughout the property);
[0027] FIG. 9 is a block diagram using a browser on a regulated
gaming device to ensure that the data presented is secure and not
tampered with;
[0028] FIG. 10 is a block diagram of the network servers and
providing a common tournament server for the Alpha electronic
gaming machine floor tournament and the iVIEW tournaments;
[0029] FIG. 11 is a block diagram of the Z-order director
application that can frame manage 1 to N browser windows on any
device in the casino property, wherein the Z-order director
determines the proper Z-order by player requests and casino
business rules, wherein the Z-order director receives requests for
focus from various clients and servers (e.g., Bally Broadcast
Server), and wherein if the business rules allow, the proper
browser screen comes into focus and delivers the proper media to
the patrons; and
[0030] FIG. 12 is a user interface for a player who selects the
Slot Stats application showing recent win/loss activity on the
gaming device through the browser interface.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0031] FIG. 1 illustrates generic game apparatus displays or
electronic gaming machine (EGM) displays suitable for use with the
browser manager operating system and method 10. A browser manager
server is able to initialize and configure one or more browser
windows on a gaming device display screen. The browser manager has
the ability to configure specific URLs for each browser window,
configure and Z-order depth for each window, set window size and
position, and call functions on the browser pages. A browser client
side application on a gaming device is capable of creating multiple
windows on an electronic gaming device and responding to said
server configuration or browser message commands.
[0032] Referring now to the drawings, wherein like reference
numerals denote like or corresponding parts throughout the drawings
and, more particularly to FIG. 1, there is shown one embodiment of
a network gaming environment that utilizes browser manager
operating systems 10 and methods of the disclosed embodiments. It
should be noted that a variety of game architectures can be used to
provide game play functions as well as access to other electronic
gaming machines and servers through networks, as described below.
The particular architecture shown is a generic architecture using
components typical to game apparatuses suitable for use with the
disclosed embodiments. An electronic gaming machine may take a
variety of forms, including a video game apparatus having one or
more display screens; a mechanical game having playing pieces
and/or other moving mechanical parts; a personal computer system; a
"network computer;" a television including or connected to a
microprocessor (e.g. a "set top box") for the Internet or other
information access, or another apparatus.
[0033] As described herein, the electronic gaming machine 80 is
used by a player in a "gaming environment." This term is intended
to refer to any location, public or private, in which games can be
used. For example, public gaming environments include such places
as arcades, stores, restaurants, bars, casinos, bowling alleys,
stations, hotels, airports, airplanes, cruise ships, gymnasiums,
health clubs, or other public places that can offer the electronic
gaming machines 120 for use by players and which can provide prizes
to players of the game apparatus. A "gaming environment" need not
ordinarily provide games to the public. In other embodiments, a
"gaming environment" may be a private place, such as a player's
home or personal residence, office or other place of employment,
private club, and the like.
[0034] An electronic gaming machine 80, in accordance with the
disclosed embodiments, may include a game processor 120, monetary
input device 140, player input device(s) 160, and game output
device(s) 180.
[0035] Game processor 120 implements (e.g., controls, influences,
coordinates, monitors, calculates, and the like) the functions of
the electronic gaming machine 80 during a game process and includes
several input and output functions. The game processor controls the
game apparatus by receiving inputs from a player, from other game
apparatuses, from a server (described below), from a progressive
bonus apparatus, and from other sources. The game processor also
controls output signals to update the game process when
appropriate. In addition, the game processor controls the browser
manager operating system 10 of the disclosed embodiments by
calculating when prizes are awarded, calculating and updating prize
lists and prize costs, and other functions, as described below.
Game processor 120 preferably includes a digital microprocessor or
a similar controller device, and other electronic components. The
operation of game processor 120 is described in greater detail
below. The game processor is preferably provided within a housing
of electronic gaming machine 80.
[0036] Monetary input device 140 is used to receive the monetary
input that is inserted by a player into the game apparatus in the
gaming environment. For example, coins can be received in return
for the player's use of the game apparatus. A coin deposit slot can
accept standard currency coins, bills, or game tokens that may be
available in the gaming environment, and also typically includes a
coin return button and coin return slot. Once one or more coins are
accepted, the coins are routed to a cash box and a signal is sent
to game processor 120 to increase the player's game credits, i.e.,
to indicate that one or more game plays have been paid. Coin slots
and boxes suitable for use in electronic gaming machine 80 are
readily available on the commercial market.
[0037] Alternatively, other monetary input devices can be used,
such as debit card or credit card readers well known to those
skilled in the art, or "smart card" readers which can read and
write electronic information to and from the card. For example,
"E-cash," "cybercash" or other electronic monetary forms can be
used. In other embodiments, user verification or validation can be
input by the player, such as a player identification and/or
password that, for example, allows a monetary value to be billed to
a player or deducted from a player's monetary account at a bank or
other institution. Herein, the term, "monetary input," is intended
to also refer to other types of player validation for use of a game
in addition to those forms mentioned above. In alternate
embodiments located in non-public gaming environments (e.g., at a
user's home), or for other applications, such as promotional uses
of electronic gaming machine 80, monetary input may not be
necessary for the player to use electronic gaming machine 80.
[0038] Input devices 160 are used by a player or user to provide
input to the electronic gaming machine 80 to influence game events
during a game process and to achieve one or more predetermined
goals or tasks for scoring points and winning prizes or other types
of awards. The input devices 160 can also be used to select prizes
within the browser manager operating system and method 10 of the
disclosed embodiments. Alternatively, separate input controls can
be used for the prize functions of the electronic gaming machine
80.
[0039] Player input typically includes game commands provided by
controlling devices 160 such as buttons, a keyboard, dials,
joystick controls, a touch screen, a track ball, a mouse, a gun
device, a steering wheel, foot pedals, speech input through a
microphone, or any other input used in playing a game and providing
selections. For example, the player can press a button to tilt a
playing surface to guide a playing piece, move a joystick to
control a graphical object displayed on a video screen, or toss a
playing piece into a target aperture having sensors to detect the
present playing piece. Each type of user input can provide a
particular game command to the game processor 120, and the game
processor interprets the commands and influences game states and
game events in the game process accordingly.
[0040] Various other types of devices can also be included in
electronic gaming machine 80 as input devices 160 to allow the
processor 120 to monitor the game. For example, sensors of various
types can be employed to detect the paths of playing pieces
directed by the player, detect when playing pieces have been
dispensed, detect when a game is over, detect cheating actions by
the player, and the like. Also, input devices such as buttons,
switches, and the like allow the player of the game to make various
selections concerning game play. For example, a player could select
a one or two player game, a preferred award type, a progressive
option, and the like, using additional controls on a front panel of
the electronic gaming machine 80.
[0041] Game output devices 180 may influence the game and/or
provide feedback to the player about the current state of the game
process. For example, motors or solenoids can influence mechanical
components of the game in response to player commands, such as
tilting a playing surface, dispensing a playing piece, spinning a
wheel, and the like. Feedback is perceived by the player preferably
in the form of visual, auditory, and/or tactile feedback. A video
display screen can provide visual feedback such as images to the
player during the game process. Other visual output devices can
include one or more score displays, lamps or other light sources
positioned on or surrounding a "game space" (e.g., a play field or
area of game action).
[0042] Game output devices such as speakers, buzzers, alarms, and
other devices provide auditory feedback, such as sound effects
during a game process, synthesized or recorded speech, and the
like. Game output devices, such as motors, solenoids, or other
actuators can provide forces on the game apparatus or on controls
handled by the player to provide tactile feedback in the form of
vibration, jolts, and the like. One or more of the game output
devices can also be used to display information related to specific
prizes that can be won by the player when using the electronic
gaming machine 80, as described below. Game output devices 180 can
also include a coin return slot for returning coins or tokens or
providing other cash prizes after a game is played. Game processor
120 preferably commands such feedback to the player by sending out
control signals to the various output devices in electronic gaming
machine 80 when appropriate.
G2S (Game to Server) Browser Class
[0043] The browser class includes commands and events related to
browser activity available on an electronic gaming machine 80. The
browser class is a single device class with one owner host, and
zero or more guest hosts permitted.
[0044] The browser class uses a region of a display device 20 of an
electronic gaming machine (EGM). The metrics for the display device
20 (egmDisplayWidth, egmDisplayHeight) are assumed to be relatively
stable (infrequent changes); however the display device metrics may
be changed if the browser class uses the following sequence: (1)
disable the browser class device; (2) delete all browser windows;
(3) change the display device metrics; and (4) optionally enable
the browser class device.
[0045] The region of the display device 20 used by the browser
class device is indicated by the browser metrics. This region may
change from one context to the next, as specified by the electronic
gaming machine 80. For example, the game selection screen may use a
specified region, yet a game theme may use a differently sized
region.
[0046] The browser class device allows browser windows to be set,
added, modified, and deleted. Additionally, each browser window can
be assigned scripts to execute. Once created, the browser windows
can be refreshed, displayed, hidden, resized, or redirected to
another web address.
[0047] Browser window state changes can be subscribed to by
specifying one or more windowStatusSub elements for the specified
window. Whenever the browser window transitions to the state, or an
error occurs, the browserStatus command is sent to the host as a
notification command (no response from the host is needed). The
Browser window state changes that are not subscribed to may not be
sent to the host.
[0048] Most of the browser class commands operate on multiple
browser windows by providing a list of windows and related
information; however, a single browser may be addressed by
providing a list containing one window.
Request-Response Pairs
[0049] The following diagram highlights the command structure of
the browser class:
##STR00001##
[0050] The following tables organize the commands contained within
the browser class into request-response pairs:
TABLE-US-00001 TABLE 1 Commands Originiated By electronic gaming
machine 80 Request Response windowStatus none
TABLE-US-00002 TABLE 2 Commands Originiated By Host Request
Response Owner Guest getBrowserStatus browserStatus Yes Yes
setBrowserState browserStatus Yes No getBrowserProfile
browserProfile Yes Yes getWindowList windowList Yes Yes
setWindowList windowList Yes No addWindowList windowList Yes No
deleteWindowList windowList Yes No updateWindowList windowList Yes
No execBrowserScriptList ackExecBrowserScriptList Yes No
[0051] The browser class is a single-device class. deviceId 0 is
reserved for class level functions.
getBrowserStatus Command
[0052] This command is used by a host to request the current status
information of the device. The browserStatus command is sent in
response to the getBrowserStatus command.
##STR00002##
[0053] The getBrowserStatus element contains no additional
attributes or elements.
setBrowserState Command
[0054] This command is used by a host to enable or disable the
browser device. Disabling the browser device prevents the device
from being active or started by an operator. The owner of the
device can execute this command. A browserStatus command is sent in
response to a setBrowserState command.
##STR00003##
TABLE-US-00003 TABLE 3 setBrowserState Attributes Attribute
Restrictions Description enable type: boolean Indicates whether the
browser device is use: optional active. default: true true = active
and false = inactive.
browserStatus Command
[0055] This command is used by an electronic gaming machine 80 to
send the current status of the device to a host. The browserStatus
command is sent in response to the setBrowserState and
getBrowserStatus commands.
##STR00004##
TABLE-US-00004 TABLE 4 browserStatus Attributes Attribute
Restrictions Description configurationId type: configurationId
Configuration identifier set use: optional by the host. default: 0
hostEnabled type: boolean Indicates whether the device has use:
optional been enabled default: true by the host (true/false).
egmEnabled type: boolean Indicates whether the device use: optional
has been enabled default: true by the electronic gaming machine 80
(true/false).
TABLE-US-00005 TABLE 5 browserStatus Elements Element Restrictions
Description browserMetrics minOcc: 1 Contains the attributes that
define maxOcc: 1 the browser position and size (metrics).
TABLE-US-00006 TABLE 6 browserMetrics Elements Attribute
Restrictions Description coordX type: int Horizontal position (in
pixels) of the browser's use: required top left corner. coordY
type: int Vertical position (in pixels) of the use: required
browser's top left corner. sizeW type: int Width of the browser in
pixels. use: required sizeH type: int Height of the browser in
pixels. use: required
getBrowserProfile Command
[0056] This command is used by a host to request the profile
information of the device. The browserProfile command is sent in
response to the getBrowserProfile command.
##STR00005##
[0057] The getBrowserProfile element contains no additional
attributes or elements.
browserProfile Command
[0058] This command is used by an electronic gaming machine 80 to
send the device profile to a host. The browserProfile command is
sent in response to the getBrowserProfile command.
##STR00006##
TABLE-US-00007 TABLE 7 browserProfile Attributes Attribute
Restrictions Description configurationId* type: configurationId
Configuration identifier set by the host. use: required
restartStatus* type: boolean Status of the device at restart: use:
required true = enabled false = disabled useDefaultConfig* type:
boolean Indicates whether the default configuration use: required
for the device may be used when the electronic gaming machine 80
restarts. requiredForPlay* type: boolean Indicates whether the
device is required for use: required play: true = enabled false =
disabled If set to true, the device may be installed and
operational before the electronic gaming machine 80 can enable
itself for play. If the device is not installed or operational, the
egmEnabled attribute should be set to false. egmDisplayWidth* type:
int Width of the electronic gaming machine 80 use: required display
in pixels. egmDisplayHeight* type: int Height of the electronic
gaming machine 80 use: required display in pixels. *Standard
configuration option that may be included in the standard option
configuration group - 3 BAL_browserOptions - for a browser class
device.
getWindowList Command
[0059] This command is used by a host to read the set of browser
windows in the browser device. The windowList command is sent in
response to the getWindowList command.
[0060] The command can request that all browser windows be returned
in the response by omitting the windowSelect element, which has the
effect of a wildcard for all browser windows. Alternatively, the
command can request that one or more specific browser windows be
returned in the response by specifying the specific sesWindowId's
in a list of windowSelect elements.
[0061] Possible error codes are: [0062] BALB RX.sub.--001: Command
references an unknown sesWindowId.
##STR00007##
TABLE-US-00008 [0062] TABLE 8 getWindowList Elements Element
Restrictions Description windowSelect minOcc: 0 Contains a list of
window specifications maxOcc: .quadrature. to return to the host.
NOTE: omission of this element specifies that all windows should be
in the response.
TABLE-US-00009 TABLE 9 windowSelect Attributes Attribute
Restrictions Description sesWindowId type: sesWindowId Unique
browser window identifier. use: required
setWindowList Command
[0063] This command is used by a host to assign the set of browser
windows in the browser device. The windowList command is sent in
response to the setWindowList command. When processed, this command
may replace all previously assigned browser windows with the
browser windows specified in this command.
##STR00008##
TABLE-US-00010 TABLE 10 setWindowList Elements Element Restrictions
Description windowSpec minOcc: 1 Contains a list of window
specifications to maxOcc: .quadrature. assign to the browser.
TABLE-US-00011 TABLE 11 windowSpec Attributes Attribute
Restrictions Description sesWindowId type: sesWindowId Unique
browser window identifier. use: required coordX type: int
Horizontal position (in pixels) of the window's use: required top
left corner. coordY type: int Vertical position (in pixels) of the
window's top use: required left corner. coordZ type: int Z-order
(front to back) of the window. use: required sizeW type: int Width
of the window in pixels. use: required sizeH type: int Height of
the window in pixels. use: required visible type: boolean Indicates
if the window is visible. use: required url type: transportLocation
A Universal Resource Locator (URL) use: required addressing the
content for the window to display.
TABLE-US-00012 TABLE 12 windowSpec Elements Element Restrictions
Description windowStatusSub type: windowStates Identifies a windows
state that minOcc: 0 may be sent to the host via the maxOcc:
.quadrature. windowStatus command. Note: This is an optional
element of type windowStates, and has no attributes.
addWindowList Command
[0064] This command is used by a host to add browser windows to the
existing set of browser windows in the device. The windowlist
command is sent in response to the addWindowList command. When
processed, this command may append the newly added windows to the
windowList.
[0065] Possible error codes are: [0066] BAL_BRX002: Command
references an existing sesWindowId.
##STR00009##
TABLE-US-00013 [0066] TABLE 13 addWindowList Elements Element
Restrictions Description windowSpec minOcc: 1 Contains a list of
window specifications to maxOcc: .quadrature. add to the
browser.
[0067] NOTE: the windowSpec element attributes are defined in Table
11.
deleteWindowList Command
[0068] This command is used by a host to remove a set of browser
windows from the browser device. The windowList command is sent in
response to the deleteWindowList command.
[0069] Possible error codes are: [0070] BAL_BRX001: Command
references an unknown sesWindowId.
##STR00010##
TABLE-US-00014 [0070] TABLE 14 deleteWindowList Elements Element
Restrictions Description windowSelect minOcc: 0 Contains a list of
window specifications to maxOcc: .quadrature. return to the host.
NOTE: omission of this element specifies that all windows should be
in the response.
[0071] NOTE: the windowSelect element attributes are defined in
Table 9.
updateWindowList Command
[0072] This command is used by a host to update the set of browser
windows in the browser device. The windowList command is sent in
response to the updateWindowList command. When processed, this
command may update the attributes specified while retaining values
for attributes that are omitted from the command.
[0073] Possible error codes are: [0074] BAL_BRX001: Command
references an unknown sesWindowId.
##STR00011##
TABLE-US-00015 [0074] TABLE 15 updateWindowList Elements Element
Restrictions Description windowUpdate minOcc: 1 Contains a list of
windows to update maxOcc: .quadrature. within the browser.
TABLE-US-00016 TABLE 16 windowUpdate Attributes Attribute
Restrictions Description sesWindowId type: sesWindowId Unique
browser window identifier. use: required coordX type: int
Horizontal position (in pixels) of the window's use: optional top
left corner. coordY type: int Vertical position (in pixels) of the
window's top use: optional left corner. coordZ type: int Z-order
(front to back) of the window. use: optional sizeW type: int Width
of the window in pixels. use: optional sizeH type: int Height of
the window in pixels. use: optional visible type: boolean Indicates
if the window is visible. use: optional url type: transportLocation
A Universal Resource Locator (URL) use: optional addressing the
content for the window to display.
TABLE-US-00017 TABLE 17 windowUpdate Elements Element Restrictions
Description windowStatusSub type: windowStates Identifies a windows
state that minOcc: 0 may be sent to the host via maxOcc:
.quadrature. the windowStatus command. Note: This is an optional
element of type windowStates and has no attributes.
windowList Command
[0075] This command is used by the electronic gaming machine 80 to
send the current set of browser windows to a host. The windowList
command is sent in response to the getWindowList, setWindowList,
addWindowList, deleteWindowList, and updateWindowList commands.
[0076] When the windowList command is sent in response to the
getWindowList command, the contents of the windowList may match the
specified browser windows from the getWindowList request. In all
other cases, all of the browser windows may be present in the
windowList response.
##STR00012##
TABLE-US-00018 TABLE 18 windowList Elements Element Restrictions
Description windowSpec minOcc: 1 Contains a list of current window
maxOcc: .quadrature. specifications within the browser. NOTE: the
windowSpec element attributes are defined in Table 11.
execBrowserScriptList Command
[0077] This command is sent by a host to execute scripts in the
context of the browser windows within the device. The
ackExecBrowserScriptList command is sent in response to the
execBrowserScriptList command.
[0078] Possible error codes are: [0079] BAL_BRX001: Command
references an unknown sesWindowId. [0080] BAL_BRX001: Command
references an unknown script function or script type.
##STR00013##
TABLE-US-00019 [0080] TABLE 19 execBrowserScriptList Elements
Element Restrictions Description browserScriptSpec minOcc: 1
Contains a list of window identifiers maxOcc: .quadrature. with
associated scripts to execute.
TABLE-US-00020 TABLE 20 browserScriptSpec Attributes Attribute
Restrictions Description sesWindowId type: sesWindowId Unique
browser window use: required identifier. scriptType type:
browserScriptType Identifies the type of script use: required
referenced by the `function` attribute. function type: string
Identifies a script to execute use: required in the context of the
browser window.
ackExecBrowserScriptList Command
[0081] This command is used by electronic gaming machine 80 to send
the host an application level acknowledgement that the
execBrowserScriptList command was processed. The
ackExecBrowserScriptList command is sent in response to the
execBrowserScriptList command.
[0082] The acknowledgement does NOT imply that the scripts have
been executed; it indicates that the scripts have been queued up
for execution.
##STR00014##
[0083] The ackExecBrowserScriptList element contains no additional
attributes or elements.
windowStatus Command
[0084] This command is sent by electronic gaming machine 80 to
notify the host that a browser window has changed state. The
purpose of this command is to notify the host when a page has
started, or has finished loading its content, and the like. The
windowStatus command is a notification command, thus has no
response from the host.
[0085] The windowStatus command is sent when there are window
status subscriptions that correspond to the windowState, or an
error occurs in the browser window.
##STR00015##
TABLE-US-00021 TABLE 21 windowStatus Attributes Attribute
Restrictions Description sesWindowId type: sesWindowId Unique
browser window identifier. use: required windowStatus type:
windowStates Identifies the state of the browser window. use:
required url type: transportLocation An optional Universal Resource
Locator (URL) use: optional addressing the content for the window
to default: <empty> display. httpStatusCode type: egmMessage
Contains an optional HTTP status code. use: optional default:
<empty> errorText type: egmMessage Contains an optional text
description of the use: optional browser window error. Note: used
when there default: <empty> is a non-empty value in the
errorCode attribute.
Data Types
[0086] The following table lists the data types specific to the
browser class:
TABLE-US-00022 TABLE 22 browser Class Data Types Data Type
Restrictions Description sesWindowId type: int A unique window
identifier. mimIncl: 1 browserScriptType type: string An
identification of the script type. windowStates type: string Window
states that are enum: see Table 23 subscribed to by the host, and
notified with a windowStatus command.
TABLE-US-00023 TABLE 23 windowStates enumerations Enumeration
Description BAL_none No window states are subscribed. BAL_anyError
An error has occurred in the browser window. BAL_openUri Window is
opening a URI. BAL_pageStarted Page start state is reported.
BAL_pageFinished Page finished state is reported.
Error Codes
[0087] The following table lists the error codes specific to the
browser class:
TABLE-US-00024 TABLE 24 browser Class Error Codes Error Code
Standard Error Text BAL_BRX001 Command references an unknown
sesWindowId. BAL_BRX002 Command references an existent sesWindowId.
BAL_BRX003 Command references an unknown script function or script
type. BAL_BRX004 Command contains invalid window position or size.
BAL_BRX005 Command contains an invalid window status
subscription.
Event Codes
[0088] The following table lists the event codes specific to the
browser class:
TABLE-US-00025 TABLE 25 browser Class Event Codes Event Code CB BR
BAL_BRE001 electronic gaming machine Disabled Browser S Device
BAL_BRE002 electronic gaming machine Enabled Browser S Device
BAL_BRE003 Host Disabled Browser Device S BAL_BRE004 Host Enabled
Browser Device S BAL_BRE005 Host Changed Browser Config S
BAL_BRE006 electronic gaming machine Changed Browser S Config
BAL_BRE101 Browser Metrics Changed S
evaluate(state)
[0089] The egmEnabled and egmstate attributes are both determined
from multiple factors.
[0090] If all of the faults for a device have been cleared then the
egmEnabled attribute for the device can be set to true. If any one
fault still exists then the egmEnabled attribute may be set to
false. Thus, after a fault is cleared, the electronic gaming
machine (egm) may evaluate all of the attributes that contribute to
the state of the egmEnabled attribute. If anyone of them shows a
fault then the egmEnabled attribute may remain false. This is
communicated in the following documentation by using the convention
"evaluate(device. egmEnabled)".
[0091] Likewise, the egmState attribute of the cabinetStatus
reflects the aggregate state of all devices in the electronic
gaming machine 80. If the requiredForPlay attribute in the profile
of a device is set to true then if either the egmEnabled or
hostEnabled attribute of the device is set to false, the egmState
may reflect that the electronic gaming machine 80 is disabled.
Similarly, if the egmLocked or hostLocked attribute of a device is
set to true then the egmstate may reflect that the electronic
gaming machine 80 is locked out. If any one device is in such a
state then the egmState may reflect that the electronic gaming
machine 80 is disabled or locked out, as appropriate. Thus, after a
device has been enabled or a lockout has been cleared, the
electronic gaming machine 80 may evaluate the state of all active
devices within the electronic gaming machine 80 to determine the
proper value of the egmState attribute. At the same time, the
deviceClass and deviceId attributes of the cabinet Status may be
updated to reflect the appropriate device. This is communicated in
the following documentation by using the convention
"evaluate(cabinet.egmState)".
BAL_BRE01 Electronic Gaming Machine Disabled Browser Device
[0092] This event is sent by the electronic gaming machine 80 after
the browser device has been disabled at the electronic gaming
machine.
TABLE-US-00026 TABLE 26 BAL_BRE001 Device State, Meter, Log Changes
and Related Commands Details Device State Changes browser.egmEnable
= "false" evaluate(cabinet.egmState) Meter State Changes None. Log
State Changes None. Related Commands None.
BAL_BRE002 Electronic Gaming Machine Enabled Browser Device
[0093] This event is sent by the electronic gaming machine 80 after
the browser device has been enabled at the electronic gaming
machine 80.
TABLE-US-00027 TABLE 27 BAL_BRE002 Device State, Meter, Log Changes
and Related Commands Details Device State Changes browser.egmEnable
= "true" evaluate(cabinet.egmState) Meter State Changes None. Log
State Changes None. Related Commands None.
BAL_BRE003 Host Disabled Browser Device
[0094] This event is sent by the electronic gaming machine 80 after
the browser device has been disabled by a setBrowserState command
issued by a host.
TABLE-US-00028 TABLE 28 BAL_BRE003 Device State, Meter, Log Changes
and Related Commands Details Device State Changes
browser.hostEnable = "false" evaluate(cabinet.egmState) Meter State
Changes None. Log State Changes None. Related Commands None.
BAL_BRE004 Host Enabled Browser Device
[0095] This event is sent by the electronic gaming machine 80 after
the browser device has been enabled by a setBrowserState command
issued by a host.
TABLE-US-00029 TABLE 29 BAL_BRE004 Device State, Meter, Log Changes
and Related Commands Details Device State Changes browser.egmEnable
= "true" evaluate(cabinet.egmState) Meter State Changes None. Log
State Changes None. Related Commands None.
BAL_BRE005 Host Changed Browser Config
[0096] This event is sent by the electronic gaming machine 80 after
the configuration options for the browser device have been changed
remotely by a host. The event may be sent after the "configuration
changes applied" event is sent by the configuration device.
TABLE-US-00030 TABLE 30 BAL_BRE005 Device State, Meter, Log Changes
and Related Commands Details Device State Changes None. Meter State
Changes None. Log State Changes None. Related Commands None.
BAL_BRE006 Electronic Gaming Machine Changed Browser Config
[0097] This event is sent by the electronic gaming machine 80 after
the configuration options for the browser device have been changed
locally at the electronic gaming machine 80. The event may be sent
until the operator commits the configuration changes.
TABLE-US-00031 TABLE 31 BAL_BRE006 Device State, Meter, Log Changes
and Related Commands Details Device State Changes None. Meter State
Changes None. Log State Changes None. Related Commands None.
BAL_BRE101 Browser Metrics Changed
[0098] This event is sent by the electronic gaming machine 80 after
the browser metrics have changed. This event provides a means for a
host to be notified of the browser metrics change and to subscribe
to the event with the device status data, which may provide the new
browser metrics values.
TABLE-US-00032 TABLE 32 BAL_BRE101 Device State, Meter, Log Changes
and Related Commands Details Device State Changes The
browserStatus.browserMetrics element attributes for coordX, coordY,
sizeW, and sizeH may be updated to the new values. Meter State
Changes None. Log State Changes None. Related Commands None.
[0099] Referring now to FIG. 5, in sequence 1A and 2A, when the
main game on the electronic gaming machine 80 powers up, it
registers with browser manager 100 by sending specific information
such as the game IP address, the screen resolution and available
browser space. The browser manager 100 then logs the information in
a database table.
[0100] With respect to the type of applications, a distinction is
made between browser content that is static or dynamic. Static
content is handled by a (or 3.sup.rd party) Broadcast Server (as
labeled in the diagram) and normally does not necessitate player
input and does not involve money transactions. The static content
is normally informational but may include static pay tables. On the
other hand, dynamic content refers to playable applications (games)
that are transmitted to the secondary display and involve player
input and wagering. This is labeled T.P. Application (game) in the
diagram.
[0101] Referring now to sequence 1b, 2b, 3b, 4b, and 5b (static
content), on startup, the application (Bingo, Keno, and the like)
registers with Browser Manager 100 by sending specific information
such as the application parameters (number of windows needed,
window coordinates, and Z order). The Browser Manager 100 then logs
the information in a database table. An authentication process may
follow to make sure the application source is secure. The Browser
Manager 100 notifies the electronic gaming machine 80 top box
(secondary display) by sending it session data including window
coordinates and application URL.
[0102] Referring now to sequence 1c, 2c, 3c, 4c, 5c, 6c, 7c, 8,c
9c, and 10c (dynamic content), the same registration and
authentication process occurs. In this case, there is an
application server providing the game content and allowing the
player to place wagers and receiving credit. All transactions are
logged by the transaction server. The transaction server acts as an
intermediary between the application server and the electronic
gaming machine/Player.
[0103] In one embodiment of the browser manager operating system
10, the design of the browser on the electronic gaming machine
incorporates additional technology components, such as adding and
using the Mozilla browser in the Alpha OS. In some embodiments,
Macromedia Flash support can be added through a plug-in.
[0104] With respect to browser configuration, using a config text
file (/games/video.cfg), the games can specify whether they want to
enable a browser region and specify the region in pixels. This file
is also used by games using the OpenGL video server (glvideo).
TABLE-US-00033 # OpenGL = Supported, Required, Unsupported OpenGL =
Unsupported # Screen0 640x480 Single Screen # Screen1 800x600
Single Screen # Screen2 1024x768 Single Screen # Screen3 1280x1024
Single Screen # Screen4 1600x1200 Single Screen # Screen5 640x480
Dual Screen # Screen6 800x600 Dual Screen # Screen7 1024x768 Dual
Screen # Screen8 1280x1024 Dual Screen # Screen9 1600x1200 Dual
Screen Screen = Screen6 # used to instruct glvideo to start in
dualscreen mode # game has to be written for both screens
DualScreen = yes # Browser variables. Whether enabled, and
dimensions in pixels Browser = Enabled BrowserX = 0 BrowserY = 0
BrowserW = 800 BrowserH = 600 #Video Y, in dual screen specifies
video's Y offset from the top VideoY = 600
Browser Server on Electronic Gaming Machine
[0105] An IPC server ("BrowserSvr") may be added to the OS that may
have the capability to launch multiple browser windows and perform
various operations on them; such as positioning, sizing each of
them, opening URLs in those windows, and closing any of them. This
server may link to the Mozilla libraries in the sandbox.
[0106] libbrowser:
[0107] The libbrowser (gameapi/libraries/libbrowser) library
contains the interface for clients to communicate with the browser
server.
[0108] A client application wishing to interface with the browser
server may include the following header file:
[0109] gameapi.xx.xx\libraries\libbrowser\BrowserAPI.h
[0110] This header may contain functions to communicate with the
server. For example, it can ask the browser server to open a new
browser window and return the handle to that browser window. The
handle returned is used to identify the browser window in other
calls that perform a specific operation on that window.
[0111] There are two types of browser windows currently defined:
Normal and Modal. The default type is Normal. A Modal window is
used when a message is to be displayed that prevents the user from
interacting with any other Browser windows. Creation of a modal
browser window is almost the same as the creation of a normal
window, except for the window type. Being that the modal window is
a regular browser window, the content inside a modal browser window
is completely server-controllable. Any other browser windows may
not receive user input until the modal window is closed.
[0112] The Browser API may also allow clients to register callbacks
for error conditions and prompts encountered while reading content
on pages.
[0113] Header Definitions:
TABLE-US-00034 #define BROWSER_SERVER_NAME "sdg.browser.1"
namespace BrowserAPI { void Init (const char * clientName = NULL);
void Kill ( ); /** Open a new browser window */ void
NewBrowserWindow(int x, int y, unsigned int w, unsigned int h,
HBROWS& hWin, int type=WND_NORMAL,int z=0, const char *uri=0);
/** Set attributes of browser window */ void
SetBrowserWndAttribs(HBROWS hWin, int x, int y, unsigned int w,
unsigned int h,int z, const char *uri); /** Set z-order of browser
window */ void SetBrowserWinZOrder(HBROWS hWin, int z); /** Load a
URI in the browser window */ void SetBrowserURI(HBROWS hWin, const
char *uri); /** Set the browser window position & size */ void
MoveBrowser(HBROWS hWin, int x, int y,unsigned int w,unsigned int
h); /** Set the visibility of the window */ void ShowBrowser(HBROWS
hWin, bool bShow); /** Close the window */ void CloseBrowser(HBROWS
hWin); /*Execute script function on page. */ void
ExecJavascriptFn(HBROWS hWin, const char *jsuri); /** Get the
browser window XID*/ void GetBrowserWindowXID(HBROWS hWin, unsigned
long& xid); /** Register for browser errors e.g. Http errors*/
typedef void (*MozErrorCB)(HBROWS hWin,const char *uri, int
errCode); void RegisterMozErrors (MozErrorCB yourFunction); }
[0114] Messages used by the library to communicate with the
server:
TABLE-US-00035 gameapi.xx.xx\libraries\libbrowser\BrowserMsgs.h
enum { cmdNewBrowserWin = 0x0001, cmdCloseBrowserWin = 0x0002,
cmdSetBrowserURI = 0x0003, cmdSetBrowserPosSize = 0x0004,
cmdBrowserShow = 0x0005, cmdSetName = 0x0007, cmdSetWndAttribs =
0x0009, cmdURIError = 0x000A, cmdSetBrowserZOrder = 0x000C,
cmdExecjscript = 0x000E, cmdGetBrowserWinXID = 0x000B,
cmdRegMozErrors = 0x0011, };
USAGE EXAMPLES
TABLE-US-00036 [0115] #include "BrowserAPI.h"
BrowserAPI::Init("browsclient"); HBROWS hWin = 0, hWin2=0;
BrowserAPI::NewBrowserWindow(20,20,600,400,hWin,
WND_NORMAL,10,"mozilla.org"; BrowserAPI::ShowBrowser(hWin,true);
...... //move first window
BrowserAPI::MoveBrowser(hWin,200,40,500,200); //open second window
BrowserAPI::NewBrowserWindow(50,300,400,100,hWin2,
WND_NORMAL,50,"gnu.org"); BrowserAPI::ShowBrowser(hWin2,true); On
some event, change Browser 2's URL BrowserAPI::SetBrowserURI(hWin2,
"somesite.com"); //execute a script function called StartFlash( )
on second Browser window. BrowserAPI::ExecJavascriptFn(hWin2,
"StartFlash(5)" ); //close the first browser window
BrowserAPI::CloseBrowser(hWin);
[0116] Referring to FIG. 4 and FIG. 5, touch events are described.
The OS reads the events for the primary monitor via the serial
port. The Browser is expected to run on a secondary/top monitor,
which may have a USB controller plugged into a USB port on the h/w.
A USB touch server may be added to the OS that may read the touch
events through the USB port and convey them to the BrowserSvr. The
BrowserSvr may forward the events to the Mozilla libraries. An
extension has been written to the Mozilla embedding library that
may convert the touch event to a mouse event and send it to the
appropriate browser window
[0117] In one embodiment of the browser manager operating system 10
true type font are utilized. In one specific, non-limiting example,
using Mozilla's XFT capability, smooth (anti-alias) true type fonts
can be displayed. Adding of true type fonts to the OS Flash
requires investigation into their licensing, since many True Type
fonts are not freely redistributable. We can include the Bitstream
Vera fonts on the OS Flash(/usr/share/fonts/bitstream-vera) since
they are free fonts and can be freely redistributed with any
commercial software product.
[0118] During system boot up, detection of how many monitors are
present is required. The starting of X windows will depend on this.
G2S browser support classes that will communicate with G2S host(s)
and with the BrowserSvr. Base G2S support is required as the
transport medium and device registration for the browser class.
Flash animations do not receive browser events. A flash to
javascript bridge API would be used to send data from the OS into
the flash content. The Browser window opacity will be supported.
This allows visibility through one or more windows to ones behind
the others.
Browser Application System
[0119] In one embodiment of the browser manager operating system
10, a browser application system presents design considerations for
Browser Manager 100. The Browser Manager 100 may control the
Browser layouts and panels presented to the player in Browser
windows on the Player Terminal (electronic gaming machine 80). The
technologies used for testing are Open Source, cross-platform.
Web Server: Apache
[0120] In another aspect of one embodiment, a Web page Scripting
language with database connectivity is utilized; PHP (alternatives
being ASP[Microsoft], JSP[Sun], and the like).
[0121] Database: MySQL or Microsoft SQL Server 2005
Browser Manager
[0122] The Browser Manager 100 is an application that sits on a
host server, communicates with app/game/3.sup.rd party servers and
with the Player Terminals on the floor. The Browser Manager 100
runs on a server `apphost`.
##STR00016##
[0123] If apphost/Browser Manager 100 is down, no Browser-based
services may be available. Alternatively, it has a
backup/redundancy system that may kick in when apphost goes down.
The splash screen residing on the OS flash may be used when Browser
Manager 100 is unavailable.
[0124] The apphost can keep a list of the application servers in a
table `tblApps`. Adding an application server for the first time
could be done by the sysadmin manually adding the record into the
table (or through a flat file that could be then loaded into the
table). During the addition process, the application/game servers
would provide an Offline page that may reside on the apphost, which
Browser Manager 100 can use in the event the application/game host
goes offline.
[0125] The information in the tblApps table may be periodically
updated by the individual application/game servers by communicating
with the Browser Manager 100. For example, if the Keno server
wanted to change the icon image or text representing it in the
panel, it would send down the request to the Browser Manager 100
with an updated icon URL and text, and the Browser Manager 100
would update the record in the table.
[0126] The application/game servers and Player Terminals would send
a Heartbeat message regularly to the Browser Manager 100 to let it
know they are online and ready. The Browser Manager 100 would
update its tables with online/offline statuses accordingly. The
Browser Manager 100 may be implemented as a Windows application, or
cross-platform[Java] with database connectivity.
Location Of Applications
TABLE-US-00037 [0127] TABLE: tblApps Database: appsdb. App App
Offline Offline App ID Name Description Host IconURL IconImg
IconTxt AppURL Page Online 0 Casino Services svcshost: svcshost://
apphost:/ Casino svcshost:// apphost:/ Y Services offered by 3200
img/services.gif Services_offline.gif Services services.html
Services_offline.html resort 1 Keno Browser Kenohost: kenohost://
apphost:/ Play kenohost:// apphost:/ Y based 3200 img/kenoicon.gif
keno_offline.gif Keno keno.php keno_offline.html Keno 2 Bingo
Browser Bingohost: bingohost:// apphost:/ Play Bingohost://
apphost:/ Y based 3300 img/bingoicon.gif bingo_offline.gif Bingo
bingo.cgi bingo_offline.html Bingo 3 Tourna- Tnmthost: tnmthost://
apphost:/ Play tnmthost:// apphost:/ Y ment 3310 img/tournament.gif
tourn_offline.gif Tournament tour.html tourn_offline.html 4 Slot
Statistics statshost: statshost:// apphost:/ Check statshost://
apphost:/ N Stats for slots 3320 statsicon.gif stats_offline.gif
Stats stats.html stats_offline.html 5 PPV PayPer Ppvhost ppvhost://
apphost:/ Pay Per Ppvhost:// apphost:/ Y View ppvicon.gif
ppv_offline.gif View ppvall.html ppv_offline.html Video Clips AppID
and AppName: Unique id and name assigned to application.
Description Description of the application. AppHost Address to
communicate with the application host. IconImg and IconTxt Icon
image and text that are used to represent the application in the
Panel. The icon image could live on the application/game server.
OfflineIconImg In case the application/game server is down, a
fallback icon image on the apphost. AppURL URL that points to the
live application. OfflinePage In case the application/game server
is offline, use this page to indicate offline status. Status Bit
indicating whether application/game server is online.
[0128] Storing some of the application/game's information in the
Browser Manager's table and keeping it updated regularly, reduces
the amount of data transferred from the Application/game servers
every time the application/game is invoked on a Player Terminal
(i.e., Electronic Gaming Machine).
Registration and Player Terminal (PT) Enrollment with Browser
Manager
[0129] On Player Terminal (i.e., electronic gaming machine)
startup, the Browser Manager 100 could send an enrollment (or
registration) message to the Browser Manager 100 passing it
information such as the primary game, IP address, the screen
resolution the Player Terminal is in, and the Browser Space
available. The Browser Manager 100 stores this in a table
tblPTinfo. As time passes, if players insert their card into the
Player Terminal, that card info can be entered in the PlayerID
field.
TABLE-US-00038 TABLE: `tblPTinfo` Description: This table is used
to keep track of the Player Terminals on the floor and the state
that they are in. PT Browser Browser Player ID PT IP PrimaryGame
ResX ResY SpaceW SpaceH ID Online 1 10.10.3.31 AuctionFever 800 600
800 600 Y 4 10.10.3.55 Poker 1280 1024 1280 1024 Y 20 10.10.3.43
Roulette 1360 768 1360 768 y 50 10.10.3.20 Blazing7s 1024 768 1024
768 y PT ID, PT IP PT identifier and IP address PrimaryGame Primary
game on PT ResX Screen resolution X ResY Screen resolution Y
Browser SpaceW Available Browser space width Browser SpaceH
Available Browser space height PlayerID Player ID if available
Online Is PT online
[0130] The PrimaryGame information can be conveyed to the Dynamic
Glass Server to display paytable or other graphics. The Dynamic
Glass Server could use a collection of PHP scripts connected to a
database and a set of images. In the most basic cases where the
secondary display is just an HTML page with one image, and may be
some standard text, a generic script glass.php could be used. If
more elaborate pages with multiple images are needed, then custom
php scripts could be written and entered into a table as shown
below. The scripts could also read in the resolution of the Player
Terminal and generate pages with different sized images.
TABLE-US-00039 TABLE Tblgamepaytables GameID PrimaryGame Script
Image 1 FourAlarmBonus glass.php images/fabpaytable.gif 2 Blazing7s
glass.php images/b7paytable.gif 3 AuctionFever auctionfever.php 4
Poker Poker.php Description: This table is managed by the sysadmin
and is used to associate primary games with paytable graphics for
the secondary screen. GameID: Identifier to the Player Terminals
primary game. Used for mapping to paytable graphics on the
secondary screen. PrimaryGame: Name of the Player Terminals primary
game. Script: Active script that presents the primary game related
content (e.g. paytables) on the secondary screen. Image: A primary
game image for use with a generic script(glass.php) that just
displays one image in an HTML page.
[0131] Example: If a Player Terminal with the FourAlarmBonus game
is booted up.
TABLE-US-00040 ##STR00017## 1: Player Terminal (PT) boots up, PT:
Browser Manager sends an enrollment message to the Browser Manager
with information about itself e.g. Enroll(GameName, screen
resolution, Browser space) 2. Browser Manager replies with a layout
and a URL for the secondary display 1 0 70 100 30 0 BANNER
apphost/glass.php?gameID=1 Browser Manager creates one Browser
window and hands it the URL. 3. The Browser window loads
apphost/glass.php, which looks up tblGamePayTables and generates
the paytable page with the gif. Had it been the AuctionFever or
Poker game that booted up, the Browser Manager would have replied
with apphost/auctionfever.php If the script was resolution
dependant, then, for example,
apphost/poker.php?ResX=1024&ResX=76 8
[0132] In the atypical event, that a game does not have an entry in
the tblGamePayTables table, a default banner URL could be sent.
Browser Layouts
[0133] In one embodiment of the browser manager operating system
10, Browser Layouts present a flexible scheme that may allow
multiple and different screen layouts. The example below shows
three sample layouts with the information stored in two tables
(tblPanes and tblLayouts).
[0134] Table tblPanes contains a list of the pane configurations
used with x, y, w, h values in percentages. Translation to pixels
may be done on the individual Player Terminals, which could have
different resolutions under different games.
[0135] Table tblLayouts contains the layouts with each pane in the
layout as a separate row. Panes of type PANEL indicate which pane
the result of the panel selections may be shown in. For example, in
the table below, Pane 2 contains the Panel, and its child is Pane
1. Therefore, any windows controlled by the Panel are defined to
appear in Pane 1.
A FEW EXAMPLE SCREEN LAYOUTS
TABLE-US-00041 [0136] TABLE ##STR00018## ##STR00019## ##STR00020##
##STR00021## ##STR00022## tblPanes (values in percentages) PaneID X
Y W H 0 0 0 100 100 1 0 0 100 70 2 0 70 100 30 3 0 0 70 80 4 70 0
30 80 5 0 80 100 20 Full screen Splash/Banner 1: App/Game 2: Panel
3: App/Game 4: Panel, 5: Banner/Ad
TABLE-US-00042 TABLE tblLayouts LayOutID PaneID Type ChildPaneID 0
0 1 1 1 2 PANEL 1 2 3 2 4 PANEL 3 2 5
[0137] Adding a new layout means adding new or reusing existing
panes in the `tblPanes` table, and then making the appropriate
entries in the `tblLayouts` table. If there is no panel in the new
layout, the Type fields may be blank. A GUI tool could be developed
that allows the sysadmin to create, edit, and manage layouts in the
database.
[0138] Dynamic layouts, as opposed to the static layouts mentioned
above are considered within the scope of the disclosed embodiments.
For example, in a 1 pane layout, say a 2nd, or 3rd pane and windows
are to be added for marketing/promotional purposes. Dynamic panes
and layouts sound appealing and would render tblPanes unnecessary,
However, as the panes grow and shrink, the Browser windows wouldn't
automatically resize images, The above assumes that there may be
one rectangular region dedicated for Browsers, divided up into
panes. There may be instances where there is no such dedicated
region, and Browser windows may be shown at any location; such as a
single widescreen, with a couple of Browser windows displaying
promotions, at arbitrary locations.
Sliding/Popup Windows
[0139] In some embodiments of the browser manager operating system
10, to avoid having to resize panes, windows and content, popup
windows could be used. In this regard, consider several Player
Terminals on the floor showing paytables on the secondary screen. A
department at the resort (gaming/dining/entertainment) works on a
promotion and creates a page (W:800, H:200), that it needs to
display at the top/bottom of the second screen. It can request the
Browser Manager 100 to show a popup window for all/a selection of
Player Terminals. The Browser Manager 100 sends the command down to
the Player Terminals, which show the popup window with the
promotional URL in a Browser window. This window can start
flattened on one axis and expands steadily in size in about 1-2s,
until it reaches the final size (800,200). A smooth transition like
this would be less visually jarring, than having a popup window
suddenly show up on screen. The Player Terminal: Browser Manager
100 would control the window resizing between the initial and final
window sizes. Having browser window transparency may be good to use
for popups too.
Screen Resolutions
[0140] In one embodiment of the browser manager operating system
10, the presence of Player Terminals with different Screen
resolutions needs to be taken into account when dealing with
content and layouts. The content can be designed to take up all
available Browser space, but there is no inherent capability of a
Browser to scale content. For example, a game with graphics for an
800.times.600 window may not be automatically scaled by the Browser
to larger graphics in a 1280.times.1024 window. However, the html
could be altered at source to display a scaled image.
[0141] The following are some of the possible screen resolutions.
Relative sizes are to scale.
[0142] Browser Content developers may need to design their content
to utilize Browser space efficiently. Banners/Splash screens can be
easily designed for multiple resolutions using HTML elements.
However, displaying fixed width content like Flash games, may be
less straightforward. An option may be to develop the games with
different resolutions and have the Browsers load the appropriate
resolution games.
Custom Panels
[0143] To generate a custom panel, a PHP script could be used that
takes application names as arguments, connects to the applications
database, pulls up the icon and URL information for the specified
applications from tblApps, and generates a web page with buttons
and embedded javascript; which the Browser may then display on the
Panel window, as shown below:
[0144]
URL(apphost://apps.php?NumApps=4&App1=Casino%20Services&App2=Keno&A-
pp3=Bingo&App4=Plantasia)
[0145] If it was a different player with a different set of games,
or some other reason, the Browser Manager 100 could send down a
different URL, as shown below:
[0146]
apphost://apps.php?player=123456&NumApps=3&App1=Keno&App2=Bingo&App-
3=Casino%20Services resulting in a different panel as shown in the
screenshot here.
[0147] The script also handles dimensions of buttons, background
and the like. When the player chooses an application by selecting
the application button, there needs to be some way of depicting
that, which is the currently selected application. Non-limiting
examples include either by showing the button in a depressed state
or a different color and the like.
[0148] Players would be identified by their ID/Tracking number, if
present. To determine what options are to be presented to the
player, there needs to be some mapping of Player ID to applications
(e.g., through a table).
Mapping Layouts to Content
[0149] In one embodiment, the Browser Manager 100 needs to map
content URLs to layouts. There is a standard predefined sequence of
layouts and content URLs presented. Alternatively, the layout may
it be dynamic, player, and preferences based.
Startup
[0150] For example, on a Player Terminal (ID-20) startup, the
Browser Manager 100 could send a default Banner URL
TABLE-US-00043 Numwindows x y w h z type url 1 0 70 100 30 0 BANNER
apphost/welcome.php
[0151] This banner/splash would be server driven and employ
client-pull or server-push techniques to display different
paytable/promotional/marketing web pages. Normally, a browser
window is told to open to a specific URL and then the client window
pulls the content down using HTTP POST or HTTP GET function calls.
The push function may also be used by a third party server to fire
javascript functions on the HTML page.
Initiating Browser Applications
[0152] In one embodiment of a browser manager operating system 10,
a browser application is initiated in response to some event (e.g.,
player inserts card/player inserts money/some event at host).
Through some logic, (e.g., a rule-based system that determines the
screen space negotiation) the Browser Manager 100 decides or is
instructed to use Layout1 and present four applications in the
panel. A specific, non-limiting example of the panel URL is as
follows:
[0153]
apphost://apps.php?NumApps=4&App1=Casino%20Services&App2=Bingo&App3-
=Keno&App4=SlotStats
[0154] The Browser Manager 100 looks up Layout1 in tblLayouts, sees
that there is a panel defined, and for each application, defines a
separate window in the child pane. So for four applications, it
opens up four stacked windows in the child pane, with the
application URLs pulled up from tblApps. If the Game/Application
Server is offline, the Browser Manager 100 sends the offline
URL.
TABLE-US-00044 ##STR00023## 1. Browser Manager asks
Host1(CasinoServices) if it is up. Response Y 2. Browser Manager
asks Host2(Bingo) if it is up. Response Y 3. Browser Manager asks
Host3(Keno) if it is up. Response Y 4. Browser Manager asks
Host4(SlotStats) if it is up. No Response Browser Manager marks
SlotStats record in database as offline 5. Browser Manager forms
message with layout and URLs and sends to Player Terminal: Browser
Manager
[0155] In this example, of the four stacked application windows;
the first three would be live URLs pointing to the application/game
servers. The fourth window for the offline applications (SlotStats)
would show the predefined Offline page for SlotStats.
TABLE-US-00045 Numwindows x y w h z type url 5 0 70 100 30 10 PANEL
apphost://apps.php?player=123456&NumApps=4&App1=
Casino%20Services&App2=Bingo&App3=Keno&App4=SlotStats 0
0 100 70 10 PANEL_CHILD1 svcshost://services.php?player=123456 0 0
100 70 0 PANEL_CHILD2 bingohost://bingo.cgi 0 0 100 70 0
PANEL_CHILD3 kenohost://keno.php 0 0 100 70 0 PANEL_CHILD4
apphost://stats_offline.html
[0156] In one embodiment of a browser manager operating system 10,
the panel window would execute apphost://apps.php, which would
present the application buttons in a customized web page. If the
player is identified through their player card, the player's info,
pulled up from the Player Tracking database could also be used for
custom, player-specific presentations in the Browser windows.
Browser Manager 100 would keep track of sessions and Browser
windows through the tables `tblSession` and `tblSessionApps`.
TABLE-US-00046 TABLE: tblSession Session- ID PT-ID PlayerID
Start-Time End-Time Layout-ID 1 4 4/3/06 11:25 am 1 2 1 4/3/06
12:25 pm 1 3 20 4/2/06 8:00 am 0 Session ID: Unique session
identifier PT-ID: PT the session was played at Player-ID: ID of
Player if available Start-Time: Time the session began End-Time:
End time of session Layout-ID: Layout used in session
TABLE-US-00047 TABLE: tblSessionApps Following example shows
entries for 3 Player Terminals: Session 1 with panel and 4 apps,
Session 2 with panel and 3 apps, Session 3 with one banner window.
SessionID AppName SessionWnd-ID Z-Level GameID 1 PANEL 0 ACTIVE_Z 1
Casino 1 ACTIVE_Z Services 1 Bingo 2 0 1 Keno 3 0 1 SlotStats 4 0 2
PANEL 0 ACTIVE_Z 2 Casino 1 ACTIVE_Z Services 2 Bingo 2 0 2
SlotStats 3 0 3 BANNER 0 ACTIVE_Z Session ID: Unique session
identifier AppName: Name of application SessionWnd-ID: Zero based
ID assigned to window Game ID: If available, a unique GameID
obtained from the app/game server Z-Level: The Z level the window
is currently at [e.g. ACTIVE_Z = 100 INACTIVE_Z = 0]
Application Comes Back Online
[0157] In one embodiment of a browser manager operating system 10,
when SlotStats comes online again, it sends a Register message to
apphost/Browser Manager 100. The Browser Manager 100 performs a
handshake, and may exchange some data with SlotStats. It updates
the Status field in the `tblApps` table; searches the
`tblSessionApps` table, finds all instances of SlotStats, and sends
a LoadURL message for the appropriate windows for each of those
Player Terminals. For example:
[0158] 10.10.3.31 LoadURL (4 statshost://stats.html)
[0159] 10.10.3.55 LoadURL (3 statshost://stats.html)
Application Goes Offline
[0160] In the reverse situation where the applications have been
loaded in ready state and one of them goes down, a similar process
takes place. The Browser Manager 100 expects a heartbeat from each
application regularly. However, if SlotStats goes down, then the
Browser Manager 100 gets no heartbeat from SlotStats a few times in
succession. In response, the Browser Manager 100 updates the
SlotStats records in `tblApps` table with Status `Down/0`, searches
the `tblSessionApps` table for all instances of SlotStats and sends
the LoadURL message to each of the Player Terminals with the
offline URL. For example:
[0161] 10.10.3.31 LoadURL(4 apphost:/stats_offline.html)
[0162] 10.10.3.55 LoadURL(3 apphost:/stats_offline.html)
Application Selection/Switching
[0163] In another embodiment of a browser manager operating system
10, when the player presses a button on the panel, that
application's window is raised in the child panel, and the other
windows are sent behind it or made invisible. This allows easy,
fast switching between applications. This can be done by the
Javascript function attached to each button, sending a message to
the Browser Manager 100.
[0164] For example, if on Player Terminal ID-1, the Keno button was
pressed, the Javascript function attached to the button would send
a message like `Keno/App2 selected`. The Browser Manager 100 would
receive the message, lookup the mapping of the
appname/appid(Keno/2) to Browser window for Player Terminal ID-1 in
the tblSessionApps table, and see that the Keno window's ID is
three. It would raise the Keno window's Z level to ACTIVE_Z and
lower the Z level for the other child windows.
TABLE-US-00048 TABLE tblSessionApps SessionID AppName SessionWnd-ID
Z-Level GameID 1 PANEL 0 ACTIVE_Z 1 CasinoServices 1 0 1 Bingo 2 0
1 Keno 3 ACTIVE_Z 1234 1 SlotStats 4 0
[0165] A message is then sent to the Browser Manager 100 on the
Player Terminal ID-1 to raise the window id:three, or hide the
other windows.
[0166] 10.10.3.31 SetZOrders (3 ACTIVE_Z 1 INACTIVE_Z 2 INACTIVE_Z
4 INACTIVE_Z)
Multiple Browser Windows Per Application
[0167] In an embodiment, browser applications may be able to
perform all foreseen operations within a single browser window
using various web technologies like DHTML, and the like. There are
cases where a browser application may find the need to open a new
browser window to display a message like a promotion, a win, and
the like. The Browser Application designers will need to define
whether they can do it with just one window or multiple
windows.
[0168] However, for now, to accommodate the possibility that an
AppServer may need to open multiple browser windows, we may
consider that each AppServer may maintain a sequential list of
window Ids. On the Browser Manager side, the table tblSessionApps
may contain a mapping of the application's windowIDs (AppWndID) and
the session's windowIDs (SessionWndID). For example, the Keno
application, may open a new window (ID: 1) with Z-order 10 at a
later stage. The Browser Manager 100 adds that window to the
tblSessionApps table and assigns it the next available ID (e.g. 5).
For Keno's 3rd window, the Browser Manager 100 would assign ID 6,
and so on.
TABLE-US-00049 TABLE: tblSessionApps Session App SessionID AppName
WndID Z-Level WndID GameID 1 PANEL 0 ACTIVE_Z 0 1 Casino 1 0 0
Services 1 Bingo 2 0 0 1 Keno 3 ACTIVE_Z 0 1234 1 SlotStats 4 0 0 1
Keno 5 ACTIVE_Z + 10 1 1 Keno 6 ACTIVE_Z + 15 2
[0169] When the player switches from Keno to Bingo in the panel,
all of Keno's windows may have their z orders moved back.
Third Party Browser Based Game Play
[0170] In one embodiment of a browser manager operating system and
method 10, when the player starts a game (e.g. by pressing a button
on the Keno page), the page requests a game from the Game Server.
The Game Server requests approval from the Transaction Manager 110.
The Transaction Manager 110 in turn queries the Player Terminal
(OS-gamemgr) for credits. If the Player Terminal has the credits,
it deducts the credit meter and sends a response (ACK/yes) to the
Transaction Manager 110. The Transaction Manager 110 records the
transaction in its database and sends the approval message to the
Game Server.
[0171] The Game Server starts a game and sends a StartGame message
with the GameID (e.g., 1234) to the Browser Manager 100. The
Browser Manager 100 records the GameID in the tblSessionApps table.
This allows the Browser Manager 100 to resume the game, if the
player cashes out before seeing the game complete, and returns at a
later time. When the game is completed, the game server sends an
EndGame message with the GameID. The Browser Manager 100 erases the
GameID field of that session.
TABLE-US-00050 ##STR00024## 1) Bet 5 Player hits a bet 5 button
placing a wager/play a game. The message is sent to the originating
game server. 2) Debit 5 The Game server asks the Transaction
Manager 110 if the credits are available and claimed for game play.
3) Transaction Manager 110 sends a message to the Player Terminal
asking for 5 credits. 4) Gamemgr tries to deduct credits by 5 and
sends status to Transaction Manager 110. 5) Transaction Manager 110
records the transaction in its database and sends Y,N to Game
server. 6) Game server either commences game or disallows it. 7) If
game is started, GameServer sends GameID to Browser Manager 100
which records it in the table.
Alerting a Player Through the Panel
[0172] In one specific, non-limiting embodiment, the player is
playing Keno, makes a wager, and is waiting for the result. He
switches to another application, for example News/Bingo. When the
Keno game needs to catch the player's attention, it may send a
command via the Browser Manager 100, to red flash the Keno button
in the panel or something similar. This can be done by a javascript
function on the page that changes the background color of the
specified button in a pre-specified color loop.
[0173] For example, there may be an event at the Keno Application
Server that needs the attention of all the Player Terminals playing
Keno. The players may not have the Keno screen active at that
moment. The Keno server sends a message to the Browser Manager 100
requesting the attention of players who may not have the Keno
window active.
[0174] The Browser Manager 100 looks through its tblSessionApps
table, and for every Player Terminal that has its Keno application
at an INACTIVE_Z, sends a message containing the appid, to Browser
Manager 100 to execute a generic JavaScript function on the page.
The javascript function may use the appid, match it to a button,
and could flash that button in red.
[0175] The Player sees the flashing Keno button in the panel,
clicks on the Keno button and sees an updated Keno page. The button
stops flashing when it is clicked. Another approach could be to use
an animated gif instead of the colors changing.
[0176] Using this technique, multiple application/game servers can
send messages through Browser Manager 100 to red flash their
applications on the panel. For less urgent alerts, different colors
(green/yellow) could also be used.
Session Termination
[0177] To end a player's sessions, in response to some event (e.g.,
player cashing out, player taking card out, host determined event),
the Browser Manager 100 may send a new layout to the Player
Terminal, such as a Browser Manager 100 with just one window
displaying a banner (e.g., a marketing screen on the top screen in
Idle mode, with for example, "Coming Soon" titles).
TABLE-US-00051 Numwindows x y w h z type url 1 0 70 100 30 ACTIVE_Z
BANNER apphost//welcome.php
[0178] Referring now to a session termination event (e.g.,
cashout), the player may be asked if he would like to save his
session. If player chooses "Yes," the session tables are updated
with the end time. If the player has not been identified by
PlayerID, the session identifier can be printed on a ticket. The
ticket may be deemed good for a predetermined (30/60/etc) number of
days. If player chooses "No," the session entries may be deleted
from the session tables.
[0179] Alternatively, if there is any game/application that the
user is using, that is in a `waiting for completion` state, just
print the ticket, and don't ask the user. If there is no such
game/application that the player is waiting on, just end the
sessions without asking. Delete the session entries from the
session tables.
[0180] With respect to session resumption, when the player returns
at a later time and inserts the ticket at any Player Terminal, the
SessionID is read from the ticket, and sent to the Browser Manager
100. The Browser Manager 100 looks at the session tables, pulls the
information for the session, and prepares a message to the Player
Terminal with the Browser layout and URL information. If the player
had been waiting for a game result when he cashed out; there should
be a GameID for that game session in the tblSessionApps table. The
Browser Manager 100 may include that GameID in the URL message. The
Browser windows then load the URLs with GameIDs, pointing to the
game servers. The game servers pull up the results for that game
and present it in the Browser windows.
[0181] An example message for resuming a session: Suppose the Keno
game was in waiting mode when the session termination/cashout
occurred. On resumption, the Browser Manager 100 would see a GameID
is present for the Keno session and include that in the Keno
URL.
TABLE-US-00052 Numwindows x y w h Z type url 5 0 70 100 30 10 PANEL
apphost://apps.php?player=123456&NumApps=4&App1=
Casino%20Services&App2=Bingo&App3=Keno&App4=SlotStats 0
0 100 70 0 PANEL_CHILD1 svcshost://services.php?player=123456 0 0
100 70 0 PANEL_CHILD2 bingohost://bingo.cgi 0 0 100 70 10
PANEL_CHILD3 kenohost://keno.php?gameId=1234 0 0 100 70 0
PANEL_CHILD4 apphost://stats_offline.html
[0182] In this example, the Keno window is the active window, and
its URL would contain the GameID from the last session. The Keno
server would look up its database for the results for that
particular game and prepare a page with the results.
Messages in the Browser Application System
[0183] Another aspect of the browser manager operating system 10
outlines the messages used in the Browser application system
between the Player Terminals, the Browser Manager 100,
TransactionManager, and the AppServers. Where applicable, the
messages may allow multiple target items to be affected, to
facilitate more effectiveness per message and less messaging
traffic.
##STR00025##
Player Terminal to Browser Manager Messaging--Register
[0184] In one embodiment of the browser manager operating system,
the player terminal to browser manager message gets sent by the
Player Terminal (PT) on boot up to the Browser Manager 100.
[0185] Parameters:
TABLE-US-00053 PT ID The unique ID assigned to the PT Primary Game
The primary AGP game running on the PT Resolution width, height The
screen resolution the PT is configured for Browser Area W, H The
Browser area in W, H
Playercardinsert
[0186] The playercardinsert message gets sent when a player inserts
their card at the Player Terminal.
[0187] Parameters:
TABLE-US-00054 PT ID The unique ID assigned to the PT PlayerID
Unique player tracking ID
Playercardremove
[0188] The playercardremove message gets sent when a player removes
their card at the Player Terminal.
[0189] Parameters:
TABLE-US-00055 PT ID The unique ID assigned to the PT PlayerID
Unique player tracking ID
Buyin/Cashin
[0190] The buyin/cashin message gets sent when credits are inserted
at the Player Terminal.
[0191] Parameters:
TABLE-US-00056 PT ID The unique ID assigned to the PT PlayerID
Unique player tracking ID if available
Cashout
[0192] The cashout message gets sent when a cashout occurs at the
Player Terminal.
[0193] Parameters:
TABLE-US-00057 PT ID The unique ID assigned to the PT PlayerID
Unique player tracking ID if available
Heartbeat/Keepalive
[0194] The Heartbeat/Keepalive message is sent by the Player
Terminal 80 to the Browser Manager 100 to inform Browser Manager
that Player Terminal is still alive.
[0195] Application Specific Messages
Sendslotsdata
[0196] The sendslotdata message is sent by the Player Terminal, on
the primary game end event, and carries some accounting meters.
[0197] Parameters:
TABLE-US-00058 PT ID The unique ID assigned to the PT gamesWon
Number of games won gamesLost Number of games lost MoneyWon Total
money won MoneyPlayed Total money played
[0198] Browser Manager to Player Terminal
Setlayout
[0199] The Setlayout message is used to send down a predefined
screen layout with multiple windows with content URLs. This message
is variable length depending on the number of windows. This message
can be used for a single or multiple windows.
[0200] Parameters:
TABLE-US-00059 NumWindows [for each window] Number of windows WndID
Window ID X Window Left Y Window Top W Window Width H Window Height
Z Z order of the window url URL the window needs to display
Setwindowurls
[0201] The Setwindowurls message is used to set the URLs for the
browser window(s).
[0202] Parameters:
TABLE-US-00060 NumWindows [for each window] Number of windows WndID
Window ID url URL the window needs to display
Showbrowserwindows
[0203] The Showbrowserwindows message is used to set the visibility
of the browser window(s).
[0204] Parameters:
TABLE-US-00061 NumWindows [for each window] Number of windows WndID
Window ID Show Flag indicating whether the window is to be shown or
not
Movebrowserwindows
[0205] The Movebrowserwindows message is used to reposition the
browser window(s).
[0206] Parameters:
TABLE-US-00062 NumWindows [for each window] Number of windows WndID
Window ID x Window Left y Window Top w Window Width h Window Height
z Z order of the window
Closebrowserwindows
[0207] The Closebrowserwindows message is used to close the browser
window(s).
[0208] Parameters:
TABLE-US-00063 NumWindows [for each window] Number of windows WndID
Window ID
Setzorders
[0209] The Setzorders message is used to set the Z-orders of the
browser window(s)
[0210] Parameters:
TABLE-US-00064 NumWindows [for each window] Number of windows WndID
Window ID Z order Z-order of window
Execjavascriptfunction
[0211] The Execjavascriptfunction message is used to execute a
Javascript function on the page. It is powerful in the sense that
the host can send commands to execute predefined functions on the
page when it needs to. For example, when the AppServer needs to
catch the attention of all its players, it can send a
RequestAttention( ) message to the Browser Manager 100. The Browser
Manager 100 may identify which Player Terminals are currently using
that application and send this message with a function (e.g.,
StartFlash( ) to execute. This function may have been previously
written to flash(/colorloop) the application button in the
panel.
[0212] Parameters:
TABLE-US-00065 WndID Window ID function String containing the
function to execute with parameters
Browser Manager to Appserver Messaging is Ready
[0213] This message is used by the Browser Manager 100 to query the
AppServer if it is online and ready to take on another player. The
AppServer needs to respond within a predefined amount of time
(ms).
Registerpt
[0214] After the Browser Manager 100 instructs the Player Terminal
to load an application, it sends the Registerpt message to the
AppServer to have it register/add the Player Terminal to its
list.
[0215] Parameters:
TABLE-US-00066 PT-ID Unique identifier for the PT. Player ID Player
tracking ID, if available.
Unregisterpt
[0216] At the end of a Player Terminal session, the Browser Manager
100 sends the Unregisterpt message to the AppServer to have it
unregister/remove the Player Terminal from its list.
[0217] Parameters:
TABLE-US-00067 PT-ID Unique identifier for the PT.
Updateptstatus
[0218] The Browser Manager 100 can use the Updateptstatus message
to the AppServer to update the status of the Player Terminal. For
example, if a Player Terminal goes down, Browser Manager 100
realizes the Player Terminal went offline and informs the AppServer
that the Player Terminal is offline using this message.
[0219] Parameters:
TABLE-US-00068 PT-ID Unique identifier for the PT. Player ID Player
tracking ID, if available. status Online/offline.
Appserver to Browser Manager Messaging--Register
[0220] This message is sent by the AppServer on startup to register
itself with the Browser Manager 100 and announce its
availability.
Heartbeat
[0221] The Heartbeat message is sent by the Player Terminal to the
Browser Manager 100, to inform Browser Manager that Player Terminal
is still alive.
Requestattention
[0222] The Requestattention message is sent by the AppServer to the
Browser Manager 100 to get the attention of any/all players using
the application. The Browser Manager 100 in turn may use the
ExecJavascriptFunction message to flash the application button in
the panels of the specified Player Terminal(s) currently using the
application. If a Player Terminal-ID is specified, the message may
be sent to the specified Player Terminal. If it is absent, the
message may be sent to all Player Terminals.
[0223] Parameters:
TABLE-US-00069 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT
Execjavascriptfunction
[0224] The Execjavascriptfunction message is sent by the AppServer
to the Browser Manager 100, to execute a Javascript function on the
page. If the Player Terminal-ID is present, Browser Manager 100 may
send the message to the specified Player Terminal. If the Player
Terminal-ID is absent, Browser Manager 100 may forward the message
to all Player Terminals. An example of this is when events occur at
the AppServer, and say it has a new total value that it needs to
have updated on every Player Terminals browser. It may send this
message to the Browser Manager 100 with a blank Player Terminal-ID
parameter and function string "updateTotal(total)." The Browser
Manager 100 may then send this message out to all the Player
Terminals who are running that application.
[0225] Parameters:
TABLE-US-00070 appid Unique ID identifying the application. PT-ID
Unique ID identifying the PT. Function String containing full
script function with parameters.
Newbrowserwindows
[0226] The Newbrowserwindows message may be sent by the AppServer
to the Browser Manager 100, to open a new browser window in the
CHILD_PANEL. For example, if the AppServer wants to popup a window
with a promotional page or have the user make some selections, it
could request the Browser Manager 100 to open a new browser window.
If no Player Terminal-ID is specified, the message may be sent to
all Player Terminals currently displaying the application.
[0227] The Z order may be relative to the Z order of the parent
window and may be in the range 2-ACTIVE_Z. The coordinates of the
new window may be contained by Browser Manager 100 to within the
panel of the parent application.
[0228] Parameters:
TABLE-US-00071 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID generated by the AppServer X Window Left Y
Window Top W Window Width H Window Height Z order Z order of the
window relative to parent window url URL the window needs to
display
Movebrowserwindows
[0229] The Movebrowserwindows message may be sent by the AppServer
to the Browser Manager 100, to reposition a browser window in the
CHILD_PANEL. The coordinates of the new window may be contained by
Browser Manager 100, to within the panel of the parent application.
If no Player Terminal-ID is specified, the message may be sent to
all Player Terminals currently displaying the application.
[0230] Parameters:
TABLE-US-00072 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID as determined by the AppServer X Window
Left Y Window Top W Window Width H Window Height
Setwindowsurls
[0231] The Setwindowsurls message is used to set the URL in the
Window ID specified. If no Player Terminal-ID is specified, the
message may be sent to all Player Terminals currently displaying
the application.
[0232] Parameters:
TABLE-US-00073 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID url URL the window needs to display
Showbrowserwindows
[0233] The Showbrowserwindows message is used to set the visibility
of the browser window. If no Player Terminal-ID is specified, the
message may be sent to all Player Terminals currently displaying
the application.
[0234] Parameters:
TABLE-US-00074 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID show Flag indicating whether the window is
to be shown or not
Setzorders
[0235] The Setzorders message is variable length depending on the
number of windows. If no Player Terminal-ID is specified, the
message may be sent to all Player Terminals currently displaying
the application.
[0236] Parameters:
TABLE-US-00075 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID Z order Z-order of window
Closebrowserwindows
[0237] The Closebrowserwindows message may be sent by the AppServer
to the Browser Manager 100, to close browser windows in the
CHILD_PANEL. If no Player Terminal-ID is specified, the message may
be sent to all Player Terminals displaying the application at that
moment.
[0238] Parameters:
TABLE-US-00076 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT NumWindows Number of windows [for each
window] WndID Window ID as determined by the AppServer
Startgame
[0239] The Startgame message is sent by the AppServer to Browser
Manager 100 to let it know a game indicated by gameID has
started.
[0240] Parameters:
TABLE-US-00077 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT gameID ID of the game
Endgame
[0241] The Endgame message is sent by the AppServer to Browser
Manager 100 to let it know a game indicated by gamelD has
ended.
[0242] Parameters:
TABLE-US-00078 appid Unique ID identifying the application PT-ID
Unique ID identifying the PT gameID ID of the game
[0243] The following are messages used to update the items
representing the AppServer in the Browser Manager's database.
Setdescription
[0244] The Setdescription message is sent by the AppServer to
Browser Manager 100 to set the description of the application in
Browser Manager's table `tblApps.`
[0245] Parameters:
TABLE-US-00079 appid Unique ID identifying the application
Description New description string to set in the table
Seticonurl
[0246] The Seticonurl message is sent by the AppServer to Browser
Manager 100 to set the URL of the icon representing it in the
Browser Manager's table `tblApps.`
[0247] Parameters:
TABLE-US-00080 appid Unique ID identifying the application IconURL
New URL of icon to set in the table
Seticontext
[0248] The Seticontext message is sent by the AppServer to Browser
Manager 100 to set the text of the icon representing it in the
Browser Manager table `tblApps.`
[0249] Parameters:
TABLE-US-00081 appid Unique ID identifying the application IconText
New icon text string to set in the table
Setappurl
[0250] The Setappurl message is sent by the AppServer to Browser
Manager 100 to set the URL of the application in the Browser
Manager table `tblApps.`
[0251] Parameters:
TABLE-US-00082 appid Unique ID identifying the application appURL
New URL that points to the live application to set in the table
Transaction Messaging Appserver to Transaction
Manager--Requesttransaction
[0252] This message is used by the AppServer to request the
TransactionMgr for a transaction with a specified Player
Terminal.
[0253] Parameters:
TABLE-US-00083 PT-ID Unique ID identifying the PT
TransactionRequestID Unique ID generated by the AppServer
identifying the Transaction request. The Transaction Manager 110
may use this in its response to the AppServer. TransactionType Type
of transaction, Debit, Credit Amount Money amount
Transaction Manager to Appserver--Transactionresponse
[0254] This message is used by the TransactionMgr to respond to
AppServer's RequestTransaction message.
[0255] Parameters:
TABLE-US-00084 TransactionRequestID Unique ID identifying the
Transaction request previously sent by the AppServer. Status
Completed, Denied
[0256] FIG. 12 illustrates a Browser Application entitled
SlotStats. SlotStats is a server application that generates a chart
based on game data of individual Player Terminal/electronic gaming
machines. The chart may be displayed on a browser window on the
Player Terminal.
[0257] When a game is played on a Player Terminal, the results
(e.g., money played, money won, games played, games won, and the
like) are sent to a server that records it in a database with a
timestamp. The amount of information to be sent/stored depends on
what is to be displayed. For example, the diagram below shows the
last 100 games played on the Player Terminal and certain wins have
icons displayed on them. This presentation uses just the MoneyWon
data field. Additionally, FIG. 1 displays the browser button
interface for the player to launch the SlotStats data viewer.
[0258] In one embodiment of the browser manager operating system,
GnuPlot, a freeware charting tool is used to generate charts via
several web sites (e.g., Yahoo Finance). Additional embodiments
have also implemented GnuPlot, MySQL and Apache. In one specific,
non-limiting embodiment, when a game ends, gamemgr sends the meter
data to a client program, which calls a PHP script on the server
with the data. The PHP script writes the data into a MySQL table
and sends a URL server://draw_chart.php back to the client program.
The client program instructs the browser to load the URL
server://draw_chart.php with some parameters. On the server side,
the draw_chart.php script runs the gnuplot program with the
parameters, generates the chart as a PNG image, and the output is
fed directly into the page. No images are saved on the server and
since the logic to generate the charts resides on the server, any
number of different presentations and styles could be used.
[0259] One operation that the GnuPlot is unable to do at the time
of writing is generate the icons on a plot. To accomplish this
operation, a feature request has to be sent to the GnuPlot project.
Alternate approaches could be used in other embodiments that
utilize MACROMEDIA FLASH, or other charting tools.
Player Initiated "View Base Game" Interface
[0260] Referring again to FIG. 1, in one embodiment of the browser
manager operating system and method 10, there is a button on the
task bar at the bottom of the display screen that reads "View Base
Game." This button enables a player to navigate back to the base
game screen upon his selection of the button. In this manner, a
player may recover the typical top monitor game art in either full
screen or in a panel at the top of the display screen.
Additionally, in one embodiment, the content may be maximized or
displayed within one of the browser windows on the top of the page,
in a Picture-in-Picture type format. Accordingly, a player may
select any button on the bottom task bar of FIG. 1 and take over
any browser window on the display screen (e.g., top, bottom, or
display content simultaneously over multiple windows).
Taskbar/Button Bar Minimization
[0261] Referring again to FIG. 1, in one embodiment of the browser
manager operating system and method 10, there is a button on the
task bar at the bottom of the display screen that reads "Min/Max
Window." This button may be utilized to either minimize or maximize
the selected active window on the display screen. In one
embodiment, this task bar may "auto-hide" itself after a period of
no user interfacing with the display screen or gaming machine base
game input/output (I/O).
[0262] Thus, the "Min/Max Window" button may be utilized to provide
a full screen view of the content on the upper portion of the
display screen. The ability of the task bar to auto-hide provides a
non-obstructed view of the browser content on the display screen.
The auto hide feature may be driven by the Browser Manager and may
be based upon business rules, data it receives from the gaming
machines, commands from the gaming machine or a back-end server, or
combinations thereof.
Base Game Capture Focus
[0263] In another embodiment of the browser manager operating
system and method 10, in a situation when the base game requires
focus on the top monitor to run an application (e.g., a bonus
round), the system enables the base game to take over the entire
screen or the top panel of the screen automatically. In one
embodiment, the content shown is rendered by native Linux graphics
technology (driven from the C++ Linux AGK or OS). In this regard,
the game knows its own game state and is capable of selectively
take control of an active window on the display screen. In one
embodiment, this is due to the game having master control as a
result of being a regulated gaming machine. Additionally, the game
may give up control of the active window on the display screen when
the game has completed its priority content (e.g., it is only
showing the game marquee logo).
Drag/Drop/Resize/Re-Position by Player
[0264] In one embodiment of the browser manager operating system
and method 10, the player has the ability to drag and drop the
browser windows in various positions around the display screen. In
one specific, non-limiting embodiment, this may be achieved by
using a player's finger to drag the windows. In such an embodiment,
this feature overrides the default browser or window configuration
of the Browser Manager. Additionally, in one embodiment, the player
has the ability to resize each window with controls that are
displayed around the corner of a window, upon selection of the
window by the player. In one embodiment, the content within the
window is scaled accordingly. Alternatively, the content in a
smaller window remains at the original size, and the player then
may only view a portion of the content in the smaller window at a
time. In such an embodiment, the player may slide the original size
content around within the smaller window using a hand/finger
gesture and a slider bar. Such an embodiment enables a player to
view the content in its original size and complexity, in comparison
to a scaled version of the content.
Save Browser State Per Player
[0265] In one embodiment of the browser manager operating system
and method 10, the browser window state, size, orientation may be
stored in a player-specific "Save State" account. In such an
embodiment, a player may visit another gaming machine (or the same
gaming machine) at a later time/day, and recover the browser state
information upon player identification at the gaming machine. This
may be achieved using system controls, biometric identification, a
player card reader attached to the gaming device or system control,
proximity detection of a player ID from a wireless PDK personal
digital key, a smart card, the player entering username/password or
casino player ID into the gaming device using a keyboard or
touchscreen, facial recognition, a ticket/voucher that is
associated with the player, or combinations thereof.
[0266] Once the browser state information is recovered, the entire
screen browser configuration may be set to the players preferred
presentation mode. In one embodiment, this is controlled by the
Browser Manager, which overrides the defaults for this specific
player. Preferably, the content is identical if the subsequent
visited game screen configuration-size-orientation is the same as
the previous one that was configured. If screen
orientations/sizes/resolutions are different on different gaming
machines, the Save State server can save the player browser
preferences for each of the various cabinet configurations.
Save Browser State Information for a Selected URL Per Player
[0267] In another embodiment of the browser manager operating
system and method 10, the "Save State" feature of the browser
windows may also save the XML string of the state of the HTML page
in that window. Thus, a third party server that is driving this
window may use the gaming machine manufacturer to maintain the
state of any content in the window by calling a javascript function
that the manufacturer provides to the third party. In this regard,
the XML string may be saved in the "Save State" server file of the
casino Browser Manager that is specific to this player. Such an
embodiment enables a patron to start a browser session at a
specific URL at another gaming machine with the same state where
the player left off on a previously used gaming machine.
[0268] For example, in one specific, non-limiting embodiment for an
e-commerce shopping application, a casino patron may add items to a
virtual shopping basket on one gaming machine, leave this gaming
machine, go to another gaming machine, and upon identifying himself
continue shopping right where the player left off on the previous
gaming machine. In an alternative embodiment, the third party
server may use a S2S (server to server) "Save State" message into
the manufacturer's "Save State" server to save any browser
state-related data it requires. In one embodiment, this is
preformed in XML format. In this regard, the gaming machine
manufacturer can return this data to the third party server once
the player is identified. The third party server may use this
recovered browser state data to update its web page state. This is
typically performed through AJAX (Asynchronous JavaScript and XML)
updates.
Browser Recovery to Normal State
[0269] In still another embodiment of the browser manager operating
system and method 10, when the player session ends (e.g., credits
go to zero for a period of time, or the player card is pulled) then
the browser content returns back to its original browser manager
controlled frames and sizes. This typically provides the base game
focus of the main portion of the top monitor. In yet another
embodiment, the Browser Manager or Z-order director server may
"auto-flip" through various content and URLs on the top monitor
including the natively-rendered, base game content.
Base Game Rendered Native Content
[0270] In one embodiment of the browser manager operating system
and method 10, the base game operating system may provide a HTML
page for the Browser Manager to render. This HTML page contains the
top box monitor content, such as the marquee artwork. It may have
animated graphics and data fields like paytables and progressives.
This data may be updated by AJAX and Dynamic HTML. In this manner,
the gaming machine operating system (e.g., an Alpha OS) also acts a
web server to provide the base game content to the browser window
running on the top display screen. These operating system HTML
pages may be pre-entered into the Browser Manager and may be
different for each gaming machine, since each machine has different
directory paths to its content.
Browser Window Transparency
[0271] In another embodiment, the browser manager operating system
and method 10 enables a player to select the level of transparency
for each browser window via the user interface. This enables the
player to see content on one browser window that is behind another
browser window. In this manner, the player may be sure to see all
of the information the player believes is important. For example,
the player may see an active keno game being played on the foremost
window and also watch the base game content in the second window
back that is completely or partially behind the front-most keno
window. In one embodiment, the player is provided a slider bar user
interface or dropdown user interface component to set the level of
transparency per window or for the level of transparency for all
windows. Alternatively, there may be a control panel user interface
that allows the player to configure all windows or specific windows
to the player's preferences. Additionally, this information can
also be saved in a player-centric database that may be recovered in
the player's next gaming session on the same or a different gaming
machine.
Picture-in-Picture
[0272] In one specific, non-limiting embodiment of the browser
manager operating system and method 10, a windows-based iVIEW
drives either a smaller iVIEW 640.times.240 window or the entire
top box display screen using MICROSOFT DIRECT X APIs, which are
contained in WINDOWS VISTA EMBEDDED. In other embodiments, other
components with equivalent functionality may be utilized. This
feature enables picture-in-picture functionality in conjunction
with variable browser window transparency, which is selectable by
the player and is savable in a central "Save State" server per
player and gaming machine configuration. Moreover, in some
embodiments, the Browser Manager also has the ability to configure
the transparency per window or for a group of windows.
[0273] While various embodiments have been described above, it
should be understood that they have been presented by way of
example only, and not limitation. Thus, the breadth and scope of a
disclosed embodiment should not be limited by any of the
above-described exemplary embodiments, but should be defined only
in accordance with the following claims and their equivalents.
* * * * *