U.S. patent application number 10/562411 was filed with the patent office on 2007-07-26 for gaming network environment providing a cashless gaming service.
This patent application is currently assigned to WMS GAMING INC.. Invention is credited to Srinivyasa M. Adiraju, Chad A. Ryan, Vikram Swamy.
Application Number | 20070173322 10/562411 |
Document ID | / |
Family ID | 33551956 |
Filed Date | 2007-07-26 |
United States Patent
Application |
20070173322 |
Kind Code |
A1 |
Swamy; Vikram ; et
al. |
July 26, 2007 |
Gaming network environment providing a cashless gaming service
Abstract
A gaming network including gaming machines and gaming services
further includes a cashless gaming service that provides systems
and methods for funds transfer in and out of a users account
between clients in the gaming network. The gaming services
framework comprises a set of services, protocols, XML schemas, and
methods for providing gaming system functionality in a distributed,
network based architecture that includes gaming machines and
servers. The systems and methods provide a service-oriented
framework for gaming and property management based upon
internetworking technology and web services concepts.
Inventors: |
Swamy; Vikram; (Chicago,
IL) ; Ryan; Chad A.; (Henderson, NV) ;
Adiraju; Srinivyasa M.; (Vermon Hills, IL) |
Correspondence
Address: |
SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH/WMS GAMING
P.O. BOX 2938
MINNEAPOLIS
MN
55402
US
|
Assignee: |
WMS GAMING INC.
800 SOUTH NORTHPOINT BLVD.
WAUKEGAN
IL
60085
|
Family ID: |
33551956 |
Appl. No.: |
10/562411 |
Filed: |
June 23, 2004 |
PCT Filed: |
June 23, 2004 |
PCT NO: |
PCT/US04/20149 |
371 Date: |
March 19, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60480929 |
Jun 23, 2003 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
G07F 17/3237 20130101;
G07F 17/32 20130101; G07F 17/3234 20130101; G07F 17/3255 20130101;
G07F 17/3281 20130101 |
Class at
Publication: |
463/042 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for providing a cashless gaming service in a gaming
network including gaming machines, the method comprising:
publishing an availability of the cashless gaming service on the
gaming network; receiving a discovery request for the cashless
gaming service; registering by a gaming client with the cashless
gaming service; and processing one or more service requests between
the gaming client and the cashless gaming service, said service
requests conforming to an internetworking protocol.
2. The method of claim 1, wherein the cashless gaming service
comprises a web service.
3. The method of claim 2, wherein the service request is formatted
according to a service description language.
4. The method of claim 3, wherein the service description language
is a Web Services Description Language (WSDL).
5. The method of claim 2, wherein the cashless gaming service is
registered in a UDDI registry.
6. The method of claim 1, wherein the gaming client comprises a
gaming machine.
7. The method of claim 1, wherein the gaming client comprises a
service provider.
8. The method of claim 1, wherein the service request comprises an
HTTP request encapsulating an OFX message.
9. The method of claim 1, wherein the service request comprises a
request to establish a new account.
10. The method of claim 1, wherein the service request comprises a
request to modify details for an account.
11. The method of claim 1, wherein the service request comprises a
request to close an account.
12. The method of claim 1, wherein the service request comprises a
request to provide details for an account.
13. The method of claim 1, wherein the service request comprises a
request to obtain an account balance.
14. The method of claim 1, wherein the service request comprises a
request to obtain a list of transactions associated with an
account.
15. The method of claim 1, wherein the service request comprises a
request to deposit funds into an account.
16. The method of claim 15, further comprising electronically
transferring funds from an external account into the account.
17. The method of claim 16, further comprising obtaining
authorization prior to electronically transferring funds.
18. The method of claim 1, wherein the service request comprises a
request to withdraw funds from an account.
19. The method of claim 18, further comprising transferring the
withdrawn funds as a playable credit on a gaming machine.
20. The method of claim 1, wherein the service request comprises a
request to deposit promotional credits into an account.
21. The method of claim 1, wherein the service request comprises a
request to withdraw promotional credits from an account.
22. The method of claim 1, further comprising authenticating the
gaming client to determine if the gaming client is authorized to
receive cashless gaming services.
23. A gaming network system, the gaming network system comprising:
a gaming client communicably coupled to the gaming network; and a
cashless gaming service communicably coupled to the gaming network
and operable to: publish an availability of the cashless gaming
service on the gaming network; register a gaming client with the
cashless gaming service; and process one or more service requests
between the gaming client and the cashless gaming service, said
service requests conforming to an internetworking protocol.
24. The gaming network system of claim 23, wherein the cashless
gaming service comprises a web service.
25. The gaming network system of claim 23, wherein the service
request is formatted according to a service description
language.
26. The gaming network system of claim 25, wherein the service
description language is a Web Services Description Language
(WSDL).
27. The gaming network system of claim 23, wherein the cashless
gaming service is registered in a UDDI registry.
28. The gaming network system of claim 23, wherein the gaming
client comprises a gaming machine.
29. The gaming network system of claim 23, wherein the gaming
client comprises a service provider in the gaming network.
30. The gaming network system of claim 23, wherein the service
request comprises an HTTP request encapsulating an OFX message.
31. The gaming network system of claim 23, wherein the service
request comprises a request to establish a new account.
32. The gaming network system of claim 23, wherein the service
request comprises a request to modify details for an account.
33. The gaming network system of claim 23, wherein the service
request comprises a request to close an account.
34. The gaming network system of claim 23, wherein the service
request comprises a request to provide details for an account.
35. The gaming network system of claim 23, wherein the service
request comprises a request to obtain an account balance.
36. The gaming network system of claim 23, wherein the service
request comprises a request to obtain a list of transactions
associated with an account.
37. The gaming network system of claim 23, wherein the service
request comprises a request to deposit finds into an account.
38. The gaming network system of claim 23, wherein the cashless
gaming service is further operable to electronically transfer funds
from an external account into an account.
39. The network system of claim 38, wherein the cashless gaming
service is further operable to obtain authorization prior to
electronically transferring funds.
40. The gaming network system of claim 23, wherein the service
request comprises a request to withdraw funds from an account.
41. The gaming network system of claim 23, wherein the service
request comprises a request to deposit promotional credits into an
account.
42. The gaming network system of claim 23, wherein the service
request comprises a request to withdraw promotional credits from an
account.
43. The gaming network system of claim 23, further comprising an
authentication service operable to authenticate the gaming client
to determine if the gaming client is authorized to receive cashless
gaming services.
44. The gaming system of claim 43, wherein the authentication
service includes an LDAP authentication service.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application Ser. No. 60/480,929 entitled "CASHLESS GAMING
SERVICE IN A SERVICE-ORIENTED GAMING NETWORK ENVIRONMENT", filed
Jun. 23, 2003; and is related to U.S. patent application Ser. No.
10/788,903, entitled "A SERVICE-ORIENTED GAMING NETWORK
ENVIRONMENT", (Attorney Docket 1842.020US 1), filed on Feb. 26,
2004 and assigned to the same assignee as the present application;
each of which are hereby incorporated by reference herein for all
purposes.
FIELD
[0002] The present invention relates generally to software and
hardware systems for gaming machines and gaming machine networks,
and more particularly to providing a cashless gaming service in a
service-oriented gaming network environment.
BACKGROUND
[0003] Today's gaming terminal typically comprises a computerized
system controlling a video display or reels that provide wagering
games such as video and mechanical slots, video card games (poker,
blackjack etc.), video keno, video bingo, video pachinko and other
games typical in the gaming industry. In addition, support
computing systems such as accounting, player tracking and other
"back office" systems exist in order to provide support for a
gaming environment.
[0004] In order to prevent players from becoming bored, new
versions of wagering games, and alterations to existing games are
constantly being developed. In the past, the game software and
content for gaming terminals and back office systems have been
developed using proprietary or closed hardware, operating systems,
application development systems, and communications systems.
Sometimes these systems are provided by a single vendor.
[0005] Additionally, gaming machines typically require a means to
accept funds in order to make wagers during the game. In previous
systems, gaming machines provide coin, token and bill acceptors and
ticket readers in order to accept finds. However, this can be
inconvenient to the player because the player must carry coins,
tokens, bills or tickets in order to use the gaming machine.
Unfortunately, due to the proprietary and closed nature of existing
architectures, it can be difficult to develop new games, and it is
difficult to modify existing proprietary game architectures to
include support for cashless gaming. As a result, the cost and time
associated with updating and adding new games or modifying existing
games in gaming networks is relatively high.
[0006] In view of the above-mentioned problems and concerns, there
is a need in the art for the present invention.
SUMMARY
[0007] The above-mentioned shortcomings, disadvantages and problems
are addressed by the present invention, which will be understood by
reading and studying the following specification.
[0008] One aspect of the systems and methods relates to providing a
cashless gaming service in a gaming network. The gaming network may
comprise gaming machines, service providers, and other entities.
The cashless gaming service may provide a web based service for
transferring funds in and out of a user account with a gaming
establishment. The entities participating in the gaming network may
implement a Gaming Services Framework using the World Wide Web and
internetworking technology. The World Wide Web ("Web" from here on)
is a networked information system comprising agents (clients,
servers, and other programs) that exchange information. The Web and
networking architecture is the set of rules that agents in the
system follow, resulting in a shared information space that scales
well and behaves predictably.
[0009] The Gaming Services Framework comprises a set of services,
protocols, XML schemas, and methods for providing secure gaming
system functionality in a distributed, network based architecture.
It is intended to be a service-oriented framework for gaming and
property management based upon internetworking technology and web
services concepts. Specifically, it supports a loosely coupled
architecture that consists of software components that semantically
encapsulate discrete functionality (self contained and perform a
single function or a related group of functions--the component
describes its own inputs and outputs in a way that other software
can determine what it does, how to invoke its functionality, and
what result to expect). These components are distributed and
programmatically accessible (called by and exchange data with other
software) over standard internetworking protocols (TCP/IP, HTTP,
DNS, DHCP, etc.).
[0010] The present invention describes systems, methods, and
computer-readable media of varying scope. In addition to the
aspects and advantages of the present invention described in this
summary, aspects and advantages of the invention will become
apparent by reference to the drawings and by reading the detailed
description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a perspective view of an exemplary gaming machine
incorporated in the present invention.
[0012] FIG. 2 is a block diagram providing an example of a
service-oriented network for distributed management in a gaming
environment.
[0013] FIG. 3 is a block diagram providing general description of
service-oriented discovery and interaction.
[0014] FIG. 4 is a representation of a Gaming Services Protocol
Stack according to embodiments of the invention.
[0015] FIGS. 5A, 5B and 6 are flow diagrams illustrating methods
and message flow for a cashless gaming service according to
embodiments of the invention.
DETAILED DESCRIPTION
[0016] In the following detailed description of exemplary
embodiments of the invention, reference is made to the accompanying
drawings which form a part hereof, and in which is shown by way of
illustration specific exemplary embodiments in which the invention
may be practiced. These embodiments are described in sufficient
detail to enable those skilled in the art to practice the
invention, and it is to be understood that other embodiments may be
utilized and that logical, mechanical, electrical and other changes
may be made without departing from the scope of the present
invention.
[0017] Some portions of the detailed descriptions which follow are
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. These algorithmic
descriptions and representations are the ways used by those skilled
in the data processing arts to most effectively convey the
substance of their work to others skilled in the art. An algorithm
is here, and generally, conceived to be a self-consistent sequence
of steps leading to a desired result. The steps are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, principally for reasons of common usage, to refer to these
signals as bits, values, elements, symbols, characters, terms,
numbers, or the like. It should be borne in mind, however, that all
of these and similar terms are to be associated with the
appropriate physical quantities and are merely convenient labels
applied to these quantities. Unless specifically stated otherwise
as apparent from the following discussions, terms such as
"processing" or "computing" or "calculating" or "determining" or
"displaying" or the like, refer to the action and processes of a
computer system, or similar computing device, that manipulates and
transforms data represented as physical (e.g., electronic)
quantities within the computer system's registers and memories into
other data similarly represented as physical quantities within the
computer system memories or registers or other such information
storage, transmission or display devices.
[0018] In the Figures, the same reference number is used throughout
to refer to an identical component which appears in multiple
Figures. Signals and connections may be referred to by the same
reference number or label, and the actual meaning will be clear
from its use in the context of the description.
[0019] The description of the various embodiments is to be
construed as exemplary only and does not describe every possible
instance of the invention. Numerous alternatives could be
implemented, using combinations of current or future technologies,
which would still fall within the scope of the claims. The present
invention is directed to a cashless gaming service in a
service-oriented framework for gaming networks that allows for the
interoperability of the software components (regardless of
manufacturer, operating system, or application) reducing the
dependence on a closed-system, single vendor solutions and allowing
for variety in innovation and competition.
[0020] The following detailed description is, therefore, not to be
taken in a limiting sense, and the scope of the present invention
is defined only by the appended claims.
Operating Environment
[0021] FIG. 1 illustrates an exemplary gaming machine 10 in which
embodiments of the invention maybe implemented. In some
embodiments, gaming machine 10 is operable to conduct a wagering
game. These wagering games may include reel based games such as
video or mechanical slot machine games, card based games such as
video poker, video dice games (e.g. a Yahtzee.RTM. like dice game)
or other types of wagering games typical in the gaming industry. If
based in-video, the gaming machine 10 includes a video display 12
such as a cathode ray tube (CRT), liquid crystal display (LCD),
plasma, or other type of video display known in the art. A touch
screen preferably overlies the display 12. In the illustrated
embodiment, the gaming machine 10 is an "upright" version in which
the display 12 is oriented vertically relative to a player.
Alternatively, the gaming machine may be a "slant-top" version in
which the display 12 is slanted at about a thirty-degree angle
toward the player.
[0022] The gaming machine 10 includes a plurality of possible
credit receiving mechanisms 14 for receiving credits to be used for
placing wagers in the game. The credit receiving mechanisms 14 may,
for example, include a coin acceptor, a bill acceptor, a ticket
reader, and a card reader. The bill acceptor and the ticket reader
may be combined into a single unit. The card reader may, for
example, accept magnetic cards and smart (chip) cards coded with
money or designating an account containing money.
[0023] In some embodiments, the gaming machine 10 includes a user
interface comprising a plurality of push-buttons 16, the
above-noted touch screen, and other possible devices. The plurality
of push-buttons 16 may, for example, include one or more "bet"
buttons for wagering, a "play" button for commencing play, a
"collect" button for cashing out, a help" button for viewing a help
screen, a "pay table" button for viewing the pay table(s), and a
"call attendant" button for calling an attendant. Additional game
specific buttons may be provided to facilitate play of the specific
game executed on the machine. The touch screen may define touch
keys for implementing many of the same functions as the
push-buttons. Additionally, in the case of video poker, the touch
screen may implement a card identification function to indicate
which cards a player desires to keep for the next round. Other
possible user interface devices include a keyboard and a pointing
device such as a mouse or trackball.
[0024] A processor controls operation of the gaming machine 10. In
response to receiving a wager and a command to initiate play, the
processor randomly selects a game outcome from a plurality of
possible outcomes and causes the display 12 to depict indicia
representative of the selected game outcome. In the case of slots
for example mechanical or simulated slot reels are rotated and
stopped to place symbols on the reels in visual association with
one or more pay lines. If the selected outcome is one of the
winning outcomes defined by a pay table, the processor awards the
player with a number of credits associated with the winning
outcome.
[0025] FIG. 2 illustrates an example of a Gaming Service Network
210 comprising a customer data center 218 and a customer property
216. The data center 218 and customer property 216 are connected
via a network 220. In some embodiments, network 220 is a public
network such as the Internet. However, in alternative embodiments,
private networks, including corporate intranets or extranets may be
used to connect a data center 218 with one or more properties
216.
[0026] In some embodiments, the Customer Corporate Data Center 218
contains the bulk of the network servers supporting gaming
properties owned by the corporation. Major elements of the gaming
service network include Auth server 232, Gaming Management Server
236, and Progressive Server 238. In some embodiments, Auth Server
32 provides authentication, authorization and content integrity for
client devices attempting to interact with other servers and
services in the architecture.
[0027] In some embodiments, the Gaming Management Server 236
includes the following services: Boot Service, Name Service, Time
Service, Game Management Service, Game Update Service, Event
Management Service, Accounting Service, and Discovery Service.
[0028] In some embodiments, the Progressive Server 238 hosts a
value-add service that allows a gaming machine to participate
within a progressive gaming offering. Any value-add service can be
added or substituted for this server/service. A progressive game
offering is provided as an example. Other value-add services can be
distributed on existing servers or reside on a newly added
server.
[0029] The Customer Property 16 contains gaming machines 10, which
in some embodiments allow remote updates and configuration through
a network interface on the gaming machine. In some embodiments, a
Boot Server 234 contains a DHCP service that facilitates the
distribution of IP addressing to the gaming machines 10. It should
be noted that any device capable of supporting a wagering game
could be substituted for gaming machine 10. For example, a personal
or laptop computer executing a wagering game may participate in the
gaming network using the services described below.
[0030] As noted above, various services may be located throughout
the gaming network. In some embodiments of the invention, a set of
core operational services may include one or more of the following
services: TABLE-US-00001 Boot Service Provides dynamic IP
addressing to devices upon boot (start-up). Typically supported by
Dynamic Host Configuration Protocol (DHCP). Discovery Service
Provides the address information of the server containing the
service when prompted by the requestor as well as the service
description, binding and location on the server. Authentication
Service Contains the master Authentication Database. Authenticates
the service user before allowing the use of services in the Gaming
Services Framework. Authorization Service Contains the master
Authorization Database. Authorizes the use of services in the
Gaming Services Framework by a service requestor. Gaming Management
Service Provides the ability to configure and monitor gaming
machines and other services from a central location. Name Service
Provides name resolution service to enable machines in a gaming
network to refer to each other by name instead of an IP Address. In
some embodiments the name service is implemented in part using the
Domain Naming System (DNS) protocol. Time Service Provides global
synchronization of time in the gaming network. This may be
implemented by running the Network Time Protocol (NTP) client
software on gaming machines.
[0031] In addition to or instead of the core services described
above, some embodiments of the invention include one or more of the
following services referred to as Basic Gaming Services:
TABLE-US-00002 Accounting Provides logging of transaction records
for billing Service and general tracking purposes. Event Management
Logs events occurring at client and server Service machines. Game
Update Provides dynamic distribution of new or updated Service game
content to gaming machines. Message Director This service uses a
software-configurable message Service routing application to
facilitate the reliable exchange of data messages among multiple
application processes within one or more gaming systems. Content
Integrity This service provides the ability to verify the Service
integrity of software components running in the gaming network.
This includes the verification of software versions running on
gaming machines, peripherals, services as well the detection of
tampering or modification of the software.
[0032] As noted above, a gaming service network may include Value
Add Services. These services include participation services and
player services. Examples of participation services that may be
included in various embodiments of the invention include the
following: TABLE-US-00003 Progressive Service Provides
functionality for a gaming machine to participate within a single
progressive or multiple progressives. Wide Area Disruption This
service takes over the processing of Progressive Service wide area
progressives at each gaming site in the event that there is no
connection with a central system or the connection with the central
system is temporarily disabled. Mobile Gaming Device This service
processes the GPS location of GPS Service gaming machines compared
with coordinates of a gaming jurisdiction. Example: players can
ride a bus and begin gambling on the bus when the bus crosses into
the gaming jurisdiction.
[0033] Examples of Player Services that may be included in various
embodiments of the invention include: TABLE-US-00004 Player This
service provides the operator and player with Tracking standard
player tracking applications such as monitoring Service card
in/card out transactions to track play and award player points for
play, providing targeted promotional compensation to specific
players, publishing account status to the player or operator,
providing temporary gaming machine locking in order to hold the
machine for the player for short periods of time, and providing
operators and players an interface and capability for Responsible
Gaming Initiatives. Game Theme This service provides location
information to clients Location regarding specific games, game
themes or vendor Service brands. The service may publish the
information by casino, by area, by city, by state, by region, by
country, or by continent depending on the input parameters
provided. An example would be to publish where all of the
progressive games of a particular theme (e.g., "Monopoly Money")
are located in a particular hotel (e.g., the Reno Hilton) in Reno,
Nevada. Personalization This service provides the gaming player
with a more Service personalized gaming environment. Example: the
player could choose to see text in Chinese, could choose to be
reminded of dinner reservation time, could customize machine
graphics, or could have a portion of his coin in go to his football
club's progressive. Bonusing This service provides the ability for
casinos to set up Service bonus games for a specific gaming
machine, carousel of machines or one or more game themes. Game
Service This service is a server-side process that provides the
outcome of game play. This service may be used to enable
Internet/online gaming. Advertising This service allows the
operator to display advertising Service information to players in
multimedia format as well as simple audio and graphic formats.
Property This is a group of services that provides the ability for
Service the property management company to integrate with gaming
systems. It can provide interaction with functions such as hotel
and restaurant reservations. Language This service provides a
translation method for players on Translation a networked gaming
machine. It may provide Service translations for one or more
languages for the game itself, some of the additional features
found on the machine, or the entire feature set of the gaming
machine. Cashless This service provides the means to allow
financial Gaming transactions such as funds transfers and game play
Service transactions to occur electronically in a distributed or
centralized model from the gaming machine.
[0034] Additional details on a cashless gaming service according to
embodiments of the invention are provided below.
[0035] It should be noted that with the distributed architecture of
the Gaming Service Network 210, the above-described services that
reside on network servers are not limited to location and can
reside anywhere the network supports. For example, it is desirable
to consider security and network latency when locating
services.
[0036] FIG. 3 is a block diagram of a Gaming Services Framework 300
according to various embodiments of the invention. In some
embodiments, the Gaming Services Framework 300 includes a set of
protocols, XML schemas, and methods for providing gaming system
functionality in a distributed, network-based architecture such as
the network described above in FIG. 2. In order to participate in
such network-based architectures, the participating machines are
interconnected via public or private networks that may be wired or
wireless networks. Further, devices performing service
communication support a common services protocol stack such as the
Gaming Services Protocol Stack that is further described below.
[0037] The Gaming Services Framework 300 provides for the
interaction of several logical elements as depicted in FIG. 3.
Logical elements represent the fundamental entities that interact
to implement a service. In some embodiments, these logical elements
include Service Requestor 302, Service Provider 304, and Discovery
Agency 306. In general terms, the roles these elements play are as
defined in Web Services Architecture--W3C Working (Draft 14
November 2002 and later versions). Further details on these
elements are provided below.
[0038] Logical elements may reside in a number of different
physical devices as part of delivering any service. For example, a
Service Provider 304 will typically reside in a slot accounting or
player tracking system and the Service Requestor 302 will typically
reside in a gaming machine. However, there may be scenarios where
it would be advantageous or appropriate for the logical elements to
reside in other physical devices. For example, in alternative
embodiments a Service Requestor 302 may reside in a slot accounting
system.
[0039] Service Provider 304 comprises a platform that hosts access
to a service 314. A service provider may also be referred to as a
service execution environment or a service container. Its role in
the client-server message exchange patterns is that of a
server.
[0040] Service Requestor 302 comprises an application that is
looking for and invoking or initiating an interaction with a
service such as that provided by service provider 304. Its role in
the client-server message exchange patterns is that of a client
312.
[0041] Discovery Agency 306 comprises a searchable set of service
descriptions where service providers 304 publish their service
description(s) 324 and service location(s) 326. The service
discovery agency 306 can be centralized or distributed. A discovery
agency 306 can support both patterns where service descriptions 322
are sent to discovery agency 306 and patterns where the discovery
agency 306 actively inspects public service providers 304 for
service descriptions 322. Service requestors 302 may find services
and obtain binding information (in the service descriptions 324)
during development for static binding, or during execution for
dynamic binding. In some embodiments, for example in statically
bound service requestors, the service discovery agent may be an
optional role in the framework architecture, as a service provider
304 can send the service description 322 directly to service
requestor 302. Likewise, service requestors 302 can obtain a
service description 324 from other sources besides a discovery
agency 306, such as a local file system, FTP site, URL, or WSDL
document.
[0042] FIG. 4 provides a block diagram of a Gaming Services
Protocol Stack 400 according to embodiments of the invention. In
some embodiments, the protocol stack includes core layers that
define basic services communication and transport, and are
typically implemented uniformly. Higher layers that define
strategic aspects of gaming processes are also described below.
FIG. 4 illustrates both the widely implemented core layers and in
addition illustrates the higher gaming services oriented layers of
the protocol stack.
[0043] Core Layers of the Gaming Services Protocol Stack 400
[0044] In some embodiments, the gaming services framework utilizes
common Internet protocols, which may include web services
protocols. Although not specifically tied to any transport
protocol, it is desirable to build the gaming services on
ubiquitous Internet connectivity and infrastructure to ensure
nearly universal reach and support. In some embodiments, gaming
services will take advantage of Ethernet 405 or 406, Transmission
Control Protocol (TCP) 408, Internet Protocol (IP) 407, User
Datagram Protocol (UDP) 409, HyperText Transfer Protocol (HTTP)
410, HyperText Transfer Protocol Secure/Secure Socket Layer
(HTTPS/SSL) 411, Lightweight Directory Access Protocol (LDAP) 412,
Domain Naming System (DNS) 413, and Dynamic Host Configuration
Protocol (DHCP) 414 layers in the protocol stack 400. Those of
skill in the art will appreciate that other protocol layers
performing equivalent functionality may be substituted for those
described above and are within the scope of the present
invention.
[0045] In some embodiments, service request and response data are
formatted using Extensible Markup Language (XML) 415. XML 415 is a
widely accepted format for exchanging data and its corresponding
semantics. XML is a fundamental building block used in layers above
the Common Internet Protocols. In some embodiments, the Gaming
Services Protocol Stack 400 incorporates this protocol in
accordance with the World Wide Web Consortium (W3C) XML Working
Group's XML specification. However, those of skill in the art will
appreciate that other data exchange formats may be substituted for
XML 415, and such formats are within the scope of the present
invention.
[0046] In some embodiments of the invention, the gaming service
protocol stack 400 utilizes the Simple Object Access Protocol
(SOAP) 416. SOAP 416 is a protocol for messaging and RPC (Remote
Procedure Call) style communication between applications. SOAP is
based on XML 415 and uses common Internet transport protocols like
HTTP 410 to carry data. SOAP 416 may be used to define a model to
envelope request and response messages encoded in XML 415. SOAP 416
messaging can be used to exchange any kind of XML 415 information.
SOAP 416 is used in some embodiments as the basic standard for
carrying service requests/responses between service users and
providers. SOAP 416 has been submitted to the World Wide Web
Consortium (W3C) standards body as recommendation documents
(versions 1.1 and 1.2) and will likely emerge as "XML Protocol
(XP)."
[0047] Higher Layers of the Gaming Services Protocol Stack 400
[0048] In some embodiments, the gaming services protocol stack
includes a Web Services Description Language (WSDL) 417 and a
Universal Description, Discovery, and Integration (UDDI) 418. WSDL
417 comprises a description of how to connect to a particular
service. In some embodiments, WSDL 417 is based on XML. A WSDL 417
description abstracts a particular service's various connection and
messaging protocols into a high-level bundle and forms an element
of the UDDI 418 directory's information. WSDL 417 is similar to
CORBA or COM IDL in that WSDL 417 describes programmatic
interfaces. WSDL 417 is typically independent of the underlying
service implementation language or component model, and focuses on
an abstract description. The Gaming Services Protocol Stack 400
incorporates this description in accordance with the World Wide Web
Consortium (W3C) Web Services Description Language (WSDL) 1.1--W3C
Note 15 March 2001 and later versions.
[0049] In some embodiments, UDDI 418 represents a set of protocols
and a public directory for the registration and real-time lookup of
services. UDDI 418 enables an entity such as a company to publish a
description of available services to the registry, thereby
announcing itself as a service provider. Service users can send
requests conforming to the UDDI 418 schema as SOAP 416 messages to
the service registry to discover a provider for services. Some
embodiments of the present invention may utilize UDDI Version 3,
released in July of 2002 and later versions. Further development of
UDDI 418 is managed under the auspices of the OASIS (Organization
for the Advancement of Structured Information Standards) UDDI
Specifications technical committee.
[0050] Returning to FIG. 3, the service requesters and service
providers use the above-described protocol stack to perform service
interactions with one another. The service interactions include
publish 330, discover (find) 332, and interact 334.
[0051] Publish interaction 330 provides a mechanism for a service
to be made accessible by other entities in the gaming network
environment. In order to be accessible, a service needs to publish
its description such that the requestor can subsequently find it.
Where it is published can vary depending upon the requirements of
the application. A service description 322 can be published using a
variety of mechanisms known in the art. The various mechanisms used
by the varying embodiments of the invention provide different
capabilities depending on how dynamic the application using the
service is intended to be. The service description may be published
to multiple service registries using several different mechanisms.
The simplest case is a direct publish. A direct publish means the
service provider sends the service description directly to the
service requester. In this case the service requestor may maintain
a local copy of the service description 322.
[0052] Another means of publishing service descriptions utilized in
alternative embodiments of the invention is through a UDDI
registry. There are several types of UDDI registries known in the
art that may be used depending on the scope of the domain of Web
services published to it. When publishing a Web service description
to a UDDI registry, it is desirable to consider the business
context and taxonomies in order for the service to be found by its
potential service . Examples of UDDI registries used in the gaming
service architecture of various embodiments of the invention are
Internal Enterprise Application UDDI registry, Portal UDDI
registry, and Partner Catalog UDDI registry.
[0053] An Internal Enterprise Application UDDI registry may be used
in some embodiments for gaming services intended for use within an
organization for internal enterprise applications integration. For
example, all services that provide gaming and gaming management to
devices within a casino or casino organization may be published to
an Internal Enterprise Application UDDI registry.
[0054] A Portal UDDI registry may be used in some embodiments for
gaming services that are published by a company for external
partners to find and use. A portal UDDI registry typically runs in
the service provider's environment outside of a firewall or in a
DMZ (de-militarized zone) between firewalls. This kind of private
UDDI registry generally contains only those service descriptions
that a company wishes to provide to service requesters from
external partners through a network. For example, these services
may be used to provide online gaming to customers connecting
through the World-Wide Web.
[0055] A Partner Catalog UDDI registry may be used in some
embodiments for gaming services to be used by a particular company.
The Partner Catalog UDDI registry can be thought of as a rolodex
like UDDI registry. A Partner Catalog UDDI registry is typically
located on a computer or gaming machine behind a firewall. This
kind of private UDDI registry typically contains approved, tested,
and valid service descriptions from legitimate (e.g. authorized)
business partners. The business context and metadata for these
services can be targeted to the specific requestor. In some
embodiments, this type of registry may be used for inter-casino
services as well as interactions between casinos and other types of
organizations such as regulators and financial institutions. It is
desirable that an appropriate authorization and qualification
procedure be in place to insure that only approved are published to
service repositories.
[0056] In the discover interactions 332 (also referred to as find
interactions), the service requestor a service description directly
or queries the for this type of service required. It there
processes the description in order to be able to bind and invoke
it.
[0057] As with publishing service descriptions, acquiring service
descriptions may vary depending on how the service description is
published and how dynamic the service application is meant to be.
In some embodiments, service requestors may find Web services
during two different phases of an application lifecycle--design
time and run time.
[0058] At design time, service requestors search for web service
descriptions by the type of interface they support. At run time,
service requestors search for a web service based on how they
communicate or qualities of service advertised.
[0059] With the direct publish approach noted above, the service
requester may cache the service description at design time for use
at runtime. The service description may be statically represented
in the program logic, stored in a file, or in a simple, local
service description repository.
[0060] Service requestors can retrieve a service description at
design time or runtime from a Web page (URL), a service description
repository, a simple service registry or a UDDI registry. The
look-up mechanism typically supports a query mechanism that
provides a find by type of interface capability (for example, based
on a WSDL template), the binding information (i.e. protocols),
properties (such as QOS parameters), the types of intermediaries
required, the taxonomy of the service, business information,
etc.
[0061] The various types of UDDI registries, including those
described above, have implications on the number of runtime binding
services can choose from, policy for choosing one among many, or
the amount of pre screening that will be done by the requestor
before invoking the service. Service selection can be based on
binding support, historical performance, quality of service
classification, proximity, or load balancing. It is desirable that
an appropriate authorization and qualification procedure be in
place to insure that only approved services are published to
service repositories.
[0062] Once a service description is acquired, the service
requestor will need to process it in order to invoke the service.
In some embodiments, the service requestor uses the service
description to generate SCAP requests or programming language
specific proxies to the service. The generation of such requests
can be done at design time or at run time to format an invocation
to the service. Various tools can be used at design time or runtime
to generate programming language bindings from interface
descriptions, such as WSDL documents. These bindings present an API
(Application Program Interface) to the application program and
encapsulate the details of the messaging from the application.
[0063] After a service has been published 330 and discovered 332,
the service may be invoked so that a service requestor and service
provider may interact 334. In the interact operation 334, the
service requester invokes or initiates an interaction with the
service at runtime using the binding details in the service
description 322 to locate, contact, and invoke the service.
Examples of service interactions 334 include: single message one
way, broadcast from requester to many services, a multi message
conversation, or a business process. Any of these types of
interactions can be synchronous or asynchronous requests.
[0064] In some embodiments of the invention, security mechanisms
may be used to secure the Gaming Services Framework 300. Securing
the Gaming Services Framework typically involves providing
facilities for ensuring the integrity and confidentiality of the
messages and for ensuring that a service acts only on requests in
messages that express the claims required by policies. Examples of
such mechanisms used in various embodiments of the invention
include IPSec and SSL/TLS, which provide network and transport
layer security between two endpoints. However, when data is
received and forwarded on by an intermediary beyond the transport
layer both the integrity of data and any security information that
flows with it maybe lost. This forces any upstream message
processors to rely on the security evaluations made by previous
intermediaries and to completely trust their handling of the
content of messages. Thus it is desirable to include security that
provide end-to-end security. It is also desirable that such
mechanisms be able to leverage both transport and application layer
security mechanisms to provide a comprehensive suite of security
capabilities.
Cashless Gaming Service
[0065] In general, the various embodiments of the invention
implement a mechanism by which a player may conveniently use
electronic funds transfers to wager at a gaming terminal. The funds
transfers can be from the gaming terminal to a Cashless Gaming
Service and from the Cashless Gaming Service to the gaming
terminal. A player may initiate funds transfers while at a gaming
machine. The casino can also initiate the transfer of promotional
credits to a player's account. The Cashless Gaming Service provides
the player with current account information, including the current
balance and a list of transactions in the current period. The
Cashless Gaming Service also supports inter-bank transfers between
player accounts. For instance a player may request that funds be
transferred from his/her Checking account to the Cashless Gaming
account.
[0066] A typical sequence of events is as follows. When a player
signs up for a Player Tracking card or some other casino-issued
identification, the player has the option of signing up for a
Cashless Gaming account at the casino. The account can be operated
just like a regular bank account and the casino in effect operates
like a bank. The player can contribute funds to the account at the
time the account is opened. Alternatively, the player may deposit
funds later while actually playing at a Cashless Gaming
Service-enabled gaming machine, akin to an ATM deposit. When a
player identifies himself/herself to a Cashless Gaming
Service-enabled gaming machine (via a Player Tracking card, User
ID/PIN), the gaming machine sends a registration message with the
player's identification and authorization information to the
Cashless Gaming Service. If the player has previously established
an account, is in good standing and is eligible to use the Service,
the Service will successfully register the player.
[0067] The player may deposit funds at a gaming machine by
inserting money into any of the gaming machine's cash-in devices.
These funds are automatically transferred to his/her Cashless
Gaming account, so that he/she might play with these funds at
another gaming terminal in the future. When the player is done
playing at a terminal, he/she has the option of cashing out all or
a portion of the funds at the machine or committing them back to
the Cashless Gaming account. If the Player removes the Player
Tracking card (or signs off the session) at any time, the gaming
device will automatically transfer all remaining credits in the
gaming machine back to the Cashless Gaming account. The player can
at any time request the current account balance and a transaction
history.
[0068] The casino also has the ability to fund a player's account
with promotional credits. These credits may be designated as
cashable or non-cashable and are transferable between gaming
machines.
[0069] FIGS. 5A, 5B and 6 are flow diagrams illustrating methods
for providing a cashless gaming service in a gaming network
according to embodiments of the invention. The methods may be
performed within an operating environment such as that described
above with reference to FIGS. 1-4. The methods to be performed by
the operating environment constitute computer programs made up of
computer-executable instructions. Describing the methods by
reference to a flow diagram enables one skilled in the art to
develop such programs including such instructions to carry out the
methods on suitable computers (the processor of the computer
executing the instructions from machine-readable media such as RAM,
ROM, CD-ROM, DVD-ROM, flash memory etc.). The methods illustrated
in FIGS. 5A, 5B and 6 are inclusive of the acts performed by an
operating environment executing an exemplary embodiment of the
invention.
[0070] FIG. 5A is a flow diagram illustrating a method for
providing a cashless gaming service in a service-oriented gaming
network. In the detailed description of the method below,
particular program method names may be provided for particular
embodiments of the invention. It should be noted that such names
are convenient labels for the method and are exemplary in nature.
The present invention is not limited to any functionality that may
be implied by the name.
[0071] The method begins by publishing the availability of a
cashless gaming service on a gaming network (block 510). In some ,
the service is registered by sending a description (e.g. in WSDL)
of the service to the discovery agency. The discovery agency adds
the service description to its UDDI repository. At this point the
cashless gaming service is available for discovery by interested
parties.
[0072] Next, in some embodiments, a client/service requestor makes
UDDI calls to the discovery agency to find a cashless gaming
service (block 512). The discovery agency returns the service
description and location information to the requestor.
[0073] Next, a client/service requestor registers with the service
provider (block 514). In some embodiments, this is accomplished by
invoking a invoking a cashlessGamingServiceRegister method on the
Cashless Gaming Service. As an example, this may occur when a
player inserts his/her Player identification card into the gaming
terminal. In some embodiments this method call is a SOAP call and
includes parameters that identify the gaming terminal, the player
and provide authentication information to the Cashless Gaming
Service provider. The Cashless Gaming Service provider may verify
that the gaming terminal and player are authorized to execute
methods in its service before successfully registering the client.
When the client is done using the service, it may invoke a
cashlessGamingServiceRegister method on the Cashless Gaming
Service. For example, this may occur when the player removes the
Player identification card from the gaming terminal.
[0074] Finally, a client (e.g. a gaming terminal, a service
requestor or a service provider) can invoke the cashless service to
process a request (block 516). In some embodiments, invoking the
cashless gaming service involves invoking methods. The methods may
be either a SOAP message or an HTTP Request encapsulating an OFX
message, or one based on a number of other open XML-based protocols
such as IFX, IOTP, and ECML. The Cashless Gaming Service may
implement ACH, SWIFT or any of a number of other electronic funds
transfer protocols to transact with other financial
institutions.
[0075] The Open Financial Exchange (OFX) is a standardized,
extensible XML-based protocol to exchange information between
clients and financial institutions. OFX supports message sets for
Consumer Banking operations, inter-bank transfers, wire transfers,
recurring transfers, credit card, automatic payment processing,
taxes and brokerage investments. In a casino gaming environment,
the Consumer banking message set adequately encapsulates the needed
functionality to perform electronic funds transfers.
[0076] The Interactive Financial exchange (IFX) is another
XML-based, financial messaging protocol. IFX provides content rich
conversations in the areas of Electronic Bill Presentment and
Payment, Business to Business Payments, Business to Business
Banking, Automated Teller Machine communications, Consumer to
Business Payments and Consumer to Business Banking.
[0077] The Internet Open Trading Protocol (IOTP) is an
interoperable framework for Internet commerce. It is optimized for
the case where the buyer and the merchant do not have a prior
acquaintance and is payment system independent.
[0078] The Electronic Commerce Modeling Language (ECML) defines a
standard set of information fields used by consumers in electronic
commerce transaction, so that the task of filling in the fields can
be automated by wallet software, for example.
[0079] The choice of a cashless transfer protocol will depend on
the model of the cashless network. In the first model, the gaming
machine and the server collaborate in financial bookkeeping. In
this model the gaming machine must handle bookkeeping for the money
on resident on gaming machine while the server handles the
bookkeeping for the money resident in the Cashless Gaming account.
Money is transferred electronically between the server and the
gaming machine. This model will be referred to as the Distributed
Banking model.
[0080] In the second model, all accounts are maintained at the
server and the server handles all financial bookkeeping. The gaming
machine simply displays the current account information held at the
server. This will be referred to as the Centralized Banking model.
The OFX (or IFX) protocol may be more appropriate in this model
between the gaming machine and the Cashless Gaming Service. Money
transfers occur on the server between the Player's account and the
Casino's account. The gaming machine is only responsible for
displaying the Player's current account balance as well as
translating game outcomes to OFX (or IFX) transactions that are
sent to the server to fulfill. The OFX (or IFX) protocol may also
be used to request the transfer funds between the Player's Cashless
account and an external account held at another financial
institution. OFX (or IFX) also allows the client to query the
Cashless service for a list of transactions for a given period.
[0081] The following is a nonexclusive list of methods of the
cashless gaming service that may be invoked in various embodiments
(the methods may be as SOAP calls): [0082]
cashlessGamingServiceNewAccount--The client this call to the
Cashless Gaming Service to establish a new account for the Player.
In some embodiments, only the casino's management system will have
the authority to make this request. [0083]
cashlessGamingServiceModifyAccount--The client makes this call to
the Cashless Gaming Service to modify the details of an existing
account. In some embodiments, only the casino's management system
will have the authority to make this request. [0084]
cashlessGamingServiceCloseAccount--The client makes this call to
the Cashless Gaming Service to close out an existing account. In
some embodiments, only the casino's management system will have the
authority to make this request. [0085]
cashlessGamingServiceGetAccountDetails--The client makes this call
to the Cashless Gaming Service to get detailed information about
the Account. The account information may include name, address,
phone number, tax identification number, account number, account
balance, promotional credits balance and transaction history.
[0086] cashlessGamingServiceGetAccountBalance--The client makes
this call to the Cashless Gaming Service to get the current account
balance. [0087] cashlessGamingServiceGetTransactionHistory--The
client makes this call to the Cashless Gaming Service to get a list
of account transactions for the specified period. The extent of
account history retained by the Cashless Service is implementation
dependent. Players may retrieve the transaction history of their
account while at a gaming terminal. Players may optionally choose
to print it out on the gaming machine's printing device or have it
sent to a chosen email address for later viewing. [0088]
cashlessGamingServiceDepositFunds--The client makes this call to
the Cashless Gaming Service to deposit funds to the account.
Typically the player situated at a gaming terminal initiates this
action. [0089] cashlessGamingServiceWithdrawFunds--The client makes
this call to withdraw funds from the Cashless Account and transfer
them as playable credits on the gaming terminal where the player is
situated. [0090] cashlessGamingServiceTransferFunds--The client can
make this call to request a funds transfer between a player's
external account (e.g. Checking account) and his/her Cashless
Gaming account. The gaming terminal will obtain information from
the player prior to requesting the funds transfer. This call may
also be used to transfer funds between two Cashless Gaming accounts
that have been previously set up as linked. For example a player
may transfer funds to a spouse's account directly from a gaming
machine. As another example, a player can tip the wait-staff
directly by transferring funds to the wait-staff's account at the
gaming terminal. [0091]
cashlessGamingServiceDepositPromoCredits--The client makes this
call to request to deposit promotional credits to the players
account. The casino operator will typically initiate this
operation. [0092] cashlessGamingServiceWithdrawPromoCredits--The
client makes this call to request to withdraw promotional credits
from the players account. The casino operator will typically
initiate this operation.
[0093] FIG. 5B illustrates a method according to an embodiment of
the invention for providing a cashless gaming service to a client
in a gaming machine network. In particular, FIG. 5B illustrates an
exemplary usage scenario involving an exemplary message sequence
500 that describes how a client such as gaming machine 501 and a
cashless gaming service 502 interact between themselves and other
components of a gaming network such as discovery service 503 and an
authorization database 504 when a player deposits finds to a
Cashless Gaming account. Message sequence 500 is but one example of
a message sequence. Those of skill in the art will appreciate that
other message sequences for other types of requests are within the
scope of the invention. Additional information for each message is
provided below as defined by the reference number in FIG. 5B.
[0094] At 521 the Cashless Gaming Service 502 is deployed and saves
its binding information to the Discovery Service 503 (e.g. using a
UDDI Registry).
[0095] At 522 the Discovery Service 503 authenticates the Cashless
Gaming Service 502 with the Authentication/Authorization/Account
Database 504 (e.g. using LDAP, RADIUS, SQLServer, Oracle, et
al.).
[0096] At 523 the Authentication/Authorization/Account Database 504
successfully authenticates the Cashless Gaming Service 502 (e.g.
using LDAP, RADIUS, SQLServer, Oracle, et al.).
[0097] At 524 the Discovery Service 503 returns a information
element to the Cashless Gaming Service 502 (e.g. using UDDI). The
Cashless Gaming Service 502 is now ready to accept requests for
service from clients (e.g. gaming machines, game servers or other
components of a gaming network).
[0098] At 525 a Gaming Machine 501 contacts the Discovery Service
503 to find the location of a Cashless Gaming Service (e.g. using
UDDI).
[0099] At 526 the Discovery Service 503 returns with a list of
possible Cashless Gaming Services (e.g. using UDDI).
[0100] At 527 the Gaming Machine 501 chooses one (using some
suitable algorithm) and requests the binding information of that
instance of the Cashless Gaming Service 502 (e.g. using UDDI).
[0101] At 528 the Discovery Service 502 returns the binding
information to the Gaming Machine 501 (e.g. using UDDI).
[0102] At 529 a player inserts a player-tracking (or other ID) card
into the Gaming Machine 501.
[0103] At 530 the Gaming Machine 501 registers with the Cashless
Gaming Service 502 (e.g. using SOAP) on behalf of the player.
[0104] At 531 the Cashless Gaming Service 502 authenticates the
Gaming Machine 501 and player with the
Authentication/Authorization/Account Database 504 (e.g. using LDAP,
SQT Server, Oracle, et al.).
[0105] At 532 the Authentication/Authorization/Account Database 504
successfully authenticates the Machine 501 and player (e.g. using
LDAP, RADIUS, SQLServer, Oracle, et al.).
[0106] At 533 the Cashless Gaming 502 returns a successful response
to the Gaming Machine 501 (e.g. using SOAP).
[0107] At 534 the player inserts funds, plays the game for a period
of time and upon completing play, removes the player-tracking card
while there are still credits remaining on the Gaming Machine 501.
The player selects the option of depositing the credit balance back
to the player's cashless account.
[0108] At 535 the Gaming Machine 501 sends a
cashlessGamingServiceDepositFunds message (SOAP) to the Cashless
Gaming Service 502. The message contains at a minimum the Player
ID, Date/Time, deposit amount (credit balance) and a unique
transaction ID.
[0109] At 536 the Cashless Gaming Service 502 commits those to the
player's account by sending a DEPOSIT_FUNDS_REQ message to the
Account Database 504 (e.g. using LDAP, RADIUS, SQLServer, Oracle,
et al.)
[0110] At 537 the Account Database 504 successfully acknowledges
completion of the transaction by returning a DEPOSIT_FUNDS_RSP
(e.g. using LDAP, RADIUS, SQLServer, Oracle, et al.) to the
Cashless Gaming Service 502.
[0111] At 538 the Cashless Gaming Service 502 responds to the
Gaming Machine 501 with a cashlessGamingServiceDepositFundsAck
message (SOAP). Either or both of the Gaming Machine 501 and the
Cashless Gaming Service 502 may maintain a transaction log for
audit purposes and also to re-sync their databases in the event of
lost communication.
[0112] FIG. 6 illustrates a method according to an embodiment of
the invention for providing a cashless gaming service to a client
in a gaming machine network. In particular, FIG. 6 describes an
message sequence scenario 600 of how a player transfers funds
between an external Checking Account and the Cashless Gaming
account. Message sequence 600 is but one example of a message
sequence. Those of skill in the art will appreciate that other
message sequences for other types of requests are within the scope
of the inventive subject matter. information for each message is
provided below as defined by the ID number in FIG. 6. Note that the
discovery process is omitted from this sequence. It is assumed that
the gaming machine knows how to locate the Cashless Gaming Service
(OFX server.)
[0113] At 621 the player inserts a player-tracking card into the
Gaming Machine 601 and initiates a funds transfer from an external
Financial Institution account to the Cashless Gaming account. The
player enters via a keypad, touch screen, or some other interface
identification and authorization information for the account(s)
being used.
[0114] At 622 the Gaming Machine 501 then sends on behalf of the
player a message to the Cashless Service 602. In some embodiments,
the message is an OFX message carried in an HTTP POST Request
message. The message is transmitted securely using SSL (Secure
Sockets Layer) and contains a Sign-on section, a transaction
section, a Destination Acct section, a Source Account Section, a
transaction amount, and a date (IFX can also be used).
[0115] At 623 the Cashless Service 602 authenticates the player and
source account information with the
Authentication/Authorization/Account Database 603 (LDAP, SQLServer,
Oracle, et al.)
[0116] At 624 the Authentication/Authorization/Account Database 603
authenticates the player and source account information (LDAP,
SQLServer, Oracle, et al.).
[0117] At 625 the Cashless Service 602 then initiates an inter-bank
transfer using any standard electronic funds transfer network such
as SWIFT, ACH or FedWire with the player's Financial Institution
External Account 604.
[0118] At 626 the Financial Institution 604 acknowledges and
completes the transfer transaction.
[0119] At 627 the Cashless Service 602 commits the funds to the
Cashless Gaming Account 603 (LDAP, SQLServer, Oracle, et al.)
[0120] At 628 the Cashless Gaming Account 603 successfully
acknowledges completion of the transaction (LDAP, SQLServer,
Oracle, et al.)
[0121] At 629 the Cashless Service 602 responds to the Gaming
Machine 601 with an OFX message contained in an HTTP OK
Response.
[0122] At 630 the player can now view the deposited funds on the
Gaming Machine 601 and display and wager those funds directly out
of the Cashless Gaming Account 603. This implies that every game
play results in a transaction to the Cashless Service 602. In the
case of a win the Gaming Machine will request a transfer from the
Casino's account to the player's Cashless Gaming Account 603. In
the case of a loss, the will request a transfer from the player's
Cashless Gaming Account 603 to the Casino's account.
Conclusion
[0123] Systems and methods providing a cashless gaming service in a
service-oriented gaming network environment have been disclosed.
Although specific embodiments have been illustrated and described
herein, it will be appreciated by those of ordinary skill in the
art that any arrangement which is calculated to achieve the same
purpose may be substituted for the specific embodiments shown. This
application is intended to cover any adaptations or variations of
the present invention.
[0124] The terminology used in this application is meant to include
all of these environments. It is to be understood that the above
description is intended to be illustrative, and not restrictive.
Many other embodiments will be apparent to those of skill in the
art upon reviewing the above description. Therefore, it is
manifestly intended that this invention be limited only by the
following claims and equivalents thereof.
* * * * *