BOB – S2S Overview May 25, 2004 Gaming Technology Summit

BOB – S2S Overview nWhat is BOB? nWhat is S2S? nBOB & S2S Message Handling nBOB Command Set – Version 1 nS2S Command Set – Version 1 nQuestions and Answers

What Is BOB? nBOB = Best Of Breed nCommunications between EGMs and back-end servers nDesigned to replace existing protocols nBased on current, proven technology standards; XML, TCP/IP, HTTP, etc nSupports high-speed communications by multiple back-end servers nConsists of three components: n BOB Message Standards – version 1 complete n BOB Transport Standards – HTTPS/SOAP complete n BOB Configuration Standards – in process

What Is S2S? nS2S – System To System nCommunications between back-end servers nBased on current, proven technology standards; XML, TCP/IP, HTTP, etc nSupports high-speed communications amongst back-end servers nDesigned to complement and support BOB nS2S and BOB use common message handling methodologies nConsists of two components: n S2S Message Standards – version 1 complete n S2S Transport Standards – in process

What Is BOB? What Is S2S? EGM Progressive Accounting Player Tracking Tickets BOB Kiosk Coin/Bill Counters S2S

BOB & S2S Message Handling nMessages are used to deliver one or more commands nCommands can be requests and/or responses nMany commands are organized into request-response pairs; two-way nOther commands do not require responses; one-way nMultiple unrelated commands can be bundled into a single message

BOB & S2S Message Handling Outbound Command Queue Inbound Command Queue Command Processor Inbound Command Queue Outbound Command Queue Command Processor 2. bobMessage 3. bobAck 1. Request4. Request 5. Response 6. bobMessage 7. bobAck 8. Response

BOB Command Set – Version 1 ndevice Class – used to identify the logical and physical devices contained in an EGM and to subscribe to the commands generated by a device. ncommunications Class – used to establish and maintain communications between an EGM and a back-end server. ncabinet Class – used to report the state of the cabinet and EGM access doors. nprocessor Class – used to report the state of the central processor and to set the themes, paytables and denominations offered by the EGM. nmeters Class – used to subscribe to and report performance, transfer, note and cabinet meters using onDemand, onPeriodic, onEvent, onChange, onAudit methods.

BOB Command Set – Version 1 ncoinAcceptor Class – used to configure and report the state of coin acceptors. nnoteAcceptor Class – used to configure and report the state of note acceptors. nhopper Class – used to configure and report the state of hoppers. nprinter Class – used to configure and report the state of printers and to print customized receipts. nhandpay Class – used to process jackpots and cancelled credit including remote jackpot key-offs.

BOB Command Set – Version 1 nprogressive Class – used to report and process progressive jackpot hits. nbonus Class – used to configure, report and process bonus awards. nplayer Class – used to configure and report player tracking events including countdowns, point awards, hot players, abandoned cards and direct messages. nvoucher class – used to process and report payment voucher (ticket) issuance and redemption. nWAT Class – used to process and report wagering account transfers. nGAT Class – used to process and report game authentication commands.

Messages SAS vs. XML BOB

Example of XML for meters

Client request and server response in XML <getPerformanceMeter denom="*" name="coinIn" payTable="" theme=""/>

BOB in the future: A Phased Approach nBOB – Phase 1 (XML Core) n Compatible with current protocol solutions n Includes basic player tracking functions nBOB – Phase 2 (Transport and Tools) n Toolkit for developers n Tools for compliance/approval testing n Physical layer (Ethernet), IP transport, addressing n Serial BOB nBOB – Phase 3 (Download) n Automated configuration n Download Games and Peripherals n Class II, Lottery and central determination message sets

S2S Command Set – Version 1 ncommunications Class – used to establish and maintain communications between back-end servers. nconfiguration Class – used to transmit application configuration data; employees, junkets, groups, clubs, chip sets, gaming tables, EGMs, comp items, etc. npatron Class – used to transmit patron registration and demographic data; mailing addresses, phone numbers, addresses, identification, images, comments, account balances, stop codes, etc. nopenClose Class – used to process table game openers and closers and to record periodic headcount and win/loss estimates. nfillCredit Class – used to process table game fills and credits.

S2S Command Set – Version 1 nmarker Class – used to process patron markers, redemptions, chip purchase vouchers and document transfers. nplayerRating Class – used to process player rating information for table games, EGMs, poker, bingo, keno, sports book and race book. njackpot Class – used to process table games progressive jackpots. ncomp Class – used to issue, redeem and void patron comps

BOB – S2S Overview

Regulatory Advisory Committee Mark Pace – RAC Chairman

RAC Committee Charter The GSA Regulatory Advisory Committee’s purpose is to ensure that all standards adopted by the Association are compliant with known jurisdictional requirements. In addition the committee will provide regulators access to GSA technology education and establish a forum in which regulators, manufacturers, systems providers and operators can collaborate to address industry issues.

RAC Committee nMechanism for open dialogue between Regulators and GSA n Regulators are unwilling to formally participate in GSA due to impartiality concerns n Regulators are eager to learn about what GSA is working on and to provide input n RAC chair has been positioned as the Regulator’s point of contact within GSA n Routine one-on-one calls to each Regulatory body has been effective in identifying their concerns, creating demand for detailed information on BOB, and making headway in having regulators seek the Association’s input.

RAC Committee Protocol Comparison Document

RAC Committee Sample Page from US Technical Requirements Document

RAC Committee 2004 Objectives ObjectivesTimeline Establish a mechanism to ensure a dialogue between GSA and regulators both audit and technical division Q1/2004 Write a white paper on GSA that speaks to the regulatorsQ1/2004 Create a protocol comparison document that conveys to regulators ‘at a glance’ the functionality each protocol has. Q1/2004 Design a document that lists all the US jurisdictional requirements. (GSA to support developing web interface to allow for on-line search for specific regulatory requirements etc.) Q1/2004 Obtain input into standards GDS, BOB and possibly S2SQ2/2004