U.S. patent application number 13/919776 was filed with the patent office on 2013-12-19 for transfer of virtual objects between applications.
The applicant listed for this patent is Brian Mark Shuster, Gary Stephen Shuster. Invention is credited to Brian Mark Shuster, Gary Stephen Shuster.
Application Number | 20130339228 13/919776 |
Document ID | / |
Family ID | 49756801 |
Filed Date | 2013-12-19 |
United States Patent
Application |
20130339228 |
Kind Code |
A1 |
Shuster; Brian Mark ; et
al. |
December 19, 2013 |
TRANSFER OF VIRTUAL OBJECTS BETWEEN APPLICATIONS
Abstract
The present disclosure provides systems and methods for
incentivizing users of one application to try or use another
application by, for example, enabling users to transfer virtual
objects between applications. These applications may be unrelated.
However, the systems disclosed herein are capable of converting the
virtual objects that are configured to function with one
application so that the virtual objects can be utilized by another
application. In some cases, the conversion of the virtual object
may be dependent on the market rate for a virtual object and/or the
number of users who decide to convert instances of the virtual
object. Further, the systems disclosed herein enable users to
unlock features of applications based on accomplishments in other
applications.
Inventors: |
Shuster; Brian Mark;
(Vancouver, CA) ; Shuster; Gary Stephen; (Fresno,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Shuster; Brian Mark
Shuster; Gary Stephen |
Vancouver
Fresno |
CA |
CA
US |
|
|
Family ID: |
49756801 |
Appl. No.: |
13/919776 |
Filed: |
June 17, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61661317 |
Jun 18, 2012 |
|
|
|
Current U.S.
Class: |
705/40 ;
719/319 |
Current CPC
Class: |
G06Q 30/00 20130101;
G06F 2203/04804 20130101; G09G 5/377 20130101; G07F 17/32 20130101;
G07F 17/3225 20130101; G07F 17/3281 20130101; G06Q 20/102 20130101;
G06F 3/0481 20130101; G06F 3/0484 20130101; G06F 9/541
20130101 |
Class at
Publication: |
705/40 ;
719/319 |
International
Class: |
G06F 9/54 20060101
G06F009/54 |
Claims
1. A method for transferring virtual objects, the method
comprising: by an application host system comprising one or more
processors, the application host system configured to host at least
a first application: capturing a first virtual object, the first
virtual object generated by the first application in response to an
action performed by a user with respect to the first application,
the first application comprising a first persistent online
environment; identifying a second application comprising a second
persistent online environment, the second persistent online
environment of a different type than the first persistent online
environment; identifying a set of conversion rules for converting
the first virtual object to a second virtual object usable with the
second application; converting the first virtual object to the
second virtual object based, at least in part, on the set of
conversion rules; and providing the second virtual object to the
second application.
2. The method of claim 1, wherein the first application comprises a
first portion and a second portion, wherein the application host
system is configured to host at least the first application by
hosting the first portion, and wherein the second portion is hosted
by a user computing device associated with the user.
3. The method of claim 1, wherein the second application is hosted
by a second application host system.
4. The method of claim 3, wherein the second application comprises
a first portion and a second portion, wherein the second
application host system hosts the second application by hosting the
first portion, and wherein the second portion is hosted by a user
computing device associated with the user.
5. The method of claim 1, wherein the set of conversion rules
comprises rules for converting the first virtual object from a form
accessible by the first application to a form accessible by the
second application.
6. The method of claim 1, wherein converting the first virtual
object to the second virtual object comprises: determining a time
period during which a quantity of the first virtual object was
obtained by the user; determining a conversion rate for converting
the quantity of the first virtual object to a quantity of the
second virtual object; and converting the quantity of the first
virtual object to the quantity of the second virtual object based,
at least in part, on the conversion rate, wherein providing the
second virtual object to the second application comprises providing
the quantity of the second virtual object to the second
application.
7. The method of claim 1, wherein converting the first virtual
object to the second virtual object comprises: determining a first
share of a quantity of the first virtual object associated with the
user; determining a number of users associated with shares of the
quantity of the first virtual object associated with the user who
have converted their respective shares of the quantity of the first
virtual object to quantities of the second virtual object;
determining a conversion rate for converting the first share of the
quantity of the first virtual object to a quantity of the second
virtual object based, at least in part, on the number of users; and
converting the first share of the quantity of the first virtual
object to the quantity of the second virtual object based, at least
in part, on the conversion rate, wherein providing the second
virtual object to the second application comprises providing the
quantity of the second virtual object to the second
application.
8. The method of claim 1, wherein providing the second virtual
object to the second application comprises: identifying a first
user account associated with the user at the first application;
determining based, at least in part, on the first user account
whether the user is associated with a second user account at the
second application; and in response to determining that the user is
associated with the second user account, associating the second
virtual object with the second user account at the second
application.
9. The method of claim 8, wherein, in response to determining that
the user is not associated with the second user account, presenting
the user with a user interface for obtaining the second user
account at the second application.
10. The method of claim 1, further comprising disassociating the
first virtual object with a user account associated with the user
at the first application.
11. The method of claim 1, further comprising alerting the user
that the second virtual object was transferred to the second
application and that the first virtual object is no longer
accessible at the first application.
12. The method of claim 1, wherein providing the second virtual
object to the second application comprises: identifying a first
user account associated with the user at the first application;
accessing a hash value associated with the first user account;
including the hash value with the second virtual object; and
providing the second virtual object to the second application
thereby enabling a second application host system configured to
host the second application to determine whether the user is
associated with a second user account based at least partially on
the hash value included with the second virtual object.
13. The method of claim 1, further comprising: determining a
payment rate associated with providing the second virtual object to
the second application; and initiating payment based at least
partially on the payment rate between a first entity associated
with the first application and a second entity associated with the
second application.
14. The method of claim 13, wherein the payment rate is based at
least partially on a conversion rate for converting the quantity of
the first virtual object to a quantity of the second virtual
object.
15. The method of claim 13, wherein the payment rate is based at
least partially on a usage pattern associated with the user's usage
of the first application.
16. The method of claim 13, wherein the payment rate is based at
least partially on the action performed by the user with respect to
the first application to obtain the first virtual object.
17. The method of claim 13, wherein the payment rate is based at
least partially on utilization characteristics associated with the
second application.
18. The method of claim 1, wherein the first virtual object and the
second virtual object comprise virtual characters.
19. The method of claim 1, wherein the first virtual object
comprises a first skill level associated with a first skill
associated with the first application, and wherein the second
virtual object comprises a second skill level associated with a
second skill associated with the second application.
20. The method of claim 19, wherein the first skill associated with
the first application corresponds, at least partially, to the
second skill of the second application.
Description
INCORPORATION BY REFERENCE
[0001] Any and all applications for which a foreign or domestic
priority claim is identified in the Application Data Sheet as filed
with the present application are hereby incorporated by reference
under 37 CFR 1.57. This application claims priority to U.S.
Provisional Application No. 61/661,317 filed on Jun. 18, 2012 and
titled "ENHANCED COMPUTERIZED GAMING APPLICATIONS AND NON-GAMING
APPLICATIONS," the disclosure of which is hereby incorporated by
references in its entirety. Further, this application incorporates
by reference in its entirety U.S. application Ser. No. ______
((Attorney Docket No. IFLOD.003A2), which was filed on the same day
as the present application and is titled "TRANSLATING USER
INTERFACES OF APPLICATIONS."
BACKGROUND
[0002] Consumers have millions of applications available to them
for purchase or use. However, most users have limited monetary
resources as well as time. Thus, most users will only purchase or
use a tiny fraction of the applications available in the
marketplace.
[0003] Convincing users to purchase or to try new applications is a
challenging task. There are a number of factors that contribute to
the challenge of engaging new users with respect to an application.
For example, inertia in the marketplace may impact the willingness
of a user to try alternative applications. As a second example,
time or other resources invested by the user in one application may
reduce the willingness of the user to try an alternative
application. As a third example, a user's status within an
application may reduce the willingness of the user to try an
alternative application.
SUMMARY
[0004] Certain embodiments of the present disclosure relate to
systems and methods for transferring virtual objects. For example,
the system may include an application host system comprising one or
more processors. The application host system may be configured to
host at least a first application. The system may perform a method
that includes capturing a first virtual object, which may be
generated by the first application in response to an action
performed by a user with respect to the first application. Further,
the first application may comprise a first persistent online
environment. The method may further include identifying a second
application comprising a second persistent online environment. The
second persistent online environment may be of a different type
than the first persistent online environment. In addition, the
method may include identifying a set of conversion rules for
converting the first virtual object to a second virtual object
usable with the second application. The method may also include
converting the first virtual object to the second virtual object
based, at least in part, on the set of conversion rules. The second
virtual object may be provided to the second application for use by
the user, or a second user, with the second application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Throughout the drawings, reference numbers are re-used to
indicate correspondence between referenced elements. The drawings
are provided to illustrate embodiments of the inventive subject
matter described herein and not to limit the scope thereof.
[0006] FIG. 1 illustrates an embodiment of transferring virtual
objects between applications.
[0007] FIG. 2 illustrates an embodiment of transferring virtual
objects between applications with a variable conversion rate.
[0008] FIG. 3 illustrates an embodiment of unlocking skills/options
in an application based on skills achieved in another
application.
[0009] FIG. 4 illustrates an embodiment of a network environment
for accessing applications and transferring virtual objects between
the applications.
[0010] FIG. 5 presents a flowchart for an embodiment of a virtual
object transfer process.
[0011] FIG. 6 presents a flowchart for an embodiment of a market
rate virtual object conversion process.
[0012] FIG. 7 presents a flowchart for an embodiment of a shared
virtual object conversion process.
[0013] FIG. 8 presents a flowchart for an embodiment of a process
for provisioning to a second application a converted virtual object
converted from a virtual object of a first application.
[0014] FIG. 9 presents a dataflow for an embodiment of a process
for provisioning a converted virtual object to a second
application.
[0015] FIG. 10 presents a flowchart for an embodiment of a virtual
object transfer payment process.
DETAILED DESCRIPTION
Introduction
[0016] Convincing a user to try new software programs, such as
those that are usable on mobile devices (or other computing
devices) and are referred to herein as "applications" or "apps,"
can be challenging. If the user has already committed significant
time and resources to a particular application, the user may be
less willing to try a new application. In particular, the user may
be unwilling to try a new application that is similar to an
application the user already utilizes. Further, the user may be
unwilling to try the new application even if it is unrelated to
applications the user already utilizes if the new application would
service a similar purpose for the user. For example, suppose the
new application is a racing game. In some cases, even if the user
would be interested in a racing game and does not own any racing
games, the user may be unwilling to try or purchase the racing game
because the games the user currently owns serve the same purpose of
entertaining the user despite being a different type of
application.
[0017] Transferring Virtual Objects
[0018] Systems and methods disclosed herein promote trying,
purchasing, acquiring or otherwise utilizing applications by, among
other things, enabling a user to transfer virtual objects (which
may also be referred to as objects or items herein), virtual
achievements, virtual skills and other characteristics or
attributes the user obtained or otherwise has access to in one
application to another application. Advantageously, in certain
embodiments, by enabling the user to transfer virtual objects
between applications, the user is incentivized to try a new
application. Further, in certain embodiments, a user who has tired
of an application may be incentivized to try a new application by
being enabled to utilize, in the new application, certain of the
virtual objects or attributes from the original application.
[0019] For example, FIG. 1 illustrates an embodiment of
transferring virtual objects (e.g., seeds in a Farm Game) between
applications that may incentivize some users to try additional
applications. As seen in the display 102, a user may have earned
100 seeds playing Farm Game. The Farm Game, as also illustrated in
display 102, may identify other applications (e.g., games,
simulators, etc.) to which the seeds can be transferred. In one
embodiment, these other applications will either be developed by
the same entity as the entity that developed the Farm Game, or will
be developed by an entity that has established an agreement with
the entity that developed the Farm Game to allow the transfer of
supported virtual objects. However, in some embodiments, there may
be no relationship between the entity that developed the Farm Game
and an entity that developed the other applications, such as the
entity that developed World Domination Game.
[0020] For instance, in some cases, the entity that developed World
Domination Game may make public, for free or for a price, an
Application Programming Interface (API) for the World Domination
Game enabling other application developers to create applications
that can interface with the World Domination Game. Thus, in such
cases, the developer of the Farm Game may be capable of
transferring objects to the World Domination Game without having an
agreement with the entity that developed World Domination Game by,
for example, downloading an API made publicly available by the
entity that developed World Domination Game. In some embodiments,
the transfer of objects is done through a third-party intermediary
(e.g., the virtual object (VO) transfer system 420 discussed below
with reference to FIG. 4) that interfaces with both the application
that is transferring the virtual objects and the application that
will receive the virtual objects. In such embodiments, applications
that wish to transfer and/or receive virtual objects may do so via
a connection with the third-party intermediary, without requiring a
direct connection (e.g., via an API) to multiple other
applications.
[0021] In some embodiments, an application may allow virtual
objects to be traded among users of the same application. However,
the application may prevent virtual objects from being traded or
converted for use with another application. In such cases, a user
of one application who wishes to trade virtual objects with a user
of another application may use a third party system (e.g., a
virtual object (VO) transfer system) to facilitate the trade as
described below.
[0022] In one implementation, assume both users who wish to trade
virtual objects have accounts with both applications. A third party
may be granted temporarily one or more of the passwords or other
credentials associated with a user account for each user for each
application. In one aspect, those credentials may be fully held by
the third party and not known to the end users. In another aspect,
access to the credentials may be shared between the third party and
one or more end users, or the credentials may be made known to the
end user, but when the end user indicates he or she has completed
use of such credentials for the time, the third party changes the
credentials such as by changing the password.
[0023] In one aspect, the third party may act as an escrow agent
for virtual or other transactions. In one example, Adam and Beth
desire to engage in a trade of 100 farm game seeds for 100 world
domination game seeds. In the example, one or both of the operators
of world domination game and farm game do not have an agreement or
mechanism by which users may transfer seeds between games. Adam and
Beth may both provide a virtual object transfer system with their
respective game credentials (in one aspect, such credentials may
provide access to a limited set of attributes, but preferably
including access to the ability to use or exchange virtual
objects). The virtual object transfer system may then optionally
change the access credentials so that neither user can access their
accounts and transfer or otherwise encumber the seeds. Once the
credentials have been changed (if such a step is taken), the VO
transfer system may optionally check to make sure that the elements
marked for transfer in fact exist, are unencumbered, and/or may be
transferred. The VO transfer system then may transfer the items
between Adam and Beth. This may require access to an account
corresponding to both Adam and Beth in both games. In one
implementation, 100 farm game seeds are moved from Adam's farm game
account to Beth's farm game account, and 100 world domination game
seeds are moved from Beth's world domination game account to Adam's
world domination game account. In one implementation, the transfer
may be an exchange of items for cash or credit, virtual or
otherwise. In one implementation, the credentials to the accounts
are restored to the original credentials after the transaction.
Alternatively, new credentials may be generated for each user after
the transfer is complete. These new credentials may then be
provided to the respective account owners.
[0024] In one implementation, a database may be maintained that
includes terms of service for various games or other applications.
These terms of service may include rules outlining the permitted
and/or prohibited transfer activities for virtual objects
associated with the applications. Alternatively, or in addition,
the terms of service for various games or other applications may be
accessed, whether at or about the time of the transaction or
otherwise, and may be parsed for language regarding permitted
and/or prohibited transfer activities. The parsing of the terms of
service may may be automated utilizing a computing device. In cases
where the terms of service do not permit the transfer of virtual
objects, the system may be configured to prevent a virtual object
transfer between applications and/or user accounts. In some cases,
the VO transfer system may suggest an alternative transfer
arrangement that does not violate the terms of service for the
applications involved in the virtual object transfer.
Alternatively, or in addition, the VO transfer system may alert a
user or users (e.g., an administrator or one or more users
attempting to complete the transaction) of the attempted virtual
object transfer thereby enabling the user or users to modify,
refuse, condition, delay, or evaluate the proposed transaction
based on the terms of service. In one implementation, statutory or
other legal requirements may be incorporated into such a system.
For example, if a state prohibited terms of services from
restricting the transfer of virtual goods, transactions by users
within such a state may be permitted. Similarly, if a state
prohibited the transfer of particular types of virtual goods (e.g.,
currency alternatives), transactions between users in such a state
may be blocked, even if permitted elsewhere.
[0025] Further, such an escrow system may be utilized within a
single system, such as the exchange of differing virtual goods
within a single virtual environment. Advantageously, in certain
embodiments, the VO transfer system enables virtual object
transfers between applications and/or users without involving one
or more entities (e.g., developers, publishers, or parties that
maintain application servers) associated with the applications.
[0026] If the user has decided to transfer the seeds to another
application, such as the World Domination Game, the user may be
taken to a network resource from which the user can download the
selected game as illustrated with the display 104. For instance, if
the user's device is an ANDROID.TM. based device, the user may be
directed to the GOOGLE PLAY.TM. store to download the World
Domination Game. When the user accesses the World Domination Game,
as illustrated in display 106, the user may be informed that the
seeds have been transferred from the Farm Game. In some cases, the
user may already have the World Domination Game. In such cases,
when the user selects the World Domination Game to receive the
seeds, the process of downloading the game as shown with display
104 may be optional. In one implementation, the virtual objects may
be converted into a redeemable code.
[0027] In some cases, virtual objects may be transferred between
applications at a one-to-one rate. Thus, in the example of FIG. 1,
100 seeds in the Farm Game may be converted to, or transferred as,
100 seeds in the World Domination Game.
[0028] However, in other cases, virtual objects may have a varying
conversion rate. This conversion rate may be based on time, such as
the time period during which the virtual object was obtained, the
time period during which the user decided to transfer the virtual
object, the amount of time during which the user has owned or
possessed the virtual object, etc. Alternatively, or in addition,
the conversion rate may be based on the difficulty of obtaining the
virtual objects in the application in which the virtual objects
were obtained compared to the difficulty of obtaining the virtual
objects in the application to which the virtual objects are to be
transferred. Further, in some cases, the conversion rate may be
based on the number of users who transfer the virtual object to the
new application.
[0029] FIG. 2 illustrates an embodiment of transferring virtual
objects between applications with a variable conversion rate. As
seen in display 202, the user received 95 seeds in the World
Domination Game when transferring 100 seeds from the Farm Game. The
user can request more information indicating why the 100 seeds of
the Farm Game were valued at 95 seeds in the World Domination Game
as illustrated in display 204, which indicates a change in the
market for the seeds in the World Domination Game.
[0030] It is not uncommon for games and applications to contain
exploitable bugs or backdoors that can be hacked, or otherwise
manipulated in a manner that may negatively impact users of the
application or of a virtual object transfer system. For example, if
a user created a software agent that engaged in screen scraping,
read the status of a user's farm in the farm game, and sent control
inputs to the farm game causing the user's account to earn seeds at
a faster rate than intended by the application developers, the
number of seeds may increase significantly and may cause the seeds
to drop in value based, for example, on the rules of supply and
demand. In some cases, although a similar exploit may not be
possible within a world domination game, the ability to transfer
improperly obtained seeds from the farm game may negatively impact
the world domination game.
[0031] One response to a discovery that an exploit has impacted an
application or its economy is to enable the application to roll
back certain transactions, such as seeds earned by a robot program
in the farm game. However, items that have already been transferred
to another game may not be rolled back as easily. In one aspect of
the disclosure, the items involved in a transaction may be marked
with information that can be used to track transferred items that
were improperly obtained and to dispose of the items or
retroactively reduce, increase, or otherwise change the conversion
rate for the items. For example virtual objects may be marked with
a timestamp, a source (e.g., the application that originally
generated the item or the one or more applications that transferred
the item), exchange rates at the time of transfer, and any other
information that can be used to track the history of an item. Such
"marking" may be embedded within the code for an item, may be
associated with a database entry for such item, may be
cryptographically recorded, or may otherwise be memorialized.
Alternatively, or in addition to retroactively changing the
conversion rate, the ability to use the converted items, in
response to determining that the items may have been obtained due
to an exploit, may be slowed or delayed. For example, a user may be
restricted to using 10% of the converted items a week to reduce the
probability that a market for the items is flooded.
[0032] In one aspect, items obtained by use of the marked items may
themselves be marked. For example, trees and proceeds of sale of
fruit from trees may be marked as deriving from seeds that were
obtained in a particular transfer transaction.
[0033] In one aspect, liability may be established between the
parties to a transaction wherein a variance of greater than N %
within Y time period in the exchange rate of the objects will
trigger an obligation to engage in a transaction (or may
automatically trigger a transaction) wherein the value of the
transfer to each party is altered, for example by transferring
additional seeds from the Farm Game player to the World Domination
Game player to make up for the change in the exchange rate. There
may be multiple N and Y pairs for each transaction. In one
implementation, the time period Y is set far enough in the future
that if the transaction was engaged in with proceeds of an exploit
that had not, at the time of the transaction, been known to both
parties and/or the game operator, the exploit would, with a minimum
probability, by time Y, be known to both parties and/or the game
operator.
[0034] In one aspect, the size of the transaction may determine, in
whole or part, the values of X and/or Y, and/or whether a rollback
of part or all of a transaction may be possible.
[0035] When a quantity of a virtual object has been identified as
being obtained via an exploit, the application that included the
exploit may identify applications that have received the virtual
objects associated with the exploit. The applications that received
the virtual objects can then remove them from the application, or
may reduce the conversion rate to normalize the market, or bring
the market closer to where it would be if the exploit had not
existed. Further, in some cases, users who were not involved in
transactions that involved virtual objects associated with the
exploit may have been advantaged or disadvantaged by the exploit
due, for example, to changes in market conditions. In such cases,
the conversion rates for the users who were impacted may have their
quantity of virtual objects modified. In some cases, it may be too
late to retroactively correct the market. In such cases, conversion
rates for future conversions of virtual objects may be adjusted to
help correct the market. Alternatively, or in addition, the effects
of the used virtual objects may be negated. For example, if a user
obtained 100 seeds when the user should only have received 75
seeds, but the user has already planted all 100 seeds, the trees
grown from 25 the seeds may be killed off or removed from the
game.
[0036] In some instances, rather than alter the conversion rate,
the quality of the converted items may be altered. For example, if
seeds normally grow 80% of the time, rather than retroactively
alter the conversion rate, seeds involved in a transaction may have
their growth success rate altered, such as by altering the growth
rate to 60% of the time, become more susceptible to pests or
drought, or otherwise have their qualities altered.
[0037] Alternatively, or in addition, antagonist items may be
introduced as a method of altering the effective value or exchange
rate. For example, if PatentBerry plants are moved from one
environment to another, and it is later determined that the
exchange rate was incorrectly twice what it should have been, the
qualities of the PatentBerry plants could be changed, but in
addition or in the alternative, a new antagonist, such as the
PriorArtLocust may be introduced. In such a case, the efficacy of
the antagonist and the resistance of the PatentBerry plants can be
calibrated to deliver a desired effective alteration to the
exchange rate. In some cases, a defense against the antagonist,
such as the PriorArtDebunker Pesticide, may be sold or otherwise
provided to the user. In one aspect, sale of such a pesticide may
be used to increase the effective cost of the PatentBerry plants,
thereby correcting the putative exchange rate. The creation,
provision, and/or sale of antagonists and anti-antagonist objects
may additionally, or alternatively, be used to enhance game play,
increase game revenues, alter the in-game economic conditions,
impact the cost and/or exchange rate and/or availability of virtual
goods, or for other purposes. For example, within a single
environment, Farm Game, an overabundance of apple seeds, whether
due to hacking, a logic flow, or other reasons, may be undesirable.
Accordingly, a worm that attacks apples may be introduced and,
optionally, a dragonfly that eats such worms. The available amount
of apple seeds may thus be reduced, while providing players with a
strong affinity for apples with a mechanism to maintain their apple
trees. Such mechanisms for control of supply of virtual objects is
advantageous, among other reasons, because it can be done within
the confines of the rules of a game, thereby eliminating the
appearance or perception that the game operator is manipulating the
game and/or the appearance or perception that the game is not real.
Such interventions may be made in a manner analogous to events
deemed by contract or law to be "acts of God" when they occur in
the physical world, thereby fitting into the narrative of the
virtual environment in a manner that appears consonant with how
people understand the real world to work.
[0038] In some cases, transferring virtual objects between
applications may also include transferring virtual objects among
users. However, in some such cases, one of the users may not have
an account with one of the applications. In some such cases, the
virtual object to be granted to the user without the account may be
converted to a code, or associated with a code. The user can then
be provided with the code. Once the user creates an account with
the application, the user can use the code to redeem the virtual
object that was exchanged.
Transferring Skills
[0039] Certain embodiments disclosed herein enable a user to unlock
skills, capabilities, or areas (e.g., maps, worlds, etc.) within an
application based on the users skill in another application.
Advantageously, in certain embodiments, by enabling the user to
unlock portions of an application based on the user's actions in
another application, the user is incentivized to try a new
application. For instance, a user may find trying a new application
unappealing if it is necessary to spend time proving that the user
has skills that were obtained in other applications and/or
acquiring skills to unlock portions of the game that may be more
appealing to the user. If the user already has the necessary skills
for a particular application, it may be beneficial for that user to
skip to the portions of the game that require a skill level
corresponding to the user's skill level and, thus, are more
appealing to the user. However, in some cases, allowing a user to
skip easier portions of a game may result in the user quickly
losing interest in the game if the harder portions of the game are
too difficult for the user. Further, in a multiplayer game, such as
a Massively Multiplayer Online Role Playing Game (MMORPG), allowing
an unskilled player into regions of the game designed for skilled
players may not only degrade or ruin the experience for the
unskilled player, but may also degrade the experience for the
skilled players who may be forced to play alongside the unskilled
player.
[0040] Thus, in some cases, it is advantageous to unlock later
portions of a game only if the user has demonstrated a likelihood
of not finding the later portion of the game excessively
challenging. Determining whether the user is skilled enough to
unlock later more challenging portions of a game may be
accomplished by examining the user's accomplishments in a related
game.
[0041] FIG. 3 illustrates an embodiment of unlocking skills/options
in an application based on skills achieved in another application.
For instance, if a user has demonstrated riding skills rated as 80
out of a possible 100 in a Horse Racing application, as illustrated
with display 302, the user may be able to unlock capabilities,
levels, or portions of other applications. As shown in display 304,
the user may be able to select different skills or features to
unlock from a set of applications based on the skills achieved in
the Horse Racing game. For instance, the user may unlock levels in
a Race Car Game or courses in a Boat Racing game. Alternatively,
the user may unlock vehicle capabilities in a Fantasy Vehicle Game.
Advantageously, in certain embodiments, by having the option to
unlock skills or portions of another game, the user of the Horse
Racing game may be incentivized to try other games. As illustrated
with the example in FIG. 3, typically the skills of one game used
to unlock features of another game are for related games and/or
related skills or features. Thus, although a Horse Racing game may
differ from a Race Car game, both relate to racing and therefore
the skills may be considered corresponding to some degree. However,
in some embodiments, the skills used to unlock features of another
game may be unrelated. For instance, racing skills may be used to
unlock units in fantasy tactics game. Advantageously, in certain
embodiments, by having skills unlock features of unrelated games or
unlock unrelated features, a user may be incentivized to try a new
type of game.
[0042] In one implementation, an abbreviated or other type of
training or testing may be utilized as an optional or mandatory
step before granting a transfer of some or all capabilities. For
example, if a person is excellent at driving in the Race Car Game
(e.g., has achieved 95 out of 100 skill rating or has unlocked all
race tracks or race cars, etc.), that same player may easily have
the same skills in the Horse Racing Game. However, the user may
still need some amount of time to become acclimated to the controls
of the Horse Racing Game. This amount of time may be less than
someone who had not played either game before. In one
implementation, the transfer of capabilities may be conditioned on
the user passing the training levels with a certain skill score, or
completing special mini-levels for accessing skill level, etc.
Advantageously, in certain embodiments, by testing skill level in
the second application, the probability that the user's ability to
play one game will not transfer to the second game, or that the
user will negatively impact the experience of other skilled users
may be reduced.
Generating Value
[0043] In some embodiments, the present disclosure describes
systems and methods that provide for digital games and applications
to create cross-dependencies and/or inter-application relationships
and/or inter-game relationships, which may serve to expose users of
at least one game or application to at least one additional game or
application. One embodiment provides a system and method for users
to generate value from their use of or play of the game or
application. In one variant, the value generated in a source
application, or an origin application, may be transferred to,
loaned to, and/or duplicated to a destination, or target
application, and such transfers may optionally be reciprocal. In
one implementation, there is a computerized calculation of the
relative values of the elements transferred between programs, and
cash, virtual currency, game elements, and/or other things of value
may be transferred between the operators of the gaming or
application systems and/or between individuals or characters within
the games or applications. It should be noted that while the
examples focus on a pair of applications or games, the disclosure
is not limited as such. Input items and/or output items, and/or
user interface items and/or other items or elements may be
exchanged between more than two games and/or applications.
Similarly, input items and/or output items, and/or user interface
items and/or other items or elements from a single game and/or
application may be sold (or the license or other rights sublicensed
or loaned).
[0044] To simplify discussion, many of the examples described
herein are in the context of game applications. However, the
present disclosure is not limited as such. One skilled in the art
will recognize that many of the systems and methods disclosed
herein may be applied to any type of application, such as for
social networking applications or dating applications.
Advantageously, in some cases, the present disclosure provides for
the creation of an inter-dependent ecosystem that facilitates play
in at least one game or application through the play of at least
one other game or application.
[0045] Although the examples illustrated in FIGS. 1-3 show mobile
devices, this disclosure is not limited as such. The embodiments
described herein may be applicable to any wired or wireless
computing device including, for example, desktops, laptops,
servers, cloud computing devices, cloud display devices, tablets,
wearable computing devices, gaming systems, set-top or other
television boxes, gaming consoles, and the like. Further,
embodiments disclosed herein may apply to applications that execute
on local devices (e.g., client devices or personal devices),
network based devices (e.g., servers or cloud computing systems),
or a combination of the two (e.g., client/server systems or
networks).
Example Network Environment
[0046] FIG. 4 illustrates an embodiment of a network environment
400 for accessing applications and transferring virtual objects
between the applications. The network environment 400 may include a
user computing device 402, an application host system 404A and "an
application host system 404B (which may be referred to herein
singularly as an application host system 404" or in the plural as
"the application host systems 404"), and a virtual object (VO)
transfer system 420. The user computing device 402, the application
host systems 404, and the VO transfer system 420 can each include
any type of computing device including, for example, desktop
computers, laptop computers, servers, tablets, personal digital
assistants (PDAs), mobile phones (including smart phones),
electronic book readers, other wireless devices, set-top or other
television boxes, media players, game platforms or consoles,
wearable computing devices (e.g., virtual reality helmets or
glasses and other eyewear with computing devices, such as GOOGLE
GLASS.RTM.), and kiosks, among others. Further, each computing
system or device of the network environment 400 may communicate
directly or via a network 430. The network 430 can include any type
of network including, for example, a local area network, a wide
area network, a wired network, a wireless network, an ad hoc
network, a cellular network, combinations of the same, and the
like. In some embodiments, the network can include the
Internet.
[0047] Using the user computing device 402, a user may use one or
more applications, such as local application 406L and local
application 416L. The one or more applications may execute entirely
on the user computing device 402 or, as in the case of the local
applications 406L, 416L, a portion of the application may execute
on the user computing device 402 and a portion of the application
may execute on one or more of the application host systems 404
(e.g., the application 406A and the application 416B). Further, in
some cases, the entire application may execute on one or more of
the application host systems 404.
[0048] The one or more applications can include any type of
application. For example, the applications may be single player
games, multiplayer games, social networking applications,
educational applications (e.g., language learning applications or
educational games), etc. In some cases, the applications may
include persistent worlds, or online environments, that may be
accessed via a network. For example, the applications may include
MMORPGs.
[0049] In some cases, the applications may include characters or
avatars that may represent a user, or which the user may utilize
when executing the application. Further, the applications may
include virtual objects that can be used in the applications. These
virtual objects can include any type of application item usable in
an application and may, although not necessarily, be application
dependent. For example, the virtual object may include types of
weapons, food, armor, spells, virtual currency representations
(e.g., credits, gems, coins, etc.), vehicles, animals, monsters,
companions, etc. Although in some cases, the virtual object may
include monetary representations, in other cases, monetary
representations may be excluded from virtual objects. In some
cases, the virtual objects may include skills, levels, courses,
region maps, or other application features that may traditionally
not be considered an object or item in a game.
[0050] It should be noted that one or more of players and/or
objects and/or avatars that are undergoing an accelerated or
altered progression through levels, that have skipped levels, that
have been imported from or imported skills or other attributes from
other environments may be displayed to one or more other players
within the environment constantly, or from time to time, or for a
fixed time, in a manner that differentiates them from other players
and/or objects. For instance, an avatar of a user who recently
created an account with an application, but which was granted a
level 10 experience level because of accomplishments in another
level may be illustrated with an orange glow to identify the avatar
as being associated with a user who obtained his or here level rank
due to skill transfer.
[0051] During use of an application, a user may cause a virtual
object to be generated, a skill to be unlocked, or a skill level to
increase in response to one or more actions performed with respect
to the application. Although embodiments of the present disclosure
may be used with skills and skill levels as previously discussed
with respect to FIG. 3, to simplify discussion, and not to limit
the applicability of the present disclosure, embodiments herein
will primarily be described with respect to virtual objects.
[0052] The virtual objects may be captured by one or more VO
capture systems 408 (which may be referred herein singularly as "a
VO capture system 408" or by a particular reference number, or in
the plural as "the VO capture system 408"). In some cases, the
virtual object is captured by a VO capture system 408L located on
the user computing device 402. In other cases, the virtual object
is captured by a VO capture system 408A or 408B located on the
application host system 404A or 404B, respectively based on the
application used by the user (e.g., the application 406A or the
application 406B).
[0053] Capturing a virtual object may include accessing software
code associated with the virtual object. Alternatively, or in
addition, capturing a virtual object may include determining that
the user has obtained the virtual object in the application.
Further, the VO capture system 408 may capture the virtual object
in response to the user obtaining the virtual object in the
application. Alternatively, the VO capture system 408 may capture
the virtual object in response to an operation, such as a quit
application operation, or in response to a request by the user. In
yet other cases, the VO capture system 408 may check periodically
or at specific time periods for virtual objects that can be
captured. In certain embodiments, the VO capture system 408 may
capture objects capable of being transferred to another
application.
[0054] In some embodiments, capturing a virtual object may include
sending the virtual object to a VO interface 422 at the VO transfer
system 420. For instance, in embodiments where the VO transfer
system 420 performs a transfer of virtual objects between the
application 406A and the application 406B, the VO interface 422 may
be informed of the user obtaining the virtual object or provided
the virtual object.
[0055] Once the virtual object has been captured, or identified as
in the user's possession within the application, the VO convertor
410 can convert the virtual object for use with another application
identified by the user. The VO convertor 410 used to convert the
virtual object can include the VO convertor 410L, 410A and/or 410B.
For example, if the virtual object is captured at the application
host system 404A by the VO capture system 408A, the VO convertor
410A may perform the conversion of the virtual object (and, thus,
in some embodiments the user computing device 402 does not include
the VO convertor 410L). Likewise, if the virtual object is captured
at the user computing device 402 by the VO capture system 408L, the
VO convertor 410L may perform the conversion of the virtual
object.
[0056] Alternatively, the conversion of the virtual object may be
performed by a VO convertor 410 at a different system than the VO
capture system 408. For example, the VO capture system 408A may
provide the virtual object to the VO convertor 410B for converting
a virtual object obtained with respect to the application 408A for
use with the application 408B. In yet other embodiments, the
virtual object may be provided via, for example, the VO interface
422 to the VO convertor 410TS along with the identity of the
application from which the virtual object originates (e.g., the
application 406A), which may be referred to as a source
application, and the identity of the application for which the
virtual object is to be converted (e.g., the application 416B),
which may be referred to as a destination application. The VO
convertor 410TS may then convert the virtual object for use with
the identified application (e.g., the application 416B).
[0057] Converting the virtual object obtained from one application
for use with another application may include converting code
associated with the virtual object so that the code can be used
with the destination application. Further, converting the virtual
object may include associating the virtual object with an account
of the user at the destination application and/or disassociating
the virtual object with an account of the user at the source
application.
[0058] In some embodiments, as is described in more detail below
with respect to FIG. 6, converting the virtual object may include
converting a quantity of a virtual object (e.g., 100 seeds) for use
with the source application to a quantity of a virtual object for
user with the destination application at a conversion rate that is
based on a time period when the virtual object was obtained, when
the virtual object was converted, or a combination of the two.
Further, in some embodiments, as is described in more detail below
with respect to FIG. 7, converting the virtual object may include
converting the virtual object at a rate that is based on a number
of other users who have converted a fractional share of a quantity
of the virtual object from a set quantity of the virtual
object.
[0059] To facilitate converting a virtual object, the VO convertors
410 may access one or more repositories 412 to obtain information
relating to, for example, the virtual object, the source
application, the destination application, the user, an account at
the source and/or destination application associated with the user,
conversion rates, and any other information that may be used to
help convert or transfer a virtual object. Further, in some cases,
the repositories 412 may include information for facilitating the
destination application (or an associated entity) compensating the
source application (or an associated entity) for the transfer of
the virtual object and/or the creation of an account at the
destination application associated with the virtual object.
[0060] As with the VO convertors 410, each of the application host
systems 404, the user computing device 402, and the VO transfer
system 420 may include a repository 412. Thus, the application host
system 404A may include the repository 412A, the application host
system 404B may include the repository 412B, the user computing
device 402 may include the repository 412L, and the VO transfer
system 420 may include the repository 412TS. In some embodiments,
one or more of the repositories 412 may be hosted by a separate
system or distributed across a number of systems.
[0061] In some embodiments, a plurality of VO convertors 410 and/or
a plurality of repositories 412 may be used to convert a virtual
object from the source application for use with the destination
application. For example, the VO convertor 410A may access account
information associated with a user from the repository 412A.
Further, the VO convertor 410A may convert the type of virtual
object from a type used in application 406A (e.g., a quantity of
throwing stars) to a type used in application 416B (e.g.,
grenades). The converted quantity of virtual object and a checksum
of the account information may then be provided to the application
host system 404B. The VO convertor 410B may then access the
repository 412B to determine whether an account exists for the user
based on the received checksum. Further, the VO convertor 410B may
further convert the grenades to an appropriate quantity based on
the availability of grenades at the present time in the persistent
online environment that is part of the application 416B. Thus, if
there are many grenades available, the conversion rate may be low
and the user may receive fewer grenades for the converted throwing
stars than if the number of grenades in the game environment is
relatively low.
[0062] In some embodiments, one or more of the application host
systems 404, the user computing device 402, and the VO transfer
system 420 may include a VO market interface 414. The VO market
interfaces 414 may be used to determine a current rate based on,
for example, market conditions for converting a virtual object from
one type associated with a first application to a virtual object of
another type associated with a second application. In some cases,
the market rate may be based on the number of users who own a
fractional share of a quantity of a virtual object who have
converted their fractional shares. Further, in some embodiments,
the VO market interface 414 may determine the applications for
which the user is capable of converting a virtual object.
[0063] As previously mentioned, in some cases, an entity associated
with the destination system may compensate an entity associated
with the source system for the conversion of the virtual object.
This compensation may be performed by one or more of the payment
systems 418. Assuming the application 416B is the destination
application, the payment system 418A may determine a payment owed
to the entity associated with the application host system 404A for
the virtual object it relinquished to the application 416B.
Alternatively, or in addition, the payment system 418B may
determine a payment to provide to the entity associated with the
application 406A from which the virtual object was obtained. In
cases where the VO transfer system 420 facilitates the transfer of
the virtual object, the payment system 418TS may determine the
payment owed by the entity associated with the destination
application to the entity associated with the source application.
In some cases, the payment system 418TS may determine the payment
rate regardless of whether the VO transfer system 420 was involved
in the virtual object transfer. For example, the VO transfer system
420 may be used to facilitate payment between entities without
being involved in the conversion and/or transfer of the virtual
object.
[0064] The application host systems 404 and the VO transfer system
420 may include a skill checker 426 that can be utilized by a user
to determine the skill level a destination application will begin a
user based on a skill lever the user has achieved at a source
application. For instance, the skill checker 426A may determine
that a user who has achieved a driving skill rating of 100 while
playing application 406A will be granted a boating skill of 15, as
opposed to 0, if the user creates an account with the application
416B via, for example, an in-application link provided by the
application 406A. Further, in some cases, the skill checker 426A
can be used to determine virtual object characteristics for a
converted virtual object if the user decides to transfer a virtual
object between applications. Thus, in such cases, the user can use
the information provided by the skill checker 426 to determine
whether to transfer a virtual object between applications.
[0065] In some embodiments, a user may bank virtual objects at the
VO transfer system 420. For example, a user may decide that a
virtual object is no longer of value to the user in the application
406A, but the user may not have decided whether to create an
account with application 416B or another application. In such a
case, the user may decide to send the virtual object to the VO
banking system 424 to save until the user decides how to best use
the virtual object.
[0066] Further, in some embodiments, the user can provide another
user with temporary or permanent access to a virtual object by
lending or gifting the virtual object to the other user. In some
cases, the gifting or lending may be performed using the VO banking
system 424. In such cases, the VO banking system 424 can associate
the virtual object with the new user and temporarily or permanently
disassociate the virtual object with the original user.
[0067] While a number of systems have been illustrated and
described with respect to the one or more of the application host
systems 404, the user computing device 402, and the VO transfer
system 420, in some embodiments, some of the systems may be
optional. For example, the user computing device 402 may in some
cases not include one or more of the VO capture system 408L, the VO
convertor 410L, and the VO marker interface 414L. As a second
example, the application host systems 404 may, in some cases, not
include the skill checkers 426.
[0068] In some cases, one or more of the user computing device 402,
the application host systems 404, and the VO transfer system 420
may be owned by or associated with the same entity. In other cases,
some or all of the user computing device 402, the application host
systems 404, and the VO transfer system 420 may be owned by or
associated with different entities. For example, the user computing
device 402 may be associated with a user, each of the application
host systems 404 may be associated with different entities, and the
VO transfer system 420 may be associated with one of the entities
associated with one of the application host systems 404, or it may
be associated with its own entity.
Example Virtual Object Transfer Process
[0069] FIG. 5 presents a flowchart for an embodiment of a virtual
object transfer process 500. The process 500 can be implemented, at
least in part, by any system that can transfer a virtual object
from one application to another application. For example, the
process 500, in whole or in part, can be implemented by the VO
capture systems 408, the VO convertors 410, and/or the VO transfer
system 420, to name a few. Although any number of systems, in whole
or in part, can implement the process 500, to simplify discussion,
portions of the process 500 will be described with reference to
particular systems.
[0070] The process 500 begins at block 502 where, for example, the
VO capture system 408A captures a virtual object generated in
response to an in-application action performed in a first
application, such as the application 406A. This in-application
action can be any type of action that causes the application to
generate a virtual object. Typically, these actions are defined by
the developer of the application. In some cases, the virtual object
is captured in response to the virtual object being created.
However, in many cases, capturing the virtual object may be
triggered by other actions that are unrelated to the generation of
the virtual object. For instance, the virtual object may be
captured in response to a command by a user, a time period elapsing
since the virtual object was last used, or the release of a new
application that is capable of receiving a converted version of the
virtual object. Thus, although in some cases the virtual object may
be captured when it is created, or shortly thereafter, in many
cases the virtual object may be captured at some time after the
creation of the virtual object.
[0071] At block 504, the VO converter 410A identifies a second
application, such as the application 416B, to which the virtual
object is to be transmitted. The second application may be
identified by the user and/or may be identified based on
relationships between the applications, which may be stored at the
repository 412A. For instance, as illustrated in FIG. 1, the
application 406A may present the user with a set of applications to
which the user can transfer a virtual object. The user can then
select from the set of applications which application to transfer
the virtual object. The set of applications may be identified based
on previously established relationships between entities associated
with the application 406A and the application 416B. In some cases,
the VO convertor 410A may present the user with the set of
applications to which the user can transfer a virtual object.
[0072] The VO converter 410A identifies conversion rules associated
with converting the virtual object captured from the first
application for use with the second application at block 506. These
conversion rules may be obtained by accessing a repository 412A.
Further, the conversion rules can include any rules for converting
the virtual object from one application for use with another
application. These conversion rules can include technical rules for
making the software code of the virtual object compatible with the
application to receive the virtual object. Further, the conversion
rules can include non-technical rules for converting the virtual
object. For example, the conversion rules may be based on time,
market conditions, user profiles, etc. Some non-limiting examples
of these conversion rules are described with respect to FIGS. 6 and
7.
[0073] In some embodiments, the conversion rules may include rules
for converting the virtual object to a type of virtual object
utilized by the second application, which may differ from the type
of virtual object utilized by the first application. For instance,
the conversion rules may include rules for converting the sword of
the first application to a gun in the second application. In such a
case, the conversion rules may identify correspondences between
characteristics, and underlying software code, of the virtual
object of the first application and characteristics, and underlying
software code, for the converted virtual object for use with the
second application. For example, the conversion rules for
converting a sword in the first application may include accessing
an edge sharpness variable for conversion to an armor piercing
variable for a gun in the second application.
[0074] In some cases, the virtual object type may remain the same,
but the characteristics associated with the virtual object may
change when the virtual object is converted for use with the second
application. For instance, seeds in the first application may
remain as seeds in the second application, but the capability of
the seeds may differ. For example, in the first application, seeds
may grow flowers. In the second application, seeds may grow towers
(e.g., tower defense turrets). In yet other cases, the virtual
object may maintain both its type and its characteristics when
converted for use with another application. Thus, for example,
seeds in a Farm Game that grow flowers converted for use with a
Gardening Game may continue to grow flowers.
[0075] The use of the transferred objects may be conditioned on the
passage of time or the investment of the player in game play. For
example, transferred seeds may grow at a slower rate, may only be
planted after N hours of game play, may become usable only as seeds
are organically earned (e.g., for each seed you earn, you can also
use one of the transferred seeds), or otherwise. In some cases,
transferring virtual objects made provide a modifier for future
virtual objects that are obtained in the destination application.
For instance, seeds may be transferred at a one-to-one rate, or a
two-to-one rate. However, a user may also receive a modifier, such
as a two-to-one modifier, for virtual objects earned in the second
application. Thus, for each seed earned by a user in the second
application, the user may be granted two or three seeds, for
example. The modifier may be active for a specific time period of
for a number of virtual objects earned.
[0076] In some embodiments, the benefits, characteristics, or
effects associated with virtual objects that are transferred
between applications may be delayed. For instance, assume a seed
grows a flower, zombie, gem, etc. within one day (real-time or
game-time). In some cases, seeds obtained by transfer from another
application may take two or three days to grow. In some cases, the
conversion rate for virtual objects may be related to the rate at
which benefits, characteristics or effects of the virtual object
are realized. For instance, a seed that grows in one day may be
exchanged between applications at a rate of two-to-one, but a seeds
that grows in three days may be exchanged at a rate of
one-to-two.
[0077] In some cases, the user may choose whether to perform the
two-to-one exchange or the one-to-two exchange. In other cases, the
application or transfer system may decide. Further, the conversion
rate and speed of effect may differ for different quantities of the
virtual object. For instance, a user may be granted a one-to-two
rate with immediate effect for the first 10 seeds and a choice of a
one-to-two rate with a two day delay or a two-to-one rate with no
delay for subsequent seeds.
[0078] In some embodiments, a user may receive a better exchange
rate in exchange for accepting a longer vesting period or a limit
on how much of the virtual object can be used in a given time
period. For instance, a user may receive an extra 20% of seeds if
the user agrees to wait three days before using the seeds. As a
second example, a user may receive an extra 15% of seeds if the
user agrees to use only 10% of the user's available seeds per day.
In some embodiments, a user may accelerate access to the
transferred virtual objects by paying an additional fee or
retroactively agreeing to reduce the transfer rate of the
transferred virtual objects. Thus, if a user decides the seeds or
throwing knives are needed sooner than they will be available, the
user can pay a fee or agree to alter the conversion rate from
one-to-two to one-to-one, assuming the user has sufficient quantity
of the virtual object left to retroactively alter the conversion
rate. Alternatively, the user may borrow against a future
conversion rate to accelerate vesting of the current quantity of
the virtual object. Thus, the user may agree that any future seeds
transferred or otherwise obtained will be at a rate of two-to-one
in exchange for the user's current bank or allotment of seeds
vesting immediately.
[0079] The aforementioned delays in obtaining the benefit of or the
full conversion rate for transferring virtual objects may be used
to encourage the player to actively engage with the game for a
longer time period, to slow down the use of transferred objects so
that fraudulent activities giving rise to the items being
transferred or otherwise impacting the transfer have time to be
detected, or for any other reason that an entity may want to
prevent a user from immediately realizing the advantages or
benefits of transferring virtual objects between applications.
[0080] In some implementations, the exchange rate may be altered
(or exchanges that are otherwise impermissible may be allowed) by
aggregating objects and/or skills from more than one player. For
example, members of a guild may aggregate their objects and
transfer them together, thereby increasing their exchange rate. In
some implementations, a pre-existing relationship between those
doing the aggregating may be required. In other implementations, no
relationship may be required and/or a relationship may be
established during or after the aggregation and/or transfer.
[0081] At block 508, VO converter 410A converts the virtual object
for use with the second application based, at least partially, on
the conversion rules identified at the block 506. The VO converter
410A, at block 510, provides the converted virtual object to the
second application (e.g., the application 416B). In some cases,
providing the converted virtual object to the second application
may include providing the converted virtual object to the VO
convertor 410B or the VO capture system 408B of the application
host system 404B. The VO convertor 410B or the VO capture system
408B can then associate with converted virtual object with an
account of the user associated with the application 416B.
[0082] Although the process 500, and the other processes described
herein, is primarily described in terms of a virtual object, one
skilled in the art will recognize that the process 500, and the
other processes described herein, may be modified for use with
skills, characters or avatars, virtual currency, or
cash-alternatives. For example, the process 500 may include
identifying an achieved skill in a first application at the block
502. Then, the process 500 may include identifying a second
application which will provide some recognition of the achieved
skill at the block 504. At the block 506, the process 500 may
include identifying conversion rules for determining benefits with
respect to the second application to provide the user for the
user's achievement in the first application. The process 500 may
then cause the second application to provide the user with the
identified benefits for having achieved the requisite skill level
in the first application.
Additional Embodiments
[0083] In one embodiment, Game "A" requires users to play for some
period of time and/or to overcome at least one challenge before
generating a reward output. In this embodiment, at least one
additional game, Game "B," can use the reward output from Game "A"
as an input element that will facilitate the play of Game "B." It
is to be understood that the at least one challenge may be a skill
challenge or a random event, or any other result of normal or
special game play of Game "A."
[0084] In another embodiment, Game "A" may produce outputs which
serve as inputs for any number of a multitude of other games.
Similarly, Game "A" may receive game inputs from one or more of a
multitude of other games or applications. It is to be understood
that games and applications may produce more than one output which
serve as input items for one or more games. Therefore, Game "A" may
produce several output items that serve as input items for Game
"B." Some of those same output items may serve as input items for
other games, Game "C", Game "D" through Game "N." Some of those
same games may also produce output items which serve as input items
for Game "A" and/or for any of the other games or applications in
the ecosystem.
[0085] The ability to transfer skills or otherwise alter the skill
level ascribed in a second game based on the skill level achieved
in a first game may be based, conditioned, moderated, adjusted, or
otherwise impacted by the similarity or lack thereof in the game
controls and/or the game display and/or the hardware used. For
example, an expert in a racing game using a KINECT.RTM. may have no
ability greater than normal to control a vehicle using a physical
steering wheel. However, a high skill level in operating the KINECT
may imply a higher than normal ability to control any game on the
KINECT.
[0086] In one aspect, the relationship between tasks that generate
a game output and the type of uses to which that game output may be
put when used as a game input in a different game may be related.
For example, looking at a horse racing game that provides an output
that is used as an input to a car racing game, an output generated
by skillfully passing other horses may be used to generate values
or properties within the car racing game that are similar or
identical to values or properties generated when a user of the car
racing game skillfully passes other cars. In one aspect, the input
may be validated by testing the user to validate that the user has
an appropriate level of expertise in the thing being given in
response to the game input. For example, using the car racing
example, the user may seek to use game output from the horse racing
game showing a "level 10 passing skill" to create a "level 10
passing skill" in the car racing game. If the user is actually able
to demonstrate only a skill level commensurate with a level 4
passing skill, the user would be credited with only a level 4
passing skill. The remaining game output may be retained for later
use, and/or may be credited toward a level 10 passing skill, so
that when the user actually demonstrates the ability to utilize the
higher achievement level, that achievement level would become
immediately available to the user, in some implementations at no
further cost. Note that while this may, in some cases, be an
"Output Item", it should be noted that this may also (or
alternatively) be treated as an "output skill".
[0087] One illustrative embodiment utilizes aspects of the
disclosure in a fictitious relationship between two games, Farming
Game and Dungeon Game. In Farming Game, users may create a virtual
farm, and plant and harvest a multitude of virtual crops. One
aspect of the Dungeon Game provides for players to gain special
game abilities when they consume certain kinds of food.
[0088] Using embodiments described herein, if the producers of
these two games desire to cross-promote their games to their
respective user-bases (or if users wish to create and/or traffic in
commerce in part relying on game output/input trading and/or
sales), they could allow the outputs from Farming Game to be used
as inputs for Dungeon Game. In this example, a player of Farming
Game might need to reach a certain high-level farm before they
could begin to grow and harvest special food items. The special
food items (game outputs), once harvested, could be transferred to
players of Dungeon Game as game inputs.
[0089] By creating this cross-dependency, Dungeon Game players may
be motivated to begin playing Farming Game, so that they can
enhance the abilities of their characters in Dungeon Game, and
Farming Game players may be motivated to begin playing Dungeon Game
so that they can leverage their high-level farms from Farming Game
to their advantage in another game.
[0090] These game producers may wish to create additional
cross-dependencies, such as allowing Dungeon Game players to engage
in quests that reward them with special seeds, for example, which
seeds would enable Farming Game players to grow special crops that
they could not otherwise grow. Those special crops may or may not
serve to provide additional useful outputs for Dungeon Game
players.
[0091] In one implementation, the cross-dependencies may be
iterative, so that an output from Game A used in Game B that
generates an output from Game B that is used in Game A is different
in one or more ways from a simple single transaction. Thus, items
and their progeny that transition as output and input more than
once between two or more games may propagate at a faster or slower
rate, have a higher or lower value or exchange rate, or may
generate additional bonus items or benefits. Using the Farming
Game/Dungeon Game example, the special seeds from Dungeon Game may
be used to grow things in Farming Game that in turn may have
additional value when re-imported into Dungeon Game. In one aspect,
they may assist in completing quests or other challenges necessary
or useful to obtaining additional game outputs, such as (in the
example) a second species of special seeds. Those second species of
seeds, when used as a Farming Game input, may in turn grow faster,
fertilize neighboring crops, or have additional benefits compared
to first generation game input seeds.
[0092] The preceding example highlights an additional aspect of the
disclosure--that users are able to transfer the output-items from
the game or application that has generated the output-item, into at
least one other game or application that uses that output-item as
an input-item. Certain methods for transferring the ownership of
digital goods are disclosed in U.S. application Ser. No. 09/837,853
(now U.S. Pat. No. 7,593,864), which is hereby incorporated by
reference in its entirety.
[0093] In one embodiment, users can transfer the output items
generated by their use of one game or application into their own
account associated with at least one game or application, which may
be a different game or application than the one that generated the
output items. In this embodiment, users may be restricted to
transferring items only to themselves, or to accounts they can show
control over. This can serve as an advantage inasmuch as it would
require that the user would have to use both the game/application
that generates the output-item, and the game/application that uses
that item as an input.
[0094] In an additional aspect, users may transfer output-items
from at least one game or application into the accounts of at least
one user of at least one other game or application. The user
associated with the account who receives the item may or may not be
a different user. The receiving user may be required to consent
and/or to show certain relationships with the initial user and/or
to transfer something of value to the game operator, to an escrow
entity, and/or to the transferring user. In this embodiment, rules
may be established to restrict or permit the transfer. Rules for
restricting and facilitating access to items include provisions for
allowing or disallowing: users to pay for output-items, either in
real-world currencies or virtual-currencies or their equivalent;
users to trade output-items for input-items or for other items that
are useful in one or more of the games or applications that
comprise the ecosystem; users to trade output-items for input-items
or for other items that are useful in one or more of the games or
applications that are not part of the ecosystem, but which may be
part of an alternate ecosystem; users to auction output-items;
users to gift or give-away output-items; users to sell output items
for future consideration; users to sell or trade output items for
help, assistance or advice; users to sell or trade output items for
game-time or account upgrades. Similarly, users may offer to
purchase input items in any of the same methods as described for
the disposition of output items (for example, users may post offers
to purchase input items at a certain price in US dollars, or ask
for input items to be sent to them in exchange for helping a user
in one or more games). An open market system may additionally be
utilized to achieve liquidity and/or open market pricing.
[0095] An additional aspect of the disclosure provides an
application, system and method for game and application developers
to expose their product to the users of other games and
applications. Furthermore, the game outputs or game inputs may be
made available via an application programming interface (API).
Furthermore, the output/input relationship need not be rigidly
defined, but rather may be left open based on some valuation
method. For example, if a third party were to value the effort
required to generate an output, another application developer may
choose to accept that output at an exchange rate equal or similar
to the valuation. By leaving the outputs and inputs untethered to a
particular counterpart game, the market may determine the best game
input/output pairings. In one implementation, users may bid on
and/or underwrite and/or suggest input/output pairings, and may
optionally be allowed to share in revenue generated as a result of
those pairings, or to enjoy some reward based on the success of the
pairings.
[0096] One or more ecosystems of interdependent games and
applications may utilize embodiments of the present disclosure. To
encourage a structure that will enable producers to gain
significant exposure for their offerings either to users or to
other producers, certain rule-sets may be helpful. These rule-sets
may be dealt with contractually between two parties, or a small
group of parties. In an embodiment, these rules are established as
part of an open-marketplace, where qualified producers can offer
their games' or applications' output-items for use as input items
for other producers' products; and where producers can acquire
input-items for their games or applications. These marketplaces can
facilitate the assembly of game or application components by
producers who would "purchase" input-items for their products
through any well-established mechanisms for exchanging value, such
as payment of cash, trade or auction. In one aspect, where the
totality of a virtual environment (or a sufficient amount of a
virtual environment) is controlled by one system (or by a plurality
of systems working in concert or in communication), such rule-sets
may be stored within a data structure and/or implemented
programmatically. In an example of one possible aspect, if Party A
and Party B agree to a transaction whereby any seeds found by Party
A will be sold to Party B at a rate of N units of value per seed,
such agreement may be recorded in the system and automatically
enforced until one or both parties (depending on whether the
agreement requires one or both parties to agree) agree to
discontinue the agreement, at which point the computerized
instructions would be updated to reflect termination (or
alteration) of the agreement.
[0097] In one aspect, the ability to move input and output items
using the API may be restricted to cases where the software
provides some manner of digital signature indicating that the
valuation of the relative items remains unchanged, materially
unchanged, or largely unchanged. Advantageously, in certain
embodiments, by requiring the digital signature, confidence in the
marketplace may be maintained. In another aspect, a change in
relative value may be communicated dynamically and exchange rates
adjusted accordingly. In another aspect, the API may check with a
game server, or with a server or database or other controlling
computer that deals with a regulator or with a plurality of
producers in the operation of a marketplace or exchange, to
determine that the items are legitimate and/or that the difficulty
of generating the items is unchanged and/or to determine the extent
exchange rate. In another aspect, items generated when their
generation required effort equal to N will command an exchange rate
of N, even if the effort at the time of exchange has changed to X.
In such a case, a digital signature indicating the date the items
were earned, a check against a database, or other method of
validation (whether through an API or otherwise) may be used. In
this manner, even if a game changes the gameplay method, the user's
earned outputs will not be devaluated or inflated, thus minimizing
the ability of game operators to manipulate relative value. To
simplify things, in one implementation there may be bracketing of
items, such as "March 2012 Gold Pieces" which are worth N, while
"April 2012 Gold Pieces" are worth X, and where N and X relate to
the value (and/or difficulty of obtaining the items and/or the
abundance of the item) during such period.
[0098] It should be understood that any of the transactions
described herein may be made contingent upon obtaining adequate
assurance, such as via digital signature, that the party or parties
actually desire such transactions.
[0099] In one embodiment of the present disclosure, one or more
marketplaces or exchanges are created to allow producers of games
and applications or their components to buy, sell, trade and
otherwise exchange input-items and output-items. These marketplaces
or exchanges may make use of a coordinated network of a plurality
of computers, or one or more central computers, servers or
databases, or some combination thereof that would provide for users
of the system to supply, remove or otherwise validate and check in
and out various Input and Output items, and would operate in
accordance with one or more of: sets of rules, terms of use, or
contract requirements, which may establish at least one of the
following restrictions: a disclosure by the producer whose product
generates the output-item of the number of output-items that users
have been able to generate historically, or the number of
output-items that will be allowed to be generated by users in the
future, or the number of output-items that the producer themselves
will create, or any planned or expected or anticipated changes to
the product that could potentially impact the number or amount of
output-items that can or could be generated by either the users or
producer of the product or the difficulty or change to the
difficulty of obtaining the output item; or, permissions or
restrictions that are placed on producers who wish to participate
in the marketplace or exchange that limit: the number of
output-items that will be allowed to be generated by users in the
future, or the number of output-items that the producer themselves
will create, or any planned or expected or anticipated changes to
the product that could potentially impact the number or amount of
output-items that can be generated by either the users or producer
of the product or the difficulty or change to the difficulty of
obtaining the output item. In some cases, changing the difficulty
of obtaining an item may include changing the visibility,
placement, or promotion of an item so that the item is brought to
the player's attention in a different, diminished or increased
manner.
[0100] Some embodiments disclosed herein facilitate the creation of
games by enabling the developers to "assemble" games by collecting
other games together rather than building them from scratch. So,
for example, a small game production company might build a simple
character and combat system, and use inputs from various other
mini-games as their mechanic for arming and specializing their
characters--no need for them to build a questing component if
that's not their specialty, all the questing for items could, in
this illustrative example, be accomplished by dealing with the
mini-games, and then all the game producers need to worry about is
character advancement and their own combat system. A code signing
system may be used in such a case to validate that each component
has passed some review, for example a review for malicious code or
behavior.
[0101] Certain aspects of the present disclosure may lead to the
emergence of a highly complex network of interconnected games and
applications that stretches across the internet and mobile
networks, where games and applications are no longer distinct
entities, but rather, they rely on and participate within an
ecosystem. Users may navigate around this network in an analogous
way to how they surf the Internet--spending time interacting with
one game or application that relies on many, up to millions or
billions, of other applications. An infotainment economy of sorts
would emerge, where producers build useful components, and others
assemble components into larger clusters, many of which overlap
with others. In some embodiments, this infotainment economy may be
transparent to users. Users may provide work into the system, which
may shift over time, as they develop new interests and/or the value
earned from the "work" that they do changes over time. Value over
time may shift as game producers make updates, for example, that
would make an output-item easier or harder to earn. New suppliers
may be added to certain markets as new deals between producers are
struck, and this would have ripple effects throughout the
ecosystem.
[0102] In one implementation, waste and/or low-value items may be
utilized as Output Items. In this manner, certain of the benefits
may be realized without requiring users to sacrifice elements they
value in one game for benefits in another. For example, if the
Dungeon World permits users to fish, but fish caught below a
certain size are considered of little or no value, and/or have
little or no use in the Dungeon World, the fish may be used as an
Input Item to a Farming World where they may have value as
fertilizer.
[0103] In one implementation, items, or virtual objects, that have
been purchased, items acquired as part of a transfer, items earned
by playing the game, items that have been won, and items that have
been acquired in one or more other ways may each be treated
differently for purposes of exchange rates, restrictions on use or
transfer, or for other purposes or reasons based on how the item
was acquired. Thus, in some cases, virtual objects may be treated
differently based on how they were acquired in the first
application and how they may be used in a second application.
Further, in some cases, whether or not a virtual object can be
transferred may be based on how the virtual object was acquired in
the first application. For example, in some cases, virtual objects
that were obtained by purchase using real-world currency may be
blocked from being transferred to another application, or to a
particular application. However, the same virtual objects may be
transferable if obtained through other actions, such as defeating a
monster. In certain cases, to prevent circumvention of the rule
against transferring purchased virtual objects, a user may be
blocked from transferring the virtual object if any quantity of the
virtual object currently held was obtained via purchase with
real-world currency. In some cases, if the user ever purchased a
quantity of the virtual object, the user may be blocked from
transferring a quantity of the virtual object.
[0104] The decision of whether a virtual object can be transferred
may be based on rules associated with the first application, the
second application, or both applications. For example, suppose a
user may purchase credits in a first application, but that a second
application prevents the purchase of credits. In such a case, a
user may be prevented from transferring purchased credits from the
first application to the second application. However, credits
obtained by killing a monster may be transferable from the first
application to the second application.
[0105] As previously stated, the virtual object may be transferable
regardless of the mechanism of obtaining the virtual object, but
the capability or characteristics of the virtual object, or the
transfer process itself may differ. For example, virtual objects
obtained by purchase may be transferred at a one-to-one conversion
rate. However, virtual objects obtained by a transfer from another
application, or by defeating a monster, may be transferred at a
different conversion rate. As a second example, loot, or virtual
objects obtained by completing an objective in the application, may
maintain its characteristics, or corresponding characteristics if,
for example, the application type differs, when transferred to
another application. However, purchased virtual objects may receive
reduced characteristics to prevent a user from purchasing an
advantage. Alternatively, the purchased virtual objects may have
increased characteristics to, for example, encourage users to
transfer virtual objects obtained with real-world currency.
[0106] In another aspect, games and applications may be constructed
in a modular fashion so that certain activities, functions and/or
games (including where such elements may also be available in a
stand-alone manner and/or in other applications and/or games) may
be utilized with one or more games or applications made by one or
more third parties. For example, a company that makes a fishing
game may package such a game as a module which may then be used in
the
[0107] Dungeon Game and the Farm Game. In one implementation, the
fishing game would yield similar and/or interchangeable output
items and/or use similar and/or interchangeable input items and/or
use a similar interface so that people familiar with the game as a
module in one game may interact with that module in the same manner
in a second game.
[0108] In one aspect, the market price or exchange rate of items or
elements may be implemented into the game itself. For example, a
character who acquires ten Dungeon Game seeds may see a pop-up or
other communication upon acquiring them (or afterwards) stating the
exchange rate. Optionally, this communication may be interactive,
permitting an immediate trade and/or permitting a link into the
game where the item is used as an Input Item. One aspect provides
real time incentive to change game behavior in response to real
time information about input/output exchange valuations.
[0109] Groups and/or individuals may be engaged in playing games or
utilizing applications (sometimes doing one of a plurality of
actions repeatedly) in order to obtain virtual items for trade.
This is sometimes colloquially referred to as "Gold Farming". In
one aspect, real time exchange rate information may be incorporated
into the game displays presented to the players (including, in one
implementation, by overlaying or otherwise incorporating the data
without the consent of the game operator). In another aspect,
instructions may be programmatically generated to change the
behavior of players engaged in such "Gold Farming" in response to
real time data about exchange rates or valuations. It should be
noted that where the term "real time" is used, it includes, but
does not require, actual real time data, but would include data
that is sufficiently current to achieve the ends desired.
[0110] On one aspect, countermeasures to prevent gold farming may
be utilized. Such countermeasures may include sending different,
delayed, false, and/or manipulated exchange rate data to groups or
individuals based on location, language, similarities in behavior,
similarities in payment method, trading volume, length of
membership or other factors.
[0111] It is to be understood that producers of games or
applications that use this system may establish that more than one
input-item may have the same effect. Therefore, for example,
Dungeon Game may take input items from Farming Game to enable
players to eat a magical food, but that same magical food, or a
food with the identical properties, could also be obtained as an
input-item from another game or application, for example, the
mobile application Tiny Towers. In this way, a producer may allow
their users to have a choice in where to obtain the useful input
items, and they may protect themselves from sudden changes in the
amount of output-items produced from a single supplier.
[0112] Similarly, it is to be understood that a single output-item
may be used by more than one game or application as an input
item.
[0113] In one aspect, this structure may resemble an entangled web
of game producers, app producers, component producers, component
assemblers, and network users. This may be managed through web
sites that allow for marketplaces and auctions of components, as
well as marketplaces for all kinds of virtual goods and services in
the form of input and output items. Items, therefore, may in some
implementations include virtual services, not simply virtual goods.
It is important to note that throughout this disclosure, the term
"items" is not intended to be defined as simply virtual items, but
is meant to include all manner items, of virtual items, virtual
goods, virtual services and virtual space.
Example Market Rate Virtual Object Conversion Process
[0114] FIG. 6 presents a flowchart for an embodiment of a market
rate virtual object conversion process 600. The process 600 can be
implemented, at least in part, by any system that can convert a
virtual object for use with one application to a virtual object for
use with another application. For example, the process 600, in
whole or in part, can be implemented by the VO capture systems 408,
the VO convertors 410, the VO market interfaces 414, and/or the VO
transfer system 420, to name a few. Although any number of systems,
in whole or in part, can implement the process 600, to simplify
discussion, portions of the process 600 will be described with
reference to particular systems.
[0115] The process 600 begins at block 602 where, for example, the
VO converter 410A identifies a virtual object associated with a
first application, such as the application 406A, to be converted
for use with a second application, such as the application 416B. At
block 604, the VO converter 410A determines a time period during
which a first quantity of the virtual object is obtained with
respect to the first application. In some cases, the time period
may correspond to the point in time when the most recent quantity
of the virtual object was obtained. In other cases, the time period
may correspond to the point in time when the oldest quantity of the
virtual object was obtained. The first quantity of the virtual
object may refer to the entire quantity of the virtual object
obtained during the time period, or a subset of the entire quantity
of the virtual object. In cases where the first quantity of the
virtual object is a subset of the total available quantity of the
virtual object, the time period may be defined by either the oldest
or most recently obtained subset of the entire quantity of the
virtual object.
[0116] The VO market interface 414A, at block 606, determines a
conversion rate for converting the first quantity of the virtual
object to a second quantity of the virtual object for use with the
second application based at least partially on the time period. The
conversion rate may differ for the first quantity of the virtual
object compared to other quantities of the virtual object that are
obtained during different time periods. For example, a conversion
rate for seeds from a Farm Game to a World Domination Game may be
one-to-one during time period X. However, due, for example, to an
abundance of available seeds in the World Domination Game at time
period Y, the conversion rate may be reduced to a rate of
two-to-one to prevent the reduction of value of obtaining seeds in
the World Domination Game.
[0117] In some cases, the conversion rate is determined based on
the time that the user attempts to convert the virtual object
obtained in a first application for use with a second application.
In such cases, the block 604 may be optional. In other cases, the
conversion rate is determined based on the time period during which
the virtual object was obtained. In yet other cases, the conversion
rate may be based both on when the virtual object was obtained and
when the conversion of the virtual object is requested. Further,
the conversion rate may be based on how long the user has possessed
or had access to the quantity of the virtual object. For instance,
the conversion value of an object may decrease over time to
incentivize, for example, the user to either use or convert the
virtual object sooner. Conversely, the conversion rate of some
objects may increase over time to incentivize, for example, a user
to maintain an account with the game for a longer period of
time.
[0118] At block 608, the VO converter 410A converts the first
quantity of the virtual object for use with the first application
to the second quantity of the virtual object for use with the
second application based at least partially on the conversion rate
identified at the block 606. In some embodiments, the block 608 may
include converting the type of object as well as the quantity of
the object. For example, 100 seeds capable of growing flowers in
Farm Game may be converted to 50 seeds capable of growing zombies
in World Domination Game. As a second example, 100 seeds capable of
growing flowers in Farm Game may be converted to 200 throwing
knives in Ninja Game.
Additional Embodiments
[0119] Time and fractional shares, which is described further below
with respect to FIG. 7, are two examples of factors that may affect
conversion rates. However, any number of other factors may affect
conversion rates. Without limiting the scope of the disclosure, one
illustrative example of one aspect may be trading of the special
seeds obtained in the Dungeon Game for various crops grown in the
Farming Game. In one aspect, an exchange rate may be set or may
emerge, whereby N Imagination Fruits (from the Farming Game) are
worth X seeds (from the Dungeon Game). From the perspective of the
Farming Game, the Dungeon Game seeds are "Input Items". From the
perspective of the Farming Game, the Imagination Fruits are "Output
Items". From the perspective of the Dungeon Game, the foregoing
Input and Output Item descriptions would be reversed.
[0120] In one embodiment, a market-based trading system, such as
may be implemented by the VO market interfaces 414, may be
implemented to facilitate identification of proper exchange rates.
In another aspect, the rates may be set on a
transaction-by-transaction basis, may be fixed, or may vary over
time. The exchange rate may vary with the partial or total
aggregate supply or demand. In addition and/or in combination, a
statistical surveyor analysis may be utilized to determine the
current and/or likely future relationship between supply and
demand. Exchange rates may also be set and/or influenced and/or
subsidized based on contracts, financial or other exchanges between
game and/or application operators and/or publishers.
[0121] Small changes to a game or application may have a
significant impact on the relative value of certain items or
virtual objects. For example, if the Farming application moves the
"Imagination Fruit" to the top of the list of possible crops to
plant, the supply of "Imagination Fruit" may be significantly
increased even in the absence of contract, pricing, or functional
game play changes. Such an increase might lower the value of
"Imagination Fruit", requiring fewer Dungeon World seeds to trade
for the same amount of Imagination Fruit. Similarly, substantive
changes to game play (such as reducing the time it takes for
Imagination Fruit to ripen) may impact pricing. To protect player
expectations, to include additional confidence in the trading
system, and/or for other reasons, it may be desirable to assign an
exchange or other value to items based on when they were produced
(or, in some cases, acquired). For example, there may be June
Imagination Fruit and July Imagination Fruit, where a programmatic
change done at 11:59 pm on June 30 made Imagination Fruit much
easier to obtain. In such a case, June Imagination Fruit may have a
fixed exchange rate (or value) of N and July Imagination Fruit may
have a fixed exchange rate (or value) of X, where N and X reflect
the pricing of Imagination Fruit in June and July, respectively. In
one implementation, N and X may reflect the relative pricing of
Imagination Fruit between June and July rather than the absolute
pricing, so that, for example, if the June price was 100 and the
July price was 50, when the extent pricing drops to 25, June
Imagination Fruit would be worth 200% of July Imagination Fruit, or
50 and 25 respectively. In another aspect, only some portion of the
pricing may be tied to value at the time or creation or
acquisition. Regardless of the formula utilized to determine value,
in one implementation the value may be adjusted by increasing the
number of items rather than the pricing of items. Using the example
where the June price was 100 and the July price was 50, a user with
10 June Imagination Fruits would have 20 July Imagination Fruits,
although in some implementations the change may be transparent to
the seller by showing the Seller as selling 10 June Imagination
Fruit and the buyer acquiring 20 July Imagination Fruits. The time
windows utilized may be large (such as year-by-year or
month-by-month), as small as measurable (such as in milliseconds),
or any window in between. Where simplicity is desired, or for other
reasons, larger time windows may be desirable. In other cases, the
accuracy of very small windows may be desirable. In one
implementation, each trade may be recorded in a SQL database, and
in a further implementation the time stamp may be made a field that
requires a unique number so that each trade may be identified in
sequence and with significant accuracy as to the time the trade
took place. Where there is a conflict and two or more trades are
intended to be executed simultaneously, in the case where the time
stamp field is unique, a rule set or random determination may be
utilized to record the trades in a sequence.
[0122] In the event that unusual trading activity takes place, such
as exchanges of items in significantly greater numbers than
historically expected and/or where prices shift significantly
and/or where exchange rates shift significantly, trading may be
halted and/or slowed. The unusual trading activity may be detected
by utilizing a computer to determine trading that meets or exceeds
or fails to meet certain criteria. In one aspect, where there is a
change in number of trades and/or amount of item traded and/or
price of item traded (or some combination whereof) of more than N %
over Y time period (where N and Y may be different for each
metric), trading may be stopped, slowed, or throttled. It should be
noted that trading activity, and any response, need not be measured
or implemented market-wide, but may instead (or in addition) be
done on single accounts, on related accounts, on accounts with
similar characteristics, on geographically similar accounts, on
ISP-similar accounts, on similar-language accounts, or otherwise.
Unusual trading activity may also include where one or more
accounts change their trading volume regardless of the relative
size of the change to the market size (as might be the case where a
user or a group of users uncover a programming flaw that allows
rapid generation of items).
[0123] The response to unusual trading activity may also be made
based on time stamps or time windows of trades or exchange or sales
or acquisition of items. In one implementation, items acquired
before and/or after the unusual activity may be treated differently
in any response in comparison to items acquired after and/or during
the unusual activity. In another implementation, items that have
been involved in unusual trading activity may be treated
differently from those that have not. In one implementation, the
response to unusual trading activity may be to limit the amount of
an input item or output item that is available on an aggregate
and/or per user basis. Similarly, location of generation may also
be utilized as a differentiating factor. Where exchange rates are
referenced herein, it should be noted that in one aspect, they may
be enforced by a computerized trading algorithm, and in a related
aspect, where a single system or systems acting in concert control
a virtual environment, such enforcement may be made part of the
environment.
[0124] The exchange rate and/or value of items may be altered based
on financial or other agreements between service provider and/or
game and/or application operators or users. In one aspect,
alterations of the rate may be utilized as a form of advertising
and/or a manner to drive traffic or users to a game or application
(or away from a game or application). In such a case, pricing for
items may be calculated in a manner similar to the way banner ad
pricing is determined, including by CPM, which may refer to cost
per mile or cost per impression. There may be limited availability
of discounted items, for example, as where the Dungeon Game agrees
to give more Dungeon Game seeds for each Imagination Fruit it
receives in exchange for a payment from the Farm Game, but the
subsidy runs out at a point agreed to between the parties, related
to the pricing of the subsidiary, and/or related to the number of
persons or users acquired, who visit the other game, or who meet
other criteria with regard to their response to the subsidy.
[0125] In some cases, the methods or actions used to obtain the
virtual objects may impact the conversion rate. For example, a user
who obtains virtual objects by grinding may receive a different
conversion rate for the virtual objects than a user who obtains the
same virtual objects by purchasing the virtual objects with
real-world currency and/or virtual currency. In cases where a user
is converting a quantity of virtual objects, the conversion rate
may differ based on a percentage of the virtual objects converted
that were obtained with one type of action versus another type of
action.
Example Shared Virtual Object Conversion Process
[0126] FIG. 7 presents a flowchart for an embodiment of a shared
virtual object conversion process 700. The process 700 can be
implemented, at least in part, by any system that can convert a
fractional share of a quantity of a virtual object for use with one
application to a quantity of a virtual object for use with another
application. For example, the process 700, in whole or in part, can
be implemented by the VO capture systems 408, the VO convertors
410, the VO market interfaces 414, and the VO transfer system 420,
to name a few. Although any number of systems, in whole or in part,
can implement the process 700, to simplify discussion, portions of
the process 700 will be described with reference to particular
systems.
[0127] The process 700 begins at block 702 where, for example, the
VO converter 410A identifies a virtual object associated with the
first application to be converted for use with a second
application. At block 704, the VO converter 410A determines a
fractional share of the quantity of the virtual object associated
with a user of the first application. For example, suppose a group
of ten users defeated a monster together in World of Monsters,
e.g., as a part of a "raid" where a team of players jointly attempt
to achieve an in-application goal associated with a portion of the
game, such as defeating a boss or completing a dungeon. In such an
example, each user may receive 10 gems for a total capture of 100
gems as a reward for defeating the monster. Thus, in such an
example, the user's fractional share would be 10 gems.
[0128] Using, for example, the VO market interface 414A, the VO
converter 410A determines a number of users associated with
fractional shares of the quantity of the virtual object who have
converted their fractional shares for use with the second
application at block 706. For instance, continuing the above
example, the VO convertor 410A may determine that five users have
converted their 10 gems from World of Monsters into credits for the
game Land of Demons.
[0129] At block 708, the VO market interface 414A determines a
conversion rate for converting the fractional share the quantity of
the virtual object associated with the user to the quantity of the
virtual object for use with the second application based, at least
partially, on the number of users who previously converted their
fractional shares for use with the second application. In some
cases, the conversion rate may increase if more users convert their
fractional shares of the quantity of the virtual object for use
with the second application. Further, the conversion rate may
retroactively change for users who have already converted their
fractional shares of the quantity of the virtual object. For
instance, again continuing the above example, the user may obtain a
one-to-two conversion rate for the gems resulting in 20 credits
because five other users already converted their fractional shares
of the 100 gems. If a seventh user converts his or her share of the
gems, the conversion rate may change to one-to-three. In such a
case, the previous user who already converted the gems at a rate of
one-to-two may be granted an additional ten credits once the
seventh user converts his or her gems. Advantageously, in certain
embodiments, by adjusting the conversion rate retroactively, each
of the users is incentivized to convince more users from their
party to convert their fractional share of a quantity of the
virtual object.
[0130] The VO converter 410A converts the fractional share of the
quantity of the virtual object associated with the user to a
quantity of the virtual object for use with the second application
based at least partially on the conversion rate at block 710.
Additional Embodiments
[0131] In some embodiments, outputs and/or revenue may be provided
to a plurality of users, in some cases providing additional, fewer,
or different outputs and/or revenue than could or would be obtained
if the actions triggering the outputs and/or revenue were
undertaken by (or undertaken for the benefit of) a single user. For
example, if a group of players in Dungeon Game form a "clan" and
together win one or more objects that may be used as inputs to the
Farming Game, the exchange rate when putting the outputs into the
Farming Game may be adjusted to take account of the group nature of
the generation of the outputs. In another aspect, where outputs are
jointly owned, as in the case of a clan jointly obtaining a single
"magic plowshare" from a monster in the Dungeon World, the joint
nature of the ownership may be preserved in whole or in part when
used as an input for Farming World.
[0132] In one aspect, more than one joint owner (between two and
the total number of joint owners) may be required to participate in
the Farming Game (or whatever game the output is used as an input
for) in order to utilize some or all of the value of the output. An
alternative implementation allows fractional importation of jointly
owned outputs. In such an implementation, incentives may be
provided (e.g., additional value for converting the output or
virtual object) to encourage multiple users, and some cases each of
the owners of the fractional shares, to join their fractional share
in the game or application for which they are inputs. Thus for
example a clan of ten users may jointly obtain 100 magic seeds in
the Dungeon World. In one implementation, any of the ten users may
take their fractional share, 10 seeds, and use it as an input to
Farming World. The fractional share of 10 seeds may be converted at
N.times.10, where N represents the conversion rate. In one
implementation where N is 0.80, the 10 seeds in Dungeon World are
converted to 8 seeds in Farming World (or ten seeds with a
discounted efficacy equivalent to 8 seeds).
[0133] Optionally, when other players in the clan use their seeds
as inputs, N may be increased. In one variant, if one user uses the
seeds, N=N; if 2 users use the seeds, then N=N+Y or N=N.times.Y; if
3 users use the seeds, then N=N+Z or N=N.times.Z. In another
variant, when user 1 uses the seeds, N=N; when user 2 uses the
seeds, N=N.times.1.1, and optionally user 1 gets an additional
N.times.0.1 (or N.times.0.2 etc.). Optionally, when all players in
the clan use their seeds as inputs, N may be made equal to (or
greater than) 1. Optionally, the players who imported the seeds
first (or earlier) may get an additional bonus, or a better
exchange rate (or a worse rate) than players who imported them
later. In order to obtain an increase to N, optionally players may
utilize the seeds in a coordinated manner, in whole or part.
[0134] When a potential output item is jointly owned, it should be
understood that ownership of the virtual item may, in some cases,
be treated in at least the same variety of ways that real property
or other tangible property may be treated. Thus, for example, seeds
in the Dungeon Game may be owned as community property, as a joint
tenancy with right of survivorship, as tenants in common, limited
to transfers with the consent of all owners, limited to transfers
with the consent of a majority or other percentage of owners,
transferable by anyone owner, severable, non-severable, or any
other ownership modality or modalities. Additionally, a third
party, such as an employer or a charity, may be designated as a
beneficiary of coordinated transfers of output items, whether by
giving the entity a portion of the output items (or their value) or
by giving them a bonus additional item, value, or thing.
[0135] In some instances, it may be the case that certain players
in the clan are higher level or are in leadership roles in the
clan, and/or that certain players take leadership roles in driving
or encouraging or facilitating the use of Output Items. It may
therefore be the case that "loot" is not divided equally, or
ownership shares may not be evenly distributed, or that benefits of
utilizing Output Items would not be evenly distributed. Indeed, in
some cases, users may register with a computing system (e.g., the
VO transfer system 420) that is capable of enforcing distribution
or allocation of benefits and/or risks of quests and/or of using
Output or Input Items. In some cases, the application or
application host may enforce the division of virtual objects.
[0136] A further problem exists in the area of gaming and
applications, where ownership of digital and/or virtual items
and/or goods becomes clouded upon the death of the actual owner or
of a character or avatar. In one aspect, embodiments of the present
disclosure can track ownership of items and may be used to
determine ownership and/or access to items after the death of the
actual owner or of a character or avatar. In one aspect, a SQL
database (or other data structure, such as the repository 410) is
utilized to store ownership data.
[0137] In another aspect, upon the death of an avatar or character,
a database or data structure may be accessed by a program or game
server to effectuate a transfer of ownership of a virtual item in
keeping with the title. Thus, for example, if Jim and Jane are
"married" in a virtual reality game, they may hold title to their
virtual house as "joint tenants with right of survivorship". If Jim
actually dies and/or if Jim's avatar dies (or if Jim quits the game
or otherwise becomes inactive), the system may automatically
recognize that Jim has died, based for example on public records or
time since last access, and ownership of the house is now Jane's
alone. Because gaming systems (and other applications) differ from
the real world in that users can "die" or otherwise terminate their
use of the game, and then come back to life (as in the case of a
user who fails to pay monthly fees, is terminated, and then brings
the account current), new ownership structures, and methods to
automate implementation of those structures, must be created. In
one aspect, title may be held as "Jane alone, with a right to
restoration held by Jim", whereby Jane holds title alone unless and
until Jim returns from the dead, at which time title may
automatically (or upon request, or upon payment of a fee) return to
the title status prior to death (or to some other title status). In
one aspect, the right to restoration may extinguish after a period
of time. In another aspect, the right may become more expensive to
exercise as time passes. In one aspect, if property is held in such
a title (i.e. title with some form of right to restoration), when
that property is sold, traded, or otherwise alienated, whatever
benefit that accrues to the extent title holders may inherit the
title of the sold, traded, or otherwise alienated property. Using
the example of Jane and Jim, if Jane sells property titled as "Jane
alone, with a right of restoration held by Jim" in exchange for
virtual currency, the currency may be titled as "Jane alone, with a
right of restoration held by Jim". When the currency is used to
purchase a virtual car, title to the car would likewise be "Jane
alone, with a right of restoration held by Jim." It should be
appreciated that a database or data structure is one method to
track such ownership, and to track title through a serious of
transactions.
[0138] In one aspect, title with a right of restoration may be
limited to transactions where title to the proceeds of the
transaction may be held with a right of restoration. In another
aspect, Jane may be required to compensate for some or all of his
interest if he returns from the dead (e.g., revives an account with
the application) and she has sold, traded or alienated the
property. In some aspects, it may be useful to allow title to
transfer over time, such that eventually, a clear title may be held
by Jane. This may be done incrementally, as in equal portions over
a period of time; it may be done with a grace period before
beginning an incremental or other transfer; it may be done as a
logarithmic or exponential transfer; it may be done according to
another formula; or it may be done in combination, among other
ways. Transfers may additionally be made differently for different
properties and/or classes of properties. Funds or virtual goods or
services that are received by one owner of a joint ownership
property may be distributed to the "surviving" owner only in part,
with the balance going into an escrow fund, which escrow fund could
release the funds to the survivor as title or portions of title are
removed from the decreased owner, or which could return all or part
of those funds to the title holder upon reactivation of the
account. In another aspect, the escrow fund may instead be treated
as a trust, wherein some or all of the funds may only be used for
purposes that fall within the rules of the trust. In one aspect,
the default trust rules may require funds be used for the benefit
of all beneficiaries in approximately equal share. In another
aspect, the trust rules may change over time, or may change with
the increasing time or other measure since one or more
beneficiaries have been active. In one aspect, one or more
confirmation events, such as an email indicating a window of time
to rejoin a system or a communication indicating that a positive
agreement is required to allow transfers or a communication
indicating that an intervention is required to structure, prevent,
or facilitate transfers may be required or utilized prior to
transfer, in conjunction with transfer, and/or in conjunction with
any right to reclaim.
Example Process for Provisioning a Converted Virtual Object to an
Application
[0139] FIG. 8 presents a flowchart for an embodiment of a process
800 for provisioning to a second application a converted virtual
object converted from a virtual object of a first application. The
process 800 can be implemented, at least in part, by any system
that can provide a virtual object that has been converted for use
with a different application than the application that initially
generated the virtual object. For example, the process 800, in
whole or in part, can be implemented by the VO capture systems 408,
the VO convertors 410, the VO market interfaces 414, and/or the VO
transfer system 420, to name a few. Although any number of systems,
in whole or in part, can implement the process 800, to simplify
discussion, portions of the process 800 will be described with
reference to particular systems.
[0140] The process 800 begins at block 802 where, for example, the
VO converter 410A identifies a user account associated with a user
of the first application (e.g., the application 406A). The user
account may be identified by, for example, accessing the repository
412A to identify account information. In some cases, the
application host system 404A may use information obtained from the
user and/or the user computing device 402 to facilitate identifying
user account information for the user.
[0141] At decision block 804, the VO transfer system 420 determines
whether the user has a user account with the second application
(e.g., the application 416B). In some cases, the VO transfer system
420 may access one or more of the repository 412TS and the
repository 412B to determine whether the user has an account
associated with the second application. In some cases, the VO
transfer system 410B or the VO market interface 414B may determine
whether the user has an account with the second application.
Determining whether the user has an account with the second
application may include comparing account information associated
with the user's account associated with the first application to
account information for accounts with the second application.
Alternatively, or in addition, the decision block 804 may include
comparing a checksum or hash associated with the user of the first
application with checksums of accounts with the second application
to determine whether the user has an account with the second
application. In some cases, instead of comparing checksums, a
lookup in database or a table keyed by the checksum may be
performed to determine whether the user has an account with the
second application.
[0142] If the user does not have a user account with the second
application, the application host system 404B presents the user
with a user interface for obtaining access to the second
application at block 812. This user interface may enable the user
to create an account for using the second application. In some
cases, the user may be presented with an option to automatically
generate an account with the second application based on the
account information associated with the user's account at the first
application.
[0143] If the user does have a user account with a second
application, the VO capture system 408B associates the converted
virtual object with the user account at the second application at
block 806. At block 808, the VO capture system 408A disassociates
the virtual object with the user account at the first application.
In some embodiments, the block 808 may be optional. In such cases,
the user may maintain access to the virtual object at the first
application as well as transferring a copy of the virtual object to
the second application.
[0144] At block 810, the application host system 404A alerts the
user to the completed virtual object transfer. The user may be
alerted using any method for informing the user that the virtual
objects have been transferred. For example, the user may be
presented with a message informing the user of the completed
virtual object transfer upon accessing the first and/or second
application. Alternatively, or in addition, the user may receive an
email, text message, social networking message, or any other type
of message informing the user of the transfer of the virtual object
from the first application to the second application.
Example Dataflow for Provisioning a Converted Object to an
Application
[0145] FIG. 9 presents a dataflow 900 for an embodiment of a
process for provisioning a converted virtual object to a second
application. In some embodiments, the dataflow 900 may represent
the execution of the process 800 described above with respect to
FIG. 8.
[0146] The dataflow 900 begins at operation 1 where, for example,
the user computing device 402 requests a virtual object transfer of
a virtual object from an application hosted by the application host
system 404A to a second application hosted by the application host
system 404B. The request may be performed in response to a
selection of a virtual object transfer option by the user within a
local application 406L, which may be a local portion of the
application 406A.
[0147] At operation 2, the application host system 404A creates a
message that includes the virtual object and a checksum, hash, or
other unique account identifier associated with user account
information for the user or owner of the virtual object who
generated the virtual object transfer request as part of operation
1. In some cases, the checksum may be a hash of user account
information. Alternatively, the checksum may be a unique hash
associated with the user that is unrelated to account information.
Further, in some cases, alternative to, or in addition to, the
checksum, the message may include account information associated
with the user, such as a user name. In some cases, the application
may create the message. In other cases, a system included with the
application host system 404A may create the message, such as the VO
convertor 410A.
[0148] The application host system 404A, as part of operation 3,
provides the message with the virtual object and the checksum to
the application host system 404B. In some cases, the message may be
provided as part of a single packet. However, in other cases, the
message may be divided among multiple data packets.
[0149] At operation 4, the application host system 404B associates
the virtual object with an account that includes a checksum
matching the checksum received in the message provided as part of
operation 3. Alternatively, if an account with a matching checksum
does not exist, the application host system 404B creates a new
account to include the virtual object. Thus, in some embodiments,
the new account may be associated with the virtual object instead
of, or in addition to, being associated with a user. The account
associated with the virtual object may be an anonymous account. In
some cases, from a perspective os a user transferring a virtual
object from one application to another application that the user
may or may not have an account with may be as simple as a one step
process. For example, the user may select a link or press a button.
In response to the user's action, a first application (or a system
associated with the first application) may prepare a virtual object
for transfer to a second application and transfer the virtual
object. The second application (or a system associated with the
second application) may associate the virtual object with an
identified user account (existing or new), or create an account
associated with or in the "name" of the virtual object and enable
the user to use the account. If the account is associated with the
virtual object rather than a user, the user can decide at some
point in time whether to transfer the account to the user, merge
the account with a user account, abandon the account, or rescind
transfer of the virtual object.
[0150] Going through an account creation process may be considered
a hassle by some users. Advantageously, in certain embodiments,
creating an account for the application hosted by the application
host system 404B based on the virtual object enables users to avoid
the effort of creating a new account. If a user decides he or she
likes the application and wants to continue using the application,
the user can then create an account, or have the account associated
with the virtual object transferred to the user. Alternatively, or
in addition, the account associated with the virtual object may be
combined with an existing user account. For example, a user may use
the account associated with the virtual object temporarily and then
decide whether to combine the virtual object account with the
user's account or to cancel a transfer of the virtual object.
[0151] In some embodiments, the virtual object may be consumed or
permanently transferred to the new application. Thus, in some
cases, the virtual object may be used in lieu of payment for
accessing the application hosted by the application host system
404B.
[0152] At operation 5, application host system 404B confirms the
virtual object transfer to the user associated with the virtual
object. Confirming the virtual object transfer to the user can
include providing the user with a message that the virtual object
transfer successfully completed, such as was described with respect
to the block 810.
[0153] Further, at operation 6, the application host system 404B
performs a virtual object transfer payment process. The virtual
object transfer payment process can include any process for an
entity associated with the application host system 404B
compensating an entity associated with the application who system
404A for the transfer of the virtual object. An example of a
virtual object transfer payment processes described in further
detail with respect to FIG. 10.
[0154] Although the dataflow 900 has been described with respect to
three separate systems, the user computing device 402, the
application host system 404A, and the application host system 404B,
in some embodiments, the dataflow 900 may be modified to work with
a fewer or greater number of systems. For example, in some cases, a
VO transfer system 420 may facilitate the transfer of virtual
objects between applications. In such cases, operation 3 may
include providing the message with the VO and checksum to the VO
transfer system 420.
[0155] The VO transfer system 420 may then provide the message and
checksum to the Application host system 404B. Alternatively, the VO
transfer system 420 may perform one or more of the operations 4, 5,
and 6. For instance, the VO transfer system 420 may determine
whether the user has an account with the application hosted by the
application host system 404B by comparing the checksum to hashes
stored at the repository 412TS or the repository 412B.
[0156] In other embodiments, one or more of the applications are
hosted on the user computing device 402. In such cases, the
dataflow 900 may be performed between applications and/or systems
that are included as part of the user computing device 402. For
instance, the local application 406L may create a message that
includes the virtual object and a checksum for a user account with
the local application 406L. The local application 406L may then
provide the message to the local application 416L, which may then
perform the remainder of the previously described operations for
the dataflow 900.
Example Virtual Object Transfer Payment Process
[0157] FIG. 10 presents a flowchart for an embodiment of a virtual
object transfer payment process 1000. The process 1000 can be
implemented, at least in part, by any system that can provide
compensation to an entity (e.g., developer, owner, publisher, etc.)
associated with a first application for the transfer of a virtual
object from the first application to a second application
associated with another entity. For example, the process 1000, in
whole or in part, can be implemented by the VO capture systems 408,
the VO convertors 410, the VO market interfaces 414, the VO
transfer system 420, and/or the payment system 418, to name a few.
Although any number of systems, in whole or in part, can implement
the process 1000, to simplify discussion, portions of the process
1000 will be described with reference to particular systems.
Depending on the embodiment, the method of FIG. 10 may include
fewer or additional blocks and the blocks may be performed in an
order that is different than illustrated.
[0158] The process 1000 begins at block 1002 where, for example,
the payment system 418A identifies a virtual object transferred
between a first application and a second application. In some
cases, identifying the virtual object transferred may include
identifying a quantity of the virtual object transferred (e.g., the
number of gems or throwing knives, etc.).
[0159] At block 1004, the payment system 418A identifies a
conversion rate that was used to transfer the virtual object from
the first application to the second application. For example, the
payment system 418A may determine that the conversion rate was
one-to-one (e.g., one gem for one credit) or two-to-one (e.g., two
throwing knives for one grenade).
[0160] Payment system 418A, at block 1006, determines one or more
actions performed by a user in the first application to obtain the
virtual object. These actions can include, for example, completing
an in-application task, trading another virtual object or a virtual
currency with another user or another application, purchasing,
using real-world currency, virtual currency, or a combination of
the two, the item from an in-application market or from an entity
associated with the application, etc. In cases where, compensation
is being determined for a plurality of the virtual object, the
block 1006 may include identifying multiple actions or sets of
actions used to obtain the plurality of the virtual object. For
instance, some quantity of the virtual object may be obtained by
the user completing an in-application task and some additional
quantity of the virtual object may be obtained by the user
providing a payment to the entity (e.g., a hosting entity that owns
the application host system 404A) associated with the
application.
[0161] At block 1008, the payment system 418A determines a usage
pattern associated with the user's usage of the first application.
The usage pattern can include metrics associated with the user's
interaction with the application. For example, the usage pattern
may include information relating to the amount of time the user may
spend "grinding" or repeatedly performing actions to increase the
user's experience level or virtual currency level. Additional
examples of metrics that may be part of the usage pattern may
include: the difficulty level the user plays most often, the amount
of time the user spends in a time period using the application, how
often the user purchases items or features using real-world
currency, etc. Advantageously, in certain embodiments, by examining
the usage pattern of the user, payment for the transfer of the
virtual object can be based on a subjective value of the user. For
example, if user's who spend more money or more time on an
application are considered more valuable, the entity associated
with the first application may charge the entity associated with
the second application at a greater rate for allowing the transfer
of the virtual object between the first application and the second
application.
[0162] The payment system 418A determines utilization
characteristics associated with the second application at the block
1010. The utilization characteristics of the second application may
include any characteristics associated with the state of use of the
second application. For example, the utilization characteristics
may include the number of users who are using the second
application or the average length of time that users are using the
second application over a time period. Advantageously, in certain
embodiments, by examining the utilization characteristics of the
second application, a payment rate may be determined based on the
status of the second application and, in some cases, the user who
is transferring the virtual object. For example, if the second
application has few users who spend much time using the second
application, the entity associated with the second application may
pay a premium for a user who tends to spend a lot of time using
applications. This may particularly be so with the type of
application whose stickiness, or ability to keep users, increases
with the number of users who use the application, such as with
MMORPGs that have a lot of player versus player (PVP) features.
[0163] At block 1012, the payment system 418A identifies a payment
rate for the transfer of the virtual object by the user from the
first application to the second application based at least
partially on the conversion rate, the one or more actions performed
by the user in the first application to obtain the virtual object,
the usage pattern, and/or the utilization characteristics obtained
at the blocks 1004, 1006, 1008, 1010, respectively. In certain
embodiments, one or more of the blocks 1004, 1006, 1008, and 1010
may be optional. In such embodiments, the block 1012 may exclude
the optional information in determining the payment rate. Thus, for
example, the payment rate may be based on the conversion rate
alone, or on the conversion rate and the usage pattern of the user,
etc.
[0164] Payment system 418A, at block 1014, transfers payment from a
developer (or other entity) of the first application to a developer
in parentheses or other entity) of the second application based, at
least partially, on the payment rate associated with the transfer
of the virtual object is determined at the block 1012. In some
embodiments, the transfer of payment may occur at the time the
virtual object is transferred, at the time the virtual object is
used at the second application, at a time upon which the entity
associated with the second application bills the entity associated
with the first application, or at any other time that may be
determined by one or more entity associated with one or more of the
first application and the second application. In some cases, the
transfer of payment may occur through a third party, such as an
entity associated with the VO transfer system 420.
[0165] Although the process 1000 has been described as being
performed by the payment system 418 associated with the first
application (e.g., the payment system 418A), in some embodiments,
the process 1000, at least in part, may be performed by the payment
system associated with the second application (e.g., the payment
system 418B) or the payment system associated with the VO transfer
system 420 (e.g., the payment system 418TS). In such cases, the
block 1014 may include billing or requesting payment from the
entity associated with the first application and/or from the
payment system 418 associated with the first application (e.g., the
payment system 418A).
[0166] Advantageously, in certain embodiments, the process 1000
prevents or reduces the situation where a user provides monetary
payment, or other compensation, to a first application, but
receives services from the second application without an entity
associated with the second application being compensated. For
example, suppose a user purchases credits from one social
networking application, but transfers the credits to another social
networking application or a dating application. Then suppose the
user spends the credits at the dating application. In such an
example, an entity associated with the first social networking
application received compensation, but the dating application
provided services (e.g., direct messages to potential dates). Using
the process 1000, the entity associated with the dating application
may receive at least partial compensation. In some cases, the
entire compensation provided by the user to the entity associated
with the first application (e.g., the social networking
application) is provided to the entity associated with the second
application (e.g., the dating application). In other cases, only a
portion of the payment is transferred. In such cases, the first
application may retain some of the compensation as a form of a
finder's fee.
Terminology
[0167] A number of computing systems have been described throughout
this disclosure. The descriptions of these systems are not intended
to limit the teachings or applicability of this disclosure. For
example, the application host systems 404 described herein can
generally include any computing device(s), such as desktops,
laptops, servers, and distributed computing systems, to name a few.
As a second example, the user computing devices 402 can generally
include any computing device(s), such as desktops, laptops,
servers, video game platforms, television set-top boxes,
televisions (e.g., internet TVs), computerized appliances, and
wireless mobile devices (e.g. smart phones, PDAs, tablets,
electronic book readers, or the like), to name a few. Further, it
is possible for the user systems described herein to be different
types of devices, to include different applications, or to
otherwise be configured differently. In addition, the user systems
described herein can include any type of operating system ("OS").
For example, the mobile computing systems described herein can
implement an Android.TM. OS, a Windows.RTM. OS, a Mac.RTM. OS, a
Linux or Unix-based OS, or the like.
[0168] Further, the processing of the various components of the
illustrated systems can be distributed across multiple machines,
networks, and other computing resources. In addition, two or more
components of a system can be combined into fewer components. For
example, the various systems illustrated as part of the VO transfer
system 420 can be distributed across multiple computing systems, or
combined into a single computing system. Further, various
components of the illustrated systems can be implemented in one or
more virtual machines, rather than in dedicated computer hardware
systems. Likewise, the data repositories shown can represent
physical and/or logical data storage, including, for example,
storage area networks or other distributed storage systems.
Moreover, in some embodiments the connections between the
components shown represent possible paths of data flow, rather than
actual connections between hardware. While some examples of
possible connections are shown, any of the subset of the components
shown can communicate with any other subset of components in
various implementations.
[0169] Depending on the embodiment, certain acts, events, or
functions of any of the algorithms, methods, or processes described
herein can be performed in a different sequence, can be added,
merged, or left out altogether (e.g., not all described acts or
events are necessary for the practice of the algorithms). Moreover,
in certain embodiments, acts or events can be performed
concurrently, e.g., through multi-threaded processing, interrupt
processing, or multiple processors or processor cores or on other
parallel architectures, rather than sequentially. For example, the
blocks 1004, 1006, 1008, and 1010 of the process 1000 may all be
performed concurrently or may be performed sequentially in the
order as presented or in a different order. The methods disclosed
herein may be executed on the computing systems or devices in
response to execution of software instructions or other executable
code read from a tangible computer readable medium. A tangible
computer readable medium is a data storage device that can store
data that is readable by a computer system. Examples of computer
readable mediums include read-only memory, random-access memory,
other volatile or non-volatile memory devices, CD-ROMs, magnetic
tape, flash drives, and optical data storage devices.
[0170] Each of the various illustrated systems may be implemented
as a computing system that is programmed or configured to perform
the various functions described herein. The computing system may
include multiple distinct computers or computing devices (e.g.,
physical servers, workstations, storage arrays, etc.) that
communicate and interoperate over a network to perform the
described functions. Each such computing device typically includes
a processor (or multiple processors) that executes program
instructions or modules stored in a memory or other non-transitory
computer-readable storage medium. The various functions disclosed
herein may be embodied in such program instructions, although some
or all of the disclosed functions may alternatively be implemented
in application-specific circuitry (e.g., ASICs or FPGAs) of the
computer system. Where the computing system includes multiple
computing devices, these devices may, but need not, be co-located.
The results of the disclosed methods and tasks may be persistently
stored by transforming physical storage devices, such as solid
state memory chips and/or magnetic disks, into a different state.
Each process described may be implemented by one or more computing
devices, such as one or more physical servers programmed with
associated server code.
[0171] Conditional language used herein, such as, among others,
"can," "might," "may," "e.g.," and the like, unless specifically
stated otherwise, or otherwise understood within the context as
used, is generally intended to convey that certain embodiments
include, while other embodiments do not include, certain features,
elements and/or states. Thus, such conditional language is not
generally intended to imply that features, elements and/or states
are in any way required for one or more embodiments or that one or
more embodiments necessarily include logic for deciding, with or
without author input or prompting, whether these features, elements
and/or states are included or are to be performed in any particular
embodiment. The terms "comprising," "including," "having," and the
like are synonymous and are used inclusively, in an open-ended
fashion, and do not exclude additional elements, features, acts,
operations, and so forth. Also, the term "or" is used in its
inclusive sense (and not in its exclusive sense) so that when used,
for example, to connect a list of elements, the term "or" means
one, some, or all of the elements in the list. In addition, the
articles "a" and "an" are to be construed to mean "one or more" or
"at least one" unless specified otherwise.
[0172] Disjunctive language such as the phrase at least one of X,
Y, or Z," unless specifically stated otherwise, is otherwise
understood with the context as used in general to present that an
item, term, etc., may be either X, Y, or Z, or any combination
thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is
not generally intended to, and should not, imply that certain
embodiments require at least one of X, at least one of Y, or at
least one of Z to each be present.
[0173] While the above detailed description has shown, described,
and pointed out novel features as applied to various embodiments,
it will be understood that various omissions, substitutions, and
changes in the form and details of the devices or algorithms
illustrated can be made without departing from the spirit of the
disclosure. Thus, nothing in the foregoing description is intended
to imply that any particular feature, characteristic, step,
operation, module, or block is necessary or indispensable. As will
be recognized, the processes described herein can be embodied
within a form that does not provide all of the features and
benefits set forth herein, as some features can be used or
practiced separately from others. The scope of protection is
defined by the appended claims rather than by the foregoing
description. All changes which come within the meaning and range of
equivalency of the claims are to be embraced within their
scope.
* * * * *