Note: Descriptions are shown in the official language in which they were submitted.
CA 02486310 2004-10-29
SYSTEM AND METHOD FOR
OFFERING AWARDS TO PATRONS OF AN ESTABLISHMENT
FIELD OF THE INVENTION
s The present invention relates generally to computerized business information
processing systems, and more particularly to computerized business information
processing systems to enable intelligent patron awarding.
BACKGROUND OF THE INVENTION
to Businesses engage in marketing of their goods and services both to augment
relationships with existing customers and to establish relationships with new
customers. In order to ensure that marketing resources are expended
productively,
marketing campaigns are ideally only to existing customers and to those
entities
reasonably likely to become customers.
~ s Many businesses do not maintain a comprehensive repository or database of
customer transaction history, and hence lack knowledge of customer
demographics
and purchasing trends which could potentially be leveraged in developing
effective
marketing programs. Although other businesses may maintain detailed records of
customer activity, many businesses nonetheless remain largely incapable of
2o developing sophisticated marketing offers and campaigns likely to be
attractive to
both existing and potential customers. This is often because the task of
gleaning
useful information from the often voluminous records of customer activity has
proven
to be difficult. Moreover, even when promotional campaigns are formulated
using
existing customer databases, businesses are often unable to readily estimate
the
2s effectiveness of the promotional campaign. Similarly, it is also often
difficult to
discern change in the behavior of various demographic groups of customers,
which
precludes formulation of effective promotional campaigns.
As a consequence of the foregoing, decisions regarding marketing and
promotional programs are often made primarily on the basis of the experience
and
3o inclination of marketing personnel. As a consequence, substantial marketing
resources may be allocated based upon decisions which do not leverage historic
transactional and other empirical data. This may lead to substantial waste of
CA 02486310 2004-10-29
marketing resources, since such resources may then become directed to
population
groups in which only a relatively small fraction of the group's members are
actually
interested in the product or service being marketed.
s SUMMARY OF THE INVENTION
The present invention pertains to a computer-implemented system and method
for selecting awards to be offered to patrons of an establishment. The
inventive
system is configured to: maintain a patron database storing patron information
relating to a plurality of patrons and historical transaction information
involving said
t o patrons; monitor substantially current transaction activity of at least a
first patron of
said plurality of patrons; assign a profile to said first patron based at
least upon
portions of said historical transaction information pertinent to said first
patron and
said current transaction activity; and match an award to said profile.
In one aspect, the present invention relates to a method of award offering.
The
t s method includes maintaining a patron database storing patron information
relating to
a plurality of patrons of an establishment and historical transaction
information
involving the patrons. The method also includes monitoring substantially
current
transaction activity of the plurality of patrons, and regularly assigning
profiles to the
plurality of patrons based upon said historical transaction information and
said current
2o transaction activity. The method further includes matching awards to ones
of said
profiles; and offering said awards to ones of said plurality of patrons
assigned to said
ones of said profiles.
In another aspect the present invention pertains to a method of award
offering.
The method includes receiving a description of an award. The award is
associated
zs with a profile assigned to a patron of an establishment based at least in
part upon
substantially real-time transaction activity of said patron. The method also
includes
receiving a script containing information relating to conveyance of said
award; and
offering said award to said patron and conveying said information.
In yet a further aspect the present invention pertains to a computer-
3o implemented patron award system. The award system includes a patron
database in
which is maintained patron information relating to a plurality of patrons and
historical
transaction information involving said patrons. The ward system also includes
a
2
CA 02486310 2004-10-29
current activity database for storing substantially current transaction
activity
information for said plurality of patrons, and a server unit operatively
connected to
said patron database and said current activity database. The central server
includes a
processor and a memory associated with the processor. The memory further
includes:
s a profile assignment module executable by said processor. The profile
assignment
module being disposed to regularly assign profiles to said plurality of
patrons. The
memory also includes an award matching module executable by the processor,
which
operates to match awards to ones of said profiles.
to BRIEF DESCRIPTION OF THE DRAWINGS
For a better understanding of the nature of the features of the invention,
reference should be made to the following detailed description taken in
conjunction
with the accompanying drawings, in which:
FIG. 1 provides an overview of a computing environment in which a patron
t s bonusing system of the present invention may be embodied.
FIG. 2 is a schematic diagram of the structure of a central server included
within the system of FIG. 1.
FIG. 3 provides a schematic representation of a user computer included within
the system of FIG. 1.
2o FIG. 4 is a data flow diagram illustrating the interaction among various
functional components comprising an exemplary embodiment of the system of FIG.
1.
FIG. 5 is a data flow diagram which depicts the cooperation between various
functional components of the system of FIG. 1 in effecting a data extraction,
transformation and load process.
2s FIG. 6 provides a flowchart representing a high-level sequence of
operations
performed in connection with creating a promotional campaign.
FIG. 7 is a flowchart representative of a Segment creation process.
FIG. 8 is a flowchart representative of an Offer creation process.
FIG. 9 is a flowchart illustrating a campaign creation process.
3o FIG. 10 is a flowchart illustrating a data visualization process.
3
CA 02486310 2004-10-29
FIG. 11 provides a simplified illustrative representation of certain aspects
of
the structure and function of a Player Contact System (PCS) module relative to
other
system components.
FIG. 12 is a flowchart illustrating the operation of the player contact
system.
s FIG. 13 is a flowchart illustrating the operations involved in making calls
upon patrons, the scheduling of such calls, and the definition of associations
between
patrons.
FIG. 14 is a flowchart of an exemplary statistical analysis routine which may
be employed in connection with the analysis of data accumulated by the player
i o contact system of the invention.
FIG. 15 is a flowchart illustrating a patron locator and data visualization
process pertinent to the player contact system.
FIG. 16 is an overview of a computing environment in which a PCS bonusing
system of the present invention may be embodied.
~s FIG. 17 is a data flow diagram illustrating the interaction among various
functional components comprising an exemplary embodiment of the PCS bonusing
system of FIG. 16.
FIG. 18, which is a flowchart illustrating steps carried out by the PCS
bonusing system of FIG. 16 according to an exemplary embodiment.
2o FIGS. 19 - 51 depict various user interface windows displayed during
interaction with the campaign management system.
FIGS. 52 - 76 depict various user interface windows displayed during
interaction with the player contact system.
2s DETAILED DESCRIPTION OF THE INVENTION
I. SUMMARY OVERVIEW
The present invention relates to a patron bonusing system capable of being
utilized by users of a commercial establishment (e.g., the staff of a casino)
to provide
so bonuses to patrons based upon both the patrons' historical and
substantially current
transaction activity while the patrons are within the establishment. Although
the
exemplary embodiment of the inventive bonusing system described herein is
adapted
4
CA 02486310 2004-10-29
to the casino industry, the inventive system can be readily applied to other
types of
business concerns.
In order to more fully appreciate the inventive patron bonusing system, a
description is first provided of a business information processing system,
which is the
s subject matter of U.S. patent application Serial No. 10/406,561, filed on
4/3/03,
entitled SYSTEM AND METHOD FOR CUSTOMER CONTACT
MANAGEMENT.
The business information processing system is configured to transform and
integrate data from various transactional systems into a central data
warehouse. The
t o data integrated within the central data warehouse is accessible to various
applications
designed to work in concert to improve and manage marketing and business
intelligence activities. In the exemplary embodiment the transactional systems
providing information to the central data warehouse are operated or controlled
by a
casino or other gaming establishment, within which a number of gaming machines
are
~ s located in one or more rooms of a facility. In accordance with one aspect
of the
business information processing system, data extracted from the transactional
systems
is transformed in a predefined manner and used to populate designated fields
in the
data warehouse.
As is described below, the business information processing system retains
2o contact information for patrons registered with a particular gaming
establishment, and
also tracks the preferences of these patrons. Such preferences may include,
for
example, stated preferences with regard to particular casino games, leisure
activities,
and offers redeemed. In addition to recording stated preferences, the system
determines actual preferences based upon data included within the data
warehouse.
2s Based on these preferences, managers employed by the gaming establishment
may
create reports listing patrons sharing a common preference (e.g., interest in
professional football) and assign hosts to contact the listed patrons. Other
types of
reports could reveal which customers have not visited the gaming establishment
since
a given date, or which "VIP" customers have not been assigned a host. This
enables
3o the gaming establishment to ensure that appropriate levels of its customer
service
resources are directed to its most valued patrons.
CA 02486310 2004-10-29
The business information processing system may be applied in connection
with, for example, (1) designing, managing and analyzing customer contact via
a
contact management system designed for the casino hospitality industry, (2)
provision
of visual representations of geographic distributions of selected segments of
patrons
s associated with particular merchants or gaming establishments, (3) provision
of
relational and mufti-dimensional representations of attribute data for the
purpose of
data access, mining, modeling, predictive modeling, and other analysis, and
(4)
formulation of mufti-dimensional database queries requiring no actual
knowledge of
applicable mufti-dimensional query languages (e.g., MDX). As is described
~ o hereinafter, the synergistic interactivity of the constituent modules of
the inventive
system leads to significant improvements in functionality relative to existing
approaches to computerized business information processing.
II. GENERAL SYSTEM ARCHITEC'TLTRE & FUNCTIONALITY
~ s An overview of a computing environment in which the business information
processing system 100 may be embodied is shown in FIG. 1. As discussed further
herein, the business processing system 100 is capable of implementing a patron
bonusing system in accordance with the present invention. In the environment
of
FIG. 1, the system 100 is implemented using a central server 104 disposed to
interface
2o with transactional databases 108, a patron contact system (PCS) database
112, a
customer management system (CMS) database 116, and with one or more user
computers 120. The central server 104 communicates with the transactional
databases
108, PCS database 112, CMS database 116 and user computers 120 over a computer
network 124 (e.g., the Internet or a local area network (LAN)). The
transactional
2s databases 108 will often include data representative of the interaction
between
customers and merchants. In certain cases this data may be culled from
existing
customer databases, merchant loyalty programs, and/or promotional data. In
exemplary implementations of the system 100, the transactional databases 108
may
include a casino management system, slot accounting system, hotel/property
3o management system, retail or point-of sale (POS) system, and golf and
events
management systems. In alternate implementations yet other sources of data may
also
6
CA 02486310 2004-10-29
be tapped as necessary to facilitate additional functionality (e.g., third
party databases
containing demographic or geographic data, census data, and the like).
FIG. 2 is a schematic diagram of the structure of the central server 104. The
central server 104 includes a CPU 202 connected to RAM 204, ROM 208, a network
s communication module 210 and secondary data storage 212. Included within
secondary data storage 212 are a PCS module 216, a CMS module 220, a data
visualization module 222, a report writer module 224, a data warehouse 226 and
mufti-dimensional data storage 228. Secondary data storage also includes a
copy of
the operating system for the server 104 (not shown), data transformation
services 232
to and a dimension builder 236 disposed to operate upon the contents of the
legacy
transactional databases and the data warehouse 226, respectively. When
effecting the
functionality described below, the CPU 202 loads into RAM 204 and executes one
or
more of the program modules stored within secondary data storage 212.
A schematic representation of a user computer 120 is provided by FIG. 3. As
t s shown, the user computer 120 includes a CPU 302 connected to RAM 304, ROM
308
and hard disk storage device 312 containing a copy of the operating system
(not
shown) for the computer 120. The storage device 312 further includes a PCS
client
module 350, a CMS client module 354 and a data visualization client module
360, the
operation of each of which is described hereinafter. The CPU 302 is also
operatively
2o connected to an input device 318 and to a display device 320 through which
a user
may communicate with user computer 120. Communication with the central server
104 via computer network 124 is facilitated by a network interface module 324,
which
may comprise a network interface card when user computer 120 is utilized in a
LAN
networking environment and a modem or the like when user computer 120
interfaces
2s directly with the Internet. The functionality of the system 100 may be
accessed by
users (e.g., operators of casinos) via one of the user computers 120. In
certain
implementations the user computer 120 rnay comprise a portable wireless
device,
such as a handheld computer or personal digital assistant.
FIG. 4 is a data flow diagram illustrating the interaction among various
so functional components comprising an exemplary embodiment of the system 100.
As
is described further below with reference to FIG. 5, data transformation
services 232
serve to transform data from the transactional databases 108 prior to storage
within
7
CA 02486310 2004-10-29
the data warehouse 226. In the case in which the system 100 is configured to
be
utilized in the context of a casino or the like, the transactional databases
are seen to
include a slot accounting database component 420, a patron tracking database
component 424, and a hotel database component 426.
s As shown, system stored procedures 440 function to supply data from the
warehouse 226 that is required by the PCS database 112 and the CMS database
116.
The dimension builder 236 also functions to generate a plurality of mufti-
dimensional
data representations (cubes) based upon the contents of the data warehouse
226, and
to store such representations within the mufti-dimensional data storage 228.
The
to report writer module 224 draws upon the contents of the mufti-dimensional
data
storage 228 in generating reports of desired complexity (e.g., from simple,
transactional-based reports to more complex "drill-down" reports). In
addition, a
SQL report writer 244 is configured to generate reports based upon the "flat"
table
structures of the data warehouse 226 described below.
~ s As may be appreciated by reference to FIGS 2-4, the data flow and
functionality described with reference to FIG. 4 may be effected by various
combinations of modules and elements disposed at the user computers 102 and
central
server 104. The precise division of functionality between the modules within
the user
computers 120 (e.g., the PCS client module 350 and the CMS client module 354)
and
2o the modules within the central server 104 is not critical to the present
system, and
variations of the system may be predicated upon different distributions of
functionality between the central server 104 and the user computers 102.
Accordingly, references in the description below to the modules within the
central
server 104 (e.g., the PCS module 216 and the CMS module 220) are not
necessarily
2s intended to be directed exclusively to such modules, and should be
construed as being
applicable to embodiments in which the relevant functionality is implemented
in
cooperation with complementary modules disposed within the user computers 102.
FIG. 19 shows a user interface window 1900 presented to a user when
initiating interaction with a promotional campaign under development using the
CMS
3o module 220. As shown, a General tab 1910 has been selected in the view of
FIG. 19.
Other tabs (described below) capable of being selected from the window 1900
include
a Segments tab 1912, Offers tab 1916, Expenses tab 1918, Summary tab 1920,
Forma
8
CA 02486310 2004-10-29
tab 1922, Export Lists tab 1924 and a Map tab 1928. The window 1900 also shows
certain parameters of the campaign which have been previously selected. For
example, a Start Date 1940 is indicated, as well as a Description 1944 and
Campaign
Name 1948.
s Turning now to FIG. 20, there is shown a user interface window 2000
displayed upon invoking the functionality of the PCS module 216. The user
interface
window 2000 includes a primary pane 2010 depicting a map of a casino floor. As
shown, a user has positioned a mouse pointer 2014 proximate the location of a
particular patron. Using a customer identifier or the equivalent, the PCS
module 216
retrieves data such as, for example, the name (i.e., "Dorothy Player") from
memory
and superimposes this information on the pane 2010.
III. EXTRACTION, TRANSFORMATION & LOAD PROCESS
FIG. 5 is a data flow diagram which depicts the cooperation between various
functional components of the system 100 in effecting a data extraction,
transformation
~ s and load (ETL) process 500. It is assumed that data is collected and
compiled within
the transactional database 108 using conventional techniques. For example, in
the
gaming industry it is common for patrons to be issued a patron identification
card
encoded with a patron identification number uniquely identifying the patron.
Within
the casino or other gaming area, individual gaming devices are fitted with a
card
2o reader, into which the patron inserts the patron tracking card prior to
playing the
associated gaming device. The card reader reads the patron identification
number off
the card and informs a central computer of the patron's subsequent gaming
activity.
This enables individual patron usage to be monitored by associating dated
records
from the gaming device with patron identification numbers. As a patron
interacts
2s with a gaming device andlor visits a hotel, interaction or other
transactional data is
generated, collected and stored within the transactional database 108. The
collected
data could be stored within a number of records within a relational database
structure
of the transactional database 108. Each record may include, for example, a
customer
identifier associated with a particular patron identification card.
3o In certain exemplary implementations the ETL process S00 is conducted at
least once daily, and automatically copies data from the transactional
database 108
into the data warehouse 226. Specifically, based upon the pertinent fields
within the
9
CA 02486310 2004-10-29
database components 420, 424, 426 of the transactional database 108, a data
transformation service (DTS) package 510 is developed so as to enable
extraction of
each of the pertinent fields from the various transactional databases (e.g.,
the
databases 420, 424 and 426). The content of these fields are assembled into
staging
s tables 514, at which point various data validation or integrity operations
518 are
performed. Such operations could comprise, for example, validating that a
field
expected to contain a date does in fact contain information formatted
consistently with
a date, or confirming that a field expected to contain zip code information
does in fact
contain a valid zip code. The validated data may then be used as the basis for
a
to variety of data transformation operations 520. For example, new fields may
be
computed based on the validated data that do not exist within the
transactional
databases 108 (e.g., a profit margin field could be created on the basis of
revenue and
cost information fields). Data from external sources could also be appended as
part of
the data transformation operations 520. In any event, the resultant
transformed data is
is then used to update 524 the data warehouse 226, which stores the table
structures
created pursuant to the preceding operations.
In the embodiment of FIG. 5 the data within the warehouse 226 is organized
on the basis of a plurality of dimensions (e.g., age, gender, time). Data
associated
with ones of these dimensions is then assembled into cubes and stored within
the
2o mufti-dimensional data store 228. Various on-line analytical processing
(OLAP)
services 540 may also be developed in order to provide an interface through
which
users may transform or limit the raw data within the data stores 228 in
accordance
with user-defined or pre-defined functions, and quickly and interactively
examine the
results in various dimensions of the data. The OLAP services 540 may also be
used
2s in performing predictive modeling and reporting 546 in the manner described
hereinafter.
IV. CAMPAIGN MANAGEMENT SYSTEM (CMS)
A. Overview
The CMS module 220 and CMS client module 354 are designed to
3o cooperatively function as a tool for the creation, management and analysis
of multi
channel marketing campaigns. As is described below, marketing campaigns
consist
of one or more offers directed to a particular segment of patrons (e.g.,
players),
CA 02486310 2004-10-29
hereinafter referred to as a "Segment" or a "Segment population". Campaigns
are
distributed in a predefined format by way of one or more selected distribution
channels. In the exemplary embodiment, the CMS module 220 facilitates the use
of
MDX in order to substantively improve response times for Segment calculations.
The
s CMS module 220 then converts the MDX query into a SQL query when the actual
list
of individual records required for export and campaign execution is
identified. The
expense worksheet, proforma and analysis functions, along with the integration
with
the mapping and PCS systems are also believed to be unique. Each of the
elements of
a marketing campaign are described in further detail below. In these
descriptions
io reference may be made to FIG. 6, which illustratively represents certain
aspects of the
structure and function of the CMS module 216 with reference to other
components of
the system 100.
As is discussed below, the campaign management system is configured to
facilitate the targeting of appropriate Offers to specified Segment
populations. For
is example, the system enables definition of a Segment corresponding to those
"platinum" patrons which spend at least $100 per trip at the applicable gaming
establishment. In addition, Offers such as free meals or rooms may be defined.
A
campaign is then constructed at least in part based upon Offers and Segment
definitions such as these, and an estimate of the results of one or more
potential
zo campaigns is then generated. The results of each potential campaign may
then be
analyzed, and Offer and Segment definitions adjusted accordingly until a
desired
return-on-investment (ROI) is attained. Once a campaign has been selected and
initiated, the actual performance of the campaign may be evaluated through the
tracking of spending and other activity ancillary to the redemption of Offers.
zs FIG. 6 provides a flowchart 600 representing a high-level sequence of
operations performed in connection with creating a promotional campaign.
Commercial entities may elect to conduct promotional campaigns in order to
attract
additional business from existing customers and/or to attract new customers or
patrons. As shown at 610, a user initiates creation of a promotional campaign
by
3o defining one or more Segment populations, which are then stored by the
system as
corresponding Segment definitions. The campaign creation process also involves
defining one or more Offers and storing corresponding Offer parameters (step
620).
11
CA 02486310 2004-10-29
Appropriate formats for distributing the details of the offers are also
selected and the
resulting selections are also stored (step 630). In addition, profiles of
vendors capable
of distributing the defined Offers in the selected formats are defined (step
640). Once
these definitions and selections have been made, the promotional campaign may
be
s created in the manner described hereinafter (step 650). The expected results
of the
campaign may be analyzed during development of the campaign, and the actual
results analyzed following its execution (step 660).
B. Segments
The group of customers or patrons included within a Segment population each
to meet a specific set of criteria defined by a Segment definition. The user
defines
Segments for use in developing current or subsequent promotional campaigns.
Segments are expected to typically be selected based upon characteristics such
as age,
gender, geographic location and other demographic criteria or patron
characteristics.
Segment definitions may also be inclusive of those patrons for which
transaction
~ s histories have not been stored by the applicable merchant. Accordingly,
the term
"patrons" or "players" as used in the specification includes patrons and
potential
patrons, whether or not registered with a particular merchant or gaming
establishment.
In an exemplary implementation of the system 100, Segments are defined
using a Segment definition "wizard" (step 604 of FIG. 6). The wizard is in the
form
zo of a graphical user interface (GUI) that provides any easy to use and
understand
interface for creating complex MDX queries based on measures (data sets that
describe attributes of a patron, such as gender, theoretical win, ete.)
available in the
data warehouse 226. Once a Segment is created, it must later be associated
with a
campaign (described below). Segments, once defined, are characterized by a
Segment
2s profile 612 defined by attributes such as size, worth, average trip
theoretical win, etc.
As the Segment definition is manipulated, the CMS module 220 modifies the MDX
query that describes the Segment to reflect the changes and uses that query
definition
to calculate the Segment attribute values. Additionally, as a Segment is
associated
with various campaigns, the Segment MDX query definition is converted to a SQL
3o query definition so that the records that, in aggregate, make up the
Segment can be
extracted from the data warehouse 226 for the purpose of creating distribution
lists in
a format consistent with the format required for the channels) and vendors)
12
CA 02486310 2004-10-29
associated with the Segment. The use of MDX to query aggregated data in the
data
warehouse 226 greatly increases the speed of the query, thereby enabling a
user to
determine the effectiveness of the Segment definition more quickly than if the
query
were run against a traditional record set within a relational database. This
timely
s feedback allows greater agility in the Segment definition process, and
better ensures
accurate and effective segmentation.
Referring now to FIG. 21, there is illustrated a user interface window 2100
through which a user may edit previously defined Segments and create new
Segments. The window 2100 is accessed by selecting the Segments tab 1912 of
t o window 1900 (FIG. 19). In certain embodiments a tree structure (not shown)
may be
displayed upon selection of the Segments tab 1912. Through such a tree
structure or
the like a user may open an exiting Segment to view and/or edit, create a new
Segment, rename one or more Segments, and/or create or rename folders to
manage
and organize existing Segments. In general, the window 2100 enables users to
define
~ s a group of customers having characteristics comporting with various user-
defined
criterion. Through use of table-driven query builder, users may define
relatively
complex Segment definitions using the intuitive drop-down menu design of the
user
interface window 2100. For more robust queries, selection of a Query Design
Tool
button 2110 displays a design tool interface through which a user may fine-
tune, edit,
2o and test more complicated queries.
Segments may be stored and re-used in connection with future promotional
campaigns. Such re-used is facilitated through inclusion, within a Criteria
Period
sub-panel 2112 included in a Segment Dimensions panel 2121, of a Start Date
ZI16
and an End Date 2120 field designed to enable users to indicate a desired
criteria
2s period without entering specific dates. For example, in one embodiment the
End Date
field 2120 is set by default at the current date, and the Start Date 2116 is
set by
default to three months prior to the current date. Accordingly, a Segment can
be
defined once and used simultaneously in several campaigns, since the actual
start/end
dates characterizing the Segment will vary depending upon when the campaign is
3o actually conducted.
In addition to the Segment Dimensions panel 2121, the window 2100 includes
a General panel 2130, a Segments Spec panel 2154 and a Formula panel 2138. In
the
13
CA 02486310 2004-10-29
embodiment of FIG. 18 the Formula panel 2138 is populated in real-time with
pseudo-code of the SQL query corresponding to the Segment definition criteria
entered by the user. The fields of the General panel 2130 and additional
details
regarding the fields of the Segment Dimensions panel 2121 are described below
in
s Tables I and II, respectively.
TABLE I
Field of General Descri lion
Panel
Name The user enters a name and that name
is tested against the data
warehouse 226 for uniqueness only when
the user attempts to save
the Segment definition.
Description This field is used to provide a brief
description of the Segment.
I o TABLE II
Field of SegmentDescription
Dimensions Panel
Criteria Period This panel allows the user to define the
date range for the Segment.
Sub-Panel The date range is dynamic, and statistics
based on the associated
date range are updated within the campaign
that the Segment is being
used each time the Segment is recalculated.
For example, if a user
selects start date is 3 months before
today, then the query uses the
current date and the 3 months prior to
the current date whenever this
Segment is calculated.
By DayIBy Month The user selects whether it is desired
that the Start Date begin either
'x' number of days, or'x' number of months,
prior to the End Date.
Start Date The displayed Start Date will be equal
to the End Date less the
specified number of dayslmonths prior
to the End Date. The Start
Date will also be updated upon pressing
CALC. If the Segment is
newly defined, the Start Date will display
"undefined" until the CALC
button is pressed. The Start Date cannot
be before the End Date.
End Date In the case of a previously defined Segment,
the End Date will be
displayed as the date at which the Segment
was last calculated. If
the Segment is newly defined, the End
Date will be displayed as
"undefined" until the CACL button is pressed.
The End Date cannot
be greater than the current date.
Text Field The "Start Date is..." field allows the
user to define the date range of
the applicable Segment by entering the
number of days or months
prior to the End Date corresponding to
the Start Date.
In the embodiment of FIG.. 5 the Segment Specs panel 2154 serves as an
interface to a read-only table populated by the data warehouse 226.
Specifically, the
data warehouse 226 populates this table with information relevant to a
specified
I s Segment based on the query results from the warehouse 226. If a user
desires to
recalculate the table information (for example, in response to a change in the
dates the
14
CA 02486310 2004-10-29
Criteria Period sub-panel 2112), then the user may select a CALC button 2152
in
order to display the new results or statistics. The results may be made to
appear in a
predefined color (e.g., red) in cases in which the applicable Segment has
never been
calculated (or has not been calculated for more than a predefined period of
time, such
s as two weeks), thus indicating that the displayed statistical information or
results may
be inaccurate.
Again refernng to FIG. 21, the user interface window 2100 is also illustrated
as including a SAVE button 2170 and a CLOSE button 2174, the functionality of
each
being described below in Table III.
to
TABLE III
Button Descri tion
SAVE Upon pressing SAVE, a document validation routine
checks to ensure that all
fields are filled with valid information. If
so, the Segment will be saved but the
window 2100 will remain open. If an error occurs,
a dialog box will inform the
user and the Segment will not be saved until
the fields in question have
appropriate content.
CLOSE Upon pressing CLOSE, a dialog box will query
the user as to whether it is
desired to save any changes that have been
made since the last SAVE. If so,
the validation routine is executed will run
and the window will close after the
save is completed. If no, the window 2100 closes
without any such changes
being saved.
Referring now to FIG. 7, a flowchart is provided of the Segment creation
process 610 mentioned above with reference to FIG. 6. As shown, the
interaction
is occurnng with the CMS database 116 and data warehouse 226 during the
Segment
creation process is also illustrated in FIG. 7 in order to more fully
elucidate this
process. As may be appreciated with reference to FIG. 7, the CMS database 116
provides a first or "local" repository of information that is populated by the
data
warehouse 226.
zo A first step 704 in creating a Segment is to establish a valid Start Date
and End
Date for the Segment. This is illustrated by the user interface window 2200 of
FIG.
22, which depicts a cursor 2204 within the End Date field 2120. In FIG. 22, a
user
has entered Name and Description information for a newly created Segment, and
is in
the process of entering a Start Date and an End Date. As shown in FIG. 7, the
2s selected Start Date and End Date are used identify any existing Segments
708 within
the CMS database 116 having compatible Start Date and End Date criteria. The
set of
CA 02486310 2004-10-29
compatible Segments may then be further narrowed by establishing additional
parameters or "measures" consistent with the organizational parameters of the
data
warehouse 226 (step 712). In the exemplary embodiment this involves selecting
a
category and a measure from a set of available measures 710, each of which
s comprises part of the criteria defining the Segment being created. The
foregoing
aspects of the Segment creation process are illustratively represented by the
screen
shots of FIGS. 23 and 24. Specifically, FIG. 23 depicts a user interface
window 2300
within which a user is in the process of selecting from a list 2310 of
warehouse
measures pertinent to the gaming industry in order to further define the
Segment
~o definition query. FIG. 24 depicts a user interface window 2400
substantially similar
to the window 2300, but in the case of FIG. 24 a user is show as being in the
process
of selecting a category from a category list 2410. Once an initial group of
measures
has been identified, a decision is made of whether or not to retain them (step
718). If
a decision is made to keep the measures, then the measures are combined with
logical
t s operators and target values in order to form a Segment definition query
(step 722);
otherwise, a new set of measures is selected pursuant to step 712.
Once a Segment definition 724 has been developed, a corresponding Segment
is calculated by applying a query based on the definition the data warehouse
226 (step
726) via system stored procedures 760. In the exemplary embodiment the result
of
2o application of a Segment definition query against the data warehouse 226 is
a list of
patron identification numbers corresponding to a set of individual patrons
meeting the
criteria established by the Segment definition.
Once the composition of the Segment has been calculated, it may be spatially
analyzed (i.e., geographically mapped) in a step 730. Turning now to FIG. 26,
a
2s screen shot is depicted of a user interface window 2600 which
illustratively represents
the geographic distribution of the results of a Segment definition query. The
user
interface window 2600 is displayed upon selection of a Map tab 2610, and is
color-
coded or gray-scaled coded to reflect the clustering of members of the
applicable
Segment throughout the illustrated geographic area 2620.
3o A Segment may also be quantitatively analyzed (step 734) subsequent to its
calculation pursuant to step 726. For example, FIG. 25 depicts a user
interface screen
2500 as it could appear immediately following the execution of the Segment
16
CA 02486310 2004-10-29
calculation operation of step 726. As may be appreciated from FIG. 25,
quantitative
analysis may now be performed on the basis of the values displayed within the
Segment Specs panel 2510. In addition, the accuracy of the applied Segment
definition query be verified by comparing the values from the Segment
Dimensions
s panel 2516 with the text in the Formula display box 2520.
Following completion of the above spatial and quantitative analysis of the
calculated Segment, it may be desired to retain the corresponding Segment
definition
(step 738); otherwise, essentially any aspect of the Segment definition may be
changed as desired. Once it has been decided to keep a particular Segment
definition,
to it is stored for subsequent use as an existing Segment 708 within the CMS
database
116 (step 742). As is discussed below, if it is decided to utilize a
particular Segment
definition in the context of a given campaign, the Segment definition is
retrieved from
the existing Segments 708 within the CMS database 116. The criteria
corresponding
to the retrieved definition are then applied against the contents of the data
warehouse
~s 226 in order to yield a list of patron identification numbers identifying a
set of patrons
meeting such criteria.
C. Offers
FIG. 8 is a flowchart representative of, inter alia, the Offer creation
process
620 described briefly above with reference to FIG. 6 In the exemplary
embodiment
2o any number of Offers (e.g. free hotel room, free gaming chips, food
discounts, etc.)
may be defined in the manner illustrated by FIG. 8. Offers have a plurality of
attributes such as name, type (gaming, hotel, food, etc.), location, cost,
value, etc.
Once an Offer is created, it is stored as an available Offer 810 within the
CMS
database 116 and made available for use in subsequent promotional campaigns.
zs Referring to FIG. 8, the Offer creation process 620 is initiated by
ascribing a
name, description, date and status to a new Offer (step 814). This aspect of
the
process is illustrated by FIG. 27, which depicts a user interface window 2400
having a
New Offer panel 2710. As shown, the New Offer panel 2710 includes a General
sub-
panel 2714 and an Offer Details sub-panel 2718. In the exemplary embodiment
each
3o user interface window driven by the CMS module 220 includes an Offers tab
(see,
e.g., the Offers tab 2620 of window 2600), which may be selected (i.e.,
"double-
clicked") in order to display the New Offer panel 2710.
17
CA 02486310 2004-10-29
Within the General sub-panel 2714, a user has begun the process of creating a
new Offer by entering a name within an Offer Name field 2722 and a description
of
the Offer within a Description field 2726. An Offer status (e.g., active or
inactive)
may also be indicated through appropriate selection of a status box 2730. If a
user
s desires to use the same name as a previously defined Offer, by checking the
"Inactive" status box 2730 the Offer is automatically moved to an Inactive
folder (not
shown) and a new Offer may be created with the same name.
The Offer creation process also involves categorizing the Offer and
identifying it as a particular type (step 820). This is illustrated by the
user interface
t o window 2800 of FIG. 28, which is substantially identical to the window
2700 but
further depicts the selection of a category (i.e., "Gaming") from a Categories
list 2810
within the Offer Details sub-panel 2718. In addition, the window 2800
indicates that
the user has also selected an Offer type from a drop-down menu associated with
a
Types field 2820.
~ s The Offer creation process continues through specification of a value of
the
Offer to a potential patron and the cost of the Offer to the offering casino
or other
gaming establishment (step 824). These values are determined by management of
the
applicable casino or gaming facility. For example, the value of the Offer may
be
equivalent to the value of the Offer perceived by the patron receiving the
Offer (e.g., a
2o ticket to some form of entertainment having a face value of $50 would
likely be
perceived as a $50 value). Similarly, the cost of the Offer to the casino
could simply
be the actual cost of extending the Offer to the patron (e.g., the cost of
procuring the
ticket given to the patron). In the user interface window 2900 of FIG. 29, a
user has
entered a value of an Offer within a Value field 2910 of the Offer Details sub-
panel
2s 2718 and a cost of the Offer within a Casino Cost field 2920. Once an Offer
has been
saved, it is generally not permitted to be edited other than to change the its
description
or be declared inactive. This is because Offers are directly associated with
promotional campaigns, and changing the values of the Value field 2910 or the
Casino Cost field 2920 would impact the post-analysis of the efficacy of a
given
3o campaign.
18
CA 02486310 2004-10-29
If it is determined to keep the Offer which has been created (step 828), the
Offer is stored as an available Offer 810 for later use in one or more
campaigns (step
832).
Additional details regarding the various fields within the General sub-panel
s 2714 of the windows of FIGS. 27-29 are set forth in Table IV. Similarly,
further
description of the fields of the Offer Details sub-panel 2418are given below
in Table
V.
TABLE IV
Field of GeneralDescription
Panel
Offer Name A user enters a unique Offer name within
the Offer Name field. Upon
SAVE or GLOSE, the CMS database 116 will
be queried to ensure the
Offer name is unique. If it is not, a dialog
box will prompt the user to
enter a new one.
Date Created The Date Created is a non-editable text
field. Upon SAVE, the current
date will be entered in this field.
Creator The Creator is the person creating the
Offer. This field is automatically
entered based on the identification provided
during the system login
process.
Description The Description field is a text field.
It will allow special characters,
numbers, etc. The user will input a description
of the Offer in this area.
Inactive If a user would like to end an Offer, the
Inactive status box may be
checked and the Offer will be put in an
Inactive Folder. At that time, the
Offer cannot be used in any future campaigns.
No Value If the No Value status box is selected,
the offer properties will not
require the input of "Value" or "Cost"
data, as the offer will be
considered an advertisement.
19
CA 02486310 2004-10-29
TABLE V
Field of Offer Description
Details
Panel
Categories The Categories field is a list box that
will be populated by the CMS
database 118 to include all available Offer
categories. A user will select
the category that best fits the Offer.
In the exemplary embodiment
there are several pincipal predefined categories
such, as, for example,
Room, Gaming, Special Events, and Entertainment.
Each of these
general categories includes "Offer Types"
unique to that category. For
example, a Room (general category) contains
a predefined set of Offer
types that include (but are not limited
to) Casino RatelLimited Food &
Beverage or Full Comp RoomINo Food 8~ Beverage.
Types Upon selection of the category, the Types
dropdown will populate from
the CMS database 116 with the subtypes
of the category chosen. The
Types field is a dropdown list of subtypes
for the chosen Category.
The user selects a type that is best suited
to the Offer.
Location Location is a text field in which is entered
the location where the Offer is
valid. For example, "Benihana" or "Bellagio".
Value Value is a text field of the currency format
in which the value of the
Offer to the guest is entered.
Casino Cost Casino Cost is also a text field of the
currency format in which the cost
of the Offer to the Casino or other gaming
establishment is entered.
D. Channels
Marketing campaigns can be executed through a number of channels,
s including, but not limited to, direct mail, email, telemarketing, door-to-
door. Each
Segment receiving an Offer within a campaign can be delivered via any number
of
channels. When integrated, the PCS module 216 provides information regarding
telemarketing channels for campaigns utilizing this approach.
E. Distribution Formats
~ o As is described below, during the process of creating a promotional
campaign
specific vendors and channels will be specified through which the campaign is
executed. Since different vendors may utilize different equipment when
developing
campaign-related material for particular channels, various distribution
formats
specific to particular vendors and channels may be defined. Typically, a
distribution
Is format defines the specifics of the electronic files generated and sent to
vendors in
connection with campaigns of various types (e.g., mailing, or e-mail, or
telemarketing). Exemplary distribution formats may, for example, specify the
required fields for such electronic files, the display order, the data types
to be output,
and the delimiters) to be used for the output files.
CA 02486310 2004-10-29
Turning again to FIG. 8, there is shown a flowchart representative of the
Offer
distribution format creation process 630. The process 630 may be initiated by
selecting a Distribution tab 2630 (FIG. 26) from any window relating to the
campaign
management system. For example, selection of the Distribution tab 2630 could
result
s in display of the user interface window 3000 of FIG. 30. Through the window
3000 a
user may open an existing distribution format for viewing and/or editing,
create a new
distribution format, rename an existing distribution format, and create or
rename
folders to manage and organize existing distribution formats. In particular,
through a
New Distribution Format panel 3010 a user may create or edit distribution
formats by
~ o adding or deleting fields, entering the maximum size allowed for
particular fields, and
place the fields in the desired order (step 842). Then, using an Output sub-
panel
3020, the user selects the preferred delimiter for the chosen format (step
846). Radio
buttons 3010 on the sub-panel 3020 allow a user to choose the delimiter for
the
distribution format, with comma-delimited being the default selection in the
~ s exemplary embodiment. The selection of "Other" enables the Char-Delimited
field,
which allows the user to enter one letter as a delimiter.
If it is determined to keep the distribution format which has been created
(step
850), the format is stored as an available distribution format 854 for later
use in the
campaign export process (step 856).
2o Additional details regarding the various fields within a General sub-panel
3120 of the distribution format windows of FIGS. 30-31 are set forth in Table
VI.
Similarly, further description of the fields of the Offer Details sub-panel
2718 are
given below in Table VII.
zs TABLE VI
Field of General Description
Sub-
Panel
Distribution ListDistribution List Name is a text field
Name in which the user assigns a name to
the particular distribution list.
Creator Creator is a non-editable text field which
is automatically populated
based upon login information supplied
by the creator of the distribution
format.
Last Modified Last Modified is a non-editable text field
which auto-populates based on
~ the last time the format was saved with
changes.
21
CA 02486310 2004-10-29
TABLE VII
Field of Fields Description
Sub-
Pane!
Available Available is a database-populated list
of all available fields. These
fields are used to create a template for
the Distribution Format. Upon
selection of a field from the list, the
user will click the > to move that
field into the Selected table, simultaneously
removing it from the list.
Selected This list constitutes all fields selected
by the user. A user may remove
a field from the Selected table by clicking
on <. At the same time as the
removal, that field is added back into
the Available list.
The user may move the fields in the Selected
table up and down as
required, using the ~ and v buttons, thereby
changing the order in which
the distribution format is later returned
when exported to a file.
F. Vendors
Again refernng to FIG. 8, there is shown a flowchart representative of the
s Vendor creation process 640. In the exemplary embodiment each Vendor
corresponds to a commercial vendor of materials or services used in the
execution of a
campaign. For example, a Vendor may be utilized for printing or otherwise
producing brochures distributed through one or more channels in connection
with
execution of a campaign.
to The Vendor creation process 640 may be initiated by selecting a Vendor tab
2640 (FIG. 26) from any window relating to the campaign management system,
which results in display of a user interface window 3200 such as that depicted
in of
FIG. 32. Through the window 3200 a user may open an existing Vendor for
viewing
and/or editing, create a new Vendor, rename Vendors, and create or rename
folders to
Is manage and organize existing Vendors. In particular, through a Vendor panel
3210 a
user may create or edit Vendors by specifying contact information, indicating
the
Vendor's format preferences, and adding notes regarding the Vendor (step 860).
An
Available Channels table 3226, generally dynamically created based upon the
number
of marketing channels in the CMS database 116, is disposed within a Channels
and
2o Distribution Format sub-pane 3230. Users can select those marketing and
fulfillment
channels that the Vendor is capable of handling (step 864), each of which is
associated with a default distribution format specifying the format/style
preferred by
the Vendor (step 868). The selection of a fulfillment channel is illustrated
by the
window 3300 of FIG. 33, in which a Direct Mail channel 3310 has been selected.
2s FIG. 33 also indicates that a user is in the process of associating a
distribution format
22
CA 02486310 2004-10-29
from within a drop-down list of distribution formats 3320 with the Direct Mail
channel 3310. Refernng now to the user interface window 3400 of FIG. 34, it is
seen
that after a distribution format (i.e., Mass Mail) has been selected from the
list of
formats 3420, a Distribution Format Quick View panel 3410 is populated with a
s preview of the selected format. FIG. 34 also indicates that the user is also
in the
process of selecting Telemarketing 3420 as an additional Available Channel
322b
provided by the Vendor.
If it is determined to keep the Vendor which has been created (step 872), the
format is stored as an available Vendor 874 for later use in one or more
campaigns
(step 876).
Additional details regarding the various fields within the Vendor panel 3210
of the Vendor windows of FIGS. 32-34 are set forth in Table VIII. Similarly,
further
description of the fields of the Distribution Format Quick View panel 3410 are
given
below in Table IX.
23
CA 02486310 2004-10-29
TABLE VIII
Field of Vendor Description
Panel
Company Name The Company Name will be checked against
the database upon
saving to ensure its uniqueness. In the
event that the name is already
in use, the validation will lead to a
dialog box, which asks the user if
they wish to overwrite the current information
or create a new
company.
Address1 The Addressl field will accept all numbers,
letters, apostrophe, pound
sign, and a hyphen. (Le.: 29 1st Street).
Address2 The Address2 field is not required. It
will also accept all numbers,
letters, apostrophe, pound sign, and
a hyphen. (Le.: #B-34).
City The City field will accept letters, hyphen,
and apostrophe only.
State The State field will accept letters,
hyphen, and apostrophe only.
Country Country will allow input of letters,
hyphen, and apostrophe only.
Country Code The Country Code is a prefix for the
telephone number. Only numbers
will be allowed.
Phone Phone will accept hyphens and numbers
only.
FAX Fax will accept hyphens and numbers only.
Contact Name Contact Name is not a required field.
Contact Name will accept
letters, comma, hyphen, and apostrophe
only.
Title Letters, apostrophe, hyphen, and comma
will be accepted.
Phone Ext Phone Ext is not a required field.
Secondary ContactSecondary Contact is not a required field.
It will enact the same
validation as Contact Name.
Title Title is not a required field.
Phone Ext Phone Ext is not a required field.
TABLE IX
Field of Quick Description
View
Panel
Name The Name field consists of a dropdown
box populated by the CMS
database 116 with all available distribution
formats. The user may
choose a distribution format to view or
they may click on the ellipses
button in the table to the left in order
to make a selection. Once a
selection is highlighted, all the fields
in that particular distribution
format will populate in the list box below.
Delimiter The delimiter field is a read only text
field, which is populated by the
CMS database 116 with the delimiter associated
with the selected
distribution format.
24
CA 02486310 2004-10-29
G. Creating a campaign
FIG. 9 is a flowchart illustrating the campaign creation process 650. As
shown, the interaction occurnng with the CMS database 116 and data warehouse
226
s during the campaign creation process is also illustrated in FIG. 9 in order
to more
fully elucidate this process. As may be appreciated with reference to FIG. 9,
the CMS
database 116 provides a first or "local" repository of information that is
populated by
the data warehouse 226. In the exemplary embodiment the functionality of the
campaign management system is effected though execution of program
instructions
i o stored within the CMS module 220 and the CMS client module 354.
As was discussed above, the data warehouse 226 is filled via the extraction,
transformation and load process (ETL) 500 of FIG. 5..
A first step 904 in creating a campaign is to establish a valid start date,
end
date, and name for the campaign. In the exemplary embodiment the start date
for the
~ s campaign may correspond to the date upon which promotional materials for
the
campaign are distributed to existing and/or potential patrons, or any other
date in
some way corresponding to the beginning of the campaign. The establishment of
campaign start/end dates is illustrated by the user interface window 3500 of
FIG. 35,
in which a user has entered a name for the campaign in a Campaign Name field
3510
Zo after selecting the General tab 3514. In addition, the user has utilized a
drop-down
calendar 3520 to facilitate entry of campaign start/end date information into
a Start
Date field 3524 and an End Date field 3528, respectively. As is indicated by
FIG. 35,
a campaign may also be further defined by entry of appropriate information
into a
Campaign Code field 3532, Description field 3536, and a Creator field 3540.
When
25 a campaign's Start Date is reached, the campaign is tagged as active and
certain
attributes can no longer be modified. Additionally, active and completed
campaigns
have actual redemption activity associated with them, whereas campaigns in
creation
stages are characterized by only proforma redemption metrics.
Any number of Segments are chosen from the Available Segments 708 and
3o associated with the campaign (step 918). This process is illustrated by the
user
interface window 3600 of FIG. 36, which is displayed upon selection of a
Segments
tab 3610. As shown, the window 3600 includes a Select Segments panel 3620
containing an Available Segments list 3624 and a Selected Segments sub-panel
3628.
CA 02486310 2004-10-29
In the example of FIG. 36, a user is in the process of associating a Segment
from the
Available Segments list 3624 with the current campaign (i.e., the campaign
having a
Campaign Name of "Superbowl Campaign"). Segments are selected from the
Available Segments list 3624 and added (associated) to the current campaign by
use of
s the arrow buttons 3630. In the user interface window 3700 of FIG. 37, which
illustrates the user interface window 3600 of FIG. 3G as it could exist at a
later time,
the user has highlighted a particular Segment 3710 within the Selected
Segments sub-
panel 3628. As shown, the user is in the process and of establishing campaign-
specific date parameters for this Segment within a Date Range sub-panel 3420
of a
io Select Criteria panel 3730, thereby yielding a campaign Segment definition
922 (FIG.
9).
Referring again to FIG. 9, once a campaign Segment definition 922 has been
determined, the user may elect to calculate a corresponding campaign Segment
population (step 924). If so, the campaign Segment population is calculated by
~ s applying the campaign Segment definition 922 against the contents of the
data
warehouse 226 (step 928). Once a campaign Segment population has been
calculated,
it may be analyzed both spatially (step 930) and quantitatively (step 934).
It is observed that by changing the date range for a Segment definition,
corresponding changes accrue in the corresponding Segment population as a
different
2o set of patrons will typically qualify relative to the patron set qualifying
under the
original date range. For example, if a particular Segment definition requires
a
theoretical win of $1000 over a nine month period, a potentially different set
of
patrons will be identified by altering the Segment definition to specify a
date range
spanning one month.
2s FIG. 38 depicts a user interface window 3800 illustratively representing
the
type of quantitative analysis which may be effected with respect to selected
campaign
Segment populations. As is indicated by FIG. 38, a Selected Segments sub-panel
3810 accessible upon selection of the Segments tab 3610 displays various
statistical
information associated with a pair of campaign Segment populations. These
statistics
3o include, for example, total theoretical win 3820 for the Segment
population, average
theoretical win per patron 3830 within the Segment population, and average
theoretical win per patron per trip 3834. It is noted that once a set of
potential
26
CA 02486310 2004-10-29
Segments for a campaign have been selected and the corresponding Segment
populations calculated, a prioritization calculation determines the
appropriate
placement for each member of all the Segments selected. That is, if a patron
qualifies
for more than one Segment within a campaign, the patron will be placed into
the
s Segment given the highest priority in the system. As a consequence, in the
exemplary
embodiment each Segment population identified within the window 3800 contains
a
mutually exclusive set of patrons (i.e., individual patrons are not
"duplicated" within
different Segment populations). This ensures that only a single Offer is
distributed to
each patron in connection with execution of a given campaign, and places
patrons
~ o within the most highly "ranked" of the various Segments in which they
could be
included for a given campaign. Although Segments may be so ranked in any order
desired, ranking will often be done on the basis of theoretical win per
patron.
Turning now to FIG. 39, there is shown a user interface window 3900
illustratively representing the type of spatial analysis which may be effected
with
~ s respect to selected Segment populations. As is indicated by FIG. 39, the
window
3900 is displayed upon selection of a Map tab 3910. The map 3920
illustratively
represents the geographical distribution of the campaign Segment populations
identified within a Segments panel 3924. In the embodiment of FIG. 36 the set
of
population members within a given zip code are aggregated and the composite
results
2o for each zip code are displayed. Spatial analysis the map 3920 may be
performed by
using various mapping tools, as well as by simply viewing it in accordance
with the
legend information contained within a Map Legend panel 3940. The quantitative
and
spatial analysis window 3800 and 3900 permit a user to evaluate various
economic
attributes of a given Segment population, which facilitates determination of
whether
2s to actually include the corresponding Segment definitions within the
campaign under
development.
Once a set of one or more Segments have been selected for inclusion within
the campaign (step 938), any number of predefined Offers can be associated
with each
Segment (step 942). FIG. 40 shows a user interface window 4000 containing a
3o primary panel 4010 displayed upon selection of an Offers tab 4014. As
shown, the
primary panel 4010 includes a Selected Segment and Offer Association sub-panel
3718 and an Available Offers list 4022. In the example of FIG. 40 a user is in
the
27
CA 02486310 2004-10-29
process of associating Offers from the Available Offers list 4022 with the
individual
Segments of the open campaign identified within the Selected Segment and Offer
Association sub-panel 4018. This is shown as being effected by selecting an
Offer
from the Available Offers list 4022 and "dragging and dropping" the selected
Offer
s onto a Segment in the sub-panel 4018 in order to perform the association. As
shown
within a user interface window 4000 of FIG. 40, other attributes may then be
associated with the Offers copied to the sub-panel 4018. For example, in the
embodiment of FIG. 40 a period of time during which a given Offer may be
redeemed
can be set by specifying a Valid Start date 4110 and a Valid End date 4116
using a
~o drop-down calendar 4120. An expected redemption percentage 4126 during the
specified redemption period may also be entered. In order to facilitate
estimation of
redemption rates, the data warehouse 226 may be configured to support the
training of
predictive models utilizing, but not limited to, cluster and decision tree
modeling
protocols. To the extent available, users may utilize such predictive models
to
is associate redemption rates with Offers within a campaign.
Once an Offer has been associated with each Segment of a campaign, a
summary of statistical information characterizing each Offer and Segment of a
campaign may be viewed (step 950). This is illustrated by the user interface
window
3900 of FIG. 42, which is seen to include a By Segment summary panel 3910 and
a By
2o Offer summary panel 4214. As shown, the By Segment summary panel 4210
provides
certain statistical information relating to the various Segments 4220 of the
applicable
campaign. Similarly, the By Offer summary panel 4214 provides various
statistics
pertinent to the Offers 4230 of the campaign.
Turning now to FIG. 43, there is shown a user interface window 4300
2s containing an Estimated Expenses panel 4310 through which various expense
items
may be associated with a campaign (step 954). The expenses entered via the
worksheet 4320 within the Estimated Expenses panel 4310 frequently correspond
to
those additional expenses or "hard costs" associated with execution of a
promotional
campaign; that is, to those costs ancillary to the inherent costs of the
Offers extended
3o during execution of the campaign. For example, such additional expenses
could
comprise the costs of television or print advertising, mailing costs, printing
costs and
the like, but would not include the cost to a casino of offering a free night
of
28
CA 02486310 2004-10-29
accommodations through a particular Offer. In FIG. 43, a user is shown
entering a
value with a Quantity field 4330 of the expenses worksheet 4320, and will then
enter
a value within a Cost field 4334. A total cost value will then be calculated
and appear
within the corresponding Total Cost field 4340. The expense items occupying
the
s rows of the worksheet 4320 can be added and removed by means of a right-
click
context menu (not shown). Although it is assumed that estimated costs are
being
entered within the worksheet 4320, at the conclusion of the applicable
campaign
actual expenses could subsequently entered in a different portion of the
worksheet
4320 (not shown).
~o In a particular embodiment the development of a promotional campaign is
considered complete and amenable to a pro forma analysis when all Segments,
channels, Offers, redemption rates, Vendors, expenses and distribution formats
have
been defined. Once these definitions have been completed, the expected pro-
forma
results 956 of the campaign may be generated (step 958). As is discussed
below, the
is results 962 of this pro-forma analysis may be analyzed in conjunction with,
or
independently of, the active/post campaign performance data 964 resulting from
the
actual execution of the campaign itself (step 966). Specifically, once a
campaign has
begun to be executed (i.e., is active), the active campaign performance data
964 may
be compared to the pro-forma results 956, while the post campaign performance
data
20 964 may be compared to the pro-forma results 956 at the conclusion of the
campaign.
A variance 970 between the pro-forma results 956 and the active/post campaign
performance data 964 may be determined in connection with each comparison.
FIG. 44 depicts a user interface window 4400 containing a used for
quantitative analysis of a campaign. As shown, the user interface window
includes a
2s Pro-Forma tab 4410, an Analysis tab 4414 and a Variance tab 4418, with the
Pro-
Forma tab 4410 having been selected in the embodiment of FIG. 44. Selection of
these tabs results in population of the window 4400 with the pro-forma results
956,
the active/post campaign performance data 964, and the variance 970,
respectively.
After a campaign has been launched, data relating to the redemption of Offers
during
3o patron trips to the applicable casino or other gaming establishment, i.e.,
"redemption
trip data" (step 974) is used in subsequent campaign analysis (step 978). The
variance
29
CA 02486310 2004-10-29
970 is also updated in association with updating of the active campaign
performance
data 964 which occurs in response to each iteration of step 978.
Referring to FIG. 44, a results table 4426 is displayed upon selection of the
Pro-Forma tab 4410. In the exemplary embodiment similar results tables are
s displayed upon selection of the Analysis tab 4414 and the Variance tab 4418.
As
shown, a first column 4430 of the results table 4426 includes various objects
comprising a significant portion of the applicable campaign 4432 (e.g.,
Segments
4434, Offers 4436, distribution channels 4438). An Accounts column 4450
provides
an indication of the raw counts associated with each object, while an
estimated
~ o redemption percentage column 4452 indicates the redemption percentage
estimated
for the Offers objects 4436.
If the pro-forma results 956 generated on the basis of a given campaign
definition are deemed acceptable, it may be determined to keep the campaign
(step
982). If not, and as is indicated by FIG. 9, essential any aspect of the
campaign
~s definition may be modified. For example, different Segments may be used,
different
Offers may be associated with different Segments, and/or the campaign expense
structure may be modified. If it is decided that the campaign is acceptable,
the
information defining the campaign (e.g., Segments, Offers, Vendors,
distribution
formats) is stored within the CMS database 116 as a campaign definition 984.
In
zo addition, the Vendors for the campaign are associated with the Segments of
the
campaign as a function of fulfillment channel (step 988).
Refernng now to FIG. 45, a user interface window 4500 is shown in which a
Vendor is being associated with a Segment for a particular Offer fulfillment
channel.
In particular, selection of an Export Lists tab 4510 results in display of a
file export
2s table 4514 organized as a function of fulfillment channel. As shown, the
rows of the
file export table 4514 are divided into groups corresponding to the
fulfillment
channels of Direct Mail 4218, E-Mail 4520 and Telemarketing 4522. In the
example
of FIG. 42, a particular Vendor 4226 is being associated with Segment 4530 for
purposes of Direct Mail 4520 fulfillment; that is, Vendor 4526 will distribute
Offers
3o to members of Segment 4530 via direct mail. Once this association has been
effected,
a format for distribution (i.e., Dist Format 4540) via the Direct Mail 4518
fulfillment
channel will be chosen.
CA 02486310 2004-10-29
Referring again to FIG. 9, once Vendors and distribution formats have been
selected, the data defining a given campaign is exported in files to the
applicable
Vendors in the selected distribution formats (step 992). In particular, one
file is sent
to each Vendor for each Segment/channel combination. FIG. 43 is a user
interface
s window 4600 which again depicts the file export table 4514, which is
displayed upon
selection of the Export Lists tab 4510. As shown, since both a Vendor 4610 and
a
Distribution Format 4540 have been specified for each Segment within the
Direct
Mail 4518 category, the user has chosen to export the corresponding data to
files by
selecting a Vendor Export button 4530. In the exemplary embodiment the file
for
Io each fulfillment channel includes data (e.g., name, account number,
address) for the
patrons included in the applicable Segment that is arranged in accordance with
the
selected distribution format. These files are then sent to the applicable
Vendors for
fulfillment, which appropriately process them and forwards the specified
Offers to
patrons or other consumers (step 994).
~ s As mentioned above, as Offers are redeemed by patrons or consumers via one
or more transactional systems (step 974), the corresponding redemption events
are
recorded in the applicable transactional databases 108 and subsequently
transferred to
the data warehouse via the ETL process 500. The CMS database 116 then
recognizes
the redemption record and updates the campaign attributes 984 to include the
2o redemption event and any associated records appropriate for the completion
of a
financial performance analysis 966 vis-a-vis the proforma financials. In
addition,
Offer performance records can be further utilized to train predictive models
for use in
future campaigns.
H. Data Process Visualization
2s FIG. 10 is a flowchart illustrating a data visualization process 1000. In
the
embodiment of FIG. 10, it is contemplated that the process 1000 will be
executed
primarily by the CMS module 220 and the CMS client module 354. As shown, the
interaction occurring with the CMS database 116, data warehouse 226 and an
external
mapping server 1006 during the data visualization process is also illustrated
in FIG.
30 10 in order to more fully elucidate this process. In the exemplary
embodiment the
data visualization process 1000 may be utilized in connection with providing a
visual
31
CA 02486310 2004-10-29
representation of the geographic distribution of members of an individual
Segment or
of the collection of Segments included within a campaign.
In one embodiment the external mapping server 1006 may be commercially
operated by a third party engaged in providing geographic information systems
(GIS)
s and other mapping services to Internet-enabled client browsers. For example,
ESRI
(http://www.esri.com/software/arcims/index.html) operates an ArcIMS Server
which
facilitates access to, and interaction with, Internet mapping and GIS data
from a Web
browser.
Referring to FIG. 10, the data visualization process 1000 is initiated through
~o issuance of a request to the CMS database llb for data relating to a
Segment or set of
Segments within a campaign (step 1004). Once this data has been received or
pending its receipt, the external mapping server 1006 is queried (step 1012)
and
geographic information concerning the identified area is returned (step 1016).
The
returned geographic data is then joined with the data received from the CMS
database
~s 116 and/or data warehouse 226 that is specific to the Segment or collection
of
Segments of interest (step I020). At this point the resultant geographic
representation
of the Segment data may be spatially analyzed in the manner described below
(step
1030).
FIGS. 47-49 depict user interface windows through which certain aspects of
2o spatial analysis of mapped Segment data may be performed. In each of FIGS.
47-49,
mapped Segment data 4710 is displayed within a primary panel 4714 exhibited
upon
selection of a Map tab 4718. In the exemplary embodiment the mapped Segment
data
4710 comprises a geographic representation of the patrons comprising the
Segments
of the campaign having a Campaign Name 4720 of "Superbowl Campaign"..
2s Turning now to FIG. 47, a user has selected an Identify tool 4430 in
connection with viewing of the mapped Segment data 4710. The selection of the
Identify tool 4730 is further indicated by the icon 4734 proximate the
displayed cursor
4738. As is illustrated by the user interface window 4700 of FIG. 47, the
Identify tool
4730 may be used to obtain detailed information concerning an attribute of the
3o mapped Segment data 47I0. Specifically, clicking upon the mapped Segment
data
4710 causes a dialogs to appear, which will generally consist of a table
containing
general and statistical data relevant to the attribute. In the case of FIG.
48, a Map
32
CA 02486310 2004-10-29
Properties dialog 4810 and a Class Breaks Editor dialog 4814 have been opened.
The Class Breaks Editor dialog 4814 may be used to create manual class breaks
as the
data classification method for the mapped Segment data 4710 in its entirety,
and
provides one example of the interactive nature of the mapping process.
s Referring now to the user interface window 4900 of FIG. 49, a user has
utilized one of the selection tools (not shown) to open an Attribute Viewer
window
4910 comprising an attribute table characterizing the mapped Segment data
4710.
The attribute table provides an indication of the number of patrons, i.e.,
Patron Count
4914, as a function of ZIP code 4916. Within the attribute table, highlighted
rows
~0 4920 correspond to geographic features highlighted on the mapped Segment
data
4710.
FIG. 10 also indicates that the results of the spatial analysis of the mapped
Segment data (step 1030) may also be used to create one or more reports. For
example, in the embodiment of FIG. 10 a Feature Analysis report 1050 and an
~ s Attribute Analysis report 1054 may be generated. In this regard the
attribute table
displayed within the Attribute Viewer window 4910 exemplifies that type of
data
which could form the basis of an Attribute Analysis report 1054. In contrast,
a
Feature Analysis report 1050 is typically intended to provide a visual
representation
of the geographic distribution and location of the patrons within one or more
2o Segments. Accordingly, information in the form of, for example, the mapped
Segment data 4710 may be used in creating a Feature Analysis report 1050.
As is indicated by FIG. 10, in addition to being spatially analyzed the mapped
Segment data 4710 may be scrutinized from differing perspectives using
interactive
mapping tools (step 1040). For example, FIG. 50 shows a user interface window
2s 5000 through which a user is defining the coverage of an extent 5010 by
clicking and
dragging with using a zoom-in tool 5020. Once the extent 5010 has been defined
and
then selected for viewing, it is transformed into the new map 5110 within the
user
interface window 5100 of FIG. 51.
33
CA 02486310 2004-10-29
III. PLAYER CONTACT SYSTEM (PCS)
A. Overview
The PCS module 216 of the system 100 is designed to provide a mechanism
for system users (e.g., the staff of a casino) to identify, manage and analyze
s relationships with valued customers or potential patrons. As is described
hereinafter,
the deployment of the PCS module 216 in conjunction with the data warehouse
226 is
believed to be unique and to offer the advantages of providing greater access
to
detailed historical data (i.e., finer data granularity) and of reducing the
load on the
underlying transactional systems (as represented by the transactional
databases 108).
~ o In addition, this reduced loading of the underlying transactional systems
is believed to
enhance the performance of the system 100.
FIG. 11 provides a simplified illustrative representation of certain aspects
of
the structure and function of the PCS module 216 relative to other components
of the
system 100. During operation of the PCS module 216, historical and otherwise
"pre-
~s processed" data may be obtained fiom both the dedicated PCS database 112
and the
data warehouse 226. In contrast, any required "real time" data is retrieved
via
interface 1104 from transactional databases 108. In order to determine the
extent of
any requirements for such real time data, the PCS module 216 queries the
transactional databases 108 (e.g., upon user access of the PCS module 216) in
order to
2o determine if a user account being accessed has had activity since the last
update of the
data warehouse 226; if so, the PCS module 216 requests and obtains the updated
information as needed during the session via interface 1104. If there has been
no
activity on the applicable user account recorded in the transactional
databases 108
since the last update of the data warehouse 226, the PCS module 216 pulls data
2s exclusively from the data warehouse 226. This configuration significantly
reduces
load on the underlying transactional system (as represented by transactional
databases
108) and enables access to a broader range of historical data than would
otherwise be
obtainable from a conventional transactional system.
In certain embodiments the PCS module 216 may be configured to operate in
3o the absence of data warehouse 226. However, in such implementations it is
anticipated that the granularity of the data available would be more coarse
than that
furnished in configurations including a data warehouse. The PCS module 216
34
CA 02486310 2004-10-29
preferably includes "plug-and-play" configurability, so that the existence of
the
warehouse 226 can be identified at installation or modified to "point" to the
warehouse 226 if it is subsequently added to the system 100.
B. Player General Data
s A patron general data component 1108 comprises a repository of information
with respect to patrons which have registered with an underlying transactional
system
(e.g., a system operated by a casino) and thus are known to one or more of the
transactional databases 108. In the exemplary embodiment, the patron general
data
component 1108 includes at least the following information for each tracked
patron or
~ o customer: account number, name(s), address and phone number. Related
geographic
and other demographic data may also be included to the extent available from
the
applicable transactional database 108.
C. Stated Preferences
A stated preferences component 1112 comprises a plurality of data points a
t s table of information indexed by account number that describe various
preferences and
dislikes, as reported by the patron to the system 100 (e.g., via a casino
staff member).
Examples include hobbies, sporting events, dining, gaming preferences and
dislikes.
D. Observed Preferences
An observed preferences data structure1116 includes a plurality of data points
2o a table of information indexed by account number which are calculated based
upon
various metrics descriptive of patterns of behavior discerned from analysis of
certain
transactions stored within the data warehouse 226. In the exemplary embodiment
the
table of data points stored within the preferences data structure 1116 is
updated at
regular intervals (e.g., once per day) using transformed sets of data provided
during
Zs these intervals by the data transformation services 232. The preferences
data reflected
by the preferences data structure 1116 may be based upon activity over various
default time periods (e.g., most recent 30, 60 or 90 days). Alternately, users
may
specify the duration of the time period represented by the preferences data
stored by
the data structure11I6 (e.g., most recent 74 days) Attributes of these
transactions are
3o stored within the PCS database 112, and the contents of the observed
preferences data
structure 1116 is distilled from this stored information. These preferences
contained
within the data structure 1116 may include, for example, (1) gaming
preferences
CA 02486310 2004-10-29
based on observed time played or actual win or theoretical win as recorded
(derived or
observed) from a casino's management system (Z) favorite restaurant based on
number of visits to restaurants as recorded in the warehouse 226 on the basis
of
restaurant-related transactions stored within the transactional databases 108.
s E. Transaction Summaries; Gaming History
A transaction summaries component 1120 comprises a set of data points
collectively presenting a complete view of a patron's gaming activity as
recorded in
the casino management system and data warehouse 226. The PCS module 216
preferably uses a folder-tree type of GUI that allows users to drill down into
finer
to grains of detail as needed to acquire information relating to the gaming
activity
metrics of interest. Representative metrics include, for example, number of
visits to
the applicable casino, theoretical win (i.e., the product of the aggregate
amount of
money exchanged during playing of a given game and the percentage of such
aggregate amount expected to be retained by the applicable casino
installation),
~ s average theoretical win per visit, actual win/loss for slot machines and
table games,
and amount of compensatory products and services ("comps") consumed (e.g.,
room,
food, show tickets, and travel). Different sets of these metrics will
generally be
tracked by the separate installations of the system 100 in different casino
establishments. In addition, the metrics tracked will also tend to differ in
installation
20 of the system 100 which include a data warehouse 226 relative to
installations in
which a data warehouse 226 is not present.
F. Campaign History
A campaign history component 1124 includes information identifying the
marketing campaigns associated with a given customer account, as well as the
status
2s of the campaign and any associated offers. This information may vary from
installation to installation of the system 100, and between installations
including a
data warehouse 226 and those not including a data warehouse 226.
G. Operation of Player Contact System
FIG. 12 is a flowchart 1200 illustrating the operation of the player contact
3o system. As shown, the interaction occurring with the PCS database 112 and
data
warehouse 226 during the campaign creation process is also illustrated in FIG.
12 in
order to more fully elucidate this process. As may be appreciated with
reference to
36
CA 02486310 2004-10-29
FIG. 12, the PCS database 112 provides a first or "local" repository of
information
that is populated by the data warehouse 226. In the exemplary embodiment the
functionality of the player contact system is effected though execution of
program
instructions stored within the PCS module 216 and the PCS client module 350.
s Referring to FIG. 12, in one embodiment of the player contact system,
several
different types of information regarding players or other patrons are
accessible to
various system users. In particular, a view 1204 may be provided of the set of
players
currently located on the "floor" of a gaming establishment, another view 1208
may be
provided of the players assigned to a particular host employed by the
establishment,
to and yet another view 1210 of a list of the calls to be made to the players
assigned to a
given host may also be displayed. Access to the views 1204, 1208 and 1210 will
often be restricted as a function of the role of the system user within the
gaming
establishment. For example, player hosts and the like will often be granted
access to
views 1204 and 1210, while access to view 1208 may be available exclusively to
1 s management personnel. As is discussed below, each of these views is
generated by
applying a filter comprised of various criteria or "warehouse measures" to the
player
data stored within the data warehouse 226. In addition, operations relating to
the
making of calls upon patrons (step 1240) or the scheduling of such calls (step
1242)
may be conducted from within the contexts of the various views 1204, 1208 and
1210.
2o FIG. 52 depicts a user interface window 5200 providing an illustrative
representation of one potential player location view 1204 of the locations of
players
within a gaming establishment. As shown, the interface window 5200 includes a
floor diagram pane 5210 illustrating the layout of various gaming machines
5216
within the applicable gaming establishment. The locations of certain players
5220
2s within the gaming establishment are also illustrated within the floor
diagram pane
5210, as well as within a player location table 4930. As may be appreciated by
reference to FIG. 12, the contents of the user interface window 5200 may be
generated by applying filter to warehouse 226 (step 1214) and mapping the
results of
the filtering operation (step 1218). As is discussed below, such application
of a filter
3o to the data warehouse 226 involves defining a set of warehouse measures and
then
extracting information from the data warehouse 226 corresponding to players
fitting
the criteria established by the defined warehouse measures. In the case of
FIG. 52,
37
CA 02486310 2004-10-29
the filtering process (step 1214) identifies a subset of the players on the
floor of the
applicable gaming establishment which meet the filtering criteria. The
information
extracted through the filtering process (e.g., player identification number
and/or name
information) may then be associated with corresponding locations within the
floor
s diagram pane 5210 during the mapping process 1218, which is described in
further
detail below with reference to FIG. 15. As is indicated by FIG. 52, a user may
then
cause the identify of a particular player to be displayed by moving a cursor
5240 over
the location of a particular player 5220.
Turning now to FIG. 53, a user interface window 5300 is shown which
~o illustratively represents a player list table 5310 comprising a player list
view 1208.
As shown, the player list table 5310 includes a Player ID column 5314, a
corresponding Name column 5318, and a Rank column 5320. In the embodiment of
FIG. 53 the Player List Table 5310 includes a Player ID 5324 for all the
patrons
assigned to the player host logged in to the terminal 120 displaying the user
interface
~s window 5300. If an individual having superior viewing rights to the player
host (e.g.,
a manager of multiple player hosts) were instead logged in to the terminal
120, the
Player List Table 5310 would instead contain a list of all player hosts and
associated
patrons. Again referring to FIG. 12, the contents of the user interface window
5000
may be generated by applying a filter to warehouse 226 (step 1224) and
generating
2o the view
FIG. 54 depicts a user interface window 5400 containing a calls list table
5410
comprising one potential implementation of the calls list view 1204. The calls
list
table 5410 is intended to provide a player host with a tabular listing of the
calls to be
made to the players assigned to such host. In the exemplary embodiment the
term
2s "calls" encompasses telephone calls, "in-person" meetings and any other
mode of
contacting or communicating with patrons. As shown, the calls list table 5110
includes a Sch Date column 5414 in which are listed the dates upon which the
applicable host is scheduled to make calls to the corresponding players within
a
Player list 5420. It is noted that although all players associated with the
applicable
3o host will typically be listed within Player List Table 5310, only those
players which
are scheduled to receive calls from the host are identified within the calls
list table
5410. In certain embodiments those scheduled calls within the call list table
5410
38
CA 02486310 2004-10-29
which are "overdue" may be displayed in a different color (e.g, red) than that
used to
display calls which are schedule to occur at a later date. In addition to
being manually
entered within the calls list table 5410, calls to players may also be
scheduled and
added to the calls list table 5410 by other means. For example, a player 5120
within
s the floor diagram pane 5110 may be "right-clicked" and a call to such player
may
then be scheduled.
Again refernng to FIG. 12, the contents of the user interface window 5400
may be generated by applying a filter to warehouse 226 (step 1228) and
extracting the
identities of a set of patrons for which calls have been scheduled and which
meet the
~o other filtering criteria. Such other filtering criteria may be related to
any parameter of
the data contained within the data warehouse 226 (e.g., birthday, gaming
preferences,
Offers sent/redeemed, lodging preferences).
Turning now to FIGS. 55A-55D, a user interface window 5500 containing a
filter patrons dialog 5510 is depicted. The filter patrons dialog 5510 may be
invoked
~ s from within several contexts when it is desired to generate a list of
patrons meeting
various criteria. The use of the filter patrons dialog 5510 in establishing
such criteria
is illustrated by FIGS. 55A-55D.
Referring to FIG. 55A, the filter dialog 5510 is seen to include a Category
column 5514 from which a user is selecting a particular category 5516
applicable to
2o the filtering process. In the exemplary embodiment the categories within
the
Category column 5514 are intended to impose a degree of organization upon the
potentially large list of warehouse measures available for selection as
filtering criteria.
That is, each of these measures is placed into a particular category. This
organizational approach is further illustrated by FIG. 55B, which shows a
particular
2s measure 5520 within the specified category 5516 being selected from a
Measure
column 5524. In FIG. 55C, an arithmetic operator 5530 and a value 5534 have
been
specified for application against the selected measure 5520. In addition, FIG.
SSC
represents the manner in which further measures may be chained to the selected
measure in connection with development of the desired filtering criteria.
Specifically,
3o FIG. 55C depicts a logical operator 5540 being selected, which would define
the
relationship of any next measure 5550 potentially entered within the dialog
5510 to
the measure 5520. In the embodiment of FIG. 55C it has been decided not to
enter
39
CA 02486310 2004-10-29
any such additional measure 5550, and hence the logical operator 5540 is seen
to
comprise the "END" operator. Finally, FIG. 55D illustrates the selection of a
Filter
Calls List button 5554B, which is one of several buttons 5554 which could be
selected
at this juncture in order specify the operations executed in response to the
contents of
s the filter dialog 5510. In this case selection of the Filter Calls List
button 5554B
causes display of a Calls List - Filtered table 5562, which contains a single
entry
5564 corresponding to the results of the filtering process defined by the
dialog 5510.
Turning now to FIG. 56, a user interface window 5600 is depicted which
includes an initial Player Detail View pane 5610. Referring to FIG. 12, the
initial
~o Player Detail View pane 5610 may be caused to appear through execution of a
Load
Player Detail View operation 1232 from the context of each of the views 1204,
1208
and 1210. As shown in FIG. 56, the initial Player Detail View pane 5610 is
displayed
upon selection of a General tab 5614, and enables entry of general contact
information for the applicable patron and the patron's spouse.
~ s If it is decided to define associations between the patron and other
patrons or
non-patrons (e.g., spousal relationships, friendships) (step 1234), then such
relationships may be defined from within the context of the Player Detail View
(step
1236). This definition process is introduced by FIG. 57, which depicts a user
interface window 5700 containing a context menu 5410 displayed upon right-
clicking
2o from within the Player Detail View pane 5610. As shown, a user is in the
process of
selecting an "Add Relationship" entry 5714 from the context menu 5710, which
enables definition of an association with the applicable patron (i.e., the
patron
identified by the Player Detail View pane 5610) in the manner illustrated by
FIGS. 13
and FIGS. 68-70.
2s Referring now to FIG. 13, a flowchart 1300 is provided which illustrates
the
operations involved in making calls upon patrons (step 1240), the scheduling
of such
calls (step 1242) and the definition of associations between patrons (step
1236).
Considering first the sequence of operations involved in performing the patron
association process of step 1236, a search of the records of a patrons data
structure
30 1308 is initially performed (step 1310) as a function of patron
identification number
or name information entered by a user (step 1314). The search results may
yield a list
of one or more registered and unregistered patrons, one of which is selected
by the
CA 02486310 2004-10-29
user (step 1318). If the user decides that it is desired to create an
association between
the selected patron and the patron identified during the Load Player Detail
View
operation 1232 (step 1320), then the association is created and stored within
a player
associations data structure 1324 within the PCS database 112 (step 1322).
s FIGS. 68-70 are a set of screen shots illustrating an exemplary user
interface
through which the player association process 1236 may be effected. Refernng to
FIG.
68, a user interface window 6800 is depicted within which an Add Friends and
Family dialog 6810 has been displayed. The Add Friends and Family dialog 6810
is
the first of multiple dialogs launched upon selection of the Add Relationship
entry
t o from the context menu 5710 (FIG. 57). In the dialog 6810, the user has
selected
Search by Player Name and has begun entering a name within a First Name field
6814. As shown in a user interface window 6900 of FIG. 69, a results table
6910 is
made to appear within the dialog 6810 immediately following selection of a
Search
button 6914. 'The results table 6910 is seen to include an entry 6920 for a
single
is patron matching the search criteria. If other registered patrons had met
the search
criteria, these other patrons would also have had corresponding entries within
the
results table 6910. After deciding that is desired to create an association
between the
patron corresponding to the entry 6920 and the patron identified within the
Player
Detail View pane 6930, an Add button 6634 is enabled and selected by the user.
2o Selection of the an Add button 6934 results in display of a Select
Relationship Type
dialog 7010 within a user interface window 7000 (FIG. 70). In FIG. 70, the
user is
shown selecting from a drop-down list of relationship types 7020 in order to
complete
the association process.
Referring again to FIG. 13, the call making process 1240 is initiated in a
step
2s 1330 by examining a list of scheduled calls (see, e.g., the Calls List -
Filtered table
5562 of FIG. 55D). The telephonic or other call upon the identified patron is
then
made by the responsible player host (step 1332). The host may then elect to
record
the result of the call and note regarding any impressions or observations of
the host
(step 1334), which is illustrated by the user interface window 6700 of FIG.
67. As
3o shown, the window 6700 includes a Make a Call dialog 6708 displayed upon
selection of a Make Contact button 6710 from a Contact History tab 6?14. In
FIG.
67, the user is in the process of entering information within a Notes field
6720
41
CA 02486310 2004-10-29
pertinent to the applicable call. If it is decided to save this information
once entered
(step 1336), then it is stored within a contact history data structure 1350
(step 1338).
See also the user interface window 6400 of FIG. 64, which contains a Contact
Info
sub-pane through which is displayed information from the contact history data
s structure 1350.
Again referring to FIG. 13, the call scheduling process 1242 is initiated by
assigning a host a particular call desired to be made upon or to a patron
(step 1350).
This essentially entails selecting, typically from a filtered list of patxons,
those patrons
for which it is desired to schedule calls. This is illustrated by the user
interface
to window 6500 of FIG. 65, which includes a Schedule Calls dialog 6510. The
dialog
6510 is launched by clicking upon a Schedule Call button 6410 (FIG. 64)
subsequent
to selection of the Contact History tab 6414. In FIG. 65, the dialog 6510 has
opened
with default values present within a scheduled date field 6518 (i.e., the
current date)
and a Name field 6520 (i.e., the name of the open patron). In this case a call
is being
is scheduled only for the patron that is "open" or displayed; however,
information
regarding the entire series of patrons would be displayed via the Schedule
Calls dialog
6510 if more than one customer were selected.
As is indicated by FIG. 13, a scheduled date and purpose for the call is then
entered (step 1354), which is illustrated by the user interface window 6600 of
FIG.
20 66. In this case the user has entered a purpose for the scheduled call
within a Purpose
field 6610 of FIG. 66. In addition, the user is in the process of using a drop
down
calendar 6620 to modify the date of the call within a scheduled date field
6630. If it is
decided to save this information once entered (step 1360), then it is saved to
a calls
list 1364 stored within the PCS database 112 (step 1368).
2s Referring again to FIG. 12, stated gaming preferences provided by a patron
may be entered via the user interface window 5800 of FIG. 58 and stored as
stated
gaming preferences within the gaming preferences data structure 1116a (step
1240).
In FIG. 58, selection of a Gaming tab 5810 results in display of a primary
pane 5814
containing a Player Stated Prefs sub-pane 5816 in which is entered the gaming
3o preferences articulated or otherwise provided by a patron. Within the sub-
pane 5816,
a user is seen to be in the process of selecting among many Table Game options
listed
within drop-down menu 5818. The user may also enter additional table game, bet
and
42
CA 02486310 2004-10-29
skill information within the sub-pane 5816, as well information relating to as
slot
games based upon the information provided by the applicable patron (i.e., the
patron
identified within the Player Detail View pane 5610).
As is indicated by FIG. 12, observed gaming preferences for the applicable
s patron are calculated based upon the actual gaming preference data for the
patron
maintained within the PCS database 112 (step 1244) and may then be displayed
(step
1246). In the exemplary embodiment this actual gaming preference data is "pre-
calculated" based upon preferences information for the applicable patron
accessed
from the data warehouse and stored within the gaming preferences data
structure
~0 1116a. In FIG. 59, various obsen~ed gaming preferences for the applicable
patron
may be viewed through the user interface window 5900. As shown, the user has
selected from among various warehouse measures, and has also actuated a
Refresh
button in order to update the displayed information. The user interface window
5900
advantageously provides significant information as to the activities of the
applicable
~ s patron on the floor of the gaming establishment.
Gaming history for the applicable patron is also calculated based upon gaming
history information maintained within a gaming history data structure 1120a of
the
transaction summaries component 1120 (step 1250). In the exemplary embodiment
gaming history may comprise, for example, the play history, revenues,
reinvestment
2o information, number of trips or visits, theoretical win, actual win, as
well as more
specific gaming results for slots and table games, associated with the
applicable
patron. These historical gaming results may be represented as a function of
time in
the manner illustrated by FIG. 60 (step 1254), which depicts a user interface
window
6000 having a Play History panel 6010 that is displayed upon selection of a
Play
2s History tab 6020. An upper portion 6030 of panel 6010 includes information
identifying the applicable patron, while a lower panel portion 6034 includes a
revenue/reinvestment table 6040. As shown, the revenue/reinvestment table 6040
contains revenue and reinvestment measures organized as a function of time.
This
information is typically displayed in a "read-only" format and is intended to
permit
so users to analyze the revenues and costs associated with the applicable
patron.
Referring again to FIG. 12, dining and leisure preferences for the applicable
patron may also be entered (step 1258). FIG. 58 illustrates a user interface
window
43
CA 02486310 2004-10-29
6104 containing a Dining pane 6110 that is displayed upon selection of a
Dining tab
6120. In this case a user has entered information within a Patron Dining Prefs
field
6130, a Patron Dining Dislikes field 6134, a Patron Comments field 6138 and a
Patron Beverage and Tobacco Preyrences field 6140. Similarly, FIG. 62 depicts
a
s user interface window 6200 including a Leisure pane 6210 that is displayed
upon
selection of a Leisure tab 6220. As shown, the Leisure pane 6210 includes a
number
of fields through which patron preferences regarding leisure activities may be
entered
or updated.
As is illustrated by FIG. 12, the PCS database 112 includes an Offers data
~ o structure 1262 containing information regarding Offers associated with the
patron
identified within the Player Detail view pane 5610. The information within the
data
structure 1262 characterizes each such Offer as either active or inactive
(i.e., utilized
or expired), along with the value and redemption amount thereof. In addition,
aggregate Offer values and redemption amounts are also maintained for the
applicable
~ s patron. This Offer information for the applicable patron is calculated
based upon the
information within the data structure 1262 (step 1266) and then may be
displayed
(step 1270). FIG. 63 depicts a user interface window 6300 containing an Offer
pane
6310 displayed upon selection of an Offer tab 6320. As shown, information
regarding
Offers sent to the applicable patron may be viewed through the Offer pane
6310.
2o Information regarding active Offers is presented through an Active Offers
sub-pane
6330, while information pertaining to inactive Offers is conveyed via an
Inactive
Offers sub-pane 6334. An additional sub-pane 6350 provides information
concerning
Offer revenue and redemption information.
Turning again to FIG. 12, contact history information 1272 relating to the
2s contacts made with the applicable patron (e.g., telephone calls from a
player host to
the patron) may be loaded (step 1274) and displayed upon request of a user
(step
1278). The contact history information 1272 may comprise the player host or
other
individual initiating the contact with the patron, the date of the contact, as
well a
summary of the result of the contact. FIG. 64 shows a user interface window
6400
3o containing a Contact History pane 6408 that is displayed upon selection of
the
Contact History tab 6414. As may be appreciated with reference to FIG. 64, a
user
44
CA 02486310 2004-10-29
may review the contact history information far the applicable patron that is
displayed
through the Contact History pane 6408.
In the exemplary embodiment of FIG. 12, the contents of the PCS database
112 are updated regularly (e.g., daily) with information from the data
warehouse 226.
s For example, the gaming preferences data structure 1116a may include
information
relating to the type of slot machines the applicable patron frequently plays,
whether
the patron tends to play other games (e.g. , Blackjack and then Baccarat)
before or
after playing slots, the denominations typically used, and similar
information. This
information will generally be updated on a daily basis so as to accurately
reflect the
Io current gaming preferences of the applicable patron.
As shown in FIG. 12, patron general data component 1108 includes a Patrons
data structure 1282 and a Player Detail data structure 1286. The Patrons data
structure 1282 preferably comprises of a list of the account numbers for
registered
patrons and is linked to the other data structures within the PCS database
112. The
~ s Player Detail data structure 1286 includes various identifying information
pertaining
to each patron (e.g., address, phone number).
Turning now to FIG. 14, a flowchart is provided of an exemplary statistical
analysis routine 1400 which may be employed in connection with the analysis of
data
accumulated by the player contact system. Execution of the routine 1400
enables a
zo user (e.g., a patron host or host manager) to view the activity or gaming
performance
of specified patrons. The routine 1400 may be applied to a complete or
filtered set of
the patrons associated with particular host(s), and facilitates comparison of
performance over different date ranges. That is, date range parameters may be
specified in order to define different periods of interest, and variance in
performance
2s then computed between the defined periods. Either standard or "custom"
periods may
be defined by entering desired date ranges (step 1410). In the exemplary
embodiment
performance results may be pre-calculated for various standard periods (e.g.,
month-
to-date, year-to-date, week-to-date, etc.). FIG. 71 depicts a screen shot of a
user
interface window 7100 containing a Statistical Analysis pane 7110 through
which
3o such standard and custom periods may be defined. In FIG. 68, a user is in
the process
of entering a date within a Start field 6812 for the first date range, i.e.,
Range One
7114, of a customized period. As shown, the user may also enter startlend date
CA 02486310 2004-10-29
information defining a second period, i.e., Range Two 7120. By default, any
reports
generated based upon the contents of the user interface window 7100 will be
predicated upon the set of patrons assigned to the user (e.g. patron host)
currently
logged in.
s Refernng again to FIG. 14, upon selection of a Calc button 7130 (FIG. 71) an
MDX query is generated based upon the information entered through the
Statistical
Analysis pane 7110 (step 1420). After passing through interface 1430, the MDX
query is applied to rnulti-dimensional data storage 228. In response, data
concerning
the subset of patrons specified by the query is reported to the interface
1430. FIG. 72
t o shows a screen shot of a user interface window 7200 in which a Calc button
7230 of a
Statistical Analysis pane 7210 has just been selected. As shown, the user has
selected
the system-defined date ranges of "Last Month" for Range One 7214 and "Month
to
date" for Range Two 7220. The presence of the Statistical Calculation pop-up
7228
having progress bar 7230 indicates that calculations necessary for generation
of a
is report are being performed. In FIG. 73, a screen shot of a user interface
window 7300
is depicted in which the Statistical Analysis pane 7310 displays a report 7320
of the
type which could result from similar such calculations. As shown, the report
7320
includes a Revenue & Reinvestment column 7330 containing multiple revenue and
reinvestment measures. Corresponding statistical data is shown in subsequent
2o columns, including a Custom Date (Rl) column 7350 for the first date range,
a
Custom Date (R2) column 7354 for the second date range, a Variance (Rl-R2)
column 7060 reflective of the variance between the results of like kind for
the two
date ranges, and a Yariance% column 7364 indicative of the corresponding
variance
percentage..
zs I. Patron Locator arid PCS Data Visualization
FIG. 15 is a flowchart illustrating a patron locator and data visualization
process 1500 pertinent to the player contact system. In the embodiment of FIG.
15, it
is contemplated that the process 1500 will be executed primarily by the PCS
module
216 and the PCS client module 350. As shown, the interaction occurring with
the
3o PCS database 112, data warehouse 226 and an external mapping server 1506
during
the data visualization process is also illustrated in FIG. 15 in order to more
fully
elucidate this process. In the exemplary embodiment the data visualization
process
46
CA 02486310 2004-10-29
1500 may be utilized in connection with providing a visual representation of
the
location of specified patrons or Segment members on the "floor" of the
applicable
gaming establishment.
As initial step 1510 in the process 1500, the floor layout of the applicable
s gaming establishment (i.e., the relative position and arrangement of the
various
gaming tables and devices) is geocoded into a predefined format and provided
to the
external mapping server 1506 for use as map layer source data 1514. The
process
1500 also operates upon patron location data obtained from a property source
system
1518 within the transactional databases 108. Such source system 1518 will
often
to comprise a slot accounting system, which contains information as to the
locations of
registered patrons within the gaming establishment (e.g., patron #A currently
playing
slot machine #X). This patron location information from the property source
system
1518 is transferred through an interface 1522 and stored within a Players on
Floor
table 1526 within memory 212 of the server 104. In the exemplary embodiment
the
is data from the Players on Floor table 1526 and PCS databases 112 is either
pushed to
the PCS client module 350 or provided upon request. The PCS client module 350
may then invoke an appropriate mapping service from the external mapping
server
1506, join the information provided by the mapping service with attribute data
furnished by the PCS databases 112, and generate reports facilitating the
analysis of
20 location and/or attributes of specified patrons.
In one embodiment the external mapping server 1506 may be commercially
operated by a third party engaged in providing geographic information systems
(GIS)
and other mapping services to Internet-enabled client browsers. For example,
ESRI
(http://www.esri.com/software/arcims/index.html) operates an ArcIMS Server
which
2s facilitates access to, and interaction with, Internet mapping and GIS data
from a Web
browser.
Refernng to FIG. 15, the data visualization process 1500 is initiated through
issuance of a request to the PCS database for data relating to a particular
patron or
Segment population (step 1530). Once this data has been received or pending
its
3o receipt, the external mapping server 1506 is queried (step 1532) and
location
information concerning the identified area of the floor of the gaming
establishment is
returned (step 1536). The returned geographic data is then joined with the
data
47
CA 02486310 2004-10-29
received from the PCS database 112 and/or data warehouse 226 that is specific
to the
patron or Segment population of interest (step 1540). At this point the
resultant
localized geographic representation of the Segment data may be spatially
analyzed in
the manner described below (step 1550). FIG. 15 also indicates that the
results of the
s spatial analysis of the mapped patron data (step 1550) may be further used
to create
one or more reports. For example, in the embodiment of FIG. 15 a Feature
Analysis
report 1560 and an Attribute Analysis report 1564 may be generated.
FIGS. 74-76 depict user interface windows through which certain aspects of
spatial analysis of mapped Segment data may be performed. Refernng to FIG. 74,
a
~ o user interface window 7400 containing a primary pane 7410 is depicted. In
the
exemplary embodiment the user interface window 7400 is loaded upon selection
of a
particular button (not shown) from toolbar 7420. In FIG. 74, the user is in
the process
of previewing a map of the floor of the applicable gaming establishment though
primary pane 7410. The user has also moved a mouse pointer 7430 over a
highlighted
is stand 7440 in order to ascertain the identity 7450 of the patron currently
interacting
with the device at the stand 7440. In the user interface window 7500 of FIG.
75, an
interactive mapping tool (i.e., a zoom tool 7510) is being used to specify a
smaller
map extent 7520, from which a new map may be rendered.
FIG. 76 provides another example of the manner in which interactive mapping
2o tools may be used. As shown, FIG. 76 depicts a user interface window 7600
containing a primary pane 7610 and a patron list pane 7620. In FIG. 76 a user
has
caused the representation 7630 of a particular patron within the primary pane
7610 to
be highlighted by selecting the patron's name 7640 from a table 7650 within
the
patron list pane 7620. In the exemplary embodiment the representation 7630 may
2s take the form of a large flashing red dot, thus providing a readily
discernible visual
indicator of the location of the applicable patron within the gaming
establishment.
J. Report Writer
The report writer module 224 is configured to process both transactional and
analytical data processed by the player contact system. In the exemplary
embodiment
3o the report writer module 224 uses industry-standard XML to define the
format and
layout of reports, as well as to define the columns and selection clauses that
control
the displayed data points.
48
CA 02486310 2004-10-29
In the case of analytical data, the report writer module 224 (i) defines base
levels of information, and (ii) provides an interactive client that allows a
user to drill
down into the data and print a report from the selected data level of the
interactive
client as fomatted hard-copy.
s During operation, the report writer module 224 provides a user with lists of
the
dimensions and measures available to them in connection with a desired report.
The
user then "drags" the dimensions into the "X" and "Y" positions depicted via
display
device 320 of a user computer120, and also drags the measures into the display
section provided. The report writer module 224 also provides for multiple
~o dimensions, as well as the ability to "drill down" into a dimension for
further
clarification (e.g., in the case of a report with "time" as one of the
dimensions, a user
would be capable of drilling down from "Year" into "Quarter" into "Month" into
"Day"). The comprehensive reports and visualization tools provided by the
exemplary embodiment of the system 100 described herein facilitate
understanding of
is customer demographic information. This information can be used to develop
new
marketing campaigns and adjust the focus of existing campaigns.
K. PCS Bonusing
FIG. 16 is an overview of a computing environment in which a PCS bonusing
2o system 1600 of the present invention may be embodied. In the environment of
FIG.
16, the system 1600 is implemented with a central server 1604 disposed to
interface
with transactional databases 1608, a patron contact system (PCS) database
1612, with
one or more user computers 1620 and with one or more programmable handsets
1622.
The central server 1604 communicates with the transactional databases 1608,
PCS
2s database 1612, user computer 1620 and programmable handset 1622 over a
computer
network 1624 (e.g., the Internet or a local area network (LAN)).
As shown in FIG. 16, the computing environment of the PCS bonusing system
1600 in the present embodiment is an extension of the computing environment of
the
business information processing system 100 described with reference to FIG. 1.
3o Specifically, the transaction database 1608, the central server 1604 and
the PCS
database 1612 perform the same general functions of the transactional
databases 108,
49
CA 02486310 2004-10-29
the central server 104 and the PCS database 112 in addition to functions
associated
with the PCS bonusing system 1600.
The PCS module 1616 of the system 1600 is designed to provide a mechanism
for system users of a commercial establishment (e.g., the staff of a casino)
to provide
s bonuses to patrons based upon both the patrons' historical and substantially
current
transaction activity while the patrons are within the establishment. In the
present
embodiment, the PCS module 1616 interoperates with the transactions database
1608
to obtain substantially current or "real time" activity of a patron, and
interoperates
with the data warehouse 1626 and the PCS database 1612 to obtain historical,
preference and other information (e.g., metrics) in much the same way as the
PCS
module 216 described with reference to FIG. 11. In addition, the PCS module
1616 in
the present embodiment is also configured to access a profile database 1630
and an
award database 1632 in the PCS database 1612.
The profile data base 1630 stores a collection of established profiles that
are
~s created to help classify patrons based upon their current and or historical
gaming
activity. As discussed herein each profile in the profile database 1630 is
provided a
value so that each profile may be associated, based at least in part upon the
value of
the profile, with one or more potential awards in the award database 1632. In
one
embodiment for example, the award database 1632 includes a collection of
awards
2o and several awards may be correspond to a particular profile. In this way,
when a
patron fits within a particular profile, the PCS module 1616 may select, from
among
many potential awards for that particular profile, one award based upon the
patron's
current and/or historical activity.
In the present embodiment, the transactional databases 1608 include a gaming
2s system database 1634, which stores data representative of the patron's
current
activity. As discussed herein, substantially current or "real time" data
utilized by the
PCS bonusing system 1600 is retrieved from the gaming system database 1634.
For
example, a patron's current activity and location may be established by
tracking a
patron identification card encoded with a patron identification number
uniquely
3o identifying the patron. When the patron inserts the patron tracking card in
a card
reader prior to playing the associated gaming device, the card reader reads
the patron
identification number off the card and informs the central server 1604 of the
patron's
CA 02486310 2004-10-29
subsequent gaming activity. This enables individual patron usage to be
monitored by
associating dated records from the gaming device with patron identification
numbers.
As a patron interacts with a gaming device and/or visits a hotel, interaction
or other
transactional data is generated, collected and stored within the gaming system
s database 1634. The collected data could be stored within a number of records
within
a relational database structure of the gaming system database 1634.
As shown in FIG. 16 the functionality of the system 1600 may be accessed by
users (e.g., operators of casinos) via one of the user computers 1620 and/or
programmable handset 1622. In the present embodiment, the user computers 1620
and programmable handset 1622 include the same functional components as the
user
computer 120 schematically represented in FIG. 3 except that the PCS client
module
350 is adapted to provide an interface for users to generate profiles, input
award types
and receive a list of proposed awards as described herein.
Referring next to FIG. 17, shown is a data flow diagram 1700 illustrating the
~ s interaction among various functional components comprising an exemplary
embodiment of the PCS bonusing system 1600. While referring to FIG. 17
simultaneous reference will be made to FIG. 18, which is a flowchart
illustrating steps
carried out by the PCS bonusing system 1600 according to an exemplary
embodiment.
2o As may be appreciated by reference to FIGS 16-17, the data flow and
functionality described with reference to FIG. 17 may be effected by various
combinations of modules and elements disposed at the user computers 1620,
programmable handsets 1622 and central server 1604. The precise division of
functionality between the modules within the user computers 1620, programmable
2s handset 1622 and the modules within the central server 1604 is not critical
to the
present invention, and various embodiments of the invention may be predicated
upon
different distributions of functionality between the central server 1604 and
the user
computers 1620 and/or programmable handsets 1622. Accordingly, references in
the
description below to the modules within the central server 1604 (e.g., the PCS
module
30 1616) are not necessarily intended to be directed exclusively to such
modules, and
should be construed as being applicable to embodiments in which the relevant
51
CA 02486310 2004-10-29
functionality is implemented in cooperation with complementary modules
disposed
within the user computers 1620 and/or programmable handsets 1622.
As shown in FIG. 17, a profile builder component 1740 is disposed to allow
users to define profiles that are associated with corresponding profile
valuations (Step
s 1802). A user is able to define profiles via the customer profile
configuration
component 1742 which provides an interface with the profile builder component
1740. The customer profile configuration component 1742 may implemented as a
new menu item within the player contact system.
In an exemplary embodiment, the profile builder component 1740 enables
2 o profiles to be defined based upon both current activity and historical
transaction
information. Each of the defined profiles are then associated with a
particular value
(e.g., a measure of worth) and stored in the profile database 1630. The number
of
profiles created will vary depending upon the establishment, but it is
contemplated
that just a few or more than twenty profiles may be utilized. In one
embodiment, the
is profile builder component 1740 associates values with particular profiles
by
calculating a monetary value for each profile. In this way, an establishment
may
create customized profiles with information that more accurately reflects the
value of
patrons (from the perspective of the establishment) that fall within each
profile.
2o In an exemplary embodiment, one or more profiles include an
inflator/deflator
of award value. The inflator/deflator concept is simply a process of boosting
or
diminishing a baseline award value based on a player's specific profile
characteristics
(e.g., characteristics that are not worth based, but demographic or other,
like a
birthday, anniversary or first trip). For example, there may be a base award
of $20 for
2s players that meet a set of criteria (e.g. $500 theoretical in a day);
however, a particular
player may also be a "Diamond" level patron, and would therefore qualify for
$20
plus X (i.e., an inflated amount).
As shown in FIG. 17, an award configuration portion 1744 provides an
interface to an award entry module 1746 which allows a user to define a
variety award
3o types (Step 1804). Awards may be defined by various terms including room
compensation, cash and food. In the present embodiment, the awards are also
defined
in terms of a monetary value (e.g., retail and/or actual cost) to the
establishment (e.g.,
52
CA 02486310 2004-10-29
a casino). Once defined, the award types are stored in an awards database 1632
for
later access as discussed herein.
As shown in FIG. 17, a patron database 1748 within the PCS database 1612 is
maintained, which stores patron information relating to patrons of an
establishment
s and historical information involving the patrons (Step 1806). In addition,
substantially current transaction activity of a patron is monitored and stored
in the
gaming system database 1634 (Step 1808). The current transaction activity is
loaded
into the patron database 1748 along with demographic and historical data from
the
data warehouse 1626.
~o In an exemplary embodiment, the gaming system database 1634 is realized by
a combination of the slot accounting database 420 and the player tracking
database
424 described with reference to FIGS. 4 and 5. It should be recognized
however, that
the gaming system database 1634 may be effected by a separate single data
base.
Some examples of substantially current transaction activity include an amount
t s of gaming activity during a present trip, substantially current winnings
and other
activities a patron has engaged in during the most recent trip (e.g., the last
several
minutes). For example, among other information the gaming system database 1634
may store information about a jackpot just won by a patron, the location and
type of
the patron's most recent meal and a grand total the patron has expended during
the
2o day and the trip.
Examples of historical data include stated preferences, observed preferences,
and historical gaming metrics. Some historical gaming metrics include, number
of
visits to the applicable casino, theoretical win (i.e., the product of the
aggregate
amount of money exchanged during playing of a given game and the percentage of
2s such aggregate amount expected to be retained by the applicable casino
installation),
average theoretical win per visit, actual win/loss for slot machines and table
games,
and amount of compensatory products and services ("comps") consumed (e.g.,
room,
food, show tickets, and travel), revenues, and reinvestment information.
As shown in FIG. 17, a profile assignment module 1750 is coupled to receive
3o historical and substantially current transaction information from the
patron database
1748. Based upon the historical and substantially current transaction
information for
a particular patron, the profile assignment module assigns one of the profiles
from the
53
CA 02486310 2004-10-29
profile database 1630 to that particular patron (Step 1810). In an exemplary
embodiment, a patron's activity is polled on an ongoing basis at a regular
interval to
establish whether the patron qualifies for a new profile. When the patron
qualifies for
a new profile, the profile assignment module 1750 applies a new profile to
them. For
s example there might be 15-20 players in an establishment and the profile
assignment
module 1750 will continually poll those player's respective activities to see
if they
qualify for a new profile. It should be recognized that a patron need not have
a profile
to be tracked. For example, a patron without a profile may be tracked, and
once they
qualify for a profile based upon their activity (e.g., historical and current
activity),
~ o they may be assigned a profile and an award.
As shown in FIG. 17, an award matching module 1754 receives the patron
profile information from the profile assignment module 1750 and matches at
least one
award from the awards database 1632 to the patron based at least in part upon
the
relative values of the awards and the profile assigned to the patron (Step
1812).
is In an exemplary embodiment, several awards with a value appropriate for the
profile of the patron are matched to the patron, and data in the patron
database 1748 is
used to sort the awards based upon the likelihood of the patron accepting each
award.
For example, a set of possible awards may be matched with the patron's
profile, and
based upon the patron's historical preferences (e.g., stated and observed
preferences,
2o and the patron's past refusals and acceptances) and/or current activities,
recommendations are made to a system user (e.g., a casino employee) as to
which
award they should offer to the patron. For instance, three awards may match
the
profile of a particular patron: a buffet for two, cafe for one, or a
discounted room;
however, one of them may be highlighted (e.g., in green) because that is the
award
2s that the patron (based on their historical behavior) is most likely to
appreciate.
As a further example of the role a patron's preferences may play, if a patron
always stays in the hotel (of the establishment using the bonusing system
1600),
always pays full rack rate and is in the hotel again when they qualify for an
award,
then the patron may be offered a discounted rate or a free room. If, however,
the
3o patron never eats in the buffet and typically eats in the cafe, then the
bonusing system
1600 may recommend giving the patron a free cafe comp.
54
CA 02486310 2004-10-29
As an example of the role the patron's current activities plays, if the patron
has
already been to the cafe on a particular day, the PCS bonusing system 1600 may
not
recommend a cafe comp again on that day. As another example, if it is 3:00
o'clock
in the afternoon and a patron has been in the establishment for 20 minutes,
something
s other than a food award may be offered. It should be recognized that the PCS
bonusing system is in no way limited to the preceding examples, which are only
intended to convey that the PCS bonusing system is able to tailor awards based
upon
historical and current preferences/activities.
As shown in FIG. 17, the awards matched to the patron are then displayed
~0 1756 for system users at one of the user computers 1620 and/or programmable
devices 1622. The patron locator and visualization process 1500 described with
reference to FIG. 15 may be utilized in connection with the list of potential
awards so
that system users may easily locate a patron and personally offer them an
award. In
one embodiment scripting that describes how to deliver the award is displayed
along
~s with the collection of potential awards. In this way, personnel of the
establishment
that do not have the experience of executive hosts, for example, are given a
list
potential awards as well as directions so that they may feel more comfortable
and
confident when offering an award.
After one or more awards are matched to the patron, the patron is offered one
20 or more of the awards (Step 1814). In an exemplary embodiment, the steps of
matching an award (Step 1812) and offering the award to the patron (Step 1814)
are
triggered by specific events. For example, a patron's qualification for a new
profile
may trigger the assignment of one or more awards to the patron. Other events
that
trigger the offering of an award may include the patron winning a jackpot, the
patron
2s reaching a level of gaming activity during a present trip, the patron's
substantially
current winnings reaching a threshold and other activities.
If the award is accepted (Step 1816), then the patron is issued an award
certificate (e.g., paper and/or electronic) (Step 1820), and the acceptance is
recorded
in the PCS database (Step 1822). If the award is not accepted (Step 1816),
then the
so refusal is recorded in the PCS database 1612 (Step 1818). In this way, if a
particular
award is offered (e.g., a room) and the patron declines the award, then an
indication
that the patron declined that award type is placed in the player contact
system
CA 02486310 2004-10-29
database 1612 so that in the future, when the PCS bonusing system 1600 is
assembling a collection of award types to be offered to the patron, the fact
that the
patron has already said no to an offer (e.g., of a room) may be taken into
consideration. For example, if a patron has previously declined an award
(e.g., of a
s room), then the declined award may still be available at a later time to
offer to the
patron, but another award may be highlighted so the declined award is riot the
first
award offered again.
The foregoing description, for purposes of explanation, used specific
nomenclature to provide a thorough understanding of the invention. However, it
will
~ o be apparent to one skilled in the art that the specific details are not
required in order to
practice the invention. In other instances, well-known circuits and devices
are shown
in block diagram form in order to avoid unnecessary distraction from the
underlying
invention. Thus, the foregoing descriptions of specific embodiments of the
present
invention are presented for purposes of illustration and description. They are
not
~ s intended to be exhaustive or to limit the invention to the precise forms
disclosed,
obviously many modifications and variations are possible in view of the above
teachings. The embodiments were chosen and described in order to best explain
the
principles of the invention and its practical applications, to thereby enable
others
skilled in the art to best utilize the invention and various embodiments with
various
2o modifications as are suited to the particular use contemplated. It is
intended that the
following Claims and their equivalents define the scope of the invention.
56
