US20070202951A1

US20070202951A1 - Asset manipulation of computer games using a network

Info

Publication number: US20070202951A1
Application number: US10/715,350
Authority: US
Inventors: Matthew Bogosian; Chih-Yu Chow; Christopher Bogosian
Original assignee: Arena Unlimited Inc
Current assignee: Arena Unlimited Inc
Priority date: 2002-11-14
Filing date: 2003-11-14
Publication date: 2007-08-30

Abstract

Computer game asset (e.g., items and dynamic content) manipulation over a network is provided. Information about game items can be stored on a separate server and users can be allowed to execute transactions on the items outside the game environment. Transactions relating to dynamic content can also be performed. Item and dynamic content changes can be updated dynamically as games execute.

Description

The present application claims priority to U.S. Provisional Application No. 60/426,006, filed Nov. 14, 2002, U.S. Provisional Application No. 60/471,756, filed May 20, 2003, and U.S. Provisional Application No. 60/479,812, filed Jun. 18, 2003, all of which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

The present invention relates to the advancement and enhancement of digital gaming and novel applications of digital information over networks and methods for implementing and using such invention. More specifically, the invention relates to ways of manipulating assets (e.g., items and dynamic content) in computer games using a network.
The network ready gaming console and high performance wireless device markets, including personal digital assistants (PDAs) and handheld computers, are relatively nascent. Personal computers have had online gaming capabilities for some time, but, the communities and technologies available to and being developed for personal computers are not cohesive or universal.
Currently, online gaming communities are very limited. There are effectively four types of online gaming communities: 1) Those supported by the producers of the games themselves; 2) Simple, uncopyrighted gaming websites (these sites typically offer the ability to play commonly known and unowned games, such as poker, chess, pool, and the like, via web applications (e.g., Java embedded in a web page)); 3) Fantasy sports sites (in these sites one's gaming performance is based on the performance of actual (i.e., real life) players and teams); 4) Online casinos (gambling sites for monetary return).
In many computer games, users have the ability to acquire (e.g., a pistol) and create (e.g., crafting a sword) items in the game. Some games have mechanisms for users to trade or sell these items. However, these mechanisms within the game can be less than satisfactory. For example, an exchange of the item generally requires that the two users be logged into the game in order to execute the transfer of an item.
Other limitations of current games are that they do not support the transfer of items outside of and between different games. The acquiring and creation of items is typically limited to within the game itself.
Many games allow for advertising within in the game. Typically, the game developer programs the game to display the desired content to the user. The current mechanisms have met with limited success as, in order to change the content being displayed in a specific location, modifications to the game may be required. Additionally, many games have content that potentially could be dynamically controlled by a user. Unfortunately, there are no currently available mechanisms for allowing users and producers to easily create, sell, lease or otherwise manage dynamic content (e.g., advertising space) within a game. Accordingly, it would be desirable to have innovative mechanisms that allow users to manipulate computer game items outside of and between games over a network. Additionally, it would be beneficial to have mechanisms that allow users and producers to create and manage dynamic content within a game.

SUMMARY OF THE INVENTION

The present invention provides innovative mechanisms for manipulating assets in computer games over a network. In general, information about assets in one or more games is stored outside the game environment. The information can include attributes of the asset, ownership, conditions for a change in ownership, permissions, and the like. During execution, the game (or games) can access the information about the assets that is stored outside the game environment.
By storing information about the assets outside the game environment, users can more efficiently and flexibly trade, sell, loan, lease, etc. the assets. Additionally, assets are not limited to a single game and inter-game transactions can be realized. Some specific embodiments of the invention are described below.
In one embodiment, the invention provides a method for storing information about assets outside a game environment. An application programming interface (API) is provided that allows information about assets to be stored outside the game environment. A game is provided that calls the API in order to store information about the assets. During execution of the game, information is stored about the assets outside the game environment. Typically, the assets are items or dynamic content.
In another embodiment, the invention provides a method for changing ownership of an asset outside a game environment. An offer from a first user is displayed for changing ownership of an item. An acceptance of one or more conditions specified in the offer is received from a second user. Upon acceptance of the one or more conditions, the ownership of the item is changed to the second user outside the game environment.
In another embodiment, the invention provides a method of lending or borrowing items without changing ownership. An offer from a first user to loan or borrow an item without changing ownership is displayed. An acceptance of one or more conditions specified in the offer is received from a second user. Upon acceptance of the one or more conditions, allowing the use of the item by a borrower, where the borrower is the first user if the offer was to borrow or the second user if the offer was to lend. The offer can also be a lease with a periodic payment amount as a condition.
In another embodiment, the invention provides a method of dynamically changing content in a game over a network. Content to be presented in the game that can be changed over a network is defined, where the content is stored in data structures maintained by a server that is not executing a game that presents the content. The content to be presented in the game is transmitted over a network to the game. The game presents the content so that the content is dynamically changed
In another embodiment, the invention provides a method of allowing access to dynamic content in a computer game. An offer from a first user is displayed for use of the dynamic content. An acceptance of one or more conditions in the offer is received from a second user. Upon acceptance of the one or more conditions, the second user obtains use of the dynamic content. Use of the dynamic content can include the ability to define and change the dynamic content. Dynamic content can be an image, a sound, an item, or any combination of these, including advertising.
With embodiments of the invention, transactions regarding assets (and any change in the data structures associated with the assets) can occur outside the game environment (e.g., separately from the game that utilizes the assets). This means that the game does not need to be executing (nor does the user have to be logged in depending on the game) for the transaction to occur. In some embodiments information about assets are stored on an asset server that is separate from the game server. In other embodiments, the game server can implement this functionality while it is still outside the game environment.
Aspects of the invention provide for the integration of digital information with a platform that utilizes and builds upon that information to create a digital virtual world that seamlessly interfaces with the real world. This platform can be used by a variety of users to extend their capabilities past that of the real world and into the virtual world while the repercussions of those actions within the virtual world extend into the real world and real life of any such user.
Other features and advantages of the invention will become readily apparent upon review of the following description in association with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a blocked diagram of an embodiment within a central server gaming system.
FIG. 2 shows a blocked diagram of an embodiment in a peer-to-peer gaming system.
FIG. 3 shows a block diagram of one embodiment of the invention.
FIG. 4 illustrates components that may be present in devices and computer systems that implement the invention.
FIG. 5 shows a flowchart of a process of changing the ownership of an item outside the game environment.
FIG. 6 shows a flowchart of another process of changing ownership of an item.
FIGS. 7A-7D illustrates data structures that can be utilized to facilitate the transaction shown in FIG. 6.
FIG. 8 shows a flowchart of a process of obtaining the use of dynamic content in a game.
FIG. 9 shows a flowchart of a process of selling the use of dynamic content.
FIG. 10 shows a flowchart of a process granting exclusive access to an asset during game play.
FIGS. 11A and 11B show flowcharts that can be utilized for a multi-person transaction.
FIG. 12 shows a block diagram illustrating a system where a content producer generates assets outside the game environment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the description that follows, the present invention will be described in reference to embodiments that allow for asset manipulation in computer games over a network. More specifically, the embodiments will be described in reference to preferred embodiments. However, embodiments of the invention are not limited to any particular configuration, architecture, or specific implementation. Therefore, the description of the embodiments that follows is for purposes of illustration and not limitation.
FIG. 1 shows a block diagram of an embodiment of the invention in a central server gaming system. Client 1 interacts through network 3 with a game server 5. The client can be gamers or games. Network 3, like all network representations shown herein, can be any network media that allows network devices to communicate.
Game server 5 is the computer system that is responsible for operation of one or more games. Although shown as a single server, the game server can utilize multiple computer systems.
Game server 5 communicates through network 7 with an asset server that can implement embodiments of the invention. Asset server 9 can store items for game server 5, facilitate the use of dynamic content within a game, allow multi-person transactions, allow content producers to generate items, and other features, as will be described in more detail below. Typically, the asset server is not executing a game, but communicates with games, gamers, advertisers, content producers, and the like.
Asset server 9 communicates through network 11 to clients 13. Clients 13 can be content producers, advertisers, garners and the like.
The central gaming system shown in FIG. 1 is illustrative of games where a central server is executing one or more games. For example, the games can be interacting sports games, online fantasy games, casino games, and the like. The games run on game server 5 can be transient, meaning that the game has a definite start and finish or persistent meaning that the game is always running (unless down for updates or maintenance).
FIG. 2 shows a block diagram of a peer-to-peer gaming system. Clients 51 interact through network 53 with each other and with an asset server 55. Clients 51 can be garners or games. Typically, there is at least one game and at least one gamer. However, a single client system can execute a game, run the environment for a gamer and/or any combination of one or more of each.
Asset server 55 can perform the similar features provided by asset server 9 of FIG. 1, just in a peer-to-peer gaming network. Asset server 55 communicates through network 57 to client 59. Clients 59 can be content producers, advertisers, and the like.
The peer-to-peer gaming system shown in FIG. 2 differs from FIG. 1 in that one or the clients hosts the game or games. Typically, the games in a peer-to-peer gaming system are transient, but the games could be of persistent nature if so designed.
Now that representative systems have been described, it may be beneficial to describe further details on the asset server in some embodiments. FIG. 3 shows a block diagram of the asset server. Asset server 101 interacts with clients or servers 103. Clients or servers 103 represent what can be gamers, games, game servers, game developers, content producers, publishers, marketing agencies, advertisers, and the like.
Asset server 101 includes a user interface 105, which in some embodiments is accessed through a web browser or the game itself. User interface 105 can be utilized by gamers, content producers, advertisers, and the like. However, for the gamer, the user interface creates a community for multiple games.
The most commonly available user interface is a World Wide Web site. This allows people to access the community site using their personal computers and Internet Web browsers (e.g., Netscape, Mozilla, AOL, Internet Explorer, etc.). Other user interfaces can be provided by the asset server which can be embedded directly in the games themselves. Using these user interfaces, people can access the community site and its functionality from within a game itself.
The community site is where the gamer's identity exists. All data about the gamer can be kept and maintained on the community site (e.g., what games have been played, how many have been won, credit balance, how much has been spent and on what, sponsor information, the terms of any formal relationships with sponsors or other gamers, and billing information). The community site has a user interface by which its users can affect data and relationships of the community. This user interface can be accessible via several means (e.g., WAP, WWW, etc.) and provides the means by which a user can take certain actions (e.g., change billing information, enroll in a tournament, purchase credits, define the terms of sponsorship and sponsor another gamer, track high scores of other users, challenge another user to play, redeem credits for prizes, develop characters, buy and sell virtual goods in the virtual marketplace, watch a tournament in progress, etc.).
These actions affect the community and define the context under which the games are played. The community is persistent. This means that characters (i.e., gamers' alter egos) are not fleeting, but rather they are permanent entities in the virtual world (just as are their real world counterparts). Because they persist, history may be established. Gamers may rise to and fall from glory, gain and lose sponsorships, just like sports figures of the real world. The community site is what maintains this world and records its history.
The underlying concept of the community aspect of the invention is to provide for the ability for the concept of a character and his/her game-worldly possessions to exist outside of and beyond the game. In fact, it allows those possessions to operate seamlessly in multiple game environments (e.g., a character who has a car in one game might also be able to use it in another game) should the content producers allow it. Such other features and functionality include but are not limited to virtual currency, virtual assets, a virtual marketplace, real world partnerships, real world payoffs, real world advertising, real world visibility, content on demand, and virtual world data management and storage.
Returning to FIG. 3, asset server 101 also includes a database 107 that can utilized to store information about items and/or dynamic content outside the game environment. Further details of exemplary embodiments of the database will be described below in reference to FIGS. 7A-7D.
Additionally, asset server 101 is shown to include marketplace 109. Marketplace 109 facilitates transactions regarding items in one or more games. Dynamic content manager 111 is also shown in asset server 101 and can be utilized to manage dynamic content such as advertising space that is utilized during game play.
The clients, servers and asset servers can be any form of computing device ranging from handheld devices to main frames. Typically, the servers posses more processing power than the clients but all may share common components.
FIG. 4 shows a block diagram of components that can be present in clients, server and client/server systems. A central processing unit (CPU) bus 151 allows the various components of the computing device to communicate. A CPU 153 executes instructions or computer code which can be stored in a memory subsystem 155. Memory subsystem 155 represents what is typically volatile memory.
A display subsystem 157 is responsible for displaying information, images or text to users. A sound subsystem 159 is responsible for generating sound and may include one or more speakers. A network subsystem 161 allows that computing device or computer system to communicate over a network.
A storage subsystem 163 is responsible for nonvolatile storage of computer code and data. Representative storage media include a hard drive 165, a floppy drive 167, a CD-ROM or DVD-ROM drive 169, or a solid state storage 171.
Handheld computing devices through more powerful servers typically include many of the components shown in FIG. 4. However, additional or fewer components may exist in any individual device. Nevertheless, FIG. 4 is fairly representative.
In one aspect of the invention, an application programming interface (API) is provided that can be called by games that are executing or running. The API can provide many services including allowing information about assets to be stored outside the game environment. A game is provided (or generated) that calls the API in order to store information about the assets. During execution of the game, information is stored about the assets outside the game environment. As described above, an asset server can store this information in a database that is stored separate from the game server.
By exposing an API by which game designers can include the features of a virtual gaming community, any game can become part of this multi-game community by utilizing the API. If the community site is analogous to the televised events and newspapers through which we follow our favorite heroes, then the game itself is the track or stadium or field in which they compete. The API allows the two to be linked and the games enable the contest. The game developer uses the API to connect the single game session with the community, giving the single session meaning within a larger context.
The API can include secure methods for the authentication and authorization of garners and can expose other behaviors of the community site (e.g., record and publish game results). Any game developer can have a community game by using the API.
The API can be accessible via the Internet and can be made available using modern remote procedure call protocols (e.g., SOAP, XML-RPC, CORBA, etc.). Support for additional protocols can be added according to developer demand. The system is flexible enough to allow game developers to easily register new games and game item types on the system without requiring that the system be reimplemented for each new game.
In some embodiments, a data model and set of tools is developed by which game developers can easily add new games and define new game item types to the system. Game item types can be designed with an arbitrary number of game-specific properties. The community site is unaware of the significance of these properties. For example, when designing a car type, a game developer may decide that an attribute of the car may be “weight in kilograms.” The developer is free to define the attribute, and to which game item type it belongs. This attribute is sent to the game when requested, where it has its significance.
Moving from a description of representative hardware and interfaces, FIG. 5 shows a flowchart of a process of changing ownership of an item. As with all flowcharts shown herein, steps can be added, deleted, combined, and reordered without departing from the spirit and scope of the invention.
At a step 201, an offer from a first user is displayed for changing ownership of an item. In one embodiment, the offer can be searched for in a marketplace and then the terms of the offer for the item are displayed. The marketplace can provide users with many advantageous search tools in order to locate items of interest.
The offer that is displayed will include one or more conditions that must be satisfied in order to change ownership of the item. The conditions can vary on the type of transaction that the offer represents. The following will describe various transactions and illustrate representative conditions to which they can be associated.
The offer can specify the sale of an item. This transaction can be a fairly simple transaction where the condition of the sale is a price in a specified amount of currency.
The offer can specify a trade, where a condition to be met is an item that is to be traded. Not all trades are of even-valued items, therefore other conditions can specify additional items for trade and/or currency as further conditions of the trade.
The offer can specify an auction for the item, as an auction the condition may specify the date of the auction with an underlying condition that the winner be the highest bid. Additionally, other conditions can be a minimum bid (or reserve) for the auction, a favorable rating for the person winning the auction, and the like.
The offer may represent a loan of the item. A condition of the loan may be the duration of the loan, which may be specified as a unit of time or any other type of measurement. At the end of the duration of the loan, ownership can automatically revert to the original owner. The owner can also specify one or more limitations on the borrower to effect the item. Similarly, the offer may represent an offer to borrow an item.
Other types of offers can include leases and leases to own, where conditions specify lease duration, periodic payment amount, and potentially conditions that affect a permanent transfer of ownership. As can be seen, the type of transaction and the accompanying conditions vary greatly depending upon the arrangement the owner of the item wishes to create.
Returning back to FIG. 5, an acceptance of the one or more conditions in the offer is received from a second user at a step 203. The one or more conditions that are accepted will depend on the specific offer.
Upon acceptance of the one or more conditions, the ownership of the item changes to the second user outside the game environment at a step 205. In this manner, the offer represents a true offer since it can be accepted and the transaction executes immediately.
Although many games allow users limited capability to execute transactions to change the ownership of items, they typically require that each user be currently playing the game and possibly meet at an agreed upon location. Information about items, including ownership, can be stored outside the game environment on an asset server. This provides numerous advantages including that in which users do not have to be in the game environment in order to execute transactions regarding items usable within the game. Additionally, this allows items to be moved between games. For example, an item can have certain characteristics in one game and similar (or different) characteristics in another game. Embodiments of the invention allow items to move thorough transactions between different games.
FIG. 6 shows a flowchart of a process of executing a transaction for an item. At a step 251, user 1 acquires item A. Item A can be acquired any number of ways including being found, bought, manufactured, and the like. As will be described below, information about the items can be stored in tables on the asset server.
At a step 253, user 1 defines terms A of a transaction for item A. Thus, the transaction terms or conditions specify under what circumstances ownership of the item will be changed. For example, in a very simple case, the condition could be the amount of currency that would be required to buy the item.
FIG. 7A illustrates exemplary data structures that can be utilized to store information about items on the asset server. Asset server 301 stores information about items in one or more tables such as an items table 303. Items table 303 as shown indicates that item A is owned by user 1. The tables can include different and additional fields so the tables that are shown herein are for illustrative purposes.
Asset server 301 receives a message 305 that specify the terms of the transaction for item A. Asset server 301 processes the message and adds the terms or conditions for the transaction to a terms table 307 as shown in FIG. 7B.
Returning now to FIG. 6, user 2 discovers items A with terms A. User 2 can discover this many ways but typically will be done using search functions through a marketplace. If user 2 finds the terms acceptable, user 2 agrees to terms A at a step 257. Once the terms are accepted, the transaction executes at a step 259. Typically, the asset server also verifies the conditions are met before the transaction executes.
FIGS. 7C and 7D illustrate how acceptance of the terms and the transaction executing can change the associated data structures. As shown in FIG. 7C, asset server 301 receives a message 309 that indicates that user 2 agreed to terms A.
Asset server 301 processes message 309 and generates a transaction table 311. Transaction tables 311 stores the users that are involved, the item and references a terms table 307 that specifies the terms of the transactions. These data structures can remain as a record of the transaction that transpired.
Asset server 301 then updates items table 303 to indicate that user 2 is now the owner of item A. Notifications 313 are then sent to user 1 and user 2 that the transaction has completed.
In some transactions, the ownership of the item will not change so items table 303 could remain unchanged. For example, a loan can be implemented without changing ownership of the item. In some embodiments, the items table can store not only the ownership, but also possession. Additionally, FIGS. 6 and 7A-7D have been described in reference to a transaction that changes ownership of an item. A similar process can be utilized when a user desires to sell or lease access to dynamic content in the game.
Aspects of the present invention enable sponsorship in the gaming world. With the existence of an economy in the virtual world and the assignment of value to assets necessary for game play and competitiveness the ability to acquire assets is crucial to a gamer's success. As in real life, a gamer may put forth their own capital or attract sponsors to supply the capital in exchange for advertising rights among other things as determined by the details of any deal or contract between the individual and the sponsor. Sponsors may also sponsor series and individual events among other things for, but not limited to, advertising rights and advertising space as determined by the details of any deal or contract between the event or series producer and the advertiser or sponsor.
Although many games include advertising within the game, typically, advertising is hard coded into the computer game making dynamic changes to the ad showing on the ad space very nearly impossible. Additionally, users or gamers can also have their own advertising space. For example, in a car racing game, each car could include dynamic space such as advertising portions or space on the car.
With embodiments of the invention, the use of space, sound, and items in a game can be more efficiently used as dynamic content and hence become opportunities for advertisement and product placement. Space, images, sound, items, etc. in the game can be dynamically updated without requiring modification of the game and users can sell or lease the dynamic content that they own.
FIG. 8 shows a flowchart of a process of selling or leasing dynamic content. At a step 351, an offer from a first user for advertising space is displayed. Typically, the offer will include one or more conditions that must be met for another user to gain access to the dynamic content.
An acceptance of the one or more conditions in the offer is received from a second user at a step 353. Upon acceptance of the one or more conditions the second user is allowed to use the dynamic content at a step 355.
Information about dynamic content can be stored in tables or any another data structure by the asset server. Thus, tables similar to FIGS. 7A-7D can be utilized in association with FIG. 9 that shows a flowchart of a process of a transaction relating to dynamic content.
At a step 401, user 1 defines dynamic content A. User 1 can be the game designer, content producer or gamer. In the case of the gamer, the gamer may not define the dynamic content but instead may acquire it by some other mechanism including buying it, creating it, acquiring an item that includes dynamic content, and the like.
User 1 defines term A of the transaction for ad space A at a step 403. Accordingly, user 1 specifies one or more terms or conditions that when satisfied will fulfill the transaction for the ad space A.
At a step 405, user 2 discovers space A with terms A. User 2 can discover this information through the use of search capabilities in a marketplace.
At a step 407, user 2 agrees to terms A. The asset server can verify the terms are met and the transaction executes at a step 409. The transaction itself can be any kind of transaction including lease, sale, lease-to-own, auction, trade, loan, and the like.
The above has described a transaction relating to dynamic content. Embodiments of the invention can also provide dynamically changing content in a game over a network. Content to be presented in the game that can be changed over a network is defined, where the content is stored in data structures maintained by a server that is not executing a game that presents the content. The content to be presented in the game is transmitted over a network to the game. The game presents the content so that the content is dynamically changed. The content can have a specific purpose or can be presented in a specific space, at a specific time, or as a result of a specific action or event in the game.
In dealing with transactions of assets, some embodiments of the invention implement an inclusive lock on an asset during game play where the asset is subject to a transaction. FIG. 10 shows a flowchart of a process of granting exclusive access to an asset during game play.
At a step 451, the game requests and exclusive lock for an asset from the server. The server is typically the asset server, but in other embodiments a different server including the game server can be utilized for this purpose.
It is determined at a step 453 whether the server allowed the exclusive lock. The exclusive lock should be granted if the asset was not already locked by another entity, game, transaction, trade, and the like.
If an exclusive lock could not be acquired, the game can display an error for the gamer at a step 455. Otherwise, it can be determined if the game needs access to another asset at a step 457. If yes, the game requests an exclusive lock for that asset at step 451.
If the game does not need access to another asset, the game uses the one or more assets and updates their states on the server at a step 459. As mentioned above, the information about the assets, including their locked or unlocked states, can be stored in data structures that are maintained by the asset server.
At a step 461, it is determined whether the game is finished using an asset. If the game is finished with an asset, the game relinquishes the lock on the asset on the server at a step 463. Alternatively, locks can be granted for a specified amount of time which if not relinquished will expire automatically. At a step 465, it is determined whether the game needs access to another asset.
The process shown in FIG. 10 can be utilized to lock assets so that they cannot be utilized while they are subject a transaction. This can be utilized to prevent such things as multiple transactions relating to the same asset and/or use of the asset while a transaction is pending for the asset.
Embodiments of the invention also provide the capability to have secure multi-person transactions. FIGS. 11A and 11B illustrate a process that can be followed for these transactions. FIG. 11A represents the process of the first person that is starting the transaction and FIG. 11B represents the process for any subsequent people.
With regard to FIG. 11, at a step 501, a user creates a transaction and defines initial terms for the transaction. It is then determined if there are any additional terms which need to be defined or whether any existing terms need to be modified at a step 503.
If changes to the terms for the transaction are desired, the user refines the terms for the transaction at a step 505. As will be made more clear, the processes in FIGS. 11A and 11B are iterative processes. In general, whenever a user modifies terms of a transaction, the acceptance of the changed terms of the transaction are revoked so that each user has to explicitly accept the new (and potentially final) terms of the transaction.
At a step 507 it is determined whether the server was able to establish the new terms and exclusively lock the relevant items. If not, the server indicates to the user which items were unable to be locked at a step 509. Additionally, the server may indicate the reason why the lock could not be obtained.
If the terms have been changed to the user's satisfaction, the server revokes any existing approvals of the terms at a step 511 since the terms of the transaction have changed. If there are no more additional changes to the terms, the user approves the transaction at a step 513. It is then determined at a step 515 whether the terms approved by the user where the same terms that are currently stored by the server in the data base.
If the terms that were approved were subsequently changed, the server indicates to the user that the terms have changed at a step 517. Subsequently, the approval of the terms will be revoked as shown.
At a step 519 it is determined if all the participants to the transaction have approved the transaction. If not, it is determined at a step 521 whether the user's approval of the terms has been revoked. If yes, the negotiation process can continue once again at step 503. Otherwise, the user is waiting for all participants to approve the transaction.
Once all the participants to the transaction have approved the transaction and the process has ensured that the terms that they approved are the current terms, the terms of the transaction are executed at a step 521. Executing the transaction can include updating data structures that are stored by the asset server with respect to the items, ownership, ad space, terms of the transactions, participants of the transaction, and the like.
FIG. 11B shows the process for the second and subsequent participants in a multi-person transaction. At a step 551, a user identifies a transaction to participant. For example, the user could identify a multi-person trade transaction that is displayed in a marketplace. Once the user identifies the transaction, the second and subsequent users proceed in the same process as the user that initiates the transaction. Thus, starting at step 503 the second and subsequent multi-person transaction follow the same process as described starting at step 503 in FIG. 11A.
In many existing games, it is the content developer who is responsible for generating assets. The content producer can specify how assets are acquired or can be created by users within the game. With one aspect of the invention, content producers can indicate conditions in which the asset server can generate an asset. FIG. 12 shows a blocked diagram where the asset server creates an asset under terms or conditions specified by the content producer.
FIG. 12 shows a content producer 601 in communication with an asset server 603. A user 605 and a game device 607 are shown in communication with asset server 603. For simplicity, many of the other potential elements of the system are not shown but they can be seen in reference to FIGS. 1-3.
Content producer 601 contacts asset server 603 and specifies conditions, that once met, will allow creation of an asset. Once asset server 603 has the conditions for creating an asset, gamer 605 can contact asset server 603 and evaluate the conditions for creating an asset.
If the gamer accepts the offer and fulfills the conditions, the asset server 603 can generate the asset and store the asset in a database specifying that the new asset belongs to gamer 605. Once the transaction is complete, the asset can be manipulated in any way that is allowed by the game or through asset server 603. In other words, from the gamer's point of view, the newly created asset is no different than any other asset.
By allowing a content producer to specify conditions upon which new assets can be created, game developers can create an additional market for these assets where none has exited previously.
While the above is a complete description of preferred embodiments of the invention, various alternatives, modifications, and equivalents can be used. It should be evident that the invention is equally applicable by making appropriate modifications to the embodiments described. Therefore, the above description should be taken as limiting the scope of the invention that is defined by the metes and bounds of the appended claims along with their full scope of equivalents.

Claims

1. A method of changing ownership of items outside a game environment, comprising:

displaying an offer from a first user for changing ownership of an item, wherein the offer specifies one or more conditions;

receiving an acceptance of the one or more conditions in the offer from a second user, wherein one of the first user and the second user is an owner of the item; and

upon acceptance of the one or more conditions, changing the ownership of the item from the owner to the other of the first user and the second user outside the game environment.

2. The method of claim 1, further comprising storing information about the item in data structures maintained separately from the game that utilizes the item.

3. The method of claim 1, further comprising determining if the item is already subject to another offer.

4. The method of claim 3, further comprising informing the owner that the item is already subject to another offer.

5. The method of claim 1, wherein the offer is a sale, trade, or auction, loan, or lease.

6. The method of claim 1, wherein the offer is a sale.

7. The method of claim 6, further comprising receiving a price for the item as a condition.

8. The method of claim 1, wherein the offer is a trade.

9. The method of claim 8, further comprising receiving identification of one or more items for the trade as a condition.

10. The method of claim 1, wherein the offer is an auction.

11. The method of claim 10, further comprising receiving information regarding the auction as a condition.

12. The method of claim 2, further comprising storing information about the item on an asset server separate from a client or server executing the game that utilizes the item.

13. The method of claim 12, further comprising providing an API, wherein the API is called by the client or server executing the game that utilizes the item.

14. The method of claim 12, further comprising creating an exclusive lock on the item upon request from the client or server executing the game.

15. The method of claim 2, wherein storing information includes storing information defining the owner of the item.

16. The method of claim 2, wherein storing information includes storing information defining the terms of a transaction for the item.

17. The method of claim 14, wherein storing information includes storing the locked or unlocked state of the item.

18. A method of changing possession of items outside a game environment without changing ownership, comprising:

displaying an offer from a first user to loan or borrow an item without changing ownership, wherein the offer specifies one or more conditions;

upon acceptance of the one or more conditions, allowing use of the item by a borrower, wherein the borrower is the first user if the offer was to borrow or the second user if the offer was to lend.

19. The method of claim 18, further comprising storing information about the item in data structures maintained separately from the game that utilizes the item.

20. The method of claim 18, further comprising determining if the item is already subject to another offer.

21. The method of claim 20, further comprising informing the first owner that the item is already subject to another offer.

22. The method of claim 18, wherein a limitation on the borrower to effect the item is specified.

23. The method of claim 18, wherein the offer is a loan.

24. The method of claim 23, further comprising receiving a duration of the loan as a condition.

25. The method of claim 24, further comprising changing the possession of the item to the owner outside the game environment when the duration of the loan expires.

26. The method of claim 18, wherein the offer is a lease.

27. The method of claim 26, further comprising receiving a duration of the lease as a condition.

28. The method of claim 26, further comprising receiving a periodic payment amount of the lease as a condition.

29-44. (canceled)

45. The method of claim 19, further comprising storing information about the item on an asset server separate from a client or server executing the game that utilizes the item.

46. The method of claim 45, further comprising providing an API, wherein the API is called by the client or server executing the game that utilizes the item.

47. The method of claim 45, further comprising creating an exclusive lock on the item upon request from the client or server executing the game.

48. The method of claim 19, wherein storing information includes storing information defining the owner of the item.

49. The method of claim 19, wherein storing information includes storing information defining the terms of a transaction for the item.

50. The method of claim 47, wherein storing information includes storing the locked or unlocked state of the item.