Advancing the Player User Interface (PUI) March 2010 M Resort - Las Vegas, NV

Slide 2 OPERATOR & VENDOR DISCUSSION Facilitated by Jeff Wyton & Marc McDermott

Slide 3 Agenda  Why We’re Here  Operator Vision of the Future  Player User Interface Overview  GSA’s Protocols  Player User Interface Functional Components  Operator Vendor Discussion

Slide 4 Why We’re Here  The OAC wants:  To validate the direction with operators  To obtain additional input and course corrections from operators  Validation of the architecture

Slide 5 Why We’re Here  So Operators can:  Help prioritize the OAC’s business requirements to suit the industry’s needs  Provide additional business requirements that may have been omitted  Assist in refining the architecture so that it provides value for all operations

Slide 6 Why We’re Here  For Manufacturers to:  Leave with an understanding of the operator requirements  Understand operators’ requirements in order to facilitate translation into each manufacturer’s particular technologies

Slide 7 OPERATOR VISION OF THE FUTURE Introduction: Jeff Wyton – Alberta Gaming & Liquor Commission (AGLC)

Slide 8 OAC Vision 1.Explore commonality among gaming operators with respect to Business Needs. 2.The Operator Advisory committee facilitates collaboration between operators and manufacturers, system providers. 3.The committee focuses on functional business requirements to ensure that GSA standards meet market demands. 4.Increasingly we are exploring the use of common architectural components to accelerate adoption of jurisdictional requirements, lower costs, reduce implementation risk and increased speed to market

Slide 9 Business Drivers  Informed Player Choice  Unified Player View  Entertainment and Social Gaming  Changing Demographics  Cost Containment Strategies  Revenue Optimization  Flexibility, Integration and Speed to Market  Vendor and Product Landscape

Slide 10 The Services Concept  The Enterprise nature of many Gaming operations is driving interest in Service Oriented Architectures.  Lower testing/certification costs & faster testing (for vendor and customer) as only changed services need to be tested/certified in depth vs. whole monolithic application  Decreased development costs due to service reuse.  More responsive to customer demand (i.e. implementing a service or an improvement to a service vs an update to an entire monolithic app) Services must :  Be modular  Be distributable  Have interfaces that are clearly defined and documented  Have the ability to be swapped out for another module that offers the same service and interface  Have the ability to be shared across an Enterprise

Slide 11 Why the PUI?  Addressing our market drivers requires a new relationship with our players.  Competing requires that we enhance the current gaming experience through customization and personalization.  We require a method to communicate with our player in a bi- directional fashion.  The technology must scale across our enterprise to all appropriate customer facing touch points.  The solution must be common across the enterprise and manage a full range of player focused applications (i.e. RG, profile updates, bonuses, multi media etc)

Slide 12 PLAYER USER INTERFACE OVERVIEW Carole Hardy - Oregon State Lottery (OSL)

Slide 13 Player User Interface  What is the Player User Interface?  A common application and method to communicate with players through the display screen in an EGM  The application will use machine peripherals (touch screen, card reader, printer)  A second screen is not a primary option (e.g. kiosk)

Slide 14 Player User Interface  What the PUI does for an operator  Enables the integration and synergy between different vertical businesses in a Casino and Lottery  Gaming products  Food, beverage, hotel services  Loyalty programs

Slide 15 Player User Interface  What goes on the display?  Mystery games, bonuses and progressives  May or may not have links to the main game  Tournaments  Leader Board  Social Gaming  Interactive games

Slide 16 Player User Interface  What goes on the display? (cont)  Another game independent of the EGM  Bingo, sports wager  Up-selling other gaming products  Streaming live video  Amber alerts

Slide 17 Player User Interface  What goes on the display? (cont)  Player Self Serve  Player notification  Hospitality services  Order drinks  Make reservations  Find a restaurant

Slide 18 Player User Interface  What goes on the display? (cont)  Manage Player accounts  Access “E” wallet  Winning number list (Lottery)  Sports or odds lists  Gaming tutorials

Slide 19 Player User Interface  What goes on the display? (cont)  Player tracking  Player loyalty  Advertising  Targeted advertising  3 rd party  On site casino or Lottery operator

Slide 20 Player User Interface  What goes on the display? (cont)  Informed Player (IP) Applications  View play histories  Set or change playing parameters  Pop up messaging when limits are exceeded

Slide 21 Player User Interface  What operators have discussed over the past 12 months  We want to communicate and collect information while a player is at a slot/VLT  We believe the solution should use computer industry standards and web browser technology  The solution needs to be configurable

Slide 22 Player User Interface  What operators have discussed over the past 12 months  Game integrity must not be compromised  There needs to be a distinct separation between a game and the content displayed on the PUI  We want a solution that all suppliers can support

Slide 23 Some Discussion?  What do we think so far?  Questions or comments?

Slide 24 GSA PROTOCOLS Ethan Tower – Protocol Director GSA

Slide 25 GSA Protocols  GSA Protocols Relevant to the Player User Interface  GDS – communications between an EGM and its peripherals.  touch-screen, card-reader, and printer protocols.  G2S – communications between an EGM and host systems.  G2S message bar requirements and mediaDisplay class.  S2S – communications between a client application and a host system.  playerInfo, playerComp, and informedPlayer classes.

Slide 26 mediaDisplay Class  Initial effort to provide a standard method for controlling application windows on an EGM.  Specifies the position and behavioral characteristics of the window.  Provides a mechanism for loading the content displayed in the window.  Provides a mechanism for communications between the content and the EGM.  Provides a mechanism for communications between the content and back-end servers.

Slide 27 G2S and GDS Interactions G2S Host EGM Control Logic G2S GDS Device GDS

Slide 28 mediaDisplay Interactions G2S Host EGM mediaDisplay Device EGM Control Logic G2S Under G2S Control GDS Device GDS Content

Slide 29 Content Interactions G2S Host EGM Application Server Application Server mediaDisplay Device Content EGM Control Logic G2S mediaDisplay Interface S2SOther Methods Under G2S Control G2S GDS Device GDS

Slide 30 PLAYER USER INTERFACE FUNCTIONAL COMPONENTS Operator Perspective Brian Macsymic – Alberta Gaming & Liquor Commission (AGLC)

Slide 31 Functional Overview of Components All systems which manage player interaction can be mapped to this component model As the gaming standards are advanced, these components provide the context to capture and debate the requirements

Slide 32 Functional Overview of Components The functional components can be redrawn as required to fit any discussion This diagram arranges the components to fit this OAC Player UI standards discussion

Slide Player UI Platform – (OAC 25)  The Player UI Platform manages the hardware I/O at the EGM and creates a universal operating environment for the system

Slide Player UI Presentation – (OAC 26)  The Player UI Presentation component provides the rich dynamic content to the player. Compelling media content is delivered to the player creating the exciting visual experience

Slide Player Session Manager – (OAC 27)  The Player Session Manager is the key component which controls the process and data flow of all sessions from beginning to end. It is the engine that drives the implementation of player services

Slide Player Rules Engine – (OAC 28)  The Player Rules Engine component separates the governing rules for a player session from the session management application code.

Slide Real-Time Events Stream – (OAC 29)  The Real-Time Events Stream provides the secure and comprehensive bi-directional communications between systems and games.

Slide Data/Information Access – (OAC 30)  The Data/Information Access component provides an enterprise view of all data regardless of where it is stored

Slide 39 Breaktime  Let’s take a 20 minute break!

Slide 40 So Why Are We Here Again?  The OAC wants:  To validate the direction with operators  To obtain additional input and course corrections from operators  Validation of the architecture

Slide 41 So Why Are We Here Again?  So Operators can:  Help prioritize the OAC’s business requirements to suite the industry’s needs  Provide additional business requirements that may have been omitted  Assist in refining the architecture so that it provides value for all operations

Slide 42 So Why Are We Here Again?  For Manufacturers to:  Leave with an understanding of the operator requirements  Understand operators’ requirements in order to facilitate translation into each manufacturer’s particular technologies

Slide 43 Discussion Areas  Comments on the functional components of the PUI?  Discussion of major components flow  How do we achieve a common look and feel across all EGMs?  What does configurable mean?  What development environment options are available for operators to develop content?  Areas for further opportunities

Slide 44 Questions?  Questions?

Slide 45 Detailed View  Four Player UI configurations options are shown  Each configuration could operate in a single environment  The game environment is transparent to the system.  Integration with the gaming devices is done securely through the backend systems, maintaining a separation of concerns