WO2014052206A1

WO2014052206A1 - Replay and resumption of suspended game

Info

Publication number: WO2014052206A1
Application number: PCT/US2013/061029
Authority: WO
Inventors: Brian Michael Christopher WATSON; Victor Octav Suba Miura; Jacob P. Stine; Nicholas J. Cardell
Original assignee: Sony Computer Entertainment Inc.
Priority date: 2012-09-28
Filing date: 2013-09-20
Publication date: 2014-04-03

Abstract

A client device platform may provide an emulator with game inputs to advance an emulated game from a first state to a second state. The emulator may record game inputs. When emulation of the game is suspended, the client device platform may deliver a replay request to the emulator. Upon receiving it, the emulator may re-emulate the game inputs stored in the emulator's memory. The re-emulation produces a replay which may be delivered back to the client device platform. Pre-loading a translated application is also described. An emulator may choose an application for pre-loading before a client device requests the application. Once the application is selected, the emulator may begin translating its data into a format compatible with the client device. After translation, the data is stored in a memory so that it may be accessed upon the request of the client device.

Description

REPLAY AND RESUMPTION OF SUSPENDED GAME

CROSS-REFERENCE TO RELATED APPLICATION

This application is related to commonly-assigned, co-pending provisional application serial no. 61/666,628, (Attorney Docket Number SCEA12004US00) filed June 29, 2012, and entitled "DETERMINING TRIGGERS FOR CLOUD-BASED EMULATED GAMES", the entire disclosures of which are incorporated herein by reference.

This application is related to commonly-assigned, co-pending provisional application serial no. 61/666,645, (Attorney Docket Number SCEA12005US00) filed June 29, 2012, and entitled "HAPTIC ENHANCEMENTS FOR EMULATED VIDEO GAME NOT

ORIGINALLY DESIGNED WITH HAPTIC CAPABILITIES", the entire disclosures of which are incorporated herein by reference.

This application is related to commonly-assigned, co-pending provisional application serial no. 61/666,665, (Attorney Docket Number SCEA12006US00) filed June 29, 2012, and entitled "CONVERSION OF HAPTIC EVENTS INTO SCREEN EVENTS", the entire disclosures of which are incorporated herein by reference.

This application is related to commonly-assigned, co-pending provisional application serial no. 61/666,679, (Attorney Docket Number SCEA12007US00) filed June 29, 2012, and entitled "SUSPENDING STATE OF CLOUD-BASED LEGACY APPLICATIONS", the entire disclosures of which are incorporated herein by reference. This application is related to commonly-assigned, co-pending application serial no. 13/ 631,740, (Attorney Docket Number SCEA12009US00), filed September 28, 2013, and entitled "METHOD FOR CREATING A MINI-GAME" to Brian Michael Christopher Watson, Victor Octav Suba Miura, and Jacob P. Stine, the entire disclosures of which are incorporated herein by reference. This application is related to commonly-assigned, co-pending application serial no.

13/631,803 (Attorney Docket Number SCEA1201 1US00), filed September 28, 2012, and entitled "ADAPTIVE LOAD BALANCING IN SOFTWARE EMULATION OF GPU HARDWARE", to Takayuki Kazama and Victor Octav Suba Miura, the entire disclosures of which are incorporated herein by reference. This application is related to commonly-assigned, co-pending application serial no.

13/631,812, (Attorney Docket Number SCEA12012US00), filed September 28, 2012, entitled "METHOD AND APPARATUS FOR IMPROVING EFFICIENCY WITHOUT

INCREASING LATENCY IN EMULATION OF A LEGACY APPLICATION TITLE", to Jacob P. Stine and Victor Octav Suba Miura, the entire disclosures of which are incorporated herein by reference.

FIELD OF THE DISCLOSURE

The present disclosure is related to video game emulation. Among other things, this application describes a method and apparatus for emulating a video game that includes generating a replay of an emulated title and a method and apparatus for pre-loading emulated applications.

BACKGROUND OF THE INVENTION

When playing video games over a cloud-based network, one of the biggest concerns for game developers is the efficient use of the available network bandwidth. As such, gaming experiences that would otherwise be available during a non-cloud based gaming session may be eliminated in order to conserve the bandwidth. One such gaming experience that requires substantial bandwidth is replay functionality. The gameplay that is traditionally recorded for use in a replay is often stored in large files. This poses several problems. First, the replay must always be recorded since there is a possibility that the game player may want to view a replay at any stage of the game. The large file that is created may consume a substantial portion of available memory on the cloud-based server. In order to keep replay functionality, the length of the replay must be kept short, or there must be a large amount of memory dedicated to the storage of replay information. Second, when the game player requests a replay, the large file must be delivered over the cloud-based network. This service may consume a large portion of the bandwidth and result in poor performance to the game player, and others using the cloud-based network at that time.

Therefore, there is a need in the art for method and apparatus for recording replays of a video game and delivering the replay to the game player, which does not consume a large quantity of memory or bandwidth. It is within this context that aspects of the present disclosure arise. Video games are commonly loaded into a random access memory (RAM) before a player may begin playing the game. This loading process may take a substantial amount of time. Instead of showing a blank screen to the game player, games are often designed with a loading screen. Loading screens may be a picture or a video related to the game, or even a progress bar. However, these loading screens are often not desirable. Preferably, once a game is selected, the game should be immediately playable. The effects of loading time are compounded further when games are being emulated and being delivered over a cloud based network. The delivery over the network may create an additional wait time. Also, network delays may cause the delivery of the emulated data to a game player's device to be slowed as well.

Further still, games are designed to be loaded from a predetermined starting position.

Incremental buffering may be used in order to make the game load faster from this predetermined starting position. Incremental buffering is a technique that may be used to allow a game to load faster. Instead of having to build a large buffer from the beginning of the game, the buffer is initially small and then grows in size as the gamep lay progresses. However, when a game is loaded at a location where the incremental buffering was not incorporated into the design of the game, the loading time may take even longer because a larger buffer must first be built at this position of the game. With the growth in popularity of mini-games, the ability to load a game quickly from any point in the game is highly desirable. In order to implement faster loading through incremental buffering, a game designer would be required to re-code parts of the game. This additional step would increase the time and cost required for developing mini-games.

Therefore, there is a need in the art for a method and apparatus for pre-loading translated code in a cloud based emulation. It is within this context that aspects of the present disclosure arise.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram of a client device platform and an emulator communicating over a network according to an aspect of the present disclosure.

FIG. 2A is a flow diagram illustrating a method of producing a replay for an emulated game according to an aspect of the present disclosure. FIG. 2B is a flow diagram illustrating a method of resuming an emulated game according to an aspect of the present disclosure.

FIGs. 3A-3E are schematic diagrams illustrating the process of producing a replay of an emulated game and the process of resuming an emulated game according to various aspects of the present disclosure.

FIG. 4 is a chart that demonstrates how game inputs are recorded over time according to an aspect of the present disclosure.

FIG. 5A is a block diagram describing computer-executable instructions for producing a replay with a client device platform according to an aspect of the present disclosure.

FIG. 5B is a block diagram describing computer-executable instructions for producing a replay with an emulator according to an aspect of the present invention.

FIG. 6A is a block diagram describing computer-executable instructions for resumes an emulated game with a client device platform according to an aspect of the present disclosure

FIG. 6B is a block diagram describing computer-executable instructions for resuming an emulated game with an emulator according to an aspect of the present disclosure.

FIG. 7 is a schematic diagram of a client device platform and an emulator residing on a cloud based server communicating over a network according to an aspect of the present disclosure.

FIG. 8A is a block diagram of a method for pre-loading an emulated application according to an aspect of the present disclosure.

FIG. 8B is a block diagram describing the instructions for how an emulator may pre-load an application according to an aspect of the present disclosure.

FIG. 9A is a block diagram of a method for pre-loading a snapshot according to an aspect of the present disclosure.

FIG. 9B is a block diagram describing the instructions for how an emulator may pre-load a snapshot according to an aspect of the present disclosure. FIG. 10 is a drawing of the game selection menu displayed on a client device platform that illustrates how a prediction engine may determine which game to pre-load according to an aspect of the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure.

Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description.

According to aspects of the present disclosure, a replay may be recorded while a client device platform is advancing an emulated game from a first state to a second state. A client device platform may first deliver a series of game inputs to an emulator. The game inputs may include a snapshot of the first state and one or more game inputs that advance the emulated game from the first state to a second state. When the emulator receives the game inputs, it begins to emulate the game in accordance with the inputs, while also recording the inputs with respect to the time they are received and storing them in a memory. The client device platform may then deliver a suspension request to the emulator. When the emulator receives the suspension request, it suspends the emulated game and may generate a snapshot of the game.

According to additional aspects of the present disclosure, the client device platform may deliver a replay request to the emulator at the same time as, or subsequent to the delivering of the suspension request. Upon receiving the replay request, the emulator will re-emulate the game inputs that have been stored in the emulator's memory. The re-emulation will produce the replay which may be delivered back to the client device platform.

According to additional aspects of the present disclosure, the client device platform may deliver a resume request to the emulator after the suspension request. Upon receiving the resume request, the snapshot generated during the suspension of the emulated game may be loaded by the emulator. Once the snapshot is loaded, the client device platform may continue delivering additional game inputs in order to advance the emulated game to a different state. According to additional aspects of the present disclosure, the emulator may load the snapshot generated before the resume request is delivered to the emulator.

FIG. 1 is a schematic diagram illustrating a system containing components that can implement emulation in accordance with aspects of the present disclosure. An emulator 107 may be accessed by a client device platform 103 over a network 160. The client device platform 103 may access alternative emulators 107 over the network 160. The emulators 107 may be identical to each other, or they may each be programed to emulate unique legacy game titles 106 or unique sets of legacy game titles 106.

The client device platform 103 may include a central processor unit (CPU) 131. By way of example, a CPU 131 may include one or more processors, which may be configured according to any suitable processor architecture, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The client device platform 103 may also include a memory 132 (e.g., RAM, DRAM, ROM, and the like). The CPU 131 may execute a process-control program 133, portions of which may be stored in the memory 132. The client device platform 103 may also include well-known support circuits 140, such as input/output (I/O) circuits 141, power supplies (P/S) 142, a clock (CLK) 143 and cache 144. The client device platform 103 may optionally include a mass storage device 134 such as a disk drive, CD- ROM drive, tape drive, or the like to store programs and/or data. The client device platform 103 may also optionally include a display unit 137 and a user interface unit 138 to facilitate interaction between the client device platform 103 and a user. The display unit 137 may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit 138 may include a keyboard, mouse, joystick, light pen, or other device. A controller 145 may be connected to the client device platform 103 through the I/O circuit 141 or it may be directly integrated into the client device platform 103. The controller 145 may facilitate interaction between the client device platform 103 and a user. The controller 145 may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The controller 145 may also be capable of generating a haptic response 146. By way of example and not by way of limitation, the haptic response 146 may be implemented in the form of mechanical vibrations or any other feedback corresponding to the sense of touch. The client device platform 103 may include a network interface 139, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods. The network interface 139 may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network 160. The network interface 139 may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform 103 may send and receive data and/or requests for files via one or more data packets over the network 160.

The preceding components may exchange signals with each other via an internal system bus 150. The client device platform 103 may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein.

The emulator 107 may include a central processor unit (CPU) 131'. By way of example, a CPU 131' may include one or more processors, which may be configured according to any suitable processor architecture, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The emulator 107 may also include a memory 132' (e.g., RAM, DRAM, ROM, and the like). The CPU 131' may execute a process-control program 133', portions of which may be stored in the memory 132'. The emulator 107 may also include well-known support circuits 140', such as input/output (I/O) circuits 141', power supplies (P/S) 142', a clock (CLK) 143' and cache 144'. The emulator 107 may optionally include a mass storage device 134' such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator 107 may also optionally include a display unit 137' and user interface unit 138' to facilitate interaction between the emulator 107 and a user who requires direct access to the emulator 107. By way of example and not by way of limitation a client device platform or engineer 103 may need direct access to the emulator 107 in order to program the emulator 107 to properly emulate a desired legacy game 106 or to add additional mini-game capabilities to a legacy game 106. The display unit 137' may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit 138' may include a keyboard, touchpad, touch screen, mouse, joystick, light pen, or other device. The emulator 107 may include a network interface 139', configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods. The network interface 139' may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network 160. The network interface 139' may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator 107 may send and receive data and/or requests for files via one or more data packets over the network 160.

The preceding components may exchange signals with each other via an internal system bus 150'. The emulator 107 may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein.

The emulator 107 may access a legacy game 106 that has been selected by the client device platform 103 for emulation through the internal system bus 150'. There may be more than one legacy game 106 stored in the emulator. The legacy games may also be stored in the memory 132' or in the mass storage device 134'. Additionally, one or more legacy games 106 may be stored at a remote location accessible to the emulator 107 over the network 160. Each legacy game 106 contains game code 108. When the legacy game 106 is emulated, the game code 108 produces legacy game data 109. Legacy game data 109 may be received by the client device platform 103 and displayed on the display unit 137.

By way of example, a legacy game 106 may be any game that is not compatible with a client device platform 103. By way of example and not by way of limitation, the legacy game 106 may have been designed to be played on Sony Computer Entertainment's PlayStation console, but the client device platform 103 is a home computer. By way of example, the legacy game 106 may have been designed to be played on a PlayStation 2 console, but the client device platform 103 is a PlayStation 3 console. Further, by way of example and not by way of limitation, a legacy game 106 may have been designed to be played on a PlayStation console, but the client device platform 103 is a hand held console such as the PlayStation Portable (PSP) or Vita from Sony Computer Entertainment. In some implementations, but not all, the emulator 107 may be a deterministic emulator. A deterministic emulator is an emulator that may process a given set of game inputs 347 the same way every time that the same set of inputs 347 are provided to the emulator 107. This may be accomplished by eliminating any dependencies in the code run by the emulator 107 that depend from asynchronous activity. Asynchronous activities are events that occur independently of the main program flow. This means that actions may be executed in a non- blocking scheme in order to allow the main program flow to continue processing. Therefore, by way of example, and not by way of limitation, the emulator 107 may be deterministic when the dependencies in the code 108 depend from basic blocks that always begin and end with synchronous activity. By way of example, basic blocks may be predetermined increments of code at which the emulator 107 checks for external events or additional game inputs 347. The emulator 107 may also wait for any activities that run asynchronously within a system component to complete before proceeding to the next basic block. When no asynchronous activities are running, the emulator 107 may be thought of as running all of the basic blocks of the code 108 in lock step. In such a case, the emulator 107 is sometimes said to be in a "steady state". As shown in FIG. 2A, the emulator 107 may be configured to implement a method for recording a replay of an emulated legacy game 106 according to an inventive method 200. Various aspects of the method 200 may be implemented by execution of computer executable instructions running on the client device platform 103 and/or the emulator 107 in conjunction with the actions of a client device platform 103. Specifically, a client device platform 103 may be configured, e.g., by suitable programming, to implement certain client device platform instructions 270. In addition, an emulator 107 may be configured to implement certain emulator instructions 271. In FIG. 2A the dashed arrows represent the flow of data between the client device platform 103 and the emulator 107 over the network 160.

Initially at 272, the client device platform 103 delivers game inputs 347 to the emulator 107 over the network 160. By way of example, and not by way of limitation, game inputs 347 may be commands that instruct the emulator 107 where to begin in an emulation routine, or they may be commands that control the game play of a legacy game 106 that is being emulated by the emulator 107. By way of example, and not by way of limitation, a game input 347 that instructs the emulator 107 where to begin in an emulation routine may be in the form of a previously generated snapshot 367. A snapshot may be a recorded description of the state of every device being emulated at a designated time during the emulation of a legacy game 106. Since the snapshot is taken when there is no asynchronous activity occurring in the emulator, the snapshot may be platform independent. Snapshots are described in greater detail in commonly-assigned, co-pending provisional application serial no. 61/666,679, (Attorney Docket Number SCEA12007US00) filed June 29, 2012, and entitled "SUSPENDING STATE OF CLOUD-BASED LEGACY APPLICATIONS". By way of example, and not by way of limitation, game inputs 347 may be automatically generated by the client device platform 103, or they may be provided to the client device platform 103 by an external source. By way of example, the game inputs 347 may be delivered to the emulator 107 all at the same time, or they may be delivered over a period of time. By way of example, and not by way of limitation, game inputs 347 which control the game play may include commands that are generally used by a game player to advance the legacy game 106 from a first state 301 to a second state 302. The first state 301 may be stored as a first snapshot, and the second state 302 may be the state of the game when a suspension request 357 is delivered to the emulator 107. The game inputs 347 may be inputted by a controller 145. Game inputs 347 of this nature may include, but are not limited to, inputs that cause a main character 340 in a legacy game 106 to move to a new position, swing a sword, select an item from a menu, or any other action that can take place during the game play of a legacy game 106. Additionally, while game inputs advance the game play of the legacy game 106 from a first state 301 to a second state 302, there may also be one or more intermediate states generated. Each of the intermediate states may optionally be recorded as a snapshot 367. Additionally a suspension request 357 or replay request 358 may be made at any intermediate state as well.

The emulator 107 receives the game inputs 347 at 273 and then proceeds to emulate the legacy game 106 in accordance with the game inputs 347 at 274. The emulation of the legacy game 106 causes the game to advance from a first state 301 to a second state 302. By way of example, and not by way of limitation, FIGs. 3 A and 3B are schematics illustrating some examples of the emulation process according to certain aspects of the present disclosure. FIG. 3A depicts the client device platform 103 delivering game inputs 347 to emulator 107. While emulating the legacy game 106, the emulator 107 may deliver emulated game data 109 to the client device platform 103. The emulated game data 109 may contain data configured to display the progression of the game on the client device platform's 103 display unit 137. By way of example, the first state 301 of the legacy game 106 is displayed on the emulator's display unit 137' as a result of receiving the game data 109. According to this example of the disclosure, the first state 301 includes the main character 340 standing on the left side of a large trench.

In addition to emulating the legacy game 106, the emulator 107 may also record the game inputs 347 in a memory component. By way of example, the emulator 107 may store the recorded game inputs 347 to the emulator's 107 memory 132', or in its mass storage 134'. FIG. 4 is a schematic of game inputs 347 as they are delivered to the emulator 107 over a thin input channel. In FIG. 4 time is represented in the X-direction, and each possible game input may be divided into its own sub-channel (represented by the rectangles stacked in the Y- direction). By way of example, and not by way of limitation, FIG. 4 displays nine possible game input values, each of which is delivered over its own sub-channel of the input channel. While eight of the game inputs displayed in FIG. 4 correspond to a button on a controller 145, these are not the only types of game inputs 347 which will be recorded. By way of example, and not by way of limitation, snapshots may also be recorded as game inputs 347. It should be noted that there could be more or less game input values, and each sub-channel may be shared by one or more game input values. When recording the input values 347, the emulator 107 will also record when each input is delivered with respect to time. By way of example, and not by way of limitation, the recording may begin at T=0 and the first game input 347 is a snapshot of a first state 301. The recording may end when a suspension request 357 is delivered to the emulator.

Once the client device platform 103 has provided sufficient game inputs 347 to advance the emulated game to a second state 302, the client device platform 103 may deliver a suspension request 357 to the emulator 107 at step 275. The suspension request 357 may be made by a user of the client device platform 103, or it may be automatically generated by the client device platform 103, or even the emulator 107. By way of example, and not by way of limitation, the suspension request may be automatically generated when there has been a lack of activity over a predetermined time period, a certain score is reached, or a predetermined game event has occurred. FIG. 3B illustrates an example of the client device platform 103 delivering the suspension request 357 to the emulator 107. In FIG. 3B, the second state 302 depicts the main character 340 standing just past the large trench. At 276, the emulator 107 may receive the suspension request 357 and (optionally) a replay request 358. Upon receiving the suspension request, the emulator 107 may suspend the emulation of the legacy game 106 and generate a snapshot 367 of the second state 302 at 277. When the emulation of the legacy game 106 has been suspended, the game data 109 delivered to the client device platform 103 may provide a visual indication that the legacy game 106 has been suspended. By way of example, and not by way of limitation, the visual indication may be a pause screen or a menu as shown on the display unit 137 in FIG. 3C. If the client did not deliver a replay request 358 with the suspension request 357, at 278 the client device platform 103 may separately deliver a replay request 358 to the emulator 107. After receiving the replay request 358, the emulator 107 may then begin to generate the replay game data 109' as indicated at 279. Instead of using recorded video of the actual gameplay, the replay game data 109' is produced by re-emulating the legacy game 106 from the point of suspension with the recorded game inputs 347. Since the emulator 107 may be a deterministic emulator, an exact replay of the original game play may be generated when the game inputs 347 are re-emulated in the same order. The replay game data 109' may also include time stamps associated with the game inputs 347 so that the recorded game inputs can be later played back in the same relative time sequence as the sequence in which they were recorded. By recording only the game inputs 347 and timestamps, fewer computer resources, such as memory and processing power, are required for generating a replay. The replay game data 109' is then delivered to the client device platform 103 at 280, and the client device platform receives the replay game data 109' from the emulator 107 at 281. The client device platform may then play a replay using the game data 109', as indicated at 283. FIG. 3D depicts the delivery of the replay request 358 and the resulting delivery of the replay game data 109'. As can be seen from the display unit 137, the legacy game 106 is taken back to the first state 301'. From the replayed first state 301', the replay game data 109' will advance the game from the first state 301' to the second state 302' by following the same sequence of events that occurred during the original course of play.

According to additional aspects of the present disclosure, the replay game data 109' may be played in slow-motion or in fast-forward. In order to control the speed of playback, the emulator 107 may have the emulation routine sped up or slowed down. By way of example, and not by way of limitation, it is possible to alter the speed of the replay, e.g., by throttling the emulation speed or accelerating the emulation to a speed that is faster than the original speed.

According to additional aspects of the present disclosure, the game inputs 347 may optionally be saved to a memory 132 on the client device platform 103. Thereafter, the replay may be recalled at any time in the future. Additionally, the saved game inputs 347 may be in a file format that is conducive to sharing between multiple client device platforms 103. Therefore, a replay may be viewed by multiple parties on multiple client device platforms 103. As shown in FIG. 5A, a set of client device platform instructions 570 may be implemented, e.g., by the client device platform 103. The client device platform instructions 570 may be formed on a nontransitory computer readable medium such as the memory 132 or the mass storage device 134. The client device platform instructions 570 may also be part of the process control program 133. The instructions 570 may include a first subset of instructions 572 that cause the client device to deliver legacy game input data 347 to the emulator, when executed . Thereafter the client device platform 103 may execute a second subset of instructions 575 that cause the client device platform to deliver a legacy game suspension request to the emulator 107, when executed. Next, the client device platform 103 may execute a third subset of instructions 578 to deliver a replay request 358 to the emulator 107. The client device platform may execute a fourth subset of instructions to receive the replay game data 109' from the emulator 107. Finally, the client device platform may execute a fifth subset of instructions 583 to play the replay using the game data 109' from the emulator 107. Specifically, the client device platform may use the game data 109' to generate the replay by disregarding inputs from a user, e.g., via a game controller, and instead sequentially implementing game actions in accordance with the recorded game inputs that are part of the game data 109' in the same manner that the client device would implement such inputs if they were received normally, e.g., from a game controller or other input device.

As shown in FIG. 5B, a set of emulator instructions 571 may be implemented, e.g., by the emulator 107. The emulation instructions 571 may be formed on a nontransitory computer readable medium such as the memory 132' or the mass storage device 134'. The emulator instructions 571 may also be part of the process control program 133'. The instructions include receiving the game inputs 347 from the client device platform 103 at 573. Thereafter the emulator 107 is instructed to begin emulating the selected legacy game 106 and recording the game inputs 347 at 574. While emulating the legacy game 106, the emulator 107 is provided with instructions for receiving a legacy game suspension request 357 from the client device platform 103 at 576. Then at 577, the emulator 107 is instructed to generate a snapshot 367. The emulator 107 is then instructed to receive a replay request 358 from the client device platform 103 at 579. Finally, the emulator 107 is instructed to deliver the replay game data 109' to the client device platform 103 at 580.

According to additional aspects of the present disclosure, the emulator 107 may also allow a legacy game 106 that has been suspended to be resumed. As shown in FIG. 2B, the emulator 107 may be configured to implement a method for resuming the emulation of a legacy game 106 according to an inventive method 201. Various aspects of the method 201 may be implemented by execution of computer executable instructions running on the client device platform 103 and/or the emulator 107 in conjunction with the actions of a client device platform 103. Specifically, a client device platform 103 may be configured, e.g., by suitable programming, to implement certain client device platform instructions 282. In addition, an emulator 107 may be configured to implement certain emulator instructions 283. In FIG. 2B the dashed arrows represent the flow of data between the client device platform 103 and the emulator 107 over the network 160. Initially at 284, the client device platform 103 delivers game inputs 347 to the emulator 107 over the network 160. By way of example, and not by way of limitation, game inputs 347 may be commands that instruct the emulator 107 where to begin in an emulation routine, or they may be commands that control the game play of a legacy game 106 that is being emulated by the emulator 107. By way of example, and not by way of limitation, a game input 347 that instructs the emulator 107 where to begin in an emulation routine may be in the form of a previously generated snapshot 367. By way of example, and not by way of limitation, game inputs 347 may be automatically generated by the client device platform 103, or they may be provided to the client device platform 103 by an external source. By way of example, the game inputs 347 may be delivered to the emulator 107 all at the same time, or they may be delivered over a period of time.

By way of example, and not by way of limitation, game inputs 347 which control the game play may include commands that are generally used by a game player to advance the legacy game 106 from a first state 301 to a second state 302. The first state 301 may be stored as a first snapshot, and the second state 302 may be the state of the game when a suspension request 357 is delivered to the emulator 107. The game inputs 347 may be inputted by a controller 145. Game inputs 347 of this nature may include, but are not limited to, inputs that cause a main character 340 in a legacy game 106 to move to a new position, swing a sword, select an item from a menu, or any other action that can take place during the game play of a legacy game 106. Additionally, while game inputs 347 advance the game play of the legacy game 106 from a first state 301 to a second state 302, there may also be one or more intermediate states generated. Each of the intermediate states may optionally be recorded as a snapshot 367. Additionally a suspension request 357 may be made at any intermediate state as well.

The emulator 107 receives the game inputs 347 at 285 and then proceeds to emulate the legacy game 106 in accordance with the game inputs 347 at 286. The emulation of the legacy game 106 causes the game to advance from a first state 301 to a second state 302. By way of example, and not by way of limitation, FIGs. 3 A and 3B are schematics of the emulation process according to certain aspects of the present disclosure. FIG. 3A depicts the client device platform 103 delivering game inputs 347 to emulator 107. While emulating the legacy game 106, the emulator 107 may deliver emulated game data 109 to the client device platform 103. The emulated game data 109 may contain data configured to display the progression of the game on the client device platform's 103 display unit 137. According to this example of the disclosure, the first state 301 consists of the main character 340 standing on the left side of a large trench.

Once the client device platform 103 has provided sufficient game inputs 347 to advance the emulated game to a second state 302, the client device platform 103 may deliver a suspension request 357 to the emulator 107 at step 287. By way of example, and not by way of limitation, the suspension request 357 may be automatically generated when there has been a lack of activity over a predetermined time period, a certain score is reached, or a

predetermined game event has occurred. FIG. 3B is an example of the client device platform 103 delivering the suspension request 357 to the emulator 107. In FIG. 3B, the second state 302 depicts the main character 340 standing just past the large trench. At 288, the emulator 107 may receive the suspension request 357. Upon receiving the suspension request, the emulator 107 may suspend the emulation of the legacy game 106 and generate a snapshot 367 of the second state 302 at 289. When the emulation of the legacy game 106 has been suspended, the game data 109 delivered to the client device platform 103 may provide a visual indication that the legacy game 106 has been suspended. By way of example, and not by way of limitation, the visual indication may be a pause screen or a menu as shown on the display unit 137 in FIG. 3C.

Next, at 290 the client device platform 103 may deliver a resume request 359 to the emulator 107. The emulator 107 receives the resume request at 291 and then loads the snapshot 367 of the second state 302 and resumes emulation from that point at 292. In order to increase the speed of loading the snapshot, the snapshot 367 may be pre-loaded. Pre-loading snapshots and other emulated game data is described in greater detail in commonly-assigned, copending application serial no. 13/631,785 , (Attorney Docket Number SCEA12010US00), filed the same day as the present application, and entitled "PRE-LOADING TRANSLATED CODE IN CLOUD BASED EMULATED APPLICATIONS". FIG. 3E depicts the delivery of the resume request 359 to the emulator 107. Once the snapshot 367 is loaded, game data 109 begins to be generated again as the emulator 107 resumes emulating the legacy game 106. The game data 109 in this example shows the game in the second state 302 again. From the second state 302, additional game inputs 347 may be delivered to the emulator 107 in order to advance the game to a new state. As shown in FIG. 6A, a set of client device platform instructions 682 may be implemented, e.g., by the client device platform 103. The client device platform instructions 670 may be formed on a nontransitory computer readable medium such as the memory 132 or the mass storage device 134. The client device platform instructions 670 may also be part of the process control program 133. The instructions include delivering legacy game input data 347 to the emulator at 684. Thereafter the client device platform 103 is instructed to deliver a legacy game suspension request to the emulator 107 at 687. Then, the client device platform 103 is instructed to deliver a resume request 359 to the emulator 107 at 690.

As shown in FIG. 6B, a set of emulator instructions 683 may be implemented, e.g., by the emulator 107. The emulation instructions 683 may be formed on a nontransitory computer readable medium such as the memory 132' or the mass storage device 134'. The emulator instructions 571 may also be part of the process control program 133'. The instructions include receiving the game inputs 347 from the client device platform 103 at 685. Thereafter the emulator 107 is instructed to begin emulating the selected legacy game 106 and recording the game inputs 347 at 686. While emulating the legacy game 106, the emulator 107 is provided with instructions for receiving a legacy game suspension request 357 from the client device platform 103 at 688. Then at 689, the emulator 107 is instructed to generate a snapshot 367. The emulator 107 is then instructed to receive a resume request 359 from the client device platform 103 at 691. Finally, the emulator 107 is instructed to load the snapshot 367 and resume the emulation of the legacy game 106 from that point at 692. According to aspects of the present disclosure, an emulator may be one of a plurality of virtual machines on a cloud based server. The emulator may be created by the server in response to demand for a given emulated application. Once the emulator has been generated by the server, the emulator may access an application that is to be emulated. The emulator may then begin translating the code of the application. The translated code may be stored in a cache. When a client device platform selects the application that has been emulated by the emulator, the emulator may deliver the translated application data to the client device platform over the network. According to aspects of the present disclosure, the emulated application may be a legacy game, a snapshot of a legacy game, an audio file, a video file, a mobile application, a desktop application or a web application.

According to additional aspects of the present disclosure, the emulator may be provided with a snapshot of a legacy game. The snapshot of the legacy game may have addresses of the stored data abstracted from the snapshot. This enables the snapshot to be platform independent. However, the emulator needs the addresses of the data in order to properly emulate the legacy game. Therefore, the addresses may be generated from platform independent information in the snapshot through an automated process. Once the addresses have been generated, the emulator may begin translating the code and storing emulated game data in a memory. Once the legacy game has been selected by a client device platform, the emulator may deliver the emulated data to the client device platform over a network.

According to additional aspects of the present disclosure, the prediction engine may direct the emulator as to which legacy game it should begin loading before a client device platform makes a selection for a game. By way of example, and not by way of limitation the prediction engine may use historical data, player profile information, trigger information from a game currently being played, or behavior patterns in order to determine which game should be pre-loaded by the emulator.

FIG. 7 is a schematic diagram illustrating a system containing components that can implement emulation in accordance with aspects of the present disclosure. An emulator 707 may be one of a plurality of emulators 707 on a cloud based server 704. An emulator 707 may be accessed by a client device platform 703 over a network 760. The client device platform 703 may access alternative emulators 707 over the network 760. The emulators 707 may be identical to each other, or they may each be programed to emulate unique legacy game titles 706 or unique sets of legacy game titles 706. The emulator 707 may be a virtual machine that can be built or deleted by a cloud based server 704. This enables the cloud based server 704 to meet the demand during times of peak usage without having to waste resources when usage is low.

The client device platform 703 may include a central processor unit (CPU) 731'. By way of example, a CPU 731' may include one or more processors, which may be configured according to any suitable processor architecture, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The client device platform 703 may also include a memory 732' (e.g., RAM, DRAM, ROM, and the like). The CPU 731' may execute a process-control program 733', portions of which may be stored in the memory 732'. The client device platform 703 may also include well-known support circuits 740', such as input/output (I/O) circuits 741', power supplies (P/S) 742', a clock (CLK) 743' and cache 744'. The client device platform 703 may optionally include a mass storage device 734' such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The client device platform 703 may also optionally include a display unit 737' and a user interface unit 738' to facilitate interaction between the client device platform 703 and a user. The display unit 737' may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit 738' may include a keyboard, mouse, joystick, light pen, or other device. A controller 745' may be connected to the client device platform 703 through the I/O circuit 741' or it may be directly integrated into the client device platform 703. The controller 745' may facilitate interaction between the client device platform 703 and a user. The controller 745' may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The controller 745' may also be capable of generating a haptic response 746'. By way of example and not by way of limitation, the haptic response 746' may be implemented in the form of mechanical vibrations or any other feedback corresponding to the sense of touch. The client device platform 703 may include a network interface 739', configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface 739' may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic

communications network 760. The network interface 739' may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform 703 may send and receive data and/or requests for files via one or more data packets over the network 760. The preceding components may exchange signals with each other via an internal system bus 750'. The client device platform 703 may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein. The emulator 707 may include a central processor unit (CPU) 731. By way of example, a CPU 731 may include one or more processors, which may be configured according to any suitable processor architecture, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The emulator 707 may also include a memory 732 (e.g., RAM, DRAM, ROM, and the like). The CPU 731 may execute a process-control program 733, portions of which may be stored in the memory 732. The emulator 707 may also include well-known support circuits 740, such as input/output (I/O) circuits 741, power supplies (P/S) 742, a clock (CLK) 743 and cache 744. The emulator 707 may optionally include a mass storage device 734 such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator 707 may also optionally include a display unit 737 and user interface unit 738 to facilitate interaction between the emulator 707 and a user who requires direct access to the emulator 707. By way of example and not by way of limitation an engineer may need direct access to the emulator 707 in order to program the emulator 707 to properly emulate a desired legacy game 706 or to add additional mini-game capabilities to a legacy game 706. The display unit 737 may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit 738 may include a keyboard, touchpad, touch screen, mouse, joystick, light pen, or other device. The emulator 707 may include a network interface 739, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface 739 may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network 760. The network interface 739 may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator 707 may send and receive data and/or requests for files via one or more data packets over the network 760. The preceding components may exchange signals with each other via an internal system bus 750. The emulator 707 may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein.

The emulator 707 may access a legacy game 706 through the internal system bus 750. There may be more than one legacy game 706 stored in the emulator. The legacy games may also be stored in the memory 732 or in the mass storage device 734. Additionally, one or more legacy games 706 may be stored at a remote location accessible to the emulator 707 over the network 760. Each legacy game 706 contains game code 708. When the legacy game 706 is emulated, the game code 708 produces legacy game data 709. Legacy game data 709 may be received by the client device platform 703 and displayed on the display unit 737'. By way of example, a legacy game 706 may be any game that is not compatible with a client device platform 703. By way of example and not by way of limitation, the legacy game 706 may have been designed to be played on Sony Computer Entertainment's PlayStation console, but the client device platform 703 is a home computer. By way of example, the legacy game 706 may have been designed to be played on a PlayStation 2 console, but the client device platform 703 is a PlayStation 3 console. Further, by way of example and not by way of limitation, a legacy game 706 may have been designed to be played on a PlayStation console, but the client device platform 703 is a hand held console such as the PlayStation Portable (PSP) or Vita from Sony Computer Entertainment.

In some implementations, but not all, the emulator 707 may be a deterministic emulator. A deterministic emulator is an emulator that may process a given set of game inputs the same way every time that the same set of inputs are provided to the emulator 707. Game inputs may be signals sent by the client device platform 703 to the emulator 707 in order to advance the emulated game from a first state to a second state. By way of example, the game inputs may be directions for the main character of a game to move on the screen, a selection of an item from a menu in the game or any other action that may take place during the playing of the game. An emulator 707 may be made deterministic by eliminating any dependencies in the code run by the emulator 707 that depend from asynchronous activity. Asynchronous activities are events that occur independently of the main program flow. This means that actions may be executed in a non-blocking scheme in order to allow the main program flow to continue processing. Therefore, by way of example, and not by way of limitation, the emulator 707 may be deterministic when the dependencies in the code 708 depend from basic blocks that always begin and end with synchronous activity. By way of example, basic blocks may be predetermined increments of code at which the emulator 707 checks for external events or additional game inputs. The emulator 707 may also wait for any activities that run asynchronously within a system component to complete before proceeding to the next basic block. When no asynchronous activities are running, the emulator 707 may be thought of as running all of the basic blocks of the code 708 in lock step. In such a case, the emulator 707 is sometimes said to be in a "steady state".

As shown in FIG. 8A, the emulator 707 may be configured to implement a method for preloading a legacy game 706 according to an inventive method 860. Various aspects of the method 860 may be implemented by execution of computer executable instructions running on the emulator 707 in conjunction with the actions client device platform 703. Specifically, an emulator 707 may be configured, e.g., by suitable programming, to implement certain emulator instructions 870.

According to a first aspect of the present disclosure the emulator 707 may begin method 860 by deciding which legacy game 706 will be pre-loaded at 861. This selection is made before a client device platform makes a request for a legacy game 706. By selecting a game to preload before the request is made by the client device platform 703, the game will be ready to play without a delay due to the loading. The selection process may be implemented by a prediction engine 747. The prediction engine 747 may be a process control program 733 stored in a memory 732 on the emulator 707 or on a mass storage 734. Alternatively, the prediction engine 747 may be located in a memory on the cloud based server 704.

According to aspects of the present disclosure, the prediction engine 747 may use historical data to choose which game will be pre-loaded. By way of example, the historical data may be information of how often a legacy game 706 is requested by all of the users accessing the cloud based server 704. This information may be further defined by the date and time. This information may show that there are patterns of usage based on the day of the week and/or the time of the day. For example, based on historical data, on Monday through Friday during the fall, there may be a historically observed spike in usage and requests for a particular first person shooting game at around 4:00 P.M. In order to have sufficient instances of the first person shooting game loaded when a client device platform 703 requests this specific legacy game 706, the emulator may choose the first person shooting legacy game 706 to pre-load. According to additional aspects of the present disclosure, the prediction engine 747 may track the navigation of a client device platform on the cloud based server 704 in order to choose which legacy game 706 will be pre-loaded. By way of example, and not by way of limitation, the client device platform 703 may access a legacy game selection menu 1000. The game selection menu 1000 may be displayed on the display 737' of the client device platform. FIG. 10 is a diagram of the menu 1000 as seen on the display 737'. Once the client device platform 703 accesses the menu 1000, the emulator may begin pre-loading one of the legacy games A - F. Further, the emulator may track a cursor 1048 in order to more accurately predict which of the legacy games will be requested by the client device platform 703. By way of example, if the cursor 1048 is hovering over legacy game B, for a predetermined time, then the emulator may select legacy game B to pre-load. The navigation of the client device platform may also be tracked by alternative indicators. By way of example and not by way of limitation, eye tracking may be used to detect which game a user of the client device platform may be focusing on in order to make a selection of a game to pre-load.

According to addition aspects of the present disclosure, the prediction engine 747 may use a user profile corresponding to the client device platform 703 in order to choose which legacy game 706 will be pre-loaded. A user profile may track the usage history of a client device platform 103. By way of example, and not by way of limitation usage history may include which legacy games 706 the client device platform 703 has requested and how many times each legacy game 706 has been requested. The usage history may also track usage patterns for an individual client device platform based on the time of day and/or the day of the week. Through analyzing this information in the user profile, the prediction engine may more accurately select which legacy game 706 the client device platform 703 will request next. According to additional aspects of the present disclosure, the prediction engine 747 may use triggers within a legacy game 706 that is currently being played by a client device platform 703 in order to choose which legacy game 706 should be pre-loaded. Triggers are further described in commonly assigned co-pending application serial no. 61/666,628 (Attorney Docket Number SCEA12004US00) filed June 29, 2012, and entitled "DETERMESflNG TRIGGERS FOR CLOUD-BASED EMULATED GAMES". By way of example, and not by way of limitation, triggers that may be used by the prediction engine could be a score, a time remaining in the game, or finishing a predetermined portion of a game. A score may be used by the prediction engine as an indication of the performance of the client device platform 703. If the score is above a certain value, then the client device platform 703 may be a skilled player, and may be more likely to request a similar game 706 that has a higher degree of difficulty next. In the alternative, if the score is below a certain value, then the client device platform 703 may be a novice player, and therefore may be more likely to request a legacy game 706 which has a lower degree of difficulty next. The time remaining in the game may be used by the prediction engine to indicate that a new legacy game 106 may be requested soon. When the client device platform 703 finishes a predetermined portion of the game, the prediction engine may determine that the next legacy game 106 in a series of legacy games 706 will be requested next, and therefore the emulator may begin pre-loading the next legacy game 706 in the series.

It should be noted that any of the previously stated types of information, or any other type of information may be used in combination or singularly by the prediction engine 747 in order to determine which legacy game 706 should be pre-loaded. Additionally, more than one legacy game may be pre-loaded in order to increase the probability that the legacy game 706 eventually requested by the client device platform 103 has been pre-loaded by the emulator 707.

Once the snapshot has been selected by the prediction engine 747, the emulator 707 may retrieve the legacy game 706 at 862. The legacy game 706 may be stored on a memory external to the emulator 707, but accessible over the network 760. By way of example, and not by way of limitation, the legacy game 706 may be stored on a memory on the cloud based server 704. Alternatively, the legacy game 706 may already be stored on a memory within the emulator 707 such as the mass storage 734 and therefore may be accessed over the internal system bus 750. After the legacy game 706 has been retrieved by the emulator 707, method 860 continues with the emulator 707 beginning the translation of the legacy game data at 863. The translation of the legacy game data is an emulation of the legacy game 706 which allows the legacy game 706 to be translated into a format that is compatible with the client device platform 703. The translation of the game may be ended once the game is at a starting position. The starting position may be an initial game menu, or it may be where the game play begins. The translated legacy game data is then stored in a memory 732 on the emulator at 864. The memory may be a cache memory in order to increase the speed of delivery once the game is requested. Finally at 865, the translated legacy game data is delivered to the client device platform 703 over the network 760 when the client device platform 703 makes a request for the legacy game 706.

As shown in FIG. 8B, a set of emulator instructions 870 may be implemented, e.g., by the emulator 707. The emulation instructions 870 may be formed on a nontransitory computer readable medium such as the memory 732 or the mass storage device 734. The emulator instructions 870 may also be part of the process control program 733. The instructions include choosing a legacy game 706 to pre-load at 871. Thereafter, the instructions include retrieving the legacy game 706 at 872. Next, the emulator 707 is provided with instructions for translating the legacy game data into a format that is compatible with the client device platform at 873. Once the legacy game data has been translated, the emulator instruction 870 may include storing the translated legacy game data in a memory at 874. Finally, at 875 the instructions may include delivering the translated legacy game data over the network to the client device platform 703 after the request for the legacy game 706 has been made by the client device platform 703.

FIG. 9A is a bock diagram of a method 960 in accordance with an additional aspect of the present disclosure. This additional aspect of the present disclosure describes how a snapshot may be pre-loaded by an emulator 707. Snapshots are platform-independent recordings of the state of the emulator 707 at a point during emulation of a legacy game 706. Snapshots may contain platform-dependent information that can be useful but not essential for restoring the state of the emulation. For example, a snapshot may include a number of graphics processor plug-ins, such as a texture cache, that may be ignored. Snapshots are further described in commonly assigned co-pending application serial no. 61/666,679, (Attorney Docket Number SCEA12007US00) filed June 29, 2012, and entitled "SUSPENDING STATE OF CLOUD-BASED LEGACY APPLICATIONS". Snapshots may be used when the game being loaded is a mini-game. Mini-games are short portions of a game that might not begin at the designated starting position of the legacy game 106 as originally designed. Mini-games are further described in commonly-assigned, co-pending application serial no. 13/631,740 , (Attorney Docket Number SCEA12009US00), filed September 28, 2012, and entitled "METHOD FOR CREATING A MINI-GAME".

As shown in FIG. 9A, the emulator 707 may be configured to implement a method for preloading a snapshot according to an inventive method 960. Various aspects of the method 960 may be implemented by execution of computer executable instructions running on the emulator 707 in conjunction with the actions of the client device platform 703. Specifically, an emulator 707 may be configured, e.g., by suitable programming, to implement certain emulator instructions 970. According to an aspect of the present disclosure, the emulator 707 may begin method 860 by determining which snapshot will be pre-loaded at 861. This selection is made before a client device platform 703 makes a request for a snapshot to be loaded. By selecting a snapshot to pre-load before the request is made by the client device platform 703, the snapshot will be ready to play without a delay. The process of pre-loading a snapshot is important for preventing a delay in the gaming experience for the user because snapshots may not begin at the original starting position of the legacy game 706 they are generated from. Since the snapshot initiates the play of the game from an intermediate position of the legacy game 706, incremental buffering may not be available. Without incremental buffering the loading of the snapshot may require additional loading time to because a larger buffer is needed to initiate the game play, as opposed to the smaller buffer when incremental buffering is available.

The selection process may be implemented by a prediction engine 747. The prediction engine 747 may be a process control program 733 stored in a memory 732 on the emulator 707 or on a mass storage 734. The prediction engine 747 may be similar to that of the prediction engine described above for use with loading a legacy game 706 from its original starting position. As such, in order to predict which snapshot will be chosen next by the client device platform 703, the prediction engine 747 may use historical data, track the navigation of a client device platform on the cloud based server 704, utilize a user profile corresponding to the client device platform 703, or use triggers within a legacy game 706 that is currently being played by a client device platform 703. It should be noted that each of the previously stated types of information or any other type of information may be used in combination or singularly by the prediction engine 747 in order to determine which snapshot should be pre-loaded. Additionally, more than one snapshot may be pre-loaded in order to increase the probability that the snapshot eventually chosen by the client device platform 703 has been pre-loaded by the emulator 707. Once the snapshot has been selected by the prediction engine 747, the emulator 707 may retrieve the snapshot at 962. The snapshot may be stored on a memory external to the emulator 707, but accessible over the network 760. By way of example, and not by way of limitation, the snapshot may be stored on a memory on the cloud based server 704.

Alternatively, the snapshot may already be stored on a memory within the emulator 707 such as the mass storage 734 and therefore may be accessed over the internal system bus 750. Once the snapshot has been retrieved, the emulator 707 may generate the platform dependent addresses for the specific instance of the emulator 707 at 964. According to some aspects of the present disclosure the address space for every instance of an emulator 707 may be randomized for security purposes through address space layout randomization (ASLR). Therefore, the emulator's address space may be abstracted from the snapshot in order for a snapshot to be platform independent. As such, in order to pre-load a snapshot, the address space information for the specific instance of the emulator 707 that is loading the snapshot may need to be generated. The specific address information may be generated from the platform independent information within the snapshot with an automated script. Additional information may be added to a translated code cache that marks dependent addresses for code and/or data. By way of example, and not by way of limitation, when a device loads the snapshot, markers in the code cache may be used to relocate code and/or data to reflect the changed emulating system's memory map.

After the address information is generated, the emulator 707 may begin translating the legacy game data at 964 in order to build a buffer. The translation of the legacy game data is an emulation of the legacy game 706 which allows the legacy game 706 to be in a format that is compatible with the client device platform 703. The snapshot provides the starting position of the legacy game 706, and instructs every device running on the emulator 707 what state it should be in for the legacy game 706 to be executed properly from that point. However, since the snapshot starting point may not be the original starting position of the legacy game 706, a buffer may also be needed since there might not be incremental buffering at that position of the legacy game 706. The translation of the legacy game data may be ended once the game is at the snapshot starting position and a sufficient buffer has been built to run the game properly from that position. Thereafter, the translated buffered data is stored in a memory 732 on the emulator 707 at 965. The memory may be a cache memory in order to increase the speed of delivery once the snapshot is requested by the client device platform

703. Finally at 966, the translated legacy game data is delivered to the client device platform 703 over the network 760 when the client device platform 703 makes a request for the snapshot.

As shown in FIG. 9B, a set of emulator instructions 970 may be implemented, e.g., by the emulator 707. The emulation instructions 970 may be formed on a nontransitory computer readable medium such as the memory 732 or the mass storage device 734. The emulator instructions 970 may also be part of the process control program 733. The instructions include choosing a snapshot to pre-load at 971. Next, the emulator 707 is provided with instructions for retrieving the snapshot at 972. Thereafter, the instructions include generating the platform dependent addresses that allow the emulator 707 to process the snapshot at 973. Then at 974, the instructions include building a buffer by translating the legacy game data into a format that is compatible with the client device platform at 974. Once the legacy game data has been translated, the emulator instruction 970 may include storing the translated legacy game data in a memory at 975. Finally, the instructions may include delivering the translated legacy game data over the network 760 to the client device platform 703 after the request for the game has been made by the client device platform 703 at 976.

While the above is a complete description of the preferred embodiment of the present invention, it is possible to use various alternatives, modifications and equivalents. Therefore, the scope of the present invention should be determined not with reference to the above description but should, instead, be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. In the claims that follow, the indefinite article "A", or "An" refers to a quantity of one or more of the item following the article, except where expressly stated otherwise. The appended claims are not to be interpreted as including means-plus-function limitations, unless such a limitation is explicitly recited in a given claim using the phrase "means for."

Claims

WHAT IS CLAIMED IS:

1. A nontransitory computer readable medium containing program instructions for

generating a replay of an emulated game, and wherein execution of the program instructions by one or more processors of a computer system causes the one or more processors to carry out the steps of:

a) receiving one or more game inputs from a client device platform over the network, wherein the one or more game inputs advance an emulated game from a first state to a second state;

b) recording the one or more game inputs;

c) emulating the emulated game such that the emulated game is advanced to the second state;

d) receiving a suspension request from the client device platform over the network and suspending emulation of the emulated game;

e) receiving a replay request from the client device platform over the network;

f) generating a replay by re-emulating the emulated game with the one or more recorded game inputs; and

g) delivering the replay to the client device platform over the network.

2. The non-transitory computer readable medium of claim 1 , wherein the emulator is a deterministic emulator.

3. The non-transitory computer readable medium of claim 2, wherein the emulator uses basic blocks to emulate the game.

4. The non-transitory computer readable medium of claim 1 , wherein the replay request is received at the same time as the suspension request.

5. The non-transitory computer readable medium of claim 1 , wherein after receiving the suspension request from the client device platform, the method further comprises generating a snapshot of the emulated game, wherein the snapshot is a recording of a state of one or more devices being emulated by the emulator, and wherein each of the one or more devices is in a steady state.

6. The non-transitory computer readable medium of claim 5, wherein the one or more

devices are in the steady state when there are no outstanding disk requests.

7. The non-transitory computer readable medium of claim 5, wherein the one or more devices are in the steady state when there is no asynchronous activity.

8. The non-transitory computer readable medium of claim 1 , wherein the suspension request is received before the emulator has advanced the emulated game to the second state.

9. The non-transitory computer readable medium of claim 1 , wherein the replay is

configured to be displayed in fast-forward.

10. The non-transitory computer readable medium of claim 1 , wherein the replay is

configured to be displayed in slow motion.

1 1. The non-transitory computer readable medium of claim 1 , wherein the replay is

configured to be displayed at variable speeds.

12. The non-transitory computer readable medium of claim 1 , wherein the one or more game inputs are received over a period of time.

13. In an emulator configured to operate on a network, a method for generating a replay of an emulated game, comprising:

b) recording the one or more game inputs;

e) receiving a replay request from the client device platform over the network;

g) delivering the replay to the client device platform over the network.

14. An emulator configured to operate on a network, comprising:

a processor;

a memory coupled to the processor; one or more instructions embodied in memory for execution by the processor, the instructions being configured to generate a replay of an emulated game, the method comprising:

b) recording the one or more game inputs;

e) receiving a replay request from the client device platform over the network;

g) delivering the replay to the client device platform over the network.

15. A non-transitory computer readable medium containing program instructions for

a) delivering one or more game inputs to an emulator over a network, wherein the game inputs are configured to advance an emulated game from a first state to a second state; b) delivering a suspension request to the emulator over the network;

c) delivering a replay request to the emulator over the network; and

d) receiving a replay of the emulated game from the emulator, wherein the replay includes one or more recorded game inputs; and

e) presenting the replay of the emulated game with the client device using the one or more recorded game inputs.

16. The non-transitory computer readable medium of claim 15, wherein the suspension

request is delivered to the emulator before the emulator has advanced the emulated game to the second state.

17. The non-transitory computer readable medium of claim 15, wherein the one or more game inputs are automatically generated.

18. The non-transitory computer readable medium of claim 15, wherein the one or more game inputs are delivered over a period of time.

19. The non-transitory computer readable medium of claim 15, wherein the suspension

request and the replay request are delivered at the same time.

20. The non-transitory computer readable medium of claim 15, wherein the replay is

configured to be displayed in fast-forward.

21. The non-transitory computer readable medium of claim 15, wherein the replay is

configured to be displayed in slow motion.

22. The non-transitory computer readable medium of claim 15, wherein the replay is

configured to be displayed at variable speeds.

23. In a client device platform configured to operate on a network, a method for generating a replay of an emulated game, comprising:

c) delivering a replay request to the emulator over the network;

24. A client device platform configured to operate on a network, comprising:

a processor;

a memory coupled to the processor;

one or more instructions embodied in memory for execution by the processor, the instructions being configured to generate a replay of an emulated game, the method comprising:

c) delivering a replay request to the emulator over the network; and d) receiving a replay of the emulated game from the emulator, wherein the replay includes one or more recorded game inputs; and

25. A non-transitory computer readable medium containing program instructions for a

suspending and resuming an emulated game, and wherein execution of the program instructions by one or more processors of a computer system causes the one or more processors to carry out the steps of:

b) emulating the emulated game such that the emulated game is advanced to the second state;

c) receiving a suspension request from the client device platform over the network;

d) generating a snapshot of the emulated game, wherein the snapshot is a recording of a state of one or more devices being emulated by the emulator, and wherein each of the one or more devices is in a steady state;

e) receiving a resume request from the client device platform over the network;

f) loading the snapshot, and resuming the emulation of the game.

26. The non-transitory computer readable medium of claim25, wherein the emulator is a deterministic emulator.

27. The non-transitory computer readable medium of claim 26, wherein the emulator uses basic blocks to emulate the game.

28. The non-transitory computer readable medium of claim 25, wherein the one or more devices are in the steady state when there are no outstanding disk requests.

29. The non-transitory computer readable medium of claim 25, wherein the one or more devices are in the steady state when there is no asynchronous activity.

30. The non-transitory computer readable medium of claim 25, wherein the suspension

request is received before the emulator has advanced the emulated game to the second state.

31. The non-transitory computer readable medium of claim 25, wherein the one or more game inputs are received over a period of time.

32. The non-transitory computer readable medium of claim 25, wherein the snapshot is loaded before the resume request is received.

33. In an emulator configured to operate on a network, a method for suspending and

resuming an emulated game, comprising:

c) receiving a suspension request from the client device platform over the network; d) generating a snapshot of the emulated game, wherein the snapshot is a recording of a state of one or more devices being emulated by the emulator, and wherein each of the one or more devices is in a steady state;

e) receiving a resume request from the client device platform over the network;

f) loading the snapshot, and resuming the emulation of the game.

34. An emulator configured to operate on a network, comprising:

a processor;

a memory coupled to the processor;

one or more instructions embodied in memory for execution by the processor, the instructions being configured to suspend and resume an emulated game, the method comprising:

c) receiving a suspension request from the client device platform over the network; d) generating a snapshot of the emulated game, wherein the snapshot is a recording of a state of one or more devices being emulated by the emulator, and wherein each of the one or more devices is in a steady state; e) receiving a resume request from the client device platform over the network;

f) loading the snapshot, and resuming the emulation of the game.

35. In a client device platform configured to operate on a network, a method for suspending and resuming an emulated game, comprising:

a) delivering one or more game inputs to an emulator over a network, wherein the game inputs are configured to advance an emulated game from a first state to a second state; b) delivering a suspension request to the emulator over the network; and

c) delivering a resume request to the emulator over the network.

36. A nontransitory computer readable medium containing program instructions for pre- loading an emulated application, and wherein execution of the program instructions by one or more processors of a computer system causes the one or more processors to carry out the steps of:

a) choosing an application to pre-load;

b) retrieving pre-translated code for the application chosen to be pre-loaded;

c) translating data from the application into a format that is compatible with the client device platform;

d) storing the translated data in a memory; and

e) delivering the translated data to the client device platform over the network after the request for the application is made by the client device platform.

37. The nontransitory computer readable medium of claim 36, wherein the application is a legacy game.

38. The nontransitory computer readable medium of claim 36, wherein the application is a snapshot of a legacy game.

39. The nontransitory computer readable medium of claim 38, further comprising generating emulator specific address information for the snapshot before the snapshot is translated into a format that is compatible with the client device platform.

40. The nontransitory computer readable medium of claim 39, further comprising building a buffer after the snapshot by translating additional data from the legacy game.

41. The nontransitory computer readable medium of claim 36, wherein the memory is a cache.

42. The nontransitory computer readable medium of claim 36, wherein the pre-translated coded is loaded before a request for the application is made by a client device platform.

43. The nontransitory computer readable medium of claim 36, wherein the choosing of which application to pre-load is determined by a prediction engine.

44. The nontransitory computer readable medium of claim 43, wherein the prediction engine uses historical data of the number of client device platforms that have made a request for the application in order to choose which application to pre-load.

45. The nontransitory computer readable medium of claim 44, wherein the historical data further includes a time and date with each request for the application.

46. The nontransitory computer readable medium of claim 43, wherein the prediction engine uses data from a user profile associated with a client device platform that is searching for an application in order to choose which application to pre-load.

47. The nontransitory computer readable medium of claim 43, wherein the prediction engine uses triggers from a second application that is being played by the client device platform in order to choose which application to pre-load.

48. The nontransitory computer readable medium of claim 43, wherein the prediction engine tracks the client device platform as it navigates an application selection menu in order to choose which application to pre-load.

49. The nontransitory computer readable medium of claim 48, wherein the prediction engine follows a cursor controlled by the client device platform in order to track the navigation.

50. The nontransitory computer readable medium of claim 48, wherein the prediction engine follows one or more eyes belonging to a user controlling the client device platform in order to track the navigation.

51. An emulator configured to operate on a network, comprising:

a processor;

a memory coupled to the processor; one or more instructions embodied in memory for execution by the processor, the instructions being configured to pre-load an emulated application, the method comprising:

a) choosing an application to pre-load;

b) retrieving pre-translated code for the application chosen to be pre-loaded;

d) storing the translated data in a memory; and

52. The emulator of claim 51, wherein the application is a legacy game.

53. The emulator of claim 51, wherein the application is a snapshot of a legacy game.

54. The emulator of claim 53, further comprising generating emulator specific address

information for the snapshot before the snapshot is translated into a format that is compatible with the client device platform.

55. The emulator of claim 54, further comprising building a buffer after the snapshot by translating additional data from the legacy game.

56. The emulator of claim 51, wherein the memory is a cache.

57. The emulator of claim 51, wherein the pre-translated coded is loaded before a request for the application is made by a client device platform.

58. The emulator of claim 51, wherein the choosing of which application to pre-load is determined by a prediction engine.

59. The emulator of claim 58, wherein the prediction engine uses historical data of the

number of client device platforms that have made a request for the application in order to choose which application to pre-load.

60. The emulator of claim 59, wherein the historical data further includes a time and date with each request for the application.

61. The emulator of claim 58, wherein the prediction engine uses data from a user profile associated with a client device platform that is searching for an application in order to choose which application to pre-load.

62. The emulator of claim 58, wherein the prediction engine uses triggers from a second application that is being played by the client device platform in order to choose which application to pre-load.

63. The emulator of claim 58, wherein the prediction engine tracks the client device platform as it navigates an application selection menu in order to choose which application to pre- load.

64. The emulator of claim 63, wherein the prediction engine follows a cursor controlled by the client device platform in order to track the navigation.

65. The emulator of claim 63, wherein the prediction engine follows one or more eyes

belonging to a user controlling the client device platform in order to track the navigation.

66. In an emulator configured to operate on a network, a method for preloading an emulated application, comprising: a) choosing an application to pre-load;

b) retrieving pre-translated code for the application chosen to be pre-loaded;

d) storing the translated data in a memory; and