Method and apparatus for collusion detection

Methods and devices for collusion detection

Method and Apparatus for Collusion Detection

Cross-references to related applications This application claims priority from U.S. Patent Provisional Application No. 61/749,525, which is hereby incorporated by reference. U.S. Patent Application No. 13/110,519 (filed on May 18, 2011); U.S. Patent Provisional Application No. 61/680,168 (filed on August 6, 2012); and U.S. Patent Provisional Application No. 61/642,812 (filed on May 4, 2012) Application) is hereby incorporated by reference.

Some embodiments may relate generally to gaming and/or mobile devices.

Mobile devices, such as cell phones, PDAs, laptops, and/or various other devices, may be used by individuals. Games, such as casino games, sports betting, video games, and/or various other forms of games may be performed.

The following description should be understood as exemplary embodiments and not as patent claims.

A. A method, including: using a computing device to monitor a player's operations in multiple games; using the computing device to generate profile data for the player based on the monitored operations; and using the computing device to determine whether the player is in An action in a second game causes a collusive outcome; in response to determining that the player's action causes a collusive outcome, the computing device determines that the action deviates from the profile; and in response to determining that the action deviates from the profile, the computing device Take collusion prevention actions.

A.1. The method described in claim A, wherein determining that the action deviates from the profile data includes: determining a probability that the action is inconsistent with the player's historical operations by comparing the action with the profile data. A.2. The method of claim A, wherein the collusion result includes: the player transferring a large amount of chips to another player in the second game. A.3. The method described in claim A, wherein determining that the action caused the collusion result includes determining the severity of the collusion based on the collusion result, and wherein determining that the action deviates from the profile data applicable to illustrate the severity, such that for a comparison A decision of low severity would require a higher bias, while a decision of higher severity would require only a lower bias.

A.4. The method of claim A, including determining a possibility of collusion and providing the possibility to a collusion detector. A.4.1. The method of claim A, comprising: in response to determining that the collusion result is a highly serious collusion and deviates significantly from the profile data, determining a high likelihood of collusion. A.4.2. The method described in claim A, including: in response to determining that a) the result of the collusion is not serious, or b) the deviation from the profile information is not significant, determining a low possibility of collusion. A.5. The method described in request A, including: determining a persistent collusion level of the player in the multiple games based on a percentage of possible collusive actions detected in the multiple games, and providing collusion level to a collusion detector.

A.6. The method of claim A, wherein the collusion prevention action includes: providing information to a collusion detector through a user interface to allow the collusion detector to perform at least one of the following: discarding a portion of the second game As a result, the player is prohibited from playing the game, the second player's game is suspended, and the second game is replayed. A.6.1. The method of request A.6, comprising: recording a history of the second game, and wherein the user interface allows the collusion detector to access the recorded game history of the second game. A.6.1.1. The method of request A6.1, wherein the user interface is configured to allow the collusion detector to access the recorded game history in a game context. A.6.1.2. The method of claim A.6.1, wherein the game history allows the collusion detector to reconstruct the second game.

A.7. The method described in claim A includes: storing the profile data in a vector, wherein each dimension of the vector represents the determined behavior of the player. A.7.1. The method of claim A.7, wherein each dimension of the vector includes a game dimension compactness determined by a small blind completion percentage in a poker game. A.7.2. The method of claim A.7, wherein one dimension of the vector includes an aggression dimension, which is determined by a post-flop betting and raising percentage and a post-flop bidding in a Texas Hold'em game. The percentages are compared to determine. A.7.3. The method described in request item A.7, wherein the multiple dimensions of the vector are dimensions of the situation class. A.7.4. The method of claim A.7, wherein the dimensions of the vector are specific to the context in which the behavior is observed. A.7.4.1. The method described in request A.7.4, wherein a background environment of one dimension of the vector is defined by at least one of the following: the player's hole card strength and hand card strength in the background environment. A.7.5. The method of claim A.7, comprising estimating one of the dimensions of the vector when there is insufficient information for that dimension by reference to one or more other dimensions in the vector. A.7.6. The method described in request A.7, including: determining one dimension of the vector by weighting the data so that, with respect to this dimension, more recent games are given more weight than less recent games. Weights.

A.8. The method of claim A, including generating the profile to identify historical actions taken in each of multiple game situations. A.9. The method of claim A, including generating profiles identifying historical actions taken against each of a plurality of types of players. A.10. The method described in request item A, wherein monitoring the player's operations includes: running an electronic platform through which the player can play multiple games with multiple other players and determine which games are actions taken through the electronic platform.

B. A device, including: a computing device; and a non-transitory medium in which a plurality of instructions are stored. When the instructions are executed by the computing device, the device can perform the following actions: monitor a player's performance in multiple operations in the game; generating profile data for the player based on the monitored operations by the computing device; determining that the player's actions in a second game resulted in a collusive outcome; in response to determining that the player's actions resulted in a collusive outcome, determining The action deviates from the profile; and in response to determining that the action deviates from the profile, taking a collusion prevention action.

I. Exemplary embodiments Certain embodiments may enable gaming. For example, one or more users can play a game together. The game may be a competitive betting game such as a card game, a video game, a mahjong tile game (such as Mahjong), a casino game and/or any other game. For example, some embodiments may include a poker card game (eg, Texas Hold'em, Omaha, card games, stud, etc.). Some examples of poker games are given in Application No. 13/110,519, which is hereby incorporated by reference. It should be appreciated that any form and/or combination of games may be used in various embodiments.

Certain embodiments may include games using physical elements such as playing cards. Certain embodiments may include games using virtual elements such as virtual playing cards. Certain embodiments may include any combination of physical and virtual elements. For example, some embodiments may include games played on a physical gaming table using physical playing cards. In this case, the data can be tracked through cameras, card RFID, etc. As another example, certain embodiments may include a game played using virtual playing cards via a computing device. Some examples of such devices are given in Application No. 61/680,168, which is hereby incorporated by reference. Such computing devices may include stationary devices (such as desktop computers or kiosks), mobile devices (such as smartphones), and/or any other device. It should be appreciated that in various embodiments, any combination of devices and/or physical elements may be used in any manner or combination.

Certain embodiments may include one or more collusion prevention operations, methods, devices, and/or other elements. In a competitive game, collusion undermines the integrity of the game and is unfair to other players who are not involved in the collusion. Collusion can be considered cheating in the game and may violate the rules of the game. Players who engage in collusive behavior often take actions to prevent their collusion from being detected. This makes collusion detection very difficult, and the various features of the various embodiments described in this disclosure can overcome the difficulty of collusion detection.

Collusion can take many forms. Some of these forms of collusion include intentionally losing to allow another player to win the game, transferring large amounts of chips from one player to another, playing casually in tournament games instead of competing hard, and playing passively instead of aggressively against a specific player. Tournaments, no-raising on a specific player, teaming up with an accomplice to run a betting pattern to squeeze another player out of the game, and more. Whether a particular type of operation actually violates the rules of the game will be determined by different embodiments. For example, some embodiments may allow for some forms of collusion (e.g., casual play may be allowed, but large transfers of chips and crowding out of others may not be allowed). Other embodiments may not allow any form of collusion. However, some embodiments may allow all forms of collusion. These examples of collusive behavior are non-limiting examples only, and other embodiments may involve any collusive behavior.

Collusion detection can also take many forms, that is, a collusion detector can take many forms. For example, in some embodiments, one or more players and/or games may be monitored to determine the likelihood of collusion. Such monitoring may include receiving data about a game (e.g., from data sources such as a game server, players, cameras, RFID readers, data collection devices, random number generators, or game outcome engines, etc.). This information can be recorded and analyzed to identify possible collusion. Such possibilities can be flagged for investigation and/or tracked for pattern recognition. After a possible collusion is identified, appropriate actions can be taken (e.g. based on the likelihood and/or severity of the collusion). For example, such actions may include: banning the player, stopping the game, conducting an investigation, notifying casino officials, replaying the game, invalidating the results, expelling the player from the tournament, preventing the player from continuing to play other games, etc. It should be appreciated that the collusion detection examples are only non-limiting examples and other embodiments may include any collusion detection element.

It should be appreciated that the various elements of the described embodiments may be combined in any manner and that the examples provided here are not limiting. It should also be recognized that although certain examples refer to poker games, tracked game characteristics, collusive behavior, collusion detection methods, responses to collusion, etc., these descriptions are only non-limiting examples.

In certain embodiments, collusion detection may include attempting to determine changes in gaming style, betting operations, or other behavior. Collusion detection can include evaluating game operations over time to detect fixed patterns and/or changes in patterns, creating profiles of player behavior in specific situations, etc. An example of player profile and index elements is given in Application No. 61/642,812, which is hereby incorporated by reference. Collusion detection may include identifying cooperating players in competitive games that do not allow cooperating based on analysis of identified behavioral dimensions and/or tracked actions in one or more games. Some embodiments may include tracking player behavior, collecting player statistics, detecting game patterns, using this information to detect collusion, preventing detection based on detected collusion, etc. Certain embodiments may use tracked information to study collusion and learn previously unknown collusion techniques that can be detected and/or prevented, thereby improving the fairness of the game. This approach may be difficult to detect without the use of comprehensive tracking and/or analysis elements.

Some embodiments may include recording information about one or more games. Such information may include actions taken in the game, cards dealt in the game, players in the game, bets placed in the game, results of the game, positions in the game and/or any other game-related information. Figure 3 shows some sample information that can be stored about a game. This information may be used to recreate a game at a later date, to conduct analysis to determine collusion in that game or other games, to study collusion, and/or for any other purpose. It should be appreciated that this example of storing game information is only a non-limiting example, and other embodiments may not store such information, or store different information.

Further examples of information that may be determined and/or stored about a game, a game round and/or a tournament may include: game type, tournament type, limit type, whether it is a tournament, whether re-buys are allowed, etc. Further examples of information that may be determined and/or stored about a game, a round and/or a tournament may include: blind positions, blind status, which cards were used to make up a player's hand at a certain point in the game , prize pool amount, stakes, etc. Further examples of information that may be determined and/or stored about a game, a round and/or a tournament may include: hand strength (which may be relative and/or absolute), whether a pair is present, whether The possibility of a straight or a flush, whether cards of the same suit are dealt to a player, the strength of the hole cards, the level of the player's hand, the strength of one player's hands compared to other players, the cards that may be drawn, and the community cards that are dealt ,etc.

Some embodiments may include recording player operation information in one or more games, rounds, tournaments, etc. This player action information can be stored in a vector or other data structure. The vectors in this profile describe a player's actions or behavior in the game. Some example dimensions may include tight vs. relaxed, aggressive vs. non-aggressive, bluffing, semi-bluffing, long game, ties, player position, hand strength, community card strength, possible ties Strength, player action (pre-flop and/or post-flop), player betting skills (pre-flop and/or post-flop), turn-specific profiles, game-general profiles and/or any other dimensions. A dimension might be for a certain round of play, or for the entire game. The vectors or other data structures describing each dimension in each case can be stored in a database. This information may be used to construct a player profile and/or may be accessed to investigate collusion and thereby review a player's prior behavior. This information may be determined for each game and/or for each player in each game (eg, all players, all games, all players except trusted players). Figure 4 shows an example data structure that can be used to record player behavior in a game. It should be recognized that this dimension and data structure is only a non-limiting example. It should also be appreciated that using and/or recording such information is only one non-limiting example, and other embodiments may directly create player behavior profiles without recording or generating such specific game or round-level data.

Figure 5 illustrates an exemplary method of determining hand strength that may be used in certain embodiments. As mentioned above, some embodiments may include hand strength dimensions or other information. Figure 5 illustrates, in some embodiments, how to determine the hierarchical strength ranking of hidden cards in Texas hold'em poker. In some embodiments, the determination of hand strength may be absolute and/or relative to the hand strengths of other players.

In some embodiments, hand strength may be determined based on the community cards. If all or more of the cards come from community cards rather than from secret cards, the hand may be of lower strength. It should be appreciated that this demonstrated strength type is only a non-limiting example, and some embodiments may not even include this type, but rather each combination has separate strength information or does not include any strength dimensions.

Certain embodiments may include determining detailed game information for one or more games, and/or contextual game information. Such information may include inputting information about player actions into the game context. This information can be determined for each game and/or for each player in each game. In some embodiments, this information may be determined individually for each player during each game round, thereby identifying the level of player behavior during each game round. For example, such information may include: bluffs and/or semi-bluffs, raises, continuations, delays, traps, folds, blind steals, continuations, exclusions and/or defenses , blind defensive operation, passive operation, intentional slack operation, intentional follow-up operation, active operation, etc. Figure 6 illustrates an exemplary data structure and set of operations that may be used to record such information in some embodiments. With this information, a complete player profile can be generated for each player. It should be recognized that the identification of such information, the structure of the data, and the information are only non-limiting examples. Other embodiments may not include such operations, or may determine different information stored in different data structures as needed. In some embodiments, such information may be used to replace, supplement the information described in Figure 4, and so on. Such information may be the same as or different from the information described in Figure 4, or may be its supplement, replacement, etc.

An exemplary method of determining the tight dimensions of a game may include determining the completion percentage of a small blind. If a player spends a long time watching the flop from the small blind, that player may be playing loosely. If a player spends less time watching the flop from the small blind, that player may be playing tighter. It should be appreciated that examples of such compact dimension indicators are non-limiting examples and other methods of determining compact dimensions may be used as desired.

An exemplary approach to determining player dimension positivity could include determining postflop bets and raises versus calls. For example, in some embodiments, a post-flop bet can be distinguished from a raise by a post-flop call, thereby determining an aggressiveness factor. The higher the number, the more motivated the player is. The lower the number, the less motivated the player is. A player with a positivity factor <1 can be considered a passive player. A player with a motivation factor above 1.5 is considered an aggressive player. A player with a motivation factor between 1 and 1.5 is considered a moderate player. It should be appreciated that examples of such positivity indicators are non-limiting examples and that other methods of determining loose positivity may be used as desired.

Any combination of information may be collected for type determination, and/or collected as part of a player profile and may or may not be used to determine a player style type (e.g., may or may not be used to determine a type for general style information). Some examples could include: how often a player performs a certain action in a specific situation, how often a player bets when a player needs to perform an action first, how often a player bets when targeting a specific player or a player with a specific play style, a player How often a player raises before the flop, how often a player raises when he is the last player to act preflop, how often a player calls a preflop when the big blind is raised, how often a player raises first frequency of raising first when a player is in middle position, frequency of calling preflop when a player has (absolutely and/or relatively) high and/or low cards, frequency of raising when a player has How often you call after the flop with high and/or low hands. It should be appreciated that these are only exemplary blocks, and various embodiments may include more, less, different information, etc. as needed to illustrate determining possible player behaviors. Some embodiments may include several situations in which an operation may occur, and the number of times an operation occurs in these situations, to determine a block. This information may be updated as more information becomes available.

As an example illustrating more possible dimensions, profiles, and levels of completion, some embodiments may include determining: the total number of hands (#H), the percentage of players who voluntarily put money into the prize pool (a player voluntarily put money into the pot pre-flop) % of games put into the prize pool), % of preflop raises, % of preflop three-bets (% of times a player continues to raise after facing a preflop raise), a player The percentage of pre-flop raises to the unopened pot in the cutoff/button/small blind position, a player's motivation factor (as in the example above), the percentage of post-flop continuations (a player's post-flop continuation bets) The percentage of times a player continues to bet on the flop after a pre-card raise), the percentage of times a player shows up (a measure of whether the player is playing it safe or aggressive), the increase or decrease in the player's stack, etc.

As an example of determining the percentage of money put into a prize pool voluntarily, some embodiments may count the number of times a player puts money into a prize pool unnecessarily. For example, the blinds paid by a player may not be calculated into this percentage, but rather towards the calculation of raises, bets and/or calls. This statistic can be used to measure a player's play style in a compact dimension. Tight play might have a rate below 24%, moderate play might have a rate of 24-28%, slightly relaxed play might have a rate of 28-33%, and relaxed play might have a rate of 33% and above. It should be appreciated that such instances of voluntarily placing money into a prize pool are only non-limiting examples. Other embodiments may include a dollar amount, or may calculate other operations such as including blind bets.

Determining the percentage of time a player shows his hand can include determining the number of times a player does not fold after seeing a flop. For example, you can determine the number of times the player continued after seeing a flop, and determine the percentage of times the player did not fold, thereby calculating the percentage of time the player showed his hand. When the percentage is higher than 39%, it can be considered aggressive. When this percentage is below 39%, it is considered a safe play style. It should be appreciated that the examples of such showdown calculations are non-limiting examples only and that other methods of conducting such showdown calculations may be used as desired.

It should be appreciated that any action can be determined or analyzed based on player behavior. More actions that can be tracked (e.g., every round, every game, every tournament, etc.) can include aggressive actions (first action, raise, reraise, third raise), compact actions (e.g., Fold to the big blind or open bet, fold to raise, fold to reraise, fold to third raise), passive actions (check to flat call, check to leader, raise) Call when calling, fold when making the big blind), relaxation operations (such as calling when flat, calling when raising, calling when reraising, calling when raising for the third time), blind stealing operations (e.g., when the player is in late position and there are no other raisers, raising even if he holds a small card), blind defensive operations (e.g., defending the big blind, folding when the big blind is over), crowding out operations ( For example, raising before and then calling one or more times can realize re-raising when being squeezed out), crowding out defensive operations (for example, following a raise before and then re-raising, following a re-raise when being squeezed out) , which can track continuation operations (e.g., continuation bets, pass continuation bets, bet/check followed by a raise to a raise, bet/check followed by a fold to a bet/raise, players who raised in previous rounds and in Betting/raising on the current round), can track against continuation operations (such as betting on the opponent of the previous operation, checking on the opponent of the previous operation, folding on the continuation bet, raising on the continuation bet), and tracking bluffing operations ( A player who bets or raises with a very small hand), can track semi-bluffs (e.g. a player who bets or raises with a normal hand), can track checks and raises (a player who has a big hand) A player checks and then raises), tracks stalling actions (e.g., a player with a high hand checks and then follows all raises), tracks showdown actions (e.g., a player folds a high hand or a very large hand) license), and/or any operations can be tracked.

These operations can be tracked collectively, and/or can be tracked based on the context in which they occur. For example, betting operations can be tracked in different contexts to determine a profile of a player's behavior in specific situations. For example, information can be determined about a player who raises when he has a high hand, raises when he has a low hand, folds when he has a high hand, folds when he has a low hand, and what actions are taken for players with a specific playing style. Betting actions (e.g., against Lions), betting actions taken against a specific player.

For example, you can determine a player's playing style when holding a trump card. In this case, players usually choose to raise or check-raise. However, every player handles this situation differently, for example some players will typically slow down the game when they have such a big hand. Tracking trends when a player is not colluding with teammates prevents confusion between a valid stalling game and collusion.

As another example, a player's playing style can be determined when in a late position. It is certain that it is not normal for a player to attempt to steal the blinds by raising at this point, and the likelihood of this tactic being used later in the tournament will increase. If the big blind raises again, tracking this trend prevents confusing a valid bluff or semi-bluff with two players working together against the middle player.

An example of determining playstyle could include determining that when a player sees other players playing tight, that player also takes an active role against them. Another player's actions against that player can be further determined, and the same aggressive actions can be taken against that player. Other players may get caught between these two aggressive players, but by tracking the player trends, it can be determined that there is no collusion between the two aggressive players, it is simply their play style in this particular situation.

Another example of determining playstyle in a specific context might include determining what a player appears to be playing casually. For example, a player may have a better hand but just happen to get a big hand by drawing a straight or a flush. However, a player may not realize this and fold that big hand. This in itself looks like collusion, but by comparing previous game profiles, it can be determined that the player has not engaged in collusion and may just be an inexperienced player who made a mistake.

Therefore, any profile may be tracked to determine a player's profile for a specific player and/or situation. This information can be used to determine a player's type. This information can be determined for each situation at any scale, so it is possible to know what a player might do in any given situation and/or generally.

Some embodiments may include determining player style over time. Such information may be determined based on player operation information in one or more games (e.g., based on the above-recorded operations and/or game information). This player play style information may be for all gaming contexts, and/or context-specific. For example, this information may indicate a player's overall playing style in a game of poker. As another example, this information may indicate the style of play in a specific situation (e.g., against a specific player, against a specific player, a specific starting hand strength, a specific community hand strength, the entire game table, etc.) . This information can indicate a player's betting trends over time. This information can be used to determine a player's collusion. For example, if a player inexplicably deviates from his style and takes an action that appears to be collusion, it can be determined that the player is likely to be involved in collusion.

As more information is collected, predictions of player behavior will become more accurate. Some embodiments may require approximately 30-40 hands to form an accurate player profile. Certain more specific or rigorous dimensions of player behavior may require more hands to accurately determine (e.g., approximately 150-400 hands). Various dimensions may take different amounts of time, depending on how often a situation occurs, or how specific a dimension is.

Information about one dimension can be used to guess about another dimension. For example, if a player is a tight and aggressive player in certain situations, he can be considered to be a tight and aggressive player in situations that have not yet occurred. Over time, the collusion detection system in some embodiments can more accurately guess a player's type and have less information on new players. The system can learn how to categorize players based on the previous types of others. Over time, a system can determine correlations between playstyles in one situation and other situations and use that correlation information to populate profile information that does not yet exist.

Figure 7 illustrates an example of determining player style that may be used in certain embodiments. In this example, players can be divided into nine different style types based on their historical actions. For example, if a player is relaxed, motivated, and enjoys bluffing, he could be called a "Lion." By analyzing the game operations, if it is found that a player performs pre-flop raising operations more than 8% of the time, the motivation factor is greater than 2, and the probability of voluntarily putting money into the prize pool is equal to or less than 20%, the player can be identified for the lion. It should be appreciated that the various types shown in Figure 7 are only non-limiting examples. It should also be appreciated that the demonstration dimensions used to determine the type of demonstration are again only non-limiting examples. In different embodiments, any number of types, or no types at all, may be used. In various embodiments, any gameplay style characteristics may be used to determine genre information. As shown, different types can be identified using different characteristics, or all using the same characteristics.

In some embodiments, as shown in Figure 7, a player's gaming style may be determined based on different gaming contexts. In this example, a player exhibits different play styles at a full table, a shorthanded table, and a heads-up situation. A player may have the same play style in all situations, or other embodiments may include only one play style determination method for all games. In still other embodiments, this determination of play style may be player-specific. For example, a play style can be determined for a specific turn (e.g., pre-flop play style, post-flop play style, etc.), a play style for other player types (for a typical "lion" play style), a play style for a specific Playing styles that determine hand strength (e.g., playing styles when the board is weak and holdings are small), Playing styles that determine specific table positions (e.g., big blind, small blind), Determining the time of day Play style over time, determine play style for a certain game type (e.g., tournament, non-tournament), determine play style at a certain level within a tournament, determine play style at different chip sizes (e.g., most chips, least of chips, average number of chips), determines the style of play at any given level in any situation.

In some embodiments, determination of game actions, player actions, and/or player style is ongoing. For example, when players play new games, information about those games will be received and stored. This information can be used to update player style information, so that player style information can be updated with the latest information at any time to indicate changes in player behavior and evolution of style. In some embodiments, player actions may be given a certain weight based on time. In some embodiments, because player style may naturally evolve over time, newer player actions will be given higher weight in determining player style. For example, some embodiments may ignore information older than six months (e.g., unless there is no or insufficient current data). As another example, some embodiments may give full weight to the most recent data, while older data may receive lower weights. Sometimes, data may not be assigned any weight (e.g., if there is sufficient information to make a determination without the data). In some embodiments, older data may be used if there is insufficient information to conduct a complete analysis (e.g., if a particular situation has not occurred for a player in the past year, then more than one year of information to determine the style in this case). Thus, in some embodiments, continuously updated style information may be maintained for a player to indicate the evolution of his or her playing style.

Some embodiments may include receiving game information. Such information may be received after determining a player profile based on previously received game information. New game information can be analyzed to determine whether collusion exists. This determination of possible collusion can be made by referring to previous game information and/or player style information. Therefore, as game information is received, collusion behavior can be continuously determined, and player style information can be continuously updated.

Some embodiments may include identifying possible collusion in a game. Figure 8 shows an example data structure that can be used to identify and/or store the possible collusion behavior of each player in each round of the game. For example, whether a player engages in negative play, large chip transfers, exclusionary play, or card sharing may be determined based on actions performed by that player during or up to that round of play. This determination may or may not take into account player style information. It should be appreciated that in various embodiments, any form of collusion, collusion operations, or determinations may be performed, and these are only non-limiting examples.

For example, in some embodiments, when a player should not lose the game (e.g., based on the cards in his/her hand), but instead transfers a large amount of chips to another player, this may be determined to be a large transfer time. . If a player takes a non-aggressive move when he should have acted aggressively (e.g., based on the better or best hand he has), this is determined to be a negative tournament event. It should be appreciated that these limit examples are non-limiting, and in various embodiments, any method may be used to determine whether a certain operation in the game is a possible collusion behavior.

For another example, in some embodiments, if a player transfers a large amount of chips to another player and his operation does not conform to the player's gaming style, it may be determined that this is a possible large-scale transfer operation of chips. Likewise, if a player performs a negative action when, based on his playing style in a situation, he should be performing a non-passive action in a situation, that player can be determined to be playing passively. It should be appreciated that these examples of determining collusion by reference to player play styles are only non-limiting examples.

Certain embodiments may include determining a level of collusion (eg, likelihood or severity). For example, a collusion may be rated higher or lower depending on the amount of money involved (e.g., the higher the amount involved, the higher the severity). As another example, a likelihood level may be determined based on the degree to which an action diverges from a style or expectation. This possibility can be further determined based on the strength of an expectation (e.g., if the expectation that an operation may be performed is very high, but is not performed, the probability of collusion is higher; if the player always performs a certain If the player performs an action, but does not perform it, the probability of collusion is high; if the player performs an action, which is only slightly more likely than not performing it, but does not perform it, the probability of collusion is low). The accumulation of multiple collusive acts between a group of individuals can be used to determine likelihood and/or severity (e.g., the more collusive acts by a player, the higher the likelihood).

Certain embodiments may include determining that, for an ongoing gaming table, game, or tournament, possible collusion may continue to be determined based on operations at that gaming table, game, or tournament. For example, as a game or game table continues, more possible collusion actions may occur or be used to affect the collusion rating for that game, game table, tournament, etc.

Some embodiments may include an ongoing collusion rating. Certain embodiments may identify total operations and a subset of those operations as collusion between the same group of people. For example, some embodiments may determine that the Y event may be collusive behavior. In some embodiments, this information may explain the player's past play style. In other embodiments, some of these collusive behaviors can be removed from the equation based on historical styles (e.g., an analysis can be performed to determine which parts of the Y operations match the player's style and thus can be removed from the collusive behavior equation removed). In yet other embodiments, all possible collusive behaviors may be used in this equation, whether consistent with style or not. The total X operations can be divided by the Y value to determine a collusion percentage.

Certain embodiments may include other persistent collusion ratings. For example, collusion severity, collusion likelihood, etc. may be used. The collusion percentage may be one element and/or all elements of a collusion determination method. For example, in certain embodiments, amount, percentage of collusive operations, likelihood of collusion, and/or any other factors may be combined and/or used individually to determine a collusion issue.

Some embodiments may include determining that a collusion rating meets a certain problem threshold, indicating that collusion may have occurred. After this is determined, one or more actions can be performed. For example, you can issue a warning, notify an administrator, ban a player, reset a game, etc.

For example, if the number of collusions divided by the total operands in a collusion percentage is higher than a certain threshold percentage (such as 1%, 0.001%, 10%, etc.), it can be determined that a collusion event may have occurred and an anti-collusion operation can be triggered . As another example, in some embodiments, if a severity and/or likelihood rating exceeds a certain threshold (e.g., 10% likelihood of collusion, high severity involving large bets), certain operate. In some embodiments, there may be a relationship between the amounts involved and the likelihood of collusion such that a lower likelihood threshold is required when higher amounts are involved. It should be appreciated that these instances of triggering an operation are non-limiting examples only.

Certain embodiments may include providing collusion rating information to one or more users of a collusion detection system. For example, collusion rating information (e.g., likelihood, severity, percentage, overall rating, etc.) for a game table, a player, a game, a tournament, etc., may be provided to an anti-collusion expert. This user can obtain more information to illustrate the analysis of collusive behavior.

Figure 9 shows a sample interface that can be used to display collusion information. This interface can display professional information about collusion in an ongoing game (e.g., within a tournament). These include a graphical representation of the physical or virtual poker table where the game is being played. Game tables can be displayed in columns based on game restrictions or other game features. Game tables can be number-marked for easy identification. Use dot indicators as shown to show the number of players around the table.

A collusion indicator can be placed in the center of each gaming table (or anywhere else) as shown. The collusion indicator may simply indicate the collusion rating on the game table (eg, likelihood of collusion, number of collusion incidents, severity of collusion, any other type of collusion rating). Game tables can be color-coded based on collusion ratings to help users identify those tables that may be exhibiting collusion.

Users of an anti-collusion system can obtain specific information about one or more games on the gaming table. For example, a user can click on a game table on the interface in Figure 9 to obtain specific information about the game table. Figure 10 shows a sample interface that can be used to provide specific information to the user. This information can indicate collusion that has occurred at that game table each time a game is played. This information may include identifying information about game assets that have been played, as well as information about each collusion event that has been detected in each game. Collusion events in this interface can be marked with color codes to indicate likelihood and/or severity.

In some embodiments, a user may obtain specific information about a game and/or collusion event. For example, by clicking on a specific game or collusion event in the interface of Figure 10, the user can obtain specific information about the game and/or event. For example, an interface can be displayed to inform the user to restart an event and re-calculate the statistics of tracked events; information about previous games and/or events, players in the event, correlation of historical events, and the status of the game when the event occurred. Operations, game table information regarding the event, relationships between players involved in the event, information used to determine collusion, and/or any other information. Information can be arranged and displayed in any order, such as by importance, time, etc.

Figure 11 shows an exemplary interface that can be used to provide game and/or event information to the user. The interface can display information about a collusion event, other events, the game in which the collusion event occurred, other games, etc. This interface can display any information or games that the user chooses to use to investigate collusion.

As shown in the figure, the event types and players involved in the event can be displayed through this interface. In this example, a negative match collusion event has been detected because when John bets, Gus, who has a strong hand, chooses to check rather than raise. This determination is made because players typically raise in this situation, and/or Gus has raised before in similar situations.

Information about each player's gaming style can also be displayed. For example, in a graphical interface, each player's avatar indicates that player's play style in that particular situation. This play style may correspond to the type in Figure 7. In addition, as shown in the figure, specific information can be displayed for each player, such as the number of hands dealt, the percentage of times a player made a preflop raise in a specific situation, or any other action in which the player voluntarily put money into the prize pool frequency, positivity factor based on the number of times a player raises and calls, the percentage of times a player shows up, the percentage of times a player wins (or shares the prize pool), etc. Each such statistic may be an overall statistic to any extent, and/or a statistic related to a specific situation (e.g., type of hand instance with a hole, possession of a specific hole, against those styles of players, etc.). In some embodiments, collusion events and/or game event information at a gaming table may be displayed. For example, in the graphical interface, the center grid displays the number of collusion events that have been detected and specific game operations. Display any information as needed.

This information can be used to determine incidents of collusion. For example, a user can view this information and estimate whether collusion has occurred. In some embodiments, the user may be a status supervisor assigned to monitor collusion. In other embodiments, the user may be a collusion expert assigned to maintain the integrity of the game. Any information a user desires can be recorded and displayed through an interface, allowing the user to determine whether collusion has occurred.

In some embodiments, users of such systems can control a system to perform anti-collusion operations. For example, such actions may include: banning the player, stopping the game, conducting an investigation, notifying casino officials, replaying the game, invalidating the results, expelling the player from the tournament, preventing the player from continuing to play other games, etc. It should be appreciated that the collusion detection examples are only non-limiting examples and other embodiments may include any collusion detection operation.

Although some embodiments are described in which collusion activities are monitored by collusion experts, it should be recognized that these embodiments are only non-limiting examples. Certain embodiments may include an automated anti-collusion system that may automatically take anti-collusion actions and/or suggest a user for confirmation based on player actions. Certain embodiments of such systems are described in this patent. As another example, certain embodiments may include a system in which one or more actions may be taken based on a collusion rating (eg, collusion likelihood, collusion severity, and/or collusion operand). For example, if a player has a high probability of collusion (e.g., 90%, 99%, 95% chance, etc.), that player can be automatically banned. If the collusion severity is high (e.g., $10,000 bet, all bets in the game, maximum bet at a game table, $1,000 bet, any other bet threshold) and the likelihood is moderate (e.g., 40% chance, 60% possibility, etc.), it will prompt the game to be played again. If some collusion operations involve two players reaching a certain threshold (e.g., 10% of collusion operations, 1% of collusion operations, 0.5% of collusion operations, 0.1% of collusion operations, etc.), these two players can be prevented from doing so in the future. Players participate in the same game together. It should be appreciated that any set of thresholds for any input collusion rating can be applied to trigger any action, as desired.

Certain embodiments may include an expert system that can learn player behavior recognition and/or collusion behavior triggering mechanisms. For example, such a system may include a rules-based system. Such a system can implement a Bayesian belief network. Such systems can be programmed using LISP-like languages such as CLIPS.

For example, such a system could set an initial set of thresholds for determining player style and/or triggering anti-collusion actions (such as discussed above in relation to the percentage of times that high likelihood, high severity, voluntarily put money into the prize pool) . Such a system can set up an initial set of relationships between these thresholds and input information. These relationships and/or thresholds may change over time. For example, a threshold or probability will decrease over time before a triggering action occurs. This reduction may occur when the system determines or is informed that no collusion has been detected (e.g., because of a user-operable trigger mechanism in a hybrid automatic/manual system). Over time, the manual aspect of such a system will decrease as the expert system learns how to detect collusion like an expert anti-collusion user. Likewise, the expert system can implement new rules or relationships that explain why an expert user triggered a certain action (e.g., it can implement a rule that triggers based on an unexpected relationship, such as game table location, given that the game table was originally thought to be Location does not affect collusion, but game table location explains why an expert user triggered an anti-collusion warning). The regulator's determinations can be input into such an expert system and used to develop new rules (e.g., if the regulator determines when an action is triggered, if the regulator determines an action to be collusive, etc., a relationship can be established to explain such determination). A determination that a wrong collusive action was taken can serve as input to further train such an expert system (e.g., if the system itself made the determination, which later turns out to be wrong, the system can adjust its rules if A user of the system makes an incorrect determination, and this information can be used to train the system). It should be appreciated that the various examples of machine learning are only non-limiting examples, and other embodiments may include any artificial intelligence components (eg, neural networks, genetic algorithms, etc.), or may not include any such components.

Certain embodiments may include a collusion detection system implemented by one or more computing devices. Such computing devices may include any number of machine-readable media (e.g., media capable of storing data structures and/or instructions), any number of processors, modules, engines, servers, network interfaces, blades, terminals , Internet-connected devices and/or components, and any combination of the above. For example, such a system may be part of a gaming system through which users can place bets on games (e.g., via a mobile device, via a computing device, at a physical location, etc.). The system may receive data (e.g., over a network, captured by a camera, input by a user, determined by a gaming system's processor, etc.). For example, in some embodiments, in-game events may be determined by a game system's game event engine. Such events may be displayed to players accessing the system through remote devices and logged by a collusion detection engine of the game system. Players can perform actions through the device on which the game is played. This action may be received by the game system over a network and used to facilitate gameplay through interaction with the game engine. This operation may be logged and/or analyzed by a collusion detection engine. A collusion detection engine may control a game service and/or terminal to perform operations and/or display information related to determined collusion behavior. It should be appreciated that the examples of various systems and/or elements are non-limiting examples only and that other embodiments may be implemented on any device. For example, there are various capabilities for playing games and/or detecting traditional collusion in games, all of which can be applied to any number of computing devices operated by the same or different entities (e.g., a supervisor can run a collusion system, a A game provider can run a game system; a game provider can run both systems; a collusive service provider can run a collusive system to provide services to game providers running collusive systems, etc.).

Certain embodiments may include a method that may be performed (eg, by a computing device). Figure 12 illustrates an exemplary method that may be performed in certain embodiments. Such a method may include determining events in a plurality of games, determining actions performed by a player in the plurality of games based on those events, determining a profile of the player based on those actions, and determining future actions in the game based on whether each player action deviates from the player profile. Whether its operations constitute collusion, display information indicating possible collusion, and/or take anti-collusion actions if collusion is determined.

As shown at block 1201, some embodiments may include determining multiple in-game events. For example, game operations, game results, distributed cards, etc. in multiple games can be received. Various exemplary game information is described herein. This information may be stored and/or processed as necessary.

As shown at block 1203, some embodiments may include determining actions performed by players in multiple games based on events. For example, bluffing actions, raising actions, negative play actions, etc. can be determined based on events that occur in the game (eg, including what the player did in the game). What a player does can be input into the context based on the game state. This disclosure describes various examples of determinable player actions. This information may be stored and/or processed as necessary.

As shown at block 1205, some embodiments may include determining a profile of the player profile for the player based on the operations. For example, a player's behavioral profile may be determined to any degree of detail. This disclosure describes various examples of determinable behavior patterns. For example, some embodiments may include determining a play style for each player in each possible situation. As another example, some embodiments may include statistics that determine the percentage of times a player performs various actions in specific situations. This information may be stored and/or processed as necessary.

As shown at block 1207, some embodiments may include determining a player's potential for collusive behavior in future games based on whether actions deviate from the profile of the respective player profile. This disclosure describes various examples of determining collusion based on profile information. For example, some embodiments may include determining that an action is a possible collusion because it is a typical collusion action and deviates from a player's typical behavior in a particular situation (e.g., the player would not perform that action most of the time. Action, 75% of the time the player does not perform the action, most of the time the player performs a different type of action, the player has never performed the action in this situation before, etc.). Certain embodiments may calculate ongoing collusion based on ongoing monitoring of the game and assign an ongoing collusion rating to a game, table, tournament, etc. Some embodiments may include providing a certain rating for a possible collusion behavior, such as severity, likelihood, trend or pattern based on persistent collusion operands, etc.

As shown at block 1209, some embodiments may include displaying information indicative of possible collusion and/or taking anti-collusion actions upon determination of collusion. This disclosure describes various examples of display interfaces that can be used to present such information. This disclosure describes various exemplary actions that can be taken after different collusive behaviors are determined. For example, play at a game table can be paused based on its collusion rating reaching a certain threshold.

It should be appreciated that this exemplary method is only a non-limiting example, and other embodiments may include different methods with different orders, more, less, different, the same, similar operations, or not include any such method.

It should be appreciated that while this disclosure describes various examples of various functions and implementations, these examples are non-limiting examples only. Other embodiments may include the same examples, examples combined in different ways, or none at all.

It should be appreciated that although the example given is Texas Hold'em, other embodiments may not be limited to this game. For example, certain embodiments may include thirteen card games, stud games, or card games, and/or any form of poker game. It should be appreciated that although the examples are given for the game of poker, other embodiments may include any card game. For example, certain embodiments may include a game of baccarat, a game of blackjack, and/or any other card game. It should be appreciated that although some examples are given of card games, other embodiments may include any type of game. For example, certain embodiments may include a game of Mahjong, a game of dominoes, and/or any other card or non-card game.

In non-Poker embodiments, different types of games may be monitored within appropriate scopes, different triggers or determination points may be used within appropriate scopes, different actions that may be performed within the games may be monitored, etc. It should be recognized that Texas Hold'em is used as an example because of the numerous demonstrations and types of collusion that may occur in this game. One of ordinary skill in the art will recognize that these examples may be applied to one or more other game types according to different rules.

A system for monitoring collusion and taking collusion prevention actions may include a system for operating a gaming system. For example, a tournament game engine operated by Cantor Gaming may include a related collusion detection module running on the same or a different computing device. Therefore, information about the game can be monitored by communications between these systems. In various embodiments, these systems may be independent of each other or operated by different companies, allowing a collusion module to be run jointly or remotely through a gaming platform as desired.

The following sections are illustrative of the invention.

II. Terminology The term "product" refers to any machine, article and/or composition of matter unless expressly stated otherwise.

The term "process" refers to any process, algorithm, method, etc., unless expressly stated otherwise.

Every process (whether a method, algorithm or otherwise) inherently includes one or more steps, and therefore all references to "steps" of a process inherently include references to the term 'process' and similar terms. Correspondingly, the process 'steps' in the request also have sufficient prerequisite basis.

The term "invention" has a similar meaning to "the invention or inventions disclosed in this application" unless expressly stated otherwise.

The terms "one embodiment," "an embodiment," "the embodiment," "this embodiment," "one or more embodiments," "certain embodiments," "particular embodiments," "a certain embodiment ", "another embodiment" and the like mean "one or more (but not all) embodiments" of the invention unless expressly stated otherwise.

The term "variant" of an invention refers to an embodiment of the invention unless expressly stated otherwise.

Reference to "another embodiment" when describing an embodiment does not imply that the cited embodiment is a mutually exclusive alternative to the other embodiment (eg, one embodiment described in the previously cited embodiment) unless Otherwise clearly stated.

The term "including" and variations thereof means "including but not limited to" unless expressly stated otherwise. For example, the sentence "The combination includes a red widget and a blue widget" means that the combination includes a red widget and a blue widget, but may also include other things.

The term "consisting of" and variations thereof means "including and limited to" unless expressly stated otherwise. For example, the sentence "The combination consists of a red widget and a blue widget" means that the combination includes the red widget and the blue widget, but not anything else.

The term "constituting" and its various variations refers to "component parts, elements or building blocks" unless expressly stated otherwise. For example, the sentence "The red widget and the blue widget form a combination" means that the combination includes a red widget and a blue widget.

The term "exclusively constituted" and its variations means "exclusively constitutes a part thereof, its only elements or parts", unless expressly stated otherwise. For example, the sentence "The red widget and the blue widget exclusively form a combination" means that this element contains only the red widget and the blue widget, and not any other parts.

The terms "a", "an", "the" and "the" refer to "one or more" unless expressly stated otherwise.

The term "plurality" means "one or more" unless expressly stated otherwise.

The term "in the present invention" means "this application including the content incorporated by reference" unless expressly stated otherwise.

For the phrase "at least one of", when it modifies multiple things (such as an enumerated list of things), it refers to one or a combination of more of these things, unless explicitly stated otherwise. For example, the phrase "at least one of a widget, a car, and a tire" means either a widget, a car, a tire, a widget and a car, a widget and a tire, or a car and a tire, Either small parts, cars, and small tires. For the phrase "at least one of them", when it modifies multiple things, it does not refer to "each of" the multiple things.

For numerical terms such as "one", "two", etc., when used as a cardinal word to express the quantity of something (for example, one widget, two widgets), it refers to the quantity represented by this numerical term, but it is not means at least the quantity to which this numerical term refers. For example, the phrase "a widget" does not mean "at least one widget", so the phrase "a widget" does not include two widgets.

The phrase "based on" does not mean "based solely on" unless expressly stated otherwise. In other words, the phrase "based on" includes both "based on only" and "at least based on". The phrase "based solely on" is equivalent to the phrase "based at least in part on".

The term "representative" and similar terms are non-limiting unless expressly stated otherwise. For example, the term "representative" does not mean "representative only," unless expressly stated otherwise. That is, the phrase "This data represents a credit card number" includes both "This data represents only a credit card number" and "This data represents a credit card number and this data also represents other things."

The term "by virtue of" in this invention is used only before a clause or other sentence group, which only expresses the expected result, purpose or consequence of something that has been previously cited. Therefore, when the term "by virtue of" is used in a claim, the clause or other words modified by the term "by virtue of" do not impose any specific restrictions on the claim or otherwise limit the meaning or scope of the claim.

The term "such as" and similar terms means "for example" and therefore does not limit this term or the phrase it interprets. For example, in the sentence "Computers send data (e.g., instructions, data agencies) over the Internet," the term "such as" states that "instructions" are an instance of "data" that computers can send over the Internet, and states that " A "data structure" is an example of "data" that a computer can send over the Internet. However, in addition to "instructions" and "data structures" being instances of "data", other things can be "data" as well.

The term "respective" and similar terms means "solely owned". So if two or more things have "respective" characteristics, then the two things have their own characteristics, and these characteristics may be different or the same. For example, the phrase "two machines have their own functions" means that the first of the two machines has a function, and the second also has a function. The functionality of the first machine may or may not be the same as the functionality of the second machine.

The term "i.e." and similar terms mean "means to be" and thus limit the terms and phrases to which they are interpreted. For example, in the sentence "A computer sends data (i.e., instructions) over the Internet," the term "i.e." explains that the "instructions" are data that the computer sends over the Internet.

Any specific range of digits includes integers and fractions within that range. For example, the range "1 to 10" should be interpreted to specifically include all numbers between 1 and 10 (e.g., 1, 2, 3, 4...9) as well as non-integer digits (e.g., 1.1, 1.2...1.9 ).

When two or more terms or phrases are synonyms (i.e., terms or phrases of the same meaning may be used to make a clear statement), then an instance of the term/phrase does not mean that the term/phrase Another instance of has a different meaning. For example, when a declarative statement indicates that "includes" means the same thing as "includes, but is not limited to," the use of the phrase "includes, but is not limited to" does not mean that the term "includes" has a different meaning than "includes, but is not limited to." ".

III. OK The term "determine" and its semantic variants (e.g., determine price, determine value, identify targets that meet certain criteria) are used in an extremely broad manner. The term "determine" includes a wide variety of actions, so "determine" can include calculation, processing, tracing, investigation, search (such as searching in a table, data or other data structure), ascertainment, etc. Likewise, "confirming" can include receiving (such as receiving information), accessing (such as accessing the information contained therein), etc. Likewise, "determine" may include solving, selecting, establishing, etc.

The term "determine" does not imply a positive or absolute tone, and therefore "determine" may include estimates, speculations, forecasts, guesses, etc.

The term "determine" does not imply that mathematical operations must be performed, that numerical methods must be used, or that algorithms or processes are used.

The term "OK" does not imply that any specific equipment must be used. For example, it is not necessary to use a computer to perform the determination process.

IV. Sentence form If the scope of the first request covers one and more features (e.g., the scope of the limitation of "at least one widget" covers one and more widgets) and the second request depends on the first request, then the The second request is limited by the qualifier "this" (for example, "this widget"). This does not mean that the first request only covers one of the features, nor does it mean that the second request only covers one of the features (such as , "widget" can cover one or more widgets).

When an ordinal number is used as an adjective before a term, the ordinal number simply refers to a specific characteristic, such as to distinguish this characteristic from other characteristics described by the same or similar term. For example, the "first widget" is named simply to differentiate it from the "second widget". Therefore, the ordinal words "first" and "second" before the term "widget" do not denote any other relationship between these two widgets, nor do they denote any other characteristics of either or both widgets. . For example, the ordinal words "first" and "second" before the term "widget" (1) do not indicate that any one widget is positioned before or after another; (2) do not indicate that any one widget is positioned before or after another; is produced or operated before or after another; and (3) does not imply that any one widget is of greater or lesser importance or quality than another. Furthermore, the use of ordinal numbers does not limit the numerical range of the characteristics they establish. For example, the ordinal words "first" and "second" before the term "widget" do not mean that there are only two widgets.

When a single device, article or other product is described in this disclosure, multiple devices/items (whether related or not) may be used instead of the single device/item. Correspondingly, a function handled by one device can also be handled by multiple devices/items (whether related or not).

Likewise, when multiple devices, articles, or other products are described herein (whether related or not), a single device/item may be used instead of the multiple devices or items. For example, multiple computing devices may be replaced by a single computing device. Accordingly, various functional classes handled by multiple devices or items are handled by a single device/item.

Functionality of a single device may also be embodied in one or more other devices that are not explicitly stated to contain this functionality. Therefore, other embodiments need not include the device itself, but may directly include one or more devices that contain this functionality/feature in other embodiments.

V. Disclosure examples and terms are non-limiting Neither the Title (beginning the first page of this application) nor the Abstract (at the end of this application) limit the scope of the disclosed invention, are intended to interpret the meaning of any claim, and are not intended to limit the scope of any claim. A summary section is included in this application solely because it is required by the provisions of 37 CFR § 1.72(b).

The titles of this application and the headings of the sections within this application are for convenience only and should not be construed as limiting the invention in any way.

Many embodiments are described in this application for reference only. The embodiments described in this application are not meant to be limiting in any sense. The invention is broadly applicable to numerous embodiments, as will be apparent from the disclosure. One of ordinary skill in the art will recognize that the disclosed invention is susceptible to various modifications and changes, such as structural, logical, software, and electrical modifications. Although specific features disclosed herein are described with reference to one or more specific embodiments and/or drawings, it should be understood that these features are not limited to usage in the specific embodiment or embodiments or drawings. Unless otherwise expressly stated.

While one disclosed embodiment may include several features, other embodiments of the invention may include fewer features. Thus, for example, a claim may not include all features of a disclosed embodiment, and the claim may not include features other than those expressly recited in the claim.

Any method step or product element described in this application does not constitute the invention, is not essential to the invention, or is of common scope with the invention, unless expressly stated in the specification or claims.

The preamble of the claim is only used to quote the purpose, benefits and possible uses of the present invention and does not limit the present invention.

This invention is not a literal description of all of its embodiments. Likewise, the present invention is not a simple list of its functions simply because these functions must be present in all embodiments.

Not all disclosed embodiments are necessarily covered by the claims (even including all pending, revised, issued and canceled claims). Furthermore, an embodiment may be (but need not be) covered by several claims. Therefore, when a request (whether pending, revised, issued or canceled) is designated to a specific embodiment, it does not indicate that the scope of other requests does not include this embodiment.

Mobile devices described as being in communication with each other need not be in continuous communication with each other unless expressly stated otherwise. In contrast, the device only sends information when necessary and appropriate, and can actually limit the exchange of data most of the time. For example, a machine that communicates with another machine over the Internet may not send data to the other machine for a long period of time, such as weeks. In addition, devices that communicate with each other may communicate with each other, either directly or indirectly through one or more intermediaries.

A description of one embodiment with several elements or functions does not imply that all or any such components/functions are necessary. In contrast, a variety of optional elements may be used to illustrate the variety of possible embodiments of the invention. Unless otherwise expressly stated, no element/feature is required or required.

Although certain process steps, algorithms, etc. are described or stated in a specific order, these processes may be configured in a different order. In other words, an explicit description or statement of any order or sequence of steps does not imply that the steps must be performed in that order. The process steps described herein can be performed in any order. In addition, although certain steps are described or implied as being performed non-concurrently (eg, one step is described after another step), they may be performed concurrently. Furthermore, when a process is illustrated in a drawing, it does not mean that the illustrated process excludes the possibility of other variations and modifications, or that the illustrated process or any steps thereof are essential to the invention, nor that the illustrated process excludes the possibility of other variations and modifications. There is no indication that the illustrated process is preferred.

Although a process may be described as including multiple steps, this does not imply that all or any steps are preferred, necessary, or required. Various other embodiments within the scope of the invention include other processes in which some or all of the recited steps are omitted. Unless otherwise expressly stated, no step is necessary or required.

Although a process may be described alone or without reference to other products or methods, in some embodiments the process may interact with other products or methods. For example, this interaction may include combining one business model into another business model. This interaction can be used to increase the flexibility or desirability of this process.

Although a product may be described as including multiple elements, aspects, qualities, features and/or functions, this does not imply that any or all of the above are preferred, required or required. Various other embodiments within the scope of the invention include other products that omit some or all of the above.

An enumerated list of projects (which may or may not be numbered) does not imply that any or all projects are mutually exclusive unless explicitly stated otherwise. Likewise, an enumerated list of projects (which may or may not be numbered) does not imply that any or all projects are a composite of any category, unless expressly stated otherwise. For example, the enumeration list "a computer, a laptop, a PDA" does not mean that any or all three items are mutually exclusive, nor does it mean that any or all three items are a combination of any categories.

An enumerated list of projects (which may or may not be numbered) does not imply that any or all projects are equal to each other or readily substituted for each other, unless expressly stated otherwise.

All examples are illustrative and do not imply that the invention or any embodiment thereof has been completed or performed as the case may be.

VI. Calculation It will be apparent to those of ordinary skill in the art that the various processes described herein may be accomplished by means of appropriately programmed general-purpose computers, special-purpose computers, and computing devices. Typically a processor (e.g., one or more microprocessors, one or more microcontrollers, one or more digital signal processors) will receive instructions (e.g., from memory or similar device) and execute them These instructions, thereby executing one or more processes defined by these instructions. Instructions may be embodied, for example, in one or more computer programs, one or more scripts.

A "processor" means one or more microprocessors, central processing units (CPUs), computing devices, microcontrollers, digital signal processors or similar devices, or any combination thereof (e.g., chip level multiprocessor/multicore processors, RISC, CISC microprocessors without interlocking pipeline stages, pipeline configurations, simultaneous multithreading).

A description of a process is therefore also a description of the apparatus for performing the process. Means for performing a process may include, for example, a processor and input/output devices that may be used to perform the process.

In addition, programs that implement these methods (as well as other data types) may be stored and sent in a variety of media (e.g., computer-readable media) and in a variety of ways. In some embodiments, hardwired circuitry or custom hardware may be used in place of or in combination with some or all of the software instructions that may implement the processes of various embodiments. Therefore, various combinations of hardware and software can be used, not just software.

The term "computer-readable medium" refers to any medium and combination of multiples of the same or different media that provides information (e.g., instructions, data structures) that can be read by a computer, processor, or similar device. This media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media includes dynamic random access memory (DRAM), which typically constitutes main memory. Transmission media include coaxial cables, copper wire, and fiber optics, which include the wires that make up the system bus that couples to the processor. Transmission media may contain or transmit acoustic waves, light waves, and electromagnetic radiation, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media include, for example, floppy disks, floppy disks, hard disks, tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, punched cards, paper tape, any punched media Other physical media, RAM, PROM, EPROM, FLASH-EEPROM, any other memory chip or tape cartridge, or any other media from which a computer can read.

Various forms of computer-readable media may be involved in transferring data (eg, sequences of instructions) to a processor. For example, data may be: (i) transmitted from RAM to processor; (ii) transmitted over a wireless transmission medium; (iii) formatted and/or transmitted according to various formats, standards or protocols, such as Ethernet (IEEE 802.3), SAP, ATP, Bluetooth<img file="TWI840939B_D0001.tif" /> and TCP/IP protocols, TDMA, CDMA and 3G; and/or (iv) encryption to ensure privacy or prevent fraud by means known in the art.

Therefore, a description of a process is also a description of the computer-readable medium that stores the program that performs the process. A computer-readable medium may store (in any suitable format) these program elements to properly perform this method.

Just as descriptions of steps in a process do not imply that all described steps are required, embodiments of an apparatus include a computer/computing device that can perform some, but not necessarily all, of the described processes.

Likewise, just as descriptions of steps in a process do not imply that all described steps are required, embodiments of a computer-readable medium storing a program or data structure include such computer-readable media storing a program when such Programs, when executed, cause a processor to perform some, but not necessarily all, of the processes described.

When describing a database, one of ordinary skill in the art will understand that (i) alternative database structures to the described database structure may be employed, and (ii) other memory structures in addition to the database may readily be employed. Any presentation or description of any example databases in this disclosure is an exemplary arrangement of information storage. Any other arrangement may be used than that suggested in the drawings or tables shown elsewhere. Similarly, any database entries shown are for exemplary purposes only, and one of ordinary skill in the art will understand that the number and content of entries may vary from that described herein. Additionally, while some of the databases described herein are in tabular form, other formats (including relational databases, object models, and/or distributed databases) may be used to store and manipulate the types of data described herein. Likewise, a database's object methods or behaviors may be used to perform various processes as described in this disclosure. Additionally, the database can be stored locally in a known manner or on a remote device that has access to the database.

Various embodiments may be configured to operate in a networked environment, including a computer in communication with one or more devices (eg, over a communications network). This computer can communicate with the device directly or indirectly, or over any wired or wireless medium (such as the Internet, LAN, WAN, or Ethernet, Scepter Ring, telephone lines, cable lines, radio channels, optical communication lines , commercial online service providers, electronic bulletin board systems, satellite communications links or any combination of the above). Each device may itself also include a computer or other computing device adapted to communicate with a computer, such as an Intel® Pentium® or CentrinoTM processor. The devices that communicate with the computer can be any number and type.

In one embodiment, a server computer or centralized server is not necessary. For example, in one embodiment, the invention may be practiced on one or more devices without the need for a centralized server. In this embodiment, any of the functions described herein performed by the server computer or data stored on the server computer may be performed or stored by one or more such devices.

When a process is described, in one embodiment the process can be performed without any user intervention. In another embodiment, the method includes some human intervention (eg, a step is performed by a human or assisted by a human).

VII. Follow-up operations of bets Various embodiments include a smart card shoe that reads the suit and rank of each card and then transmits it to various locations where cards are dealt in a casino tabletop card game. Then, the cards are dealt to the required card positions according to the rules of the game. Different games have different card distribution positions, different card numbers, and different distribution orders, which can all be included in the hand card recognition system of various embodiments of the present invention. For example, in the most complex blackjack game of card distribution, cards are usually dealt out one at a time in order around the game table, one at a time to each player position and then to the dealer position. Then repeat the operation of distributing one card at a time, so that each player position and dealer position receive exactly two cards in the first round. The hand changes are complicated because players can basically control additional cards at will until the point value in their hand exceeds blackjack. As long as the player wants, he can hold the cards unchanged at 2 points (two aces), or continue to ask for cards when he gets 21 points, so the number of points in a hand cannot determine a player's operation. On the other hand, dealers must strictly follow the casino rules according to the value of their hands. There may be slight differences in the game, such as allowing you to continue asking for cards when you have a "virtual" seventeen (for example, an ace and a 6), or prohibiting asking for cards at this time, but the rules are otherwise It is very strict, so no strategy can be taken by the casino or dealer.

Other card games offer the same number of cards in batches. For example, some variations of Stud Poker against the Dealer typically offer five cards per hand, with five cards dealt each time to each player position, as well as the Dealer position (if playing against the Dealer). This distribution of cards is very easy to track because each hand is made up of five cards from the shoe.

Other games may require cards to be dealt to players and other cards to be dealt to the flop or community area. The system of the present invention can also be programmed to cover this variation if desired.

Baccarat is similar to blackjack in the order of dealing cards, but it has stricter rules when players and dealers ask for cards, and each position can only take at most one card at a time. The hand recognition system of some embodiments of the present invention is capable of identifying hands in these game types, and is particularly capable of identifying blackjack hands in complex situations.

In various embodiments, when used to read playing cards, the photosensitive system may be any image capture system capable of identifying the suit and rank of a playing card, whether digital or analog.

In various embodiments, the first step of the operation is to provide a set of playing cards into the smart card shoe, and this set of playing cards is the playing cards that will be used in the casino table card game. The set of cards (usually one or more standard decks) has been randomized and may have been removed from a shuffler or may have been hand shuffled. U.S. Patent Application No. 10/622,321 (entitled "Wisdom Boots") describes a Smart Boot and is hereby incorporated by reference in its entirety. Certain card dealing systems or cards with reading capabilities include, but are not limited to: U.S. Patent Nos. 4,750,743; 5,779,546; 5,605,334; 6,361,044; 6,217,447; 5,941,769; 6,229,536; 6,460,848; 5,722,893; 6,0 39,650; and 6,126,166. In various embodiments, the playing cards are read in a deal-only shoe, such as one at a time in sequence. Reading playing cards with edge markings and special codes (as described in U.S. Patent No. 6,460,848) may require the playing cards to be specially encoded and marked. Therefore, the entire card sequence of the group of cards is determined and stored in the memory. The memory is at least partially embedded in the Intelligent Boot, but can also communicate with a central processing unit. Sequences can therefore also be stored simultaneously or individually in the central computer.

In various embodiments, the cards are subsequently removed from the smart shoe, and the shoe can register how many cards are removed each time. This can be achieved by the above-mentioned US Patent Application No. 10/622321, in which one card is transferred to the dealer's removal area at a time, so that the dealer can only remove one card at a time. When this card is removed, the system creates a signal indicating that a specific (rank and suit) card has been dealt. The computer and system only know that the first card has been dealt, and assume it was dealt to the first player. The remaining cards are dealt to the players and dealers. In specific games where a specific number of cards is known to be dealt to each position (e.g., a variation of Stud), the number of players can be programmed into the shoe at any time, so that the number of cards in each hand can be established even before the cards are dealt. interrelationships between. A variation of Stud in which each player and dealer is dealt three cards. PokerTM game), if this card shoe is used, the system can know in advance the hand each player and dealer will receive. It is also possible to set a signal that prompts the dealer when he receives his first card (for example, when the cards are dealt out one at a time in sequence) or when the entire hand is received. This signal can be used to automatically determine the number of active player positions at the gaming table at any one time. For example, if in a game of blackjack the dealer receives the sixth card, the system immediately knows that there are five players at the table. The signal can be provided manually (by pressing a button at the dealer's location or on a smart card shoe), or automatically (a card sensor at the dealer's location that activates the card when a card is placed on the sensor). transmit signal). When a sensor provides an automatic signal, the sensor can be physically protected, such as by providing a shield that prevents accidental contact with the sensor or blocks the sensor's signal. An L-shaped cover can be used so that a playing card can slide under the L arm parallel to the tabletop and cover the sensor under the L branch. When all the cards in the hand have been dealt, a signal can also be given to once again indicate the number of players. For example, when the dealer's two cards slide under the L-shaped cover and then block or contact the sensor, the system can know the total number of cards dealt to the hand (for example, 10 cards) and know that the dealer has 2 cards, thereby determining that the players have 8 cards, of which each player has 2 cards, thus completely determining that there are four active player positions on the game table (10-2=8, 8/2=4 players). This automatic determination replaces having the dealer enter the number of players at the table for each hand, or having to manually change the number indication of the players at the table each time when the number changes.

Once cards have been dealt to all active locations, the system knows each player, the initial card in the dealer's hand, as well as any flipped cards and community cards. When no more cards are dealt in casino table games, operation of the system becomes simple. Then all hands can be known and all outcomes can be predicted. Instead the complexity will be solved by bringing you additional cards in the game.

After the initial two cards of each hand are dealt, the system may not immediately know where each remaining card will be dealt. But the system can know which cards are being dealt. It is because of this, and the subsequent recognition of the discarded hand, that the hand and cards in the Wisdom Boot can be reconciled or authenticated. Each hand has been identified by the two special playing cards that are known. The hands are then dealt with according to the rules of the game and will be discarded when a hand is exhausted. A hand will be discarded when: 1) Blackjack occurs, the hand is paid out, and the cards have been cleared; 2) A hand exceeds 21 and the cards have been cleared; and/or 3) A game round has ended, the dealer's hand has been completed, all bets have been paid, and the cards have been cleared. Typically, when manually mixing cards in a casino, the cards are picked up from the game table in strict order. Cards are usually cleared from the dealer's right to the left, and the cards are arranged in the order in which they were dealt at each position, with the first card on the bottom, the second card on top of the first card, and the third card on top. The first card is above the second card and so on. It is important to maintain the order or general order of the cards (for example, the first two cards may be swapped) because the first two cards form the anchor, focus of each hand. , base, fence, end or advantage. For example, if the first two cards received by the third player's position are known to be the 10 of Hearts (10H) and the 9 of Spades (9S), and the first two cards received by the fourth player are known to be the 8 of Diamonds (8D) and Club 3 (3C), then the advantages or anchor points of these two hands are 9S/10H and 8D/3C respectively. When the game is over and both hands have been cleared, the cards are transferred to a smart discard rack (see, e.g., U.S. Patent Application No. 10/622,388, which is incorporated by reference in its entirety) with the 9S/10H The hand of cards has not been exhausted (for example, broken or exploded), and the swept cards include 9S, 10H, 8S, 8D and 3C (read by the smart discard rack), then the processor software can automatically identify the third The final point of the third hand in the third position is 19 (9S and 10H), and the final point of the fourth hand in the fourth position is also 19 (the original 8D and 3C plus the additional 8S). The software's analysis can specifically identify the fourth hand's value as 19 through the specific cards read by the Smart Discard Boot. The information read from the currently depleted hand is then compared to the original information collected in the Wisdom Boots. The combination of the Wisdom Boot information and the Wisdom Discard Boot information can confirm the hand of each position, even if the cards are not distributed in a uniform way (for example, the first player asks for two more cards and gets a total of four cards, the player The second player asked for three more cards and received a total of five cards. The third player did not ask for additional cards and received a total of two cards. The fourth player asked for one more card and received a total of three cards. The dealer asked for two more cards. A total of four cards were obtained).

The same analysis can be done on the dealer's cards in a number of different ways. When the last card is dealt to the last player, a signal can be generated easily and unnoticed indicating that the dealer's hand is now active and additional cards can be requested. For example, cards can be removed from under the L-shaped protective bridge using the sensors described above that sense the first dealer card or the end of the dealer's hand. This type of maneuver is common in blackjack, as the dealer only exposes one card at most and the other card face down. In this case, it would be a natural operation to remove the cards from the sensor under the L cover to reveal the hole cards, which would then expose the sensor. This would provide a signal to the central processor, informing it of the dealer's hand. The deck will receive all remaining cards for the round. At this point, the system knows the two initial cards in the dealer's hand, knows the value of the next round of cards, and knows a rule that the dealer can exploit. The system knows the cards that the dealer will receive and the dealer's final hand, since the dealer cannot decide and manipulate the cards in his or her own hand. When the dealer's hand is placed into the smart discard rack, the dealer's hand already knows the contents of the dealer's hand, even without using the initial two cards as the anchor or basis for the dealer's hand. In some embodiments, playing cards may be processed in this manner.

When hands are cleared from the game table, in order from the dealer's hand to the player's hand from right to left (starting from the dealer's position or vice versa according to casino rules), the smart discard rack reads the cards The Boot, identifies the anchor point for each hand, knowing that no more than blackjack is swept away at the end, and the computer identifies individual hands and reconciles them using raw data from the Wisdom Boot. The system therefore identifies every hand played and ensures the fairness and accuracy of the game.

In the absence of coordination of this system, a variety of events can occur. A signal may be sent directly to the dealer's position, the discard area, or the safe area, and the cards may be inspected to determine the nature and cause of the error and, if necessary, to inspect individual cards. When hand and card information is used for various statistical purposes, such as evaluating dealer efficiency, dealer win and loss events, player efficiency, player win and loss events, statistical analysis of player habits, abnormal game tactics, or meaningful game tactics (e.g., a tendency to count cards), etc., the system can place a specific hand into a "dump" file so that the hand is not used in the statistical analysis. The purpose is to ensure that the analysis is not affected by the statistical analysis. Effects of erroneous or unusual data.

Various embodiments may include date stamping (an actual time and date determined sequence, where a specific identification of the sequence identifier may be unique) to each dealt card. A specific sequence of stamps or marks may also be used in place of a date stamp, such as a specific hand number, at a specific game table, in a specific casino, a specific number of players, etc. The record in the central computer memory shows the variation of the indicator as: Lucky 777 Casino, August 19, 1995, 8:12:17 a.m., table 3, position 3, hand 7S/ 4D/9S, or simply indicated in digital form: L7C-819-95-3-3-073-7S/4D/9S (where 073 indicates that this is the 73rd hand dealt). This date stamping of hands and even cards in memory can be used as an analytical search tool to ensure security and enhance hand recognition.

Figure 1 shows a component block diagram of the hand card reading system of the game table 4 in some embodiments, which includes a card reading shoe 8 and output device 14, and a smart card reading discard rack 12 and output device 18. Also displayed are the player position 6, the dealer's hand position sensor 10 and the output port 16.

In some embodiments, it may be advantageous to utilize a discard rack to automatically reconcile hands that are returned to the discard rack out of sequence (eg, blackjack or bust). The software described above can be programmed to identify hands that are removed out of order based on the anchor cards (the two initial cards) that have been dealt to a particular hand. For example, the software will recognize that when a blackjack is dealt to the third position, that hand will be removed. Feeding the third hand to the Smart Discard Board confirms this, and in subsequent hands During processing, the third position will be completely ignored. More importantly, for example, when the anchor card in the second player's position is 9S/5C, and a depleted hand of 8D/9S/5C is put into the smart discard rack, it can be identified that the hand is The hand from the second player's position. If two hands of the same cards are dealt in the same round, the software will only receive an alert (if all hands are known) to specifically check the final order of cards put into the smart discard shoe, thereby more accurately locating the spent cards. Exhaust the position of the hand. If you understand this concept, you will know that this only applies recognition software.

The step of removing cards from the dealer's sensor or the initial activation signal indicating that the remaining cards will be sent to the dealer can be useful in defining the advantage between turns, or in identifying the dealer's hand and a The end of the round game is very useful. When the dealer's hand is stored in the smart discard rack and read, the central computer knows that another round of game is about to start, and can mark or prompt that the sequence will be a new round of game, and the analysis cycle restarts. start.

When there are no additional cards in the discard rack's feed tray, the discard rack indicates that a full hand of cards has been dealt. When cards are removed from an early depleted hand (blackjack or bust), they are removed one at a time and inserted into the smart discard rack one at a time. When the feed tray of the smart discard rack is empty, the system understands that a complete hand has been identified, and the system can use the information in the only deal shoe to reconcile the specific hand. The system can be hooked into feed strategy analysis software programs, such as SMI's patented BloodhoundTM analysis program.

Various embodiments may include a casino or card room game modified to include a progressive jackpot element. For example, in the Twenty-One game, in addition to this regular bet, a player may choose to place an additional bet that becomes part of the progressive jackpot and makes the player eligible to compete for the progressive jackpot. If a player's Twenty-One hand contains a specific, predetermined card arrangement, that player will win all or part of the amount shown in the progressive jackpot. This progressive jackpot feature also works with any other casino or card room game, such as Draw Poker, Stud Poker, Lo-Ball Poker or Caribbean StudTM Poker. Various embodiments include a game table, such as that used for Twenty-One or poker, modified to add a coin acceptor connected to a jackpot table. When a player inserts a coin into the coin acceptor, a light at that player's location is activated indicating that he is competing for the progressive jackpot for that round of play. At the same time, the coin acceptor sends a signal to the accumulation meter, causing the amount displayed on the accumulation meter to increase. When each hand ends, the coin receiver will be reset, waiting for the next hand. When a player wins all or part of the progressive jackpot, the amount on the progressive jackpot table will be reduced by the amount won by that player. Any number of gaming tables can be connected to a single progressive jackpot table.

VIII. Devices for playing games in communication systems Figure 2 shows the setup used for the game. It includes a plurality of player units 40-1 to 40-n, which are connected to the game system through a communication system 41 (such as the Internet). The game system includes a management unit 42, a player register 43 and a game unit. 45. Each unit 40 is a typical personal computer with a display unit and control devices (a keyboard and a mouse).

When a player logs into the gaming system, the unit 40 makes itself identifiable to the administration. The system maintains player details in a register 43, which provides separate player register units 44-1 to 44-n for all potential players, ie details of all members of the system.

Once a player has been identified, the player will be assigned to a game unit 45. The game unit includes a group of player information units 46-1 to 46-6, a dealer unit 47, a control unit 48 and a random processing unit 49.

Up to seven players may be assigned to gaming unit 45. There can be multiple such units, allowing multiple matches to be played simultaneously when more than seven members are logged into the system at the same time. The assignment of player profile units 46 to player units 40 may be arbitrary or random, depending on which player profile unit 46 and game unit 45 are free. Each player profile unit 46 is loaded from the corresponding player register unit 44, also contains substantially the same details as the corresponding player unit 40, and communicates with the player unit 40 to keep the contents of the player unit and player profile unit updated with each other. . Additionally, the appropriate content of the other player profile units 46 and dealer units 47 is sent to the player unit 40 for display.

The logic unit 48 of the gaming unit 45 executes the steps of the gaming unit through the various stages, thereby initiating the dealer's actions and waiting for an appropriate response from the player unit 40. The random card dealing unit 49 basically randomly distributes playing cards to the card dealer unit 47 and the player information unit 46. At the end of a round of playing cards, the logic unit passes the result of the round of playing cards (ie, winning or losing) to the player information unit 46 to inform the player of the result. The management unit 42 also receives these results and updates the player register unit 44 accordingly.

The player unit 40 is arranged with a display. When a player needs to be identified, the player's position will be highlighted. As the game progresses, players select various information boxes and enter their bets, etc., and the results of these actions are displayed. When cards are dealt, a series of overlapping cards appear in the bonus box. Depending on the player's choice, cards can be displayed under the bonus box, as well as for cards dealt to the dealer. At the end of a poker hand, a message is displayed informing players of the outcome of their bet, i.e. the amount won or lost.

It will be understood from the above discussion that the present invention can be embodied in a variety of embodiments, including but not limited to the following: 1. A method including: Monitoring of a player's actions across multiple games by a computing device; The computing device generates profile data for the player based on the monitoring information; Determining, by the computing device, that the player's actions in a second game are the result of collusion; After determining that the player's operation is the result of collusion, the computing device determines that the operation deviates from the profile information; Upon determining that the operation deviates from the profile, a collusion prevention operation is taken by the computing device. 2. The method of embodiment 1, wherein determining that the operation deviates from the profile data includes: determining a probability that the operation is inconsistent with the player's historical operations by comparing the operation with the profile data. 3. The method of embodiment 1, wherein the collusion result includes: the player transferring a large amount of chips to another player in the second game. 4. The method described in Embodiment 1, determining that the operation is the collusion result includes: determining the severity of the collusion based on the collusion result, and the determination of the deviation of the operation from the profile data is required to adjust the severity, with higher deviations Used to determine low severity, lower bias used to determine high severity. 5. The method of embodiment 1, comprising determining a likelihood of collusion and providing the likelihood to a collusion detector. 6. The method of Embodiment 5, comprising: determining a high probability of collusion after determining that the collusion result is a highly severe collusion and deviates significantly from the profile information. 7. The method described in Embodiment 5, including: determining a low degree of collusion possibility after determining that the collusion result is not serious or does not deviate significantly from the profile data. 8. The method of embodiment 1, comprising: determining a current collusion level of the player in the games based on the percentage of possible collusion operations detected in the games, and providing the collusion level to a Collusion detector. 9. The method of embodiment 1, wherein the collusion prevention operation includes: providing information to a collusion detector through a user interface, so that the collusion detector can perform at least one of the following operations: cancel the second game. As a result, the player is prohibited from playing the game, the second player's game is suspended, or the second game is reset. 10. The method of embodiment 9, comprising recording a history of the second game, and wherein the user interface allows a collusion detector to access the game record of the second game. 11. The method of embodiment 10, wherein the user interface is configured to allow a collusion detector to access the game record during game play. 12. The method of embodiment 10, wherein the game record allows a collusion detector to reconstruct the second game. 13. The method of embodiment 1, including storing the profile data in a vector, wherein each dimension of the vector represents a certain behavior of the player. 14. The method of embodiment 13, wherein each dimension of the vector includes a compact dimension of the game dimension, the compact dimension being determined by a smaller blind percentage in the poker game. 15. The method of embodiment 13, wherein one dimension of the vector includes: in Texas Hold'em, a positive dimension determined by comparing a post-flop bet and raise percentage with a post-flop bid percentage. 16. The method of embodiment 13, wherein the dimensions of the vector are scene class dimensions. 17. The method of embodiment 13, wherein the dimensions of the vector are determined based on observed behavioral context. 18. The method of embodiment 17, wherein the background of one dimension of the vector is determined by one of the player's secret card strength and hand strength. 19. The method of embodiment 13, including: when one dimension of the vector does not have enough information, estimating the dimension of the vector by referring to one or more other dimensions of the vector. 20. The method of embodiment 13, including determining one dimension of the vector by weighting information so that newer games have a higher weight than less new games. 21. The method of embodiment 1, including generating the profile information to identify historical actions taken in multiple game scenarios. 22. The method of embodiment 1, including generating profiles to identify historical actions taken for each type of player. 23. The method of embodiment 1, wherein monitoring the player's operation includes: running an electronic platform so that the player can play games with other players on the platform, and determining through the electronic platform that the player is in multiple games. Action taken. 24. A device comprising: a computing device; and A non-volatile medium that stores instructions that, when executed by a computing device, cause the computing device to: Monitor a player's actions across multiple games; The computing device generates profile data for the player based on the monitoring information; Determine that the player's actions in the first and second games are the result of collusion; After determining that the player's operation is the result of collusion, the computing device determines that the operation deviates from the profile information; Upon determining that the operation deviates from the profile, a collusion prevention operation is taken by the computing device.

<p>4:Game table 6: Player position 8: Card Reading Boots 10: Dealers hand card position sensor 12: Smart card reading discard rack 14,18:Output device 16:Output port 40-1~40-n: Player unit 41:Communication system 42: Management unit 43: Player register 44-1~44-n: Player register unit 45: Game unit 46-1~46-6: Player information unit 47: Dealer unit 48:Control unit 49: Random processing unit </p>

Figure 1 illustrates a block diagram of a hand reading system in some embodiments.

Figure 2 illustrates an apparatus for playing the game in some embodiments.

Figure 3 (divided into A and B) illustrates exemplary information storage in certain embodiments.

Figure 4 (divided into A and B) illustrates an exemplary data structure for game operations in certain embodiments.

Figure 5 illustrates exemplary hand strength determination results in accordance with certain embodiments.

Figure 6 (divided into A and B) shows an exemplary data structure for game operations in certain embodiments.

Figure 7 (divided into A and B) illustrates examples of player profile categories in certain embodiments.

Figure 8 illustrates an exemplary data structure for collusive behavior in certain embodiments.

Figure 9 illustrates an exemplary interface that may be used to display collusive behavior across multiple gaming tables in some embodiments.

Figure 10 illustrates an exemplary interface that may be used to display information on a particular gaming table in some embodiments.

Figure 11 (divided into A and B) shows an exemplary interface that may be used to display specific information about a possible collusive behavior in some embodiments.

Figure 12 illustrates an exemplary method that may be performed in certain embodiments.