GAME PROGRESSION USING RETRIEVED PARTIAL USER DATA

Description

BACKGROUND

Computing systems have revolutionized the way people communicate, do business, and play. For instance, a user may engage in complex, sophisticated and realistic games using the considerable computing power of conventional gaming consoles. In order to engage in conventional rich gaming experiences, a player might typically purchase a gaming console, and also purchase a game. This alone represents a considerable investment for the player. However, there is also a wide variety of games available for any given game console. Furthermore, online services are also available to enable or enhance the gaming experience by, for example, enabling players to engage in a distributed game in which players are remotely located. Nevertheless, the player is often limited to engaging in the game when in the proximity of the gaming console.

Gamers can also engage in online games in which much of the processing power is remotely located. For instance, a user might interact with a social media application to begin a game. The game state associated with the game may be kept on a remote location and/or local to the gamer. So long as game state is preserved, the gamer may continue the game from that preserved state.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practiced.

BRIEF SUMMARY

At least some embodiments described herein provide a system that contains multiple game servers that have a non-user specific unused state, and a user-specific game state when the game server is used. When the game server is providing a game service, the game server first obtains the user data for the user and game that is to be initiated. Accordingly, the game servers may be thought of as a bank of game servers, any one of which being potentially utilizable for incoming game requests. Once the game session is completed, the user data for the gamer may be deleted, and the game server goes back into the pool of available generic game servers. The user data is downloaded from a user data store, and may be quite limited to perhaps just that portion of the user data that relates to the game to be played. Accordingly, a paradigm is described in which a bank of generic game servers may be assigned to any given user, while still providing each user with a user-specific experience, with their own profile information, and game saves.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates an example computing system in which the principles described herein may be employed;

FIG. 2 illustrates a network environment in which the principles describe herein may operate and includes multiple game clients, multiple game servers, a connection server, and a user data store;

FIG. 3 abstractly illustrates a connection server that is an example of the connection server of FIG. 2, and includes selection logic and an index;

FIG. 4 illustrates an entry that is an example of any of the entries of FIG. 3, and which includes a game server identification field and a status field;

FIG. 5 illustrates a more detailed abstract diagram of a user data store that represents an example of the user data store of FIG. 2, and which includes user data in the form of a number of user-specific data stores;

FIG. 6 abstractly illustrates user specific user data, represents an example of any of the user specific user data of FIG. 5, and which includes general user data for that user, as well as game specific user data for that user;

FIG. 7 abstractly illustrates a game specific user data, and is an example of any of the game specific user data portions of FIG. 6;

FIG. 8 illustrates a flowchart of a method for initiating a gaming service session by a game server;

FIG. 9 illustrates a flowchart of method for addressing user state changes when progressing the game; and

FIG. 10 illustrates a flowchart of a method for completing a gaming session.

DETAILED DESCRIPTION

Some introductory discussion of a computing system will be described with respect to FIG. 1. Then, example methods and supporting architectures will be described with respect to subsequent figures.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not conventionally been considered a computing system. In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

As illustrated in FIG. 1, in its most basic configuration, a computing system 100 typically includes at least one processing unit 102 and memory 104. The memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well. As used herein, the term “executable module” or “executable component” can refer to software objects, routines, or methods that may be executed on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions. For example, such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data. The computer-executable instructions (and the manipulated data) may be stored in the memory 104 of the computing system 100. Computing system 100 may also contain communication channels 108 that allow the computing system 100 to communicate with other message processors over, for example, network 110.

Embodiments described herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

FIG. 2 illustrates a network environment 200 that includes multiple game clients 210, multiple game servers 220, a connection server 230, and a user data store 240. Each of the game clients 210, game servers 220, and the connection server 230 may be structured and operate as described above for the computing system 100 of FIG. 1. Furthermore, the user data store 240 may be managed by a computing system, such as the computing system 100 of FIG. 1. The game clients 210, game servers 220, the connection server 230, and the user data store 240 may communicate over a network 250.

The principles described herein are not limited to the particular number of clients 210 that may interact with the game servers 220. The game servers 220 may provide a service that is open to any number of clients. For instance, if the network 250 encompassed portions of the Internet between the game servers 220 and the clients 210, there may be enumerable potential clients 210 that may communicate with the game servers 220 to thereby engage in a gaming experience. However, for the purpose of illustration and example only, the clients 210 are illustrated as including five clients 211 through 215, though the ellipses 216 represents that there could be fewer or greater (even much greater) than this amount. Furthermore, the ellipses 216 symbolically represent that the number of clients in communication with the game servers 220 to engage in a gaming experience may vary dynamically as the gamers associated with the clients 210 begin and end gaming.

Furthermore, the principles described herein is not limited to the number of game servers 220 either, although the principles described herein are particularly advantageous when there are multiple game servers. For the purpose of illustration and example only, the game servers 220 are illustrated as including three game servers 221, 222 and 223, though the ellipses 224 represents that there could be fewer or greater (even much greater) than this amount.

The game servers 220 may be located within a data center, although not required. Each game server 220 may, for example, be a server blade. That said, a server blade may well be capable of providing gaming service to multiple games simultaneously. Accordingly, the principles described here do not require a one-to-one mapping between game servers and physical server blades or other machines. When in a used state, the game servers provide a gaming experience to a particular gamer (or user). For instance, the game server manages game state; receives control signals from the client in response to a game manipulating gaming controls; incorporates those controls to affect game state; generates and transmits video, audio, and tactile data to the client so that the game may visualize, hear, and sense, respectively, the gaming experience; and so forth.

When in an unused state, each game server is not user specific to any particular user. Thus, each game server is maintained in an unused state as a state that is non-gamer specific. When the game server is assigned to a particular client and gamer, the game server initiates a user specific service session by loading the user data associated with that gamer and the game to be engaged in. That said, one or more of the game servers may be pre-loaded with the game the user wants to play. In response, the game server becomes user-specific and game-specific thereby entering a used state. Accordingly, the game servers 220 are a bank of generic game servers that can be assigned to any user and any game upon assignment. When the game server is done providing the game service, the game server may delete that user data (after uploading any potential user data changes), and the game server thereby returns back to the pool of available generic game servers. The term “generic” is used herein to mean that the game server is not assigned to a specific user.

The connection server 230 receives incoming game connection requests from various game clients 210. As those game requests are received, the connection server 230 decides which of the available game servers 220 is to be assigned to connect to the requesting game client 210 to fulfill the request. The connection server 230 provides a resulting assignment to the assigned game server to thereby cause the assigned game server to initialize a corresponding game session.

FIG. 3 abstractly illustrates a connection server 300 that is an example of the connection server 230 of FIG. 2. The connection server 300 includes selection logic 301 and an index 310. The selection logic 301 selects a corresponding unused game server to be assigned for each connection request. For instance, in FIG. 2, the selection logic of the connection server 230 may select one of the game servers 220 to handle an incoming connection request.

The index 310 includes an entry for each game server. For instance, the index 310 includes entries 311, 312 and 313. Referring to FIG. 2, each of the entries 311 through 313 might correspond to game servers 221 through 223, respectively. The ellipses 314 represents again that there may be any number of entries in the index 310, just as ellipses 224 represents that there may be any number of game servers 220. Although the embodiment has been described with respect to an index in which there are as many entries as there are game servers, this need not be the case. The availability of any of the game servers 220 may be represented in any fashion at the connection server 230.

FIG. 4 illustrates an entry 400 that is an example of any of the entries of FIG. 3. The entry 400 includes a game server identification field 410, and a status field 420. The game server identification field 410 identifies the game server corresponding to the entry 400. As previously mentioned, there may be as many entries 400 as there are game servers. The status field 420 indicates whether or not the identified game server is presently in use. The connection server 300 selects from amongst the unassigned game servers when selecting a game server to fulfill an incoming game connection request. The ellipses 430 represents that there may be other fields included within the entry 400. For instance, there might be performance information, maintenance information, hardware information, or any other information regarding the corresponding game server that could be helpful in determining whether to use the game server to accommodate an incoming gaming request.

Referring back to FIG. 2, the user data store 240 contains user data for each of the potential users of the game servers 220, or in other words, for each user of the clients 210 that may successfully request gaming service from the game servers 220. For instance, FIG. 5 illustrates a more detailed abstract diagram of a user data store 500 that represents an example of the user data store 240 of FIG. 2. The user data store 500 includes user data 510 in the form of a number of user-specific data stores. For instance, the user data 510 includes use data 511 for one user identity 521, another user data 512 for another user identity 522, yet another user data 513 for a user identity 523, user data 514 for another user identity 524, and user data 515 for user identity 525. For instance, in FIG. 2, suppose there was a case in which each of the clients 210 is associated with a corresponding user identity, the user data 511-515 may correspond to the respective users of the clients 211-215. That said, there is no need for one-to-one correlation between users and clients. That correlation is just for purposes of simplicity. A user of one client machine may wander to another client machine, and thus a single user may have multiple client 210. Also, a single client machine may be shared by multiple users. Combinations of the above are also possible. Also, a user may be on multiple clients potentially connected to different game servers. For instance, a user might be playing a first game on their desktop personal computer, and be playing a second game on their tablet.

FIG. 6 abstractly illustrates user specific user data 600, and represents an example of any of the user specific user data 511-515 of FIG. 5. The user specific user data 600 includes general user data 600A that is not specific to any game. However, the user specific user data 600 also includes game specific user data 600B. For instance, the game specific user data 600B includes game specific data 601, game specific data 602, game specific data 603, and game specific data 604. Accordingly, the user specific user data 600 includes general user data and game specific user data for four different games. The number of game-specific user data will depend, however, on the number of games that the user has played and for which the user is utilizing the user data store. Accordingly, the ellipses 605 represents that there may be any number of game specific user data portions.

FIG. 7 abstractly illustrates a game specific user data 700, and is an example of any of the game specific user data portions 601 through 604 of FIG. 6. The game specific user data 700 includes user profile data 710, and game saves 720. The user profile data 710 includes, for example, a gamer tag 711, game achievements 712, achievement pictures 713, gamer settings 714, and other game data as represented by the ellipses 715. The game saves 720 includes two game saves 721 and 722, although the ellipses 723 represents that there may be other numbers of game saves also depending on the game history and functionality.

FIG. 8 illustrates a flowchart of a method 800 for initiating a gaming service session by a game server. The game session is initiated when the game server receives an assignment (act 801) to provide service to a particular gamer. This begins the transition of the game server from a non-user specific state (or an unused state) to a user specific state (or a used state). As previously mentioned, the connection server (230, 300) selects the game server using the selection logic 301 and dispatches the assignment to the game server. In response, the selected game server provides the gaming service to the particular gamer (act 810).

As part of providing this gaming service (act 810), the selected game server identifies (act 811) the particular gamer associated with the assignment. For instance, the game server may authenticate the particular gamer. The game server might, for example, receive a username and password from the game and/or receive a token from the gamer. In order to determine whether or not the username and password match and/or the token properly authenticates the user, the game server might download authentication user data from the user data store 240. The game server also identifies (act 812) a game to be played by the particular gamer. In most or all cases, this might be the game requested to be played by the gamer.

The game server then retrieves (act 813) a subset of the available user data for the particular gamer from the user data store. For instance, referring to FIG. 2, suppose that the connection server 230 selected the game server 221 to provide service to a gamer on the client 212. The game server 221 would authenticate that gamer, identify the game to be played, and then retrieve the corresponding user data from the user data store 240. The retrieved user data is a subset of the available user data for the particular gamer. For instance, the subset might just be the user data associated with the particular game to be played. As an example, referring to FIG. 6, rather than retrieve all of the user specific user data 600 associated with the authenticated gamer, the game server might perhaps only retrieve some of the generic user specific data 600A, as well as perhaps only the game specific user data 603. This significantly reduces the use of the communications channel between the game server and the user data store, and preserves processing resources of both game server and user data store. Accordingly, this also reduces the time for getting the game server is the user-specific state sufficient to start the game, thereby giving the gamer a better experience getting the game started.

Once the game server has the game specific and user specific data, the game server progresses (act 814) the identified game for the identified user using the retrieved user data. This progressing of the game might involve initiating the game, or perhaps continuing the identified game from a state of a prior game save.

FIG. 9 illustrates a flowchart of method 900 for addressing user state changes when progressing the game. As the game is progressed, there might, or might not, be user data changes that occur during the game. For instance, a user data change might occur if, for instance, a game save occurs, or if the user profile for that game changes. For instance, a user might change a gamer tag, or perhaps a game setting changed or a challenge has been achieved. If a change in user data has not occurred at a particular instant in time (“No” in decision block 901), then no further processing of method 900 is necessary. However, when a change in user data has occurred (“Yes” in decision block 901), then the method 900 proceeds.

In particular, there are several user data changes that may not warrant immediate upload (“No” in decision block 902). For instance, some user data changes may result in deferred upload to the user data store, perhaps even until after the gaming session is completed. As an example, perhaps game saves are deferred until the gaming session is completed. In that case (“No” in decision block 902), the method 900 does not proceed further for now.

On the other hand, if the user data change does warrant immediate upload (“Yes” in decision block 902), then the user data change is uploaded (act 903) to the user data store. For instance, perhaps changes to the user profile portion of the user data (such as new achievements) might warrant immediate uploading.

FIG. 10 illustrates a flowchart of a method 1000 for completing a gaming session. Upon the game server determining (act 1001) that the progressing of the identified game has completed, the game server will prepare to return to the unused non-user specific state. Accordingly, after ensuring (act 1002) that any modified user data is uploaded to the user data store, the game server deletes (act 1003) the user data associated with the particular gamer from the game server. This allows the game server to be returned back to the bank of game servers that are available for assignment for another gaming session.

Thus, the principles described herein provide a system in which a bank of game servers may be drawn from in order to serve any one of numerous users, for any one of numerous potential games. Furthermore, when initiating a gaming service, the amount of user data downloaded from a user data store is kept low, perhaps limited to just the user data for the particular selected game. This reduces lag time between the time that the game service is requested and the time that the game is initiated, thereby improving consumer appeal and more closely simulating the experience of gaming with a console local to the user. Furthermore, the processing resources of the game server and user data store (and the bandwidth therebetween) are preserved, thereby allowing the number of game servers and served gamers to be scaled.

Furthermore, since the game state is maintained at the game server, the game server may preserve game save state at any point. If, for example, the game service detects that input has not been received from the user for some time, the game server might generate a game save at that point. If the game server still has not received user input from the user, then perhaps the user has walked away from the game, or perhaps network connectivity has been lost. In that case, if a long time has passed without user input, the game save made immediately after the last input might be uploaded to the user data store, and the game session may be terminated. When the user returns, or network connectivity restored, the user may continue right where the user left off. Furthermore, the user might issue an explicit save command at any point in the game progress, causing the game server to generate a game save. This explicit ability to save might be performed at any time, and any number of times. Accordingly, perhaps to preserve bandwidth, the game server does not upload the game save until the game session is completed, and then only perhaps uploads the latest game save. Thus, the principles described herein also permit flexible and resilient game save capability.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1-20. (canceled)
21. A computer-implemented method performed by one or more processors when executing computer-executable instructions, wherein the computer-implemented method provides for more efficient remote storage and retrieval of user data required for initiating an online gaming session, the computer-implemented method comprising: storing at a remote data store user data which comprises a plurality of user specific data stores each identified by general user data not specific to any game, and game specific user data that is specific to a plurality of games;a particular gamer initiating at a client computing system a request to initiate a gaming service session;receiving at a connection server the request to initiate the gaming service session;the connection server assigning from a pool of game servers that are in an unused state that is non-gamer specific, an available gaming server to provide the gaming service for the particular gamer;the assigned game server initiating a change in state to a used state that is specific to the particular gamer;the assigned game server, while in the used state, providing the requested gaming service session to the particular gamer by performing the following: identifying the particular gamer that initiated the request;identifying a game to be played by the particular gamer during the requested gaming service session;retrieving from the remote data store a subset of the user data, the subset of user data including (i) the general user data not specific to any game, and (ii) some but not all of the game specific user data, the retrieved game specific user data corresponding to the identified game and representing only that game specific user data required to play the identified game during the requested gaming service session; andconnecting to the client computing system to provide for the particular gamer the requested gaming service session for the identified game.
22. The method in accordance with claim 21, further comprising making changes to the user state of the assigned game server as the identified game is played by the particular user.
23. The method in accordance with claim 22, further comprising uploading the changes to the used state of the assigned game server to the user data at the remote data store.
24. The method in accordance with claim 23, wherein the game server determines that the requested gaming service session for the identified game has been completed before uploading said changes.
25. The method in accordance with claim 24, further comprising in response to the game server determining that the requested gaming service session for the identified game has been completed, deleting the user data associated with the particular gamer from the assigned game server.
26. The method in accordance with claim 21, wherein the retrieved game specific user data defines a state of a prior game save for the identified game.
27. The method in accordance with claim 21, wherein identifying the particular gamer comprises authenticating the particular gamer at the assigned game server.
28. A computer program product comprising a storage device having computer-executable instructions stored thereon, which, when executed by one or more processors cause the processors to implement a computer-implemented method which provides for more efficient remote storage and retrieval of user data required for initiating an online gaming session, and wherein the computer-implemented method comprises: storing at a remote data store user data which comprises a plurality of user specific data stores each identified by general user data not specific to any game, and game specific user data that is specific to a plurality of games;a particular gamer initiating at a client computing system a request to initiate a gaming service session;receiving at a connection server the request to initiate the gaming service session;the connection server assigning from a pool of game servers that are in an unused state that is non-gamer specific, an available gaming server to provide the gaming service for the particular gamer;the assigned game server initiating a change in state to a used state that is specific to the particular gamer;the assigned game server, while in the used state, providing the requested gaming service session to the particular gamer by performing the following: identifying the particular gamer that initiated the request;identifying a game to be played by the particular gamer during the requested gaming service session;retrieving from the remote data store a subset of the user data, the subset of user data including (i) the general user data not specific to any game, and (ii) some but not all of the game specific user data, the retrieved game specific user data corresponding to the identified game and representing only that game specific user data required to play the identified game during the requested gaming service session; andconnecting to the client computing system to provide for the particular gamer the requested gaming service session for the identified game.
29. The computer program product in accordance with claim 28, wherein the computer-implemented method further comprises making changes to the user state of the assigned game server as the identified game is played by the particular user.
30. The computer program product in accordance with claim 29, wherein the computer-implemented method further comprises uploading the changes to the used state of the assigned game server to the user data at the remote data store.
31. The computer program product in accordance with claim 30, wherein the game server determines that the requested gaming service session for the identified game has been completed before uploading said changes.
32. The computer program product in accordance with claim 31, further comprising in response to the game server determining that the requested gaming service session for the identified game has been completed, deleting the user data associated with the particular gamer from the assigned game server.
33. The computer program product in accordance with claim 28, wherein the retrieved game specific user data defines a state of a prior game save for the identified game.
34. The computer program product in accordance with claim 28, wherein identifying the particular gamer comprises authenticating the particular gamer at the assigned game server.
35. An online gaming system comprising: a connection server having one or more processors and memory;a pool of game servers that are in an unused state that is non-gamer specific, each game server having one or more processors and memory;a plurality of client computing systems each having one or more processors and memory;a remote data store; anda computer program product comprising a storage device having computer-executable instructions stored thereon, which, when executed by one or more processors cause the processors to implement a computer-implemented method which provides for more efficient remote storage and retrieval of user data required for initiating an online gaming session, and wherein the computer-implemented method comprises: storing at the remote data store user data which comprises a plurality of user specific data stores each identified by general user data not specific to any game, and game specific user data that is specific to a plurality of games;a particular gamer initiating at a client computing system a request to initiate a gaming service session;receiving at the connection server the request to initiate the gaming service session;the connection server assigning from the pool of game servers that are in an unused state that is non-gamer specific, an available gaming server to provide the gaming service for the particular gamer;the assigned game server initiating a change in state to a used state that is specific to the particular gamer;the assigned game server, while in the used state, providing the requested gaming service session to the particular gamer by performing the following: identifying the particular gamer that initiated the request;identifying a game to be played by the particular gamer during the requested gaming service session;retrieving from the remote data store a subset of the user data, the subset of user data including (i) the general user data not specific to any game, and (ii) some but not all of the game specific user data, the retrieved game specific user data corresponding to the identified game and representing only that game specific user data required to play the identified game during the requested gaming service session; andconnecting to the client computing system to provide for the particular gamer the requested gaming service session for the identified game.
36. The system in accordance with claim 35, wherein the computer-implemented method further comprises making changes to the user state of the assigned game server as the identified game is played by the particular user.
37. The system in accordance with claim 36, wherein the computer-implemented method further comprises uploading the changes to the used state of the assigned game server to the user data at the remote data store.
38. The system in accordance with claim 37, wherein the game server determines that the requested gaming service session for the identified game has been completed before uploading said changes.
39. The system in accordance with claim 38, further comprising in response to the game server determining that the requested gaming service session for the identified game has been completed, deleting the user data associated with the particular gamer from the assigned game server.
40. The system in accordance with claim 35, wherein the retrieved game specific user data defines a state of a prior game save for the identified game.

GAME PROGRESSION USING RETRIEVED PARTIAL USER DATA

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims