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.

Description

INCORPORATION BY REFERENCE

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

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.

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

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

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.

FIG. 1 illustrates an embodiment of transferring virtual objects between applications.

FIG. 2 illustrates an embodiment of transferring virtual objects between applications with a variable conversion rate.

FIG. 3 illustrates an embodiment of unlocking skills/options in an application based on skills achieved in another application.

FIG. 4 illustrates an embodiment of a network environment for accessing applications and transferring virtual objects between the applications.

FIG. 5 presents a flowchart for an embodiment of a virtual object transfer process.

FIG. 6 presents a flowchart for an embodiment of a market rate virtual object conversion process.

FIG. 7 presents a flowchart for an embodiment of a shared virtual object conversion process.

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.

FIG. 9 presents a dataflow for an embodiment of a process for provisioning a converted virtual object to a second application.

FIG. 10 presents a flowchart for an embodiment of a virtual object transfer payment process.

DETAILED DESCRIPTION

Introduction

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.

Transferring Virtual Objects

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.

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.

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.

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.

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.

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.

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.

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.

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™ based device, the user may be directed to the GOOGLE PLAY™ 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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).

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.

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

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®), 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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.”

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.

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® 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.

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”.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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).

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.

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.

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

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.

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.

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.

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.

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

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.

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×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).

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×Y; if 3 users use the seeds, then N=N+Z or N=N×Z. In another variant, when user 1 uses the seeds, N=N; when user 2 uses the seeds, N=N×1.1, and optionally user 1 gets an additional N×0.1 (or N×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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.).

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).

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.

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.

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.

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.

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.

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).

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

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™ OS, a Windows® OS, a Mac® OS, a Linux or Unix-based OS, or the like.

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.

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.

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.

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.

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.

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.

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.