U.S. Pat. No. 10,471,350

PERSISTENT GAME SESSIONS WITH MULTIPLAYER SUPPORT

AssigneeApple Inc

Issue DateNovember 13, 2018

Illustrative Figure

Abstract

Embodiments of the present disclosure provide techniques for initiating direct-connection multiplayer game sessions and for resuming a previously-adjourned multiplayer game session using a stored game object representing a state of the game session. In one exemplary method, a multiplayer gaming application may be executed on a first terminal, which may be associated with a first user. The first terminal may access a game object stored on a content management server that contains data representing a state of a previously adjourned session of the multiplayer gaming application. Further, the first terminal may determine, from the game object, a second terminal associated with a second user. The first terminal may host a session between the first terminal and the second terminal. Finally, an updated game object reflecting an updated state of the session may be stored on the content management system.

Description

DETAILED DESCRIPTION Embodiments of the present disclosure provide techniques for initiating direct-connection multiplayer game sessions and for resuming a previously-adjourned multiplayer game session using a stored game object representing a state of the game session. In one exemplary method, a multiplayer gaming application may be executed on a first terminal, which may be associated with a first user. The first terminal may access a game object stored on a content management server that contains data representing a state of a previously adjourned session of the multiplayer gaming application. Further, the first terminal may determine, from the game object, a second terminal associated with a second user. The first terminal may host a session between the first terminal and the second terminal. Finally, an updated game object reflecting an updated state of the session may be stored on the content management system. FIG. 1illustrates a multiplayer gaming system100according to an embodiment of the present disclosure. The system100includes several terminals110,120,130in communication with a network150and, by extension, each other. Each terminal110,120,130may be configured to run a gaming application, in particular a multiplayer gaming application connected to a corresponding multiplayer gaming application running on one or more of the other terminals110,120,130. The first terminal110may connect, via the network150, to an identity server170for purposes of identifying the first terminal110(and/or a user thereof), as well as identifying the second or third terminals120,130(and/or a user thereof) with which the multiplayer gaming application is played. The first terminal110may further connect, via the network150, to a content manager140with a user account145in which a game object160is stored and available for retrieval and/or modification. The game object160may contain data, including user data162, game data164, and communication data166, associated with a game session of the multiplayer gaming application, which may be used by the first terminal110to resume a persistent game session of ...

DETAILED DESCRIPTION

Embodiments of the present disclosure provide techniques for initiating direct-connection multiplayer game sessions and for resuming a previously-adjourned multiplayer game session using a stored game object representing a state of the game session. In one exemplary method, a multiplayer gaming application may be executed on a first terminal, which may be associated with a first user. The first terminal may access a game object stored on a content management server that contains data representing a state of a previously adjourned session of the multiplayer gaming application. Further, the first terminal may determine, from the game object, a second terminal associated with a second user. The first terminal may host a session between the first terminal and the second terminal. Finally, an updated game object reflecting an updated state of the session may be stored on the content management system.

FIG. 1illustrates a multiplayer gaming system100according to an embodiment of the present disclosure. The system100includes several terminals110,120,130in communication with a network150and, by extension, each other. Each terminal110,120,130may be configured to run a gaming application, in particular a multiplayer gaming application connected to a corresponding multiplayer gaming application running on one or more of the other terminals110,120,130. The first terminal110may connect, via the network150, to an identity server170for purposes of identifying the first terminal110(and/or a user thereof), as well as identifying the second or third terminals120,130(and/or a user thereof) with which the multiplayer gaming application is played. The first terminal110may further connect, via the network150, to a content manager140with a user account145in which a game object160is stored and available for retrieval and/or modification. The game object160may contain data, including user data162, game data164, and communication data166, associated with a game session of the multiplayer gaming application, which may be used by the first terminal110to resume a persistent game session of the multiplayer gaming application with the second and/or third terminals120,130. In other words, the game object160allows the users of the various terminals110,120,130to save the game state of a game session of the multiplayer gaming application and return to that same game state of the multiplayer gaming application at a later time.

InFIG. 1, the first terminal110is illustrated as a tablet computer and the second terminal120is illustrated as a smart phone. However, the terminals110,120,130are not so limited and may be embodied by any manner of computing device capable of executing a multiplayer gaming application. For example, the terminals110,120,130may include mobile devices (e.g., mobile phones, smart phones, or tablet computers), personal computers (e.g., desktop computers or laptop computers), gaming devices (e.g., gaming consoles or handheld gaming devices), set-top computing devices (e.g., digital media players), or any combination thereof. In a typical implementation, the terminals110,120,130are each configured with a memory, processor, and display. The multiplayer gaming application may be stored in the memory, executed by the processor, and visually portrayed via the display. The terminals110,120,130may each further be configured with an input, such as a pointing device, touchscreen, one or more buttons, a keyboard, or the like by which the user may interact with the multiplayer gaming application.

Each of the terminals110,120,130may be configured to execute a multiplayer gaming application. A multiplayer gaming application may be an entertainment application or program that involves the interaction of two or more users via two or more respective terminals110,120,130; the multiplayer gaming applications may execute on the respective terminals110,120,130and communicate with each other. A multiplayer gaming application may define a real-time multiplayer game in which two or more users interact with their respective multiplayer gaming application on their respective terminal110,120,130and, by extension, one another contemporaneously. Examples of real-time multiplayer gaming applications may include first-person shooter (FPS), racing, or real-time strategy (RTS) games. Alternatively, a multiplayer gaming application may define a turn-based multiplayer game in which the gameplay advances in “turns” wherein one user initiates a play, action, or move while the other user(s) sit idle until it is that user's turn to perform a play, action, or move. For example, turn-based multiplayer games may include card games (e.g., poker), board-type games (e.g., checkers or chess), or turn-based strategy games.

The instances of a multiplayer gaming application on the respective terminals110,120,130need not necessarily mirror one another in gameplay, but may instead each asymmetrically display or otherwise provide different aspects of the gameplay of the multiplayer gaming application. For example, the first terminal110(e.g., a tablet computer or a computing device whose display is provided to a large-screen television) may serve as a central display viewable by all users while the second and third terminals120,130(connected to the first terminal110) each provide an interaction with the multiplayer gaming application that is specific to those respective users.

For instance, in one aspect, the first terminal110may provide an instance of the multiplayer gaining application that emulates a poker table that is visible to all the users. The second and third terminals120,130may each provide an instance of the multiplayer gaming application providing interaction with the respective user's poker hand, chips, and so forth, which would preferably only be visible to that user. As the users play cards and/or bet chips using their respective terminals120,130, the display of the poker table on the first terminal110would accordingly reflect such plays on its display of the poker table. In another aspect, the instance of the multiplayer gaming application on the first terminal110may display a roulette table and the instances of the multiplayer gaming application on the second and third terminals110would provide an interface in which the respective users may place bets. In yet another aspect, the instance of the multiplayer gaming application on the first terminal110may provide a board of a board game, viewable to all users. Each instance of the multiplayer gaming application on the second and third terminals120,130may display private holdings (e.g., tiles, cards, or other game pieces) for the respective user, as well as an interface for the respective user to effectuate one or more game commands. As the users play game pieces and/or perform game commands via the second and third terminals120,130, the board displayed on the first terminal110is accordingly updated.

The network150may represent any number of networks capable of conveying the various data communications described herein, including for example wireline and/or wireless communication networks. Representative networks include telecommunications networks, local area networks, wide area networks, and/or the Internet. It is further explicitly contemplated that the network150may embody a peer-to-peer connection between the terminals110,120,130, such as via Bluetooth® or other short-range radio protocol. Further, the terminals110,120,130may directly connect with one another for purposes of participating in a session of gameplay with the respective instances of the multiplayer gaming application, without requiring support of a game server to host the game (i.e., a server or other computing device used in some conventional implementations to coordinate and maintain game information, such as game states, player moves or commands, player avatar positions, etc., between terminals). Instead, two or more of the terminals110,120,130of the present disclosure may effectuate multiplayer gameplay by communicating game information between one another. This direct connection between the terminals110,120,130may be peer-to-peer (e.g., Bluetooth®) or may pass through one or more telecommunication or networking mediums, such as the Internet, a cellular network, etc.

The identity server170may represent one or more computing devices providing identity services. In particular, the identity server170may maintain an identity repository172of identities. An identity may be associated with a user of one of the terminals110,120,130and may be used to identity a user and/or an associated terminal110,120,130. An identity may include a number of attributes relating to a user and/or an associated terminal110,120,130. An attribute of an identity may include a unique identifier, such as a user id, a user number, an email address, or a phone number (e.g., a phone number associated with the user's terminal110,120,130). An attribute also may relate to personal information about the user, such as the user's name or nickname/alias. An attribute may further relate to the terminal110,120,130associated with the user, including an IP (internet protocol) address, a MAC (media access control) address, a phone number, or other information that may be used to identify and/or connect to the terminal110,120,130. Such attributes may additionally reflect various characteristics of the terminal110,120,130, such as device type, hardware characteristics, operating system, connection capabilities (e.g., whether the terminal110,120,130is configured to establish a Bluetooth® connection), and applications (e.g., a particular multiplayer gaming application) installed on the terminal110,120,130. An identity may also include an authentication attribute, such as a text password, a biometric profile, or a gesture password. It will be appreciated that any of the aforementioned attributes may function as a unique identifier of an identity so long as said attribute is unique among the identities in the identity repository172.

In operation, a requesting terminal110,120,130may transmit a unique identifier to the identity server170, whereupon the identity server170receives the unique identifier. Upon receipt of the unique identifier, the identity server170may cross-reference the unique identifier with the identities of the identity repository172and determine the identity corresponding to the unique identifier. Accordingly, one or more attributes of the identity may be transmitted back to the requesting terminal110,120,130.

In some aspects, for example where a user transmits his or her own unique identifier, the requesting terminal110,120,130may also transmit an authentication attribute with or following the unique identifier. The provided authentication attribute may be checked by the identity server170against the stored authentication attribute associated with the identity to ensure that the user has provided his or her correct authentication attribute. Upon this authentication, the user's identity, and attributes thereof, may be used in various functionalities of the user's terminal110,120,130, such as to identify the user in a multiplayer gaming application executing on the user's terminal110,120,130.

In other aspects, for example where a user transmits another user's unique identifier, the requesting terminal110,120,130need not transmit an authentication attribute in concert with the unique identifier. In such an instance, the identity server170may return back only a limited subset of the attributes of the identity corresponding to that unique identifier. As an example, a first user, via the first terminal110, may transmit a unique identifier for the identity of a second user to the identity server170. Based on the transmitted unique identifier, the identity server170may determine the identity of the second user and return one or more attributes of the second user's identity to the first terminal110. The attributes of the second user's identity may be used by the first terminal110(e.g., by the multiplayer gaming application executing on the first terminal110) to facilitate multiplayer gameplay with the second user. For instance, the attributes of the second user's identity may include an attribute (e.g., an IP address, MAC address, or other terminal identifier) usable to effectuate connection with the second terminal120used by the second user. Accordingly, the instance of the multiplayer gaming application executing on the first terminal110may connect to and establish a multiplayer game session with the instance of the multiplayer gaming application executing on the second terminal120.

FIG. 2illustrates a method200of establishing a multiplayer game session according to an embodiment of the present disclosure. According to the method200, the first terminal110, having an instance of a multiplayer gaming application installed thereon, transmits an identifier (e.g., a unique identifier) to the identity server170(box210). The identifier provided to the identity server170may be an identifier associated with the second terminal120and/or the user thereof. For example, the first terminal110may provide the second terminal's120user's username, email address, or phone number. Upon receipt of the identifier from the first terminal110, the identity server170may determine an identity, such as from the identity repository172, corresponding to the received identifier (box212). Preferably, the determined identity is associated with the second terminal120and/or the user thereof. As discussed in detail above, the determined identity may include one or more attributes relating to the associated user and/or the user's terminal(s).

The identity server170may transmit a connection attribute to the first terminal110, wherein the connection attribute relates to the second terminal120(box214). The connection attribute may include, for example, an IP address, a MAC address, a phone number, a terminal identifier, or other attribute that may be used by the first terminal110to effectuate a connection with the second terminal120. Optionally, the identity server170may also transmit other attribute(s) relating to the second terminal120and/or user thereof to the first terminal110(box216). The other attribute(s) may include any attribute discussed here, including an attribute describing a characteristic of second terminal's120user (e.g., name, image of the user, age, gender, alias or nickname, etc.) or an attribute describing a characteristic of the second terminal120(e.g., device type, operating system, hardware profile, connection capabilities, or whether the second terminal120has the multiplayer gaming application installed).

Upon receipt of the connection attribute and, optionally, the other attribute(s) from the identity server170, the first terminal110may use the connection attribute to directly connect to the second terminal120(box218). Said connection may then be used by the instances of the multiplayer gaming application executing on each of the first and second terminals110,120effectuate gameplay in a multiplayer game session (box220). The gameplay in the multiplayer game session will typically involve back-and-forth communications between the first and second terminals110,120, such as to communicate respective game commands initiated by each user. In one aspect, the first terminal110may establish the connection with the second terminal120at the terminal level (i.e., not within the multiplayer gaming application), such as before the multiplayer gaming application is initiated on the first terminal110. Similarly, the user of the first terminal110may cause the first terminal110to provide the identifier to the identity server170using an application or interface on the first terminal110other than the multiplayer gaming application. Yet in another aspect, the multiplayer gaming application executing on the first terminal110may be used to cause the first terminal110to provide the identifier to the identity server170and/or to establish the connection with the second terminal120. For example, as will be described in more detail in relation toFIGS. 5-6, the multiplayer gaming application may include an interface that allows a user to enter an identifier and subsequently connect to the terminal associated with that identifier upon receipt of the connection attribute from the identity server170.

Although the method200involves the two terminals110,120, the method200is not so limited and may be similarly applied to any arrangement including two or more terminals.

Referring again toFIG. 1, the system may also include the content manager140. The content manager140, in turn, may include one or more servers or other computing devices configured to maintain one or more user accounts145in which one or more game objects160are stored. For example, the content manager140may be considered a “cloud” server by which a user may upload, download, delete, replace, and/or modify a digital file, such as, particularly, the game object160. Notably, the content manager140is unaffiliated with the developer and/or publisher of the multiplayer gaming application. Instead, the content manager140is managed by a third-party that provides online file storage for users.

The user account145on the content manager140may be associated with a user of one of the terminals110,120,130. As with the content manager140, the user account145is similarly unaffiliated with the developer and publisher of the multiplayer gaming application. The content manager140may, upon receipt of a request from a user via one of the terminals110,120,130, identify the user account145associated with that user and provide, receive, delete, replace, and/or modify the game object160according to the request. The request may be accompanied by an identifier of the user and/or the user account145, as well as, in some aspects, an authenticator (e.g., a password, biometric profile, etc.) by which the content manager140authenticates the user to the user account145. In some aspects, the content manager140may communicate with the identity server170such that a user's identification with the identity server170may also serve to identify the user account145associated with the user and/or authenticate the user to the user account145.

In one aspect, the user account145may be associated with two or more users whereby each of the associated users may have full rights to upload, download, delete, replace, and/or modify the game object160. In another aspect, the user account145may be associated with only one user but may permit other non-specified users to perform designated operations (upload, download, delete, replace, modify, etc.) relating to the game object160. For example, the user associated with the user account145may have full operation rights with respect to the game object160, but other non-specified users may only be permitted to download the game object. In yet another aspect, the user account145may be associated with one or more primary users and one or more secondary users. The primary users may be afforded one set of operation rights (e.g., full rights to upload, download, delete, replace, modify, etc.) while the secondary users may be afforded a more limited set of operation rights (e.g., only rights to download).

The game object160may be embodied as a digital file including data pertaining to a game session of the multiplayer gaming application. The game object160may be used by one or more of the terminals110,120,130and/or the instance of the multiplayer gaming application executing thereon to capture the state (or aspects thereof) of the game session and, at a later point in time, resume gameplay at the captured game state of the previous game session. Thereby, the game object160may allow a persistent game session to be maintained across two or more chronologically separate game sessions of the multiplayer gaming application.

The data in the game object160necessary to sufficiently capture the state of a game session will naturally vary according to the particular multiplayer gaming application. Therefore, the data type(s), structure, or template of the game object160may be pre-determined by the developer of the multiplayer gaming application. Conversely, the content of the game object160is determined by the instance of the multiplayer gaming application executing on the terminal110,120,130.

While the game object160may be stored on the content manager140between separate game sessions, in some aspects the game object160may be downloaded to one or more of the terminals110,120,130participating in a game session wherein the game object160may be locally modified according to a current game state and then uploaded to the user account145on the content manager140to replace the previous version of the game object160or to create a new version of the game object160while keeping the previous version as a backup or alternative version. The game object160may be locally modified and/or uploaded to the user account145on the content manager140at various intervals, at the conclusion or adjournment of the discrete game session, or on command. The various intervals may include, for example, the end of a turn, the completion of a map or level, the defeat of a significant enemy character (e.g., a “boss”), the end of a game or round, or pre-specified time intervals (e.g., every five minutes). In other aspects, the game object160may be directly modified on the content manager140by one or more of the terminals110,120,130and/or the instance of the multiplayer gaming application executing thereon. Similarly, the game object160may be modified on the content manager140at the same sorts of intervals as described above and/or at the end or adjournment of the discrete game session.

In the event that a game session has recently been initiated and there is not yet an associated game object160, either locally on one or more of the terminals110,120,130or on the content manager140, a new game object160may be created. The new game object160may be created locally on the one or more terminals110,120,130and later uploaded to an appropriate user account145on the content manager140or the new game object160may be directly created in an appropriate user account145on the content manager140.

Given that a game session will typically involve the participation of multiple users and multiple terminals110,120,130, in one aspect, one of the terminals110,120,130(e.g., the terminal110) may be designated as a master terminal and undertake the tasks of creating, uploading, downloading, modifying, etc., the game object160while the remaining terminals110,120,130(e.g., the second and third terminals120,130) may be designated as slave or secondary terminals and do not perform any operations relating to the game object160. In another aspect, all of the terminals110,120,130participating in the game session may each locally maintain a respective game object160and upload and/or modify the respective game object160to the content manager140. In this arrangement, the uploaded and/or modified game objects160may be maintained in separate user accounts145corresponding to the respective users of the terminals110,120,130or the uploaded and/or modified game objects160may be maintained in a single user account145that is associated with each user of the terminals110,120,130or that otherwise permits those users to upload and/or modify the game object(s)160in the single user account145.

The game object160may include user data162, game data164, and/or communication data166. The user data162includes data relating to the users participating in a game session. For example, the user data162may include an identification of the users participating in a game session. The identification of a user may include a user id, a name, a screen name, an alias, or a phone number. The user data162may further include an identification of the terminals110,120,130involved in the game session. The identification of a terminal110,120,130may include a terminal name or alias, a phone number, a MAC address, or an IP address of the terminal110,120,130. The user data162may also include a connection status for each user and/or terminal110,120,130involved in a game session. In particular, the connection status may indicate whether a certain user and/or terminal110,120,130was online or offline in the game session at the point of time that the state of the game session was captured (a user and/or terminal110,120,130may still be deemed to be participating in a game session while that terminal110,120,130is disconnected from the other terminals110,120,130). The user data162may subsequently be used to determine the users and/or terminals110,120,130involved in a game session and re-invite and/or re-connect those users and/or terminals110,120,130to the resumed game session.

The game data164may include any data representing the captured state of the game session of the multiplayer gaming application. The principles of the present disclosure find application with many types of multiplayer gaming application and, therefore, the specific aspects comprising a captured game state will be driven by the requirements of the specific multiplayer gaming application. As some general examples, the game data164may include game character status, map or level data (e.g., which map or level is currently being played), in-game resource (e.g. coins or other currency) status, a user's playable gaming pieces (e.g., hand of cards), or score. As a specific example of game data164wherein the multiplayer gaming application is a checkers game, the game data164may include a representation of the checkers board at a given time, such as the board position of each of the checkers pieces, how many checkers pieces of each color have been eliminated from the game, which checkers pieces are “kinged”, and an ongoing win-loss record for each user in the game session. As another specific example of the game data164wherein the multiplayer gaming application is a first-person shooter (FPS) game, the game data164may include the current map being played, the position of each user's character within the map, the weapons in each user's character's inventory, the weapon currently equipped by each user's character, the amount of ammunition carried by each user's character, the health and/or armor status of each user's character, and the model, class, or type of character controlled by each user.

The communication data166may include a record of in-game communication between the users during a game session. For example, the multiplayer gaining application may support peer-to-peer messaging between the terminals110,120,130participating in the game session. A record of such messages may be included in the communication data166for persistence when the game session is resumed at a later time. Similarly, the multiplayer gaming application may support voice communication between users and a record of this voice communication may also be included in the communication data166. In some aspects, only the communications between the users during a pre-defined period of time before the creation or update of the game object160is included in the communication data166. For example, only the communications occurring in the ten-minute period before the game state is captured in the game object160may be included in the communication data166. In further aspects, the communications included in the communication data166need not be strictly within the multiplayer gaming application but may also include communications occurring via an application or communication interface of the terminal110,120,130operating in coordination with the multiplayer gaming application, such as a short message service (SMS) interface present on many mobile devices (e.g., smart phones).

FIG. 3illustrates one exemplary method300of initiating a multiplayer game session, the game state of which is embodied in the game object160. In accordance with the method300, an instance of a multiplayer gaming application may be executed on the first terminal110and the game object160may be created by the first terminal110(box310). The game object160may be created locally on the first terminal110and subsequently uploaded to the user account145on the content manager140, created directly in the user account145on the content manager140, or created locally on the first terminal110and maintained there for the time being.

The first terminal110may establish connections to the second terminal120and the third terminal130(box312). Although the method300specifically contemplates the three terminals110,120,130, the method300is equally applicable to any arrangement with two or more terminals. The connections with the second and third terminals120,130may be established according to the method200described in relation toFIG. 2in which the first terminal110uses the identity services provides by the identity server170to ascertain connection attributes relating to the second and third terminals120,130which are then used by the first terminal110to establish those connections. Alternatively, the connections to the second and third terminals120,130may be established using connection information already known to the first terminal110and/or user thereof or received from an external source. For example, the connection information may be stored in a directory of phone contacts present on the first terminal110or the connection information may be received from a social networking application or site. Establishing the connections to the second and third terminals120,130may include sending, within the instance of the multiplayer gaming application executing on the first terminal110, an invitation to the other users, which is received and displayed within the respective instances of the multiplayer gaming application executing on the second and third terminals120,130. Alternatively, the invitations may be sent and/or received outside of the multiplayer gaming application, such that said invitation prompts the receiving user to launch the multiplayer gaming application on the respective second or third terminal120,130and join the multiplayer game session. Upon acceptance of the invitations, the connection with the second and third terminals120,130may be established and the respective users may be joined to the multiplayer game session of the multiplayer gaming application.

After the connection is established between the first terminal110and the second and third terminals120,130, the gameplay of the multiplayer game session may commence. Such multiplayer gameplay may include ongoing communications amongst the terminals110,120,130, such as communications regarding game commands or moves, game character status updates, or messages between the users (boxes314,316). At various intervals during the gameplay (e.g. the end of a turn, the end of a level or map, upon a manual request by a user, etc.), the game object160may be modified by the first terminal110(or modified (not shown) by the second and/or third terminals120,130) according to the current state of the game session. For example, the user data162of the game object160may be updated to reflect that the second and third terminals120,130and/or users thereof are participating in the game session. The game data164of the game object160may be updated to reflect the current various game variables, such as the map or level, the relative position of each user's character on the map or level, character health or asset status, etc. The communication data166of the game object160may be similarly updated. For example, the communication data166may be updated to reflect the text messages transmitted between the users during the game session up to that point.

The modified game object160may be uploaded from the first terminal110(or uploaded (not shown) from the second and/or third terminals120,130) to the user account145associated with the first terminal110and/or user thereof. Such upload may be accompanied, in some instances, by an account identifier and/or an authentication element (e.g., password) to identify the particular user account145and authenticate the first terminal110with that particular user account145, respectively. In some aspects, the modification and upload of the game object160(boxes318,320) may be combined into a single step in which the game object160is maintained in the user account145and modified directly in the user account145.

Following additional gameplay (not shown), the game session may adjourn or end (box322). Responsive to the game session adjourning or ending, the game object160may again be modified, as described in greater detail above, to reflect the state of the game session at the end or adjournment of the game session (box324). The modified game object160may subsequently be uploaded to the user account145associated with the first terminal110and/or user thereof, as described above. In some aspects, the modification and upload of the game object160(boxes324,326) may also be combined into a single step in which the game object160is maintained in the user account145and modified directly in the user account145.

Since the ending or adjourning state of the previous game session is recorded and saved in the game object160, that game session may be resumed at a later point in time using the game object160, thereby creating a persistent game session despite the temporal interruption. When the persistent game session is resumed at the later point in time, the state of the game is the same, or very near the same, as that when the previous game session ended or adjourned. Such continuity may not just be limited to aspects of the multiplayer gaming application itself, but may also include aspects regarding which users and/or terminals110,120,130were participating in the previous session so that they may be rejoined to the persistent game session when it is resumed.

FIG. 4illustrates an exemplary method400of resuming a persistent game session based on the previously created and modified game object160, such as resuming the game session started and ended/adjourned in the method300described in relation toFIG. 3. Initially, the first terminal110may send a request to the user account145of the content manager140to download the game object160from the previous game session to the first terminal110(box402). The user account145may be associated with the first terminal110and/or user thereof, in which case the request may include an account identifier and/or an authentication element (e.g., password). Alternatively, the user account145may not be associated with the first terminal110and/or user thereof (e.g., the user may not have full rights to the user account145) but the user account145may be configured to allow anonymous downloads of the game object160from the user account145. The first terminal110may subsequently download the game object160from the user account145(box404). In some aspects, the game object160may already be saved locally on the first terminal.110, in which case the above request and download (boxes402,404) may be omitted.

Having accessed the game object160from the previous game session, the first terminal110may begin to resume that game session by determining the terminals and/or users that participated in the previous game session, which in this exemplary method are the second and third terminals120,130and/or users thereof, based on the game object160, such as the user data162included in the game object160(box406). As described above, the user data162includes data sufficient to identity the second and third terminals120,130and/or to allow the first terminal110to establish a connection with the second and third terminals120,130.

In some aspects, the user data162may include unique identifiers of the users that participated in the previous game session and the first terminal110may use the identity services of the identity server170to identify the terminals associated with those users based on the unique identifiers, such as in the method200described in relation toFIG. 2. In many cases, these terminals may be the second and third terminals120,130(i.e., the same terminals used by those users in the previous game session). Yet in other cases, the users may be using different terminals. For example, a user may have upgraded their old terminal to a new terminal or the user may have migrated from a smart phone terminal to a table computer terminal in the interim. In those cases, the attributes returned by the identity server170in the method200(boxes214,216) may identify the different terminal(s) and provide information sufficient for the first terminal110to connect to that terminal.

Based on the determined second and third terminals120,130and/or users thereof, the first terminal110may establish connections with the second and third terminals120,130. For example, the first terminal110may use the IP address, MAC address, or other terminal identifier included in the user data162of the game object160or received from the identity server170to connect to the second and third terminals120,130. As described in more detail in relation to the box312in the method300, the connections to the second and third terminals120,130may be established by sending (either within or external to the multiplayer gaming application) invitations to the second and third terminals120,130, which in turn may be accepted by the users of the second and third terminals120,130if that user wishes to rejoin the persistent game session. Upon acceptance of the invitation, the second and/or third terminal120,130may be connected to the first terminal110and the user(s) of the second and/or third terminal120,130may be added to the persistent game session.

After connecting to the second and third terminals120,130, the game object160may optionally be transmitted or otherwise provided to the second and third terminals120,130so that each of the respective instances of the multiplayer gaming application may resume the persistent game session with the same game state (box410). Alternatively, the second and third terminals120,130may initiate a request to the content manager140to download the game object160from the user account145. Such a request and download may be caused by an instruction (e.g., an instruction including a link to the game object160in the user account145on the content manager140) provided to the second and third terminals120,130by the first terminal110. Also alternatively, the data contained in the game object160(e.g., the user data162, the game data164, and/or the communication data166) may be transmitted to the second and third termnninals120,130via the instances of the multiplayer gaming application. For example, the instance of the multiplayer gaming application executing on the first terminal110may extract all or a portion of the data contained in the game object160and transmit that extracted data, or a portion thereof, to the instances of the multiplayer gaming application executing on the second and third terminals120,130.

After the first terminal110has established connections with the second and third terminals120,130, the persistent game session may be resumed based, at least in part, on the game object160(box412). For example, the game session may resume at the same level or map, with the same game board state, with the same scores, with the same card hands, etc. as when the game object160was modified and saved when the game session was previously ended or adjourned (e.g., as in boxes322-324in the method300). After the persistent game session is resumed, the gameplay of the multiplayer gaining application may be re-commenced. Such gameplay may include ongoing communications amongst the terminals110,120,130, such as communications regarding game commands or moves, game character status updates, or messages between the users (boxes414,416). At various intervals during the gameplay, the game object160may be modified by the first terminal110(or modified (not shown) by the second and/or third terminals120,130) according to the current state of the game session (box418). Additionally, when this portion of the persistent game session is adjourned or ended, the game object160may similarly be modified according to the state of the game session at that time.

Responsive to the modification of the game object160, either due to the trigger of the aforementioned interval or the end or adjournment of the game session, the game object160may be uploaded by the first terminal110to the user account145, which may be associated with the first terminal110and/or user thereof (box420). Such upload may be accompanied, in some instances, by an account identifier and/or an authentication element (e.g., password) to identify the particular user account145and authenticate the first terminal110with that particular user account145, respectively. In some aspects, the modification and upload of the game object160(boxes418,420) may be combined into a single step in which the game object160is maintained in the user account145and modified directly in the user account145.

FIG. 5illustrates an exemplary interface500of a multiplayer gaming application. The interface500may include a gameplay area510, in which the primary content of the multiplayer gaming application may be displayed, and a game commands area512via which a user may enter various game commands according to the needs of the specific multiplayer gaming application. The interface500may further include a user's area514in which the users516a-cparticipating in the game session are displayed. The users516a-cmay be visually identified, for example, according to a username or alias stored in the user data162of the game object160. Alternatively, the users516a-cmay be visually identified according to a username, alias, or other identifier received from the identity server170. The connection status of the users may also be indicated in the users area514. For example, one or more of the users516a-cthat are disconnected from the game session may be greyed out in the users area514.

The interface500may further include an interactive element520to add a user to the game session. With additional reference toFIG. 6, upon activation of the interactive element520to add a user, a pop-up window610is displayed that prompts the present user to provide a user identifier of the user to add to the game session. The user identifier may be entered in the interactive space612in the pop-up window610. The entered user identifier may subsequently be provided to the identity server170to receive back one or more attributes, including a connection attribute, which may be used to connect the terminal110,120,130associated with that user to the game session.

As discussed above, the connection of additional terminals110,120,130and/or users to the game session may be effectuated by sending an invitation to that terminal110,120,130. For example, an invitation may be sent to the second terminal120after the user on the first terminal110enters the user identifier associated with the second terminal120in the interactive space612of the pop-up window610. With additional reference toFIG. 7, which shows the interface500of the instance of the multiplayer gaming application executing on the second terminal120, an invitation window710may be displayed on said interface500inviting the user to join the first terminal110user's game session. An interactive element712may be provided in the invitation window710to accept the invitation and an interactive element714may also be provided in the invitation window710to decline the invitation. If the user of the second terminal120accepts the invitation, the second terminal120may then be connected to the first terminal110and that user may be joined to the game session.

Returning toFIG. 5, the interface500may further include an interactive element518to cause the game object160to be updated with the current state of the game, as described in greater detail above. The interactive element518is not necessarily present or active in each instance of the multiplayer gaming application. For example, only the interface500of the instance of the multiplayer gaming application executing on the first terminal110may include an activate-able interactive element518to update the game object160, while the interactive element518in the interfaces500of the instances of the multiplayer gaming application executing on the second and third terminals120,130may not be configured for interaction or may be absent altogether.

Several embodiments of the disclosure are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosure are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the disclosure.

Claims

  1. A non-transitory medium include application instructions that, when executed by a processing device, cause the device to: execute an application by the processing device, the processing device being associated with a first user;access an object stored on a server that contains data representing a state of a previously-adjourned session of the application;determine, from the object, a connection attribute of a second device associated with a second user;host, by the processing device, a session of the application between the device and the second device via a connection facilitated by the connection attribute;update the object according to the hosted session;and send data of the updated object to the server.
  1. The medium of claim 1 , wherein the object is received from a user account of the server associated with at least one of the first user and the second user.
  2. The medium of claim 2 , wherein the instructions further cause the processing device to, when the object contains a unique identifier of the second user: provide the unique identifier of the second user to an identity server;and receive, from the identity server, the connection attribute relating to the second device, wherein the hosting the session between the processing device and the second device is based at least in part on the connection attribute.
  3. The medium of claim 3 , wherein the unique identifier comprises at least one of a phone number, an email address, and a user name.
  4. The medium of claim 3 , wherein the instructions further cause the processing device to: receive, from the identity server, an alternate identifier of the second user;wherein the second user is identified in an interface of the application by the alternate identifier received from the identity server.
  5. The medium of claim 2 , wherein the updating the object comprises: updating, by the processing device, the object to reflect a current state of the session.
  6. The medium of claim 6 , wherein the instructions further cause the processing device to: upload, by the processing device, the updated object to the user account of the server.
  7. The medium of claim 6 , wherein: the object is a game object and the application is a gaming application, and the updating the game object is performed responsive to a trigger comprising at least one of: the end of a game level, the end of a game map, the end of a game round, the end of a game turn, and the passage of a pre-specified period of time.
  8. The medium of claim 6 , wherein the object comprises communication data representing one or more messages exchanged between the first user and the second user in the previously adjourned session of the application.
  9. The medium of claim 1 , wherein the instructions for hosting the session between the processing device and the second device cause the device to: send, by the processing device, an invitation to the second device for the second user to join the session.
  10. The medium of claim 1 , wherein the connection attribute is a device identifier.
  11. A non-transitory medium include application instructions that, when executed by a processing device, cause the processing device to: execute an application by the processing device, the processing device being associated with a first user;create, by the processing device, an object that contains data representing a state of a session of the application;host, by the processing device, a session between the processing device and a second device associated with a second user by using a connection attribute;update the object;and store the updated object on a server reflecting an updated state of the session.
  12. The medium of claim 12 , wherein the instructions further cause the processing device to: determine the connection attribute of the second device from an identifier relating to the second user.
  13. The medium of claim 13 , wherein the identifier relating to the second user is received from an identity server in response to the processing device providing a unique identifier to the identity server.
  14. The medium of claim 14 , wherein the identifier relating to the second user comprising a connection attribute relating to the second device, and wherein the hosting the session between the processing device and the second device is based at least in part on the connection attribute.
  15. The medium of claim 13 , wherein the identifier relating to the second user is accessed from a directory of phone contacts on the processing device.
  16. The medium of claim 13 , wherein the instructions for updating the object cause: updating, by the processing device, the object to reflect a current state of the session.
  17. The medium of claim 17 , wherein the instructions further cause the processing device to: upload, by the processing device, the updated object to a user account of a server associated with at least one of the first user and the second user.
  18. The medium of claim 13 , wherein the hosting the session between the processing device and a second device comprises: sending, by the processing device, an invitation to the second device for the second user to join the session.
  19. A non-transitory medium include application instructions that, when executed by a processing device, cause the device to: execute an application on the processing device, the processing device being associated with a first user;provide, by the processing device, a unique identifier to an identity server, the unique identifier relating to a second user;receive, by the processing device and from the identity server, a connection attribute relating to a second device associated with the second user;and based at least on the connection attribute, host, by the processing device, a session of the application between the processing device and the second device.
  20. The medium of claim 20 , wherein the instructions further cause the processing device to: receive, by the processing device and from the identity server, a second attribute relating to the second user, wherein the second user is identified in an interface of the application based on the second attribute.
  21. The medium of claim 20 , wherein the session between the processing device and the second device is established via a short-range radio protocol.
  22. A method comprising: executing an application by a processing device associated with a first user;creating, by the processing device, an object that contains data representing a state of a session of the application;hosting, by the processing device, a session between the processing device and a second device associated with a second user by using a connection attribute;updating the object;and storing the updated object on a server reflecting an updated state of the session.
  23. The method of claim 23 , further comprising: determine the connection attribute of the second device from an identifier relating to the second user.
  24. The method of claim 24 , wherein the identifier relating to the second user is received from an identity server in response to the processing device providing a unique identifier to the identity server.
  25. The method of claim 25 , wherein the identifier relating to the second user comprising a connection attribute relating to the second device, and wherein the hosting the session between the processing device and the second device is based at least in part on the connection attribute.
  26. The method of claim 24 , wherein the identifier relating to the second user is accessed from a directory of phone contacts on the processing device.
  27. The method of claim 24 , further comprising: updating, by the processing device, the object to reflect a current state of the session.
  28. The method of claim 28 , further comprising: uploading, by the processing device, the updated object to a user account of a server associated with at least one of the first user and the second user.
  29. The method of claim 24 , wherein the hosting the session between the processing device and a second device comprises: sending, by the processing device, an invitation to the second device for the second user to join the session.

Disclaimer: Data collected from the USPTO and may be malformed, incomplete, and/or otherwise inaccurate.