U.S. Pat. No. 8,715,077

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG. 1is a system diagram100illustrating a system that facilitates wagering within electronic multiplayer games of skill. A plurality of players110i(i=1, 2, . . . , N) operate respective player clients120i. Each player client120iincludes a third party game instance130i. The game instance130iis any online digital game (e.g., video game) in which player skill determines game outcome, not chance, and wherein multiple players110ican compete against one another online. Games are consistent across game instances130i(e.g., if the players110iare playing chess, each game instance130iis an instance of an electronic chess game). Each game instance130ican be in communication with and receiving game data from a third party game server150. The game server150provides game data necessary to operate the game. Alternatively, game instances130ican exchange game data directly.

Each game instance130iincludes a peer-wagering module140i. The peer-wagering module140iintegrates into the game instance130iand enables the players110ito wager on the outcome of a given game competition. The peer-wagering module140icommunicates with and works in tandem with a transactional server160. The transactional server160maintains account information for each player110i, including financial information, and acts as a trusted party to hold funds in escrow and/or secure funds to enforce the terms of a wager (i.e., ensures winning players receive the winnings).

The transactional server160can also pass data characterizing advertisements (e.g., advertising logic, invitations, and/or messages) to the third party game server150. This advertising data can be algorithmically customized based on player110ihistorical gaming data or metrics of the gaming data. For example, an advertisement could include or be modified to prompt the player with “you've won four out of five of your last games, click here to play in $5 tournament and take your game play to the next level.”

FIG. 11is a process flow diagram1100illustrating a method of advertising to (e.g., inviting) a player (e.g., user) to enroll and participate in an online skills based gaming tournament. Data is received at1110characterizing historical skills-based gaming metrics for a first user and historical skills based gaming metrics for at least one other user. The player can be currently playing or have recently played the game and the player can be playing the game while not being enrolled in an online skills-based gaming competition. A targeted advertisement to present to the first user is determined, using a set of rules, at1120. The targeted advertisement specifies at least one skills-based game and a characterization of other user's historical skills-based gaming metrics. The targeted advertisement can entice the player to take a specific action based upon the player's gameplay (e.g., the player is prompted/invited to join a competition). The targeted advertisement can be customized to an individual player. The targeted advertisement is generated at1130and the advertisement is provided at1140. Providing can include transmitting, persisting, displaying, and prompting to the player.

The historical skills-based gaming metrics can be supplied by the player client120i, or tracked and/or recorded (e.g., over time) by the transactional server160, or the third party gaming server150. Historical skills-based gaming metrics can include game attributes that can be traced (e.g., recorded or monitored) and are associated with the player's in-progress, most recent, and/or past game plays. For example, historical skills-based gaming data can include: an in-game score, game outcome, time to complete a stage, game level achieved, difficulty, number of enemies, power-ups acquired, player ratings, number of wins or losses, statistical measures of attributes (e.g., average scores, ratio of wins to losses, etc.), top scores across some or all players, completion of any game related task, objective, and/or achievement, in-game acquisition of items, and/or other character attributes. Historical skills-based gaming metrics can include other traceable game attributes.

When the advertisement is presented to the player and/or the content of the targeted advertisement can be based on configurable messaging rules (i.e., a set of rules). The rules can be used to target players with specific attributes, levels of skill, or relationships. For example, an advertisement or invitation could prompt to a player to join and wager on a tournament based on a player exceeding a certain predetermined value or score for a particular in-game challenge. The rules could include whether the player has completed a particular level, game, number of games played, time played, or other game element. An advertisement could be presented when a player is among a certain percentile of players (e.g., prompting players to enroll in a tournament with like-skilled players).

Additional rule examples can include when a player has wagered, lost, and/or won at least a certain amount (e.g., prompting players to enroll in a tournament that requires “high stakes” or large minimum wagers), when one or more other players associated with the first player (e.g., links on a social networking website) are enrolled in a tournament (e.g., prompting a player to enroll in a tournament with their friends), when a player has played a certain number of games, and/or when a player has completed a level or challenge in a tournament. The messaging rules can also be based on a geographic location of the player (e.g., online wagering regulations may vary based on locality), or whether the player is eligible to wager cash or rewards on a tournament. Administrators, and/or tournament creators can configure or customize the messaging rules.

The targeted advertisement can include graphical, textual, and hyperlink information necessary to populate pre-existing advertising space with a customized invitation for players to wager on a skill based gaming tournament. Targeted advertisements can include customized messages derived or based on the messaging rules and/or other data triggered by a rule, gameplay, or historical skills-based gameplay metrics. The targeted advertisement can be targeted to the player and include a characterization of the player's historical skills-based gaming metrics and a characterization of one or more other player's historical skills-based gaming metrics. For example, the targeted advertisement can include information regarding how many active games are being played for a given game or a different game. The advertisement can include a message regarding how many of the player's friends, contacts, or in-network users are active in the system. The advertisement content can show how a player would fare if they joined a tournament or played a different game by including a comparison between or characterization of the historical gaming data and other players in the system (e.g., showing how much money the player would have won in a real tournament, a comparison of the player's average score to other player's average scores, a mock leader board where the game player is compared to all players of the game, etc.). The targeted advertisement could include a proposed wager amount for the first player.

FIG. 12is an example advertisement1200presented to a player after the player satisfied a message rule (e.g., had a high score). The advertisement includes text1210, including a characterization of other player's historical skills-based gaming metrics, and a button1220(i.e., link) to redirect the player to enable the player to enroll and wager on a tournament. The advertisement could further includes graphics and be embedded in the game user interface.

FIG. 10is a process flow diagram1000illustrating a method of advertising an online skills based competition. At1010, a digital skills based game is provided to a player (i.e., user). The game contains display space for displaying advertisements. At1020, a targeted advertisement to present to the first user is determined using historical skills-based gaming metrics and a set of rules. The targeted advertisement specifies at least one skills-based game, and a characterization of at least one second user's historical skills-based gaming metrics. The advertisement display space is modified at1030using the player's historical gaming data to prompt the player to use a peer-to-peer wagering platform to enroll in and place a wager on an online skills based gaming competition. At1040, the online skills based gaming competition is provided to the player.

By utilizing specific player's historical gaming data and messaging rules, the advertisements/messages can be customized to the player and each advertisement has a higher likelihood of enticing the player than a non-customized (e.g., a general) advertisement.

Referring again toFIG. 1, players110ican register and fund accounts either directly with the transactional server160(for example, accessing the server via a web browser) or through the peer-wagering module140i. The players110ican fund their account through several means, such as, for example: PayPal, credit cards, Automated Clearing House (ACH) transfer, cash, loyalty cards, pre-paid cards, coupons, system credit, credit earned by watching advertisements, Google checkout, etc. Other methods of funding the account are possible.

Players110ican create tournaments. Prior to game play, the peer-wagering module140ican receive credential information from the player110i, send the credentials to the transactional server160, which can authenticate the credentials. Authentication can include age and location controls to ensure local law compliance. Age can be entered by the player110iand location can be verified by any of a billing address used to fund an account, the GPS location of a mobile device (if available), and an IP address of the player client120i. When each player110ienrolls in a tournament, including placing a wager on the tournament (e.g., paying a tournament entry fee), the transactional server160can secure the player110ifunds. Secured funds cannot be withdrawn or used for another wager. Securing the funds can include transferring the funds from the player account to an escrow account as well as placing a “hold” on the funds in the player's account.

Once the transactional server160secures funds from all participating players110i, the tournament can proceed. The tournament proceeds under normal game mechanics (such as each game instance130icommunicating game data with the game server150) until game play completes. The transactional server160receives completed game statistics from the game server150or, alternatively, from each peer-wagering module140i. The game statistics can indicate winners and losers based on one or more in-game metrics. A player110ican also determine one or more custom in-game metrics to be used in determining winners and losers during tournament initialization. The transactional server160transfers the previously secured funds to one or more player110iaccounts based on the game statistics. For example, a winning player can have the player's winnings transferred from the other players' accounts or the secure escrow account into the winning player's account. The transactional server160sends financial data related to winnings and losses to each peer-wagering module140i, which provides the financial data to the players110i. Additionally, the transactional server160can send the game statistics to each peer-wagering module140i, which provides the game statistics to the player110i.

Game statistics sent to the transactional server160from either the game server150or from each peer-wagering module140ican include summary level statistics such as winners and losers and/or specific in game actions such as player orientation within the gaming environment, player actions (e.g. buttons pressed or character movement), or user display details. The user display details can include, but are not limited to, graphics card-information, in-game screen shots and live action game-play. These statistics can be used to determine system level player-rewards that are independent from tournament outcomes as well as in the detection of fraudulent behavior through any of the following: real-time tournament monitoring, delayed tournament review, or statistical player review for idiosyncratic behavior or behavior characteristic of fraudulent play.

The peer-wagering module140iprovides necessary user interface components and player110ito transactional server160interaction functionality for the game instance130i. This provides a low barrier for third party game providers to enable the peer-wagering functionality into the game. The peer-wagering module can be implemented with platform specific software development kits (SDKs).

Communication can occur over any suitable communications network, such as, for example, the internet.

FIG. 2is a process flow diagram200illustrating a method of facilitating wagering within electronic multiplayer games of skill. At210, the transactional server160receives data characterizing each player and each player's wager amount. The wager amount can be variable among the players or fixed among the players. Optionally the players may be matched in tournaments with players wagering similar amounts. Each player has enrolled in a third party skills based gaming competition (e.g., a tournament). At220, the transactional server160secures, for each player and using a respective player account, funds equal to the corresponding received wager amount. The players have previously registered the player account and deposited funds in the account. The transactional server160can place the funds in an escrow account until the completion of the gaming competition. Alternatively, the transactional server160can secure the funds by placing a “hold” on the funds in the players' accounts preventing withdrawal or use of the funds. At230, the transactional server160transmits data characterizing a confirmation that the transactional server160has successfully secured funds from each enrolled player. If funds as to a player are not available in the respective player account, the transactional server160can send data to prompt the player to deposit additional funds into the player's account.

Optionally, at240, the transactional server160receives data characterizing the outcome of the competition. The data can include in-game statistics and indicate that some of the enrolled players are winners and some are losers. Alternatively, the transactional server160can differentiate, based on the in-game statistics, players that are winners and players that are losers. The transactional server160can determine based on the in-game statistics the amount of secured funds (if any) to which enrolled players are entitled. Optionally, at250, the transactional server160can transfer at least a portion of the secured funds to one or more accounts associated with their respective enrolled players. Optionally, at260, the transactional server160can transmit data characterizing the transfer and/or the in-game statistics. The transactional server160can receive the respective data from and transmit the respective data to one or more of the peer-wagering module140iand the third party game server150.

The game can be asynchronous. Asynchronous games cover any turn-based game where players110itake turns and real-time game play is not an issue. A player110imay leave the game to perform other tasks on the same device on which the game is running, without forfeiting a tournament. Asynchronous games can include games such as Chess, Checkers, Go, and most board games where timing of player turns is not a consideration.

The game can be synchronous. Synchronous games cover any game where real time interaction between the game and player or between players is required. For example, first person simulations wherein each player has one or more characters (i.e. avatars) and multiple players' characters are interacting in real time with each other's characters or game environment in a synchronized way. First person shooters, driving and racing simulators as well as real time sports simulations are synchronous. Some turn-based game designs can also include synchronous aspects if all players must be present at some times while a game is in progress.

Whether synchronous or asynchronous, an entire level of a can game constitute a turn, and the players can take turns independently. For example, games such as Angry Birds, where two or more players can complete a level, independently but potentially at the same time, and the winner can be determined based on some metric when all players complete the level. In this manner, an entire level constitutes a player turn.

The transactional server160can provide an application-programming interface (API) for the third party game instances130ior the third party game server150to communicate with the transactional server160.

Establishing tournaments can allow players110ito compete with one another within skill-based games in a single or series of contests. Tournaments can work with synchronous and asynchronous play modes, and tournaments can be user or system generated. Tournaments can be either public or private. Public tournaments can be open to any registered player while private tournaments can be open only to invited players. Any tournament must necessarily have at least two participants. Player-created tournaments can require a specific number of entrants in order to begin the competition, whereas system-created tournaments can have a fixed or variable number of permitted and/or required entrants. Tournaments with a variable number of participants can have a fixed starting time and can have a maximum number of allowed entrants.

Tournaments can comprise a single match or a series of matches (i.e., multi-round tournaments). The structure can be determined at the time of tournament creation. Each match can have a specified number of participants and winners. A specific win-metric can determine the winners of each match. Individual tournament rounds (e.g., matches) can begin at a pre-determined time set up by the creator of the tournament or they can proceed in immediate sequence. Matches not completed by the next designated match time slot can be terminated, and the top contenders from each non-concluded match can be rewarded the win for that match.

Each tournament or tournament round can have defined criteria by which the winner(s) are determined. Possible win-metrics can be dependent on the type of game, but can include (for example): highest score, first to complete a level, least moves to complete a level, etc. Additionally, each tournament can have an entry fee which is a dollar amount required to enter the tournament (i.e., a wager amount). However, some system-created tournaments can waive this fee for some or all players110i. The tournament creator can determine the amount of the entry fee.

Prizes offered to tournament winner(s) can be determined at the time of tournament creation. Prize information can be visible to all prospective tournament entrants. In the case of user-created tournaments, the player creating the tournament can set the total prize pool automatically. For example, the creating player can set the prize pool based on the number of entrants and the entry fee that the creating player has specified. The creating player can allocate prizes in a variety of ways such as awarding prizes to more than one participant in a given tournament. A tournament creator can specify the number of winners and the percentage allocation of prizes to each of those winners. A public tournament creator can base prize distribution on individual performance relative to the defined win-metric; however, a private tournament creator can incorporate team scoring relative to the win-metric in determining prize allocation.

An example player110iinteraction with an asynchronous multiplayer game including the current subject matter includes creating a tournament, joining a tournament, and concluding a tournament. To create a tournament, the player110i, using the player client120i, launches a third party game instance130i. The player can choose within the game to compete using the peer-wagering module140i. The user can log into their transactional server160account, optionally electing to remain logged in to the account within this session and future session of this game.

FIG. 3is an example user interface300integrated into a third party game that can present to the player for signing into or registering their account. At310, the player110ican enter credential information such as an email address and password. At320, the player110ican sign in using the play button320.

Once signed into their account, the player110ican create a public or private tournament and set parameters for the tournament. The transactional server160can prompt the player to add funds to their account if the player110ihas inadequate funding. The player110ican invite several known players using their account names (e.g., email addresses, user names, etc.). If the tournament is a public tournament, uninvited participants can join. Public tournaments can start on a rolling basis with players taking their first turn as soon as they join the tournament or as soon as the player before them has played (depending on game mechanics). Private tournaments start when the prescribed number of participants has entered the tournament. The game proceeds according to the game developer's prescribed game mechanics.

If the player110idoes not yet have an account, the player110ican register for an account by entering information such as email address and password in data fields330and pressing the next button340.FIG. 4is an example user interface400integrated into a third party game that presents to the player110ifor registering their account. The player110ican enter at410credit card information and billing address and specify at420an amount to charge the credit card. The player110ican select checkboxes430to agree to the terms of service and confirm payment. The player110ican complete the registration using push button440. The player110ican enter additional account information (not shown) such as full name, age, phone/mobile number (for SMS notification of game events), and an account name that will be visible to other players110i.

To join a tournament, a player110ican receive a notification inviting them to a tournament. Notifications can arrive via any one of several means. For example, push notifications, SMS, email and in-game notifications are all options for notification. Alternatively, the user browses public tournaments that are seeking players and selects one. The player110ilaunches the game via the notification they have received or proceeds into the game after selecting a public tournament. The player110iaccepts the terms of the tournament, including the funding requirements of the tournament in response to a prompt. If the player110ihas inadequate funding in their account, they can add funds. The player110ican accept the terms of the tournament and enter the game. The game proceeds according to the game developer's prescribed game mechanics.

In the case when the multiplayer game is synchronous, all players110imust start the game simultaneously. To provide this functionality, the transactional server160presents the players110iwith a tournament lobby while they wait for the synchronous game tournament to begin. The transactional server160provides the lobby for both the player110iwho created the tournament as well as the players110iwho join the tournament. The players can see the other players as they join the tournament and can have the opportunity to withdraw from the tournament before the tournament begins. The game can begin a predetermine length of time (e.g., 60 seconds) after all players have joined the tournament. Any withdrawal by the players110iafter this point constitutes forfeiture of the tournament entry fee (i.e. the wager).

The tournament can also start at a predetermined time independent of the number of players110iin the lobby. Players110ican sign-up for the tournament in advance of the tournament start time. Once players110ihave signed-up for a tournament, the transactional server160can alert the players110ithat the tournament is starting soon through a variety of methods such as email, SMS, in-game alert, etc.

FIG. 5is an example user interface500integrated into a third party game that can present to a player110ibrowsing public tournaments that are seeking players. Pending tournament list510presents several public tournaments and details regarding those tournaments. For example, the first tournament on the list520shows a summary of the tournament settings. The tournament520name is “James Game,” the type of tournament is “highest score,” there are currently ten entrants with a maximum of twelve as shown under number of players. For this example tournament, the wager or entry amount is one dollar and the total prize or payout is ten dollars. The time left shows when the example tournament520will start.

Detailed information530provides tournament information for a selected tournament and shows the name, type, number of players and maximum players, entry fee, and prize breakdown. In this example tournament, the top three players110iwill receive winnings Player list540provides each player name and overall score currently entered in the tournament. Push buttons550enables the player110ito enter or not enter the tournament.

At the conclusion of a tournament, the normal game mechanics are complete and the third party game server150posts data to the transactional server160indicating game results. Each player110iwho completes the game should see game results immediately, including data from the transactional server160detailing their winnings or losses for the tournament. Other players110iin the tournament can also receive a notification detailing their winnings or losses from the transactional server160and indicating that their tournament is complete. For games where a continuous connection to the service is important to game-play or game integrity, any player110iwho drops off the service and does not re-connect within a certain predetermined period forfeits the game. Third party game developers can determine the period or can optionally include reconnection logic to re-establish a lost connection between players when such a loss of connection cannot be used to gain an advantage in either game-play or waging. Additionally, players may be required to take their turn or take another specified in-game action within a predetermined amount of time. Players who do not act within this set amount of time, as determined by third party game developers, will forfeit the game. The peer-wagering module140ican report to the transactional server160when the player110idisconnects from the competition or when the player110ihas not taken his turn within the allotted time.

FIG. 6is an example user interface600integrated into a third party game that presents to the player110iand shows the game statistics and results (e.g., a leader board). Column610lists each tournament participants account name. Column620displays each participating player's in-game rank and column630displays each participating player's in game score. Column640displays any prizes won by the corresponding player. In this example result, the top three players received funds. At650the player110ican launch the game again and re-enter a new tournament with the same settings (e.g., same wager amount, win metric, invite list, etc.). At660, the player110ican go to a tournament selection screen.

FIG. 7is a data flow diagram700illustrating data communication flows between an example implementation of the elements ofFIG. 1for an asynchronous turn based game. Elements ofFIG. 1are shown across the top and bottom ofFIG. 7, specifically, player110i(operating player client120i), third party game instance130i, peer-wagering module140i, transactional server160, and third party gaming server150.

At702through708the player110ilogs into the transactional server160using the interface provided by the peer-wagering module140iembedded in the game instance130i. The peer-wagering module140iauthenticates706with the transaction server160allowing for further messaging between the peer-wagering module140iand the transaction server160, via authentication tokens, security certificates, or other user/password exchanges708. All future requests are set with the valid authentication method. Peer-wagering module140irequests710a list of potential gaming opponents for the logged in player for the currently running game. The transactional server160and peer-wagering module140ireturns (712and714) a list of the players available for play as well as a list of current tournaments requiring additional players. The creating player110icreates a tournament716and invites other players110i. The peer-wagering module140isends718the transactional server160data regarding invited players110iand the tournament name. When a player110ijoins the tournament, the player's information is communicated to the peer-wagering module140ias well. Funds are transferred720from the joining/creating player's transactional server160account. The transactional server160places these funds in escrow or places a “hold” on wagered funds in player accounts. The transactional server160returns722a unique tournament ID and all entered players110iwait724for the tournament to start. Each peer-wagering module140icommunicates with726the transactional server160with the tournament ID until the server indicates728the tournament has started. The peer-wagering module140ican signal the transactional server160to force the tournament to start for those players who have joined.

During normal game play, all communication (732and734) occurs between the third party game instance130iand its own third party game server150. All active gaming statistics including rank of each player is communicated and coordinated between the game instance130iand the gaming server150. The third party game instance130icommunicates736data regarding any players110iwho have left the game or any data relevant to the detection of fraudulent behavior.

On completion of the game, each connected peer-wagering modules140isend (740and742) tournament statistics to the transactional server160. The transactional server160calculates winnings and losses based on the tournament statistics. The transactional server160sends (744and746) notifications to all players in the completed tournament indicating their tournament has completed, and they have winnings or losses, as well as a leader board for the tournament. The players110ireceiving the completion notification can launch a new game via the notification.

Alternatively, on completion of the game750, the third party game server150sends752games statistics to the third party game130iand sends754tournament statistics to the transactional server160. Each peer-wagering module140ipolls756the transactional server160. The transactional server160sends (758and760) a leader board for the tournament, as well as notifications to all players in the completed tournament indicating their tournament has completed, and indicating whether they have winnings or losses. The players110ireceiving the completion notification can launch a new game via the notification.

The data flow diagram ofFIG. 7corresponds to an asynchronous turn based game; however, appropriate modification can be performed for synchronous based game play.

FIG. 8is a data flow diagram800illustrating the data communication flows between an example implementation of the elements ofFIG. 1for a player110ijoining a game tournament. At802, player110ireceives a notification or in-game message and joins804the tournaments. If the player joins an existing tournament through the lobby system, there will be a standard chat window enabled. The transactional server160will validate (806and808) the funds and inform (810and812) the third party game instance130ithat it is ok for the player110ito join the tournament. At814and816, the player joins the tournament. The transactional server160transfers820wagered funds to an escrow account or places a “hold” on wagered funds in player accounts. During normal game play, all game-related communication occurs between the third party game instance130iand the third party game server150. In some instances during game play, the third party game instance130ior the third party game server150may report826game statistics relevant to fraud detection to the transactional server150.

FIG. 9is a process flow diagram900illustrating a method of detecting fraudulent behavior. At910, data is received characterizing a player's game play. At920, characteristics or attributes of the game play can be monitored and, at930, the monitored characteristics can be compared to historical characteristics associated with the player to detect fraudulent behavior. Deviations in the game play characteristics from the historical characteristics can indicate fraudulent behavior. Fraudulent behavior can include cheating (i.e., not playing by the game rules and thereby gaining an unfair advantage). These statistics may include specific in-game actions such as player orientation within the gaming environment, player actions (e.g. buttons pressed or character movement), or user display details including, but not limited to, graphics card-information, in-game screen shots and live action game-play. Referring again toFIG. 8, on completion of the game, the third party game server150posts824game statistics to the third party game instance130iand posts826game statistics to the transactional server160. The transactional server160calculates828winnings and losses based on the game statistics. Each peer-wagering module140ipolls830the transactional server160for match results and receives832the match results including a list of winnings and losses, as well as a leader board for the tournament. Each peer-wagering module140inotifies834their respective player110ithat the tournament has completed and they have either winnings or losses. The players110ireceiving the completion notification can launch a new game via the notification.

The transactional server160can further be configured to generate a stream of pseudo-random numbers for use by the third party game instances. Since random numbers are typically used in gameplay engines to decide game elements and properties (e.g., what obstacles are present can be decided based on the value that a random number generator returns), the use of common random numbers can provide a common gameplay experience to a subset of users (e.g., the players involved in a third party game tournament). The common gameplay experience can be used to standardize (or level the playing field) for a game of skill that still has random elements.

For example, while Tetris is typically considered a game of skill, the order in which the Tetris pieces present to a player is normally random. By providing a common stream of pseudo-random numbers to each game instance participating in an online tournament, the order that Tetris pieces appear to each player can be common across all participating game instances. Thus, the results of a competitive tournament would be based entirely on skill, and not on a random chance of getting an easier order of Tetris pieces presented.

In one example, the transactional server160can use a tournament identification number as a seed to generate pseudo-random numbers, thus causing gameplay to be different between tournaments, but not between game instances involved in a given tournament.

Various implementations of the subject matter described herein may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The subject matter described herein may be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Although a few variations have been described in detail above, other modifications are possible. For example, the logic flow depicted in the accompanying figures and described herein do not require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.