U.S. patent application number 13/405171 was filed with the patent office on 2013-08-29 for providing token-based access to application features.
This patent application is currently assigned to LUNCH MONEY CO.. The applicant listed for this patent is Amos Elliston, Ari Mir. Invention is credited to Amos Elliston, Ari Mir.
Application Number | 20130225266 13/405171 |
Document ID | / |
Family ID | 49003448 |
Filed Date | 2013-08-29 |
United States Patent
Application |
20130225266 |
Kind Code |
A1 |
Mir; Ari ; et al. |
August 29, 2013 |
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.
Inventors: |
Mir; Ari; (San Francisco,
CA) ; Elliston; Amos; (San Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Mir; Ari
Elliston; Amos |
San Francisco
San Francisco |
CA
CA |
US
US |
|
|
Assignee: |
LUNCH MONEY CO.
Santa Monica
CA
|
Family ID: |
49003448 |
Appl. No.: |
13/405171 |
Filed: |
February 24, 2012 |
Current U.S.
Class: |
463/25 |
Current CPC
Class: |
G07F 17/32 20130101;
G07F 17/3244 20130101; A63F 13/79 20140902; A63F 13/95 20140902;
G07F 17/3251 20130101; A63F 13/92 20140902; A63F 2300/609 20130101;
A63F 2300/5586 20130101; A63F 13/75 20140902; A63F 2300/575
20130101; A63F 13/69 20140902 |
Class at
Publication: |
463/25 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
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.
Description
BACKGROUND
[0001] 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
[0002] 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:
[0003] 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.
[0004] FIG. 2 depicts a general architecture of a computing device
for operating a token-based application.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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).
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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).
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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).
[0037] 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.
[0038] 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).
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
* * * * *