U.S. Pat. No. 10,293,251

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, 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. 1is a schematic diagram illustrating a system containing components that can implement emulation in accordance with aspects of the present disclosure. An emulator107may be one of a plurality of emulators107on a cloud based server104. An emulator107may be accessed by a client device platform103over a network160. The client device platform103may access alternative emulators107over the network160. The emulators107may be identical to each other, or they may each be programmed to emulate unique legacy game titles106or unique sets of legacy game titles106. The emulator107may be a virtual machine that can be built or deleted by a cloud based server104. This enables the cloud based server104to meet the demand during times of peak usage without having to waste resources when usage is low.

The client device platform103may include a central processor unit (CPU)131′. By way of example, a CPU131′ 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 platform103may also include a memory132′ (e.g., RAM, DRAM, ROM, and the like). The CPU131′ may execute a process-control program133′, portions of which may be stored in the memory132′. The client device platform103may also include well-known support circuits140′, such as input/output (I/O) circuits141′, power supplies (P/S)142′, a clock (CLK)143′ and cache144′. The client device platform103may optionally include a mass storage device134′ such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The client device platform103may also optionally include a display unit137′ and a user interface unit138′ to facilitate interaction between the client device platform103and a user. The display unit137′ 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 unit138′ may include a keyboard, mouse, joystick, light pen, or other device. A controller145′ may be connected to the client device platform103through the I/O circuit141′ or it may be directly integrated into the client device platform103. The controller145′ may facilitate interaction between the client device platform103and a user. The controller145′ may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The controller145′ may also be capable of generating a haptic response146′. By way of example and not by way of limitation, the haptic response146′ may be implemented in the form of mechanical vibrations or any other feedback corresponding to the sense of touch. The client device platform103may include a network interface139′, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139′ may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network160. The network interface139′ may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform103may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150′. The client device platform103may 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 emulator107may include a central processor unit (CPU)131. By way of example, a CPU131may 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 emulator107may also include a memory132(e.g., RAM, DRAM, ROM, and the like). The CPU131may execute a process-control program133, portions of which may be stored in the memory132. The emulator107may also include well-known support circuits140, such as input/output (I/O) circuits141, power supplies (P/S)142, a clock (CLK)143and cache144. The emulator107may optionally include a mass storage device134such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator107may also optionally include a display unit137and user interface unit138to facilitate interaction between the emulator107and a user who requires direct access to the emulator107. By way of example and not by way of limitation an engineer may need direct access to the emulator107in order to program the emulator107to properly emulate a desired legacy game106or to add additional mini-game capabilities to a legacy game106. The display unit137may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit138may include a keyboard, touchpad, touch screen, mouse, joystick, light pen, or other device. The emulator107may include a network interface139, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network160. The network interface139may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator107may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150. The emulator107may 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 emulator107may access a legacy game106through the internal system bus150. There may be more than one legacy game106stored in the emulator. The legacy games may also be stored in the memory132or in the mass storage device134. Additionally, one or more legacy games106may be stored at a remote location accessible to the emulator107over the network160. Each legacy game106contains game code108. When the legacy game106is emulated, the game code108produces legacy game data109. Legacy game data109may be received by the client device platform103and displayed on the display unit137′.

By way of example, a legacy game106may be any game that is not compatible with a client device platform103. By way of example and not by way of limitation, the legacy game106may have been designed to be played on Sony Computer Entertainment's PlayStation console, but the client device platform103is a home computer. By way of example, the legacy game106may have been designed to be played on a PlayStation 2 console, but the client device platform103is a PlayStation 3 console. Further, by way of example and not by way of limitation, a legacy game106may have been designed to be played on a PlayStation console, but the client device platform103is a hand held console such as the PlayStation Portable (PSP) or Vita from Sony Computer Entertainment.

In some implementations, but not all, the emulator107may 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 emulator107. Game inputs may be signals sent by the client device platform103to the emulator107in 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 emulator107may be made deterministic by eliminating any dependencies in the code run by the emulator107that 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 emulator107may be deterministic when the dependencies in the code108depend 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 emulator107checks for external events or additional game inputs347. The emulator107may 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 emulator107may be thought of as running all of the basic blocks of the code108in lock step. In such a case, the emulator107is sometimes said to be in a “steady state”.

As shown inFIG. 2A, the emulator107may be configured to implement a method for pre-loading a legacy game106according to an inventive method260. Various aspects of the method260may be implemented by execution of computer executable instructions running on the emulator107in conjunction with the actions client device platform103. Specifically, an emulator107may be configured, e.g., by suitable programming, to implement certain emulator instructions270.

According to a first aspect of the present disclosure the emulator107may begin method260by deciding which legacy game106will be pre-loaded at261. This selection is made before a client device platform makes a request for a legacy game106. By selecting a game to pre-load before the request is made by the client device platform103, the game will be ready to play without a delay due to the loading. The selection process may be implemented by a prediction engine147. The prediction engine147may be a process control program133stored in a memory132on the emulator107or on a mass storage134. Alternatively, the prediction engine147may be located in a memory on the cloud based server104.

According to aspects of the present disclosure, the prediction engine147may 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 game106is requested by all of the users accessing the cloud based server104. 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 platform103requests this specific legacy game106, the emulator may choose the first person shooting legacy game106to pre-load.

According to additional aspects of the present disclosure, the prediction engine147may track the navigation of a client device platform on the cloud based server104in order to choose which legacy game106will be pre-loaded. By way of example, and not by way of limitation, the client device platform103may access a legacy game selection menu400. The game selection menu400may be displayed on the display137′ of the client device platform.FIG. 4is a diagram of the menu400as seen on the display137′. Once the client device platform103accesses the menu400, the emulator may begin pre-loading one of the legacy games A-F. Further, the emulator may track a cursor448in order to more accurately predict which of the legacy games will be requested by the client device platform103. By way of example, if the cursor445is 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 engine147may use a user profile corresponding to the client device platform103in order to choose which legacy game106will be pre-loaded. A user profile may track the usage history of a client device platform103. By way of example, and not by way of limitation usage history may include which legacy games106the client device platform103has requested and how many times each legacy game106has 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 game106the client device platform103will request next.

According to additional aspects of the present disclosure, the prediction engine147may use triggers within a legacy game106that is currently being played by a client device platform103in order to choose which legacy game106should be pre-loaded. Triggers are further described in commonly assigned application Ser. No. 61/666,628 filed Jun. 29, 2012, and entitled “DETERMINING 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 platform103. If the score is above a certain value, then the client device platform103may be a skilled player, and may be more likely to request a similar game106that has a higher degree of difficulty next. In the alternative, if the score is below a certain value, then the client device platform103may be a novice player, and therefore may be more likely to request a legacy game106which 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 game106may be requested soon. When the client device platform103finishes a predetermined portion of the game, the prediction engine may determine that the next legacy game106in a series of legacy games106will be requested next, and therefore the emulator may begin pre-loading the next legacy game106in 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 engine147in order to determine which legacy game106should be pre-loaded. Additionally, more than one legacy game may be pre-loaded in order to increase the probability that the legacy game106eventually requested by the client device platform103has been pre-loaded by the emulator107.

Once the snapshot has been selected by the prediction engine147, the emulator107may retrieve the legacy game106at262. The legacy game106may be stored on a memory external to the emulator107, but accessible over the network160. By way of example, and not by way of limitation, the legacy game106may be stored on a memory on the cloud based server104. Alternatively, the legacy game106may already be stored on a memory within the emulator107such as the mass storage134and therefore may be accessed over the internal system bus150.

After the legacy game106has been retrieved by the emulator107, method260continues with the emulator107beginning the translation of the legacy game data at263. The translation of the legacy game data is an emulation of the legacy game106which allows the legacy game106to be translated into a format that is compatible with the client device platform103. 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 memory132on the emulator at264. The memory may be a cache memory in order to increase the speed of delivery once the game is requested. Finally at265, the translated legacy game data is delivered to the client device platform103over the network160when the client device platform103makes a request for the legacy game106.

As shown inFIG. 2B, a set of emulator instructions270may be implemented, e.g., by the emulator107. The emulation instructions270may be formed on a nontransitory computer readable medium such as the memory132or the mass storage device134. The emulator instructions270may also be part of the process control program133. The instructions include choosing a legacy game106to pre-load at271. Thereafter, the instructions include retrieving the legacy game106at272. Next, the emulator107is provided with instructions for translating the legacy game data into a format that is compatible with the client device platform at273. Once the legacy game data has been translated, the emulator instruction270may include storing the translated legacy game data in a memory at274. Finally, at275the instructions may include delivering the translated legacy game data over the network to the client device platform103after the request for the legacy game106has been made by the client device platform103.

FIG. 3Ais a bock diagram of a method360in 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 emulator107. Snapshots are platform-independent recordings of the state of the emulator107at a point during emulation of a legacy game106. 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 application Ser. No. 61/666,679, filed Jun. 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 game106as originally designed. Mini-games are further described in commonly-assigned, application Ser. No. 13/631,740, filed the same day as the present application, and entitled “METHOD FOR CREATING A MINI-GAME”.

As shown inFIG. 3A, the emulator107may be configured to implement a method for pre-loading a snapshot according to an inventive method360. Various aspects of the method360may be implemented by execution of computer executable instructions running on the emulator107in conjunction with the actions of the client device platform103. Specifically, an emulator107may be configured, e.g., by suitable programming, to implement certain emulator instructions370.

According to an aspect of the present disclosure, the emulator107may begin method260by determining which snapshot will be pre-loaded at261. This selection is made before a client device platform103makes a request for a snapshot to be loaded. By selecting a snapshot to pre-load before the request is made by the client device platform103, 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 game106they are generated from. Since the snapshot initiates the play of the game from an intermediate position of the legacy game106, 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 engine147. The prediction engine147may be a process control program133stored in a memory132on the emulator107or on a mass storage134. The prediction engine147may be similar to that of the prediction engine described above for use with loading a legacy game106from its original starting position. As such, in order to predict which snapshot will be chosen next by the client device platform103, the prediction engine147may use historical data, track the navigation of a client device platform on the cloud based server104, utilize a user profile corresponding to the client device platform103, or use triggers within a legacy game106that is currently being played by a client device platform103.

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 engine147in 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 platform103has been pre-loaded by the emulator107.

Once the snapshot has been selected by the prediction engine147, the emulator107may retrieve the snapshot at362. The snapshot may be stored on a memory external to the emulator107, but accessible over the network160. By way of example, and not by way of limitation, the snapshot may be stored on a memory on the cloud based server104. Alternatively, the snapshot may already be stored on a memory within the emulator107such as the mass storage134and therefore may be accessed over the internal system bus150.

Once the snapshot has been retrieved, the emulator107may generate the platform dependent addresses for the specific instance of the emulator107at364. According to some aspects of the present disclosure the address space for every instance of an emulator107may 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 emulator107that 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 emulator107may begin translating the legacy game data at364in order to build a buffer. The translation of the legacy game data is an emulation of the legacy game106which allows the legacy game106to be in a format that is compatible with the client device platform103. The snapshot provides the starting position of the legacy game106, and instructs every device running on the emulator107what state it should be in for the legacy game106to be executed properly from that point. However, since the snapshot starting point may not be the original starting position of the legacy game106, a buffer may also be needed since there might not be incremental buffering at that position of the legacy game106. 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 memory132on the emulator107at365. The memory may be a cache memory in order to increase the speed of delivery once the snapshot is requested by the client device platform103. Finally at366, the translated legacy game data is delivered to the client device platform103over the network160when the client device platform103makes a request for the snapshot.

As shown inFIG. 3B, a set of emulator instructions370may be implemented, e.g., by the emulator107. The emulation instructions370may be formed on a nontransitory computer readable medium such as the memory132or the mass storage device134. The emulator instructions370may also be part of the process control program133. The instructions include choosing a snapshot to pre-load at371. Next, the emulator107is provided with instructions for retrieving the snapshot at372. Thereafter, the instructions include generating the platform dependent addresses that allow the emulator107to process the snapshot at373. Then at374, the instructions include building a buffer by translating the legacy game data into a format that is compatible with the client device platform at374. Once the legacy game data has been translated, the emulator instruction370may include storing the translated legacy game data in a memory at375. Finally, the instructions may include delivering the translated legacy game data over the network160to the client device platform103after the request for the game has been made by the client device platform103at376.

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.”