WO2006115723A2

WO2006115723A2 - Logic interface engine system and method

Info

Publication number: WO2006115723A2
Application number: PCT/US2006/012832
Authority: WO
Inventors: Anthony E. Green; Jordan J. Strub; Patel Pravinkumar
Original assignee: Bally Gaming International, Inc.
Priority date: 2005-04-28
Filing date: 2006-04-07
Publication date: 2006-11-02
Also published as: US8900054B2; US20080064501A1; WO2006115723A3; US20060247057A1

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.

Description

LOGIC INTERFACE ENGINE SYSTEM AJVD METHOD

COPYRIGHT NOTICE

[0001] 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

[0002] 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

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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

[0016] FIG. 1 illustrates a relational diagram of the logic interface engine showing data flow through various components of a preferred embodiment;

[0017] FIG. 2 illustrates a relational diagram showing various components of a logic controller, in accordance with a preferred embodiment;

[0018] FIG. 3 illustrates a relational diagram showing various components of a command router, in accordance with a preferred embodiment;

[0019] FIG. 4 illustrates a relational diagram showing data flow through message processors, in accordance with a preferred embodiment;

[0020] FIG. 5 illustrates a relational diagram showing various components of a transport layer, in accordance with a preferred embodiment; and

[0021] 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

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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 26i, communicationClass 26₂, cabinetClass 26₃, processorClass 26₄, metersClass 26₅, 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.

[0027] 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.

[0028] 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 2O₁ and communicationClass 26₂ have a special relationship with the command router 30, as indicated in Fig. 2. These object classes (i.e., the deviceClass 2O₁ and communicationClass 26₂) 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₁ and communicationClass 26₂ simplifies the connection between the logic manager 24 and the command router 30. With respect to the deviceClass 2O₁, 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.

[0029] With respect to the communicationClass 2O₂, as described below, communication status information is passed through the command router 30 so that the router can notify the communicationClass 26₂ of changes in status. Otherwise stated, the communicationClass 26₂ 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₂ 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₂.

[0030] 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 2O₁. The EGM deviceClass 2O₁ 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 2O₁. 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₂ and automatically subscribes each registered host to the communicationClass 26₂.

[0031] 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.

[0032] 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.

[0033] 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₂ of changes in status.

[0034] 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 deviceClass26j where they are referred to a subscriptions list.

[0035] 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 deviceClass26_l5 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 deviceClass26_! 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.

[0036] 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 26j in the logic controller 20 does not need to be concerned with (i.e., perform any processing related to) guest subscriptions. Instead, the deviceClass 2O₁ 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.

[0037] 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_1;2j ,._n, (i.e., inbound queues) as shown in Fig. 3. Each command InQueue 34_lj2; ..._n (i.e., inbound queues) of the command router 30 transmits inbound information to its corresponding EMG object class 26_lj2, ..._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_1;2j ,..„.

[0038] 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 sessionld and unique commandld for every host to which the command is directed.

[0039] 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_1;2j ..._n for each host 44_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^2, ._,.„. 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.

[0040] 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.

[0041] 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_1J2J ..._n and its corresponding host 44_1]2i ..._n. Each host 44_1;2j ,.,_n forwards these outbound commands to a message builder 46_1J2J ,.._n (within the outbound message processor 40_lj2, .,,„) that encapsulates the outgoing grouped commands into messages which are, in turn, forwarded to the transport layer 50, as shown in Fig. 4.

[0042] As described above, for outbound information, the host 44_1;2; .._.„ queue of each message processor 40_lj2, ..._n forwards its respective outbound commands to its respective message builder 46_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 4O₁^, ..._n manage retry logic. Preferably, the message processors 40_1;2, .,.„ also notify the command router 30 when a host 44_lj2) ..._ndies or is established. Further, the message processors 40_1J2I ..._n manage an independent process or thread for each host 44_lj2; ...„.

[0043] As shown in Fig. 4, for inbound information, the message splitter 48_1;2, ..._n of each message processor 40_lj2, ..._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_1>2> „.„ (i.e., having multiple inbound queues) prevents a single slow host from backing up communication through other hosts in the other message processors 40_1;2, ...„. Additionally, for inbound information processing, the message splitter 48^₂, ..._n of each message processor 40_li2, ...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_1>2> ..._n , message builder 46_1;2, ..._n , and message splitter 48_1;2, .._.n may be consolidated into a single component or integrated into one another as part of the message processor 40_lj2j ..._n in other preferred embodiments of the logic interface engine 10.

[0044] 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.

[0045] In one preferred embodiment, when a timeout occurs, a communication status event is sent to the appropriate communicationClass 26₂ 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₁,2, ..._n- As such, the message processor 40 is also a source of communication status information.

[0046] 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. [0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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. [0054] 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.

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.

Claims

WHAT IS CLAIMED:

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 objpct 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 I₃ 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.