U.S. Pat. No. 9,839,838

DETAILED DESCRIPTION OF THE INVENTION

The present disclosure describes a number of methods and computerized systems for quick, efficient, fair, and flexible management of an online community. The present disclosure further describes an automated system capable of identifying predetermined conduct. Based on the conduct, the system could take automatic action or flag the players for further investigation by admin staff. As a result of the automatic detection or admin review, the players can be sent to an alternate pool of players for a predetermined amount of time. Alternatively, players may also be banned from playing the game depending on the severity of the conduct.

The system is implemented between a network cloud comprising a single server machine, multiple server machines, and/or a content delivery network communicating with a plurality of player consoles. A player console can be any system with a processor, memory, capability to connect to the network, and capability of executing gaming software in accordance with the disclosed invention. Some examples of a console include: Sony Playstation, Microsoft Xbox, Nintendo Wii, personal computers, and even smartphones. A hardware and network implementation suitable for the disclosed system is described in greater detail in concurrently filed commonly assigned application Ser. No. 13/894,099, entitled “System and Method for Network Gaming Architecture,” incorporated herein by reference.

First, the system comprises two elements, an automated component and a manual component maintained and operated by admin staff. The automated component is used to detect predetermined activities that are deemed to be undesirable. Undesirable conduct includes: bad sportsmanship, bullying, offensive conduct, offensive content, poor network connection, manipulation of stats, bug exploitation, repeat offenders, hacking, piracy, or any conduct deemed by admin staff to be unwanted or harmful to the community. In essence, management of an online community is not unlike management of any society. To fairly and effectively address undesirable conduct, an online community management system must be able to appropriately address each type of infraction though identification, classification, and proportionate punishment. To properly identify and address each type of conduct, the system utilizes a classification system including five classifications: non-cheaters, bad sports, cheaters, repeated cheaters, and banned players. All players are initially classified as non-cheaters. In addition to the classification system, an appropriately scaled punitive system can be automatically implemented to issue appropriate punishment.

Undesirable conduct is segregated into two types of conduct: bad sportsmanship and cheating. Bad sportsmanship relates to conduct that, while not cheating creates a hostile and uncomfortable gaming experience for other players. The main types of bad sportsmanship or anti-social behavior are: offensive or inappropriate conduct over messaging or voice chat services, using offensive or in appropriate user generated content such as artwork or other customizable content, sabotaging team members, quitting during play of a game, or bullying. This type of conduct makes up a large majority of the negative reports from any online community.

To address bad sportsmanship, the system implements several features, a point based bad sportsmanship statistic is provided that is incremented by a negative peer report or certain pre-determined behaviors automatically tracked by the system.

Peer Report System

Due to the amorphous nature of bad sportsmanship, it is difficult for admin staff and game developers to program and create a system that automatically detects every possible instance of bad sportsmanship. Additionally, due to the large number of games being played it is also unfeasible for admin staff to police sportsmanship. Thus the system provides tools for players to police sportsmanship though a peer reporting system. The peer reporting system allows players in the same game to submit a negative peer report against a player for bad sportsmanship. The reporting system can be implemented for example as a dropdown menu accessible at any time during the game. The menu provides players with a list of other players currently in the game. The player first selects the offending player from the menu and then selects either a positive or negative report followed by the reason for the report. The reasons for the report can be as numerous as necessary to address the specific implementation of the system; however, in the present embodiment, players may choose: offensive conduct or “griefing.” Other potential offenses can include: sabotage of game, killing allies (if possible), failure to cooperate with game, purposely dying to give opposing team points, or giving away ally position. A negative peer report from another player automatically increases the player's bad sportsmanship statistic; however, a positive report can decrease the player's statistic. To manage abuses, the system also decreases the influence of a peer report for players submitting numerous reports over a predetermined period of time. If a player reports an inordinate number of abuses, it could be that the reporter is overly sensitive and the impact of their reports should be reduced. This can be done by providing an appropriate and proportionate multiplier to a peer report. In the present embodiment, players submitting more than one report during a match may only increase the offending player's bad sportsmanship statistic by half of the normal value. Alternatively, other incentive based systems can be used in addition or alternative to the current “weighted” system to manage peer report abuse such as requiring players to use game credits or currency to submit peer reports.

Additionally, different types of abuses can be given varying values based on their severity as judged by the implementer of the system. For instance, offensive conduct over voice chat or messaging can be annoying and harmful, but it might be decided that this sort of behavior only contribute 1 point to a player's bad sportsmanship statistic because they can be optionally muted by the other players. On the other hand, conduct that adversely affects the play of the game such as “griefing” can be treated more seriously by increasing a player's bad sportsmanship statistic by 2. “Griefing” refers generally to conduct that negatively affects the play of the game such as: bullying, harassment of players, sabotage of team events, or giving away teammate position. In addition to peer reports, players may also vote to kick an abusive player from the game. Similar to the peer report option discussed above, players may also access a menu of current players and select a player they wish to kick from the game for any reason. If enough players from the game, for example 66%, vote to kick a certain player, then that player is automatically kicked from the game and their bad sportsmanship statistic can be incremented. In the present embodiment the sportsmanship statistic is incremented by 1 for a successful vote resulting in the player being kicked out of a game.

Bad Sportsmanship Automatic Detection

In addition to the peer reporting system described above, the present invention also provides an automatic detection component that can be programmed to identify certain pre-determined activities that are considered to be bad sportsmanship. The program can be executed at the player console or on the developer server. In some embodiments, the developer server is implemented as a telemetry server as part of a cloud network wherein the telemetry server uses other information related to game play to detect bad sportsmanship. In addition to sportsmanship, the developer server can detect cheating as will be discussed in greater detail below. The specifics of the telemetry server and cloud network is discussed in greater detail in concurrently filed commonly assigned application Ser. No. 13/894,099, entitled, “Method and System for Network Gaming Architecture.”

In the present embodiment the automatic detection is done at the player console and transmitted to the developer server to minimize processing overhead to the developer. Many multiplayer games are often cooperative and require the formation and cooperation of large teams, thus it is important that all players in the team are present and cooperate to create an entertaining, balanced, and competitive experience. A common occurrence in many multiplayer games is “rage quitting.” Rage quitting is where players exit a game prematurely after becoming frustrated with the current status of play. This puts their allies at a severe disadvantage and thus also ruins the experience for the remaining players. Even if the player is exiting the game for other more legitimate reasons, it still leaves the other players at a disadvantage and should be discouraged. Thus, the system automatically detects when a player exits a game prematurely and their bad sportsmanship statistic can be increased. There are two ways a player can exit the game: (1) by selecting the exit option from the menu or (2) disconnecting their connection either though turning off their console or internet connection. The latter is considered more detrimental because repeated occurrences could corrupt game files and additionally could be an indicator of rage quitting. Thus, players disconnecting that way may have their bad sportsmanship statistic increased by 2 as compared to players that exit normally who would have their statistic only increased by 1.

Another negative influence on the game, although not related to sportsmanship, is players with a weak or slow internet connection. The system treats these players in the same way as bad sports since these players also need to be segregated from the general player pool. When a player is disconnected due to a connection problem, their bad sportsmanship statistic can be incremented as discussed above. Additionally, the system also records the player's connection speed and also logs the number of times they disconnect. This information can, also be used to match players with similarly weak connections as to minimize disruption to the general player pool.

Bad Sportsmanship Statistic Limit

Each time a player's bad sportsmanship statistic reaches a certain value (such as, 10, 20, 30, or 40) the system issues the player a warning informing the player that they are in danger of being unable to continue participation in the general player pool and instead must play in an alternate player pool. The system allows for flexibility and for players to adjust their conduct by having their bad sportsmanship statistic decrease in one of two ways. For example, the bad sportsmanship statistic could decrease by 1 for every thirty minutes of unreported play. And, as discussed above, positive peer reports can decrease the statistic with the same “weight” attribute based on the frequency of the reporter's reports.

Once the bad sportsmanship statistic reaches a limit, in the current embodiment, of 50, the player is classified as a “bad sport” and automatically placed into the alternate player pool. The classification is done by storing classification information to their player account located in a User Name Space at the developer server which is described in greater detail in concurrently filed and commonly assigned application Ser. No. 13/894,099, entitled “System and Method for Network Gaming Architecture,” incorporated herein by reference. In the present embodiment the classification causes a +1 to be added to the player's hash value which is described in greater detail in concurrently filed and commonly assigned application Ser. No. 13/894,109, entitled “System and Method for Multiplayer Network Gaming,” incorporated herein by reference.

Upon initiation of the game, the player's console downloads any script files from the server and executes an algorithm that produces a unique hash value based on the player's script files. This hash value will be checked by the multiplayer system so that only players with the same hash value are allowed to play together. This prevents players with different script files from playing together and thus potentially causing the game to crash or have errors. The system also checks the player's account to see if there are any additional values to add and in the case of a player classified as a bad sport, a +1 is added to the hash value. Alternately, the number could be added to the data used to generate the hash. Where the system is designed to only allow players with matching hashes to play together, players classified as bad sports cannot play in the general pool since their hash value is now the general pool's hash value +1. However, the other players with the bad sports classification will share the +1 hash value and they can be automatically segregated to play in an alternate pool of players. For embodiments with multiple alternate player pools, different values can be added.

In addition to storing the classification in the player's account, the system also stores a timer that will expire upon the end of the sentence. For the first bad sport classification, the player account is tagged as a bad sport for two days. Thus the player must play in the alternate player pool for two days until the classification timer expires. The system can gradually increment the length of subsequent sentences, e.g., 4, 8, 16, etc. However, players who persist in bad sportsmanship may also be upgraded the “cheater” classification.

Additional punishments could be implemented to deter unsportsmanlike conduct such as the addition of an undesirable “dunce cap” shaped like a paper cone on the player's character's head. Other more severe punishments can include limiting a player's ability to transfer in game credits or the use of personalized content such as decals or emblems. Further still, more tailored punishments befitting of the infraction could be crafted such as automatically muting players who have a significant percentage of their peer reports relate to offensive conduct over voice chat.

The left side ofFIG. 1depicts the bad sportsmanship process flow. All players start in the general player pool and classified as non-cheaters. If they are classified as bad sports based on their conduct as discussed above, the player is automatically transferred to the alternate player pool until certain requirements are satisfied, e.g., their bad sport classification timer expires. Once their bad sport classification timer expires, the players are returned to the general player pool with their bad sportsmanship statistic reset to zero, however the system will retain a history of their classification so that future classifications can recognize the history and increase sentencing accordingly.

Turning now to the right side ofFIG. 1, the cheater classification system will be described. The cheaters classification system utilizes an automated component to detect activities that can be indicators for cheating and compiling a “Potential Cheaters List” for further review by admin staff. Upon a determination by admin staff, the player is transferred to the appropriate pool, either back to the general pool for innocent players or the alternate player pool with a cheater classification for guilty players. The primary difference between the cheaters system and the bad sports system is that the cheaters system does not automatically classify players as “cheaters.” In the present embodiment, cheater classification is preferably done by admin staff with the aid of an automated component. However, it should be understood that in other implementations of the system, certain activities can automatically lead to cheater classification. The automatic cheater classification system can utilize a plurality of threshold checks in conjunction with incremented automatic checks similar to the bad sportsmanship statistic being incremented and threshold values monitored as discussed above.

Potential Cheaters Detection

Behaviors classified as cheating require a wider range of checks that occur both in-game and at the backend. The automated component of the system will perform a plurality of checks in helping admin staff identify players that are potentially cheating. One type of check relates to exploitation of lag to gain an unfair advantage during the game. In the present multiplayer game embodiment, players may exploit delays in information being sent through the multiplayer game system by temporarily disconnecting from the network for short periods of time while they maneuver to an advantageous position to shoot other players. After several seconds of delay, their connection is reestablished, their actions are sent, and the game tries to catch up. This causes players to appear to jump or teleport potentially giving them an unfair advantage over other players. In essence this is the same to players with bad connections and they can be dealt with in the same manner by having their connection speed logged and the number of disconnects tracked. This information can similarly be used to match players with similar connection problems in order to minimize disruption to the general player pool. Additionally, they can be reported as a potential cheater for further investigation by admin staff if temporary disconnects become a recurring problem. This could be implemented using a counter with a minimum threshold before placing a player on the potential cheaters list. Generally players with poor connections do not perform well in the game, thus a secondary score check could be implemented to distinguish between players with poor connections and potential cheaters. Potential cheaters will have similar connectivity issues reported, but will also have an uncharacteristically high score.

Modification of any files such as saved games, profile data, or leader board scores can be automatically detected by the system. For instance, with respect to saved games data, redundancy checks through the use of specialized algorithms that generate unique hash values (CRC number) at the player console can be communicated to the server when the player saves a game, and the same number can be recalled from the server and checked again when the player loads a game to make sure the two CRC numbers match. If there is a discrepancy in the values, the system automatically adds the player to the potential cheaters list. Similarly, for leader board or profile data, the system can implement an automatic redundancy check or alternatively manual checks by admin staff can be employed. If there is any discrepancy, then players are also to be automatically added to the potential cheaters list.

Peer-to-Peer File Modification Detection

In an embodiment of the present invention, a multiplayer match is implemented over a peer-to-peer network which is discussed in greater detail in concurrently filed and commonly assigned application Ser. No. 13/894,099, entitled “System and Method for Multiplayer Network Gaming,” incorporated herein by reference. Each peer performs automatic and autonomous checks against either all or random peers. These checks can take the form of CRC checks as discussed above, or in addition include checks for detecting obvious signs of cheating such as a player taking unreasonable amounts of damage before dying (invincibility hacks), firing large amounts of bullets without reloading (infinite ammo hacks), or moving impossibly fast (run speed hacks). Furthermore, the system can implement CRC checks of critical segments of the console/game memory which control core game logic from a randomly selected player. CRC checks could also be implemented for any game file such as metadata files that control weapon tuning, progression data, experience modifiers, etc. This minimizes the processing time and resources required to run a CRC check. If the CRC numbers do not match, the player is reported. If the player does not respond in a reasonable amount of time, they are also reported. Additionally, if a remote player does an excessive number of requests, their requests are ignored and they are also reported as this may be a sign of a flood attack to invalidate the system by delaying real requests from other consoles. The CRC checks are performed in a low-priority background thread in order to avoid negatively affecting game play or network performance by placing them in a hardware thread different than the main game, streaming, and network threads. All reports are sent to the developer server along with both player's unique ID, i.e., the requesting and responding player, the type of cheat detected, and the relevant CRC data reported. The CRC checks are implemented in the scripting language understood by the system such that any in-game situation could trigger a specific CRC check. For instance, being killed too many times by one player would trigger a CRC request against the weapon files for that player. Additionally the script and checks are implemented such that they do not contain any language or labels that would indicate they are for cheat detection such as, “remote cheat.”

Potential Cheaters List

The automated component of the system compiles a list of players identified as potential cheaters and also compiles information related to the players' game activity including: player ID, total number of violations, leader board scores cleared as a result of scores being attributable to a cheating player, number of times player left mid-game, number of times player voted out of a session, and profile statistics violations.FIG. 2depicts a potential cheaters list in accordance to an embodiment of the present invention.

The admin staff is then tasked with reviewing the player history to make a determination on whether the player was guilty or innocent. If the player is found to be guilty, they are classified as “cheaters” and the appropriate information is stored on their profile within the developer server. Players classified as cheaters do not have their classification automatically removed over time like the bad sports classification. Instead the sentencing and duration (if any) can be manually set by the admin staff. In alternative embodiments, the cheater determination and classification can be automatically done based on a predefined algorithm that takes into account all player activity. If the player is found to be innocent, they are removed from the potential cheaters list and all their current cheater checks are set to be ignored by the system so that they are not automatically placed back on the potential cheaters list.

Banned Player Cheats

Some conduct is so disruptive that the only appropriate remedy is banning the player. Modification of game or executable files and memory modification are extremely disruptive and can harm the entire system, thus upon detection an immediate ban is sometimes necessary. Fortunately, these checks are fairly easy to implement and can be done using the automated component of the system. Similar to the redundancy checks discussed above for saved game data, similar redundancy checks can be used to generate CRC numbers for ISO files or any other potentially modifiable data. Upon detection, the system could automatically ban players or place them into the potential cheaters list.

Gold/XP farming is another ban-able offense and is defined as selling in-game currency for real world currency. Players can also create game modes that give unfair amounts of experience. Any players caught in these acts are automatically placed on the potential cheaters list or banned. To help detect these activities, the system can implement delta checks, i.e., checks on differences between two values. For instance if a player's cash increases by an unrealistic amount over a short period of time, this could indicate they have recently purchased from other player in-game currency. Players who are caught engaging in this activity will be added to the potential cheaters list and have their currency stripped from them. An exception for currency purchased from the developer store can be added.

While banned, players are not allowed to use the online component of the game, however they may still play the offline single player version.

Repeat Offenders

Repeat offenders can have their classification upgraded to “repeated cheaters.” Repeated cheaters are the same as “cheaters” except they will no longer be able to upload stats to the developer server.

Backend Considerations

For instances in which a player believes that their classification or increment of their bad sportsmanship statistic is in error, the player may contact admin staff to have the issue resolved and reviewed. If the player is found to be correct, then the admin may take any corrective measure they see fit.

Matchmaking

In addition to making sure a player's hash values match and that the player is playing in the appropriate pool, the system also allows for other preferences to be added to the matchmaking system. Player's friend list, ban list, bad sportsmanship statistic, age, skill level, and player type (i.e., difficulty level setting) can all be taken in to account such that players are similarly matched with other players of the same preferences. Further, with respect to the ban list, players will not be matched with players that are on their ban list.

The entirety of this disclosure (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the disclosure are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program modules (a module collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.