METHOD AND APPARATUS FOR DETECTING COLLUSIONS IN ONLINE GAMES

Abstract

An apparatus and method for detecting situations of collusion or collusion attempt tempt in online gaming environments, wherein games are operated by an operator, and players participate in the games from remote locations. The apparatus and method detect collusion situations in the round level, session level or multi-session level, and optionally generate an alert or take an action such as blocking a user if a situation was detected.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to online games in general, and to a method and apparatus for detecting collusions in computer games played over a communication network in particular.

2. Discussion of the Related Art

Computing and network technologies, together with the rising numbers of computer users contribute to the continuous growth of gaming environments offered to online users playing at their homes, offices, internet cafes or any other locations. Some games are played by one or more garners and do not involve an external operator, while others do involve such operator. Among the games that is involve external operators, many games involve payment, such that each player deposits, for example by providing details of a credit card, an amount of money which is lost if the player loses, and is paid back or even increased if the player wins, for example by crediting an account. Since the operator can not see or talk to the players, this opens a fertile ground for collusions which may involve one or more players cooperating in collusion schemes. Various schemes may be plotted, each scheme may involve one player or two or more cooperating players. Each scheme may also be directed against the game operator or against innocent players. Generally the schemes depend on the rules of the specific game in which the schemers participate, and should therefore be adapted to each game type. In addition, the detection of schemes relevant for each game type should be adjustable, so that alerts or actions will be taken when the suspicion level that a scheme is practiced exceeds a certain threshold. This will provide the possibility to focus on the more severe cases on one hand, while not interrupting the regular flow of games played by innocent players.

Thus, there is a need for a method and apparatus for detecting such collusions, for purposes including blocking or taking other actions against schemers, avoiding loses and protecting innocent garners. The method should be adjustable to the rules of each game and adaptable to changing suspicion levels used.

SUMMARY OF THE PRESENT INVENTION

It is an object of the present invention to provide a novel method for detecting collusions in an online poker game, which overcomes the disadvantages of the prior art.

In accordance with the present invention, there is thus provided a method for detecting a collusion or collusion attempt situation within an online computerized gaming environment, the gaming environment is operated by an operator and one or more players participate from remote computing platforms in one of more rounds of one or more sessions of a game, the method comprising the steps of: defining a collusion situation; and searching for an occurrence of the collusion situation in the rounds of the sessions. The method can further comprise a step of assigning a collusion factor to the collusion situation. The collusion situation is optionally a round collusion situation, a session collusion situation, or a post-session collusion situation. The collusion situation is optionally associated with the player. The player can be associated with a username. The game is optionally a poker game. The situation is optionally strong hand folded before the flop, shoveling hand, increasing pot size, consecutive wins, irregular pot size, shoveling in a session, chip dumping in a heads up tournament, or the same player having coordinated wins or loses in at least two sessions. Within the method, the at least two sessions can be of different games. The collusion factor is optionally associated with a bet placed or raised by a player. The method can further comprise a step of taking an action when the occurrence of the at least one collusion situation is detected or when the collusion factor exceeds a predetermined threshold. The action can be blocking the at least one player from playing, or generating an alert related to the situation.

Another aspect of the disclosed invention relates to an apparatus for detecting a collusion or collusion attempt situation within an online computerized gaming environment, wherein the gaming environment is operated by an operator and one or more players participates from a remote location in one of more rounds of one or more sessions of a game, the apparatus comprising one or more computing platforms; one or more definition components executing on said computing platform, for generating a definition for one or more collusion situations associated with the game; and one or more situation detection components executing on said computing platform for detecting the collusion situation in the game. The apparatus can further comprise a storage device for storing the one or more definitions. The definition component is optionally a round definition component, a session definition component, a configuration definition component or an application query definition component. The situation detection component can be a round situation detection component, a session situation detection component or a post-session situation detection component. The apparatus can further comprise a presentation component for presenting collusion situation, or an alert generation component for generating an alert related to the at least one collusion situation. The game is optionally poker.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:

FIG. 1 is a schematic illustration of a typical environment in which the disclosed invention is used;

FIG. 2A is a flowchart of the main steps associated with the definition part of the disclosed method;

FIG. 2B is a flowchart of the main steps associated with the detection part of the disclosed method; and

FIG. 3 is a block diagram of the components of an apparatus implementing the disclosed invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention overcomes the problem of collusions in computer games played over a communication network such as the internet and involving an operator.

In a preferred embodiment of the disclosed invention, the gaming system has the information related to the status of each player at every point in time during the game, for example cards given to the player, bets set by the player or the like. Having all relevant data, the system can search for and detect non-reasonable or suspicious situations or rule violation, for example a player leaving the game when his status seems promising, or vice versa. The system thus attaches a suspicion factor to each hand, i.e. round of the game, such as a “hand” in a poker game. The factor optionally comprises a numerical estimation for the suspicion factor, and the nickname of one or more players involved with an irregular situation or action. At the next stage, a collusion factor or a collusion estimation is attached to each session, the session comprising a number of consecutive hands. The collusion factor is determined based upon the collusion factors associated with the hands of the session, and upon determination of additional problematic issues or rule violation, such as an exceptional number of winnings out of the total number of rounds played by a player. One or more player nicknames are also optionally attached to the suspicion factor. Once collusion factors are available for hands or sessions, statistics, queries and additional data mining activities and operations can be performed upon the data. The activities include detection of cross-section rule violation or identifying problematic cross-sections issues. Thus, a player whose username repeats beyond a predetermined frequency or number of times in a collusion factor, may be further examined or blocked from further participating in games. Additional tools comprise the comparison of playing patterns of two or more players, such as common play times, percentage of all games that the two players play together, average amount of money that the one player loses or wins to the others possibly relatively to the amount of time the two players play together, etc., and additional comparison of further characteristics, such as sign up date, deposit date, e-mail, zip code or the like. The rule settings applicable for the hands, sessions or cross-sessions may be fine tuned or adjusted according to a game type, whether the game is played as a tournament or as a cash table, or other factors. A game operator or an employee thereof can change the collusion factor attached to each round or session, but the original suspicion factor, as assigned by the system is preferably stored as well. The system is preferably configurable. Thus, a user can define, configure, or fine-tune situations that should be recognized as well as the required details, for example associated thresholds (such as card or combination values, winning sums, number of consecutive wins, thresholds beyond which a collusion factor is associated with a round or a session, or the like). The disclosed invention can thus be used for detecting collusion or collusion-attempt situations, and identify one or more players that cooperate in a collusion or are victims of a collusion.

Referring now to FIG. 1, showing a typical environment in which the disclosed invention is used. The environment comprises a server 100 running an application 104 of a game, such as poker, baccarat, blackjack or any other game in which players may participate. Application 104 preferably comprises components required for executing the game, and also monitoring components for a supervisor, game operator or another person 108. Person 108, associated with an operator of the game, preferably monitors the on going behavior and activities of the system and players thereof, through the usage of computing platform 110 running an application 111, beyond the scope of a single game or session. Thus person 108 can issue queries, run research applications, analyze behaviors, or the like. One or more remote players participate in the game through the use of one or more computing platforms. Thus, in a non-limiting example player 112 participates using platform 116 running application 118, player 120 participates using platform 124 running application 126 and player 128 participates using platform 132 running application 134. Each of server 100 and platforms 116, 124, 132 is preferably a computing platform such as a personal computer, a mainframe computer, a network computer or any other type of computing platform that is provisioned with a memory device (not shown), a CPU or microprocessor device, and several I/O ports (not shown). Each computing platform is preferably provisioned with input and/or output device, such as a keyboard, a mouse or another pointing device, a monitor, a microphone, loud speakers or similar devices intended for receiving and transmitting information, including information related to the flow of the game or to wagers associated with the game. Alternatively, server 100 or any of platforms 116, 124, 132 can be a DSP chip, an ASIC device storing the commands and data necessary to execute the methods of the present invention. In yet another alternative, each of platforms 116, 124, 132 can be a cellular phone, a handheld device, a portable computer or any other computing platform provisioned with a CPU. Server 104 is preferably provisioned or in communication with a storage device for storing information related to games played in the past, participants in said games, their activities and other related information. Server 108 and platform 116, 124, 132 are preferably connected through a communication network such as the internet. Alternatively, two or more units of server 108 and platform 116, 124, 132 can be connected in a network such as a local area network, a wide area network, a wireless network or the like. Applications 104, 111, 118, 126 and 134 are preferably software applications, comprising executables, scripts, modules, libraries or other components, and written in any programming language, such as C, C++, C#, Java or others and under any development environment or operating system such as Windows, .NET, Linux and others. Each of applications 111, 118, 126, 134 communicates with application 104 running on server 100. In a preferred embodiment of the disclosed invention, application 104 is a server side of an application, such as a client-server application, while applications 111, 118, 126, 134 are the client side. Preferably, application 111 is a client side application with operator privileges, while applications 18, 126 and 134 are client side applications with player privileges. Applications 104, 111, 118, 126, 134 can be web applications accessed through the web, or installed on any computing platforms they are being run from. Alternatively, computing platform 100 and 110 can be the same platform, wherein applications 104 and 111 are the same application, communicating with applications 116, 128 and 134.

Referring now to FIGS. 2A and 2B, showing a flowchart of the main steps associated with the method of the disclosed invention. The steps of disclosed method are divided into two main groups: FIG. 2A shows preliminary steps 200 and FIG. 2B shows detection steps 216. Preliminary steps are performed as a basis for detection steps 216, but a user can also practice any of preliminary steps 200 at a later stage for modifying the system. Preliminary steps 200 further comprise a hand situation definition step 202. In hand situation definition step 202, the user identifies and describes using a dedicated user interface, a scripting language or any other interface situations associated with a single round, which should be noticed. The user further assigns or sets guidelines for determining a collusion score to be associated with a round or with a player. For example, in a poker game the following situations can be defined: A). Strong hand folded before the flop situation: the strength of the best pre-flop pocket cards among all players in a poker hand, that have seen the flop is marked according to configurations discussed in association with step 208 below). The situation is detected if the maximal value of pocket cards is equal or stronger than a predetermined value and weaker than the best pre-flop pocket cards. B). Shoveling hand situation: this situation is detected if a player calls on the river (excluding hands where players only check in the last round) with a hand weaker than a predetermined value and loses. C). Increasing pot size level 1 situation: this situation is detected if after the flop, a player bets or raises his bet in a multiplication between two predetermined values, when his hand is not the strongest hand on the table. D). Increasing pot size level 2: Similarly to situation C, using different values than the values used in situation C. Each defined situation is optionally assigned a weight, indicating the severity of the situation.

In session situation definition step 204, the user identifies and describes using a dedicated user interface, a scripting language or any other interface, situations associated with a session comprising two or more rounds, which should be noticed. The user further determines the collusion factor to be added to a session or to a player based on the situations. For example, the following situations can be defined: A). Consecutive wins situation: if a player wins a sum larger than his bet sum more than a predetermined number of hands in a row during the session, a consecutive wins situation is identified. B). Irregular pot size: the average pot within the session is determined. If at least one hand won a sum which is more than a predetermined number of standard deviations larger than the average pot, an irregular pot size situation is determined. C). Shoveling in a session: the balance of a player when he exits a session is determined, and compared to the total sum bet by the player during the session. If the won sum is more than a predetermined number of times larger than the bet sum, shoveling in a session situation is detected. D). Chip dumping in heads up tournaments: this situation refers to shoveling in a session (case C above) in heads up tournaments, i.e. when only 2 players participate. Each defined session situation is optionally assigned a weight, indicating the severity of the situation.

At step 206, the user defines post session conditions, which are checked for when a session ends, at time intervals, or according to other conditions. Such conditions can refer to whether and which problematic situations had been identified in rounds within the session or in the session itself, to one or more players or the like. The situations include, but are not limited to: A). High collusion score for a session: if the average collusion factor of the rounds plus the collusion factor of the session based rules exceeds a predetermined number, a case will be raised: B). High collusion scores in several sessions: if the average collusion factor for sessions within a predetermined time period exceeds a predetermined number. C). High tournament winnings ratio: If a player has won money in more than a predetermined percentage of the tournaments he participated in during a predetermined period. D). High tournament winnings sum: when a certain player has won more than a predetermined sum in sessions in which he participated during a predetermined period. E). Shoveling in multiple sessions: If a first player had played more than a predetermined number of heads up cash game sessions with a second player, and the first player has won more than a predetermined sum within the predetermined period. When one or more such conditions is identified (as detailed in association with FIG. 2b below), a case is raised, indicating a suspicion of a collusion situation.

At step 208, the user defines configuration variables and system variables, such as, but not limited to the following values, related to the situations relevant to a poker game, and more specifically to a Hold'em type poker game, described in association with steps 202, 204 and 206 above: rating of pocket cards (2 cards): each of the 169 combinations of two pocket cards are rated based on the strength of the cards, wherein the highest rating (169) will be given to the best 2 card combination; rating of hand strengths (5 cards): one-pair is rated one, two-pair is rated two, etc.; minimal average collusion factor of hands within a session for raising a case; time period for checking past sessions: to be used in post-session situation definition step 206; minimal average collusion factor for a player within a session for raising a case; strong hand folded before the flop settings: including minimum strength of pocket cards that were folded, and weight to be associated with the situation; Hand shoveling settings: including maximum strength of the hand that called the river, and weight to be associated with the situation; Increasing pot size level 1 settings: including a minimal number of bets or raises by a player, a maximal number of bets or raises by a player, and weight to be associated with the situation; Increasing pot size level 2 settings, including: a minimal number of bets or raises by a player, a maximal number of bets or raises by a player, and weight to be associated with the situation; Consecutive wins settings, including: a minimal number of consecutive wins for a player; and weight to be associated with the situation; Irregular pot size settings, including: minimal number of standard deviations for a hand, and weight to be associated with the situation; Shoveling in a session settings, including: minimal number of hands per tournament, and weight to be associated with the situation; Chips dumping in heads up tournaments settings, including: minimal number of hands per tournament, and weight to be associated with the situation; High tournament winnings ratio settings, including a minimal winning percent of a player, and a time period; Shoveling in multiple sessions settings, including: minimal number of sessions in the period, and minimal sum the first player won from the second player. At step 212, the user defines which queries, criteria or parameters are to be considered for researching the data collected during one or more sessions. The definitions may include both intra-session or inter-session criteria or parameters. For example, the user can define that searching for sessions common to two players will be performed over a predetermined time frame, such as a month, or checking for correlated wins or loses within a session between the two players. The checking may be defined to be performed for each session as data is collected or in a batch. The inter-session criteria may include checking correlated wins or loses of the same player participating in different games, such as a combination of two or more games including but not limited to: a Texas-Holdem poker session, an Omaha poker session, a “seven card stud” session, a “cho dai di” session, or the like. This last situation of a player losing in multiple sessions, whether of the same game or of different games, may point at a situation wherein a user is using a stolen credit card through which he can not receive money, but he can lose on purpose to a partner who will legitimately receive the money.

Referring now to FIG. 2B, showing the main steps 216 in the detection phase performed by an operative system according to the disclosed invention. The steps are taken prior to, during, or following a gaming session, comprising one or more rounds of games. At step 220, one or more hand situations are detected. The detectable situations belong to the situations defined at step 202 of FIG. 2A. The round situations are optionally detected in relation to one or more players. At step 224, a comment or another indication relating to each detected situation is attached to a data structure associated with the round. The comment should contain an indication to the type of the situation, such as a “Shoveling hand”, the nickname of the player associated with the situation, and a collusion factor or estimation for the situation. The collusion estimation is preferably a combination of the bet size of the player in the specific round, the user's state (for example the user's hand value in a poker game) and the type of the situation detected. After each round, session situations are detected at step 228. The situations are any of the situations defined in step 204 of FIG. 2A, such as consecutive wins. The session situations are optionally detected in relation to one or more players, whether a player has left the session, or the session continues and the player is still playing. At step 232, a comment or another indication relating to each detected situation is attached to a data structure associated with the session. The comment should contain an indication to the type of the session situation, such as a “consecutive wins”, the nickname of the player associated with the situation, and a collusion estimation for the situation. The collusion estimation may be a combination of individual collusion estimations associated with the rounds of the session, or alternatively involve general measures, such as the average pot size of the session.

After each round, after each session, when a player leaves a session, at predetermined time intervals, or according to other criteria, additional analysis step 236 is performed. In step 236, one or more situations, such as but not limited to the situations described in association with step 206 above are searched for, as detailed below. If one or more such situations are detected, or if a collusion factor assigned to a hand, a session, or a combination of one or more hands or one or more sessions exceeds a predetermined threshold, an action is taken at step 252. Such action can be automatically blocking one or more players having a certain username usernames, not allowing such players to continue playing, hold payments to such players, generating an alert to a game operator, wherein said alert can take any required form, such as an e-mail message, a text message, a phone call, a fax, or any other option for drawing the attention of an operator or of an employee thereof.

Step 236 comprises a number of optional steps, including player behavior detection step 240, multi-player behavior detection step 244 and periodic detection step 248. Each of steps 240, 244 and 248 may identify one or more situations. Player behavior detection step 240 identifies situations associated with one or more players. Step 240 is optionally performed when a player leaves a session, but can also be performed after every round in a session, for each player that participated in the session. Player behavior detection step 240 preferably identifies one or more of a collection of situations including strong hand folded before the top, shoveling hand, or increasing pot size associated with a round, consecutive wins, winning a relatively large sum of money during a short login time, irregular pot size, shoveling in a session or chip dumping in heads up, associated with multiple sessions and with one or more players. Step 240 can further check for any withdrawal request, the player's winnings from all the players he had played with by percentage and winning amounts. If a first player was playing and/or winning from a second player more than the average, the first player might have had an advantage in the relevant sessions, which may raise a collusion suspicion. Step 240 preferably checks for the existence of situation is combinations among multiple sessions. In step 244, correlation is preferably searched for between a first player associated with any of the detected situations, and other players. Step 244 can be performed between the first player and all other players in the session, or between the first player and any other player known in the system. Thus, step 244 may perform login proximity, and search for one or more other players who participated in a number of sessions with the first player. The step may check the time difference between the two players in joining or leaving the session, the number of common sessions in the last predetermined period of time, differences in hands, total wins for the two players, and similar factors, related to the circumstances of the sessions, to their flow, and/or to their outcomes. Step 244 may further check for common winnings of such players, in order to detect trapping situations, in which two or more players cooperate to win over innocent players. Details detection step 248 optionally fetches details related to a player according to parameters such as a nickname, a unique identifier, or other details. The fetched details preferably comprise any subset of the following: one or more IP addresses or other identifiers for a location the player was playing from, the player's e-mail address, payment method, phone number, zip code, or the like. Details detection step 248 can also fetch details of two or more players and compare them, in order to detect connection and possible common collusion. Such details may include tournament registration details, such as IP address from which players registered to a tournament, serial number of computing platforms from which players registered, registration times for a tournament, or the like. Additional tool that may be used in tracking collusions is a log of a chat between players, if one is enabled and stored. Automatic or manual searching of keywords, or other analysis of the log file can help identify collusions or collusion attempts.

Optional presentation step 250 presents to an operator or an employee thereof a report or a query result related to sessions or players. A report may be presented for example, for all sessions, or only for sessions in which a situation has been detected. The presented details can include the details of the situation, the players, the sums won or lost, characteristics of the session or the rounds, including collusion factors, characteristics of the players or of the session, the player's hands, the player's activities, and the like. Preferably, clicking or otherwise pointing at or marking the name or nickname of a player presents the details associated with the players, as fetched in step 248. During presentation step 250, an operator can activate step 240 or step 244 for one or more specific players. At presentation step 250 an operator can optionally change the collusion factor associated with a round or a session. Preferably, the changed detail is the one that is taken during further searches for situations, but the original collusion factors as assigned by the system may also be retained.

It will be apparent to a person skilled in the art that preliminary steps 200 can be performed in any desired order, and not necessarily in the presented order. Thus a session situation definition can precede or follow a round situation definition, and similarly with configuration definition or queries. In addition, any one of preliminary steps 200 can be performed in order to define new situations or configurations, during or between any of detection steps 216. Thus, situations may be added, deleted or changed, such that they take effect and are tested for during the on going work of the operative system. It will also be apparent that all steps within preliminary steps 200 and detection steps 216 are optional. Thus, an operator can choose for example not to define (and thus not to check) for round situations, but only for session situations, or vice versa. Similarly, an operator can employ any subset of additional analysis steps 236. It will also be appreciated that detection steps 216 can be performed either on-line, i.e. immediately after each round or session, but can also be performed offline and analyze situations on the basis of a batch provided for example after each day, week or another period of time.

Referring now to FIG. 3, illustrating a block diagram of the main components in an apparatus implementing the disclosed invention. The components are preferably components stored and executed by server 100 or platforms 110, 116, 124 or 132 of FIG. 1. The general structure of the apparatus comprises definition components 300, storage 314 and detection components 316. Definition components 300 comprise: round definition component 302 for defining situations associated with a round, as detailed in association with step 202 above; session definition component 304 for defining situations associated with a session, as detailed in association with step 204 above; post-session definition component 306 for defining situations associated with multiple sessions, as detailed in association with step 206 above; configuration definition component 308 for defining variables, constants and other data items related to situations associated with a round, a session or multiple sessions, as defined using components 302, 304 and 306 above; and queries or research applications definition component 312 for defining queries or applications for an operator to follow or investigate situations in one or more rounds or sessions, relating to one or more players. The situations, constants, configuration variables and constants, queries and other data defines by the usage of definition component 300 are preferably stored in storage device 314. Storage device 314 can be a magnetic tape, a magnetic disc, an optical disc, a laser disc, a mass-storage device, or the like. Detection components 316 comprise components for identifying, detecting, and researching the situations defined by definition components 300 as stored in storage device 314. Detection components 316 comprise detail retrieval component 318 for retrieving details associated with a player, a hand, a session, multiple sessions, multiple players or the like. The details may be required for other components detailed below, and may be, but is not limited to being related to any of the following: 1. The players details as provided during registration, such as user name, credit card, or others. 2. Login times, hands, sessions, or tournaments played, players that played with him, wins/loses, etc. 3. Communication details, such as IP address a player logged in from, serial number of the computing platform, service providers, and the like. Detection components 316 further comprise round situation detection component 320, for detecting situations associated with a single round, as defined by using round definition component 302 and as detailed in association with round situation definition step 202 of FIG. 2. Detection components 316 further comprise session situation detection component 324 for detecting situations associated with a session, whether the session was finished or prior to that, as defined by using session definition component 304 and as detailed in association with session situation definition step 204 of FIG. 2. Another component of detection components 316 is post-session behavior detection component 340, which identifies combination of situations related to one or more players and to multiple players. Multi-player behavior detection component 344 performs cross-checks of behaviors of players preferably identified by nicknames. Component 344 optionally checks for similarity in playing times, similar or complementary bet, raise, win, or lose patterns between the players, similarity in details, or the like, as detailed in association with step 244 of FIG. 2 above. Presentation component 350 is used for presenting the data collected regarding the rounds, sessions, detected situations and player details to a gaming operator. The data can be presented in any form as designed using queries or research applications definition component 312, including tables, charts, plain text, or any other presentation tool or method. The data can be presented in a file, a web page, a message, a printed page or the like, and be static or interactive. Detection components 316 further comprises alert generation component 354 for generating an alert when a situation is defined. The alert is preferably generated conditionally, for example when a collusion score associated with a round, a session, or multiple sessions exceeds a predetermined threshold, when a specific player is associated, according to various dates or times, etc. The alert generation can include sending an e-mail, sending a message, highlighting elements in a report, or any other way of drawing attention to a situation.

The disclosed invention provides a method and apparatus for detecting situations suspected as collusions in a game played over a network by remote players. The method and apparatus test for the existence of predefined situations in the flow or in the outcome of a round, or to outstanding accumulative results of a session of multiple games. The method and apparatus attach a player name or nickname to situations in which the player is involved, and provides tools for further checking the details of a player, or possible connection between two or more players. It will be appreciated that the method and apparatus can be applied to any game played by remote players according to rules, and that the above shown situations are exemplary only and additional or different rules and situations can be applied to the poker game or to any other game. The defined situations can be checked on a temporal basis, i.e. every predetermined period of time, and not necessarily when a round or a session ends. A collusion indication, estimate or factor can be attached to any player known to the system, and when a player having a collusion indication higher than a predetermined value is joining a session, an alert can be generated to an operator. It will be appreciated by persons skilled in the art that the disclosed method and apparatus are exemplary only, and different composition or order of components or steps can be designed to achieve the goals of the disclosed invention without departing from the spirit of the current invention.

It will further be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather the scope of the present invention is defined only by the claims which follow.

Claims

1. A method for detecting an at least one collusion or collusion attempt situation within an online computerized gaming environment, wherein the gaming environment is operated by an operator and an at least one player participates from a remote computing platform in one of more rounds of one or more sessions of a game, the method comprising the steps of

defining an at least one collusion situation; and

searching for an occurrence of the at least one collusion situation in the one or more rounds of the one or more sessions.

2. The method of claim 1 further comprising a step of assigning a collusion factor to the at least one collusion situation.

3. The method of claim 1 wherein the at least one collusion situation is a round collusion situation.

4. The method of claim 1 wherein the at least one collusion situation is a session collusion situation.

5. The method of claim 1 wherein the at least one collusion situation is a post-session collusion situation.

6. The method of claim 1 wherein the at least one situation is associated with the at least one player.

7. The method of claim 6 wherein the at least one player is associated with a username.

8. The method of claim 1 wherein the game is a poker game.

9. The method of claim 1 wherein the at least one situation is a strong hand folded before the flop situation.

10. The method of claim 1 wherein the at least one situation is a shoveling hand situation.

11. The method of claim 1 wherein the at least one situation is an increasing pot size situation.

12. The method of claim 1 wherein the at least one situation is a consecutive wins situation.

13. The method of claim 1 wherein the at least one situation is an irregular pot size situation.

14. The method of claim 1 wherein the at least one situation is a shoveling in a session situation.

15. The method of claim 1 wherein the at least one situation is a chip dumping in a heads up tournament situation.

16. The method of claim 1 wherein the at least one situation is the same player having coordinated wins or loses in at least two sessions.

17. The method of claim 16 wherein the at least two sessions are of different games.

18. The method of claim 2 wherein the at least one collusion factor is associated with a bet placed or raised by the at least one player.

19. The method of claim 1 further comprising a step of taking an at least one action when the occurrence of the at least one collusion situation is detected.

20. The method of claim 2 further comprising a step of taking an at least one action when the collusion factor exceeds a predetermined threshold.

21. The method of claim 20 wherein the at least one action is blocking the at least one player from playing.

22. The method of claim 20 wherein the at least one action is generating an alert related to the at least one situation.

23. An apparatus for detecting an at least one collusion or collusion attempt situation within an online computerized gaming environment, wherein the gaming environment is operated by an operator and an at least one player participates from a remote location in one of more rounds of one or more sessions of a game, the apparatus comprising:

an at least one computing platform;

an at least one definition component executing on said at least one computing platform, for generating a definition for an at least one collusion situation associated with the game; and

an at least one situation detection component executing on said at least one computing platform for detecting the at least one collusion situation in the game.

24. The apparatus of claim 23 further comprising a storage device for storing the at least one definition.

25. The apparatus of claim 23 wherein the at least one definition component is a round definition component.

26. The apparatus of claim 23 wherein the at least one definition component is a session definition component.

27. The apparatus of claim 23 wherein the at least one definition component is a configuration definition component.

28. The apparatus of claim 23 wherein the at least one definition component is an application query definition component.

29. The apparatus of claim 23 wherein the at least one situation detection component is a round situation detection component.

30. The apparatus of claim 23 wherein the at least one situation detection component is a session situation detection component.

31. The apparatus of claim 23 wherein the at least one situation detection component is a post-session situation detection component.

32. The apparatus of claim 23 further comprising a presentation component for presenting the at least one collusion situation.

33. The apparatus of claim 23 further comprising an alert generation component for generating an alert related to the at least one collusion situation.

34. The apparatus of claim 23 wherein the game is poker.