U.S. Pat. No. 9,919,220

DETAILED DESCRIPTION OF THE INVENTION

The inventors provide a unique system and method for matching a game player that has selected and initiated an online game to a running game instance that includes one or more of the player's friends actively engaged. The present invention is described in enabling detail using the following examples, which may describe more than one relevant embodiment falling within the scope of the present invention.

FIG. 1is an architectural overview of a gaming network100supporting game play matching by friend status according to an embodiment of the present invention. Gaming network100includes the well-known Internet network illustrated by a network backbone101. Backbone101represents all of the lines, equipment and access points that make up the Internet as a whole, including any connected sub-networks. Therefore, there are no geographic limitations to the practice of the present invention. Backbone101supports a gaming service provider domain102. Provider domain102includes equipment and software required to provide online gaming services to consumers who subscribe to such services, typically through a Website. Providing organization102may maintain a Website (WS)104hosted on a Web server103supported by backbone101in this example. Server103may be maintained by a third-party Web hosting service or an in-house Web hosting service without departing from the spirit and scope of the present invention.

Website104may be a contact point between gaming service subscribers and provider102. Website104enables searching or browsing of online games and may advertise or otherwise promote featured or highly popular online games. Website104enables secure access and connection to at least one game server. In this example, service provider domain102includes game servers110(1-n). Game servers110(1-n) may be maintained within a physical location of the service provider or they may be cloud-based and distributed over a larger geographic region. In a preferred implementation they are distributed and in current art known to the inventor, users may connect to the server that is running a selected instance of a game, that is closest to the accessing user's geographic position in the network for latency reduction purposes.

Backbone101supports at least one data router. In this case, a data router105and a data routed106, that may function as edge routers or bridges connecting a wired or wireless data network to the wired Internet network101through an Internet service provider not illustrated. In this implementation, connection to game server(s)110(1-n) in domain102may be through router105or through router106from a wireless or wired network, enabling gaming devices or stations, such as a gaming device107,108, or109depicted herein, to engage in online game play through the respective routers. Devices107,108, and109may be any wirelessly-capable or tethered computing appliances having browser capability of accessing WS104to be redirected to one or more of gaming servers110(1-n). In this example, devices107,108, and109are wireless gaming devices such as a smart phone, a tablet computer, a laptop, a gaming station, or similar devices.

Gaming devices107,108, and109may have a software (SW) gaming application114executable therefrom for the purpose of simplifying and specializing gaming experience according to an embodiment of the invention. Application114may be acquired by download from WS104hosted on Web server103. Application114is typically browser-based and capable of site navigation on the internet network. Application114is not specifically required to practice the present invention. In some embodiments it is provided for a mobile-friendly experience for users. Users not having application114may nevertheless search and browse games on WS104. Users having application114installed may connect and search games through the application adapted for mobile devices.

Backbone101supports a data back-end processing server (DPS)111within domain102of the service provider. Data processing sever111is a back-end server that may subscribe to gaming feeds from servers110(1-n) and record game play history of gaming subscribers, such as those operating devices107,108and109. Data processing server111also hosts a software application112. Application112enables data server111to receive information about the users operating devices107,108and109such as their friend graphs data. SW112enables, among other tasks, server111to match a player who has selected a game using application114or WS104to one of multiple running game instances115(1-n) executing on game servers110(1-n).

Data processing server111includes a data repository113containing friend graph data representing friend state details for each member of the gaming service. A friend graph is a data model that depicts a user's total friend state with other users of the service. A friend graph may include identification of and other information surrounding the current user's friends. Data may include attributes that dive deep into a friendship state between players such as number of mutual friends, following states, time friends, and who initiated friendship action. The data may also include or may be appended with activity and history data from interactions between the friends, such as number of times in chat together, number of games played together, etc. More detail about friend attributes as used to match players to games with friends is provided later in this specification.

In general use of the invention, a player, such as one of players107-109, may connect online with the gaming service with or without application114. The player may search or browse to select a game to play. When the user initiates to play the game, the user may be directed to server111for subsequent game matching based on friend graph data of the player. SW112in cooperation with game matching SW or acting unilaterally, with game search and match capability, may search for running instances of the game selected by the player, where friend graph data about the player is used by the SW to identify running instances of the game selected by the player where there are one or more friends of the player actively engaged in playing the game. It is noted herein that SW112may be integrated with existing game-matching software, or it may be a standalone version of game-matching software having added capability of matching players to games where friends of the player are engaged.

FIG. 2is a sequence diagram200depicting interaction between system components relative to player insertion into a running instance of a game, in one implementation of the invention. Sequence diagram200includes some basic components that interact in accordance with the present invention. Components depicted in this example may be the same components introduced inFIG. 1and retain the same element numbers introduced inFIG. 1. Players107-109may access Website104to search or browse for a game to play online. In this example one of players107-109connects to Website104to play a game online. Website104authenticates the player and the connected player is redirected to data processing server111. In this implementation, the Website may forward a portion or all of the player's friend graph to data processing server111for use in game matching. In another implementation, server111may already have unfettered local access to all friend graph data of players that subscribe to the service.

Data processing server111may subscribe to game servers110(1-n) hosting running instances of games. In this example, server111gets server feeds for game instances115(1) through115(n) representing running instances of the game selected by the player. Data server111aided by SW (112) may utilize friend graph data to first see games having one or more of the player's friends engaged in play of the game. In this example, server111utilizes knowledge of friends of the player to identify running instances of the selected game where friends are engaged. In this example the SW aids server111to identify a friend201(1) of the player engaged with a running instance of game115(n) and a friend201(n) of the player engaged with running instance of game115(1).

Data server111makes a determination as to which running game instance the player will be inserted into during a brief processing window (broken rounded rectangle). During this process, SW (112) may utilize player friend graph data and run one or more weighting algorithms to determine which game instance with one or more friends of the player engaged is the best one into which to insert the player. Friend graph data may be utilized at more than one level to determine where to insert a player considering available attributes of a friend model detailed later in this specification.

In this example, the first player is inserted by server111into game instance115(n) based on analysis of friend graph data relative to friends201(1) and201(n) within the brief processing window. In this case each game instance has one friend of the player engaged. Therefore, in analysis of friend graph data the SW may have weighed one or more attributes of the friends as they relate to the player at a higher level than simply sending the player to the instance having a friend engaged.

In this example sequence, a second player from players107-109accesses Website104, authenticates, connects, and is redirected to server111with friend graph data. A difference in this case is that server111aided by SW (112) determines that game instance115(1) has two of the player's friends engaged, friend201(2) and friend201(n), while game instance115(n) has none of the player's friends engaged. In this case the determination may be made on the lowest level (one or more friends engaged) without considering friend attributes).

It is possible that multiple game instances of a player-selected game have at least one if not more of the player's friends engaged. It is also possible that the player selects a game and it is determined that none of the game instances at the servers include any of the player's friends. In such a case, the player may be matched to a running game instance using other criterion such as network distance from a server. Other combinations are possible lending to a decision made on a higher level than friend identification as enabled through consideration of friend attributes in the friend model. It is also possible that a game instance that includes friends of the player is full or cannot accept an additional player. In such a case the SW may look for another game instance having friends engaged that is not currently full. In one embodiment a buffer is provided so that an instance identified as full may actually accept one more player in a super max state.

FIG. 3is a process flow chart300depicting steps for selecting a best game instance from multiple game instances for insertion of a player according to an embodiment of the present invention. At step301, a player analogous to one of player's107-109selects and initiates play of a game. It may be assumed herein that the player is logged into the gaming service. At step302it may be determined whether or not the player has a friendship graph. It is a possibility though not likely, that the player has no friends on the gaming service.

If determined at step302that the player has no friend graph data, the process may move to step304where the data server analogous to server111ofFIG. 1may search for running game instances on the game server or servers. In this process, step304includes the redirect to the data processing server. Since the player has no friends and hence no player graph data in this instance, the process may move directly from step304to step309where the server aided by SW may select a best game instance for the player according to criteria other than friend data. Step305(broken decision boundary) is reserved for a player with friend graph data. The process may then culminate at step310where the server inserts the player into the game connecting the player to the appropriate game server and running game instance.

If determined at step302that the player has a friendship graph, the friend graph data may be accessed directly or by reference link at step303. In one implementation, updated friend graph data for the player may be periodically sent to a data server so that it may be available locally. In another implementation, friend graph data is referenced in a database local to the Web server by link so that the data server matching players to game instances may use the link to access the data. The process moves from step303to step304where the data server searches for instances of the player's game that include one or more friends of the player engaged as discovered using the player graph data.

At step305, the server may determine if there are any game instances running on the game server or servers that include friends of the player engaged and playing those game instances. It is possible that no running instances of the player's selected game include friends of the player engaged in game play. At step305, if it is determined that there are no game instances on the server or servers that include the player's friends, the process may move to step309where the server may select a game instance for insertion based on other criteria and then on to step310where the player may be inserted (connected to server and game).

If it is determined at step305that there are one or more game instances found that include one or more friends of the player, the process may move to step306where the server aided by SW112may run a calculation to compare player graph data points relative to each friend in association with the particular game instance considered. In one implementation a calculation at step306may not be required if the match is made on the most basic level, that is one game instance has one or more friends while no other game instances with friends playing are found. In such a case, the process may move to step309where the server selects the game with friends and inserts the player into the game at step310.

It is noted herein that a step may be provided with or after step305that qualifies whether a game instance is full, meaning it cannot accept any more players unless one or more players drop out. In this case such instances may be ignored even though there are friends of the player engaged. In one implementation there may be a small buffer provided to game player capacity that might accept one more player such as a “super max” level that may be an absolute limit.

If it is determined at step306to run a calculation to help determine which game instance will be selected, the process moves to step307where the calculation is executed by the SW. An attribute calculation is a weighted comparison of the isolated data sets representing friend models and attributes for each friend of the player engaged in an instance of the game that the player initiated. At step308it may be determined whether or not the best game instance emerged from the calculation of step307. If no determination is made as to best game in step308, the process may loop back for another calculation round at step307.

It is noted that each calculation round may be performed at a higher level than the preceding calculation round relative to considering attributes of the friend models representing the player's friends actively playing a game instance. Attributes may include “state” attributes such as “who friended who” (friending action) and “who is following who” (following state), and number of mutually shared friends. Other attributes that might be considered in a calculation round may include shared activity values that may be continually updated as they occur between friends such as number of games played together over a span of history or the number of chat interactions engaged in with one another, etc. In one implementation only one calculation may be required to positively determine a best game instance for the player. In another implementation further rounds may be required using more attributes each time until a best game instance emerges due to heavier score or weight than other game instance candidates.

If a best game instance for the player is determined at step308, the process moves to step309where the server selects the game instance for service. At step310, the server inserts or connects the player to the game server and to the particular game instance selected. In all implementations there may be a set of rules or constraints that may govern comparison of friend models, including associated attributes. More detail about attributes and how they may be considered in weighting during calculation such as in step306is provided later in this specification.

FIG. 4is a block diagram depicting a friend model400and associated attributes that may be used in a weighting algorithm to select a best game instance for player insertion. Model400has a parent module abstract401, which represents an identified friend of a player. Without attributes the only data known would be that module401is a friend of the players and has identification (basic attribute). In one implementation a game instance could be selected based only on this data at a lowest calculation level.

Friend401includes a friending action state attribute402that indicates whether the friend originally requested friendship or accepted a friendship request from the player. Friending state attribute402may include a flag403indicating that the friend requested friending action from the player, and a flag404indicating that the friend accepted a friendship request from the player. Either indication may be a permanent data attribute to action state402. In one implementation, a higher value may be put on a friend of the player who accepted a friend request from the player than one who sent a friend request to the player that was accepted by the player. In this way attributes of the friend model400may be used with rules and constraints to score friendship value of the particular player's friends in any running game instance.

Friend401includes a mutual friends attribute407that simply states the number of mutually held friends that exist between the player and the friend. Friend401may include a following state attribute408that indicates the current following state between the player and the friend. Following state attribute408may have a flag409that indicates that the friend is following the player and a flag410indicating that the player is following the friend. These states may change and may be updated to model400when a change in state occurs from either end.

Friend401may include a chat attribute405that indicates a number value (n) representing the total number of chat interactions shared between the player and friend401. Friend401may include a games attribute406that indicates a number value (n) representing the total number of games that the player and friend have played together.

Friend401may include a posts attribute416that indicates a number value (n) representing the number of posts that both the player and the friend posted in. Friend401may include a trades attribute415that indicates a number value (n) representing the total number of game relative trades, item swaps or transactions that occurred between the player and the friend. Friend401may include other attributes than those depicted here without departing from the spirit and scope of the present invention. Similarly, the friend attributes may include further attributes as children, etc. It may be noted herein that number value (n) may be zero or more than zero. It may also be noted herein that friendship models like model400are modular and may be deleted or neutralized from a friendship graph in the case of an un-friending event.

FIG. 5is a process flow chart500depicting steps for selecting one of multiple running game instances having active friends for player insertion based on weighted score comparison of friend attributes. This example assumes that a player has selected a game and has a friend graph and that multiple running game instances were found having one or more of the player's friends engaged in play. At step501the data server aided by SW (112) may determine to run a weighting algorithm. In one implementation more than one weighting algorithm may be started to handle different aspects of comparison of the data sets.

At step502, the SW may input a number value (n) of friends associated with each running game instance. This step may include the identification of each of the friends. At step503the SW may input friend action state data for each of the friends. It is noted herein that the friend data may be segregated by friend identification and by the boundary of the domain of the running game instance that the friends are engaged in playing. At step504the SW may input the following state data for each of the friends. It is noted herein that steps503and504may be arbitrary relative to the input attribute data. For example, the process may input other attributes in place of or in addition to those mentioned. Calculation steps are assumed at each input of data.

At step505it may be determined whether enough data has been compared and scored to reveal a best game instance for the player. Step505may or may not follow step504as there may be more or fewer input steps before a determination might be made to best game instance for the player. However, the process may resolve to a decision step periodically to save time in process. In another implementation, a decision step may not be taken until all available data has been compared. If at step505a best running game instance is selected, the data server may insert or connect the player to the server and the game instance selected at step513, ending the process for that player.

If it is determined not to select a best running game instance in step505, the process may move to step506where the number value (n) representing number of mutual friends between the player and each of the friends may be input into the weighting algorithm as yet another attribute to consider (compare). At step507, the SW may input a number value (n) representing the total number of games that the player and each of the friends shared or played together. It is noted herein that each additional input of attribute data flows to the associated model data for each friend and further segregated by running game instance. In this way weighting produces an overall score for each running game instance based on the value of the friend information bounded to each running instance.

It may be noted herein that a friend may log out or drop out of a game during calculation. There may be a mechanism for fixing the score of a running game instance in that case such that the overall score may be recalculated based on the loss of the friend data associated with the dropped friend. It may also be noted that a running game instance may have a single friend that may drop off during processing or weighting. In this case the game instance may be ignored or neutralized from selection. Likewise, a friend may pop into a game during weighting thus changing the calculation for that instance. The total time for determining the best game should not adversely affect the player so calculations and scoring are performed at a high level of computation in the server including up scaling to more than one server performing the process for players in real time.

At step508it may be determined whether or not to select a game instance for the player. It may be that a clear winner (game instance) has emerged from calculation. It is not required that a decision step immediately follow step507. If at step508the best game is identified and selected, the process may end for that player with connection into the game at step513. If it is determined not to select a game instance for the player at step508, the process may move back to accepting more attribute input. At step509, the SW may input the number value (n) of chat interactions shared between the player and each of the friends. At step510, the SW may input the number value (n) of shared posts between the player and each of the friends for each game instance.

A step511it may be determined whether to select a best game instance for the player. It is again noted that there may be more or fewer attributes input into the weighting routine than were depicted in this process. Moreover, all of the data may be input into the weighting algorithm in one step without departing from the spirit and scope of the invention. There may be one or more than one determination or decision step where it may be determined if a clear winner (game instance) is identified by high score. There may be other friend attributes that may be considered without departing from the spirit and scope of the present invention. Moreover, weighting constraints may also include friend data such as age, gender, and other basic criteria.

If it is determined to select a game instance at step511, then the process may move to step513for player inserting or connection to the particular server and game instance. If the system still cannot determine a clear game instance that is best for the player, the system may report an error or may rerun the calculations. It may be perceived that at each instance of a player having a friend graph and selecting a particular game to play, the process of coming to resolution of a clear game instance that is best for the player may occur very quickly using only a fraction of the available model data. In some cases, decisions may require more data input requiring further steps of input at higher levels.

In one implementation a player may have an ability to list certain friends with whom that they wish to be matched during game play. Likewise, a player may have a list of players with whom they do not want to share a game, but wish to stay friends with just the same. In one implementation that information may be available as a player addition or customization to the friend graph. In another implementation, when the system discovers friends in multiple game instances considered for a player, and transfers the player into one of those available game instances, the system might also invite the other friends of the player to transfer to the instance that the player is in.

It will be apparent to one with skill in the art that the recommendation system of the invention may be provided using some or all of the above-described features and components without departing from the scope of the present invention. It will also be apparent to the skilled artisan that the embodiments described above are specific examples of a single broader invention that may have greater scope than any of the singular descriptions taught. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.

It will also be apparent to the skilled person that the arrangement of elements and functionality for the invention is described in different embodiments in which each is exemplary of an implementation of the invention. These exemplary descriptions do not preclude other implementations and use cases not described in detail. The elements and functions may vary, as there are a variety of ways the hardware may be implemented and in which the software may be provided within the scope of the invention. The invention is limited only by the breadth of the claims below.