AU2011205032B2 - Gaming system and gaming system processor module - Google Patents

Abstract

Abstract: A gaming system and processor module therefore adapted to support simultaneous execution of two or more operating system instances. Program code for play of the game uses two or more cooperating component processes partitioned such that at least one of the component processes executes using a first operating system instance, and at least one other cooperating component process executes using a further operating system instance. Each operating system instance may execute in its own virtual machine. 2750803_1 (GHMatte) P783%.AU.2 27/07111 770 780 782 784 Network Device Device Device interface Driver A Driver B Driver C 730 1st Virtual Machine 2nd Virtual Machine 740 (Domain 0) (Domain U) 750 760 15t game processes 2nd game processes Hypervisor/Virtual Machine Monitor Hardware CPU-b ...... CPU-n Memory 2 712ab 712n 714 Figure 7 P78365A1J2 20559371 (GHMIaers) 27/07111

Description

AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION Standard Patent Applicant: Aristocrat Technologies Australia Pty Limited Invention Title: GAMING SYSTEM AND GAMING SYSTEM PROCESSOR MODULE The following statement is a full description of this invention, including the best method for performing it known to me/us: 27567331 (GHMatters) P78365.AU.2 -2 GAMING SYSTEM AND GAMING SYSTEM PROCESSOR MODULE Related Application 5 The present invention is a divisional application of Australian patent application 2009222627, the disclosure of which is incorporated herein by reference. Field 10 The present invention relates to gaming systems and processor modules therefore. Background 15 Electronic gaming machines and gaming systems incorporating one or more electronic gaming machines are known. Such gaming machines and systems are used to provide games, playable by users for their enjoyment. 20 While such gaming systems provide users with enjoyment, a need exists for alternative gaming systems. Summary of the Invention 25 According to a first aspect, there is provided a gaming system processor module adapted to support simultaneous execution of two or more operating system instances to thereby enable execution of program code which enables play of a game, whereby 30 execution of the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and second of the cooperating component processes executes using a further operating system instance, 35 each operating system instance at least having direct access to system memory such that data elements generated by the first of 27508032 (GHMatters) P78365.AU.2 30/10/13 -3 the cooperating component processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance. 5 The gaming system processor module can have a virtual machine monitor to support the simultaneous execution of two or more operating system instances, wherein each operating system instance executes in its own virtual machine. The processor module may comprise one or more physical processors. Each 10 processor can have one or more processing cores. In some embodiments each operating system instance can be selectively provided with direct access to one or more hardware resources. Any hardware resource access provided to an 15 operating system instance can be exclusive to the operating system instance. In an embodiment a first operating system instance acts as a host operating system and each further operating system instance 20 acts as a guest operating system, and wherein access to hardware resources is allocated selectively to guest operating system instances under control of the host operating system. The host operating system instance can be adapted to monitor the 25 guest operating system instances and selectively restart a guest operating system instance, if necessary, when an execution error is detected in the guest operating system instance. In one embodiment, component processes related to game play 30 execute in a first operating system instance and component processes related to game presentation execute in a second guest operating system instance. In some embodiments the first and second operating system 35 instances each execute a different type of operating system. For example, the first operating system type can be a LINUX 27508032 (GHMatters) P78365.AU.2 30/10/13 -4 operating system or variant thereof. The second guest operating system can be a Microsoft Windows operating system. Alternatively each operating system instance can execute the 5 same type of operating system. In an embodiment component processes executed using the second guest operating system include game graphics component processes. In this embodiment the second guest operating system 10 may be provided access to game system hardware resources for displaying game graphics. According to a second aspect, there is provided a gaming system comprising: 15 a player interface arranged to enable a player to enter instructions to play a game and including one or more displays to display game results; and a game controller in data communication with the player interface, the game controller comprising: 20 a memory; and an electronic processing arrangement adapted to support simultaneous execution of two or more operating system instances to thereby enable execution of program code which enables play of a 25 game, whereby execution of the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and a second of the cooperating component 30 process executes using a further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component processes in the first operating system 35 instance are accessible by the second of the cooperating component processes in the further 2750803_2 (GHMatters) P78365.AU.2 30110113 -5 operating system instance. According to a third aspect, there is provided a game controller comprising: 5 a memory; and an electronic processing arrangement adapted to support simultaneous execution of two or more operating system instances to thereby enable execution of program code which enables play of a game, whereby execution of the program code 10 uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and a second of the cooperating component processes executes using a further operating system instance, each operating system instance at 15 least having direct access to system memory such that data elements generated by the first of the cooperating component processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance. 20 According to a fourth aspect, there is provided a computer readable storage medium comprising computer readable instructions which when executed by a processor of a game system adapt the processor to support simultaneous execution of two or 25 more operating system instances, to thereby enable execution of program code which enables play of a game, and execution of a the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system 30 instance, and a second of the cooperating component processes executes using a further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component processes in the first operating 35 system instance are accessible by the second of the cooperating component processes in the further operating system instance. 27508032 (GHMatters) P78365.AU.2 30/10/13 -6 According to a fifth aspect, there is provided a method of gaming comprising the steps of: providing program code which enables play of a game, 5 wherein execution of the program code uses two or more cooperating component processes; executing a first of the cooperating component processes using a first operating system instance; and executing a second of the cooperating component 10 processes using a further operating system instance, wherein the execution of the component processes in the first and further operating systems cooperates to implement the game, each operating system instance at least having direct access to system memory such that data elements generated by the first of 15 the cooperating component processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance. The method can further comprise the step of selectively 20 providing direct hardware access to each operating system instance. In an embodiment the component processes executed in the first operating system are component processes for implementing game 25 play and component processes executed the further operating system instance are component processes for game presentation. Brief Description of Drawings 30 An exemplary embodiment of the invention will now be described with reference to the accompanying drawings in which: Figure 1 is a block diagram of the core components of a gaming system; 35 Figure 2 is a perspective view of a stand alone gaming 2750803_2 (GHMatters) P78365.AU.2 30/10/13 -7 machine; Figure 3 is a block diagram of the functional components of a gaming machine; 5 Figure 4 is a schematic diagram of the functional components of a memory; Figure 5 is a schematic diagram of a network gaming system; 10 Figure 6 is a further block diagram of a gaming system; Figure 7 is a block diagram representative of an exemplary architecture for a gaming processor; 15 Figure 8 is a further block diagram of a gaming system. Detailed Description 20 Referring to the drawings, there is shown a gaming system having a game controller with an electronic processing arrangement adapted to support simultaneous execution of two or more operating system instances. The game controller is arranged to implement a game using to or more 25 component software processes wherein at least one component process is executes using a first operating system instance and at least one other component process executed using a further operating system instance. 30 The gaming system can take a number of different forms. In a first form, a stand alone gaming machine is provided wherein all or most components required for implementing the game are present in a player operable gaming machine. 2750803_1 (GHMattm) P7830.ALU2 27/07/11 - 8 In a second form, a distributed architecture is provided wherein some of the components required for implementing the game are present in a player operable gaming machine and some of the components required for implementing the 5 game are located remotely relative to the gaming machine. For example, a "thick client" architecture may be used wherein part of the game is executed on a player operable gaming machine and part of the game is executed remotely, such as by a gaming server; or a "thin client" architecture 10 may be used wherein most of the game is executed remotely such as by a gaming server and a player operable gaming machine is used only to display audible and/or visible gaming information to the player and receive gaming inputs from the player. 15 However, it will be understood that other arrangements are envisaged. For example, an architecture may be provided wherein a gaming machine is networked to a gaming server and the respective functions of the gaming machine and the 20 gaming server are selectively modifiable. For example, the gaming system may operate in stand alone gaming machine mode, "thick client" mode or "thin client" mode depending on the game being played, operating conditions, and so on. Other variations will be apparent to persons skilled in the 25 art. Irrespective of the form, the gaming system comprises several core components. At the broadest level, the core components are a player interface 50 and a game controller 30 60 as illustrated in Figure 1. The player interface is arranged to enable manual interaction between a player and the gaming system and for this purpose includes the input/output components required for the player to enter instructions and play the game and observe the game 2750803_1 (GHMatter) P78305.AUJ.2 27/07/11 -9 outcomes. Components of the player interface may vary from embodiment to embodiment but will typically include a credit mechanism 5 52 to enable a player to input credits and receive payouts, one or more displays 54, a game play mechanism 56 including one or more input devices that enable a player to input game play instructions (e.g. to place betas wager), and one or more speakers 58. 10 The game controller 60 is in data communication with the player interface and typically includes a processor 62 that processes the game play instructions in accordance with game play rules and outputs game play outcomes to the 15 display. Typically, the game play instructions are stored as program code in a memory 64 but can also be hardwired. Herein the term "processor" is used to refer generically to any device that can process game play instructions in accordance with game play rules and may include: a 20 microprocessor, microcontroller, programmable logic device or other computational device, a general purpose computer (e.g. a PC) or a server. A gaming system in the form of a stand alone gaming machine 25 202 is illustrated in Figure 2. The gaming machine 202 includes a console 12 having a display 14 on which are displayed representations of a game 16 that can be played by a player. A mid-trim 20 of the gaming machine 202 houses a bank of buttons 22 for enabling a player to 30 interact with the gaming machine, in particular during game play. The mid-trim 20 also houses a credit input mechanism 24 which in this example includes a coin input chute 24A and a bill collector 24B. Other credit input mechanisms may also be employed, for example, a card reader for 2750803_1 (GHMattes) P7830 AU.2 27/07/11 - 10 reading a smart card, debit card or credit card. Other gaming machines may configure for ticket in such that they have a ticket reader for reading tickets having a value and crediting the player based on the face value of the ticket. 5 A player marketing module (not shown) having a reading device may also be provided for the purpose of reading a player tracking device, for example as part of a loyalty program. The player tracking device may be in the form of a card, flash drive or any other portable storage medium 10 capable of being read by the reading device. In some embodiments, the player marketing module may provide an additional credit mechanism, either by transferring credits to the gaming machine from credits stored on the player tracking device or by transferring credits from a player 15 account in data communication with the player marketing module. A top box 26 may carry artwork 28, including for example pay tables and details of bonus awards and other 20 information or images relating to the game. Further artwork and/or information may be provided on a front panel 29 of the console 12. A coin tray 30 is mounted beneath the front panel 29 for dispensing cash payouts from the gaming machine 202. 25 The display 14 shown in Figure 2 is in the form of a video display unit, particularly a cathode ray tube screen device. Alternatively, the display 14 may be a liquid crystal display, plasma screen, any other suitable video 30 display unit, or the visible portion of an electromechanical device. The top box 26 may also include a display, for example a video display unit, which may be of the same type as the display 14, or of a different type. 2750803_1 (GHM.t1 )P78385AIJ.2 27107111 - 11 Figure 3 shows a block diagram of operative components of a typical gaming machine which may be the same as or different to the gaming machine of Figure 2. 5 The gaming machine 100 includes a game controller 101 having a processor 102. Instructions and data to control operation of the processor 102 are stored in a memory 103, which is in data communication with the processor 102. Typically, the gaming machine 100 will include both 10 volatile and non-volatile memory and more than one of each type of memory, with such memories being collectively represented by the memory 103. The gaming machine has hardware meters 104 for purposes 15 including ensuring regulatory compliance and monitoring player credit, an input/output (I/O) interface 105 for communicating with peripheral devices of the gaming machine 100. The input/output interface 105 and/or the peripheral devices may be intelligent devices with their own memory 20 for storing associated instructions and data for use with the input/output interface or the peripheral devices. A random number generator module 113 generates random numbers for use by the processor 102. Persons skilled in the art will appreciate that the reference to random numbers 25 includes pseudo-random numbers. In the example shown in Figure 3, a player interface 120 includes peripheral devices that communicate with the game controller 101 comprise one or more displays 106, a touch 30 screen and/or buttons 107, speakers or audio output (not shown), a card and/or ticket reader 108, a printer 109, a bill acceptor and/or coin input mechanism 110 and a coin output mechanism 111. Additional hardware may be included as part of the gaming machine 100, or hardware may be 2750803_1 (GHMattr) P7830AU.2 27/07/11 - 12 omitted as required for the specific implementation. For example, while buttons or touch screens are typically used in gaming machines to allow a player to place a wager and initiate a play of a game any input device that enables the 5 player to input game play instructions may be used. For example, in some gaming machines a mechanical handle is used to initiate a play of the game. In addition, the gaming machine 100 may include a 10 communications interface, for example a network card 112. The network card may, for example, send status information, accounting information or other information to a central controller, server or database and receive data or commands from the central controller, server or database. In 15 embodiments employing a player marketing module, communications over a network may be via player marketing module - i.e. the player marketing module may be in data communication with one or more of the above devices and communicate with it on behalf of the gaming machine. 20 Figure 4 shows a block diagram of the main components of an exemplary memory 103. The memory 103 includes RAM 103A, EPROM 103B and a mass storage device 103C. The RAM 103A typically temporarily holds program files for execution by 25 the processor 102 and related data. The EPROM 103B may be a boot ROM device and/or may contain some system or game related code. The mass storage device 103C is typically used to store game programs, the integrity of which may be verified and/or authenticated by the processor 102 using 30 protected code from the EPROM 103B or elsewhere. It is also possible for the operative components of the gaming machine 100 to be distributed, for example input/output devices 106,107,108,109,110,111 to be provided 2750803_1 (GHMatters) P7838iAJJ2 27/07/11 - 13 remotely from the game controller 101. Figure 5 shows a gaming system 200 in accordance with an alternative embodiment. The gaming system 200 includes a 5 network 201, which for example may be an Ethernet network. Gaming machines 202, shown arranged in three banks 203 of two gaming machines 202 in Figure 5, are connected to the network 201. The gaming machines 202 provide a player operable interface and may be the same as the gaming 10 machines 10,100 shown in Figures 2 and 3, or may have simplified functionality depending on the requirements for implementing game play. While banks 203 of two gaming machines are illustrated in Figure 5, banks of one, three or more gaming machines are also envisaged. 15 One or more displays 204 may also be connected to the network 201. For example, the displays 204 may be associated with one or more banks 203 of gaming machines. The displays 204 may be used to display representations 20 associated with game play on the gaming machines 202, and/or used to display other representations, for example promotional or informational material. In a thick client embodiment, game server 205 implements 25 part of the game played by a player using a gaming machine 202 and the gaming machine 202 implements part of the game. With this embodiment, as both the game server and the gaming device implement part of the game, they collectively provide a game controller. A database management server 206 30 may manage storage of game programs and associated data for downloading or access by the gaming devices 202 in a database 206A. Typically, if the gaming system enables players to participate in a Jackpot game, a Jackpot server 207 will be provided to perform accounting functions for 2750803.1 (GHMatter) P783e5 AL.2 27/07/11 - 14 the Jackpot game. A loyalty program server 212 may also be provided. In a thin client embodiment, game server 205 implements 5 most or all of the game played by a player using a gaming machine 202 and the gaming machine 202 essentially provides only the player interface. With this embodiment, the game server 205 provides the game controller. The gaming machine will receive player instructions, pass these to the game 10 server which will process them and return game play outcomes to the gaming machine for display. In a thin client embodiment, the gaming machines could be computer terminals, e.g. PCs running software that provides a player interface operable using standard computer input and output 15 components. Other client/server configurations are possible, and further details of a client/server architecture can be found in WO 2006/052213 and PCT/SE2006/000559, the disclosures of which are incorporated herein by reference. 20 Servers are also typically provided to assist in the administration of the gaming network 200, including for example a gaming floor management server 208, and a licensing server 209 to monitor the use of licenses 25 relating to particular games. An administrator terminal 210 is provided to allow an administrator to run the network 201 and the devices connected to the network. The gaming system 200 may communicate with other gaming 30 systems, other local networks, for example a corporate network, and/or a wide area network such as the Internet, for example through a firewall 211. Persons skilled in the art will appreciate that in 2750803.1 (GHMaOes) P7835 AU 2 270711 - 15 accordance with known techniques, functionality at the server side of the network may be distributed over a plurality of different computers. For example, elements may be run as a single "engine" on one server or a separate 5 server may be provided. For example, the game server 205 could run a random generator engine. Alternatively, a separate random number generator server could be provided. Further, persons skilled in the art will appreciate that a plurality of game servers could be provided to run 10 different games or a single game server may run a plurality of different games as required by the terminals. Embodiments of the gaming system described in detail herein use an electronic processing arrangement adapted to support 15 simultaneous execution of two or more operating system instances. Games can be implemented in this system using two or more cooperating component processes such that at least one component process executes using a first operating system instance and one or more other component 20 processes execute using a further operating system instance. Thus, game execution is partitioned such that cooperating component processes execute using different operating system instances. 25 Each of the operating system instances may be a different operating system type. For example the first operating system may be a LINUX operating system and a second operating system may be a Microsoft Windows* operating system. Each operating system instance may be selectively 30 provided direct access to one or more hardware resources. Other operating system types may also be used. An example of an embodiment of a stand alone game machine having a processor adapted to support two or more operating 2750803_1 (GHMatte) P78385AIJ.2 27107/11 - 16 systems simultaneously is illustrated in Figure 6. The game machine 600 comprises a game controller 660 and a player interface 650. The player interface 650 includes a credit mechanism 652, displays 654, a game play mechanism 5 656 and speakers 658. The controller 660 includes a processor 662 and memory 664. In this embodiment the memory 664 stores game data including software programs for two or more component 10 processes 640, 645 which, when executed, implement the game. The processor 662 is adapted to support two or more operating system instances. The processor 662 can be a processor module, such as a central processor unit (CPU) having one or more physical processors, or an electronic 15 processing arrangement comprising one or more physical processors. The electronic processing arrangement may be centralised in one processor module. Alternatively the electronic processing arrangement may be distributed, for example where two or more CPUs are connected in a multi 20 processor environment. The processors may be single or multi-core processors. In the example illustrated the processor 662 is running two operating system instances 666, 668. A first component 25 process executes 640' in the first operating system 666 and a second component process executes 645' in the second operating system 668. Using two or more operating system instances enables different processes to execute independently of one another. In the embodiment 30 illustrated in Figure 6, access to hardware resources can be selectively allocated to different operating systems. In this example, the first operating system 666 is used for executing game play processes 640' and is therefore allocated access to hardware resources for the credit 27508031 (GHkatter)P78385AU.2 27/07/11 - 17 mechanism 652 and game play mechanism 656 of the player interface 650. The second operating system 668 is used for executing component processes for game presentation 645' and is therefore allocated access to hardware resources for 5 the displays 654 and speakers 658 of the player interface 650. As illustrated the execution of game processes and hardware access is separated into two partitions 630, 635 with the 10 first partition 630 being for game play and the second partition 635 being for game presentation. Allocation of hardware resources separately to each partition is optional. In an alternative embodiment only one operating system instance is provided direct access to hardware 15 resources. Partitioning of game component process execution using different operating system instances can exhibit a number of advantages. For example, in some embodiments 20 partitioning can enhance security by separating player account and credit handling from other game processes. For example, resistance to hacking of player accounts may be increased by quarantining player account and credit handling from processing of inputs from the player 25 interface other than the credit mechanism. In some embodiments one operating system instance can be used for providing the game machine platform and another one or more operating systems used for execution of the game per se, for example the platform operating system instance may 30 handle all I/O and mathematical functions and the one or more operating system instances for implementing the game handle execution of the game play process and presentation. This can minimise risk of interference or timing delay for the mathematical functions due to processing of other 2750803_1 (GHMaesM) P7830 AU2 27/07111 - 18 aspects of game play or presentation, such as playing animated graphics. Interference or security risks can be even further mitigated in embodiments where access to hardware resources can be selectively allocated to 5 different operating system instances. In some embodiments the two or more component processes can be adapted to execute in different operating system types or versions. This can be advantageous for portability or 10 compatibility of games between different machines. Further, partitioning games into cooperating component processes adapted to execute in different operating systems enables a game to be designed and implements in a modular fashion. This has the advantage of enabling component 15 processes to be selectively modified or upgraded, for example for compatibility with different hardware or selectively upgrading different elements of the game such as the game graphics. 20 Producing a game in this modular fashion may also be advantageous for obtaining regulatory approval of games initially and in the case of upgrades. For example, game play component processes which deal with credit handling, game outcome generation, random number generation, player 25 tracking etc could be adapted to execute using one operating system instance. The component processes for game presentation, such as graphics and sound can be adapted to execute in another operating system instance. Game data, such as game outcome data, can be provided to 30 the game presentation component processes of one operating system instance by game execution component processes of the other operating system instance. This data can be passed between the two operating system instances using a data transfer protocol or signal. However, the game 2750803_1 (GHMattes) P78365. AU12 27/07/11 - 19 presentation component process cannot influence game play due to the operating system separation. Thus, the requirement for regulatory approval of the game presentation component processes may be different and less 5 strict than the regulatory approval requirements for the game play processes. For example, this can have significant advantages where the same game play process is used for two or more types of game machines which each have different game presentation capabilities, for example 10 different displays and different graphics processing abilities. The game play process may be granted regulatory approval and then each of the sets of game presentation component processes assessed and approved individually. Further, regulatory approval may be straightforward and 15 readily obtained where only the presentation of a game is changed, for example changing a game theme from a circus to a seaside theme, without altering the actual game play process. 20 As illustrated in Figure 7, a virtual machine monitor or hypervisor 720 is provided to enable execution of multiple virtual machines on the same physical processor hardware 710, this can be referred to as virtualisation or paravirtualisation. The physical hardware 710 may comprise 25 one or more central processor units (CPUs) 712a-n and a variety of memory resources 714. In the architecture of the embodiment illustrated, the virtual machine monitor (VMM) 720 is a basic abstraction layer of software that sits directly on the hardware 710 below any operating 30 systems 730, 740. The VMM performs scheduling of process execution across the physical hardware 710, including scheduling across multiple processors 712a-n and processor cores in the case of multi-core processors. The VMM also abstracts the hardware to define the virtual machines for 2750803_1 (GHMattr) P78385.AIJ.2 27107111 - 20 the various operating systems. Thus the virtual machine hardware architecture apparent and accessible to the operating system executing within that machine may be different from the actual physical hardware architecture. 5 It should be appreciated that the sophistication of the VMM used may place constraints on the physical hardware architecture which may be used. Further, the sophistication of the VMM will also determine the flexibility of the abstraction of hardware to the different 10 virtual machines. For example, a simple VMM may only be able to operate in a single processor hardware environment. The abstracted hardware for each virtual machine may be an image of the physical processor hardware and hardware peripherals only visible to one virtual machine. 15 Alternatively a sophisticated VMM may be capable of operating in a multi processor environment and enable different abstracted hardware architectures for each virtual machine. 20 The VMM 720 of Figure 7 operates at the lowest and most privileged layer in the architecture. The 'MM 720 can host multiple guest operating systems (OS), each executing within a secure virtual machine 730, 740. The VMM 720 is responsible for processing scheduling and memory 25 partitioning of the various virtual machines running on the same physical hardware 710. The VMM 720 abstracts the hardware for the virtual machines 730, 740 and controls the execution of the virtual machines 730, 740 which share a common hardware processing environment 710. The operating 30 system running in each virtual machine may be a modified or unmodified version of an operating system depending on the level of virtualisation. For example, where full virtualisation is used, unmodified operating systems such as standard windows or other unmodified operating systems 2750803_1 (GNMatter) P78380AU 2 27/07/11 - 21 may be used. In this full virtualisation embodiment the operating system is not aware that it is sharing hardware. Whereas where paravirtualisation is used operating systems must be modified and the virtual machine recognises that it 5 is sharing hardware resources. A VMM may support a combination of fully virtualised and paravirtualised virtual machines. Each virtual machine 730, 740 can be referred to as a 10 domain. Within each domain 730, 740 the operating system manages its own applications. Managing the applications within an OS includes responsibility for scheduling each application 750, 760 within time allotted to the virtual machine 730, 740 by the VMM 720. For example, each 15 operating system schedules the execution of its applications as if it were operating on its own stand alone hardware. The VMM allocates processing capacity to the respective virtual machines and schedules the execution from each virtual machine on the physical hardware. 20 The VMM can also include a mechanism for enabling data to be exchanged between processes executing in different virtual machines, for example using an inter domain signalling protocol. For example, this inter-domain data 25 exchange enables data, such as game outcome data, to be transferred from an operating system executing component processes for game play to an operating system executing component processes for game outcome presentation. 30 The VMM can also be adapted to selectively enable access to peripheral hardware devices. For example, by virtualising hardware devices 770 or their drivers 780, 782, 784 in a virtual machine, the peripheral hardware devices become accessible to that virtual machine. The VMM may 2750803_1 (GHMattr) P78305 AU2 27107111 - 22 selectively virtualise peripheral devices in a virtual machine, thus only making some peripheral devices accessible to the operating system of the virtual machine. For example, in a gaming system peripheral devices for 5 handling player credits, such as a card reader, can be made accessible only to one operating system and invisible to others, which can have security advantages. Further, each virtual machine can use a different operating system, enabling advantageous operating system and hardware 10 combinations to be chosen. For example, the virtual machine executing a windows operating system having enhanced graphics handling capabilities may be granted direct hardware access to the graphics card. 15 In the embodiment illustrated in Figure 7 the applications executed in each operating system 730, 740 are the component processes 750, 760 for implementing the game. The two sets of component processes 750, 760 cooperate to implement the game. For example, the first set of 20 component processes 750 can be processes related to processing game play instructions and generation of game outcomes. The second set of component processes 760 can be game presentation processes, for example game graphics, sounds and controlling other aspects of a game machine such 25 as flashing lights. In this example, game result data generated by the first set of component processes 750 is provided to the second set of component processes 760 for presentation to the player. As these component processes operate in different virtual machines, the game 30 presentation processes do not influence the result of the game. This can offer security advantages and flexibility in game generation. An example of a suitable VM for implementing the described 2750803_1 (GHMates) P7830 AIJ.2 2707/11 - 23 architecture is a Xen* hypervisor. Xen* is an open source VMM adapted for use with processor hardware provided from several manufacturers, for example the Xen* hypervisor is adapted for use with IA-32, x86, x86-64, IA-64 and PowerPC 5 970 architectures. Xen* can support a number of different guest operating systems including Windows, Linux, Solaris®, and various versions of the BSD operating system. Xen* is also adapted to take advantage of some hardware virtualisation support in processors manufactured by Intel* 10 and AMD* which enables the hypervisor to grant direct hardware access to guest operating systems. Although a preferred embodiment will now be described with reference to features of the Xen* hypervisor, alternative VMNs are considered within the scope of the present application. 15 In the Xen* architecture the first virtual machine, domain 0 can have special management privileges for interaction with other virtual machines and special hardware access privileges. The domain 0 operating system instance is 20 booted initially on power up. Typically the operating system for domain 0 is a modified version of Linux. Domain 0 includes management and control functions for building other virtual machines. For example, after the operating system instance of domain 0 is booted further operating 25 system instances can be booted as guest domains from within domain 0 using the management and control functions. For example, a windows operating system may be booted in a guest domain and a further guest domain for a further Linux operating system instance. Each guest domain can be 30 referred to as a domain U or unprivileged domain. The management and control functions of domain 0 can also be used to selectively allocate access to physical hardware resources to guest operating system instances and the 2750803_1 (GHMatter) P7830. AU.2 27/07/11 - 24 hardware access can be exclusive. For example, hardware access can be allocated to a domain at PCI (peripheral component interconnect) level in a manner which makes the hardware visible and accessible to the allocated domain 5 only, say a guest domain U with a windows operating system instance, and invisible to the other domains including the host domain 0. Domain 0 can also perform administrative tasks such as 10 suspending and resuming other virtual machines. For example, where there is a fault or crash in a guest domain, the guest operating system instance may be restarted under the control of domain 0 while processing continues in other domains. An advantage of this is that where an operating 15 system is less stable or the code execution in a virtual machine is potentially unstable, this operating system instance can be re-booted independent of processing occurring in other virtual machines, if necessary. For example, in a gaming context graphics processes may execute 20 in one domain and game play processes such as result generation and award handling may execute in another domain. If there is a problem with the graphics processing, then the operating system of the graphics domain may be restarted without disturbing the game play 25 processing. This means that where a problem occurs with graphics processing this can be corrected and allow the game to continue uninterrupted. Depending on the time taken to correct the graphics processing fault a player may not even be aware a problem occurred. Further, risks due 30 to a graphics package or operating system being potentially unstable are mitigated by virtue of the partitioning into separate virtual machines. Figure 8 illustrates a game system having an electronic 2750803_1 (GHMatter) P7835ALI.2 27107111 - 25 processing arrangement adapted to support simultaneous execution of two or more operating system instances. The system comprises a game controller 800 and a player interface 850. The game controller comprises memory 810, 5 processor 820, and peripheral hardware 886. The player interface 850 includes all the hardware accessible to the player, including a credit mechanism 852 such as a card/ticket reader or coin mechanism, game play mechanism 856 such as a touch screen or buttons, one or more displays 10 854 and speakers 858. In a case where a touch screen is included as part of the game play mechanism 856 the touch screen may also be one of the displays 854. In this embodiment the game controller 850 processor 820 15 can be an electronic processing arrangement comprising one or more processors, each having one more processor cores. The processor 820 is adapted to support simultaneous execution of two operating system instances, with a first operating system instance running in domain 0 860 and a 20 second operating system instance running in domain U 870. The first, domain 0, operating system instance 860 includes management and control functions 862 for starting and monitoring the second operating system instance 870. The management and control functions 862 can also be used to 25 control access to peripheral hardware for each operating system 860, 870. In this embodiment a game is implemented using cooperating component processes including an outcome generator process 30 864, an input/output handling process 866, a prize evaluator 868, a display controller 875 and a sound controller 878. The component processes are partitioned such that the outcome generator 864, input/output handler 866 and prize evaluator 868 component processes for 2750803_1 (GHMatr) P7835AAJ 2 27/07111 - 26 implementing game play execute using the first operating system instance 860 and the display controller 875 and sound controller 878 component processes for presenting game results execute using the second operating system 5 instance 870. The memory 810 is shared between the two operating system instances. Memory 810 is used to store data such as game rules 840 accessed by the component processes for game 10 play, in particular for generating and evaluating game outcomes, and game presentation theme data 845 which can be accessed by the game presentation component processes. Other data such as player data 830 may be accessed by both the game play and game presentation component processes. 15 For example, during the course of game play, player data may be updated by the game play component processes with a players current credit balance, bet amount, selected pay lines, win amount etc. This data may be read by game presentation component processes for display. A virtual 20 machine monitor VMM (not shown) is responsible for scheduling processing on the physical hardware and memory access for the two domains 860, 870. In this example the first virtual machine 860, domain 0, 25 uses a version of the Linux* operating system. The game component processes executed within this operating system instance, in this embodiment, are processes related to game play. These processes can include: communication via the network interface to game 30 servers; receiving and processing game play instructions input via the game play mechanism; interaction with game controller peripheral hardware such as a meters for regulator monitoring and a random 2750803_1 (GHMatter) P78380ALJ2 27/07/11 - 27 number generator, if a peripheral random number generator is used; game mathematics such as outcome generation and prize evaluation; 5 market functions such as player tracking an loyalty monitoring; and handling of player credit, including reading cards or tickets, real time processing of credit input using a coin or bill input acceptor, and controlling pay out of credit 10 using a coin output or ticket output. In this example the second virtual machine 870, domain U, uses a Windows* operating system. The game component processes executed within this operating system instance, 15 in this embodiment, are processes related to game presentation, including video processing, graphical presentation of game outcomes and graphical user interface (GUI) presentation. Sound processing may also be included in this operating system instance. Partitioning the game 20 component processes in this manner enables latest graphical processing features of the Windows* operating system to be taken advantage of for presenting the game. Other operating system types and combinations thereof may 25 also be used and are envisaged within the scope of the present application. For example, the graphical processing capabilities of Windows* operating system referred to above may be superseded by an alternative operating system or operating system version. In this instance the system may 30 be upgraded by producing an alternative embodiment using the alternative operating system. The host operating system instance and component processes therein executed to perform the game may remain the same . The second guest operating system instance and the component processes 2750803_1 (GHMtter) P7838EAIJ.2 27/07/11 - 28 executed therein can be changed to the new operating system or version having improved graphical processing capabilities. In this scenario, as the game execution component processes have not been changed, regulatory 5 approval for the upgraded gaming system may be easier to obtain than for an entirely new gaming system. Some of the game play processes executing in the first virtual machine 860 require access to peripheral hardware. 10 For example, the game play processes 864, 866, 868 executing in the first virtual machine 860 may require access to the credit mechanism 852, network card 882, random number generator 880, meters 884 and game play mechanism 856. Domain 0, in the Xen* architecture is a 15 privileged domain and therefore, by default, is allocated access to all peripheral hardware. This means that all the peripheral hardware will be visible in domain 0 but not visible or directly accessible to any guest domain U. This has an advantage in that any processing in a guest domain U 20 cannot interact with peripheral hardware it does not have access to. For example, graphics processing in domain U cannot affect any credit input or payed out as the credit mechanism is not visible or accessible to domain U. In some embodiments the processing in domain U 870 may not 25 require any direct hardware access or hardware can be emulated in the domain U virtual machine so it appears to domain U that the operating system has access to the hardware, but any data exchanged between a peripheral hardware device and a process in domain U is actually 30 handled by domain 0. In some embodiments processor and VMM architectures can support granting direct hardware access to domain U. In such embodiments domain 0 can selectively allocate direct 2750803_1 (GHMattes) P78365.AU.2 27/0711 - 29 access to hardware to domain U. For example, in the embodiment illustrated, domain U can be granted direct access to graphics or video cards and sound cards at PCI level for game presentation. The virtual machines can be 5 configured so that direct access is selectively allocated for different hardware devices and the access can be exclusive. For example, domain U 870 can be granted direct access to 10 graphics and sound cards used for game graphic and sound processing by the display controller 875 and sound controller 878 and driving the displays 854 and speakers 858 respectively. Other hardware can remain invisible to domain U, for example there is no need for domain U to 15 access the random number generator 880 or credit mechanism 852 so this hardware is not made visible to domain U 870. The virtual machines can be configured such that direct hardware access to a device is granted exclusively to a 20 virtual machine. Exclusive access to a hardware device for domain U will make the device visible to the operating system in domain U and invisible to the operating system in domain 0. Using the example above, exclusive access to the video and sound cards to domain U will make these cards 25 visible to processes executing in domain U but invisible and inaccessible to processes executing in domain 0. Granting direct access to hardware to a guest domain 870 can be controlled by the host domain, domain 0 860, using the management and control functionality 862 provided in 30 that domain. Configuring the virtual machines may be performed automatically using program code or under the control of an administrator. For example, when starting up a game machine an administrator may log in to domain 0 820 and, using the management and control functions 862, 2750803_1 (GHMatts) P78385.AI.2 27107/11 - 30 configure the two or more domains to selectively allocate hardware access to one or more domains. An example of game processing using the game system of 5 Figure 8 will now be described in relation to a spinning reel game. The display controller 875 in domain U 870 reads game presentation data from memory, processes the presentation data and presents game information on a display 854, for example a screen including game play 10 instructions and an invitation to play the game. A player uses the credit mechanism 852 to input credit for wagers and the game play mechanism 856 to input game play instructions, for example the number of win lines to play and the amount wagered for each win line. These inputs are 15 processed in domain 0 860 by the I/O interface process 866 and player data 830 stored in memory 810. Data may also be sent to a connected game server using the network card 882, for example player tracking data sent to a player loyalty/marketing server or wager data to a bonus server. 20 The outcome generator 864 operates in response to the player's operation of game play mechanism 856 to generate a game outcome which will then be evaluated by prize evaluator 868. The first part of forming the game outcome 25 is for a random result to be generated, for example using a random number generator 880 and processing the random result by the outcome generator 864 in accordance with game rules 840. 30 For example, for a spinning reel game, each spinning reel is simulated using a set of symbols having a defined sequence. The symbol image data for each symbol set can be stored in the presentation data 845. A generated random number is used by the outcome generator 864 to determine 2750803_1 (GHMatr) P78305 AIJ2 27/07111 - 31 for each set of symbols a position in the sequence representative of a stop position for the spinning reel. A selected outcome symbol set can be determined from the stop positions and the number of symbols to be selected from 5 each reel, for example three symbols for each of five reels. The prize evaluator 868 is provided with selected symbol set which is evaluated in accordance with game rules 840 to 10 determine whether a prize is to be awarded for the game outcome. For example, the prize evaluator compares the selected symbol set with prize winning symbol combinations and prize tables stored in the game rules 840 to determine any prize to award. Data indicating any winning 15 combinations and prize data is then stored in player data. The stop position data or selected symbol data for each reel and any prize data can be provided to the display controller 875 in domain U for presentation of the game 20 outcome symbol set. For example, the stop position data may be stored in memory 810 and a signal or interrupt, triggered by the outcome generator and handled by the VMM, sent to the display controller and sound controller in domain U to advise that a result is ready for display. The 25 display controller 875 uses the stop position data and symbol image data to cause a set of symbols to be displayed on display 854 at a set of display positions. For example, for each of five sets, the three symbols in sequence after the stop position for that set may be displayed such that 30 symbols are displayed at fifteen display positions on display 854. The display controller may also generate and play an animation of the reels spinning prior to displaying the outcome symbol set. The display controller can also highlight any winning symbol combinations based on the 275083.1 (GHMatter)PT8305.A).2 27107111 - 32 prize data, for example by changing the colour of a winning pay line or flashing symbols of a winning combination. Other data such as a credit value awarded for the outcome and player's remaining credit balance can also be read from 5 player data and displayed. Sounds may also be played by the sound controller based on the outcome, for example sounds representative of the reels spinning may be played in conjunction with the animation of the spinning reels and a selected tune may be played for a winning outcome. 10 This example illustrates how game presentation processing can be performed independent of game play processing. The display controller and sound controller simply read data from the shared memory in order to present the game 15 outcomes. The presentation game processing may be provided read only memory access or alternatively data passed between domains may only be temporarily stored, for example in buffer or register memory, so the processing in domain U does not directly access player data 830. It should be 20 appreciated that partitioning processing in this manner means that presentation processing in domain U cannot influence the game play processing in domain 0. Although the example illustrated uses two virtual machines, 25 three or more virtual machines may also be used. For example, where a software random number generator or pseudo-random number generator is used for generating game outcomes, this random number generator may be isolated from other game processes in its own domain U. This may be 30 advantages for maintaining the security and integrity of the random number generator or enabling the random number generator to be implemented in an operating system different from other operating systems used for game processing. 2750803_1 (GHMatir) P783M.AU 2 27107111 - 33 Persons skilled in the art will also appreciate that an embodiment could be embodied in program code for adapting a processor to support two or more operating system instances 5 and implement a game as described above. The program code could be supplied in a number of ways, for example on a computer readable medium, such as a disc or a memory (for example, that could replace part of memory 103) or as a data signal (for example, by downloading it from a server). 10 In some cases hardware access may be shared between domains. For example an I/O interface such as a touch screen may be visible in both domain 0 860 for processing input game play instructions and domain U for presenting 15 game instructions or outcomes. In this example the hardware may be emulated in one of the domains. Alternatively access to the hardware is scheduled between the hardware sharing virtual machines by the VMM. 20 It will be understood to persons skilled in the art of the invention that many modifications may be made without departing from the spirit and scope of the invention, in particular it will be apparent that certain features of the invention can be combined to form further embodiments. 25 It is to be understood that, if any prior art publication is referred to herein, such reference does not constitute an admission that the publication forms a part of the common general knowledge in the art, in Australia or any 30 other country. In the claims which follow and in the preceding description, except where the context requires otherwise due to express language or necessary implication, the word 275083_1 (GHMatt) P7838i.AU 2 27/07111 - 34 "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various 5 embodiments of the invention. 2750803_1 (GHUattes) P78365.AJ.2 27/07/11

Claims (39)

1. A gaming system processor module adapted to support simultaneous execution of two or more operating system 5 instances to thereby enable execution of program code which enables play of a game, whereby execution of the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, 10 and second of the cooperating component processes executes using a further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component processes in the first operating 15 system instance are accessible by the second of the cooperating component processes in the further operating system instance.

2. A gaming system processor module as claimed in 20 claim 1 having a virtual machine monitor to support the simultaneous execution of two or more operating system instances, wherein each operating system instance executes in its own virtual machine. 25

3. A gaming system processor module as claimed in claim 2 comprising one or more physical processors.

4. A gaming system processor module as claimed in claim 3 wherein each processor has one or more processing 30 cores.

5. A gaming system processor module as claimed in claim 2 wherein each operating system instance can be selectively provided with direct access to one or more 27508032 (GHMatters) P78365.AU.2 30/10/13 -36 hardware resources.

6. A gaming system processor module as claimed in claim 5 wherein any hardware resource access provided to an 5 operating system instance is exclusive to the operating system instance.

7. A gaming system processor module as claimed in claim 6 wherein a first operating system instance acts as a 10 host operating system and each further operating system instance acts as a guest operating system, and wherein access to hardware resources is allocated selectively to guest operating system instances under control of the host operating system. 15

8. A gaming system processor module as claimed in claim 7 wherein the host operating system instance is adapted to monitor the guest operating system instances and selectively restart a guest operating system instance, if 20 necessary, when an execution error is detected in the guest operating system instance.

9. A gaming system processor module as claimed in claim 7 wherein component processes related to game play 25 execute in a first guest operating system instance and component processes related to game presentation execute in a second guest operating system instance.

10. A gaming system processor module as claimed in 30 claim 9 wherein the first and second operating system instances each execute a different type of operating system.

11. A gaming system processor module as claimed in 27508032 (GHMatters) P78365.AU.2 30/10/13 -37 claim 10 wherein the first operating system type is a LINUX operating system or variant thereof.

12. A gaming system processor module as claimed in 5 claim 11 wherein the second guest operating system is a Microsoft Windows operating system.

13. A gaming system processor module as claimed in claim 12 wherein component processes executed using the 10 second guest operating system include game graphics component processes.

14. A gaming system processor module as claimed in claim 13 wherein the second guest operating system is 15 provided access to game system hardware resources for displaying game graphics.

15. A gaming system comprising: a player interface arranged to enable a player to 20 enter instructions to play a game and including one or more displays to display game results; and a game controller in data communication with the player interface, the game controller comprising: a memory; and 25 an electronic processing arrangement adapted to support simultaneous execution of two or more operating system instances to thereby enable execution of program code which enables play of a game, whereby execution of the program code uses 30 two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and a second of the cooperating component process executes using a 2750803_2 (GHMatters) P78365.AU.2 30/10/13 -38 further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component 5 processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance. 10

16. A gaming system as claimed in claim 15 wherein the processing arrangement is provided with a virtual machine monitor to support the simultaneous execution of two or more operating system instances wherein each operating system instance executes in its own a virtual 15 machine.

17. A gaming system as claimed in claim 16 wherein the processing arrangement comprises one or more physical processors. 20

18. A gaming system as claimed in claim 17 wherein each processor has one or more processing cores.

19. A gaming system as claimed in claim 16 wherein 25 each operating system instance can be selectively provided with direct access to one or more hardware resources.

20. A gaming system as claimed in claim 19 wherein any hardware resource access provided to an operating 30 system instance is exclusive to the operating system instance.

21. A gaming system as claimed in claim 20 wherein a first operating system instance acts as a host operating 2750803_2 (GHMatters) P783065.AU.2 30/10/13 -39 system and each further operating system instance acts as a guest operating system, and wherein access to hardware resources is allocated selectively to guest operating system instances under control of the host operating 5 system.

22. A gaming system as claimed in claim 21 wherein component processes related to game play execute in a first operating system instance and component processes related 10 to game presentation execute in a second guest operating system instance.

23. A gaming system as claimed in claim 22 wherein the first and second operating system instances each 15 execute a different type of operating system.

24. A gaming system as claimed in claim 23 wherein the first operating system type is a LINUX operating system or variant thereof. 20

25. A gaming system as claimed in claim 24 wherein the second guest operating system is a Microsoft Windows operating system. 25

26. A gaming system as claimed in claim 25 wherein component processes executed using the second guest operating system include game graphics component processes.

27. A gaming system as claimed in claim 26 wherein 30 the second guest operating system is provided access to game system hardware resources for displaying game graphics.

28. A game controller comprising: 27508032 (GHMatters) P78365.AU.2 30/10113 -40 a memory; and an electronic processing arrangement adapted to support simultaneous execution of two or more operating system instances to thereby enable execution of program 5 code which enables play of a game, whereby execution of the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and a second of the cooperating component 10 processes executes using a further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component processes in the first operating system instance are 15 accessible by the second of the cooperating component processes in the further operating system instance.

29. A game controller as claimed in claim 28 wherein the processing arrangement comprises one or more physical 20 processors.

30. A game controller as claimed in claim 29 wherein each processor has one or more processing cores. 25

31. A computer readable storage medium comprising computer readable instructions which when executed by a processor of a game system adapt the processor to support simultaneous execution of two or more operating system instances, to thereby enable execution of program code 30 which enables play of a game, and execution of a the program code uses two or more cooperating component processes partitioned such that a first of the cooperating component processes executes using a first operating system instance, and a second of the cooperating component 2750803_2 (GHMatters) P78365.AU.2 30110/13 -41 processes executes using a further operating system instance, each operating system instance at least having direct access to system memory such that data elements generated by the first of the cooperating component 5 processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance.

32. A method of gaming comprising the steps of: providing program code which enables play of a 10 game, wherein execution of the program code uses two or more cooperating component processes; executing a first of the cooperating component processes using a first operating system instance; and executing a second of the cooperating component 15 processes using a further operating system instance, wherein the execution of the component processes in the first and further operating systems cooperates to implement the game, each operating system instance at least having direct access to system memory such that data elements 20 generated by the first of the cooperating component processes in the first operating system instance are accessible by the second of the cooperating component processes in the further operating system instance. 25

33. A method as claimed in claim 32 further comprising the step of selectively providing direct hardware access to each operating system instance.

34. A method as claimed in claim 32 wherein the 30 component processes executed in the first operating system are component processes for implementing game play and component processes executed the further operating system instance are component processes for game presentation. 2750803_2 (GHMatters) P78365.AU.2 30/10/13 -42

35. A gaming system processor module substantially as herein described.

36. A gaming system substantially as herein described. 5

37. A game controller substantially as herein described.

38. A computer readable storage medium substantially as herein described. 10

39. A method of gaming substantially as herein described. 27508033 (GHMatters) P78365.AU.2 30/10/13