U.S. Pat. No. 9,202,340

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention overcomes the problem of preventing or reducing collusions and collusion attempts 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 information related to each player, regarding information relevant to the player's registration and information related to the player, such as recent or current games he participates in. Such information may relate to the Internet Protocol (IP) address or another identifier of the computer from which the player registered, or the computer from which he or she is playing, registration data, or the like. Having all relevant data, the system can search for and detect suspected situations or players suspected in collusion or collusion attempts, and take a preventive action. The suspicious situations may involve any one or more of the following: two players playing from computers having the same identifier such as the same IP address, two or more players that are related in some way such as players who transferred money to one another, players playing from the same kiosk (the same IP group), players playing from platforms belonging to the same agent or affiliate, two players whose playing times are coordinated, a player who was previously suspected or detected as performing or attempting a fraud, or other situations. The preventive action is optionally any of the following: blocking one or more users from playing, the blocking can be total or temporary, limiting the wager any one or more players can place, waiting until a minimal number of players are accumulated into a waiting list before enabling a game, randomly distributing a waiting list of players into separate games, disabling direct access to games (only via waiting list), sapping players between tables according to a predetermined criteria, asking one or more players for any type of verification, or the like.

The system is preferably configurable. Thus, a user can define, configure, or fine-tune preventive actions and situations that should be recognized.

Referring now toFIG. 1, showing a typical environment in which the disclosed invention is used. The environment comprises a server100running an application104of a game, such as poker, baccarat, blackjack or any other game in which players may participate. Application104preferably comprises components required for executing the game, and also monitoring components for a supervisor, game operator or another person108. Person108, 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 platform110running an application111, which relates beyond the scope of a single player, game or session. Thus person108can monitor the system online, 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 remote computing platforms. Thus, in a non-limiting example player112participates using platform116running application118, player120participates using platform124running application126and player128participates using platform132running application134. Each of server100and platforms116,124,132is 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, server100or any of platforms116,124,132can be implemented as hardware or configurable hardware such as field programmable gate array (FPGA) or application specific integrated circuit (ASIC). In yet another alternative, any of platforms116,124,132can be a cellular phone, a handheld device, a portable computer or any other computing platform provisioned with a CPU and memory. Server100is 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. Server110and platforms116,124,132are preferably connected through a communication network such as the internet. Alternatively, two or more units of server100and platforms116,124,132can be connected in a network such as a local area network, a wide area network, a wireless network or the like. Applications104,111,118,126and134are 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 applications111,118,126,134communicates with application104running on server100. In a preferred embodiment of the disclosed invention, application104is a server side of an application, such as a client-server application, while applications111,118,126,134are the client side. Preferably, application111is a client side application with operator privileges, while applications113,126and134are client side applications with player privileges. Applications104,111,118,126,134can be web applications accessed through the web, or installed on any computing platform they are being run from. Alternatively, computing platforms100and110can be the same platform, wherein applications104and111are the same application, communicating with applications116,128and134.

Referring now toFIG. 2, 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: definition steps200and action steps260. Definition steps200are preferably performed prior to action steps260, but they can also be performed at a later stage for adding, deleting or otherwise modifying the system.

Definition steps200comprise situation definition steps204for defining the situations in which a suspicion to collusion or collusion attempt rises, and action definition steps208for defining the actions that should be taken in response to such situations.

Situation definition steps204comprise IP related situation definition step212, for defining possible collusion attempts through an IP address of the computing platform used by one or more players. Such situations may include any one or more of the following: two players playing from the same IP address; a player playing from an IP address from which another player registered; the same player, recognized by the same user name, is tying to login from two or more computing platforms having different IP addresses; or other IP related situations. Another situation definition step is identifier of the computing platform related situation definition step216. Step216is similar to step212, but involves an identifier of the computing platform used by a player, such as the serial number, rather than the IP address. Situation definition steps204further comprise related players situation definition step220, in which situations related to multiple players are defined. Such situations may include two players that transferred money to one another. A further alternative is an indirect transfer: player A transfers money to player B, and player B transfers money to player C. Thus, the situation should preferably include recognizing players A and B as related, players B and C as related, and also players A and C as related. Other situations may include players who referred one another to the game, players whose playing times and durations overlap beyond a predetermined threshold, or the like. A further situation definition step is affiliate- or kiosk-related situation definition step224. The situations defined in step224include players playing from the same kiosk, internet cafe or are otherwise related to the same affiliate of the gaming operator. Such situations are preferably recognized by IP addresses or other identifiers such as serial numbers of the computing platforms available in a kiosk, as provided by the kiosk operator prior to establishing business with the game operator. Configuration definition step228is used for defining parameters for the defined situations or actions, such as thresholds, user preferences or the like. Steps212,216,220,224and228can be performed at any preferred order. Any of steps212,216,220,224and228can be omitted, repeated or re-visited before or after any other step. Definition steps200further comprise action definition steps208. Steps208include blocking definition step232, which includes blocking or otherwise limiting one or more players. A player can be totally blocked from further playing, blocked until the detected reason disappears or another condition is met, for example a related player stops playing, the wager that can be placed by the player can be limited, or the like. On indirect game access definition step236a user can define if and when direct access to a game table is enabled or disabled. If direct access is disabled, the system has control on routing a player to a table, for example through a queue or a waiting list. A further limitation can be defined on queue limitation step240, in which a user can define the minimal number of players to be waiting in a queue for a game to be opened. Setting the minimal number so that the players can be arranged in two or more sessions, reduces the chances that two coordinated players will play together, and can thus reduce the attractiveness of a scheme. A further step is random assignment definition step244, in which a user defines the parameters for randomly assigning players into tables or sessions, in order to reduce the chances that two or more related players will indeed play together. On swapping players definition step248the user indicates when and how to swap players playing in different tables between games. The swapping can be random, according to the time a player played on a specific game, or according to any other condition. On step252the user defines and implements ways to contact a suspicious player, for example by chat, e-mail or another mechanism in order to communicate with the player, receive further authentication or verification, or for any other purpose. On step256the user associates and optionally prioritizes one or more situations defined on situation definition steps204with one or more actions defined on action definition steps208, so that once one or more situations are detected, actions associated with these situations are taken.

Runtime steps260comprise situation monitoring step264, in which the situations defines in steps204are searched for. Preferably, step264is performed repeatedly in a continuous manner, so that a system according to the disclosed invention continuously checks for the occurrence of the situations are checked. Alternatively, the situations are checked when a certain event happens, such as a new player joining, a player depositing a wager beyond a predetermined sum, or the like. In yet another alternative, a timer event can also trigger an action. Action selection step268is performed after one or more situations are detected on step264. On step268one or more actions are selected according to the situation-action association defined on step256. On step272the selected actions are performed, such as blocking one or more players, swapping players or the like.

Referring now toFIG. 3, showing a block diagram of the main components in a preferred embodiment of an apparatus according to the disclosed invention. The apparatus is preferably a part of application104running on server100ofFIG. 1. However, parts of the apparatus, especially one or more of runtime components320may be implemented as a part of applications111,118,126or134. The apparatus comprises definition components300and runtime components320, which are preferably software components implemented using any programming language such as C, C#, C++, Java, VB, VB.Net, or the like, and any development environment, such as .Net, J2EE or others. Definition components300comprise situation definition component304, in which the user defines situations that may raise suspicion of fraud, such as a user trying to login to the system from an IP address which was used by another user for registration. The detected situations include the situations listed in association with steps204ofFIG. 2above, and may relate to collusion situations, to collusion attempt situations, or to both. Definition components300further comprise action definition component308, in which a user can define actions to be taken when a decision was made that a preventive action should be taken. The actions include the action types listed in association with steps208ofFIG. 2above. A further definition can relate to whether an action is taken automatically when the associated situation is detected, whether a confirmation of a human user is required, or whether an additional parameter is involved, for example a predetermined wager, above which confirmation is required or vice versa. Association component312is used for associating one of the situations defined using component304with one of the actions defined using component308. The association is optionally many-to-many, i.e., each situation may be associated with one or more actions, and each action can be activated in response to the detection of one or more situations. The definitions and associations are preferably stored in storage device316, from which they are fetched by runtime components320. Storage device316is preferably a mass storage device, for example an optical storage device such as a CD, a DVD, or a laser disk; a magnetic storage device such as a tape or a hard disk; a semiconductor storage device such as Flash device, memory stick, or the like.

Runtime components320are functional in detecting situations and acting accordingly when one or more players login or play with the system. Runtime components320comprise detail retrieval component324in which details relevant to one or more players are retrieved from storage316or from an alternative storage, storing for each player the IP address and identifier such as serial number of the computing platform from which he registered, a referring players if any, and additional details. The details may also comprise details about previous logins, IP address and identifiers of computing platforms from which the player played, wagers placed, wins, loses or other details. Runtime components320optionally comprise situation detection component328, for checking whether one or more of the situations defined using situation definition component304exists at a certain moment. The testing can be performed in a continuous manner, on a time basis, or when triggered by an event, such as a player joining a game. Possibly after one or more situations are detected, one or more actions are selected at step332. The actions are selected from the actions defined using action definition component308, and are activated by action activation component336. Communication component340is responsible for communicating the situation, if any, and the action taken to a user such as an operator of the gaming. The user can then override the action using action confirm/override component. In a preferred embodiment, a selected action is first transferred for approval, and is performed only if approved. Alternatively, the action is first performed, and is cancelled if overridden by a user. The preferred mode can be action-dependent, in which case no uniform policy is required. The mode can further be determined according to one or more parameters such as wager exceeding or not a predetermined sum. For example, stopping a player from playing may be performed automatically if the player placed a wager beyond a predetermined sum, and after receiving confirmation from a user otherwise. Alternatively, a decision whether to confirm or override the actions can be taken after opening a communication channel with the player, such as a chat, an e-mail, a telephone call or the like. It will be appreciated by a person skilled in the art that the division of the disclosed apparatus into components is exemplary only and divisions can be used without departing from the spirit of the current invention.

The disclosed method and apparatus are functional in preventing collusions and collusion attempts by players participating in on-line games. The disclosed method and apparatus are not limited to the mentioned situations and actions, which are provided merely as examples. Rather, additional situations and actions can be devised, such as blocking a player who was previously suspected in collusion or collusion attempt. It should be appreciated that one or more actions can be defined and taken without defining or detecting any situation, as a general precaution. Such actions may include limiting the number of players required for opening a new game not to go under a predetermined number.

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.