PROVIDING TOKEN-BASED ACCESS TO APPLICATION FEATURES

Abstract

Systems and methods are provided for implementing token-based access to application features of an application executable by a computing device. In some embodiments, a number of initial electronic credits, or tokens, may be assigned to a user of an application, where a token enables the user to access one or more features of the application. The number of tokens to be assigned to the user may be determined based at least in part on data regarding users that were previously assigned tokens of varying amounts. When a user selection is received corresponding to a request to access certain features of the application, one or more tokens may automatically be subtracted from the number of tokens available to the user. In some embodiments, additional tokens may be purchased or otherwise obtained by the user.

Description

BACKGROUND

Computer application developers and/or distributors typically offer their software applications to consumers for a fee. For example, a software distributor or software developer may allow a user to download a computer game or other application to the user's computing device by purchasing the game for a predetermined fee from an online marketplace. As an alternative, some software developers offer their applications to users as a free download. In some instances, a free version of an application may include limited features relative to a pay version of the same application, and/or the free version of the application may include advertisements that are presented to the user during use of the application.

BRIEF DESCRIPTION OF THE DRAWINGS

Specific embodiments of a system and associated processes for providing token-based access to application features will now be described with reference to the accompanying drawings, wherein:

FIG. 1 is a block diagram depicting an illustrative operating environment in which a computing device may receive an application from an application distribution server, and in which the computing device may receive information regarding tokens to be used in the application from a token management server.

FIG. 2 depicts a general architecture of a computing device for operating a token-based application.

FIG. 3 is an illustrative user interface generated for display by a computing device during user interaction with a game, where the user interface includes an option that may be selected by the user in order to use an electronic token to access game functionality.

FIG. 4 is a flow diagram of an illustrative method implemented by a user computing device or a token management server for controlling access to game play.

FIG. 5 is a flow diagram of an illustrative method implemented by a token management server for determining the number of free tokens to assign to a user.

FIG. 6 is an illustrative user interface generated by a computing device during game play, where the user interface includes score information and token balance information.

FIG. 7 is an illustrative user interface generated by a computing device that provides options to a user for obtaining additional tokens.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Aspects of the present disclosure relate to controlling access to features of software, such as an application operable on a computing device, through the use of electronic credits or tokens that are purchased by, given to, and/or otherwise obtained by a user of the software. According to certain embodiments, a software application may be offered for installation onto a user's computing device for free, and the user may initially receive a given number of electronic credits or tokens for use in the application. Subsequently, each time that the user accesses certain features within the application, the number of tokens available to the user may be decreased. For example, according to some embodiments in which the application is an electronic game playable on a mobile computing device, each time that the user selects to begin a new instance of game play, a certain number of tokens may be debited from the user's balance of tokens. If the user's available token balance is less than the number of tokens required to access the desired software feature, the user may be prevented from accessing the feature until the user obtains additional tokens according to one or more options described further below.

In some embodiments, a token module as disclosed herein may determine a number of initial electronic credits, or tokens, to be assigned to a user of an application, where a token enables the user to access one or more features of the application. The number of tokens to be assigned to the user may be determined based at least in part on data regarding users that were previously assigned tokens of varying amounts. The token module may then store an electronic record associating the determined number of tokens with the user. The token module may later receive a user selection corresponding to a request to access a certain feature of the application, and in response to the selection, automatically modify the electronic record to subtract one or more tokens from the number of tokens available to the user. The application may then provide the user with access to the desired feature, at least temporarily.

As used herein, an “application” may be, for example, software that may be executed by a computing device. While a game that may be executed on a computing device is often used below as an example of an application, it will be appreciated that aspects of the present disclosure may be implemented in, or applicable to, various other types of software. In some embodiments, applications may include stand-alone software packages that are executable within a particular operating system. In other embodiments, applications may include cross-platform and/or browser-based software modules.

As used herein, a “token” may refer to a unit of electronic credit. In some embodiments, the electronic credit may be used or spent by a user within one or more applications in order to access certain functionality, and/or may be used by an individual in other environments unassociated with an application, such as in exchange for real-world goods. In some embodiments, a token may correspond to a hard currency value in a general monetary system (for example, a token may correspond to a U.S. penny, or have a one cent value associated with it). As will be appreciated, the “value” of a token may simply convey the general cost to purchase a token, and does not necessarily require that a user be able to convert an available token into the token's U.S. currency value. In other embodiments, a token may correspond to a “soft” value within a given system that is unattached to any specific governmental currency system. For example, an operator of a token management server and/or a developer of a given application that utilizes tokens may determine the effective worth of a token, which may be defined in terms of what a token enables the user to do (e.g., how many tokens a user must spend in order to access a given application feature) rather than in terms of any cost associated with obtaining a certain number of tokens.

A token module is described herein as, in certain embodiments, grouping or segmenting users into various cohorts. As used herein, a “cohort” generally refers to a group of users with one or more common characteristics or attributes, where the specific type of characteristic(s) or attribute(s) upon which users are grouped may vary in different embodiments. For example, attributes may include demographic information such as age, gender, geographic location, employment status, etc. Attributes of users may additionally or alternatively include information regarding past purchase behavior, types of electronic devices used (such as the manufacturer of a user's mobile computing device), operating systems used, extent and type of social network usage, extent of application and/or game usage, number of token purchases, number of offer completions, etc.

FIG. 1 depicts an illustrative operating environment 100 in which a computing device 102 may receive an application from an application distribution server 104, and in which the computing device 102 may receive information regarding tokens to be made available to a user of the application from a token management server 106. The depicted environment 100 includes a computing device 102, an application distribution server 104, and a token management server 106 communicatively connected by a network 108, such as the Internet. Those skilled in the art will recognize that the computing device 102, token management server 106 and/or application distribution server 104 may collectively be any of a number of computing devices that are capable of communicating over a network including, but not limited to, a laptop, personal computer, tablet computer, electronic book reader, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, smart phone, digital music player, and the like. In some embodiments, one of the computing device 102 and the token management server 106 may implement aspects of the present disclosure without cooperating with another computing device. Similarly, the application distribution server 104 may not be present in the operating environment of certain embodiments.

In the illustrated embodiment, the application distribution server 104 may provide access to a number of software applications, which may be retrieved by the application distribution server from one or more data stores, such as application data store 114. A user of computing device 102 may browse the available applications and request that the application distribution server 104 send a given application to the computing device 102 in order for the application to be installed on the computing device. Once an application has been installed on computing device 102, the computing device 102 may request an available token count associated with the user from token management server 106, and may generally send and receive token information to and from token management server 106 during operation of the application, as will be discussed further below. In other embodiments, the computing device 102 may determine a number of tokens to be made available to a given user and/or manage user tokens without communicating with token management server 106.

In the environment shown in FIG. 1, the computing device 102 may communicate with the application distribution server 104 and/or token management server 106 via a communication network 108, such as the Internet or other communications link. Communications between the computing device 102 and the application distribution server 104 and/or token management server 106 may be secure, such as by encrypting or encoding the data exchanged. In some embodiments, the application distribution server 104 and/or token management server 106 may include computer hardware and software components similar to those described below with respect to the computing device 102.

As illustrated in FIG. 1, the application distribution server 104 includes or communicates with an application data store 114. The application data store 114 may include data associated with a number of software applications that may obtained by a user of a computing device, such as computing device 102, from the application distribution server for installation onto the user's computing device. For example, the application distribution server 104 may provide a retail environment in which users may purchase applications and/or may provide an interface from which at least some applications are freely provided to users. Those skilled in the art will appreciate that the application data store 114 may be local to the application distribution server 104, may be remote to the application distribution server 104, and/or may be a network-based service itself.

As further illustrated, the token management server 106 includes or communicates with a token data store 112. The token data store 112 may include token data associated with a number of users, including token balance information for each user. In some embodiments, the token data store 112 may additionally include user data, such as demographic data or personal information, and/or behavioral information regarding the use of tokens, purchasing activity, and/or information regarding application usage by a user. Those skilled in the art will appreciate that the token data store 112 may be local to the token management server 106, may be remote to the token management server 106, and/or may be a network-based service itself. In other embodiments, the token data store 112 may be local to the computing device 102 or the application distribution server 104.

Those skilled in the art will appreciate that the network 108 may be any wired network, wireless network or combination thereof. In addition, the network 108 may be a personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, etc., or combination thereof. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art of computer communications and, thus, will not be described in more detail herein.

In some embodiments, a token module that implements aspects of the present disclosure may be distributed to software developers in order for a number of different software applications to provide token-based access to application features of the given applications. For example, an operator of the token management server 106 may provide an application programming interface (“API”) or a software development kit (“SDK”) that allows developers of applications (such as applications accessible via the application distribution server 104) to integrate token functionality within their applications.

FIG. 2 depicts a general architecture of a computing device 102 for operating an application that requires tokens, as described herein, to access certain features. The computing device 102 may have one or more processors 202 in communication with a network interface 204, a display interface 206, a computer readable medium drive 208, and an input/output device interface 210, all of which communicate with one another by way of a communication bus. The network interface 204 may provide connectivity to one or more networks or computing systems. The processor(s) 202 may thus receive information and instructions from other computing systems or services via a network. The processor(s) 202 may also communicate to and from memory 220 and further provide output information or receive input information via the display interface 206 and/or the input/output device interface 210. The input/output device interface 210 may accept input from one or more input devices 224, including, but not limited to, keyboards, mice, trackballs, trackpads, joysticks, input tablets, trackpoints, touch screens, remote controls, game controllers, velocity sensors, voltage or current sensors, motion detectors, or any other input device capable of obtaining a position or magnitude value from a user. The input/output interface 210 may also provide output via one or more output devices 222, including, but not limited to, one or more speakers or any of a variety of digital or analog audio capable output ports. The display interface 206 may be associated with any number of visual or tactile interfaces incorporating any of a number of active or passive display technologies, such as electronic-ink, LCD, LED or OLED, CRT, projection, etc.

The memory 220 contains computer program instructions that the processor(s) 202 execute in order to implement one or more embodiments of the present disclosure. The memory 220 generally includes RAM, ROM and/or other persistent or non-transitory computer-readable media. The memory 220 may store an operating system 214 that provides computer program instructions for use by the processor(s) 202 in the general administration and operation of the computing device 102. The memory 220 may further include other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 220 includes a user interface module 212 that facilitates generation of user interfaces (such as by providing instructions therefor) for display. For example, a user interface may be displayed via a navigation interface such as a web browser installed on the computing device, or via an application installed on the computing device, such as an electronic game. In addition, memory 220 may include or communicate with an auxiliary data store 240. Data stored in the data store 240 may include various application data and/or token data similar to that discussed above with respect to token data store 112.

In addition to the user interface module 212, the memory 220 may include a token module 216 that may be executed by the processor(s) 202. In one embodiment, the token module 216 may be used to implement various aspects of the present disclosure, such as determining or requesting the number of tokens to associate with a given user, controlling access to application features, managing tokens, etc., as described further below. In certain embodiments of the present disclosure, the application distribution server 104 and/or token management server 106 may include several components that operate similarly to the components illustrated as part of the computing device 102, including a user interface module, processor, computer readable medium drive, etc. In some embodiments, the token management server 106 may include a module similar to token module 216, and aspects of the present disclosure described herein as implemented by the token module 216 may be implemented by the token management server 106 in communication with the computing device 102.

FIG. 3 is an illustrative user interface 300 generated for display by a computing device, such as computing device 102, during user interaction with a game entitled “Car Racing Game.” User interface 300 may be displayed, for example, when an application (in this case, a game) that implements at least some aspects of a token module, as described herein, is executed by the computing device 102. In the illustrated embodiment, user interface 300 may be presented for display by the computing device 102 the first time that the user selects to launch or open the “Car Racing Game” application after the application has been installed on the user's computing device. In such an embodiment, the token balance 302 (indicated as twenty-five available tokens) may include a number of free tokens that have been determined by the token module 216 of computing device and/or by the token management server 106 in communication with the computing device, as described further below. For example, prior to display of user interface 300, the token module may have requested the user's token balance from token management server 106, and may have received from the token management server an indication of a balance of twenty-five tokens associated with the user based on a user identifier, device identifier, or other identifier associated with the user's account with the token management server 106.

According to some embodiments, a user interface similar to user interface 300 may be presented for display after each instance of game play (which may correspond to a turn, a life, a time-limited instance, or other discrete amount of game play), with the token balance 302 indicating a balance of one less token after each instance of game play. Accordingly, the token balance displayed at a given time may includes tokens that were assigned to the user for free upon installation of the game, tokens that were assigned to the user as a result of offers completed by the user, and/or tokens that were purchased by the user or for the user by another individual. In some embodiments, the token balance 302 may include tokens that were obtained by the user outside of the “Car Racing Game” application, such as tokens that were originally obtained during user interaction with a different application.

As illustrated, user interface 300 includes an option 304 that may be selected by the user to use an electronic token to access game functionality. In the illustrated embodiment, the game functionality that the user may request to access by selection of option 304 is a single instance of game play of the “Car Racing Game” application. In the illustrated embodiment, the user is not provided with any option to initiate an instance of game play other than option 304, which requires use of a token. Accordingly, in order for the user to access an instance of game play (which may be considered “playing” the game), the user must, in some embodiments, agree to allow the token module 216 to subtract an available token from the user's token balance 302 by selecting option 304. As a result of the user's selection of option 304, the computing device may initiate an instance of game play, such as by presenting for display a user interface similar to FIG. 6, discussed below, and subtract a token from the user's token balance 302 (which would result in a balance of twenty-four tokens in the illustrated example).

Illustrative user interface 300 additionally includes an option 306, which the user may select if the user desires to obtain additional tokens to be added to the user's token balance 302. Selection of option 306 may result, for example, in the computing device 102 presenting for display a user interface with selectable options similar to those illustrated in user interface 700, discussed below in reference to FIG. 7. For example, the computing device may present the user with various offers that may be completed by the user in order for the user to receive additional tokens, and/or may present the user with options to purchase additional tokens. If the user does not wish to use a token to access game functionality, the user may select quit option 308 in order to request that the computing device end execution of the “Car Racing Game” application.

FIG. 4 is a flow diagram of an illustrative method 400 implemented by user computing device 102 and/or token management server 106 for controlling access to game play. While illustrative method 400 is described below in terms of controlling access to game play within a game, illustrative method 400 may be implemented in association with applications of various types other than games in order to control access to one or more application features. While illustrative method 400 will be described below as implemented by the computing device 102 based in part on data received from token management server 106, it will be appreciated that, in other embodiments, illustrative method 400 may be implemented in whole or in part by the token management server 106.

Illustrative method 400 begins at block 404, where the computing device 102 determines a number of free tokens to be assigned to the user based on the user and/or the game. In some embodiments, the number of free tokens to assign to the user within a given game or other application may only be determined once for the given user, such as at the time the application is first installed by the user onto computing device 102, or at the time when the application is first opened by the user and executed by the computing device 102. In some embodiments, the number of free tokens to assign to the user may be based in part on cohort analysis regarding token purchase data and/or token usage data associated with other users that share certain user attributes with the given user. Determining the number of free tokens to assign to the user is discussed in more detail below with reference to illustrative method 500 of FIG. 5.

The “free” tokens to be assigned to the user may be tokens that the user is allotted for no monetary cost as a result of downloading the application from application distribution server 104, installing the application onto computing device 102, and/or selecting to open the application for execution by computing device 102. Tokens may, in some embodiments, generally be portable between different applications, such that a token in one application may be considered a cross-application token that may be made available for use by the same user in a second application. In some such embodiments, a “free” token may have limited use relative to tokens obtained in other manners, such as only being usable within the application with which the tokens are first associated, or only being usable within applications associated with a single developer or distributor.

Once the computing device 102 has determined the number of free tokens to assign to the user, the computing device 102 associates the determined number of free tokens with the user at block 406. Associating the determined number of free tokens with the user may include retrieving a previous token balance associated with the user from token data stored in a data store, adding the determined number of free tokens to the previous token balance, and associating the new token balance with the user in the data store. In embodiments in which free tokens have limited utility relative to tokens that are purchased or obtained through offer completions, associating the determined number of free tokens with the user may include storing a new free token balance associated with the user and the given application, which may be stored as a separate balance from one or more other token balances associated with the user (such as the user's purchased token balance and/or the user's free token balance associated with another application).

In some embodiments, token management server 106 may maintain token balance information associated with the user and token balance information associated with a number of other users in token data store 112, and may send the token balance information to computing device 102 in order for the user to access his tokens in the given application. In other embodiments, the computing device 102 may maintain token balance information in a local data store, such as data store 240. In other embodiments, the token management server 106 and computing device 102 may each maintain a token balance associated with the user in separate data stores, and may communicate with each other periodically or in response to certain triggering events in order to synchronize the token balance information between the different data stores. For example, the token management server 106 may update token balance information in token data store 112 in response to an indication from computing device 102 that the user has used five tokens in an application executed by computing device 102. Similarly, the computing device 102 may update token balance information in data store 240 in response to an indication from token management server 106 that the user has used five tokens in another application and/or using a different computing device.

At block 408, the computing device 102 receives a user selection corresponding to a game play request. For example, the selection may be received as a result of the user selecting an option displayed in a user interface generated by the application, such as the “play” option 304 discussed above with reference to illustrative user interface 300 of FIG. 3. The selection received at block 408 may generally correspond to a request by the user to access a feature of the game or other application that requires use of one or more tokens. Once the computing device 102 receives the user selection at block 408, such as a selection indicating a request to begin a new instance of game play, the computing device retrieves the available token count associated with the user at block 410. In some embodiments, the available token count associated with the user may be retrieved directly by the computing device 102, such as from data store 240. In other embodiments, the computing device 102 may send a request to the token management server 106. The token management server 106 may then retrieve the user's available token count from token data store 112 based on a user identifier associated with the user, and may send the retrieved token count to the computing device 102.

Next, at block 412, the computing device 102 determines whether the user has sufficient tokens available to access the application feature requested at block 408. For example, if the user has requested to begin a new instance of game play, and a new instance of game play in the given application requires use of two tokens, the computing device may determine at block 412 whether the user's available token count is greater than or equal to two tokens. If the computing device determines that the user does not have sufficient tokens available, the method proceeds to block 414, where access to the requested game play feature is blocked until the user obtains additional tokens, as described in more detail below. The illustrative method 400 then ends at block 420.

If the computing device instead determines that the user has sufficient tokens available at block 412, the method proceeds to block 416, where the computing device subtracts the required tokens from the user's token count and provides access to the game play instance or other application feature requested by the user. For example, if the user's selection corresponded to a request to initiate an instance of game play at a cost of two tokens, the computing device may initiate an instance of game play (such as by presenting for display a user interface similar to FIG. 6, discussed below) and subtract two tokens from the user's token balance. Once the user's game play instance has ended (which may be defined in different ways depending on the game, but may include the user exceeding a game play time limit, the user losing a certain number of “lives” within the game, etc.) at block 418, the illustrative method 400 may return to block 408, where the user may select to begin a new instance of game play. The illustrative method 400 may end as a result of the user selecting to exit the game or end execution of the application by computing device 102 (not illustrated).

FIG. 5 is a flow diagram of an illustrative method 500 implemented by user computing device 102 and/or token management server 106 for determining the number of free tokens to assign to a user. While illustrative method 500 will be described below as implemented by the computing device 102 based in part on data received from token management server 106, it will be appreciated that, in other embodiments, illustrative method 500 may be implemented in whole or in part by the token management server 106 or by another computing system or component. Illustrative method 500 is an example of a method that may be implemented at block 404 of illustrative method 400, discussed above, in order to determine how many free tokens to assign to a user.

Illustrative method 500 begins at block 502, where the computing device 102 retrieves information associated with the user. The retrieved information may include, for example, one or more attributes associated with the user, such as geographic location, gender, occupation, and/or other demographic or personal data. The information may be retrieved, in some embodiments, from one or more third party data stores or received from one or more third party servers. For example, an application implemented by the computing device 102, such as a game, may present the user with a user interface prompting the user to enter a user identifier that may be used by the computing device 102 and/or token management server 106 to request information regarding the user from a third party server, such as a server operated by a social networking service with which the user maintains an account, the application distribution server 104, a electronic commerce retailer, or other service provider. For example, the user may enter a username and password associated with the user's account with the social networking service or other service, and the computing device 102 may request information regarding the user from a server associated with the social networking service or other service. In other embodiments, the user may have previously set up an account with the application distribution server 104 and/or token management server 106, from which the computing device 102 may access user attribute information associated with the user's account. In some embodiments, the computing device 102 may retrieve personal and/or demographic information regarding the user directly from one or more data stores local to computing device 102, and/or may utilize geolocation functionality of the computing device 102 to determine the current geographic location of the user (which may be considered a user attribute, in certain embodiments).

At block 504, the computing device 102 identifies other users that are similar to the user based on the information regarding the user that was retrieved or received by the computing device 102 at block 502. In some embodiments, identifying other users that are similar to the user may include determining a cohort with which to associate the user. As discussed above, a cohort may generally be a group of users with one or more common characteristics or attributes, where specific cohorts may be defined in various ways in different embodiments. For example, one cohort may be defined as 18-25 year old males, while another cohort may be defined as students at U.S. universities. The computing device may place the user in a cohort, or otherwise identify users that are similar to the user, by comparing one or more attributes of the user with attributes of a number of other users of the token management server 106. In some embodiments, information regarding user attributes associated with other users may be retrieved from a data store, such as token data store 112. In other embodiments, the token management server 106 may provide the token module 216 with cohort definitions in order for the token module to determine a cohort with which to associate the user.

After the computing device 102 has identified other users, or a cohort of users, that are similar to the user, the illustrative method 500 proceeds to block 506, where the computing device analyzes token usage information of the similar users and/or token purchase history of the similar users. In order to analyze token usage and/or purchase history data, the computing device may retrieve from one or more data stores, such as token data store 112, information regarding the number of free tokens that have previously been assigned to the similar users, the number of tokens that have been used by the similar users in one or more applications, the amount of money spent on token purchases, and/or other token data associated with the users. In some embodiments, analyzing the token data may include determining an optimal number of free tokens to assign to a user of a given cohort (or a user that is associated with certain attributes) in order to maximize a given target metric or value. For example, according to some embodiments, the token module 216 may be configured to maximize a conversion rate of users, where a conversion rate may be defined as the percentage of users that eventually purchase tokens at least once after receiving a given number of free tokens. Alternatively, the token module 216 may be configured to maximize a lifetime value of a user, which may be defined as the total amount of money spent by a user in purchasing tokens over an extended period of time.

At block 508, the computing device 102 determines the number of tokens to assign to the user based on the analysis of similar users implemented at block 506. In some instances, the number of tokens to be assigned to the user may be the number of tokens determined above to be optimal for users of the given cohort. According to some embodiments, the computing device 102 may randomly vary the number of free tokens to initially assign to each user of a given cohort in order to test the success of different token amounts until a certain confidence level is achieved in the optimal token amount. In other embodiments, a certain subset of users of a given cohort may be assigned random token amounts within a given range for testing purposes, or all users of a given cohort may be assigned random token amounts until a certain minimum sample size is achieved for the given cohort. Once the number of tokens to assign to the given user has been determined, the illustrative method 500 ends at block 510.

Although FIG. 5 depicts the token usage analysis as being performed for a particular user, this need not be the case. For example, in some embodiments, the usage analysis may instead be performed periodically (e.g., daily, weekly or monthly) for specific groups or segments of the user population, and the results stored for subsequent look up. These results may, for example, associate specific cohort descriptions (e.g., certain attribute values for certain user attributes) with specific numbers of initial tokens, and may be used to determine the number of initial tokens to assign to particular users.

While illustrative method 500 is described above in terms of an embodiment in which information associated with the user, such as user attributes, is considered by the computing device 102 when determining the number of free tokens to assign to a user, in other embodiments, the computing device 102 may not consider information associated with the user when determining the number of free tokens to assign to a user. For example, in some embodiments, the number of free tokens to assign to the user may be based on an analysis by the token management server 106 of token usage data and/or token purchase data associated with users of a given application without regard to cohorts or similarities between users. A token module in such an embodiment may generally be configured to analyze token data in order to determine the number of free tokens that is optimal for a given application, rather than for a given user or group of users. In other embodiments, the number of initial tokens to assign to a given user may be based partly or wholly on past behavior of the particular user. For example, a user who has previously made substantial token purchases and/or application purchases after running out of his initial free tokens in other applications may be awarded more tokens than would otherwise be the case for a user with similar attributes. On the other hand, in some such embodiments, a specific user who rarely purchase tokens may, over time, be awarded fewer tokens upon subsequent installation of token-based applications than would otherwise be the case for other users within the given cohort.

FIG. 6 is an illustrative user interface 600 generated by computing device 102 during game play of a game application executed by the computing device. The game may be, for example, the game entitled “Car Racing Game” previously discussed as an example application above with reference to FIG. 3. Illustrative user interface 600 may be displayed during an instance of game play after the user has selected to use a token to play the game, such as by selecting option 304 of user interface 300 discussed above. Accordingly, the user's token balance 604, indicated as twenty-four tokens, may be a revised balance totaling one less token than the user's previous balance of twenty-five tokens. The token balance may have been updated automatically by the token module 216 in response to the user selecting to begin a new instance of game play. In some embodiments, once the user's game play instance ends, such as by the user completing a given race within the user interface 600 of the “Car Racing Game,” the user may be prompted to play again at a cost of one additional token.

User interface 600 includes a score 602 that reflects the user's current score in the instance of game play, which may be updated as the user plays the game. User interface 600 also includes a high score ranking 606 that indicates where the user's personal high score for the game ranks relative to other users' high scores. In some embodiments, the high score ranking 606 may include scores of other users with whom the user is connected within one or more social networks. For example, the token module 216 may access information identifying a user's social connections or friends from one or more social networking services, such as by communicating with the a server associated with the social networking service and/or through an API provided by the social networking service. The user may have previously indicated to the token management server 106 a number of the user's friends or social connections that the user was interested in competing with for high score(s), which may include “Joe” and “Mark” in the illustrated high score ranking 606. In other embodiments, the high score ranking 606 may include users that are associated with accounts with the token management server 106, whether or not such users are connected on any social networking service. The presence of high score ranking 606 may serve to encourage the user to continue using tokens and/or to purchase additional tokens in order to have additional chances to beat a friend's high score in the game. Additionally, high score ranking 606 includes an option 608 which the user may select in order to invite a social network connection of the user, indicated as “Alex,” to compete with the user for high scores and/or to sign up for an account with the token management server 106.

FIG. 7 is an illustrative user interface 700 generated by a computing device, such as computing device 102, or generated in whole or in part by token management server 106 to be presented for display by computing device 102, that provides options to a user for obtaining additional tokens. User interface 700 may be displayed, for example, when the user's token balance reaches zero (indicated by token balance 702), such that the user can no longer use an available token to begin a new instance of game play (or access some other token-controlled application functionality). In some embodiments, a user interface similar to user interface 700 may be displayed by the computing device 102 in response to certain selections by the user, whether or not the user currently has tokens available.

User interface 700 includes four illustrative options 704, 706, 708 and 710 for the user to select from in order to obtain additional tokens. Options 704 and 706 may be selected by the user in order for the user to be prompted for payment information to purchase 99 tokens or 499 tokens, respectively. For example, selection of option 704 may present the user with a user interface that enables the user to purchase 99 tokens for $0.99, or some other amount, depending on the embodiment. The user may be offered a variety of payment options, such as payment by credit card or by the user's account associated with the application distribution server 104, an online payment processor, an e-commerce retailer, a phone carrier or service provider, or other payment processor. After payment processing, the token management server 106 may add 99 tokens to the account balance associated with the user in token data store 112.

Illustrative user interface 700 also includes option 708, which the user may select in order to earn five free tokens as a reward for inviting a friend to set up an account with the token management server 106. Selection of option 708 may, for example, present the user with options to select an individual from a list of the user's social connections on one or more third-party social networking services and/or enter an email address associated with the friend to be invited. Once the user has indicated a friend to invite, the token management server 106 may add five tokens to the user's token balance and send an invitation to the selected friend by email, text message, message within a social networking service, and/or other communication.

Option 710 of user interface 700 may be selected by the user to view other offers that the user may complete in order to receive tokens without monetary payment. For example, in some embodiments, the user may be presented with options of one or more additional applications that the user may select to install on the computing device 102. The additional application may be, for example, an application that is distributed by an application distributor that has offered to pay the operator of token management server 106 for each user installation of the offered application, or for each user that both installs and actually uses the offered application. In some embodiments, the token management server 106 may add a certain number of tokens associated with the offer to the user's token balance once the user installs the application, while in other embodiments the user may be required to actually use the installed application before receiving the free tokens associated with the offer. In some embodiments, the price that the distributor or developer of the offered application pays to the operator of the token management server 106 for the user's installation of the offered application may vary depending on one or more metrics tracked by the token management server 106, such as the number of times users actually use the offered application after installation, the amount of time users spend in the offered application, the number of tokens that the user spends in the offered application, etc.

It is to be understood that not necessarily all objects or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that certain embodiments may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages as may be taught or suggested herein.

All of the processes described herein may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware or a combination thereof.

Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Conjunctive language such as the phrase “at least one of X, Y and Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be either X, Y or Z. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y and at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

1. A system for providing electronic access to one or more features of a computer game, the system comprising:

a data store that stores data identifying at least one user and a number of tokens available to the at least one user, wherein a token represents an electronic credit that may be used to access game functionality of one or more computer games; and

a computing system in communication with the data store and that is operative to: receive an indication that a user has requested initial access to a computer game, wherein the computer game requires usage of a token in order to access an instance of game play; determine a number of initial tokens to be assigned to the user based at least in part on information associated with the user and token usage data associated with a plurality of users; store a token count associated with the user in the data store, such that the token count includes the determined number of initial tokens; receive an indication that the user has selected to initiate an instance of game play within the computer game; and in response to receiving the indication, automatically subtract a token from the stored token count associated with the user.

2. The system of claim 1, wherein the computing device is further operative to enable the user to electronically purchase a plurality of tokens in order to access an instance of game play.

3. The system of claim 1, wherein the computer game comprises a game playable on a mobile computing device.

4. The system of claim 3, wherein the mobile computing device is a mobile phone.

5. The system of claim 1, wherein the indication that the user has requested initial access to a computer game is received based at least in part on the computer game being installed on a computing device associated with the user.

6. The system of claim 1, wherein the computing device is further operative to present one or more offers to be completed by the user in order to increase the token count associated with the user.

7. The system of claim 1, wherein determining the number of initial tokens to be assigned to the user comprises analyzing token usage data associated with a plurality of users that are each associated with at least one user attribute associated with the user.

8. The system of claim 1, wherein the number of initial tokens to be assigned to the user is determined prior to receiving the indication that the user has requested initial access to the computer game.

9. A system for managing tokens in association with one or more applications, the system comprising:

a data store that stores data identifying a plurality of users and a number of tokens associated with each of the plurality of users, wherein a token represents an electronic credit that may be used to access functionality of one or more applications that are executable by at least one computing device; and

a computing system in communication with the data store and that is operative to: determine one or more user attributes associated with a user of at least one of the one or more applications; identify a cohort of users within the plurality of users with which to associate the user, wherein the cohort is determined based at least in part on one or more user attributes associated with the user; determine a number of tokens to be assigned to the user based at least in part on token data associated with users of the identified cohort; and store information in the data store associating the determined number of tokens with a user identifier associated with the user, such that the tokens are made available for use by the user in one or more applications.

10. The system of claim 9, wherein the token data associated with users of the identified cohort comprises a number of tokens previously assigned to each user of the cohort and token purchase information associated with each user of the cohort.

11. The system of claim 9, wherein determining the number of tokens to be assigned to the user based at least in part on token data associated with users of the identified cohort comprises retrieving from the data store an optimal token amount associated with the identified cohort.

12. The system of claim 9, wherein determining the number of tokens to be assigned to the user comprises determining a number of tokens that is likely to maximize a total dollar amount of subsequent purchases of tokens by the user.

13. The system of claim 12, wherein the number of tokens that is likely to maximize a total dollar amount of subsequent purchases of tokens by the user is determined based at least in part by analyzing a total dollar amount of token purchases by each of one or more users of the cohort of users and a number of tokens initially assigned to each of the one or more users of the cohort.

14. The system of claim 9, wherein determining the number of tokens to be assigned to the user comprises determining a number of tokens that is likely to result in the user subsequently purchasing additional tokens, wherein the likelihood of the user subsequently purchasing additional tokens is determined based on an analysis of previous token purchase data of users of the cohort.

15. The system of claim 9, wherein the one or more applications comprise a game, wherein the functionality of the one or more applications which a token may be used to access comprises initiating an instance of game play.

16. The system of claim 9, wherein the one or more user attributes comprises at least one of age, gender and geographic location.

17. The system of claim 9, wherein the one or more user attributes comprises at least one of a number of past token purchases, a type of electronic device used, and an amount of application usage time.

18. The system of claim 9, wherein the number of tokens to be assigned to the user is determined in response to receiving an indication that the user has installed on a computing device one of the one or more applications in which the tokens are made available for use.

19. A computer-implemented method for providing electronic access to one or more features of an application executable by a computing device, the computer-implemented method comprising:

as implemented by one or more computing devices configured with specific executable instructions: determining a number of initial electronic credits to be assigned to a user, wherein an electronic credit enables a user to access one or more features of the application, wherein the number of electronic credits to be assigned to the user is determined based at least in part on results of a token usage analysis of a plurality of users; storing an electronic record associating the determined number of electronic credits with the user; receiving a user selection corresponding to a request to access one of the one or more features of the application; and in response to receiving the user selection, automatically modifying the electronic record to subtract one or more electronic credits from the number of electronic credits associated with the user.

20. The computer implemented method of claim 19, further comprising blocking access to the one or more features of the application when the number of electronic credits associated with the user is insufficient.

21. The computer-implemented method of claim 19, wherein determining the number of initial electronic credits to be assigned to the user comprises analyzing electronic credit usage data of at least 1,000 users.

22. The computer-implemented method of claim 19, further comprising associating additional electronic credits with the user in response to receiving an indication that the user has completed one or more offers.

23. The computer-implemented method of claim 22, wherein the one or more completed offers comprise the user inviting one or more individuals to request electronic credits.

24. The computer-implemented method of claim 22, wherein the one or more completed offers comprise the user selecting to install a second application onto a computing device of the user.

25. The computer-implemented method of claim 19, further comprising providing functionality within the application for the user to purchase additional electronic credits.

26. The computer-implemented method of claim 19, wherein the number of electronic credits to be assigned to the user is determined based at least in part on previous token purchase data associated with the user.

27. The computer-implemented method of claim 19, wherein determining the number of initial electronic credits to be assigned to the user comprises determining a number of initial electronic credits that is likely to result in the user subsequently purchasing additional electronic credits.

28. The computer-implemented method of claim 27, wherein the likelihood of the user subsequently purchasing additional electronic credits is determined based at least in part on electronic credit purchasing data associated with a plurality of users that were previously assigned electronic credits of varying amounts.

29. A non-transitory computer-readable medium having a computer-executable component for managing tokens in association with one or more applications executable by one or more computing devices, the non-transitory computer-readable medium comprising:

a token assignment component for: storing an electronic record associating a number of tokens with a user identifier identifying a user of an application, wherein a token enables the user to access one or more features of the application, wherein the number of tokens to associate with the user is determined based at least in part on one or more attributes associated with the user; and

a token management component for: receiving an indication that the user has requested to access one of the one or more features of the application, wherein the one of the one or more features is associated with a cost of a given number of tokens; and modifying the stored electronic record to indicate a decreased number of tokens associated with the user identifier based on the cost associated with accessing the one or more features of the application.

30. The non-transitory computer-readable medium of claim 29, wherein the number of tokens to associate with the user is determined based at least in part on a number of tokens purchased by each of a plurality of users with one or more attributes in common with the user.

31. The non-transitory computer-readable medium of claim 29, wherein the token assignment component generates for display one or more user interfaces that provide one or more selectable options for the user to obtain additional tokens.

32. The non-transitory computer-readable medium of claim 31, wherein one of the one or more selectable options comprises an option for the user to purchase additional tokens.

33. The non-transitory computer-readable medium of claim 31, wherein one of the one or more selectable options comprises an option for the user to complete an offer in order to obtain tokens for no monetary cost.

34. Non-transitory computer storage that stores executable instructions that direct a computing system to perform a process that comprises:

analyzing token usage of a plurality of users that fall within a user class, said user class defined in terms of one or more user attributes, wherein a token represents an electronic credit that may be used to access functionality of a computer application; and

based on said token usage, determining a number of initial tokens to assign to at least one additional user falling in said user class.

35. The non-transitory computer storage of claim 34, wherein the number of initial tokens to assign to the at least one additional user is determined based at least in part on a number of tokens initially assigned to one or more of the plurality of users that fall within the user class and token purchase information associated with the one or more of the plurality of users that fall within the user class.