OAC Proposal for a Common Player User Interface (PUI) May 24, 2010 Green Valley Ranch - Las Vegas, NV

Slide 2 Agenda  Operator Vision of the Future  Player User Interface Overview  GSA Protocols Supporting the PUI  PUI Functional Components  Questions – Comments - Discussion

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

Slide 4 Role of OAC in the GSA  To reinforce operator objectives within the GSA.  To obtain business requirements and course corrections from operators.  To assist in refining GSA architecture so that it provides value for operators.  To prioritize the business requirements to suite the industry’s needs.  To submit business requirements and priorities to the GSA board.

Slide 5 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 6 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 7 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.

Slide 8 Why the PUI? continued  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)  Operators need the ability to configure and control the PUI  Players need the ability to configure and control the PUI  Manufacturers need to build common PUI capabilities

Slide 9 PLAYER USER INTERFACE OVERVIEW Cornell Balagot - Oregon State Lottery (OSL)

Slide 10 Player User Interface  What is the Player User Interface?  A common application and method to communicate with players through a bi-directional display screen in an EGM  Although the PUI is integrated with the gaming environment, it is separate and distinct from the game

Slide 11 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 12 Player User Interface  Examples of 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 13 Player User Interface  Examples of what goes on the display  Informed Player (IP) Applications  View play histories  Set or change playing parameters  Pop up messaging when limits are exceeded  Hospitality Services  Order drinks  Make reservations  Find a restaurant

Slide 14 Use Cases  What is a Use Case?  A technique that describes how a system responds to a specific request through a series of descriptive steps  They describe the interaction between a player and the gaming system (via PUI)  They provide examples of kinds of information a player can request or receive through the PUI

Slide 15 Use Cases  We defined 22 gaming specific Use Case scenarios  Hundreds of specific cases could be described  Use Case Objectives  Use Cases are broad enough to cover undefined or future applications  Outcomes identify backend systems that need to be integrated in a PUI application

Slide 16 Player User Interface – Use Case  Use Case applications are grouped into 3 categories:  Gaming  Services  Player Management  This is just a starting point

Slide 17  Tournament Status  Description: Player wants to find out how he or she did in a tournament  Outcome: Player sees ranking on PUI Use Case Example PUI Control & Display Area

Slide 18 Gaming Use Case  Place Sports Wager  Description: A player wants to place a wager on a sporting event  Outcome: Player places a wager on a sporting event via Player User Interface

Slide 19 Service Use Case  Room Status Message  Description: Property wants to notify a player that his/her room is ready  Outcome: Player learns that their room is ready

Slide 20 Player Management Use Case  Player Tracking  Description: Player wants to check account balances and availability  Outcome: Player views balances and availability via Player User Interface

Slide 21 GSA PROTOCOLS SUPPORTING THE PUI Jeff Wyton

Slide 22 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 23 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 24 PLAYER USER INTERFACE FUNCTIONAL COMPONENTS Operator Perspective Klaus Peltsch – Ontario Lottery and Gaming Corporation (OLG)

Slide 25 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 26 Functional Overview of Components – Summary of requirements  Decoupled components – not tightly coupled proprietary  Integration with the EGM is based on GSA standards  Maximum flexibility for operator to interact with player  Player interface have no effect on game  Common player interface across all EGM’s  Content centrally managed  Operators able to create content  Session flows managed centrally  Low latency  Separate rules engine to isolate business rules  Information exposed and available in real-time

Slide 27 QUESTIONS - COMMENTS - DISCUSSION Jeff Wyton