U.S. Pat. No. 10,617,957

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The elements illustrated in the Figures interoperate as explained in more detail below. Before setting forth the detailed explanation, however, it is noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in memories, all or part of systems and methods consistent with the contact management system architecture may be stored on, distributed across, or read from other machine-readable media, for example, secondary storage devices such as hard disks, floppy disks, and CD-ROMs; a signal received from a network; other forms of ROM or RAM either currently known or later developed; and the like.

Furthermore, although specific components of the communications architecture will be described, methods, systems, and articles of manufacture consistent with the contact management system architecture may include additional or different components. For example, a processor may be implemented as a microprocessor, microcontroller, application specific integrated circuit (ASIC), discrete logic, or a combination of other type of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash or any other type of memory. Flags, data, databases, tables, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways, including unstructured data. Programs may be parts of a single program, separate programs, or distributed across several memories and processors. Systems may be implemented in hardware, software, or a combination of hardware and software in one processing system or distributed across multiple processing systems.

As shown inFIG. 1, an exemplary architecture10for a system for providing an electronic game having one or more virtual currencies is shown. One or more client devices may run client applications20aand20bwhich may communicate with a game server40via a communications network30. The client applications20amay provide an interface to the user or player and provide game data to the game server40. In response, the game server40may interpret that game data and issue new game data to the client devices20aand20b. The game server40may store information in one or more databases45and also may provide an administrative interface50that enables an administrator to interact with the server40.

Although references will now be made to specific components of the system performing specific features, it should be apparent to one of ordinary skill in the art that such references are exemplary and are not intended to limit the scope of the claims in any way; furthermore, the functionalities described herein may be implemented in a virtually unlimited number of configurations. For example, the game server may be implemented as a single server configured to provide all of the systems functionalities, or the functionalities may be implemented across multiple servers.

The client applications20aand20bmay provide a user interface for the system and may communicate device specific information, user profile information, game data and other information with game server40via communications network30. In one embodiment, client applications20aand20bmay comprise stand-alone applications which may be either platform dependent or platform independent. For example, client applications20aand20bmay be stand-alone applications for a mobile phone configured to run on a mobile operating system such as the iOS™ operating system from Apple Inc. located in Cupertino, Calif., the Android™ operating system from Google, Inc. located in Mountain View, Calif., or the like. Alternatively, or additionally, client systems may connect to the game server via the Internet using a standard browser application. Alternatively, or additionally, one or more of the client applications20aand20bmay be an application configured to run on mobile computer such as a laptop computer, handheld computer, tablet, mobile messaging device, or the like which may all utilize different hardware and/or software packages. Other methods may be used to implement the client devices20aand20b.

The communications network30may be any type any private or public communication network, such as the Internet, and may include one or more communications networks. In some embodiments, the communications network30may be a cellular network such as, for example, a Code Division Multiple Access (CDMA) network, Global System for Mobiles (GSM) network, General Packet Radio Service (GPRS) network, cdmaOne network, CDMA2000 network, Evolution-Data Optimized (EV-DO) network, Enhanced Data Rates for GSM Evolution (EDGE) network, Universal Mobile Telecommunications System (UMTS) network, Digital Enhanced Cordless Telecommunications (DECT) network, Digital AMPS (IS-136/TDMA), Integrated Digital Enhanced Network (iDEN), Long-Term Evolution (LTE) and the like.

The game server40may store game data, user profile information and related information in a database45, receive game data, device data, and user profile information from a client application20aand20b, implement game logic, provide a user interface for an administration inerface50, and the like. As should be apparent to one of ordinary skill in the art from the disclosure herein, other related services may also be provided.

The database45may store a variety of information, including user profile information, user preference information, game data, tournament data, and the like. In some embodiments, all information stored in the database45is encrypted.

Exemplary Poker Game Using Virtual Currency

Although reference will now be made to certain embodiments described herein with reference to a poker game, the principles presented herein may be used for other games, such as black jack, roulette, slots and the like. In addition, the embodiments presented here may also be used in non-casino games that use virtual currencies. The embodiments illustrated herein should therefore not be interpreted to be exclusive or limiting, but rather exemplary or illustrative.

Referring toFIG. 2, an exemplary screen shot of a main poker lobby is shown. Upon logging in to the server40, the client application20amay present the player with a main lobby200from which the player may select a variety of games224. Exemplary games may include ring games (or cash-in games) that may be segmented into casual or high-stakes game types, all-in or fold game types, sit-and-go game types (which may offer scaled down tournament type play) and tournament game types. For each game type, a list of available tables222may be displayed along with certain game type information, such as a buy-in, number of total seats, number of available seats and the like. Selection of a table from the list222may cause additional information to be displayed in a game detail display section230, which also may provide an interface control232for the player to request a seat at the selected table. In the illustrated embodiment, the main lobby200may include player indicia202that shows the player's name, chip indicia203that shows the player's current chip count, level indicia204that shows the player's current level (e.g. a numerical representation corresponding to a total number of experience points earned for performing in-game actions), reward point indicia206that shows the player's current reward point total.

In addition, the main lobby200may provide an interface control208that, upon selection by the user, presents the user with the opportunity to purchase various in-game items. Referring also toFIGS. 3a-3d, exemplary screen shots300a-300dof a virtual currency storefront is shown. As shown inFIG. 3a, a user may purchase one or more virtual currencies using actual currency or money. In the illustrated embodiment, the user may purchase gold chips302that may be used to wager in electronic poker games and purchase other in-game items (as described below and shown inFIGS. 3band 3c), a booster304that may increase virtual currency rewards earned by performing in-game actions such as mini-games, and a lucky spin ticket306that may grant the user a chance to win virtual currency through a lucky spin mini-game212(described below and shown inFIGS. 4aand 4b).

In some embodiments, the user may be able to purchase additional in-game items using one or more of the virtual currencies. For example, a user may purchase avatars310(as shown inFIG. 3b) and charms312(as shown inFIG. 3c) using gold chips302. Avatars310may be icons, 3-D cartoon characters or other images that act as visual representations of the user in the game. In some embodiments, a user may be given a default avatar, such as a dark silhouette. Charms312may be objects that are traditionally associated with good luck, such as a rabbit's foot, horse shoe, four leaf clover and the like. In some embodiments, a player may be able to transfer a charm312to other players. Charms312may be permanent, i.e. do not expire. Finally, in some embodiments, players may be able to purchase gold chips302using reward points314.

Players also may be able to win virtual currency (such as gold chips302) through one or more mini-games provided by the system10. An exemplary virtual currency giveaway mini-game is shown in the screenshots400aand400bdepicted inFIGS. 4aand 4b. In the illustrated embodiment, a player may spin a wheel410having multiple segments420a-ccorresponding to multiple prizes. Referring also toFIG. 5, the user may begin the process of obtaining a reward by selecting the spin button430at step510. In response, the client application20amay send a request for a reward to the game server40at step520. The game server40may validate the request at step530and authorize the distribution of the reward in light of reward management rules at step540. If the request is valid and the distribution is authorized, the server40may determine a reward amount to the player via the client application20aat step550. Rewards may be authorized, for example, if the reward is in compliance with reward management rules, as described. The reward amount may be fixed amount, such as $500 in gold chips302or may be selected randomly from a set of possible rewards. Other methods may be used to determine a reward amount. In the example illustrated inFIG. 4b, the system10distributed a reward of $200 in virtual currency in response to the player's spin of the lucky wheel.

Reward Management Rules

Game server40may authorize distribution of a reward by implementing reward management rules. In some embodiments, the reward management rules may include establishing one or more allotments of rewards that may be distributed by system10via a particular reward distribution method. For example, in embodiments that utilize poker chips, a reward allotment may be a pool of free chips that may be distributed via a reward distribution method, such as the lucky spin mini-game shown inFIGS. 4a-b. In some embodiments, free chip pools also may be allocated based on user information, such as a user's IP address, user account type and the like.

Limiting the distribution of free chips may provide several benefits. For example, one benefit that may be obtained by limiting the amount of chips in the game may be a better user experience by encouraging good plays. Another technical benefit that may be obtained by limiting chip distribution is to limit the impact of hackers creating fake accounts or finding a bug in a distribution method, such as the lucky spin mini-game.

Reward allotments (also referred to herein as free chip pools) may be established for each reward distribution method tied to the completion of in-game activities, also referred to as triggering events. For example, rewards may be distributed for completing a player registration process, completing an email validation process, completing a tutorial, playing a reward mini-game such as the lucky spin mini-game described above, collecting a timed reward package (such as a reward package that may be collected on a daily, hourly or other basis). In some embodiments, a set of in-game activities may be grouped, such as playing 100 hands or 500 hands, the completing of which may trigger a reward distribution. In some embodiments, free chips may be distributed to a registered player if their balance falls below a predetermined threshold, such as giving the player 300 chips if their balance falls below 200 chips. Other amounts also may be used.

The size of a reward allotment may be based on an expected number of chips that may be distributed via the pool's associated distribution method based on, for example, an expected or historical daily player count, expected or historical daily new player registrations and the like. Other parameters also may be factored into the size of a free chip allocation pool. Distributed rewards may be deducted from the allotment and reward allotments may be reset or reestablished at set intervals, such as once a day (e.g. 24 hour period), once an hour or the like. Other intervals also may be used.

In one embodiment, reward allotments may be established as follows: a first allotment of 11,500,000 may be established for the total amount of free chips that may be distributed in a 24 hour period; a second allotment of 1,500,000 may be established for rewards for email validation for a 24 hour period, and a third allotment of 10,000,000 may be established for reward via the lucky spin mini-game for a 24 hour period. The server40may compare a request for a reward distribution against one or more relevant reward allotments before authorizing the reward. If distribution of the reward would exceed an allotment, the request may be denied. If not, the reward amount may be subtracted from the reward allotment and the reward may be distributed to the player.

Other reward management rules also may be implemented. For example, a user may be limited to a predetermined number of uses of a distribution method over a given time. For example, a player may be limited to one spin of the lucky spin mini-game per day unless the player purchases additional spins as described above. As another example, a player may be limited to a single distribution for verifying an email account associated with the player's game account over the life of that game account. Other distribution methods limitations may be implemented.

Automatch

Another method by which the system10may prevent fraudulent behavior is by limiting the ability of players to choose a particular table or seat in certain conditions that indicate the player is likely to be using free chips. In some embodiments, conditions that indicate the player is likely to be using free chips may be table properties for the requested table, user properties for the requesting user, and the like. For example, players at low stakes tables and/or players with relatively new accounts may be likely to be using free chip. The age of an account may be based on chronological time, in-game activity (such as a number of hands played and the like). Other conditions also may be used to indicate a likelihood that a player is using free chips.

Referring toFIGS. 2 and 6, a player may be presented with a list of available tables or table types220at step602. The player may request to play at a selected table or table type from the list by selecting a corresponding interface control232, which causes a request to join the selected table or table type to be received by the server40at step604. The request may include a player identifier, the player's IP address, the player's current chip stack, and table parameters for the desired table or table type. The server40may determine if seating at the selected table or table type is restricted or limited at step606. If not, the player may be allowed to select a seat at the requested table at step608. If the selected table or table type does have restricted or limited seating, the system may determine if the player's chip stack is equal to or greater than a buy-in associated with the table at step610. If the player's chip stack is not large enough, the player may be returned to the lobby at step612.

Optionally, the server40may prevent the player from sitting at more than one table if it is likely that the player is using free chips. In such embodiments, the server40may determine if the user already is seated at a table at step614and, if so, the player may be returned to the lobby at step612. If the player is not already seated at another table, the server40may determine if there are any open seats at an existing table that meets the requested table parameters at step616and, if so, may select that table at step618. If no such table exists, the server40may create and select a new table that meets the requested table parameters at step620. In either case, the system may determine whether any other players at the selected table have a common IP address with the requesting player at step622as a further step to reduce collusion among multiple accounts. If so, the player may be returned to the lobby at step612. If no other players at the selected table share a common IP address with the requesting player, the server40may randomly select a seat and sit the player at the selected table and seat at step624. As a result, the player may play at a table having their desired characteristics (as shown inFIG. 7) in an environment in which the abuses of fraud, collusion, hacking and other unethical behavior unique to electronic games is reduced.

A system for reducing fraud, hacking and other exploitive behavior in an electronic game may comprise a first software module for use on a first device comprising one or more processors and one or more memories and a second software module for use on the server computer comprising one or more processors and one or more memories. The first software module may include instructions stored on a non-transitory computer readable medium that: provide a user interface to a user, the user interface including controls that allow a user to request a reward of an amount of a virtual currency via one or more reward distribution methods; transmit, to a server computer, a request for the reward via a first of the one or more reward distribution method. The second software module may include instructions stored on a non-transitory computer readable medium that: establish a reward allotments for each of said one or more reward distribution methods; receive the request from the first device; determine a reward amount to distribute to the user in response to the received request; and if the reward allotment for the first of the one or more reward distribution methods is greater than the reward amount, subtract the reward amount from the reward allotment for the first of the one or more reward distribution methods and distribute the reward amount to the user.

The reward allotment may be reestablished daily.

The reward amount may be randomly selected from a set of possible rewards.

The reward distribution methods may include at least one selected from the group comprising a player registration process, an email validation process, a tutorial, a reward mini-game and a timed reward package.

The reward allotment may be for the total amount of reward distributions that may be distributed on a given 24 hour period through all reward distribution methods.

The first software module may further include instructions stored on a non-transitory computer readable medium that: present a list of available tables to the user; receive a selection of one of the listed tables; and transmit, to the server computer, a request to play at the selected table. The second software module may further include instructions stored on a non-transitory computer readable medium that: receive, from the first device, the request to play at the selected table; determines if the selected table has restricted seating and if so, automatically sits the user at a table in accordance with restricted seating rules.

The determining if the selected table has restricted seating may include determining if a buy-in associated with the selected table falls below a predetermined threshold.

The automatic seating of the user at a table in accordance with restricted seating rules may include determining if a player's virtual currency total is equal to or greater than a buy-in associated with the selected table.

The automatic seating of the user at a table in accordance with restricted seating rules may include determining if the player is already seated at another table.

The player may have an associated IP address and the automatic seating of the user at a table in accordance with restricted seating rules may include determining if a second player having a common IP address with the player is already seated at the selected table.

While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.