Methods and System for Creating In Game Objects

Abstract

The present disclosure provides various novel concepts to a video game environment. The disclosure describes video game environments that include a method and system for importing, assembling and creating objects in a virtual environment for use in the virtual environment based on the ideas of the players.

Description

PRIORITY CLAIM

The following application is a continuation-in-part of U.S. patent application Ser. Nos. 11/428,263, “Video Game Environment” filed Jun. 30, 2006 and Ser. No. 11/620,563 “Copyright of Digital Works in a Virtual Environment” filed Jan. 5, 2007, each of which is hereby incorporated by reference.

BACKGROUND

Video games which are accessible to multiple players via a server or peer to peer network are well known. For example, hundreds of thousands of players access games known as massive multi-player online games (MMOGs) and massive multi-player online role playing games (MMORPGs). Players of these games customarily access a game repeatedly (for durations typically ranging from a few minutes to several days) over a given period of time, which may be days, weeks, months or even years. The games are often constructed such that players pay a periodic subscription price (e.g., $15 per month) rather than, or in addition to, paying a one time purchase price for the game. Often, though not necessarily, these games have no ultimate “winner” or “winning goal,” but instead attempt to create an enjoyable playing environment and a strong player community.

It would be advantageous to provide improved methods and apparatus for increasing the enjoyment and/or longevity of video games including, but not necessarily limited to MMOGs and MMORPGs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a network according to an embodiment of the present disclosure.

FIG. 2 is a block diagram of system 100 according to an embodiment of the present disclosure.

FIG. 3 is a block diagram of a system 200 according to an embodiment of the invention.

FIG. 4 is an embodiment of a method of determining the requirements for assembling an object.

FIG. 5 is a block diagram of a system 300 according to an embodiment of the invention.

FIG. 6 is a block diagram of a system 400 according to an embodiment of the invention.

FIG. 7 is an embodiment of a method of hiring an entity to construct an in game object according to an embodiment of the invention.

FIG. 8 is a block diagram of a system 500 according to an embodiment of the invention.

DETAILED DESCRIPTION

Definitions:

Unless stated to the contrary, for the purposes of the present disclosure, the following terms shall include the following definitions:

Credit Card—includes a credit instrument issued by a real or virtual world institution to a player or player character that allows the player or player character to make purchases by providing an account identifier (e.g. a credit card number) rather than real or virtual cash or other currency. An example is a credit card like those issued by Visa, MasterCard, or American Express. For the purposes of the present disclosure, the term “Credit card” is intended in a very broad sense and is not limited to those situations in which a player's purchases are made on credit (i.e. where payments for those purchases is not due until a later time) but also includes financial instruments such as debit cards, check cards, lines of credit and the like.

Virtual credit card—includes a credit card or other financial instrument issued or used in a virtual environment that acts in the virtual environment for virtual currency similar to the way a real world credit card acts in the real world for real currency. Virtual credit card also includes the use of a real world credit card for purchases, loans, security, identification, collateral, currency conversion and any other financial transactions within the virtual world.

Real Cash Value includes the value in real dollars one or more virtual currencies. This value can be determined by any applicable means, including, for example, multiplying the value of a virtual currency amount by the current exchange rate to real dollars. Such conversion may include a tax, tariff or other conversion fees or penalties.

Total virtual obligation amount—includes the total amount of the virtual financial obligation(s) associated with a player or player character's account. Such amounts may be comprised of several individual amounts or accounts and may have a real currency amount equivalent.

Virtual Contract—includes an agreement, which may be enforceable, between one or more first player or player characters and either another one or more players or player characters, and/or one or more of a game server, a real or virtual financial institution or business, an NPC, or a third party. Some examples of virtual contracts are provided in U.S. Provisional Patent Application Ser. No. 60/652,036, which is hereby incorporated by reference in its entirety for all purposes.

Game environment manager: includes any entity that administers a game environment. The game environment manager may be a character, player, player character, group of characters, group of players, one or more NPCs, group of NPCs, committee, company, religion, government, financial institution, outsourcing services company, any third party, or any combination thereof.

Virtual—shall include one or more video game environments, video game space (in whole or in part), non-physical item, object, character, or other intangible item or space.

Virtual World—includes any one or more of any space, visual representation, world, environment or software, or tracking or game application created in an online game such as World of Warcraft, or a virtual community such as Second Life, Eve or There.com. Virtual World may also include any virtual or intangible area of game play, such as an island or continent or globe or universe, or one, two, three or more dimensional area, or any combination or groups or categories or subcategories of the forgoing. Such areas may be presented on a screen in one or more dimensions, or as icons, pictures, maps, images, video, and/or may include black or dark areas, or areas with color.

Virtual Creditor—includes any one or more real or virtual game owner, financial institution, or a first player or player character or other entity or any person or virtual entity or third party, who is owed a virtual obligation by a second player or player character. Virtual Creditor may include a real world financial institution, for example, Wachovia Visa, that offers real or virtual credit cards or other financial means in a video game or Virtual World.

Virtual Credit Score—includes a score given to a player and/or player characters in a video game or virtual world or by a virtual creditor based on one or more of the following criteria including, but not limited to: part or all of the virtual assets they possess, the age of the character account, the type of account, e.g. basic or premium, the available credit line of the real or virtual credit card associated with the account, the existing real or virtual financial obligations of the player character account, the player or player character's payment history including days to pay, amounts overdue or delinquent, and/or the player character's real world credit score, and/or the factors used in the real world to determine a credit score, and/or any other attribute or financial or other information associated with the player or player character.

Virtual Financial Account—includes a virtual account issued to a player character by a real or virtual bank, real or virtual creditor, game server, game owner, in game lending institution or third party where real or virtual cash can be exchanged, bought, sold, deposited and/or withdrawn.

Virtual Financial Obligation—includes an agreement made and/or entered into and/or purchase made by one or more of any real or virtual: player or player character or entity to pay or otherwise deliver or provide one or more game attributes or items to another player or player character, entity, exchange, business or game server or other third party. This obligation can be a one time payment, or multiple payments over time. The obligation can specify that payments are due on virtual or real dates. Such obligation may also include additional legal terms and conditions, including, but not limited to: payment terms, due dates, finance charges, interest payments, late payments or other fees, tariffs and charges, early payment or other penalties, exchange rate fees and may require a real or virtual credit card to serve as part or complete security, e.g., collateral, on such obligation.

Virtual Financial Intermediary—Financial intermediaries include, for example, real or virtual: financial institutions including depository institutions, creditors, contractual savings institutions, and investment intermediaries which may offer financial products and services for use within the virtual environment. The various virtual financial intermediaries available in the virtual environment may each serve different or overlapping purposes and provide means for using, saving, borrowing and transferring currency. In certain cases, real world financial intermediaries offer such services outside the virtual environment and may permit real or virtual cash or other items of value to be transferred or exchanged with or within the virtual environment.

Virtual Financial Obligation Value—includes the in game value of the obligation. For virtual cash the value may be stated as a virtual and/or real cash amount, which may be in one or more real or virtual currency types, e.g., US Dollars and Linden Dollars. For other game attributes, the value can be determined, for example, by generating a virtual cash market value for the item based on the current value in an online marketplace or exchange. The value of the obligation may be fixed or variable and may also be set as a condition of the player contract and/or by the game server or other entity. Such obligation may also include additional legal terms and conditions, including, but not limited to: payment terms, due dates, finance charges, interest payments, late payments or other fees, tariffs and charges, early payment or other penalties, exchange rate fees and may require a real or virtual credit card to serve as part or complete security, e.g., collateral, on such obligation.

Billing Information—shall include any information pertaining to billing a player or player character and/or any other party for playing a game, accessing a game, providing or offering for sale or purchasing goods or services, or any other reasons. Billing information may include, but is not limited to, such real world or virtual information as a home or billing address, social security number, credit card account number, bank account number, pay pal account number or other payment facilitator, or the account number of any other financial entity providing a real world credit line or any other payment-related information.

Virtual Blueprints—includes virtual designs or instructions to enable creation of a design for one or more virtual items that may include information such as dimensions, materials, skills, method of construction, legal ownership rights, licenses or permissions, or required licenses or permits, and/or other virtual items or attributes that are required to assemble or use a virtual item specified by the blueprint. Virtual Blueprints may define virtual objects, and/or business methods, business processes, software, games, and/or definitions to create any or all of the foregoing.

Character or “player character”—includes a persona created and controlled by a player in a video game. Character or player character may also include an account associated with a player that identifies a persona or avatar owned, created or controlled by a player in a video game or other virtual environment or virtual world. Such account may include billing information, or other information about the player or the player character, such as current status, items owned or controlled, skill levels or other attributes.

Avatar—includes the virtual or visual representation of a player character. An avatar may be an icon, picture, image, token, video, or other representation of a player character.

Character Account—includes an account or records that stores or tracks information regarding player characters, including, but not limited to any one or more, or any combination of any real or virtual: character attributes, billing information, character skills, financial obligations, and/or any other information associated with the player character or the virtual environment or virtual world.

Character Attribute—includes any quality, trait, feature or characteristic a particular Character can have that is stored in the corresponding Character Account. Character Attributes may include, but are not be limited to:

• • 1. A character score
  • 2. A virtual object
  • 3. The physical appearance of a character
  • 4. An emblem or mark
  • 5. A synthetic or recorded voice
  • 6. Virtual currency
  • 7. Virtual help points or credits
  • 8. The ability to join groups of other players at a later time
  • 9. A score for subsequent matching of later game parameters
  • 10. A relationship with another character
  • 11. A genetic profile or makeup
  • 12. A skill or skill level
  • 13. A ranking
  • 14. A video
  • 15. Experience information

Character Life—includes a fixed or variable, finite or infinite period of virtual or real world time that a player character can exist in a game environment or a virtual world or an era or other period of time.

Character Skills—includes game attributes inherent in or otherwise bought, sold, exchanged, used, acquired or developed by a player or player character before or during game play such as, but not limited to: the ability to cast (certain) spells, foretell the future, read minds, use (certain) weapons, cook, hunt, find herbs, assemble herbs into potions, mine, assemble objects into other objects, fly, organize players, create, buy, sell, exchange or steal attributes or other items, establish or purchase or exchange businesses, communicate, and/or enchant other player characters and/or any other information that describes, tracks, controls, limits, permits, records, or is related to an ability of one or more players or player characters or NPCs or third parties.

Computer Generated (CGC) or Non-Player (NPC) Character—any character that is controlled by the game system and/or a computer program and/or rules established by the game system or third party, and/or a player and not by a player on a continuous basis. Such NPC (or NPCs in the plural) may be controlled partially or fully by a human or in an automated fashion.

Game performance parameter—includes any aspect of a Video Game by which a player character's performance, actions, tendencies or preferences, can be measured. Game Parameters shall include, but not be limited to:

• • 1. Completing or failing to complete all or part of a mission
  • 2. Playing or not playing for a certain period of time
  • 3. Winning or losing a match against another player or player character or computer generated character or NPC
  • 4. Reaching or failure to reach a certain level or score or within a certain time
  • 5. using or obtaining or failure to use or obtain, or exemplary or improper use of an ability or technology
  • 6. kill/death ratios
  • 7. obtaining, creating or modifying an object, or failing to do so
  • 8. solving or failing to solve a puzzle, or failing to do so within a proscribed period
  • 9. accuracy with weapons
  • 10. effective or ineffective use of a weapon or the proper weapon
  • 11. killing or failure to kill a certain character/creature
  • 12. getting through or failing to get through to a certain geographic area
  • 13. decreasing or increasing Karma Points
  • 14. getting, buying, exchanging or learning a new skill or player attribute
  • 15. having or losing a child
  • 16. getting or failing to get married
  • 17. failing to or obtaining, buying, trading, producing or developing raw materials
  • 18. producing or failing to produce goods or services or within or not within a proscribed period
  • 19. earning or failing to earn income or a certain level of income or within a required time
  • 20. earning or failing to earn a higher rank in an army
  • 21. winning or losing an election among two or more players or player characters or NPCs or third parties
  • 22. achieving or failing to achieve deity or other status and/or within a required time
  • 23. improving or failing to improve player character status or caste
  • 24. assisting or failure to assist other player characters with any of the above
  • 25. speed of accomplishing/failing or changing the rate or trends of any or all of the above.

In-game Marketplace—shall include a virtual environment where Characters can buy, sell, trade, barter, encumber, seek, offer, or exchange items, attributes, or any other exchangeable game element.

Novice Player—shall include a player that is identified as requiring the help of an expert or other aid or assistance (e.g., automated assistance or a tutorial) to complete a Game Parameter.

Player—shall include an individual or entity or third party who can register or create an account with a Video Game Central Server, or virtual world or virtual environment, or video game, or within a peer-to-peer or other network and/or create Characters that can interact with other Characters in a Virtual Environment, and/or that can authorize an NPC to act on the player's behalf.

Player Account—shall include an account on the Video Game Central Server or console, or other server or within a peer-to-peer or other network that contains a Player profile, which profile may include personal, billing, and character account and/or attribute information.

Player Attribute—includes any attribute or information that can be applied to or used or accessed by a player account. Player Attributes shall include, but not be limited to real or virtual:

• • 1. Currency.
  • 2. Discount of monthly fees for playing game.
  • 3. Monthly fee for playing a game.
  • 4. Interest rates for use of or borrowing real or virtual cash amounts.
  • 5. Global character attribute settings for all characters created by player across multiple games.
  • 6. Rewards for encouraging another player to signup to play.
  • 7. Game Performance Parameters

Player to Player Contract—includes a real and/or virtual binding contract between player characters or third parties or NPCs or other entities that allows the players or other entities to provide or exchange game attributes or other items of value to one another. Once a player-to-player contract is established, the game server or peer-to-peer or other network may automatically distribute acquired game attributes between the player characters based on the contract conditions.

Video Game—includes a game played on a Video Game Consul or Server or network that may or may not be networked to a Video Game Central Server or within a peer-to-peer or other network topology.

Video Game Consul—includes a device comprising a CPU, memory and optional permanent storage residing at a player or other location that can allow for the playing of video games. Examples include, home PCs, Microsoft Xbox, and Sony Playstation.

Video Game Central Server—may include a CPU, memory and permanent or temporary storage that is connected to multiple Video Game Consuls that allows for Massive Multi Player Online Video Games or other video games to be played.

Virus—includes any unwanted, undesirable or harmful computer program, virus, worm, or Trojan horse or other application or service that can copy itself, in whole or in part, without permission or knowledge of one or more affected parties, e.g., an end user and/or that can spread itself to other computers or applications or data without needing to be transferred as part of a host or other server system, or not requested, permitted, designed or desired by the owner of the affected, i.e., infected, computer, application, or database and/or that can cause damage to one or more computers, applications or data.

“Game Environment”—a particular level or area within a virtual world. Each game environment may have its own rules, regulation, currency, government, managers, etc. Game environments may exist within other game environments.

The term “variation” of an invention means an embodiment of the invention, unless expressly specified otherwise.

A reference to “another embodiment” in describing an embodiment does not imply that the referenced embodiment is mutually exclusive with another embodiment (e.g., an embodiment described before the referenced embodiment), unless expressly specified otherwise.

The terms “including”, “includes”, “comprising” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.

The term “consisting of” and variations thereof mean “including and limited to”, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.

The term “plurality” means “two or more”, unless expressly specified otherwise.

The term “herein” means “in this patent application, including anything which may be incorporated by reference”, unless expressly specified otherwise.

The phrase “at least one of”, when such phrase modifies a plurality of things (such as an enumerated list of things) means any combination of one or more of those things, unless expressly specified otherwise. For example, the phrase “at least one of a widget, a car and a wheel” means either (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car, (v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, a car and a wheel.

The phrase “based on” does not mean “based only on”, unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on”.

The term “represent” and like terms are not exclusive, unless expressly specified otherwise. For example, the term “represents” does not mean “represents only” unless expressly specified otherwise. In other words, the phrase “the data represents a credit card number” describes both “the data represents only a credit card number” and “the data represents a credit card number and the data also represents something else”.

The term “whereby” is used herein only to precede a clause or other set of words that express only the intended result, objective or consequence of something that is previously and explicitly recited. Thus, when the term “whereby” is used in a claim, the clause or other words that the term “whereby” modifies do not establish specific further limitations of the claim or otherwise restricts the meaning or scope of the claim.

The term “e.g.” and like terms means “for example”, and thus does not limit the term or phrase it explains. For example, in the sentence “the computer sends data (e.g., instructions, a data structure) over the Internet”, the term “e.g.” explains that “instructions” are an example of “data” that the computer may send over the Internet, and also explains that “a data structure” is an example of “data” that the computer may send over the Internet. However, both “instructions” and “a data structure” are merely examples of “data”, and other things besides “instructions” and “a data structure” can be “data”.

The term “determining” and grammatical variants thereof (e.g., to determine a price, determining a value, determine an object which meets a certain criterion) is used in an extremely broad sense. The term “determining” encompasses a wide variety of actions and therefore “determining” can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” can include resolving, selecting, choosing, establishing, and the like. It does not imply certainty or absolute precision, and does not imply that mathematical processing, numerical methods or an algorithm process be used. Therefore “determining” can include estimating, predicting, guessing and the like.

It will be readily apparent to one of ordinary skill in the art that the various processes described herein may be implemented by, e.g., appropriately programmed general purpose computers and computing devices. Typically a processor (e.g., one or more microprocessors, one or more microcontrollers, one or more digital signal processors) will receive instructions (e.g., from a memory or like device), and execute those instructions, thereby performing one or more processes defined by those instructions.

A “processor” means one or more microprocessors, central processing units (CPUs), computing devices, microcontrollers, digital signal processors, or like devices or any combination thereof. Thus a description of a process is likewise a description of an apparatus for performing the process. The apparatus can include, e.g., a processor and those input devices and output devices that are appropriate to perform the method. Further, programs that implement such methods (as well as other types of data) may be stored and transmitted using a variety of media (e.g., computer readable media) in a number of manners. In some embodiments, hard-wired circuitry or custom hardware may be used in place of, or in combination with, some or all of the software instructions that can implement the processes of various embodiments. Thus, various combinations of hardware and software may be used instead of software only.

The term “computer-readable medium” refers to any medium that participates in providing data (e.g., instructions, data structures) which may be read by a computer, a processor or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying data (e.g. sequences of instructions) to a processor. For example, data may be (i) delivered from RAM to a processor; (ii) carried over a wireless transmission medium; (iii) formatted and/or transmitted according to numerous formats, standards or protocols, such as Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP, TDMA, CDMA, and 3G; and/or (iv) encrypted to ensure privacy or prevent fraud in any of a variety of ways well known in the art.

Thus a description of a process is likewise a description of a computer-readable medium storing a program for performing the process. The computer-readable medium can store (in any appropriate format) those program elements which are appropriate to perform the method.

Just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of an apparatus include a computer/computing device operable to perform some (but not necessarily all) of the described process.

Likewise, just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of a computer-readable medium storing a program or data structure include a computer-readable medium storing a program that, when executed, can cause a processor to perform some (but not necessarily all) of the described process.

Where databases are described, it will be understood by one of ordinary skill in the art that (i) alternative database structures to those described may be readily employed, and (ii) other memory structures besides databases may be readily employed. Any illustrations or descriptions of any sample databases presented herein are illustrative arrangements for stored representations of information. Any number of other arrangements may be employed besides those suggested by, e.g., tables illustrated in drawings or elsewhere. Similarly, any illustrated entries of the databases represent exemplary information only; one of ordinary skill in the art will understand that the number and content of the entries can be different from those described herein. Further, despite any depiction of the databases as tables, other formats (including relational databases, object-based models and/or distributed databases) are well known and could be used to store and manipulate the data types described herein. Likewise, object methods or behaviors of a database can be used to implement various processes, such as the described herein. In addition, the databases may, in a known manner, be stored locally or remotely from any device(s) which access data in the database.

Various embodiments can be configured to work in a network environment including a computer that is in communication (e.g., via a communications network) with one or more devices. The computer may communicate with the devices directly or indirectly, via any wired or wireless medium (e.g. the Internet, LAN, WAN or Ethernet, Token Ring, a telephone line, a cable line, a radio channel, an optical communications line, commercial on-line service providers, bulletin board systems, a satellite communications link, or a combination of any of the above). Each of the devices may themselves comprise computers or other computing devices, such as those based on the Intel® Pentium® or Centrino™ processor, that are adapted to communicate with the computer. Any number and type of devices may be in communication with the computer.

In an embodiment, a server computer or centralized authority may not be necessary or desirable. For example, the present invention may, in an embodiment, be practiced on one or more devices without a central authority. In such an embodiment, any functions described herein as performed by the server computer or data described as stored on the server computer may instead be performed by or stored on one or more such devices.

Description

Massive multi player online games (MMOGs) or massive multi-player role-playing games (MMORPGs) are computer games, which are capable of supporting hundreds, thousands, or millions of players simultaneously. Typically, this type of game is played in a giant persistent world where the game continues playing regardless of whether or not real players are logged in. Players commonly access these games through a network such as the Internet, and may or may not be required to purchase additional software or hardware in order to play the game. Such networks allow for people all over the world to participate and interact with each other in a virtual environment. The present disclosure provides systems and methods which contribute to the evolution and longevity of such a game.

The herein described aspects and drawings illustrate components contained within, or connected with other components that permit play in the virtual environment. It is to be understood that such depicted designs are merely exemplary and that many other designs may be implemented to achieve the same functionality. Any arrangement of components to achieve the same functionality is effectively associated such that the desired functionality is achieved. FIG. 1 provides an exemplary network which may be used to support a virtual environment.

Referring to FIG. 1, a network 10 according to one embodiment includes a central server 20 in communication with a plurality of video game playing units 18. Those of ordinary skill in the art will appreciate that any number of video game playing units may be in communication with the central server. Typically, the number of video game playing units changes at various times as players join games and as players stop playing games. Similarly, more than one server may operate to coordinate the activities of the video game playing units, as is well known in the art.

Central server 20 may comprise any computing device (e.g., one or more computers) capable of communicating with other computing devices. The server 20 typically comprises a processor which is in communication with a storage device, such as an appropriate combination of RAM, ROM, hard disk, and other well known storage media. Central server 20 may comprise one or more personal computers, web servers, dedicated game servers, video game consoles, any combination of the foregoing, or the like.

Each video game device 18 may comprise any device capable of communicating with central server 20, providing video game information to a player, and transmitting the player's desired actions to the central server. Each video game device typically comprises a processor which is in communication with a storage device, such as an appropriate combination of RAM, ROM, hard disk, and other well known storage media. Suitable video game devices include, but are not limited to, personal computers, video game consoles, mobile phones, and personal data assistants (PDAs).

Some or all of video game 17 can be stored on central server 20. Alternatively, some or all of video game 17 may be stored on the individual video game devices 18. Typically, the video game devices are able to communicate with one another. Such communication may or may not be facilitated by central server 20. Accordingly, a player 19a accessing video game 17 via game device 18a may be able to play with a player 19b accessing video game 17 via game device 18b. As shown, it may be possible for multiple players (e.g. 19c, 19d) to access central server 20 via the same game device (e.g. 18c).

Regardless of whether video game 17 is stored on central server 20 or video game devices 18, server 20 is typically configured to facilitate play of the game between multiple game players.

Those having skill in the art will recognize that there is little distinction between hardware and software implementations. The use of hardware or software is generally a choice of convenience or design based on the relative importance of speed, accuracy, flexibility and predictability. There are therefore various vehicles by which processes and/or systems described herein can be effected (e.g., hardware, software, and/or firmware) and that the preferred vehicle will vary with the context in which the technologies are deployed.

At least a portion of the devices and/or processes described herein can be integrated into a data processing system with a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system generally includes one or more of a system unit housing, a video display device, memory, processors, operating systems, drivers, graphical user interfaces, and application programs, interaction devices such as a touch pad or screen, and/or control systems including feedback loops and control motors. A typical data processing system may be implemented utilizing any suitable commercially available components to create the gaming environment described herein.

While virtual environments as previously described allow for interactions between players and the environment, the amount and depth of interaction may be limited by the parameters of the game. For example, players are generally limited to the vision of the game designer in that the types of objects found in an environment are predetermined or may only be assembled in predetermined fashions. There is no room for the imagination or creativity of a player.

Various embodiments of the present invention address this issue by providing means for importing and assembling virtual objects and/or creating virtual objects within a virtual environment based on the ideas of the players or third parties. Furthermore, virtual objects and resources already located within the virtual environment may be improved upon, altered, or developed into additional, new or other game attributes depending on aspects of game play. They may also be traded or exchanged between players, player characters, NPCs, third parties, game environments and other games. This expansion of sources for virtual objects and the manipulation or use of virtual objects within the game environment expands the development of the game and provides increased variability and inputs improving the depth and the interactions of the game. Such creation, development, manipulation or use of new or transformed virtual objects or attributes may also have a desirable effect upon the amount and type of real or virtual commerce engaged in or developed or used by players, player characters, NPCs, game owners or other parties, and/or may increase or otherwise affect real or virtual revenues generated by the game and/or commerce or exchange between players, player characters, NPCs, game owners, lending or other institutions, games or game environments, and/or any third parties or any combination of these entities.

Design concepts for virtual objects to be patented, copyrighted, bought, sold, traded, exchanged, imported, designed, developed, created or modified within a virtual environment may be based, in whole or in part, on real objects or may be imaginary or may be based, in whole or in part on existing designs, blueprints, patents and/or copyrights. Representations of such objects to be imported into a game environment may be rendered digitally or written as software or parts of software applications and/or described via one or more equation, formulas or algorithms. In one embodiment, a design concept may be based in whole or in part on a digital image. In another embodiment, a design concept may be drawn or otherwise rendered by a player or character. In a further embodiment, a design concept may be created in computer readable code. In yet another embodiment, a design concept may be expressed in mathematical equations, formulas or algorithms. In some embodiments, a design concept may be a combination of some or all of these things.

Characters and players may come up with sources for a design or the entire design independently, or may access a database of digital images which can be searched and/or browsed. In addition, or in the alternate, players or characters may receive designs, in whole or in part, for example, from other players, the game itself, other third parties, or via internal or external exchanges. The player and/or character may select virtual objects to make or have made based on objects in the database or supplied by others, may make or have made modified objects based on objects selected from the database or as supplied by others, may use the database as a source of inspiration, may use the database to add design elements to be incorporated into an object based on the player or character's specifications, or any combination thereof. In some embodiments such modifications may be of the appearance or functional purpose of an object. In other embodiments, such modifications may effect the construction or durability or other attribute of an object. For example, players and characters may modify the object to be made of specific materials, a particular size, weight, shape, color, dimension, strength, or any other physical attribute or performance characteristics they may choose.

Virtual objects created or otherwise acquired by players or characters may have properties or attributes beyond the general function of the virtual object. In one embodiment, the attributes of the design concept may be set by the player. In another embodiment, the attributes may be determined based upon the interaction among two or more component parts or construction materials. Such interactions may be complementary or contradictory and/or they may be additive or subtractive in nature or effect. In another embodiment, the attributes may be determined based on the type of virtual object. For example, a player may select healing properties or increased velocity to be part of a virtual object so that when the virtual object is used these properties may be accessed by the user. Other virtual objects may always have certain properties, for example swords made of a particular type of metal may be able to pierce particular types of armor. Properties or attributes imbued to virtual objects may include things such as, but are not limited to, shelf or useful life, strength, hit power or points, defends against, penetrates armor types, extends life by x days, weeks, months, years, reduces life by X, appreciation or depreciation rate, enhance experience accumulation, invisibility, reload rate, lifespan, dominate class, recovery class, improves recovery rate, improves armor, protects against specific weapons, healing or any other type of attribute commonly found in virtual objects in virtual environments. In other embodiments, virtual objects may assume or confer attributes on other virtual objects, for example a special lubricant may make the virtual cars on which it is applied run more efficiently.

Design concepts for virtual objects to be created in the virtual world may be imported by any means applicable. For example, they may be digital images such as photographs; drawings made using a computer program including, but not limited to, Adobe® Photoshop®, AutoCAD®, 3ds Max®, Maya®, Visio®, Corel® Painter™, ArtRage, Microsoft® Expression®, SketchBook® Pro, Deleter CGillust, Project Dogwaffle, Pixarra Twisted Brush, GraphicsMagick, Inkscape, Adobe® Illustrator®, or any other drawing or rendering program; scanned in images, including but not limited to 2D and 3D scanning, such as laser holography; computer readable code; programs; subroutines; software, mathematical formula or algorithm or any other format which would allow a computer to display an image.

Digital images to be converted into virtual objects may be one or more images of three dimensional objects, or scanned or otherwise converted two dimensional objects such as pictures, which pictures may or may not include multiple perspectives or dimensions, such as 3D holograms. In some embodiments, the images may be representations of one, two, three or four (or any number) dimensional objects. In other embodiments, the images themselves may be one, two, three or four (or more) dimensional. The image file may be formatted in any known image format including, but not limited to, RAW, bitmap, Graphic Interchange Format (GIF), Joint Photographic Experts Group Format (JPEG), Tag Image File Format (TIFF), or the like. In another embodiment, the object being designed or created is in the form of a software application or portion of an application e.g., a subroutine or software object that performs one or more functions.

Once the concept is in digital or other computer readable format, it may be imported into the game environment. In one embodiment, the imported image or concept may be broken down into its component parts for construction of the object in the virtual environment. In another embodiment, the imported image is brought into the game environment in its entirety. In some embodiments, the image is converted into a blueprint. In other embodiments, certain images may have predetermined aspects into which they are broken. For example, a sword may be broken into the pommel, hilt, guard, tang, shoulder, and blade even though the tang is generally not visible in images of swords. In some embodiments, there may be a database of elements of objects based on the construction of other items in a game environment or a preformed store of design and object construction blueprints in the game. Such a database may be added to by the creation of additional objects or designs in a virtual environment. In another embodiment, images may be broken down into simplified versions of the visible aspects of an object, for example, a sword may be broken down into the pommel, hilt, guard, and blade, or just the hilt and blade. In a further embodiment, the server may be able to fill in aspects of a virtual object that are not visible in an image. For example, an image of a car may be imported. The image may show the right side of the car. Based on certain algorithms, and the image of the right side of the car, the server may fill in the requirements for the left side of the car or the interior of the car. In other embodiments, the server may request images of other angles of the car.

In addition or in the alternate, component parts may include connection characteristics, which determine which components may connect with other components and in which order or orientation. Similar to Lego building blocks manufactured by The LEGO Group or building long chain amino acids, such connection characteristics could permit or prevent certain interrelationships. For example, a tire may be affixed to a wheel, but not to an axel, while a wheel may be affixed to an axel, but not a door. Certain connection characteristics may be generally more flexible in the number and type of connections that are possible, while others may be more particular or restrictive while yet others may only permit a specific interconnection or association. Such connection characteristics may provide visual representations, such as a round peg fitting into an appropriate diameter round hole, or such connection characteristics may be represented in whole or in part using code names or more easily understood descriptions. The general purpose of such connection characteristics, if used or present is to permit a player or player character to more easily understand which components or objects may or may not interoperate or be joined or combined with other components or objects. In another embodiment, there may be little or no limitations on how various components interoperate with each other or only certain components or objects may have such connection characteristics.

In some embodiments, a player or player character may be able to alter or add to the acquired image. For example, the color of the car, the type of engine, the options on the car, the tires, the shape, the doors, the roof, the hood, hood ornament, etc. may be varied from the image acquired. In one embodiment, the right side and the left side of a virtual object such as a car may originate in images of different cars, other vehicles or other objects to produce a hybrid vehicle that is completely imaginary. For example, a car may be crossed with a motorcycle or a horse. In a further embodiment, the interior of an object may be at odds with the exterior of the object, similar to a genie bottle in which the items in the interior would appear too large to fit into an object the size or shape of the exterior of the object. In another embodiment, such alterations may defy known physical laws, such as modifying part of a car to be visually distorted when viewed from the side but not from the front or other angle, even when viewed within the same lighting or environment. In another example, an object might be fashioned that interacts or performs differently depending upon how or where it is used or by whom.

Along with the physical appearance of an object, players and player characters may alter other physical aspects of the object such as the material an object is made out of, its weight, and size. For example, objects can be altered to fit into certain areas of a virtual environment, or to fit a particular character. In some embodiments, players and player characters may assign particular amounts of attributes to the object which would add to the object's usefulness. For example, a sword may also have the ability to heal its user or a car may be capable of changing its width or length upon command or under certain conditions, which may or may not be desirable given the prevailing circumstances.

The physical attributes and aspects of an object may affect its utility and efficiency. For example, according to one embodiment, the size and weight of an item may affect the cost to use an item, e.g., if a vehicle is built, the cost to operate and/or maintain the vehicle may increase with the size and weight of the vehicle. The amount of energy required to use the item, e.g., gasoline for a vehicle, may also increase with the size, weight or shape of the item. Moreover, the ability of an item to perform certain tasks, e.g. for a vehicle to carry a certain load such as passengers and/or items, may be restricted based upon the size and design of the item.

In another embodiment, a player or player character or the game itself may change one or more such attributes, which may require payment of a fee. In yet another embodiment, other players or player characters may desire to change the usefulness of an object to deprive its owner of part or all of its usefulness. Such changes may require the payment of a fee, or the casting of a spell, or use of some other method that permits such modifications. In yet another embodiment, the interaction of one object with another may result in a desired or undesired outcome. For example, if an owner of a male NPC permits intercourse with another player's female NPC, a new, baby NPC may be created as a new in game object.

According to another embodiment, the virtual size and weight of an item may affect the effectiveness of the item, e.g., if a sword weighs 50 pounds it may be more lethal when striking a blow, but it may fatigue its user faster than a sword that weighs only 10 pounds. Such effects may also be affected by the size and strength of the bearer of arms. For example, a 50 pound sword in the hands of a 300 pound virtual character may be both more lethal and less strenuous than when wielded by a 150 pound player character.

Furthermore, the relative skill of the virtual character may also have an affect on the effectiveness of the object. In the preceding example, if the 150 pound player is a master swordsman, then wielding the 50 pound sword may not be more strenuous than a less skilled 300 pound virtual character.

In some embodiments, the size, shape, and weight of an object may be adjusted based on the attributes of the requesting character so that it provides a custom fit. In other embodiments, the size, shape, and weight of an object may affect the cost to make or use the object. In another embodiment, all objects may cost the same to make or use regardless of size, shape, and weight, or all objects may be adjustable to the character using them, for example, based upon the character's skill level or account type or age of the character or account.

Once a design concept is rendered and its physical attributes and aspects are determined, a determination of the resources, skills and attributes necessary to make the object may be made. In some embodiments, a player or character may supply a list of all elements, resources and attributes that will be used in constructing the object. In another embodiment, a player, a character, the game server or other third party can determine or dictate the resources that are needed to assemble the object. For example, there may be experts in the construction of particular types of objects who review plans for the construction of an object in their specialty and determine the resources including skills, natural resources, raw materials, and NPCs needed to construct such an object. In another embodiment, the connection characteristics may determine part or all of the construction steps, options and methods.

Once the design concept is imported into the game environment and the specifications are provided or are otherwise understood, one or more player characters with the necessary skills may assemble part or all of the virtual object based on the image and/or request that all or part of the object be created based on the image. In some embodiments, certain skills and other resources such as virtual natural resources, virtual raw materials and NPCs may be required in order to make an object. Players and characters may use virtual natural resources, virtual raw materials, skills and NPCs available in a game or acquired from other games to create or modify virtual objects to be used within a game environment. In one embodiment, players may purchase tokens in the real world for redemption in the virtual world for particular resources. In the case that additional players, characters, and resources are required, the game server or other third party may be configured to indicate to the player character which other player characters have the skills and/or resources required to construct the object. In another embodiment, there may be a database for locating projects or characters, players and NPCs with the requisite skills or other resources necessary for assembling an object.

In yet another embodiment, for certain or all objects or objects of a certain type or use or purpose or cost, the player or player character may only be required to provide one or more or all of the design, construction materials, skills, funds, permits, licenses, fees, attributes, connection information, etc., and, upon collecting the necessary items, the game environment may then create the object for such player or player character without any further effort or action by such player or player character, i.e., “no assembly required.” In such cases, the object may be created based upon a library of known or similar objects, which may or may not restrict or otherwise limit the flexibility, use, purpose or other attributes of the object.

An exemplary system 100 configured to provide a virtual environment as described above is shown in FIG. 2. As shown in FIG. 2, system 100 includes a master game server 102 for running the game and a game environment server 104 for one or more game environments within the game.

Master game server 102 may host a program such as game environment creation and set up program 106. Master game server 102 may further host a plurality of databases including, for example, game environment database 118 and player database 120. Game environment server 104 may host a plurality of programs including, for example, Game Environment Maintenance Program 108, Game Environment Management Program 110, Game Attribute Valuation Program 112, Exchange Multiplier Determination Program 114, and Game Item Assembly Program 116.

Game environment server 104 may include a plurality of databases including, for example, current date database 122, raw material database 124, NPC database 126, skill database 128, era database 130, exchange multiplier database 132, player database 134, player character database 136, natural resources database 138.

In one embodiment, game environment creation and set up program 108 may establish the parameters for the functioning of a particular environment. Information regarding a particular game environment or all game environments may be stored, for example in game environment database 118. Game environment database 118 may store information regarding the game environment such as the game environment ID, identification of the owners, percentage ownership, governance structure, configurations, natural resources, raw materials, creation date, fee structure, or any other information relating to the game environment. Information regarding the players who use game environments or participate in a virtual environment may be stored, for example, in player database 120. Player database 120 may include information regarding the players in a virtual environment, their ID(s), the character(s) they control, account information, billing information and the game environments in which the players have characters. Once they are established, game environments may be maintained, for example, using game environment maintenance program 108. Decisions which affect the running of the game environment may be implemented using game environment management program 110.

Virtual objects for use in a game environment may be constructed using resources located in one or more game environments or games. Such resources include, but are not limited to, virtual natural resources, virtual raw materials, skills, attributes, finished items that may be used to construct other items, and NPCs. Each virtual object to be assembled may require possession of particular skills, levels of skills or materials before a player or player character will be allowed to assemble the virtual object. Materials to assemble the virtual object may be acquired by any means applicable. For example, they may be purchased from the game server, purchased from an NPC, purchased from another player character, stolen, gathered from the game environment or acquired by purchasing, winning, receiving or otherwise acquiring game tokens in the “real world” and exchanging the token for materials in the virtual game space. The value of a game attribute used to make a virtual object or the value of the virtual attribute itself may be determined by any means applicable. For example values may be set or variable, or may be set or variable at different times during the game. In one embodiment, values may be determined by market forces. In a further embodiment, values may be determined by game attribute valuation program 112.

In one embodiment, construction of a virtual object may be based on a plan. The plan may include the virtual natural resources needed to make the virtual object as well as particular virtual raw materials which may be used to construct parts of the virtual object and the amounts of the virtual natural resources and virtual raw materials that are required to construct the virtual object. For example, a natural pigment may be required to produce paint to change the color of a car. The virtual natural resources and raw materials requested by the player or character desiring the creation of a virtual object may or may not be available in a particular game environment. In one embodiment, the necessary virtual materials may be imported into the game environment from other games or game environments or they may be acquired in an exchange. When a player character submits a request for a virtual object he has designed to be built, the game server can display a list of the virtual natural resources, raw materials and quantities required to assemble the object. In another embodiment, the game server or other controlling entity may suggest alternate materials that are available in that game environment. Such a list may include viable alternatives or substitute materials that may be used. In some embodiments, available substitutions may have no beneficial or deleterious effects on the finished product, while in other cases, substitutions may affect, positively or negatively, the operating characteristics of an object and/or its cost to produce or to use, or it may affect one or more of its performance characteristics, such as its effectiveness or useful life. In a further embodiment, the types of virtual natural resources and raw materials that are available or may be imported may be limited based on the era of the game or game environment and the technologies available. The player requesting the construction of a virtual object may have the materials on hand, may purchase the materials or may outsource the construction of the virtual object to another character or NPC who has the materials. Based on the plan and the materials specified, a price may be determined or negotiated for the materials.

Natural resources are naturally occurring substances that are considered valuable in their relatively unmodified (natural) form. There relative value may be increased through process of manufacture or modification, such as carving wood. They are generally classified as renewable or non-renewable, while certain resources may begin as renewable or non-renewable and then, unlike the real world, may change their classification, which change may be controlled by the game itself, or rules established by the game owner or the game server, and/or may be established or modified by rules established before or during game play, which may be established by any one or more of the players, player characters, game owner, game server or any other authorized third party and/or via the use of neural networks or genetic algorithms. Changes to the “renewability” of a given resource, may be based, in whole or in part, on the effect such availability or classification has or might have on a given game or the outcome of one or more events that will or may occur. For example, if game enjoyment or game revenues may be artificially or unnecessarily retarded by the lack of virtual oil, the system might create a new reserve of oil so as to alleviate demand on what would otherwise be considered a non-renewable resource in the real world. In the real world, the rate of sustainable use of a renewable resource is determined by the replacement rate and amount of standing stock of that particular resource. In the virtual world, the rate of sustainable use may be determined by the replacement rate and amount of standing stock or may be determined by other factors. For example, some virtual resources may be automatically renewable when they reach a particular depletion level. In another embodiment, virtual resources that are generally considered nonrenewable may be renewable in the virtual world. Information regarding virtual natural resources may be stored, for example, in Natural Resources Database 138 and may include information such as, but not limited to: resource ID, resource descriptor, last market value, maximum allowed, issued to date, remaining to be issued, permit price, available date range, resource attributes 1-n, renewability, perishability, decay rate and level in which it exists.

Raw materials may include crude or processed material that can be converted by manufacture, processing, or combination into a new and useful product. In one embodiment, raw materials include semi-processed materials such as building supplies or food. Raw material database 124 may include, for example, raw material ID, raw material type, location, first date available, conditions for use, conditions for discovery, conditions for availability, max quantity allowed, quantity issued, quantity remaining, license or permit fee, resource attributes, renewability, level at which it exists, expiration date, natural decay rate/perishability factor, and available times during the game.

Virtual objects may also be constructed by NPCs. NPCs may be hired directly or arrangements may be made with the owner or an NPC. Information regarding NPCs and the skills of particular resources of NPCs may be stored, for example, in NPC database 126. NPC database 126 may include information such as, but not limited to, NPC ID, type, location, conditions for use, skills, license or permit fee and available eras.

Along with the list of materials required to assemble a virtual object, a plan may include the necessary skills to make a virtual object. In one embodiment, a player or character may determine the skills required to make a virtual object. In another embodiment, the game server may supply a list of the skills required to make a virtual object.

In one embodiment, system 100 may be configured to determine the missing skills or other resources necessary to complete assembly of the item using some or all of the following steps:

• • 1. Receive a request to assemble a game attribute.
  • 2. Create an item record, including a unique serial number, item creator, blueprints used, and other asset information.
  • 3. Determine raw materials and skills necessary to complete assembly of item.
  • 4. Determine existing missing skills and raw materials in the player character account.
  • 5. Output existing missing skills and raw materials to player character.

In some embodiments, the skills required to make a virtual object may not be available in a particular era, or may not have been acquired by anyone in a particular game environment. Such information may be made available to a character requesting the construction of a virtual object who may then seek to import the skill or someone with the skill from another game or game environment, or may seek to acquire the necessary skill themselves. Information regarding skills and their availability may be stored by any means applicable. For example, such information may be stored in skill database 128. Skill database 128 may include information such as, but not limited to, skill ID, type, levels, conditions for use, conditions for availability, maximum quantity allowed, quantity issued, quantity remaining, prerequisites, continuing education requirements, license or permit fee, and available eras. In another embodiment, such limitations based upon skill or other discriminating criteria may be obviated through the use of a spell, or through payment of a fee, which might be considered excessive, or through other means, such as by stealing the object. Using an object acquired via these extraordinary means, may or may not generate possible harmful side effects. For example, if a player character steals the technology to build a hydrogen bomb, and then attempts to build the object (i.e., the bomb), there may be an increased probability that such a player or player character may accidentally detonate such a device, thereby destroying him or herself and everything within a 100 km radius.

Along with the type of skill required, there may be a particular skill level which may be required or selected. For example, all blacksmiths may be able to make a knife, but the quality of the knife and its usefulness may depend on the skill level of the blacksmith. In another embodiment, only blacksmiths with a certain skill level can make knives. In a further embodiment, the resources used to make the object may determine the skill level required. For example, if the character requesting the object has or acquires mineral ores that need to be purified and forged, that may require a different skill or skill level than if the character has steel.

According to one embodiment, the game system can determine the skill level required to assemble an item based on the complexity of the design and the natural resources and raw materials required to assemble it. In some embodiments, a player character or NPC with the appropriate skill set(s) may only reside in another game environment. In such a case, the player character may hire the player character or NPC in the other game environment, may recruit the player character or NPC to move game environments, or may sell his design to the player character or NPC in exchange for a finished object.

In another embodiment, when a plan or design concept is submitted, a list of NPC and player characters who possess the skills necessary to build the object or pieces of it may be made available to the player characters. Such a listing may include the fee such NPC and/or player characters charge for their construction or manufacturing services. Information regarding the particular rights and abilities of players and characters in a particular game environment may be stored by any means applicable, for example in player database 134 and character database 136. Such information may allow the game server or other entity to determine which characters and players have access to the necessary skills and other resources required to make a requested object. In some embodiments, players may be required to pay an additional fee or have a premium account to permit their characters to use NPCs or other player characters to build objects and/or to import objects to assemble in the game or to assemble objects for other player characters. Player database 134 which may include information such as, but not limited to, player ID, the character(s) controlled by the player, GUID, account type, billing information and personal information. Player character database 136 may include information such as, but not limited to, character ID, player ID, assets, skills, skill levels, obligations, resources, designs, blueprints, physical limitations, connection characteristics, image type/name, GUID, and game environment access.

For some objects the skill level may be greater than the skill that any one or more player character(s) or NPCs in the game environment has or can have. The game server can list all of the skills necessary to assemble the item and list other player characters or NPCs who have the required skill level to assemble components of the item. The game server may also list any general contractors (within the current or any other connected game) who are available and have demonstrated the skills, connections, etc., necessary to acquire the necessary resources and labor to build a virtual object. Such player and/or contractor listings may be listed alphabetically, or sorted according to any one or more of: experience, other player ratings or rankings, quality, quantity/capacity, price for similar or identical items, bid, barter options, availability, reputation, past legal violations, e.g., prior patent infringement or lawsuits or claims by other players, etc. The player character can immediately contact characters who have the necessary skills and/or other desired attributes to build the item and request bids to assemble all or part of the in game object and/or control or manage the process for the player requesting the item(s). In another embodiment, characters or owners of NPCs willing to sell their skills may advertise. In yet another embodiment, characters or players wishing to have objects assembled may request bids to assemble the object.

Some resources may only be available at particular times or in particular eras. Such information may be calculated and tracked by any means applicable. In one embodiment, current date DB 122 may be configured to track the passage of time and the resources available at the particular point in the game play. Era DB 130 may include information as ERA ID, date range, and the skills, resources, attributes, raw materials and NPCs available in each era.

In one embodiment, resources to make a virtual object such as skills, NPCs, natural resources and raw materials may be purchased from other game environments or other games. Such purchases may be made by the owner(s) or controlling entities of a game environment, or by individual characters or groups of characters. For example, in some embodiments, some or all resources brought from other game environments must be purchased by a game environment manager or licensed vendors in a particular game environment. In another embodiment, any player character can purchase any item in any game environment. Purchases may be paid for by any means available. In one embodiment, virtual resources may be purchased using real or virtual currency, assets, credit, loans or other financial instruments. Such methods of payment are further described in detail in U.S. patent application Ser. Nos. 11/620,542 11/559,158, 11/421,025, 11/380,489, 11/096,212, 11/096,265, 11/068,736, 11/069,906, and 11/069,905, each of which is herein incorporated by reference in its entirety.

Attributes and resources including created objects, skills, virtual natural resources, virtual raw materials and NPCs exchanged between game environments or game servers may be uniform or may be exchanged using multipliers to recognize differences in supply and demand between game environments. Conversion rates may be determined by any means applicable. They may be fixed, on an automated trading system, or as determined by an exchange on the open market or any combination thereof. For example, conversion rates may be based on a comparison of the economies of two game environments, a comparison of a representative basket of goods, the number of player characters in each environment, the amount of a particular virtual asset available in a particular game environment, the amount of production of a virtual asset in the game environments or on any other number of market forces or comparable factors. For example, a gallon of oil may be converted to two gallons of oil when traded from War Craft to Second Life. In another embodiment, a barrel of oil may be converted into 1000 thistle seeds within a game environment, and/or a barrel of oil may be converted to 5000 thistle seeds when exchanged between two games. 5000 thistle seeds may be worth 3 shares of stock in a particular game environment. In a further embodiment, a game attribute coming from a first environment may be converted into a game attribute in a second environment by multiplying the value of the game attribute in the first environment by a conversion multiplier that reflects the difference in the labor (and/or other factors) required to build the game attribute in the first environment vs. the second environment. For example, 1000 thistle seeds in one game environment may be worth 700 thistle seeds in another game environment. Alternatively or additionally, the multiplier may take into account any differences in supply, availability, ease or cost of acquisition, or the like, of the resources and/or the prevailing exchange rates of real or virtual currency. Some game environments may be configured to produce items more optimally. These game environments may receive a premium valuation in that their labor is more efficient in that game environment than on other game servers. Alternatively, environments that produce such items more optimally may be penalized or a tariff may be imposed to create a more fair exchange between or among such game environments.

In one embodiment, some or all of the following steps may be used to convert assets between game environments.

• • 1. Generate a conversion value for two or more game environments based on activity and conditions in the game environments.
  • 2. Create a conversion multiplier based on the relationship of the values between two or more game environments.
  • 3. Store multiplier.
    Such a multiplier could be calculated using any means applicable, for example using exchange multiplier determination program 114. Such information may be stored by any means applicable. In one embodiment, such information is stored in exchange multiplier database 132. Exchange multiplier database 132 may track the exchange ID number and the multiplier number for transactions between exchanges, game environments, game environment jurisdictions and/or games.

In another embodiment, system 100 may be configured to determine the value of an item on an exchange based on a multiplier by performing the following steps:

• • 1. Receive a request to purchase an item from a player character in one game environment.
  • 2. Determine available items to fulfill the request that are owned by player characters in other game environments.
  • 3. Retrieve the exchange multiplier between the game environments of the purchasing player and the selling players.
  • 4. Multiply each available item by the appropriate exchange multiplier.
  • 5. Output available items, with a corresponding price that has been adjusted based on exchange multipliers.
  • 6. Receive a request to fulfill the request to purchase with one of the available items.
  • 7. Withdraw virtual funds from the purchasing player character equal to the purchase price.
  • 8. Convert the purchase price using the exchange multiplier into a virtual currency value.
  • 9. Deposit virtual currency value into account of selling virtual player.

According to one embodiment, the game server can set a maximum trade amount per time period on currency, resources and other available items including finished products both in the game environment and between game environments.

In another embodiment, import or export taxes may be imposed. Such taxes may be a percentage of the value of the import or based on the amount per unit of the import. They may be imposed by the game server, game owner, server owner, game environment owner(s), a character or group of characters or any combination thereof. In some embodiments, there may be agreements between or among games and/or game environments regarding import and export taxes. Taxes may be manually or automatically adjusted based on taxes imposed by other servers and/or game environments or imposed unilaterally.

Once the resources including skills and materials to assemble a virtual object are acquired, the virtual objects may be assembled by any means applicable. For example, such an assembly may occur using game item assembly program 116. In one embodiment, the game server may assemble a virtual object. In another embodiment, the player or character who imported an image or came up with a design may assemble a virtual object. In a further embodiment, assembly may be outsourced to a NPC or other player character. The determination of the qualifications of any particular character of player may be made by any means applicable. In one embodiment, system 100 may be configured to determine if a character qualifies to assemble an item using some or all of the following steps:

• • 1. Receive request to assemble item from a player character.
  • 2. Determine if player character qualifies to assemble item.
  • 3. If player character qualifies, output list of required materials.
  • 4. Receive appropriate materials.
  • 5. Assemble item.
  • 6. Output item to player character.

In some embodiments, permits may be required to assemble objects. Such permits may apply to a particular industry, a particular type of virtual object, a particular skill, a particular resource, and/or a particular project or any combination thereof. In some embodiments, permits may be needed to construct certain types of virtual objects in particular game environments. In other embodiments permits may be limited to a particular game environment or may apply across game environments. The virtual permit may be a one-time fee and/or may require periodic payments that are fixed or variable, which may be based upon the total value of a particular project, the industry in general, the amount of resources that will be required to build a particular project, the number of characters or other entities applying for permits, the population density of a particular game environment, vote by a group of player characters and/or an entity or player character elected to represent the player characters, the game manufacturer, by the game, market prices, or any combination of the foregoing. In some embodiments, permits may be acquired by purchasing them from other characters. In other embodiments, permits may be obtained from official sources through the use of bribery.

According to one embodiment, game server 102 may be configured to perform some or all of the following steps to issue a permit:

• • 1. Receive a request from a player character, group of player characters, or one or more third parties to acquire a permit.
  • 2. Determine if there is an available permit for the virtual resource the player characters wish to acquire.
  • 3. If there is an available permit determine and output a permit fee.
  • 4. Receive an acceptance and payment for the permit fee.
    In one embodiment, virtual objects may not be constructed without the necessary permits. In another embodiment, virtual objects may be constructed but may not be traded on exchanges if the necessary permits have not been obtained. In a further embodiment, an item may not be registered, for example in a new item database, unless the necessary permits have been obtained. In some embodiments, a black market may exist for the trade of items that have been created without a permit.

In some embodiment, images created or imported into a game environment by players or characters are converted into blueprints or mathematical representations, e.g., an algorithm or formula, from which the virtual object may be constructed. In some embodiments, the images may be of each aspect of a three dimensional object, for example the sides, front, back, top and bottom. In another embodiment, a single image may be submitted and a program may fill in the other aspects of the image based on information provided by the player or character or based on similar virtual objects that have previously been imported. In a further embodiment, a single image may be taken in such a way as to show more than one aspect of an object. For example, an image taken at an angle may reveal the front and the top. Multiple images showing multiple aspects may be combined to create a truer representation of the desired object.

An exemplary system 200 configured to provide a virtual environment as described above is shown in FIG. 3. As shown in FIG. 3, system 200 includes a master game server 202 for running the game and a game environment server 204 for one or more game environments within the game.

Master game server 202 may host a program such as game environment creation and set up program 206 and digital file import program 214. Master game server 202 may further host a plurality of databases including, for example, game environment database 208, player database 210 and new item database 212. Game environment server 204 may host a plurality of programs including, for example, object creation program 220, game item assembly program 222, game attribute valuation program 224, exchange multiplier determination program 236, and blueprint generation program 228.

Game Environment server 204 may include a plurality of databases including, for example, new item database 232, raw material database 230, NPC database 234, skill database 236, natural resources database 238, design database 240, exchange multiplier database 242, player database 244 and character database 246.

The ability to create a virtual object in a virtual environment may depend in some part on the type of game environment in which a character resides. Such determinations may be made at the time the game environment is formed, for example using game environment creation and setup program 206, or may evolve as the game progresses. Particular game environments may have limitations on the types of objects that may be created in that game environment, there may be limitations based on the era of the game environment, or the resources in the game environment. For example, some game environments may not permit the construction of mechanized objects. Information regarding the game environment may be stored, for example in game environment database 208. In one embodiment, game environment database 208 may store information regarding the game environment such as the game environment ID, identification of the owners, percentage ownership, governance structure, restrictions on imports or exports, restrictions on object creation, configurations, natural resources, raw materials, creation date, fee structure, or any other information relating to the game environment.

Digital renderings of objects to be created in a game environment may be brought in by any means applicable, for example using digital import program 214. Once an imported design concept is determined to be acceptable to a particular game environment, the digital images and software applications may be converted into blueprints for creating the requested virtual object using, for example, blueprint generation program 228. Blueprints may contain all or some of the design elements of a concept or may contain a general outline of the object sought to be replicated. In one embodiment, blueprints may include information regarding the materials to be used and/or the skills required to assemble an object. In some embodiments, some or all of a blueprint may be acquired, for example, from design database 240. Design database 240 may include images of items that may be used as part of virtual objects, as inspiration for virtual objects, blueprints for objects created by other players, and decorative elements. Blueprints may be created, for example, using some or all of the steps in the method outlined in FIG. 4. In some embodiments, a request may be made to import a digital image. Some digital images may be more or less suitable for creating blueprints. In some embodiments, additional images may be required, in other embodiments, additional information may be required or both additional images and additional information may be required. When an image is imported, a determination is made regarding its sufficiency. If it is sufficient, a blueprint is generated. The game server or other controlling entity may automatically assign particular materials to the construction of a virtual object or may request a list of materials to be used. In addition to the raw materials and natural resources to be used in constructing a virtual object, there may be attributes imbued into the virtual object, for example certain spells, powers, healing, longevity, invincibility, armor piercing ability, clean running, accelerating, strength or any other attribute generally found in virtual objects. The attributes to be attributed to a virtual object may be requested. Once the specifications for a virtual object are provided, determinations may be made regarding the amount of materials and the skills required to produce an object.

In another embodiment, the game server or other controlling entity or a specific application may evaluate any one or more or all of the blueprints, raw materials, construction method(s), and/or intended use or inclusion of any application or other software to determine if such proposed object may be harmful to the game environment, for example, the system may determine that such an object might include coding that is, or is similar to, a virus, worm or other harmful code. In such cases, the game server or other controlling entity or application may prohibit the import or creation of such an object and/or may quarantine the object and/or may provide instructions as to which changes are mandated so as to modify the object so that it is no longer harmful or otherwise violates some restriction, building code, or other constraint(s). For example, the game server might examine the software that controls an NPC for potentially harmful computer viruses. Applications that provide such software scanning or review are well known in the prior art, including software such as Norton Utilities provided by Symantec.

Virtual natural resources and raw materials used to make virtual objects may be purchased, found, harvested, gathered, mined, husbanded, grown, distilled, raised, leeched, pumped, drilled, purified, stolen, or otherwise acquired from the game environment. Information regarding virtual natural resources may be stored, for example, in natural resources database 238 and may include information such as, but not limited to: resource ID, resource descriptor, last market value, maximum allowed, issued to date, remaining to be issued, permit price, available date range, resource attributes 1-n, renewability, perishability, decay rate and level in which it exists. Raw material database 230 may include, for example, raw material ID, raw material type, location, first date available, conditions for use, conditions for discovery, conditions for availability, max quantity allowed, quantity issued, quantity remaining, license or permit fee, resource attributes, renewability, level at which it exists, expiration date, natural decay rate/perishability factor, and available times during the game.

The requesting character's assets may be inventoried to determine if they possess the necessary materials to make the requested virtual object. Information regarding the character and the player controlling the character may be stored, for example in player database 244 and player character database 246, respectively. Player database 244 may include information such as, but not limited to, player ID, the character(s) controlled by the player, blueprints imported, design concepts, objects created, billing information, account information and personal information. Player character database 246 may include information such as, but not limited to, character ID, player ID, assets, skills, obligations, objects created, objects requested, raw materials, natural resources, rates for use of skills, and game environment access.

If they do not have the necessary materials, the name of a supplier may be requested. If they do have the necessary materials, an assessment regarding their skills may be made. If they have the necessary skills, the requesting character may be permitted to make the object. If they do not have the necessary skills, the requesting character may request the game server, an NPC or another character assemble the object. Information regarding the skills and NPCs available in a particular environment may be stored for example, in skill database 236 and NPC database 234 respectively. Availability of particular skills may be stored, for example, in skill database 236 which may contain information such as the skill ID, type, conditions for use, available era(s), characters with skills, NPCs with skills, skill levels, and use of skills. NPC database 234 may include information such as NPC ID, type, location, conditions for use, license or permit fee, available eras, costs for use, and skills. In some embodiment, the particular characters or NPCs with the necessary skills may not exist in that game environment. Information regarding players with characters or NPCs with the necessary skills in other game environments may be stored, for example, in Player database 210. Player database 210 may include information regarding the players in a virtual environment, their ID(s), the character(s) they control, the skills and assets of the characters, billing information and the game environments in which the players have characters. The costs for assembling the virtual object may be determined based on who assembles the virtual object.

In one embodiment, a request to create a virtual object could be processed by system 200 which may be configured to perform some or all of the following steps:

• • 1. Receive a request to assemble a game attribute, including a blueprint.
  • 2. Create an item record, including a unique serial number, item creator, blueprints used, and other asset information.
  • 3. Determine raw materials and skills necessary to complete assembly of item from blueprint.
  • 4. Determine existing skills and raw materials in the player character account.
  • 5. Determine missing resources required to complete assembly of item
  • 6. Output list of missing skills and raw materials to player character.
  • 7. Identify suppliers of missing skills and raw materials.
  • 8. Output list of suppliers to requesting player character.

In one embodiment, a character may only be able to request the formation virtual objects that they have the ability to assemble. In another embodiment, a player character may only be able to request the formation of virtual objects that they can use. In a further embodiment a player character may request or assemble any virtual object. Characters may also request that a virtual object be assembled by a third party such as the game server, an NPC or other player character for a fee.

Information regarding all finished objects may be stored, for example, in new item database 212. New item database 212 may include information such as new item ID, creator ID, new item digital images, new item blueprints, new item materials, new item construction cost, and new item salvage value.

Within a specific game environment, information regarding newly created items may be stored, for example in new item database 232. Such newly created items may be linked to the requester and creator of new items and new item database 232 may include information such as new item ID, originating character ID, creating character ID, required skills for replication, new item digital images, new item algorithms, new item blue prints, new item materials, new item construction cost and availability.

In one embodiment, exchanges may be used to acquire the necessary blueprints and resources for assembling an object. In one embodiment, a blueprint can be posted on an exchange and player characters having the appropriate skills can bid to assemble the item. Such bids may or may not include the raw materials necessary to build the item. If raw materials are not included, the player making the request may be expected to supply, purchase or otherwise acquire (e.g., pillage, plunder, or steal) the raw materials and/or the component parts. The player character who posted the item can then accept one of the bids posted on the exchange to assemble the item. In another embodiment, all resources required for a project may be purchased on an exchange.

The value of items on an exchange and the determination of the value to different games and game environments may be calculated by any means applicable. In one embodiment, exchange multiplier database 242 may track the exchange ID number and track or store the multiplier number calculated by exchange multiplier determination program 226 for purchases and acquisitions of objects or resources between exchanges, game environments, game environment jurisdictions and/or games. In some embodiments, game attribute valuation program 224 may track and/or calculate the market for particular game attributes, whether finished objects or parts of objects.

Payment terms for items acquired on exchanges or through other means may be established by the game, players and/or agreed to between the requesting player and the supplier player or NPC. Terms may created using any financial arrangement including but not limited to: cash up front, partial initial payment and lump sum upon completion, credit card or other financing instrument, series of equal or unequal payments, total amount upon completion, etc. Methods to provide for use of credit cards and other financial instruments in virtual environments are disclosed in U.S. patent application Ser. Nos. 11/279,991, 11/380,489, and 11/421025, each of which is hereby incorporated by reference in its entirety for all purposes.

Once the blueprints are created and the resources and skills are acquired or hired, a virtual object may be assembled. Such an assembly may take place using any means applicable. In one embodiment, the actions of characters and NPCs may be executed using game item assembly program 222. In another embodiment, the game server may assemble the object using object creation program 220. Each item created may be customizable based on the physical limitations of the requesting character. For example, system 200 may be configured to customize a virtual object based on the attributes of the requesting character using some or all of the following steps:

• • 1. Receive digital image(s) of item from a player character.
  • 2. Determine physical limitations of an item based on player character profile.
  • 3. Determine required skills and materials.
  • 4. Request required skills and materials.
  • 5. Assemble item.
  • 6. Determine if item contains software or potentially harmful attributes.
  • 7. If item is harmful, attempt to modify or cleanse the item
  • 8. If approved or item is otherwise not harmful, output item to player character

In some embodiments, players or other third parties may create software applications or portions of an application e.g., a subroutine or software that performs one or more functions. Such imported software applications or portions of an application may then be brought into the game and objects may be formed using the designs in the imported software application. Imported applications may be required to conform to existing, published or standard software application program interfaces or APIs. API's may be developed by the game owner, the players or other third parties, such as standards bodies currently existing or organized for such purposes. API's may permit or prevent certain interactions or transaction types. In certain embodiments, such imported applications or portions of applications or other software may first undergo an evaluation or scanning process to ensure that such software is devoid of any harmful code, such as a virus or worm, or other harmful code, such as code to steal player account or billing information, or code that might destroy part or all of the game application or adversely affect the game server or any application loaded on it, such as the operating system. (Ellen, this would be a good place to reference prior art for virus scanning software)

An exemplary system 300 configured to provide a virtual environment as described above is shown in FIG. 5. As shown in FIG. 5, system 300 includes a master game server 302 for running the game and a game environment server 304 for one or more game environments within the game.

Master game server 302 may host a program such as game environment creation and set up program 306, digital file import program 314, and subroutine import program 316. Master game server 302 may further host a plurality of databases including, for example, game environment database 308, player database 310 and new item database 312. Game environment server 304 may host a plurality of programs including, for example, object creation program 320, game item assembly program 322, game attribute valuation program 324, and exchange multiplier determination program 336.

Game Environment server 304 may include a plurality of databases including, for example, new item database 332, raw material database 330, NPC database 334, skill database 336, natural resources database 338, design database 340, exchange multiplier database 342, player database 344 and character database 346.

The ability to create an object in a virtual environment may depend in some part on the type of game environment and/or the game in which a character resides. For example, particular game environments may have limitations on the types of objects that may be created in that game environment, there may be limitations based on the era of the game environment, the resources in the game environment, or the type of programs that may be created and used in a game environment. For example, the software application may be a program that creates a virtual car wash that, once added to the game space, can provide virtual car washes for virtual cars. The benefits of such software applications can vary widely and owners or licensors of such applications may charge a fee for use of the application and/or usage charges based upon in game play. In one embodiment, the benefit of such an action may be of purely cosmetic or of entertainment value. In another embodiment, such an action may have a beneficial effect on the virtual car, e.g., the car is faster or wears out more slowly. In an environment that does not allow mechanized cars, such a program would be blocked. Information regarding the game environment and the types of objects that may be used in a game environment created, for example, by game environment creation and setup program 306, may be stored, for example in game environment database 308. In one embodiment, game environment database 308 may store information regarding the game environment such as the game environment ID, identification of the owners, percentage ownership, governance structure, configurations, natural resources, raw materials, allowable technologies, prohibited technologies, creation date, fee structure, or any other information relating to the game environment.

In yet another embodiment, the system may track the trustworthiness of a given player, player character or NPC or other third party so as to permit the system to determine if such individual can be trusted to build additional objects. For example, if a player produces an object that contains a virus, said player's account may be flagged to indicate that the player may not be trustworthy. Over time, a player's trustworthiness may be modified to reflect current construction practices. When importing code from outside the game environment, such trust may be based, in whole or in part upon so called trust or verification or authenticity certificates, such as those used by Microsoft's Vista operating system.

In some embodiments, players may create programs or subroutines to create virtual objects in the game environments. Such programs and subroutines may be vetted for appropriateness to the era or game environment, viruses, completeness and functionality. In some embodiments, such programs and subroutines may be imported using subroutine import program 316. Such an import program may include a debugging function to allow correction of the program if the resulting image of an object does not meet the appearance desired by the creator. In another embodiment, subroutine import program 316 may be used to integrate a virtual object into a game environment. Once an imported design concept is determined to be acceptable to a particular game environment, the image created by the software applications may be converted into blueprints for creating the requested virtual object. Blueprints may contain all or some of the design elements of a concept or may contain a general outline of the object sought to be replicated. In one embodiment, blueprints may include information regarding the materials to be used and/or the skills required to assemble an object. In some embodiments, parts of a blueprint generated by the importation of a subroutine could be supplemented, for example using information from a design database such as design database 340. Design database 340 may include images of items that may be used as part of virtual objects, as inspiration for virtual objects, blueprints for objects created by other players, subroutines and programs for virtual objects, and decorative elements. In another embodiment, programs may be supplemented or complemented by other digital images such as photographs or sketches. Such digital images may be imported using any means applicable, such as digital file import program 314. For example, a program or subroutine could provide an outline of an object, or the general formation or workings of an object. Decorative details, information regarding the materials to be used, and attributes given to the object may be supplied from other sources such as design database 340 or digital file import program 314. Such a compilation of a program, design and image may be compiled using, for example, object creation program 320.

When a program is imported, a determination is made regarding its sufficiency, efficacy and safety. If it is sufficient, effective and safe, a blueprint may be generated. If it is not sufficient, effective or safe, additional information, programs or images may be requested. The game server or other controlling entity may automatically assign particular materials to the construction of an object or may request a list of materials to be used or the game server or other controlling entity may display a list of objects, materials or code that may not be used, and/or may be used as a viable substitution. In addition to the raw materials and natural resources and code or software to be used in constructing and/or using an object, there may be attributes imbued into the object, for example certain spells, powers, healing, longevity, invincibility, armor piercing ability, clean running, accelerating, strength, healing or any other attribute generally found in virtual objects. Once the specifications for an object are provided, determinations may be made regarding the amount of materials and the skills required to produce an object to match the imported subroutine.

Virtual natural resources and raw materials used to make virtual objects may be purchased, found, harvested, gathered, mined, husbanded, grown, distilled, raised, leeched, pumped, drilled, purified, stolen or otherwise acquired from the game environment. Information regarding virtual natural resources may be stored, for example, in natural resources database 338 and may include information such as, but not limited to: resource ID, resource descriptor, last market value, maximum allowed, issued to date, remaining to be issued, permit price, available date range, resource attributes 1-n, renewability, perishability, decay rate and level in which it exists. Raw material database 330 may include, for example, raw material ID, raw material type, location, first date available, conditions for use, conditions for discovery, conditions for availability, max quantity allowed, quantity issued, quantity remaining, license or permit fee, resource attributes, renewability, level at which it exists, expiration date, natural decay rate/perishability factor, and available times during the game.

The requesting character's assets may be inventoried to determine if they possess the necessary materials to make the requested virtual object. Information regarding the character and the player controlling the character may be stored, for example in player database 344 and player character database 346, respectively. Player database 344 may include information such as, but not limited to, player ID, the character(s) controlled by the player, blueprints imported, design concepts, objects created, subroutines imported, billing information, account information and personal information. Player character database 346 may include information such as, but not limited to, character ID, player ID, assets, skills, obligations, objects created, objects requested, raw materials, natural resources, rates for use of skills, and game environment access.

If they do not have the necessary materials, the name of a supplier or list of available substitutions may be requested. If they do have the necessary materials, an assessment regarding their skills may be made. Such assessments may be made in either order or any order. For example, in some embodiments it may be determined if a character has the necessary skills and once that determination is made, an assessment may be made regarding the materials needed for constructing the object. If they have the necessary skills, their trustworthiness may be determined. If they have the necessary skills and can be trusted, they may be permitted to make the object. If they do not have the necessary skills or they cannot be trusted, they may request the game server, an NPC or another character assemble the object. Information regarding the skills and NPCs available in a particular environment may be stored for example, in skill database 336 and NPC database 334 respectively. Skill database 336 may contain information such as the skill ID, type, conditions for use, available era(s), characters with skills, skill levels, and use of skills. NPC database 334 may include information such as NPC ID, type, location, conditions for use, license or permit fee, available eras, costs for use, and skills. In some embodiment, the particular characters or NPCs with the necessary skills may not exist in that game environment. Information regarding players with characters or NPCs with the necessary skills in other game environments may be stored, for example, in Player database 310. Player database 310 may include information regarding the players in a virtual environment, their ID(s), the character(s) they control, the skills and assets of the characters, billing information and the game environments in which the players have characters. The costs for assembling the virtual object may be determined based on who assembles the virtual object.

In one embodiment, a character may only be able to request the formation of objects that they have the ability or are trusted to assemble. In another embodiment, a player character may only be able to request the formation of objects that they can use or can afford to use or are permitted or trusted to use. In a further embodiment a player character may request or assemble any virtual object for which they have the necessary skills. In yet another embodiment, subroutines may not need to be created in a virtual environment, but may simply appear in the possession of the designer. Characters may also request that an object be assembled by a third party such as the game server, an NPC or other player character.

Information regarding all finished objects may be stored, for example, in new item database 312. New item database 312 may include information such as new item ID, creator ID, new item digital images, new item blueprints, new item materials, new item construction cost, and new item salvage value.

Within a specific game environment, information regarding newly created items may be stored, for example in new item database 332. Such newly created items may be linked to the requester and creator of new items and new item database 332 may include information such as new item ID, originating character ID, creating character ID, required skills for replication, new item digital images, new item algorithms, new item blue prints, new item materials, new item construction cost and availability.

In one embodiment, exchanges may be used to acquire particular subroutines and resources for assembling an object. In one embodiment, a character can acquire all of some of the resources and skills needed to assemble a virtual object from an exchange. In another embodiment, a description of a subroutine or an image of the finished product can be posted on an exchange and player characters having the appropriate skills can bid to assemble the item. Such bids may or may not include the raw materials necessary to build the item. If raw materials are not included, the player making the request may be expected to supply, purchase or otherwise acquire (e.g., pillage, plunder, or steal) the raw materials and/or the component parts. The player character who posted the item can then accept one of the bids posted on the exchange to assemble the item.

The value of items on an exchange and the determination of the value to different games and game environments may be calculated by any means applicable. In one embodiment, exchange multiplier database 342 may track the exchange ID number and track or store the multiplier number calculated by exchange multiplier determination program 326 for purchases and acquisitions of objects or resources between exchanges, game environments, game environment jurisdictions and/or games. In some embodiments, game attribute valuation program 324 may track and/or calculate the market for particular game attributes, whether finished objects or parts of objects. In yet another embodiment, the value, price, cost to manufacture or use and/or to import or construct an object may be based in whole or in part on the trustworthiness of the player or player character. For example, if a player can generally be trusted, but on occasion has proven untrustworthy, such player character may pay more to import or construct a new item or object as compared with a player or player character that has proven to be highly trustworthy over a relatively long period of time.

Once the blueprints are created and the resources and skills are acquired or hired, and/or the player character has been authorized to proceed, a virtual object may be assembled. Such an assembly may take place using any means applicable. In one embodiment, the actions of characters and NPCs in constructing an object may be executed using game item assembly program 322.

Payment terms for items acquired on exchanges or through other means, and for the use of services or resources may be established by the game, players and/or agreed to between the requesting player and the supplier player or NPC. Terms may created using any financial arrangement including but not limited to: cash up front, partial initial payment and lump sum upon completion, credit card or other financing instrument, series of equal or unequal payments, total amount upon completion, etc. Methods to provide for use of credit cards and other financial instruments in virtual environments are disclosed in U.S. patent application Ser. Nos. 11/279,991, 11/380,489, and 11/421025, each of which is hereby incorporated by reference in its entirety for all purposes.

In some embodiments, players or characters or virtual or other businesses, NPCs or other third parties may hire other players and characters, virtual or other businesses, or NPCs or other third parties to create objects for them. Offers to assemble objects and requests to have objects made can be assembled by any means desired. In one embodiment, the game serve or other managing entity may match requests to have objects made with those with appropriate skills or other credentials, such as trustworthiness. In another embodiment, there may be a means to post requests to have objects made or offers to make objects. Such postings may be made in the marketplace section of the game, for example through a vendor stall or business; in a trade chat window of the game; in an email that is sent to qualified non-player characters; in a database; through a business directory; through solicitations by businesses through electronic mail, pop up windows, in game alerts, regular mail, screen or other alerts, instant messaging; through an exchange; via an auction, or any other means calculated to attract the notice of potentially interested parties. Arrangements to create objects for others may be agreed to using a contract, for example, a player-to-player contract.Player to player contracts are discussed in further detail in U.S. patent application Ser. Nos. 11/355,232, and 11/624,662, each of which is hereby incorporated by reference.

An exemplary system 400 configured to provide a virtual environment as described above is shown in FIG. 6. As shown in FIG. 6, system 400 includes a master game server 402 for running the game and a game environment server 404 for one or more game environments within the game. Master game server 402 may host a program such as game environment creation and set up program 406, and digital file import program 414. Master game server 402 may further host a plurality of databases including, for example, game environment database 408, player database 410 and new item database 412. Game environment server 404 may host a plurality of programs including, for example, object creation program 420, game item assembly program 422, game attribute valuation program 424, exchange multiplier determination program 426, and contract generation program 428.

Game Environment server 404 may include a plurality of databases including, for example, new item database 432, raw material database 430, NPC database 434, skill database 436, natural resources database 438, new item contract database 440, exchange multiplier database 442, player database 444 and character database 446.

The ability to create a virtual object in a virtual environment may depend in some part on the type and/or state of one or more game environments and/or the game in which a character resides or interacts. For example, particular game environments may have limitations on the types of objects that may be created, imported, traded, or used in that game environment, there may be limitations based on the era of the game environment, the resources in the game environment, or the type of programs that may be created, imported, traded and used in a game environment. In some embodiments, the limitation may be on the object in its entirety or may be on the timing or making the object in that environment. For example, certain environments may be environmentally conscious and therefore do not allow smelting to occur in that environment, however they may allow the importation of finished extracts or the product of finished extracts to be brought into the environment. Such regulations may be determined during game environment creation and setup, or anytime thereafter, using game environment creation and set up program or may be determined as the game evolves. In one embodiment, the rules and regulations for a game environment may be formulated when the game environment is formed, using game environment creation and setup program 406. In another embodiment, the rules and regulations for a game environment may evolve as the game progresses. Such information may be stored in a game environment database, for example, in game environment database 408. In some embodiments, game environment database 408 may store information regarding the game environment such as the game environment ID, identification of the owners, percentage ownership, governance structure, configurations, natural resources, raw materials, allowable technologies, prohibited technologies, allowable objects, prohibited objects, import restrictions, export restrictions, creation date, fee structure, or any other information relating to the game environment.

Design concepts for objects may be acquired by the game environment by any means applicable. In one embodiment, design concepts may be imported using digital file import program 414. Once an imported design concept is determined to be acceptable to a particular game environment, the image or subroutine may be converted into blueprints for creating the requested virtual object. Blueprints may contain all or some of the design elements of a concept or may contain a general outline of the object sought to be replicated. In one embodiment, blueprints may include information regarding the materials to be used and/or the skills required to assemble an object. In some embodiments, some or all of a blueprint may be acquired, for example, from a design database. A design database may include images of items that may be used as part of virtual objects, as inspiration for virtual objects, blueprints for objects created by other players, businesses, third parties, subroutines and programs for a virtual object, and decorative elements. Combinations of original designs, images and stored designs, images, blueprints and decorative elements may be compiled using, for example, object creation program 420.

When an image is imported, a determination is made regarding its sufficiency. If it is sufficient, a blueprint or other plan is generated. The game server or other controlling entity may automatically assign particular materials to the construction of an object or may request a list of materials to be used. In addition to the raw materials and natural resources to be used in constructing an object, there may be attributes imbued into the object, for example certain spells, powers, healing, longevity, invincibility, armor piercing ability, clean running, accelerating, strength, healing or any other attribute generally found in virtual objects. Once the specifications for an object are provided, determinations may be made regarding the amount of materials and the skills required to produce an object to match the plan or blueprint.

Virtual natural resources and raw materials used to make virtual objects may be purchased, found, harvested, gathered, mined, husbanded, grown, distilled, raised, leeched, pumped, drilled, purified or otherwise acquired from the game environment. Information regarding virtual natural resources may be stored, for example, in Natural Resources Database 438 and may include information such as, but not limited to: resource ID, resource descriptor, last market value, maximum allowed, issued to date, remaining to be issued, permit price, available date range, resource attributes 1-n, renewability, perishability, decay rate and level in which it exists. Raw material database 430 may include, for example, raw material ID, raw material type, location, first date available, conditions for use, conditions for discovery, conditions for availability, max quantity allowed, quantity issued, quantity remaining, license or permit fee, resource attributes, renewability, level at which it exists, expiration date, natural decay rate/perishability factor, and available times during the game.

The requesting character's assets may be inventoried to determine if they possess the necessary materials, skills, permits, licenses, funds or assets to pay for a requested virtual object. Information regarding the character and the player controlling the character may be stored, for example in player database 444 and player character database 446, respectively. Player database 444 may include information such as, but not limited to, player ID, the character(s) controlled by the player, blueprints imported, design concepts, objects created, subroutines imported, billing information, account information and personal information. Player character database 446 may include information such as, but not limited to, character ID, player ID, assets, skills, obligations, objects created, objects requested, raw materials, natural resources, rates for use of skills, and game environment access.

In one embodiment, a character may only be able to request the formation objects that they have the ability to assemble. In another embodiment, a player character may only be able to request the formation of objects that they can use. In a further embodiment a player character may request or assemble any virtual object for which they have the necessary skills. Characters may also request that an object be assembled by a third party such as the game server, an NPC or other player character.

In one embodiment, an object may be created using some or all of the method steps in FIG. 7. For example, the game server may receive a request to import an image. If the image is sufficient to generate a blueprint, a blueprint will be generated. Information may be requested regarding the materials and attributes to be used to assemble the object and a list of skills and other resources required to make the object may be outfitted. In some embodiments, the contract may include additional terms such as a time limit, a price, one or more digital photos of an item to assemble, a list of materials the object needs to be made from, and a list of additional attributes or specific requirements that the requester wants included in the object. Such a list may be assembled into a description upon which other players, characters or NPCs may bid to do the work. The bids may be submitted to the requesting character who may or may not accept a bid.

In one embodiment, a bid may be met by a counteroffer. System 400 may be configured to negotiate a contract using some or all of the following steps:

• • 1. Submit bid on proposed contract.
  • 2. Receive a counter offer to a contract offer to assemble an item from a blueprint, including a counter offer price and assembly date from a player character
  • 3. Store and output offer to the player character who initially created the contract offer.
    If a bid or counteroffer is accepted, a contract may be generated, for example using contract generation program 428 and an accepted contract may be stored in new item contract database 440. In one embodiment, system 400 may be configured to accept a contract to build an item by performing steps such as:
  • 1. Create a contract to build an item, including the item record, the date of completion, the necessary skills, the actual virtual assets need to assemble the item, and a contract price from a player character.
  • 2. Store contract offer.
  • 3. Withdraw contract offer price, plus applicable fees, from player character account.

In some embodiments, no single character or NPC may have all of the necessary skills or resources to construct an object. It may therefore be necessary to assemble a group of characters and/or NPCs and/or make use of the services of a real or virtual business entity. Bids may therefore be submitted on a part, sub-part or the entirety of the contract. In one embodiment, a contract may be entered into with a general contractor who is then responsible for hiring, finding, organizing, managing, and paying for all necessary resources and/or players or NPCs to build an item. In another embodiment, contracts may be between or among multiple parties.

In one embodiment, system 400 may be configured to generate a new item contract using some or all of the following steps:

• • 1. Generate blue print of item from digital images from a first player character.
  • 2. Receive list of materials
  • 3. Determine material amounts.
  • 4. Create and save request to assemble contract.
  • 5. Receive request to fulfill contract.
  • 6. Receive price to fulfill contract.
  • 7. Output price to fulfill contract to first player character.
  • 8. Receive acceptance price.
  • 9. Output acceptance of price to second player character.
  • 10. Create and store contract.

An evaluation may be made of the materials and other resources owned by the contractor, services provider, third party or requesting character. If they do not have the necessary materials, the name of a supplier may be requested. If they do have the necessary materials, an assessment regarding their skills may be made. Such an assessment may be made in any or either order, or simultaneously. If they have the necessary skills, or are otherwise authorized to produce or deliver the requested object, they may be permitted to make the object. If they do not have the necessary skills or authorization, they may be required to find a subcontractor. Information regarding the skills and suppliers, or NPCs available in a particular environment may be stored for example, in skill database 436 and NPC database 434 respectively. Skill database 436 may contain information such as the skill ID, type, conditions for use, available era(s), characters with skills, skill levels, and use of skills. NPC database 434 may include information such as NPC ID, type, location, conditions for use, license or permit fee, available eras, costs for use, and skills. In some embodiments, the particular characters or NPCs with the necessary skills may not exist in that game environment. Information regarding players with characters or NPCs with the necessary skills in other game environments may be stored, for example, in Player database 410. Player database 410 may include information regarding the players in a virtual environment, their ID(s), the character(s) they control, the skills and assets of the characters, billing information and the game environments in which the players have characters. The costs for assembling the virtual object may be determined based on who assembles the virtual object.

Once the necessary skills, raw materials, natural resources and NPCs for making an object have been assembled, the contract may be fulfilled. System 400 may fulfill a new item contract using some or all of the following steps:

• • 1. Receive an acceptance of a contract offer to assemble an item from a blueprint
  • 2. Receive an indication that a contract has been completed
  • 3. Flag item record as complete
  • 4. Transmit payment for fulfilling contract, less applicable fees, to player character

Such routines may be executed, for example, using game item assembly program 422.

In another embodiment, an item may be requested by a first character and then sold to a second character. Such a transaction may occur using some or all of the following steps:

• • 1. Assemble and output item to a first player character.
  • 2. Send item complete message to second player character.
  • 3. Receive payment amount or barter object from second player character.
  • 4. Receive item from first player character.
  • 5. Release payment or barter object to first player character.
  • 6. Release item to second player character.

The price for constructing a virtual object or for a finished virtual object may be determined, for example, using game attribute valuation program 424.

Information regarding all finished objects may be stored, for example, in new item database 412. New item database 412 may include information such as new item ID, creator ID, new item digital images, new item blueprints, new item materials, new item construction cost, and new item salvage value.

Within a specific game environment, information regarding newly created items may be stored, for example in new item database 432. Such newly created items may be linked to the requester and creator of new items and new item database 432 may include information such as new item ID, originating character ID, creating character ID, required skills for replication, new item digital images, new item algorithms, new item blue prints, new item materials, new item construction cost and availability.

In one embodiment, offers for contracts, contracts and resources for assembling an item may be bought and sold on an exchange. In one embodiment, a blueprint can be posted on an exchange and player characters having the appropriate skills can bid to assemble the item. Such bids may or may not include the raw materials or permits necessary to build the item. If raw materials or permits are not included, the player making the request may be expected to supply, purchase or otherwise acquire (e.g., pillage, plunder, or steal) the raw materials and/or the component parts and/or the permits. The player character who posted the item can then accept one of the bids posted on the exchange and form a contract with the winning bidder.

The value of items on an exchange and the determination of the value to different games and game environments may be calculated by any means applicable. In one embodiment, exchange multiplier database 442 may track the exchange ID number and track or store the multiplier number calculated by exchange multiplier determination program 426 for purchases and acquisitions of objects or resources between exchanges, game environments, game environment jurisdictions and/or games. In some embodiments, game attribute valuation program 424 may track and/or calculate the market for particular game attributes, whether finished objects or parts of objects.

Payment terms for items acquired on exchanges or through other means may be established by the game, players and/or agreed to between the requesting player and the supplier player or NPC and/or any other interested or affected parties. Terms may created using any financial arrangement including but not limited to: cash up front, partial initial payment and lump sum upon completion, credit card or other financing instrument, series of equal or unequal payments, total amount upon completion, etc. Methods to provide for use of credit cards and other financial instruments in virtual environments are disclosed in U.S. patent application Ser. Nos. 11/279,991, 11/380,489, and 11/421,025, each of which is hereby incorporated by reference in its entirety for all purposes

In one embodiment, created virtual objects, designs for created virtual objects, blueprints for virtual objects, contracts, virtual natural resources, raw materials, skills, and NPCs, may be sold or traded on a virtual exchange. Such an exchange is further described in detail in U.S. patent application Ser. Nos. 11/428,263, filed Jun. 30, 2006, and Ser. No. 11/560,456, filed Nov. 16, 2006, each of which is herein incorporated by reference in its entirety. An embodiment of an exchange system is shown in FIG. 8. As shown, system 500 includes a master game server 502 a game environment server 506 and an exchange server 504.

Game environment server 506 may include databases such as player database 514, player character database 516, exchange open offers database 528, exchange transaction database 520.

In one embodiment, Player Database 514 may include information such as, but not limited to player ID, player billing info, player personal info, player credit info, and player assets. Player Character Database 516 may include information such as, but not limited to, character ID, player ID, character assets, character inventory, character Skills, virtual account numbers, character permits, NPC employment.

Exchange Server 504 may include or host various programs, routines, subroutines and/or databases including, but not limited to an exchange database 508, an exchange open offers database 510, and an exchange transaction database 512.

In one embodiment, Exchange database 508 may include information such as, but not limited to, exchange ID, exchange type, allowable assets, and allowed traders. Exchange open offers database 510 could contain information such as:

• • 1. Offer ID
  • 2. Offer type
  • 3. Offer posting date
  • 4. Offer expiration date
  • 5. Offer Item
  • 6. Offer Quantity
  • 7. Offer Price.

Exchange open offers may additionally be associated with the character or player submitting the offer. Such information could be stored in Exchange Open Offer Database 528 and include information such as the character ID, holdings, offer ID, offer type, offer posting date, offer expiration date, offer item, offer quantity, and offer price.

In one embodiment, each transaction could be stored in an Exchange Transaction Database, for example in Exchange Transaction Database 512. Such a database could store information such as:

• • 1. Order ID
  • 2. Order Buyer
  • 3. Order Seller
  • 4. Order Date
  • 5. Order Price
  • 6. Order Type
  • 7. Order terms and conditions
    In another embodiment, such transactions could be associated with the character in Exchange Transaction Database 520. Such a database could include information such as character ID, character inventory, order ID, order date, order, price, order type, and/or authentication number.

According to one embodiment, the game server can set a minimum and maximum trade amount per time period on currency and other virtual resources both in the game environment and between or among multiple game environments. This amount could be based on any one or more of: the total amount of a virtual resource available in a game parameter; the amount per player character of a virtual resource available in a game parameter; the amount of open buy orders for a virtual resource in a game environment; the amount of open sell orders for a virtual resource in a game environment; any other factors and/or rules and regulations as disclosed herein. In another embodiment, there may be permits required or import and export taxes and/or currency conversion or other fees imposed on items exchanged between game environments or between games. Such calculations may be made, for example, using some or all of the following steps:

• • 1. Receive a request to sell a virtual item on an exchange.
  • 2. Determine if item is unique.
  • 3. Determine if a permit exists to sell the item.
  • 4. If the item is unique and a permit exists, post item on exchange.
  • 5. Receive acceptance of request.
  • 6. Determine an import tax amount and an export tax amount.
  • 7. Apply import tax amount to purchase price.
  • 8. Withdraw virtual cash equal to purchase price plus tax from buyer.
  • 9. Transmit purchase price, less applicable export tax fees to seller.

Items bought and sold on the exchange may generate virtual currency, and/or real currency and/or may generate an exchange of assets. The value of a currency or an asset may be based on a conversion factor as described above or on an exchange rate.

The exchange rate for one type of virtual currency for another type of virtual or real currency, virtual currency for real currency, virtual assets for real assets, real assets for virtual assets, real assets for virtual currency, virtual assets for real currency or virtual assets for virtual currency (or any combination of these) may be fixed in that the rate does not change for the duration of the game or segment of the game. Alternatively, the exchange or conversion rate may be variable or market based. Such a variable rate may be pegged to a floating real world exchange relationship, for example the U.S. dollar/Japanese yen spot exchange rate, a percentage thereof, a plus or minus adjustment thereof, some other economic indicator, or a combination thereof. The exchange rate may also vary depending on the country of origin of the player, or may be fixed to a particular real world currency, i.e., all exchange rates are quoted in dollars. In another embodiment, the exchange rate may be floating and determined by market forces such as the relative demand for virtual currency versus real world currency, or the relative demand of particular types of virtual currency, or based upon the affect of said rates on one or more game objectives or goals. Said exchange rates may further be established or determined by any suitable method including, but not limited to, by a) the game manufacturer, b) the owner(s) of the server(s) upon which the game resides, c) one or more player characters, d) market forces, e) law or regulation of the game or within the real world, f) negotiation among the affected parties, g) game objectives, or h) any combination of the above.

It will be appreciated that while, for the sake of discussion, various databases have been described separately, the data in these and any other suitable databases could be merged into a single large databases and/or maintained separately in additional databases, or in other structures besides a database. Moreover, any such databases could be independent or linked, and the data in these databases could be stored centrally on a server or separately on game devices.

The present disclosure provides numerous systems and methods related to virtual environments in online computer games. It should be appreciated that numerous embodiments are described in detail and that various combinations and subcombinations of these embodiments are contemplated by the present disclosure.

Conclusion

Of course it will be appreciated that the systems methods described herein are provided for the purposes of example only and that none of the above systems methods should be interpreted as necessarily requiring any of the disclosed components or steps nor should they be interpreted as necessarily excluding any additional components or steps. Furthermore, it will be understood that while various embodiments are described, such embodiments should not be interpreted as being exclusive of the inclusion of other embodiments or parts of other embodiments.

The invention is described with reference to several embodiments. However, the invention is not limited to the embodiments disclosed, and those of ordinary skill in the art will recognize that the invention is readily applicable to many other diverse embodiments and applications as are reflected in the range of real world financial institutions, instruments and activities. Accordingly, the subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various systems, methods configurations, embodiments, features, functions, and/or properties disclosed herein.

Where a limitation of a first claim would cover one of a feature as well as more than one of a feature (e.g., a limitation such as “at least one widget” covers one widget as well as more than one widget), and where in a second claim that depends on the first claim, the second claim uses a definite article “the” to refer to the limitation (e.g., “the widget”), this does not imply that the first claim covers only one of the feature, and this does not imply that the second claim covers only one of the feature (e.g., “the widget” can cover both one widget and more than one widget).

Each claim in a set of claims has a different scope. Therefore, for example, where a limitation is explicitly recited in a dependent claim, but not explicitly recited in any claim from which the dependent claim depends (directly or indirectly), that limitation is not to be read into any claim from which the dependent claim depends.

When an ordinal number (such as “first”, “second”, “third” and so on) is used as an adjective before a term, that ordinal number is used (unless expressly specified otherwise) merely to indicate a particular feature, such as to distinguish that particular feature from another feature that is described by the same term or by a similar term. For example, a “first widget” may be so named merely to distinguish it from, e.g., a “second widget”. Thus, the mere usage of the ordinal numbers “first” and “second” before the term “widget” does not indicate any other relationship between the two widgets, and likewise does not indicate any other characteristics of either or both widgets. For example, the mere usage of the ordinal numbers “first” and “second” before the term “widget” (1) does not indicate that either widget comes before or after any other in order or location; (2) does not indicate that either widget occurs or acts before or after any other in time; and (3) does not indicate that either widget ranks above or below any other, as in importance or quality. In addition, the mere usage of ordinal numbers does not define a numerical limit to the features identified with the ordinal numbers. For example, the mere usage of the ordinal numbers “first” and “second” before the term “widget” does not indicate that there must be no more than two widgets.

When a single device or article is described herein, more than one device/article (whether or not they cooperate) may alternatively be used in place of the single device/article that is described. Accordingly, the functionality that is described as being possessed by a device may alternatively be possessed by more than one device/article (whether or not they cooperate).

Similarly, where more than one device or article is described herein (whether or not they cooperate), a single device/article may alternatively be used in place of the more than one device or article that is described. For example, a plurality of computer-based devices may be substituted with a single computer-based device. Accordingly, the various functionality that is described as being possessed by more than one device or article may alternatively be possessed by a single device/article.

The functionality and/or the features of a single device that is described may be alternatively embodied by one or more other devices which are described but are not explicitly described as having such functionality/features. Thus, other embodiments need not include the described device itself, but rather can include the one or more other devices which would, in those other embodiments, have such functionality/features.

Numerous embodiments are described in this patent application, and are presented for illustrative purposes only. The described embodiments are not, and are not intended to be, limiting in any sense. The presently disclosed invention(s) are widely applicable to numerous embodiments, as is readily apparent from the disclosure. One of ordinary skill in the art will recognize that the disclosed invention(s) may be practiced with various modifications and alterations, such as structural, logical, software, and electrical modifications. Although particular features of the disclosed invention(s) may be described with reference to one or more particular embodiments and/or drawings, it should be understood that such features are not limited to usage in the one or more particular embodiments or drawings with reference to which they are described, unless expressly specified otherwise.

The present disclosure is neither a literal description of all embodiments of the invention nor a listing of features of the invention which must be present in all embodiments.

Neither the Title (set forth at the beginning of the first page of this patent application) nor the Abstract (set forth at the end of this patent application) is to be taken as limiting in any way as the scope of the disclosed invention(s). An Abstract has been included in this application merely because an Abstract of not more than 150 words is required under 37 C.F.R. §1.72(b).

The title of this patent application and headings of sections provided in this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.

Devices that are described as in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. On the contrary, such devices need only transmit to each other as necessary or desirable, and may actually refrain from exchanging data most of the time. For example, a machine in communication with another machine via the Internet may not transmit data to the other machine for long period of time (e.g. weeks at a time). In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

A description of an embodiment with several components or features does not imply that all or even any of such components/features are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention(s). Unless otherwise specified explicitly, no component/feature is essential or required.

Although process steps, algorithms or the like may be described in a sequential order, such processes may be configured to work in different orders. In other words, any sequence or order of steps that may be explicitly described does not necessarily indicate a requirement that the steps be performed in that order. On the contrary, the steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to the invention, and does not imply that the illustrated process is preferred.

Although a process may be described as including a plurality of steps, that does not imply that all or any of the steps are essential or required. Various other embodiments within the scope of the described invention(s) include other processes that omit some or all of the described steps. Unless otherwise specified explicitly, no step is essential or required.

Although a product may be described as including a plurality of components, aspects, qualities, characteristics and/or features, that does not indicate that all of the plurality are essential or required. Various other embodiments within the scope of the described invention(s) include other products that omit some or all of the described plurality.

Unless expressly specified otherwise, an enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are mutually exclusive. Therefore it is possible, but not necessarily true, that something can be considered to be, or fit the definition of, two or more of the items in an enumerated list. Also, an item in the enumerated list can be a subset (a specific type of) of another item in the enumerated list. For example, the enumerated list “a computer, a laptop, a PDA” does not imply that any or all of the three items of that list are mutually exclusive—e.g., an item can be both a laptop and a computer, and a “laptop” can be a subset of (a specific type of) a “computer”.

Likewise, unless expressly specified otherwise, an enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are collectively exhaustive or otherwise comprehensive of any category. For example, the enumerated list “a computer, a laptop, a PDA” does not imply that any or all of the three items of that list are comprehensive of any category.

Further, an enumerated listing of items does not imply that the items are ordered in any manner according to the order in which they are enumerated.

In a claim, a limitation of the claim which includes the phrase “means for” or the phrase “step for” means that 35 U.S.C. §112, paragraph 6, applies to that limitation.

In a claim, a limitation of the claim which does not include the phrase “means for” or the phrase “step for” means that 35 U.S.C. §112, paragraph 6 does not apply to that limitation, regardless of whether that limitation recites a function without recitation of structure, material or acts for performing that function. For example, in a claim, the mere use of the phrase “step of” or the phrase “steps of” in referring to one or more steps of the claim or of another claim does not mean that 35 U.S.C. §112, paragraph 6, applies to that step(s).

With respect to a means or a step for performing a specified function in accordance with 35 U.S.C. §112, paragraph 6, the corresponding structure, material or acts described in the specification, and equivalents thereof, may perform additional functions as well as the specified function.

Computers, processors, computing devices and like products are structures that can perform a wide variety of functions. Such products can be operable to perform a specified function by executing one or more programs, such as a program stored in a memory device of that product or in a memory device which that product accesses. Unless expressly specified otherwise, such a program need not be based on any particular algorithm, such as any particular algorithm that might be disclosed in this patent application. It is well known to one of ordinary skill in the art that a specified function may be implemented via different algorithms, and any of a number of different algorithms would be a mere design choice for carrying out the specified function.

Therefore, with respect to a means or a step for performing a specified function in accordance with 35 U.S.C. §112, paragraph 6, structure corresponding to a specified function includes any product programmed to perform the specified function. Such structure includes programmed products which perform the function, regardless of whether such product is programmed with (i) a disclosed algorithm for performing the function, (ii) an algorithm that is similar to a disclosed algorithm, or (iii) a different algorithm for performing the function.

The present disclosure provides, to one of ordinary skill in the art, an enabling description of several embodiments and/or inventions. Some of these embodiments and/or inventions may not be claimed in this patent application, but may nevertheless be claimed in one or more continuing applications that claim the benefit of priority of this patent application. Applicants intend to file additional applications to pursue patents for subject matter that has been disclosed and enabled but not claimed in this patent application.

Claims

1. A method comprising:

providing a first video game environment;

receiving a digital rendering for a game object from a first player character interacting in the first game environment;

converting the digital rendering to a blueprint for the object;

determining the materials required to construct the object in the virtual environment.

2. The method of claim 1 further comprising determining if the materials used to construct the object are acceptable.

3. The method of claim 2 wherein determining if the materials used to construct the object are acceptable comprises:

determining if the game environment comprises multiple game phases;

determining which game phase the first player character was interacting in when the blueprint was constructed; and

determining if the materials needed to construct the object exist in the game phase in which the first player character was interacting.

4. The method of claim 1 wherein each player character interacting in the game environment possesses one or more skills, the method further comprising:

determining the skills required to build the object in the blueprint;

determining whether the first player character possesses the required skills.

5. The method of claim 4 further comprising only authorizing the player character to build the object if the first player character possesses the required skills.

6. The method of claim 4 further comprising, if the first player character does not possess the required skills, identifying to the first player character one or more other player characters who do possess the required skills.

7. The method of claim 4, further comprising if the first player character does not possess the required skills, allowing the first player character to outsource construction of the object.

8. The method of claim 4, further comprising, if the first player character does not possess the required skills, a means for acquiring the necessary skills to assemble the object.

9. The method of claim 1, wherein aspects of the digital rendering are obtained from a database of digital renderings in the video game environment.

10. A method comprising:

providing a first video game environment;

receiving a digital rendering for a game object from a first player character interacting in the first game environment;

converting the digital rendering to a blueprint for the object;

determining the skills required to construct the object in the virtual environment;

allowing second player characters with the requisite skills to bid on construction of the object.

11. The method of claim 10, wherein second player characters with the requisite skills may exist in the same or different game environments as the first player character.

12. The method of claim 10, wherein the first player character selects a bid to construct the object.

13. The method of claim 10, wherein selection of the bid forms a contract between the first player character and the second player character.

14. The method of claim 10, wherein the second player character is an NPC.

15. The method of claim 10, wherein the digital rendering is a digital photograph.

16. The method of claim 10, wherein the digital rendering is a digital drawing.

17. A method comprising:

providing a video game environment;

providing a virtual exchange configured to allow for the sale and purchase of game created objects;

receiving requests for sales and purchases of game created objects via the exchange from player characters interacting with the video game environment; and

altering the player accounts of the player characters according to the sales and purchases on the exchange.

18. The method of claim 17 further comprising determining a conversion rate for game created objects offered for sale on the exchange.

19. The method of claim 17 wherein the exchange is configured to receive and manage requests for sales and purchases of game created objects between two or more game environments.

20. The method of claim 17, wherein the two or more game environments may exist in different games.