WO2009001075A1

WO2009001075A1 - Entertainment device

Info

Publication number: WO2009001075A1
Application number: PCT/GB2008/002168
Authority: WO
Inventors: Alistair Hopkins
Original assignee: Inspired Gaming (Uk) Limited
Priority date: 2007-06-27
Filing date: 2008-06-24
Publication date: 2008-12-31
Also published as: GB0712402D0

Abstract

Pay to play entertainment machines or devices for gaming, gambling and other entertainment functions used in public spaces such as bars, clubs etc are networked and centrally controlled. Each entertainment device has at least one payment mechanism such as a coin acceptor or a card reader. Content executables (e.g. games) are configured to use a set of generic payment instruction messages to communicate with the payment mechanisms. Locally applicable requirements relating to credit handling operations in the real and virtual environment of the entertainment device can be implemented without modifying content executables. Operation of generic entertainment device is initialised when the device boots-up produces a custom shell and sends the MAC data to the central file server which passes the configuration data specific for that location to the device.

Description

ENTERTAINMENT DEVICE

The present invention relates to networked entertainment devices and in particular to entertainment machines or devices for use in public spaces such as bars, clubs, pubs, arcades and the like. Examples of such networked entertainment devices include video and/or audio jukeboxes, gambling machines such as slot machines including so-called 'one-armed bandits' and playing card game based systems, automated betting systems for both real and virtual events, video gaming machines and general arcade games.

There are a large number of different types of entertainment devices in the public space. Each type of device can have significantly different properties, in terms of the entertainment functions provided, the entertainment content available for display and use, and the permissible rules of operation of the machine. There has recently been a trend towards providing multi-function machines in which software and firmware can be configured on generic processor-based machines in order to provide a range of different possibilities for the type of entertainment content being offered. This enables common hardware to be used in many different environments, configured to provide entertainment content according to local requirements, legislation etc. This also enables entertainment content to be updated more readily as business requirements and popularity of entertainment content change.

For example, in a common application, a slot machine may provide an assortment of arcade games, quiz games and gambling games. Some of the entertainment content may be universal, i.e. provided on all machines of that type, while some may be selected by the manager of the premises in which the machine is operated. Some of the entertainment content may be admissible only during certain hours of the day, e.g. in the case of family pubs. The slot machine may be configured to display advertising material while in a standby mode of operation or during game play. The slot machine may be configured to display information related to local activities or events such as a happy hour drink offer or pub quiz. The local environment in which a machine operates, both real (e.g. physical and geographical location) and virtual (e.g. legislative and business environment) will collectively be referred to in this specification as the domain of operation.

Often, such machines have some form of payment mechanism, being coin, token or card operated.

There has also recently been a trend towards networking entertainment devices so that they can, to some extent, be controlled, configured and/or monitored remotely over the public telecommunications network. For example, it is now well-known for jukebox systems to routinely download new audio and video content from a central server as new content is released and becomes popular.

A problem with configuration of generic entertainment devices is the complexity of the task of ensuring that each device controlled within a large network is configured, maintained and operated in an appropriate manner for its current domain of operation. As suggested above, there are often a very large number of competing requirements that must be taken into account.

For example, the owner or operator of such entertainment devices may require specific controls in respect of entertainment content, pricing, advertising content etc, while allowing the local business (e.g. pub) in whose premises the device resides some flexibility in determining content which is locally popular, relevant to local trade, or useful in specific promotions. Furthermore, third parties such as licensees, sponsors, etc may have an interest in ensuring that advertising content appears in association with relevant entertainment content and possibly also at specific times and in specific formats. Furthermore, strict legislation controlling the use of entertainment devices is often determined on both a national and a regional level, as well as being specific to the type of premises in which the device is being operated and the type of entertainment content being offered. For example, legislation may govern both the type of entertainment content (e.g. gambling or game play) as well as the functionality (amount of payout or form of payout). Thus, ensuring that each entertainment machine in a large distributed network of machines is configured to operate correctly is a difficult task usually requiring complex preparation prior to installation and on-site service visits to configure and reconfigure machines.

A particular problem associated with the use of networks of entertainment devices with varying entertainment content is to ensure that all the entertainment devices have the correct entertainment content loaded onto the entertainment device for that location.

Another problem is to ensure that each entertainment device has current instructions, applications and functionality. Furthermore, as mentioned above, the domain of operation of the entertainment device may also influence the allowable operations that can be carried out. It is a time consuming, expensive and error - prone activity to ensure that entertainment content provided to entertainment devices is correctly modified and/or configured e.g. for working with the credit handlers and domains of operation of the entertainment devices for which it is destined.

Another particular problem associated with networks of entertainment devices at least some of which have time-dependent operations or applications relates to the difficulty of ensuring that there is consistency and/or synchronisation of the operations throughout the network.

It would be highly desirable for entertainment devices to be managed centrally from a central or distributed control server in a manner that ensures that all machines in the network operate and are configured correctly for their domain of operation. It would also be highly desirable for each networked entertainment device to be remotely monitorable to verify its present configuration.

It would also be highly desirable to be able to remotely control the configuration of each machine. It would also be highly desirable to provide for expedient delivery of event messages generated by different entertainment devices to appropriate entities according to the type of event message. It would also be highly desirable for the operation of the network of entertainment devices to be time consistent and/or synchronised throughout the network.

It is an object of the present invention to provide an improved entertainment device which overcomes some or all of the problems associated with prior art devices.

According to one aspect, the present invention provides a method of initialising operation of one generic entertainment device in a network of generic entertainment devices, each of the devices having an attached payment mechanism, the method comprising: sending an identification signal representing said one generic entertainment device, for initialisation in the network, to a central configuration server of the network; then the central configuration server sending configuration data for the said generic entertainment device to said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network.

Preferably the method comprises one or more of the following features:- • the identification signal originates from the device.

• the identification signal originates from the device after boot-up and production of a custom shell at the device.

• the identification signal comprises the MAC address for the device.

• the central configuration server sends to the device only configuration data for creation of entertainment content at the device.

• after receiving the configuration data, the device creates an software providing logical control at the device.

• the device creates entertainment content comprising graphics content operable at the device. • the device creates entertainment content comprising graphics content and most or all of the entertainment content operable at the device. • the device creates entertainment content graphics contents, most or all the entertainment content used at the device, and peripherals applications for the device.

• the device comprises one or more of the following: a gambling unit, a gaming unit, a quiz unit, and arcade unit, a jukebox unit.

In the present invention, software is loaded from a persistent memory which is shared between all devices into volatile (runtime) memory which is unique to each device. The present invention creates endpoints which have their own unique identifiers despite loading the same software, this being achieved by mapping different data depending on the MAC address of the connecting device.

According to another aspect, the present invention provides a network of generic entertainment devices having attached payment mechanisms, a central configuration server of the network having means to receive an identification signals representing individual generic entertainment devices for initialisation of that device in the network; the central configuration server being operable to send configuration data for a generic entertainment device to said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network.

According to a further aspect, the present invention provides a generic entertainment device having an attached payment mechanism and for operation in a network of generic entertainment devices having attached payment mechanisms, the device having means to send an identification signal representing said one generic entertainment device, for initialisation in the network, to a central configuration server of the network, and means to receive, from the central configuration server, configuration data for the said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network. The present invention may provide execution of all programs with consistency throughout the network, being at execution time from the server.

Furthermore, this can ensure ready and easy updating of devices throughout the network with assurance that the content is identical, even though each of the devices in the network has its own distinct identity and is capable of having its own unique content and performance.

In order that the invention may more readily be understood, embodiments of the present invention will now be described by way of example and with reference to the accompanying drawings in which:

Figure 1 is a schematic overview of a network of entertainment devices embodying the present invention;

Figure 2 is a schematic block diagram of the set-up operation for a new device in the network of Figure 1 ;

Figure 3 is a schematic diagram of a networked entertainment device and control system of Figure 1;

Figure 4 is a detailed schematic diagram of the entertainment device and server of Figure 3.

Throughout the present specification, the expression 'entertainment device' is used to encompass all forms of 'pay-to-play' type machines including gaming machines, gambling machines, audio and video jukeboxes and any other machine adapted to provide digital data content to a user, in return for payment via a payment mechanism. Thus, the expression 'entertainment device' may also encompass a machine adapted to deliver digital entertainment content (such as audio or video data) directly to a user device, such as an MP3 player.

The digital content delivered to the user may be of the form of an interactive program requiring continuous or periodic input from the user (e.g. a game or a quiz) via a user interface (e.g. keyboard, button set, touch screen, control console etc) or may be a non-interactive program requiring no input from the user once the program is initiated (e.g. the playing of music, a movie clip, advertising or other display content). More generally, the program which runs on the entertainment device to deliver digital content may be referred to herein as 'payload'.

The expression 'payment mechanism' is intended to encompass any form of physical and/or electronic payment mechanism receiving from the user a form of payment token including any one or more of a coin acceptor mechanism, a banknote reader, a credit card reader, a credit token, a proprietary card reader and the like.

There is shown in Figures 1 to 4, a network 1 of entertainment devices ED 1 to 4 are operated from a central network server 2. The devices ED 1 to 4 may be located in different commercial environments for example ranging between family pubs, nightclubs, and so on, with a variety of local requirements, legalisation and so on. They may have different types of customers, and, indeed, the customers for a particular device and location may vary widely at different times of the day.

In order to add a new entertainment device ED5 to network 1, an internal POST routine is run and BIOS chips 10 are actuated to send BIOS signals to Boot Server unit 12 of network server 2. Boot server unit 12 sets up a RAM disk 13 for a standard Operating System 14 image to be input to ED5 for boot-ups which includes construction of a customised shell 15 specific to the configuration data of that ED5.

The customised shell 15 is then used to map a device from a file server 16 which holds a library of configurations data for all remote units of network. This file server 16 also provides instructions to map various other devices to action logging and unit-specific content.

Once the respective shared drives are mapped, the custom shell 15 opens up software providing logical control 17 to operate the graphics drives and software, the contents of ED5 and the peripherals of ED5. When the Operating System 14 is launched, it is configured to log straight into the default user. Then it sets up a new shell which mounts the main content drive at a fixed reference.

The shell 15 then checks for data on the network drive to see if an identity image for a machine unique identifier is set against the current MAC address. If there is, a mapped drive is added which contains unit-specific configuration for that machine unique identifier.

If there is no identity, an application is launched to allow selection of the machine unique identifier which is to be used, and to ensure that the same machine unique identifier is not being used twice.

If the shared mounted drive is called S and the specific machine unique identifier is called Q:, the software providing logical control need only be changed

• so that the configuration for the identity image is; wrapper. java. classpath.1 =S: \logicalcontrol\dist\lib\comm.jar wrapper. java. classpath.2=.. \lib/*.jar wrapper. java. classpath.3 =.. \conf/user wrapper. java. classpath.4=Q:\

• The core configuration specifies the shared drive for content, widgets and working directories as working_dir=S:/logicalcontrol/working content _base=S:/logicalcontrol/content/apps widget _base=S:/logicalcontrol/content/widgets.

• The message service software (e.g. MQTT MessageListener) uses the private drive (Q:) for the queue-and-send operation.

Thus the working directory will automatically use subdirectories for all different machine unique identifiers.

The message service architecture can be modified so that each running logical control software write messages to disk, but a single client of the series server, hosted on the file server, picks them up and sends them to the message server. This provides a significant saving on the load at the message server, since sending the same number of messages through fewer connections is a much lower load on the message server.

In order to implement the filesystem, a configuration client updates the shared filesystem, for example operating at user prompting. It will need to share data from a different part of the DSL and the process to build those unit configurations will need to be created, as a routine extension of the configuration building functionality, for example by sharing the same content/configuration at the same time as updating the server.

By mounting different shared drives for the payment operations, the shared drive can manage different software providing logical control as functionality of the "logon app" which uses the MAC address to determine which drives to mount.

Figure 3 shows an overview of an exemplary networked entertainment device. One entertainment device 30 is shown, connected to a control server 31, a messaging server 32 and a supporting database 33, over network connections 34, 35. It will be understood that many hundreds or thousands of entertainment devices 30 may be connected to the network 34, 35 using any convenient telecommunications network such as the public telephone network, leased private lines or the internet. It will also be understood that the functions of the server 31 and messaging server 32 may be provided by multiple servers, e.g. distributed around a network or provided by a hierarchical network of smaller servers.

Each entertainment device 30 is preferably based on a generic processor running a suitable operating system 40, e.g. Windows XP™ Embedded. Each entertainment device 30 includes a kernel process 31 executable on the operating system for managing content, controlling peripherals and communication on the device 30.

The entertainment device 30 includes a plurality of different content executables 42, each relating to a different entertainment content item. A content item may be any item of pay-to-play content, e.g. a game, a quiz, a music player or music track to be played thereon, a video player or video sequence to be played thereon, as well as any advertisement or display sequence to attract attention to the device, a menu for presentation of options to a user, or any executable causing output or transfer of digital content from the entertainment device as a service to the user. As discussed above, the content executables 42 may be referred to as payload.

The kernel process 41 preferably includes a set of components such as: content interfaces 43 which the content executables 42 use to connect to the kernel process 41; service components 44 for providing functions such as paying in, paying out, cash handling and connectivity; a message hub 45 for distributing event messages created within the device 30, e.g. relating to payments in, payment out, play counts, error messages, alarms etc; and other functional components 46 e.g. a credit handler, as will be explained in greater detail later. One content interface 43 may connect to many different content executables 42, and each content interface 43 may support one or more different types of content executable 42.

Preferably, the operating system 40 and kernel process 41 generally remain unchanging after the installation procedure, although it will be understood that software upgrades could be delivered over the network 32. Hardware peripherals 50 and associated services 60 are preferably pre-installed and remain unchanging, although preferably these are modular items that can be swapped by service visits to the device. Different content items 42 and configuration data are delivered to the devices according to the schedules in the following manner.

With further reference to Figure 3, a content repository 80 is located in server 31 and maintains a structured list of all content items available, including version information if required to ensure that content item compatibility with each entertainment device 30 can be established. The content repository 80 includes content item executables for transfer to entertainment devices 30 or pointers to where to obtain that content elsewhere, if the content items are not already installed on the entertainment devices 30. A data transfer server 81 in server 31 communicates with a corresponding data transfer client 48 in the entertainment device 30 for transfer of content items 42, schedules and configuration files 47. A configuration builder application 82 builds configuration files for transfer to the entertainment devices 30. The configuration data is provided from a suitable configuration database 84 in supporting database server 33. The configuration data in configuration database 84 includes one or more schedules for each group of devices 30 as discussed previously.

One or more management user interfaces or management computers 90 are in communication with a management server 100 over a suitable network connection 36, e.g. the internet. In one embodiment, the management user interface executable 91 resides on the management computer 90 and interacts with the management server 100 via SOAP 102. In another embodiment, access to the management server 100 may be via a web browser 92 installed on the management computer 90 which communicates with a web application 101 to manipulate this data. Management logic 103 in the management server 100 updates the schedules in configuration database 84.

Different management users may implement different schedules within the configuration database 84 via the management server 100 according to individual user privileges. In a simple embodiment, one management user could implement all schedules for all groups of entertainment devices throughout the network. So, for example, the management user establishes a plurality of schedules, each schedule corresponding to a particular domain of operation of entertainment devices as discussed earlier. There may be hundreds of available schedules, each corresponding to a different type of entertainment venue, legislative environment, business environment etc. In general sense, each schedule defines a set of attributes for operation of an entertainment device.

In use, an entertainment device 30¹ is installed in a domain of operation and is given a particular unique identification tag. The management user establishes which schedules are applicable to this device according to its domain of operation and, using the management interface 90, associates that entertainment device with appropriate ones of the available schedules. In practice, each schedule is associated with a group of devices having at least one set of common required or preferred attributes.

Using the data transfer client 48, the installed device 30¹ establishes communication with the data transfer server 81. Using configuration builder 82, server 81 queries the configuration database 64 and acquires the relevant schedules associated with the installed device 30¹. The schedules are then transferred to the entertainment device for use by the installed device 30 to establish its local configuration. Alternatively, and more preferably, the schedules are used to generate required configuration data for the installed device 30 and deliver that configuration data to the device for updating configuration files 47. All the schedules that apply to the installed device are used to determine a subset of attributes that shall prevail in that device. It will be understood that those attributes may include menu items for display to users, content items or "payload" available on the device, and the mode of operation of those content items, as previously discussed.

The kernel process 41 uses the configuration data to retrieve content items 42 either from its own local storage, from remote storage such as content repository 80, or from any other location determined according to the configuration data. The kernel process then displays or otherwise implements a menu selection according to the prevailing attributes as determined by the schedules.

With reference to Figure 4, each entertainment device 30 has a plurality of different peripherals 50 specific to its function. These may include, for example, a display output, an audio and/or video output, a user input console, and payment in and payment out mechanisms such as a single coin hopper 51, a banknote reader

52, a coin acceptor 53, and a card reader 54. Other peripherals may be used to model and control more abstract functions, for example connectivity to the network or the current build of the operating system. Each peripheral 56 implements a certain type of functionality or behaviour. In one aspect, the peripherals 56 comprise all of the non-standard hardware items attached to or integrated into an entertainment device 30. Each peripheral 50 supports a set of functions, e.g. a single coin hopper is a coin hopper which dispenses a single denomination of coin only, and allows for commands like 'Payout 25 coins'. Services are abstractions of the functions which types of peripherals provide: for example, a coin hopper provides the service 'Payout'. In different environments, the same peripheral may provide different services. An example of this would be a card reader. In some environments, it may be possible to use an inserted card to take credit and to give credit to the customer - in these environments, the 'CardReader' peripheral 34 provides 'Payin' and 'Payout' services. In other environments, even using exactly the same card, it may only be used for one of those services. The decision as to which peripheral provides which services depends on the wishes of the operator of the entertainment device and may depend on the regulatory environment in which the device is located. The services provided by a peripheral may be entirely controlled through configuration.

As shown in Figure 4, a peripheral handler 55 controls the set of loaded peripherals and monitors them for health. It will hand peripherals to appropriate services 60, but only as directed by configuration files. Exemplary services include 'Payin' service 61, 'Payout' service 62, 'CashHandling' service 63 and 'Connectivity' service 64. If a peripheral 50 becomes unavailable, the peripheral handler 65 will notify all the services which have previously received it. Each service is able to determine whether it is available at any time, given the current state of the entertainment device and the peripherals which are attached and available.

The configuration of the device 30 with respect to the hardware, firmware and software functionality of the device is stored in a configuration database 47 containing a number of configuration files. These may usefully be divided into: core configuration files 71 relating to the configuration of the kernel process and operating system; location-specific configuration files 72 relating to the location and ownership of the entertainment device 30; and content configuration files 73 relating to the configuration of content items 42. Each content item 42 has a 'content service type' which indicates a set of services which must be available on an entertainment device 30 in order for the content item to function properly. It will be evident that a gambling game with cash prizes will need both Payin and Payout services available in order to function. A motor racing game may require specific user console services but will not require Payout services. A video jukebox content item will require specific video and audio output peripherals.

The configuration database 47 is used by the kernel process to establish exactly what services and functionality are available at any given time on the entertainment device 30 and this is used to determine what content is offered to the user. This means that, even if a particular peripheral should fail within the entertainment device, the device is capable of reconfiguring the menu options available to a user to maintain functionality of the device. The menu can simply offer a reduced choice. When the peripheral service becomes available again, then the menu can be modified back to the full range of content again.

Each entertainment device 30 is adapted to operate in a particular domain of operation, which domain defines both physical and virtual environment constraints as defined earlier. For example, the domain of operation may be a public bar which is (i) run by a local management, (ii) owned by a specific brewery, (iii) in a relationship with certain advertisers, (iv) targeting family clientele during the daytime and adult clientele in the evenings, (v) operating under local authority licensing regulations and (vi) operating under national licensing and gaming laws.

It will be understood that each of these six factors in the domain of operation may influence the way in which the entertainment device is to be operated. Generally speaking, a significant number of such factors determine the allowable or preferred attributes of the entertainment device. The expression 'attributes' is intended to encompass the content items or 'payload' available on a device, and the mode of operation of those content items. The expression 'mode of operation' is intended to encompass rules governing the way in which the content is delivered, restrictions on its input / output parameters and restrictions on the services available to the content.

For example: (i) the pub owner, or brewery may wish to dictate that a certain range of promotional games and offers are available; (ii) the local landlord may recognise that certain games are locally more popular than others and prefer that these are presented with a higher profile; (iii) local management may wish to introduce special offers in conjunction with content delivered by the entertainment device, e.g. an offer to "play game X to win a pint of guest ale"; (iv) a contract between the brewery and another commercial organisation may dictate that predetermined advertising material should appear on the entertainment device display for predetermined periods of time, e.g. when the device is in an idle mode, or even during content item delivery; (v) legislation, regulation or operator preferences may stipulate that certain video or audio jukebox material is not available during the day while families are using the pub; and (vi) gaming laws may dictate certain payout restrictions, possibly at different times of the day.

In prior art systems, it has proved impossible or complex and expensive to configure and reconfigure entertainment devices to meet ever changing requirements for the content offered on the device menu, and the way in which that content executes on the device.

Each entertainment device 30 is assigned to belong to one or more 'groups' of such devices 30. Each group has an associated schedule that defines a set of attributes (e.g. content, mode of operation) for all the devices belonging to that group. Those attributes in the schedule may include desired attributes in an order of preference and may include mandatory attributes to comply with regulations.

It will be recognised from the above description that the invention offers a powerful and effective tool for remotely controlling the content offered, mode of operation of, and other attributes of, a large number of entertainment devices in a network, according to a complex set of fixed and variable requirements, by a large number of management users. Another important aspect of maintaining a network of entertainment devices 30 is the function of event reporting and, more generally, event handling. During operation of an entertainment device 30, numerous different events occur which it may be desirable, essential or legally mandatory to record and / or notify to an appropriate entity. The appropriate entity to which an event should be notified may vary, for example according to: (i) the type of event; (ii) the owner, operator or administrator of the machine or of certain functions of the machine (e.g. cash handling, maintenance, etc), (iii) the physical or geographical location of the device, etc. More generally, the domain of operation may also determine the manner in which event messages should be handled.

Events that should be recorded may include any significant interaction with a user. The user in this context may be a customer, manager, installation engineer, service engineer, cash collection agent etc. The events to be recorded may include identity of games played, payloads executed, the times and amounts of payout events and payin events, cash floats maintained, errors reported by software and / or hardware relating to peripherals and / or content, changes in menus, payloads etc, and completed status of downloads. Events that generate messages generally include changes in the virtual or physical condition of the entertainment device.

More generally, the event recordal process ideally should enable the precise current and / or historic configuration of a device to be confirmed at any given time.

For entertainment devices handling cash, it is desirable that the state of the bank within the machine is known at any given time. For credit-based machines, it is desirable that credit transactions are passed to the relevant credit handling entity at reasonable intervals, and that credit authorisation requests are handled immediately. For juke box type machines, it is desirable that the number of times an audio or video content item is played is accurately and verifiably recorded for the purposes of copyright royalty payments and the like. For routine and critical error events, it is desirable that service personnel are notified in a timely manner according to the criticality of the error.

With further reference to Figures 3 and 4, various elements in the entertainment device are capable of initiating event messages that indicate an activity, status or outcome in the entertainment device. For example, the kernel process 41 may initiate event messages relating to the running of certain payloads or content executables 42, or to the updating of configuration files 71, 72, 73 in the configuration database 47. The peripherals 50 or peripheral handler 55 may initiate event messages relating to payin and payout events, hardware status, faults etc. The entertainment device 30 may also have hardwired and / or software detection systems (not shown) triggered by physical events such as an attack on a machine, or an authorised opening of a cash box to remove or replenish cash. The data transfer client 48 may also initiate event messages relating to opening and closing of network connections to the control server 31 and messaging server 32, and logging downloads / updates from the control server 31. The kernel process 41 may also initiate event messages relating to different users logging into the entertainment device, e.g. management or service users accessing special menus or service options on the device 30. More generally, the event messages may represent any physical and / or virtual event that occurs in the entertainment device 30.

Each event message initiated is sent to the message hub 45 (Figure 3). As shown in more detail in Figure 4, message hub 45 includes a messaging module 75. In one implementation, the messaging module 75 includes a messaging component 76 which simply writes a local log file (e.g. in the entertainment device 30) for subsequent debug. The messaging module 75 is also adapted to prepare and transmit event messages to an external entity, such as a data centre. In this respect, the messaging module 75 includes a transmit module 77 which transmits event messages to the remote messaging server 32 over network connection 35. The transmit module 77 includes a message queue 78 to be described later. Message preparation may include packaging the messages into a standard format and include such generic functions as attaching a source address field and a destination address field. Each event message includes an event type (such as 'cash transaction', 'game play', 'bank status' etc. The event types may be arranged in a hierarchical manner to help organise them. Each event message may include a number of information fields giving one or more event value, e.g. a numeric, text or logical state to the event. If the events are arranged hierarchically, any event may have all the attributes of its parent event. Each message is allocated a priority level, which might be explicitly indicated in a priority field of the message, or might be inferred from the event type and / or event value.

In a simple embodiment, only two priority levels might be used. A first priority level indicates that the event message is time critical and should be sent to the message server 32 at the soonest opportunity, e.g. immediately that a network connection 35 becomes available. If a network connection is not presently available, then a first priority level message would indicate that a connection should be established. A second priority level indicates that the message is not time critical (or is less time critical) and need not be sent immediately. Generally, the first priority level event message is referred to herein as having an 'immediate- send' or 'send now' status, while the second priority level event message is referred to herein as having a 'non-immediate-send' or 'send later' status.

An important consideration in maintaining a large number of networked entertainment devices 30 is that of communication bandwidth. To maintain permanently open or available communication channels between devices 30 and messaging server(s) 32 may be prohibitively expensive. The messaging module 75 therefore preferably uses the message queue 78 to store event messages that have 'non-immediate-send' status. Various triggers may be used to determine when to send queued messages to the messaging server 32. For example, all queued messages, or as many as will fit into a standard transmission packet or chain of messages, may be transmitted periodically. This periodic transmission may be any suitable type, such as (i) as soon as the queue reaches a predetermined length; (ii) as soon as the oldest message in the queue has reached a predetermined age; (iii) as soon as any message in the queue has reached a critical age; or (iv) fixed time, such as every hour, or any combination thereof. Alternatively, or in addition, queued messages may be transmitted whenever an 'immediate-send' message arrives, forcing a transmission to the messaging server.

Such an event message sending strategy optimises use of the communications network while maintaining real time transfer of critical data.

It will be understood that more priority levels may be used in the 'non-immediate- send' status category. For example, event messages may be given a maximum delay period for transmission to the messaging server. This feature is useful if it must be guaranteed that certain types of status data on the entertainment devices is never more than a predetermined period out of date. It will be understood that messages of the 'immediate send' status are sent as soon as possible, i.e. as soon as a communication channel to the messaging server 32 is available. Preferably, this would be practically immediate, but otherwise is intended to mean as soon as a communication channel becomes available.

The message log 76 may be used in a number of different possible ways. For example, it may maintain a permanent or semi-permanent record of event messages or their headers, or may delete event messages after a predetermined time or in response to a user instruction. The message log may store event messages only until receipt has been confirmed by the message server 32. In another arrangement, the queue 58 may reside in the message log, e.g. by flagging unsent messages.

A feature of one preferred embodiment is that the entertainment devices 30 do not need any substantive message routing intelligence. The messaging module 75 is preferably required only to prepare and transmit messages to a message server 32 without knowledge of the ultimate intended recipient(s) of, or subscriber(s) to, the messages. In a preferred embodiment, the messaging server 32 is a message oriented middleware product, such as the IBM MQ series. Each entertainment device 30 may be regarded as a publisher of event messages. Each event message will have one or more subscribers authorised as recipient of the information in the event message. A function of the messaging server 32 is to distribute information from the event messages to relevant authorised subscribers or 'subscriber entities'. A subscriber entity is depicted in Figure 3 as a subscriber server 36, which may be any suitable communication device capable of receiving data from the messaging server 32. It will be understood that a large number of subscriber servers may be connected or connectable to the messaging server 32.

Each operator or owner of entertainment devices 30 may be a subscriber to the data from all event messages originating from its respective entertainment devices. A device servicing organisation may be a subscriber to the data from all event messages relating to operational condition of hardware from entertainment devices for which it is responsible. A cash handling or credit handling organisation may be a subscriber to the data from all event messages relating to cash or credit transactions. A regulatory authority or other control body may be a subscriber to data from event messages which can be used to confirm compliance with rules governing use of the entertainment devices such as gambling regulations, amusements-with-prizes regulations, copyright control and royalty collection etc.

In a general aspect, the messaging server 32 is responsible for forwarding all event messages to the correct subscribers according to a classification of a message and / or according to an attribute of the message. The expression 'message classification' is intended to encompass a message source identity (e.g. the identity of the device 10 which originated the event message), a source location or domain of operation, a source group or schedule defining device attributes of such a group as previously defined. The expression 'message attribute' is intended to encompass event types and event values as previously discussed and may also include time and / or date of origin of the message as well as other content of the message. Thus, a subscriber may elect to receive only error messages from entertainment devices for which it is responsible, and the error status may be determined by either the event type being an error type, or the event value indicating an error, e.g. out of range. Preferably, the message server 12 maintains a profile in respect of each subscriber, which profile determines the messages forwarded to that subscriber.

Message classifications and attributes may be determined according to a hierarchical or tree structure of event messages in which child nodes inherit properties of a parent node. Subscribers may subscribe to certain branches of the message hierarchy, e.g. a node and all children of that node.

The forwarding of messages may take place in several possible ways. In a first arrangement, the messaging server 32 acts a 'post office' forwarding entire messages or selected message contents to intended subscribers. Destinations of the messages are determined by a subscription basis of the individual subscribers, i.e. determining which messages a subscriber is authorized to receive. A subscriber server 16 is then used to receive and store event message data as required. Thus, each subscriber receives a subset of the messages received by the messaging server

32.

In a second arrangement, the messaging server 32 may act as a repository for event messages from many devices 30. Individual subscribers 36 may then access event messages to which they are authorized subscribers (i.e. a subset of the received event messages or data) on demand from the messaging server. In this aspect, the forwarding of event messages is 'on demand'. The expression 'event messages' is intended to cover the messages themselves or just the event information or data contained therein.

It will be recognised that a significant advantage in the arrangements of the messaging server as described above is that changes in subscribers to the messaging server can take place without any change in the software or other functionality of the individual entertainment devices. The expression 'changes in subscribers' is intended to encompass changes in the subscription basis of one or more subscriber entities, changes in the subscription profile of one or more subscriber entities and / or changes in the subscriber entities themselves including deletion or addition of subscriber entities. The forwarding of event messages by the messaging server 32 to a subscriber server may operate on a similar basis to that which applies between the messaging module 75 and the messaging server 32, e.g. according to message priority levels corresponding to 'immediate send' status and 'non-immediate-send' status. The communication channel 37 between the messaging server 32 and subscriber servers 36 may be continuous or intermittent. The messaging server 32 preferably offers guaranteed delivery of messages, even where there is intermittent connectivity between the messaging server and the subscriber servers 36 and thus behaves as a persistent message server.

Although the principal recipient of event messages is the message server 32, the event messages generated by the messaging module 75 may be received or captured elsewhere. For example, a local network (e.g. within a pub or arcade) may have a local management computer system adapted to also receive some or all event messages from an entertainment device using a wired or wireless LAN. Such a local management computer system could include a venue cash management database for local cash flow control. In this aspect, the messaging module may be configured to multicast messages to two or more separate destination addresses. These messages may be in different formats and using different transport protocols. To implement this, the messaging module 55 may include more than one transmit module 57. Still further, the entertainment device 30 itself may monitor event messages and, if there is a predetermined period of inactivity in respect of certain types of event messages, may use this as a trigger to load a different content executable - e.g. a video sequence or different menu likely to attract more attention.

A significant advantage of the use of a message server is that requirements for use of the event messages may be expected to vary more rapidly than changes in the operation of the entertainment devices themselves. Altering software on the entertainment devices to change the rules governing generation, use and destination of event messages is problematic and high risk owing to the number of software modules that would have to be updated. Changing functionality at the message server is a simpler and more controllable task.

Another important aspect of configuring and maintaining entertainment devices is to ensure the correct operation of credit handling facilities on the entertainment device. Different types of payment mechanism offer very different mechanical and electronic functionality, and may also be used to implement very different methods of credit handling.

For example, a coin acceptor mechanism in conjunction with a coin hopper provides electromechanical functionality for receiving and verifying coins and paying out coins of specific denomination, provided that the coin bank has sufficient credit. A card reader may have mechanical and electronic functionality for reading a card type, reading available credit from the card, debiting an amount from that card, and crediting an amount to that card.

The credit handling facilities must not only be configured correctly for the type of payment mechanism available, but must also implement transaction processing logic that ensures that payment transactions are handled in accordance with the domain of operation of the entertainment device. For example, this may require maintenance of one or more credit banks. In a typical entertainment device environment, separate banks may be maintained for credit paid in, credit from promotions and credit from winnings. The transaction processing logic may also be dictated by local regulations. For example, in certain UK gaming rules, cash winnings from a betting game may not be used to stake on a game without an explicit transfer of funds from the 'winnings' bank to the 'credit' bank. Similarly, it may be required that accrued winnings on the entertainment device may not exceed a predetermined level without physically paying out those winnings. Other constraints may be required by the operator of the entertainment device, e.g. that credit from promotions must be used before credit from monies paid in, or vice versa or that credit from promotions may not be used for paying out, only for game play. The implementation facilitates the separation or segregation of generic payment instruction messages as may be issued or received by an entertainment content handler (e.g. content executable 42 running through content interface 43 on kernel process 41) from specific payment functionality. This allows a content executable 42 to use a generic set of payment instruction commands regardless of the domain of operation of the entertainment device. It will be recalled that the domain of operation may refer to both physical attributes of the entertainment device such as its peripheral payment mechanisms, as well as virtual attributes such as the legislative and business environment.

The entertainment device 30 is provided with a credit handler module 46 that enables the content executable 42 running through content interface 43 on kernel process 41, to interface with payment mechanisms 50 via a common set of generic payment instruction messages.

The credit handler may determine the mode of use of the payment mechanism. For example, where the payment mechanism is a smart card reader, the value of cash held is written to the actual card which is inserted into a special peripheral. AU credit in and credit out instructions result in writes to the card data directly. The card can be removed at any time and taken to another device to add more credit, or to redeem winnings.

Other embodiments are intentionally within the scope of the accompanying claims.

Claims

1. A method of initialising operation of one generic entertainment device in a network of generic entertainment devices, each of the devices having an attached payment mechanism, the method comprising: sending an identification signal representing said one generic entertainment device, for initialisation in the network, to a central configuration server of the network; then the central configuration server sending configuration data for the said generic entertainment device to said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network.

2. An initialising method according to Claim 1 wherein the identification signal originates from the device.

3. An initialising method according to Claim 2 wherein the identification signal originates from the device after boot-up and production of a custom shell at the device.

4. An initialising method according to any preceding claim wherein the identification signal comprises the MAC address for the device.

5. An initialising method according to any preceding claim wherein the central configuration server sends to the device only configuration data for creation of entertainment content at the device.

6. An initialising method according to any preceding claim wherein, after receiving the configuration data, the device creates logical control at the device.

7. An initialising method according to any preceding claim wherein the device creates entertainment content comprising graphics content operable at the device.

8. An initialising method according to any preceding claim wherein the device creates entertainment content comprising graphics content and most or all of the entertainment content operable at the device.

9. An initialising method according to any preceding claim wherein the device creates entertainment content graphics contents, most or all the entertainment content used at the device, and peripherals applications for the device.

10. An initialising method according to any preceding claim wherein the device comprises one or more of the following: a gambling unit, a gaming unit, a quiz unit, and arcade unit, a jukebox unit.

11. A network of generic entertainment devices having attached payment mechanisms, a central configuration server of the network having means to receive an identification signals representing individual generic entertainment devices for initialisation of that device in the network; the central configuration server being operable to send configuration data for a generic entertainment device to said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network.

12. A network of generic entertainment devices according to Claim 11 wherein the identification signal originates from the device.

13. A network of generic entertainment devices according to Claim 12 wherein the identification signal originates from the device after boot-up and production of a custom shell at the device.

14. A network of generic entertainment devices according to any of Claims 11 to 12 wherein the identification signal comprises the MAC address for the device.

15. A network of generic entertainment devices according to any of Claims 1 1 to 14 wherein the central configuration server is operable to send to the device only configuration data for creation of entertainment content at the device.

16. A network of generic devices to any of Claims to 10 to 15 wherein, after receiving the configuration data, the device is operable to create logical control at the device.

17. A network of generic entertainment devices according to any of Claims 11 to 16 wherein the device is operable to create entertainment content comprising graphics content operable at the device.

18. A network of generic entertainment devices according to any of Claims 11 to 17 wherein the device is operable to create entertainment content comprising graphics content and most or all of the entertainment content operable at the device.

19. A network of generic entertainment devices according to any of Claims 11 to 18 wherein the device is operable to create entertainment content graphics contents, most or all the entertainment content used at the device and peripherals applications for the device.

20. A network of generic entertainment devices according to any of Claims 11 to 19 wherein the device comprises one or more of the following: a gambling unit, a gaming unit, a quiz unit, and arcade unit, a jukebox unit.

21. A generic entertainment device having an attached payment mechanism and for operation in a network of generic entertainment devices having attached payment mechanisms, the device having means to send an identification signal representing said one generic entertainment device, for initialisation in the network, to a central configuration server of the network, and means to receive, from the central configuration server, configuration data for the said generic entertainment device thereby to manage entertainment content on said generic entertainment device specific to that location in the network.

22. A generic entertainment device according to Claim 21 wherein the identification signal originates from the device after boot-up and production of a custom shell at the device.

23. A generic entertainment device according to Claim 21 or 22 wherein the identification signal comprises the MAC address for the device.

24. A generic entertainment device according to any of Claims 21 to 23 wherein the device is operable to receive only configuration data for creation of entertainment content at the device.

25. A generic entertainment device according to any of Claims 21 to 24 wherein, after receiving the configuration data, the device is operable to create an software providing logical control at the device.

26. A generic entertainment device according to any of Claims 21 to 25 wherein the device is operable to create entertainment content comprising graphics content, for use at the device.

27. A generic entertainment device according to any of Claims 21 to 26 wherein the device is operable to create entertainment content comprising graphics content and most or all of the entertainment content for use at the device.

28. A generic entertainment device according to any of Claims 21 to 27 wherein the device creates entertainment content graphics contents, most or all the entertainment content for use at the device, and peripherals applications for the device.

29. A generic entertainment device according to any of Claims 21 to 28 wherein the device comprises one or more of the following: a gambling unit, a gaming unit, a quiz unit, and arcade unit, a jukebox unit.