OAC Proposal for a Common Player User Interface (PUI)May 24, 2010Green 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 PerspectiveKlaus Peltsch – Ontario Lottery and Gaming Corporation (OLG)

Slide 25

Functional Overview of Components

EGM

Player Session Manager

Player UI Platform

Player UI Presentation

Real-Time Events Stream

Data/Information Access

Player Rules Engine

Other Event Sources

1 2

3 4

5 6

• 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