U.S. patent application number 11/278937 was filed with the patent office on 2006-11-02 for logic interface engine system and method.
Invention is credited to Anthony E. Green, Patel Pravinkumar, Jordan J. Strub.
Application Number | 20060247057 11/278937 |
Document ID | / |
Family ID | 37215199 |
Filed Date | 2006-11-02 |
United States Patent
Application |
20060247057 |
Kind Code |
A1 |
Green; Anthony E. ; et
al. |
November 2, 2006 |
Logic Interface Engine System and Method
Abstract
A logic interface engine 10 is used as an interface between a
command driven device and a logical communication channel. The
logic interface engine 10 includes a logic controller 20, a command
router 30, a message processor 40, and a transport layer 50. The
logic controller includes a plurality of object classes that
correspond to components of the command-driven device. The command
router receives the outbound commands sent by the object classes,
and inbound commands sent from the command inQueues of the command
router, which the command router duplicates and forwards, as
required. The message processor(s) each includes a corresponding
host, message builder, and message splitter. The transport layer
receives the outbound messages sent by the message processors and
sends outbound messages to the logical communication channel.
Additionally, the transport layer sends inbound messages to the
message processors.
Inventors: |
Green; Anthony E.;
(Henderson, NV) ; Strub; Jordan J.; (Henderson,
NV) ; Pravinkumar; Patel; (Las Vegas, NV) |
Correspondence
Address: |
BROWN RAYSMAN MILLSTEIN FELDER & STEINER, LLP
1880 CENTURY PARK EAST
12TH FLOOR
LOS ANGELES
CA
90067
US
|
Family ID: |
37215199 |
Appl. No.: |
11/278937 |
Filed: |
April 6, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60676429 |
Apr 28, 2005 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
G07F 17/3223 20130101;
G07F 17/3202 20130101; G07F 17/32 20130101; G07F 17/323
20130101 |
Class at
Publication: |
463/042 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A logic interface device for interfacing between a gaming device
and a logical communication channel, the device comprising: a logic
controller, wherein the logic controller includes a plurality of
object classes that correspond to components of the gaming device,
and wherein the object classes send outbound commands; a command
router, wherein the command router receives the outbound commands
sent by the object classes, wherein the command router includes a
plurality of command inbound queues that correspond to the object
classes of the logic controller, wherein the object classes receive
inbound commands sent from the command inbound queues of the
command router, and wherein the command router duplicates commands
as required and sends outbound commands; one or more message
processors each including a corresponding host, message builder,
and message splitter, wherein the host of each message processor
receives an outbound command sent by the command router, wherein
the message builder of each message processor groups and
encapsulates outbound commands into a single outbound message per
host, wherein the message splitter of each message processor parses
inbound messages into multiple inbound commands, wherein the
command router receives inbound commands from the hosts of the
message processors, and wherein the message processors send
outbound messages; and a transport layer, wherein the transport
layer receives the outbound messages sent by the message
processors, wherein the transport layer sends inbound messages to
the message processors, and wherein the transport layer sends
outbound messages to the logical communication channel.
2. The device of claim 1, wherein the object classes include at
least one of a device class, a communication class, a cabinet
class, a processor class, or a meters class.
3. The device of claim 1, wherein the command router uses a
device-to-host subscription list to direct outbound commands to
appropriate message processors, and wherein the command router uses
the device-to-host subscription list to route inbound commands to
command inbound queues.
4. The device of claim 1, wherein a communication device class
connection provides improved access to host status by enabling
communications status information to travel through the command
router and the message processor to the communication device
class.
5. The device of claim 1, wherein the message splitters include
acknowledgement logic that enables the message splitters to send an
acknowledgement receipt after commands have been transmitted.
6. The device of claim 1, wherein the logical communication channel
comprises a network.
7. The device of claim 1, wherein the logical communication channel
comprises an Ethernet, serial, or universal serial bus.
8. The device of claim 1, wherein one or more system hosts are
connected to the logical communication channel to enable
communication with the gaming devices via the logic interface
device.
9. The device of claim 1, wherein the logic interface device is
asynchronous.
10. The device of claim 1, wherein each controllable components of
the gaming device has a corresponding object class in the logic
controller.
11. The device of claim 1, wherein the logic interface device
enables a modular breakdown of components on a gaming platform.
12. A method for interfacing between a gaming device and a logical
communication channel, the method comprising: providing control
logic, wherein the control logic includes a plurality of object
classes that correspond to components of the gaming device, and
wherein the object classes send outbound commands; routing inbound
and outbound commands using a command router, wherein the command
router receives the outbound message commands sent by the object
classes, wherein the command router includes a plurality of command
inbound queues that correspond to the object classes of the logic
controller, wherein the object classes receive inbound message
commands sent from the command inbound queues in the command
router, and wherein the command router duplicates command as
required and sends outbound commands; processing outbound commands
and inbound messages using one or more message processors, each
message processor including a corresponding host, message builder,
and message splitter, wherein the host of each message processor
receives an outbound command sent by the command router, wherein
the message builder of each message processor groups and
encapsulates outbound commands into a single outbound message per
host, wherein the message splitter of each message processor parses
inbound messages into multiple inbound commands, wherein the
command router receives inbound commands from the hosts of the
message processors, and wherein the message processors send
outbound messages; and providing a transport layer, wherein the
transport layer receives the outbound messages sent by the message
processors, wherein the transport layer sends inbound messages to
the message processors, and wherein the transport layer sends
outbound messages to the logical communication channel.
13. The method of claim 11, wherein the object classes include at
least one of a device class, a communication class, a cabinet
class, a processor class, or a meters class.
14. The method of claim 11, wherein the command router uses a
device-to-host subscription list to direct outbound commands to
appropriate message processors, and wherein the command router uses
the device-to-host subscription list to route inbound commands to
command inQueues (i.e., inbound queues).
15. The method of claim 11, wherein a communication device class
connection provides improved access to host status by enabling
communications status information to travels through the command
router and the message processor to the communication device
class.
16. The method of claim 11, wherein the message splitters include
acknowledgement logic that enables the message splitters to send an
acknowledgement receipt after commands have been transmitted.
17. The method of claim 11, wherein the logical communication
channel comprises a network.
18. The method of claim 11, wherein the logical communication
channel comprises an Ethernet, serial, or universal serial bus.
19. The method of claim 11, wherein one or more system hosts are
connected to the logical communication channel to enable
communication with the gaming devices via the logic interface
device.
20. The method of claim 11, wherein the logic interface device is
asynchronous.
21. The method of claim 11, wherein each controllable components of
the gaming device has a corresponding object class in the logic
controller.
22. A method for sending outbound information from a gaming device
to a logical communication channel, the method comprising:
providing control logic, wherein the control logic includes a
plurality of object classes that correspond to components of the
gaming device; sending outbound commands from the object classes to
a command router; receiving outbound commands at the command router
sent by the object classes; routing outbound commands using a
command router, wherein the command router includes a plurality of
command inbound queues that correspond to the object classes of the
logic controller; duplicating commands as required and sending
outbound commands from the command router to one or more message
processors; receiving one or more outbound commands at a host of a
message processor host that are sent by the command router;
processing outbound commands using one or more message processors,
each message processor including a corresponding host, message
builder, and message splitter; grouping and encapsulating outbound
commands into a single outbound message per host at a message
builder of a message processor; sending outbound messages from the
message processors to a transport layer; receiving the outbound
messages at the transport layer sent by the message processors; and
sending outbound messages from the transport layer to the logical
communication channel.
23. A method for receiving inbound information from a logical
communication channel to a gaming device, the method comprising:
providing control logic, wherein the control logic includes a
plurality of object classes that correspond to components of the
gaming device; routing inbound commands to the plurality of object
classes using a command router, wherein the command router includes
a plurality of command inbound queues that correspond to the object
classes of the logic controller, wherein the object classes receive
inbound message commands sent from the command inbound queues of
the command router; processing inbound messages from a transport
layer using one or more message processors, each message processor
including a corresponding host, message builder, and message
splitter, wherein the message splitter of each message processor
parses inbound messages into multiple inbound commands, wherein the
command router receives inbound commands from the hosts of the
message processors; and receiving inbound messages at a transport
layer from the logical communication channel.
24. A logic interface system for interfacing between a
command-driven device and a logical communication channel, the
system comprising: a logic controller, wherein the logic controller
includes a plurality of object classes that correspond to
components of the command-driven device, and wherein the object
classes send outbound commands; a command router, wherein the
command router receives the outbound commands sent by the object
classes, wherein the command router includes a plurality of command
inbound queues that correspond to the object classes of the logic
controller, wherein the object classes receive inbound commands
sent from the command inbound queues of the command router, and
wherein the command router duplicates commands as required and
sends outbound commands; one or more message processors, each
including a corresponding host, message builder, and message
splitter, wherein the host of each message processor receives an
outbound command sent by the command router, wherein the message
builder of each message processor groups and encapsulates outbound
commands into a single outbound message per host, wherein the
message splitter of each message processor parses inbound messages
into multiple inbound commands, wherein the command router receives
inbound commands from the hosts of the message processors, and
wherein the message processors send outbound messages; and a
transport layer, wherein the transport layer receives the outbound
messages sent by the message processors, wherein the transport
layer sends inbound messages to the message processors, and wherein
the transport layer sends outbound messages to the logical
communication channel.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. provisional
patent application No. 60/676,429, filed Apr. 28, 2005, which is
hereby incorporated by reference in its entirety.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material that is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent files or records, but otherwise
reserves all copyright rights whatsoever.
FIELD OF THE INVENTION
[0003] This invention relates generally to a system and method for
providing an interface layer between command-driven devices and a
logical communication channel, and more particularly, to a system
and method for providing a logic interface engine that is utilized
as an interface layer between command-driven devices and a logical
communication channel.
BACKGROUND OF THE INVENTION
[0004] Typically, network data is gathered and transformed into a
standard format before they are transmitted over a network. In
order for information to be moved across a network, the information
is converted into a data stream that corresponds with the packet
structure of the network transfer protocol. This is also true with
respect to command protocols and message protocols, which often
must be converted when transmitting between various locations,
systems, and devices.
[0005] Traditionally, interface and transport layers have been
designed to package and send individual messages and commands with
little or no organization of those commands. In this regard,
messages are typically sent on a first-in, first-out (FIFO) basis
from a general message stack in which the messages are collected.
The stack may become bogged down with messages and commands to and
from various components in a bus or network structure. Although the
order of processing the messages may be altered according to
priority, the message stack operates with little or no regard to
origin or destination.
[0006] Similarly, received messages and commands are processed as
they are received, usually on a FIFO basis, and without regard to
origin or destination. Even in parallel processing systems, one
incoming and one outgoing stack is typically used at the transport
or command layer in a system. Thus, it would be desirable to
provide a system that includes relative parallel processing of
incoming and outgoing messages and commands in a system.
[0007] Accordingly, those skilled in the art have long recognized
the need for a system that is capable of relative parallel
processing of incoming and outgoing messages and commands. This
invention clearly addresses these and other needs.
SUMMARY OF THE INVENTION
[0008] Briefly, and in general terms, a preferred embodiment
resolves the above and other problems by providing a logic
interface device for interfacing between a gaming device and a
logical communication channel. The logic interface device includes:
a logic controller, a command router, one or more message
processors, and a transport layer. The logic controller includes a
plurality of object classes that correspond to components of the
gaming device. The object classes send outbound commands. The
command router receives the outbound commands sent by the object
classes. Additionally, the command router includes a plurality of
command inQueues (inbound queues) that correspond to the object
classes of the logic controller. The object classes receive inbound
commands sent from the command inQueues (inbound queues) of the
command router. The command router duplicates commands, as
required, and sends outbound commands.
[0009] The one or more message processors each include a
corresponding host, message builder, and message splitter. The host
of each message processor receives an outbound command sent by the
command router. The message builder of each message processor
groups and encapsulates outbound commands into a single outbound
message per host. The message splitter of each message processor
parses inbound messages into multiple inbound commands,
Additionally, the command router receives inbound commands from the
hosts of the message processors, and the message processors send
outbound messages. Continuing, the transport layer receives the
outbound messages sent by the message processors, sends inbound
messages to the message processors, and sends outbound messages to
the logical communication channel.
[0010] In accordance with one aspect of a preferred embodiment, the
object classes include at least one of a device class, a
communication class, a cabinet class, a processor class, or a
meters class. Preferably, the command router uses a device-to-host
subscription list to direct outbound commands to appropriate
message processors. Additionally, the command router uses the
device-to-host subscription list to route inbound commands to
command inQueues (i.e., inbound queues). In accordance with another
aspect of a preferred embodiment, a communication device class
connection provides improved access to host status by enabling
communications status information to travel through the command
router and the message processor to the communication device class.
Preferably, the message splitters include acknowledgement logic
that enables the message splitters to send an acknowledgement
receipt after commands have been transmitted.
[0011] In accordance with another aspect of a preferred embodiment,
a logical communication channel comprises a network. Preferably,
the logical communication channel comprises an Ethernet, serial, or
universal serial bus. In another aspect of a preferred embodiment,
one or more system hosts are connected to the logical communication
channel to enable communication with the gaming devices via the
logic interface device. In one embodiment, the logic interface
device is asynchronous. Preferably, each controllable component of
the gaming device has a corresponding object class in the logic
controller. In another aspect of a preferred embodiment, the logic
interface device enables a modular breakdown of components on a
gaming platform.
[0012] In another preferred embodiment, a method for interfacing
between a gaming device and a logical communication channel is
disclosed. The method includes: providing control logic, wherein
the control logic includes a plurality of object classes that
correspond to components of the gaming device, and wherein the
object classes send outbound commands; routing inbound and outbound
commands using a command router, wherein the command router
receives the outbound message commands sent by the object classes,
wherein the command router includes a plurality of command inQueues
(inbound queues) that correspond to the object classes of the logic
controller, wherein the object classes receive inbound message
commands sent from the command inQueues (inbound queues) in the
command router, and wherein the command router duplicates command
as required and sends outbound commands; processing outbound
commands and inbound messages using one or more message processors,
each message processor including a corresponding host, message
builder, and message splitter, wherein the host of each message
processor receives an outbound command sent by the command router,
wherein the message builder of each message processor groups and
encapsulates outbound commands into a single outbound message per
host, wherein the message splitter of each message processor parses
inbound messages into multiple inbound commands, wherein the
command router receives inbound commands from the hosts of the
message processors, and wherein the message processors send
outbound messages; and providing a transport layer, wherein the
transport layer receives the outbound messages sent by the message
processors, wherein the transport layer sends inbound messages to
the message processors, and wherein the transport layer sends
outbound messages to the logical communication channel.
[0013] In still another preferred embodiment, a method for sending
outbound information from a gaming device to a logical
communication channel is disclosed. The method includes: providing
control logic, wherein the control logic includes a plurality of
object classes that correspond to components of the gaming device;
sending outbound commands from the object classes to a command
router-receiving outbound commands at the command router sent by
the object classes; routing outbound commands using a command
router, wherein the command router includes a plurality of command
inQueues (inbound queues) that correspond to the object classes of
the logic controller; duplicating commands as required and sending
outbound commands from the command router to one or more message
processors; receiving one or more outbound commands at a host of a
message processor that are sent by the command router; processing
outbound commands using one or more message processors, each
message processor including a corresponding host, message builder,
and message splitter; grouping and encapsulating outbound commands
into a single outbound message per host at a message builder of a
message processor; sending outbound messages from the message
processors to a transport layer; receiving the outbound messages at
the transport layer sent by the message processors; and sending
outbound messages from the transport layer to the logical
communication channel.
[0014] In yet another preferred embodiment, a method for receiving
inbound information from a logical communication channel to a
gaming device is disclosed. The method includes: providing control
logic, wherein the control logic includes a plurality of object
classes that correspond to components of the gaming device; routing
inbound commands to the plurality of object classes using a command
router, wherein the command router includes a plurality of command
inQueues (inbound queues) that correspond to the object classes of
the logic controller, wherein the object classes receive inbound
message commands sent from the command inQueues (inbound queues) of
the command router; processing inbound messages from a transport
layer using one or more message processors, each message processor
including a corresponding host, message builder, and message
splitter, wherein the message splitter of each message processor
parses inbound messages into multiple inbound commands, wherein the
command router receives inbound commands from the hosts of the
message processors; and receiving inbound messages at a transport
layer from the logical communication channel.
[0015] In another aspect of a preferred embodiment, a logical
interface system interfaces between a non-gaming device (e.g., a
non-gaming command-driven device) and a logical interface
channel.
[0016] Other features and advantages of the invention will become
apparent from the following detailed description when taken in
conjunction with the accompanying drawings, which illustrate by way
of example, the features of the claimed invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] FIG. 1 illustrates a relational diagram of the logic
interface engine showing data flow through various components of a
preferred embodiment;
[0018] FIG. 2 illustrates a relational diagram showing various
components of a logic controller, in accordance with a preferred
embodiment;
[0019] FIG. 3 illustrates a relational diagram showing various
components of a command router, in accordance with a preferred
embodiment;
[0020] FIG. 4 illustrates a relational diagram showing data flow
through message processors, in accordance with a preferred
embodiment;
[0021] FIG. 5 illustrates a relational diagram showing various
components of a transport layer, in accordance with a preferred
embodiment; and
[0022] FIG. 6 illustrates a relational diagram showing inbound and
outbound data flow through various components of logic interface
engine, in accordance with a preferred embodiment.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0023] Briefly stated, a preferred embodiment of a logic interface
engine and system, constructed in accordance with the claimed
invention, is directed towards an interface device that is utilized
between an electronic gaming machine (EMG) and a logical
communication channel. In such a device, bidirectional data flow is
possible through the various components of the logic interface
engine. A preferred embodiment of the logic interface engine
increases reliability and expandability with respect to interfacing
gaming devices and logical communication channels. In a preferred
embodiment, the logic interface device enables a modular breakdown
of components on a gaming platform. In other preferred embodiments
of the claimed invention, the logic interface engine is utilized as
an interface layer between other generic (non-gaming) devices and
other logical communication channels (e.g., Ethernet, serial, USB,
or other logical channel). In some such embodiments, the generic
(non-gaming) devices are command-driven devices.
[0024] Referring now to the drawings, wherein like reference
numerals denote like or corresponding parts throughout the drawings
and, more particularly to FIGS. 1-5, there is shown one embodiment
of a logic interface engine 10 constructed in accordance with the
claimed invention. Specifically, with respect to the preferred
embodiment logic interface engine 10 shown in FIG. 1, data flow is
illustrated as a bidirectional path through the various components
of the logic interface engine. As shown in FIG. 1, the logic
interface engine 10 includes a logic controller 20, a command
router 30, a message processor 40, and a transport layer 50. The
logic interface engine 10 is an interface device that, in one
embodiment, is utilized between an electronic gaming machine (EMG)
and a logical communication channel.
[0025] Preferably, the logic interface engine 10 is defined as the
complete interface between the EGM and the logical communication
channel, but excludes (i.e., is not utilized for interfacing with)
communication channel drivers. In another aspect of one preferred
embodiment, persistent memory is only available outside of the
grand transport block 60 (i.e., the command router 30, the message
processor 40, and the transport layer 50). In such an embodiment,
different manufactures/platforms can provide persistent memory API
points that the grand transport block 60 can reference
indirectly.
[0026] Preferably, the logic controller 20 provides command
generation and processing for the grand transport block 60. In one
preferred embodiment, logic is highly reusable (i.e., standardized)
for different manufactures. However, some customization of the
board support package 22 (BSP) in the logic controller 20 may be
required in order for the BSP to properly interface with devices
and components from varying manufactures. Preferably, the logic
controller 20 further includes a logic manager 24 for managing
logic commands.
[0027] As shown in FIG. 2, in another aspect of a preferred
embodiment, the logic controller 20 also contains the EMG object
classes 26 (e.g., deviceClass 26.sub.1, communicationClass
26.sub.2, cabinetClass 26.sub.3, processorClass 26.sub.4,
metersClass 26.sub.5, and the like) that are necessary for proper
interaction with the electronic gaming machine. The EMG object
classes 26 manage the associated transaction logs in persistent
memory. Preferably, the interaction between the EMG object classes
26 and the grand transport block 60 provides the necessary events
for commit, rollback, and/or recovery of complete transactions.
[0028] Referring again to FIG. 2, the core EMG object classes 26
are identified in the generic logic controller 20. FIG. 2
illustrates an exemplary simplification of the logic controller 20.
An actual implementation of a preferred embodiment includes every
EMG object class 26, including any multiple instances of the same
device, in order for logical commands to be directed to each EMG
object class. Referring again to FIG. 2, the components 28 to the
left of the logic controller 20 are interfaces to the BSP 22. These
interfaces 28 to the BSP 22 are configured to interface with EMG
object classes 26, EMG optioning data, and EMG control logic.
[0029] In one preferred embodiment shown in FIG. 2, with respect to
outbound information, the EMG object classes 26 are capable of
sending fully formed commands to the command router 30.
Correspondingly, with respect to inbound information, the EMG
object classes 26 are capable of receiving fully formed commands
from the command router 30. In another aspect of a preferred
embodiment, the deviceClass 26.sub.1 and communicationClass
26.sub.2 have a special relationship with the command router 30, as
indicated in FIG. 2. These object classes (i.e., the deviceClass
26.sub.1 and communicationClass 26.sub.2) are unique in that they
contain the necessary information (i.e., additional logic) to
control (or react to) events related to the command router 30, the
message processor 40, and the transport layers 50. The additional
logic provided to the deviceClass 26.sub.1 and communicationClass
26.sub.2 simplifies the connection between the logic manager 24 and
the command router 30. With respect to the deviceClass 26.sub.1, as
described in full detail below, the command router 30 uses the
device-to-host subscription lists to direct the outbound commands
to the appropriate message processor 40.
[0030] With respect to the communicationClass 26.sub.2, as
described below, communication status information is passed through
the command router 30 so that the router can notify the
communicationClass 26.sub.2 of changes in status. Otherwise stated,
the communicationClass 26.sub.2 connection is simplified in order
to provide the communicationClass with improved access to the host
status. Accordingly, the communications status travels through each
module (e.g., the command router 30 and the message processor 40)
to the communicationClass 26.sub.2 where the communications status
information is most useful. For example, in one preferred
embodiment, when a timeout occurs at the transport layer a
communication status event is sent to the communicationClass
26.sub.2.
[0031] In one aspect of a preferred embodiment, the logic manager
24 discovers all instances of the EMG object classes 26 and
registers them with EGM deviceClass 26.sub.1. The EGM deviceClass
26.sub.1 then, in turn, registers each instance with the command
router 30. Additionally, the default owner host references are
presented to the command router 30 via the EGM deviceClass
26.sub.1. Preferably, each instance of an EMG object class 26 is
aware of its owner. This information is necessary for the EMG
object classes 26 to make a determination if a control command
should be processed. A control command is any command that only the
owner has permission to request. In one preferred embodiment, logic
manager 24 initializes the EGM communicationClass 26.sub.2 and
automatically subscribes each registered host to the
communicationClass 26.sub.2.
[0032] In one preferred embodiment of the logic interface engine
10, the EMG object classes 26 are responsible for class specific
content XML formatting. Preferably, the EMG object classes 26 send
fully formed (logic interface engine-compliant), command content to
the command router 30. This is analogous to data marshalling the
specific content. Data marshalling is the process of gathering data
and transforming it into a standard format before the data is
transmitted over a network. This allows the data to be able to
transcend network boundaries. In order for an object to be moved
over a network, the object must be converted into a data stream
that corresponds with the packet structure of the network transfer
protocol. After the data is transmitted, the receiving device
converts the marshaled data back into an object. Similarly, in one
preferred embodiment of the logic interface engine 10, inbound
commands have (logic interface engine-compliant) message
class-specific content `ripped` down (e.g., down-converted) into a
usable format. This is analogous to data de-marshalling.
[0033] Referring now to FIG. 3, the core EMG object classes 26 are
identified along with the command router 30. FIG. 3 illustrates an
exemplary simplification of the command router 30. An actual
implementation of a preferred embodiment includes every EMG object
class 26 in the logic controller 20, including any multiple
instances of the same device, in order for logical commands to be
directed to each EMG object class.
[0034] In a preferred embodiment of the logic interface engine 10,
the EMG object classes 26 of the logic controller 20 send complete
(logic interface engine-compliant) commands to the command router
30. Similarly, the message processors 40 preferably send complete
(logic interface engine-compliant) commands to the command router
30. Notably, in one preferred embodiment, communication status
information is passed through the command router 30 so that the
command router can notify the communicationClass 26.sub.2 of
changes in status.
[0035] A preferred embodiment of the logic interface engine 10
allows hosts to subscribe to devices that the host does not own.
Otherwise stated, the logic interface engine 10 allows guest host
subscriptions. These guest host subscriptions are typically managed
in the deviceClass 26.sub.1 where they are referred to a
subscriptions list.
[0036] However, in a preferred embodiment, all of the subscription
list requests and other related subscription list related processes
are controlled by the command router 30. Accordingly, in a
preferred embodiment the logic manager 24, the subscription list of
the deviceClass 26.sub.1, and the command router 30, all have
special interactions with the subscription lists. Specifically, the
subscription logic has been centralized in the command router 30 so
that the deviceClass 26.sub.1 do not need to be concerned with
guest subscriptions. In order to comply with some related
protocols, it is beneficial to ensure that when a command is sent
to an owner device, that a copy is also sent to any guest hosts. As
such, in a preferred embodiment of the logic interface engine 10,
any time a message is sent to an owner host, a copy is also sent to
any guest subscribers.
[0037] The command router 30 performs this copying and distribution
on behalf of the logic interface engine 10. By using centralized
logic in command router 30 the deviceClass 26.sub.1 in the logic
controller 20 does not need to be concerned with (i.e., perform any
processing related to) guest subscriptions. Instead, the
deviceClass 26.sub.1 need only be concern with talking to their
owner host. The command router 30 is responsible for determining
who is on the subscription list and dispatching the multiple copies
as needed.
[0038] Accordingly, as shown in FIG. 3, the command router 30 uses
the device-to-host subscription lists to direct the outbound
commands to the appropriate message processor 40. Similarly, the
command router 30 uses the device-to-host subscription lists to
route the inbound command to the appropriate command inQueues
34.sub.1,2, . . . n, (i.e., inbound queues) as shown in FIG. 3.
Each command InQueue 34.sub.1,2, . . . n (i.e., inbound queues) of
the command router 30 transmits inbound information to its
corresponding EMG object class 26.sub.1,2, . . . n in the logic
controller 20. In one preferred embodiment, the command router 30
has no control over the subscriptions. Instead, the command router
30 uses the subscriptions to direct the commands to the appropriate
InQueue 34.sub.1,2, . . . n.
[0039] In a preferred embodiment of the logic interface engine 10,
the logic of the command router 30 does not make assumptions with
respect to Owner or Guest hosts when directing inbound commands.
However, the command router 30 preferably will pass on a hostID to
the EMG object classes 26 in order to determine if the inbound
command is from the Owner host. Continuing, in one preferred
embodiment, the logic of the command router 30 manages the
sessionIDs and commandIDs that are used with the commands. In this
regard, since a single outbound command may be directed to many
hosts, copies of this command must have the same sessionId and
unique commandId for every host to which the command is
directed.
[0040] Referring now to FIG. 4, regarding outbound information, a
preferred embodiment of the logic interface engine 10 includes a
plurality of outbound message processors 40, namely one outbound
message processor 40.sub.1,2, . . . n for each host 44.sub.1,2, . .
. n. Notably, the message processors 40 in a preferred embodiment
of the logic interface engine 10 are intelligent message processors
40. In this regard, outbound messages are composed of commands that
are transmitted from the command router 30. The intelligent message
processors 40 aggregate these messages and send them out as a
single message per host 44.sub.1,2, . . . n. Similarly, when a
system host (from across a network and outside of the logic
interface engine 10) sends a message to the gaming device, the
intelligent message processors 40 decompose the message into its
constitute commands. Preferably, the intelligent message processor
40 performs this process of monitoring the queues, grouping and
encapsulating the commands, and composing a message containing the
multiple commands (per host), asynchronously. In a preferred
embodiment, the logic controller 20 is not even aware that this
grouping and encapsulating process is occurring.
[0041] Additionally, in a preferred embodiment, the intelligent
message processors 40 include acknowledgement functionality in
connection with messages (and in some embodiments commands as
well). Otherwise stated, when a message is sent out, an
acknowledgement receipt is received in reply. In a preferred
embodiment, the acknowledgement logic is encapsulated in the
outbound message such that other upstream components do not have to
be concern with the aspect. Preferably, this acknowledgement logic
is self-contained and automatic, which advantageously simplifies
software design.
[0042] More specifically, as shown in FIG. 4, outbound commands
sent from the command router 30 are grouped and sent out together
to each outbound message processor 40.sub.1,2, . . . n and its
corresponding host 44.sub.1,2, . . . n. Each host 44.sub.1,2, . . .
n forwards these outbound commands to a message builder 46.sub.1,2,
. . . n (within the outbound message processor 40.sub.1,2, . . . n)
that encapsulates the outgoing grouped commands into messages which
are, in turn, forwarded to the transport layer 50, as shown in FIG.
4.
[0043] As described above, for outbound information, the host
44.sub.1,2, . . . n queue of each message processor 40.sub.1,2, . .
. n forwards its respective outbound commands to its respective
message builder 46.sub.1,2, . . . n (which encapsulates the
outgoing grouped commands into messages) which, in turn, forwards
the message to the transport layer 50, until the message that
contains the command is acknowledged. Once acknowledged, the
command can be removed from the queue. Additionally, the message
processors 40.sub.1,2, . . . n manage retry logic. Preferably, the
message processors 40.sub.1,2, . . . n also notify the command
router 30 when a host 44.sub.1,2, . . . n dies or is established.
Further, the message processors 40.sub.1,2, . . . n manage an
independent process or thread for each host 44.sub.1,2, . . .
n.
[0044] As shown in FIG. 4, for inbound information, the message
splitter 48.sub.1,2, . . . n of each message processor 40.sub.1,2,
. . . n splits inbound messages into commands and transmits each
command to the command router 30 before acknowledging the inbound
message. In this manner, utilizing separate message processors
40.sub.1,2, . . . n (i.e., having multiple inbound queues) prevents
a single slow host from backing up communication through other
hosts in the other message processors 40.sub.1,2, . . . n.
Additionally, for inbound information processing, the message
splitter 48.sub.1,2, . . . n of each message processor 40.sub.1,2,
. . . n provides duplicate message checking, parsing out of
commands, and verification of commandID order. It will be
appreciated by one of ordinary skill in the art that a host
44.sub.1,2, . . . n, message builder 46.sub.1,2, . . . n, and
message splitter 48.sub.1,2, . . . n may be consolidated into a
single component or integrated into one another as part of the
message processor 40.sub.1,2, . . . n in other preferred
embodiments of the logic interface engine 10.
[0045] Thus, in a preferred embodiment, the message processor 40 is
responsible for: (1) combining outbound commands into messages, and
proving the (logic interface engine-complaint) message header; (2)
processing message acknowledgements; (3) managing message retries;
(4) splitting inbound messages into commands, passing the commands
to the command router 30, and acknowledging the message; (5)
managing the timeout for a keep-alive command. A keep-alive command
enables clients to keep a connection to a server open and pipeline
multiple requests over the connection, without the connection
timing out and disconnecting. A keep-alive prevents clients from
having to re-negotiate a new session for every request due to a
connection timing out.
[0046] In one preferred embodiment, when a timeout occurs, a
communication status event is sent to the appropriate
communicationClass 26.sub.2 so that a keep-alive command can be
generated. Interestingly, when using this configuration, the
message processor 40 is aware of the communication status for each
host 44.sub.1,2, . . . n. As such, the message processor 40 is also
a source of communication status information.
[0047] Referring now to FIG. 5, in one preferred embodiment, the
transport layer 50 of the logic interface engine 10 is not viewable
to other components outside of the transport layer itself.
Otherwise stated, implicit knowledge of how the transport layer 50
works, and/or what the transport layer does, is not required by
either the command router 30 or the communication channel drivers.
Additionally, in a preferred embodiment logic interface engine 10,
the transport layer 50 is unaware of the message content that it is
transmitting. Preferably, the transport layers 50 are configurable
for any number of (logic interface engine-complaint) device
instances. In one preferred embodiment of the logic interface
engine 10, the transport layer 50 includes diagnostic and debugging
capabilities to facilitate developers with diagnostic issues.
Preferably, the transport layer receives messages, handles
security, SOAP (Simple Object Access Protocol), SSL (Secure Sockets
Layer) HTTP (Hyper Text Transfer Protocol), DHCP (Dynamic Host
Configuration Protocol), and the like.
[0048] Furthermore, in one preferred embodiment, no persistent
memory is available to the transport layer. In such an embodiment,
the persistent memory is provided by the EMG object classes 26
through the command router 30. Additionally, communication status
information is preferably passed to the EMG object classes 26
through the command router 30.
[0049] In another aspect of a preferred embodiment, the transport
layer 50 provides message-envelope, header-specific (logic
interface engine-compliant) content for XML formatting. This is
analogous to data marshalling the header-specific content.
Similarly, in one preferred embodiment of the logic interface
engine 10, inbound commands have message-envelope, header-specific
(logic interface engine-compliant) content `ripped` down (e.g.,
down-converted) into a usable format. This is analogous to data
de-marshalling.
[0050] FIG. 6 illustrates inbound and outbound data flow through
various components of logic interface engine. The invention shown
in FIG. 6 displays a method for sending outbound information from a
gaming device to a logical communication channel, and receiving
inbound information from a logical communication channel to a
gaming device. Exemplary embodiments of methods for implementing
this invention are described in further detail below.
[0051] A method for sending outbound information from a gaming
device to a logical communication channel includes: providing
control logic, wherein the control logic includes a plurality of
object classes that correspond to components of the gaming device;
sending outbound commands from the object classes to a command
router; receiving outbound commands at the command router sent by
the object classes; routing outbound commands using a command
router, wherein the command router includes a plurality of command
inQueues (inbound queues) that correspond to the object classes of
the logic controller; duplicating commands as required and sending
outbound commands from the command router to one or more message
processors; receiving one or more outbound commands at a host of a
message processor host that are sent by the command router;
processing outbound commands using one or more message processors,
each message processor including a corresponding host, message
builder, and message splitter; grouping and encapsulating outbound
commands into a single outbound message per host at a message
builder of a message processor; sending outbound messages from the
message processors to a transport layer; receiving the outbound
messages at the transport layer sent by the message processors; and
sending outbound messages from the transport layer to the logical
communication channel.
[0052] A method for receiving inbound information from a logical
communication channel to a gaming device includes: providing
control logic, wherein the control logic includes a plurality of
object classes that correspond to components of the gaming device;
routing inbound commands to the plurality of object classes using a
command router, wherein the command router includes a plurality of
command inQueues (inbound queues) that correspond to the object
classes of the logic controller, wherein the object classes receive
inbound message commands sent from the command inQueues (inbound
queues) of the command router; processing inbound messages from a
transport layer using one or more message processors, each message
processor including a corresponding host, message builder, and
message splitter, wherein the message splitter of each message
processor parses inbound messages into multiple inbound commands,
wherein the command router receives inbound commands from the hosts
of the message processors; and receiving inbound messages at a
transport layer from the logical communication channel.
[0053] While one specific embodiment of the logic interface engine
10 has been described in detail, those of ordinary skill in the art
will appreciate that other implementations of the logic interface
engine 10 can be utilized without departing from the scope of the
above-described technology. Further, those of ordinary skill in the
art will appreciate that while the logic interface engine 10 has
been described with regard to the gaming environment, the logic
interface engine 10 and related technology may be used in other
environments as well. By way of example only, and not by way of
limitation, the logic interface engine 10 can be used in the
telecommunications, computers, network, data transmission,
Internet, and other related areas that require passing data and/or
information between a message protocol and a command protocol.
[0054] Several preferred embodiments of a system and method for the
logic interface engine 10 have been described above. Attached in
Appendices hereto are materials and protocols that may be used: (1)
in support of the above described embodiments and implementations,
(2) as one possible environment for the above described embodiments
and implementations, and (3) as alternate preferred embodiments of
the above described embodiments and implementations.
[0055] Although the invention has been described in language
specific to computer structural features, methodological acts, and
by computer readable media, it is to be understood that the
invention defined in the appended claims is not necessarily limited
to the specific structures, acts, or media described. Therefore,
the specific structural features, acts and mediums are disclosed as
exemplary embodiments implementing the claimed invention.
[0056] Furthermore, the various embodiments described above are
provided by way of illustration only and should not be construed to
limit the invention. Those skilled in the art will readily
recognize various modifications and changes that may be made to the
claimed invention without following the example embodiments and
applications illustrated and described herein, and without
departing from the true spirit and scope of the claimed invention,
which is set forth in the following claims.
* * * * *