Virtual Environments

Priority Claim and Cross-Reference to Related Applications [0001] The following application claims priority to U.S. Patent

Application Serial Nos. 11/535,577 filed November 27, 2006 and 11/535,585, filed November 27, 2006, which both claim priority to U.S. Patent Application Serial No. 11/421,025 filed May 30, 2006, which claims priority to U.S. Provisional Application Serial No. 60/727,121 filed October 14, 2005. The following application also claims priority to U.S. Patent Application Serial Nos. 11/368,143, filed March 7, 2006, 11/421,026, filed May 30, 2006, 11/279,991 , filed April 17, 2006 and 11/280,489, filed April 27, 2006, all of which also claim priority to U.S. Provisional Application Serial No. 60/727,121 filed October 14, 2005. Each of the above-referenced applications is hereby incorporated by reference in their entirety for all purposes

Background

[0002] 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. [0003] 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

[0005] Fig. 1 is a block diagram depicting a network according to an embodiment of the present disclosure.

[0006] Fig. 2 is a block diagram of a system 10 according to one embodiment of the present invention.

[0007] Fig. 3 is a schematic screen shot of a bank menu according to one embodiment of the present invention. [0008] Fig. 4 is a schematic screen shot of a transaction history according to one embodiment of the present invention. [0009] Fig. 5 is a schematic screen shot of a type of information required to open an account according to one embodiment of the invention [0010] Fig. 6 is a schematic screen shot of a type of information required to open an account according to one embodiment of the invention. [0011] Fig. 7 is a schematic screen shot of the initiation of a deposit transaction according to one embodiment of the present invention. [0012] Fig. 8 is a schematic screen shot of the initiation of a withdrawal transaction according to one embodiment of the invention. [0013] Fig. 9 is a schematic screen shot of an embodiment of a virtual currency purchase of the invention.

[0014] Fig. 10 illustrates a method for opening a bank according to one embodiment of the invention.

[0015] Fig. 11 illustrates a method for opening an account according to one embodiment of the invention.

[0016] Fig. 12 illustrates a method for depositing money in an account according to one embodiment of the invention. [0017] Fig. 13 is a block diagram depicting a system 100 according to one embodiment of the present invention. [0018] Fig. 14 illustrates a method of applying for a loan according to one embodiment of the invention.

[0019] Fig. 15 is a schematic screen shot of a type of a request for a loan.

[0020] Fig. 16 is a schematic screen shot of an array of payment options for a loan.

[0021] Fig. 17 is a schematic screen shot of an acceptance of a loan.

[0022] Fig. 18 illustrates a method of applying for a loan according to one embodiment of the invention.

[0023] Fig. 19 illustrates a method of applying for a loan according to one embodiment of the invention.

[0024] Fig. 20 illustrates a contract generated upon formation of a.

[0025] Fig. 21 loan illustrates a written communication notifying a player that payment on a loan is due.

[0026] Fig. 22 is a block diagram of a system 210 according to one embodiment of the present description.

[0027] Fig. 23 is a block diagram of a system 240 according to another embodiment of the present invention.

[0028] Fig. 24 is a block diagram depicting exemplary databases suitable for use in system 1.

[0029] Fig. 25 is a block diagram of the system shown in Fig. 24 including an Expert Management program.

[0030] Fig. 26 is a block diagram depicting additional exemplary databases suitable for use in a system that includes an Expert Management program.

Detailed Description Definitions:

[0031] Unless stated to the contrary, for the purposes of the present disclosure, the following terms shall have the following definitions: [0032] Credit Card - a credit instrument issued by a real world institution to a player that allows the player to make purchases by providing an account identifier (e.g. a credit card number) rather than 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.

[0033] Virtual credit card - a financial instrument issued in a virtual environment that acts in the virtual environment for virtual currency the way a real world credit card acts in the real world for real currency.

[0034] Real Cash Value - the value in real dollars of the virtual currency. This value can be determined by multiplying the value of a virtual currency amount by the current exchange rate to real dollars.

[0035] Total virtual obligation amount-the total amount of the virtual financial obligation(s) associated with a player character's account.

[0036] Virtual Contract - An enforceable agreement between a first player character and either another player character, a game server, or a third party. Some examples of virtual contracts are provided in U.S.

Provisional Patent Application Serial No. 60/652,036, which is hereby incorporated by reference in its entirety for all purposes.

[0037] Virtual - shall mean in a video game environment or other intangible space.

[0038] Virtual World - a world created in an online game such as

World of Warcraft, or a virtual community such as Second Life, Eve or

There.com.

[0039] Virtual Creditor-shall mean a first player character or other entity who is owed a virtual obligation by a second player character.

[0040] Virtual Credit Score - a score given to player characters in a video game based on one or more of the following criteria: 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 credit card associated with the account, the existing virtual financial obligations of the player character account, the 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.

[0041] Virtual Financial Account - a virtual account issued to a player character by a virtual bank, game server or third party where virtual cash can be deposited and withdrawn.

[0042] Virtual Financial Obligation - An agreement by a player character or entity to pay one or more game attributes to another player character, entity or the game server. This obligation can be a one time payment, or may require multiple payments over time. The obligation may specify when payments and/or interest are due.

[0043] Virtual Financial Intermediary - Financial intermediaries are institutions including depository institutions, contractual savings institutions, and investment intermediaries which offer financial products and services for use within the virtual environment. The various financial intermediaries available in the virtual environment may each serve different or overlapping purposes and provide means for using, saving, borrowing and transferring currency.

[0044] Virtual Financial Obligation Value - the in game value of the obligation. For virtual cash the value may be stated as a virtual and/or real cash amount. For other game attributes, the value can be determined 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.

[0045] Billing Information - shall mean any information pertaining to billing a player for playing a game, accessing a game, purchasing goods or services, or any other reasons. Billing information may include such information as a billing address, 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.

[0046] Character or "player character" - a persona created and controlled by a player in a video game.

[0047] Avatar - the virtual representation of a player character.

[0048] Character Account - an account that tracks character attributes.

[0049] Character Attribute - 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 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

[0050] Character Life - a fixed or variable, finite or infinite period of virtual or real world time that a player character can exist in a game environment.

[0051] Character Skills - game attributes inherent in or acquired by a player character 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, and/or enchant other player characters.

[0052] Computer Generated (CG) or Non-Player (NP) Character

- any character that is controlled by the game system and/or a computer program and/or rules established by the game system and/or a player and not by a player on a continuous basis.

[0053] Game performance parameter - any aspect of a Video

Game by which a player character's performance can be measured. Game

Parameters shall include, but not be limited to:

1. Completing all or part of a mission

2. Playing for a certain period of time

3. Winning a match against another player character or computer generated character

4. Reaching a certain level or score

5. using or obtaining an ability or technology

6. kill/death ratios

7. obtaining, creating or modifying an object

8. solving a puzzle

9. accuracy with weapons

10. effective use of the proper weapon

11. killing a certain character / creature

12. getting through or 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 a child

16. getting married

17. obtaining, buying, trading, producing or developing raw materials

18. producing goods or services

19. earning income

20. earning a higher rank in an army

21.winning an election among two or more player characters

22. achieving deity or other status

23. improving player character status or caste

24. assisting other player characters with any of the above

25. speed of accomplishing or changing the rate or trends of any or all of the above.

[0054] In-game Marketplace - shall mean a virtual environment where Characters can exchange items attributes, or any other exchangeable game element.

[0055] Novice Player - shall mean a player that is identified as requiring the help of an expert to complete a Game Parameter.

[0056] Player - shall mean an individual who can register an account with a Video Game Central Server or within a peer-to-peer network

and create Characters that can interact with other Characters in a Virtual Environment, and/or that can authorize a NPC to act on the player's behalf. [0057] Player Account - shall mean an account on the Video

Game Central Server or within a peer-to-peer network that contains a Player profile including personal, billing, and character account information. [0058] Player Attribute - shall mean any attribute that can be applied to a player account. Player Attributes shall include, but not be limited to:

1. Real 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 [0059] Player to Player Contract - a real and/or virtual but binding contract between player characters that allows the players to provide or exchange game attributes to one another. Once a player-to-player contract is established, the game server or peer-to-peer network automatically distributes acquired game attributes between the player characters based on the contract conditions.

[0060] Video Game - a game played on a Video Game Consul that may or may not be networked to a Video Game Central Server or within a peer-to-peer network.

[0061] Video Game Consul - a device comprising a CPU, memory and optional permanent storage residing at a player location that can allow for the playing of video games. Examples include, home PCs, Microsoft

Xbox, and Sony Playstation.

[0062] Video Game Central Server - 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 to be played.

[0063] Video Game Environment - a virtual video game world that is stored on the combination of the Video Game Central Server and Video

Game Consuls where Characters interact and games are played.

[0064] The term "variation" of an invention means an embodiment of the invention, unless expressly specified otherwise.

[0065] 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.

[0066] The terms "including", "comprising" and variations thereof mean "including but not limited to", unless expressly specified otherwise.

[0067] The term "consisting of and variations thereof mean

"including and limited to", unless expressly specified otherwise.

[0068] The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

[0069] The term "plurality" means "two or more", unless expressly specified otherwise.

[0070] The term "herein" means "in this patent application, including anything which may be incorporated by reference", unless expressly specified otherwise.

[0071] 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.

[0072] 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".

[0073] The term "represent" and like terms are not exclusive, unless expressly specified otherwise. For example, the term "represents" do 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", [0074] 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. [0075] 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".

[0076] The term "determining" and grammatical variants thereof

(e.g., to determine a price, determining a vaiue, 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.

[0077] 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.

[0078] 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. [0079] 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. [0080] 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.

[0081] 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. [0082] 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.

[0083] 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.

[0084] 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.

[0085] 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, 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.

[0086] 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

[0087] 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. [0088] 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. Figure 1 provides an exemplary network which may be used to support a virtual environment. [0089] Referring to Fig. 1, a network 1 according to one embodiment includes a central server 2 in communication with a plurality of video game playing units 4. 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.

[0090] Central server 2 may comprise any computing device

(e.g., one or more computers) capable of communicating with other computing devices. The server 2 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 2 may comprise one or more personal computers, web servers, dedicated game servers, video game consoles, any combination of the foregoing, or the like. [0091] Each video game device 8 may comprise any device capable of communicating with central server 2, 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) and may be wireless or conventionally wired devices. [0092] Some or all of video game 7 can be stored on central server 2. Alternatively, some or all of video game 7 may be stored on the individual video game devices 8. Typically, the video game devices are able to communicate with one another. Such communication may or may not be facilitated by central server 1. Accordingly, a player 9a accessing video game 7 via game device 8a may be able to play with a player 9b accessing video game 7 via game device 8b. As shown, it may be possible for multiple players (e.g. 9c, 9d) to access central server 2 via the same game device (e.g. 8c). Regardless of whether video game 7 is stored on central server 2 or video game devices 8, server 2 is typically configured to facilitate play of the game between multiple game players.

[0093] 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.

[0094] 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.

[0095J While gaming environments as previously described allow for interactions between players, they generally lack sophisticated financial systems. This lack limits financial interactions to trade or barter systems or very rudimentary banking systems which do not have the ability to infuse currency into the virtual world or transfer sums between players and/or through third party intermediaries such that the currency may be used by those other than the original holders to advance play in the game. This limits the ability of the economy of the virtual world to expand and decreases the depth of play available.

[0096] Various embodiments of the invention address this issue by providing services through virtual financial intermediaries similar to those provided by financial intermediaries in the real world. Financial intermediaries include, but are not limited to, depository institutions, contractual savings institutions, and investment intermediaries. Players and player characters can take advantage of the financial products and services offered by these institutions to develop more complex levels of play and increase their interactions in the game. In one embodiment, the virtual financial intermediaries and the services they provide are linked to real world credit lines permitting an increase in the currency available for use within the parameters of the game, thus encouraging growth and development of the virtual environment. The various financial intermediaries available in the virtual environment may each serve different or overlapping purposes and provide means for using, saving, borrowing and transferring currency. [00114] Various embodiments of the invention provide virtual financial intermediaries which provide services similar to those provided by financial intermediaries in the real world. Furthermore, these virtual financial intermediaries are able to facilitate the transfer of funds to the game and within the game, thereby contributing to the development of the game. Financial intermediaries include, but are not limited to, depository institutions, contractual savings institutions, and investment intermediaries. Players and player characters can take advantage of the financial products and services offered by these institutions to accelerate and develop more complex levels of play and increase their interactions in the game. In one embodiment, the virtual financial intermediaries are linked to real world credit lines including

credit cards permitting an increase in the currency available for use within the parameters of the game, thus encouraging growth and development of the virtual environment. The various financial intermediaries available in the virtual environment may each serve different or overlapping purposes and provide means for using, saving, aggregating funds or lines of credit, borrowing and transferring currency.

[00115] In one embodiment, the financial intermediary is a depository institution. The depository institution may be a commercial bank, savings and loan association, mutual savings bank, credit union, mercantile association, cooperative bank or other type of depository institution, which may or may not have a real world counterpart. In another embodiment, the financial intermediary is a contractual savings institution that acquires funds at periodic intervals on a contractual basis. Such institutions include, but are not limited to, life insurance companies, fire and casualty insurance companies and pension funds. In a further embodiment, the financial intermediary is an investment intermediary. Investment intermediaries include, but are not limited to, finance companies, mutual funds, and money market funds. [00116] In one embodiment, there may be a central financial institution which regulates either directly or indirectly (e.g. through monetary policy) financial intermediaries in the game, or in a particular location within the game. In another embodiment, there may be a financial institution that functions as a governing body that may create virtual currency, collect funds, e.g., taxes, to provide a source of funding to sustain a game, a game environment, enforce rules and regulations, protect player characters, protect player and character assets or any combination of the above. Such governing body or central financial institution may be controlled by the majority of player characters, the game server, game manufacturer, a body elected by the player characters to serve in such capacity, or a combination of any one or more of the foregoing.

[00117] For ease of description, the term "bank" is used throughout the present disclosure when describing an exemplary embodiment of a financial intermediary or institution, however it is understood that the processes as described herein may apply to any type of financial intermediary or institution and the types of services they generally provide in the real world.

[00118] An exemplary system 10 configured to provide the virtual environment described above is shown in Fig. 2. As shown, system 10 includes a game server 12, a bank server 14 and a credit card server 16. Game server 12 may include a bank creation program 18 and a bank monitoring program 20. It will be understood that bank server 14 may equally be any other financial intermediary server including a contractual savings institution or investment intermediary server. Such servers 14 may include a deposit program 22, an interest payment program 24, an interest rate determination program 26, a financial backing set up program 28, and financial backing claim payment program 30. Server 14 may further include additional programs appropriate for the type of financial intermediary they represent. For example, an investment intermediary server may include investment programs. Credit card server 16 may include a financial backing payment program 32 and a financial backing claim payment program 34. [00119] The financial intermediaries and institutions for use within the virtual world may be in existence at the formation of the game, or may be formed during the game by one or more players or player characters, real world financial institutions or other legal entities. Moreover, the financial intermediaries and institutions may be run by the game manufacturer, the owner(s) of the server upon which the game resides, player characters, other legal entities, any other duly authorized third parties or a combnation of these. [00120] According to one embodiment, game server 12 may be configured to create a virtual bank using some or all of the following method steps:

1. Receive a request from a player character, group of player characters, or one or more third parties to create a bank.

2. Determine if there is an available charter for the bank based on the game environment and the player characters.

3. If there is an available charter determine and output a charter fee.

4. Receive an acceptance and payment for the charter fee.

5. Create new bank with the player character(s) as owners.

[00121] The request may be made and received using any suitable method within the virtual environment. For example, the request may be sent via email, instant message, or via an on-screen request system. The request

may be processed automatically by the server, by a paid or voluntary player or staff member, or though a combination of the above. [00122] Such method steps also apply to other financial intermediaries and institutions in which one or more player characters or groups of player characters may request to form a financial intermediary or institution. The rules for forming a financial intermediary or institution are governed by the parameters of the virtual environment in that there may be a virtual government or other controlling entity including real world controlling entities such as the game manufacturer or server owner and/or real or virtual laws that may dictate the number of financial intermediaries or institutions in existence at any one time or the requirements for formation and/or dissolution. [00123] According to some embodiments, the game environment, a particular government, or a virtual land area governed by the game environment or by player characters may limit the number of banks that can exist in the environment. Accordingly, there may be a limit on the number of charters that can be given out at any particular time in a virtual environment. In some embodiments, if a bank closes or becomes inoperable, the charter may be forfeited and made revert to the governing entity such that it is available to a new entity desirous of starting a bank, or it may be sold by the player character(s) that own it. The game server and any government formed by the game server or by a group of player characters may charge a tax or fee each time a charter is issued or resold. Such fees could be up front, periodic, or any combination thereof.

[00124] The granting of a charter or the ability to open a financial intermediary may be governed by certain regulations. Such regulations may be imposed by a governing entity, by a central institution, by the game server, game owner, server owner, or group of managing players. These regulations may impose certain requirements that must be met prior to the formation of a financial intermediary. Such requirements may include, for example, the ability to pay a given fee, reserve requirements, availability of land and/or an appropriate building or other assets in the virtual environment, procurement of various suitable skills by the requesting group, etc. In such a case, only those requests that come from an entity that is able to fulfill any imposed requirements will be granted a charter, if one is available.

[00125] The amount of the charter fee may be determined using any method suitable for the virtual environment. It may be established by the game itself, the owners or manufactures of the game, the game server, the owners of the server, a plurality of a predetermined number of players in existence at the time of the creation or acceptance of the charter, by real and/or virtual law, or any combination thereof.

[00126] According to another embodiment, a bank may be required to apply for and/or buy a virtual permit to do business in each location where it has a branch in the game environment. 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 amount of funds in the depository, loans outstanding, revenues generated, interest rates or interest received, number of borrowers, number or percentage of defaulting borrowers, percentage of secured vs. unsecured loans, total number of banks, real or virtual tax rates for similar real or virtual institutions within the game or similar games, 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, which determination may be based upon market forces and/or an auction or reverse auction, and/or by real or virtual laws, or, in the case of one player character or group of player characters wishing to sell their bank to another player characters), for an amount as determined by the sellers and/or as determined by any of the foregoing.

[00127] In another embodiment, bank server 14 may be configured to create a virtual bank using some or all of the following method steps:

1. Create and Output a request to create a bank.

2. Receive a charter fee amount if applicable.

3. Pay license amount if applicable.

4. Receive bank registration identifier.

5. Create virtual bank

[00128] The bank registration identifier may be a number or other identifier that can be associated by the game server to the bank in order to identify the bank as well as any transactions conducted by, through, or otherwise associated with the bank.

[00129] In one embodiment, game server 12 may be configured to create a virtual bank or other financial intermediary using some or all of the method steps outlined in figure 10 wherein a certain minimum number of players decide to form a bank. The game server 12 verifies that the requisite number of players would like to form a bank. Once the minimum number of members has agreed to form a bank, they must apply for a charter, determine if the organizing committee will supply all of the initial funding through deposits or other means and/or solicit shareholders or other third parties to provide additional initial funding. The solicitation of shareholders or other third parties may take place in any type of forum useful for disseminating such information. For example, the organizers may send out a mass e-mail, post an advertisement, contact immediate friends, publish a notice, or any other type of means aimed at contacting interested parties. In an alternative embodiment, player characters may indicate that they are interested in becoming shareholders and may or may not choose to specify the type of financial intermediary they are interested in supporting. The minimum number of committee members and/or the minimum amount of funding may be determined 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) bank charter, e) law or regulation, or f) any combination of the above. The initial funding may be secured by one or more real world credit lines such as credit cards, bank accounts, private or public payment facilitator accounts (for example PayPal), or other financial security of the player characters on the committee, shareholders, other player character, a non-playing third party, such as a bank, credit institution, credit card company, mutual fund, investments, hedge fund, brokerage firm, insurance company, third party individual(s) etc. or any combination of these. In one embodiment, the applicants determine the minimum amount of funding they will require, in another embodiment, the minimum funding may be determined 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) governing body, e) law or regulation, or f) any combination of the above. In one embodiment, the game server 12 will verify the underlying financial securities supplied by the committee members and, if sufficient, permit the committee members to apply

for a charter. If the charter is granted, which may depend on criteria established 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) law or regulation, or e) any combination of the above, then the bank will form and may solicit business such as depositors and loan applicants. Information regarding the formation of a bank may be stored by any means desired, for example on Bank database 40 and may comprise information such as, for example:

1. Bank ID number

2. Owner ID numbers 1-n

3. Owner Percentages 1-n

4. Shareholder Percentages 1-n

5. Manager 1-n

6. Deposit Accounts 1-n

7. Loan Accounts 1-n

8. Financial Backing Accounts 1-n

9. License fee (upfront)

10. License fee (recurring)

[00130] In a further embodiment, game server 12 may be configured to create a link between banks or other financial intermediaries (real or virtual) or other financial institutions. Such a link may be used to form a network of related or co-owned institutions, to form a financial network to facilitate the transfer of funds between institutions, to link real and virtual financial accounts, to exert control by a central institution, any other reason for linking financial institutions, or a combination thereof.

[00131] Once a financial intermediary is in existence, whether formed by the game, the owners of the server, or formed by players or player characters or otherwise, a player may be assigned or apply for an account. It is to be understood that a player may create one or more characters and each character may have one or more accounts with one or more banks or other financial intermediaries. These accounts may or may not be associated with the player account of the player controlling the player character. [00132] As shown in Figure 2, Bank server 14 may comprise a means for inputting new accounts or transactions into one or more of the bank server

databases. One method of applying for an account is displayed in Fig. 11. To apply for an account, the user will select or be assigned a user name and password. The user name and password may be the character name, the player name, and/or any combination of alphanumeric characters. In one embodiment, the user name and password are submitted to the bank account database 144 to verify that such a user name does not already exist and that the user name and password are valid within the guidelines set by the system (e.g. length, use of symbols, etc.) If the user name and password and/or user name are invalid, the character will be asked to select an alternative user name and/or password. Such a routine will continue until a unique and valid user name and/or password have been submitted, verified and approved. In one embodiment, the server may suggest a unique user name based on random combinations of numbers and letters, or combinations based on the character name or using other well known assignment methods. Alternatively, the user name may be the character name which has been previously established.

[00133] In another embodiment, once the user name and password have been selected and approved, the server will display the terms and conditions of use and will request the player accept such terms. In alternate embodiments, the terms and conditions of use are provided at definite time points, such as prior to creating a user name and password, or as an email or other correspondence sent to the player and/or character. If the player and/or player character declines the terms of use, whether initially or subsequently to signing up, the operation will terminate and/or prevent further use. In this embodiment, once the player accepts the terms of use, the server will proceed to the next step.

[00134] Once the character has created a user name and password for the account(s) the character will be requested to submit character information. In an alternate embodiment, character information may be submitted prior to the selection of a user name and password. Such character information may or may not be linked to the user name. In one embodiment, character information may include character first name, character last name, and an email address as shown in the schematic screen shot Fig. 5. In another embodiment, the character may be asked to select a question and answer

providing further identifying information. Typical questions may be provided such as mother's maiden name, first pet's name, elementary school, high school mascot etc. Alternatively, the player or character may be permitted to create their own question. While such information may be stored in a variety of ways, in one embodiment, character information is stored in character database 138. In another embodiment, such data may be encrypted to prevent unauthorized access or use of such data. There are many well known methods to encrypt data in the prior art. One such method is that known as Pretty Good Privacy or PGP by PGP Corporation of Palo Alto California. Character database 138 may comprise information such as:

1. Character Attributes 1-n

2. Character Accounts 1-n

3. Account Balances 1-n

4. Character Assets 1-n

5. Character Obligations 1-n

[00135] Once the character information is entered, a character credit check may be run. In the event that the character is deemed to have a credit problem through the evaluation of criteria established 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) virtual bank owners, e) bank charter, f) any combination of the above, the formation of the account may be denied. In an alternative embodiment, the character may be asked to provide additional financial security, e.g. a second credit card, to back the account or may be limited in the types of actions that may be taken within the account, i.e., the amount or rate of money the character may withdraw from the account. [00136] In a further embodiment, the character may be asked for real world billing information as exemplified by the schematic screen shot shown in Fig. 6. Such billing information requests real world information from the player of the character. Such real world information may include the player's name, real world address, social security number, and financial security or securities such as a credit cards, bank accounts, private or public payment facilitator accounts (for example PayPal), or other financial security and/or that of another player character and/or a non-playing third party, such as a bank, credit institution, credit card company, mutual fund, investments, brokerage

accounts, hedge funds, insurance company, etc. or any combination of these. The amount of financial securities required may be determined in whole or in part by the credit score of the character and/or the credit score of the real world player or 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) bank owners or their designees, e) bank charter, f) by law or regulation, or g) any combination of the above.

[00137] Player information may be stored by any means desired. In one example, player information is stored in player database 36. In another embodiment, such data may be encrypted. Player database 36 typically stores a unique identifier for each player. The unique identifier could be the player's name, a username (e.g., specified by the player), a phone number, a social security number, or any combination thereof. The unique identifier may be linked to the account information for the player including information such as credit card or other financial security information, personal information, billing information or character identification 1-n or any subset or functionally equivalent information thereof.

[00138] Once the financial security information is entered, the server may verify that the information is correct and the financial security description is accurate and valid. Such tests for validity may occur later or not at all. If the information is deemed invalid or, for example, the credit card is expired or stolen, the server will request an alternate financial instrument. If the financial security information is satisfactory, the server may create the account. Accounts may also be formed upon mutual consent of the two parties. [00139] Bank server 14 may additionally comprise a means for adding additional accounts to the user name and password selected by the character. Such accounts may include, but are not limited to checking accounts, savings accounts, credit accounts, loan accounts, investment accounts, money market accounts, or any other type of financial account typically available at a real world bank. Additionally, the server may add accounts exemplified by other financial intermediaries such as brokerage accounts or policies. Accounts may additionally have different requirements and restrictions. For example, some accounts may require minimum balances, or limit access to funds to a certain number of times in a given term or a certain amount in a given term.

Types of accounts available at a particular financial intermediary and the restrictions on those accounts may be determined according to the charter, the governing entity in the virtual world, or real world controlling entities such as the game manufacturer or server owner. The types of accounts available and the restrictions or requirements may also evolve as the game progresses according to the desires or needs of the game and characters and/or as may be required by rule, law or regulations. Such laws or regulations may be established within the game itself or by a real world governing body. [00140] Once an account is formed, a player may use the account to access funds, deposit and withdraw funds, exchange currency, pay bills, transfer currency, borrow currency, lend currency or other such actions that are typically undertaken by a financial institution such as a bank. Similarly, a player may use an account to transact the types of business transacted at other financial intermediaries including, but not limited to, save currency, deposit currency, buy and sell annuities, buy and sell insurance policies, borrow amounts against or pay loans borrowed against insurance policies, buy and sell stocks and bonds, buy and sell mutual funds, or any other financial transaction typically undertaken at a financial intermediary. [00141] When a player has created an account and logged in, they or their character may select an action to take. Transactions may be recorded in a transaction history. An exemplary transaction history is shown by the schematic screen shot in Fig. 4. Such information may be stored by any means appropriate. For example, transactions may be stored in transaction database 42 on the game server 12 and/or in transaction database 50 on bank server 14. Such database(s) may be encrypted and/or comprise information such as a transaction identification number, bank identification number(s), player character identification(s) and transaction data. In another embodiment, transactions may be transmitted by bank server 14 to game server 12 using some or all of the following method steps:

1. Create a transaction record.

2. Transmit record to game server.

3. Receive indication that record was received.

[00142] According to one or more embodiments, the present invention provides a virtual environment in which characters are able to make virtual

deposits of virtual currency. A character may choose to deposit all or part of the virtual currency they possess at any given time and may choose to deposit one or multiple types of currency. In one example, as shown in exemplary form in Fig. 7, after the player character has logged into his account at the virtual bank, the game or some aspect of the game determines the amount of virtual cash possessed by the player character at that time and permits the player to deposit the virtual cash. In another embodiment, the game or some aspect of the game verifies that the character possesses the amount of virtual currency they wish to deposit.

[00143] Deposits may be recorded in the transaction history, and/or bank server 14 may be configured to manage deposits to a virtual bank using some or all of the following method steps:

1. Receive a request to deposit a sum of virtual cash from a player character, including a deposit time period, deposit type, loan conditions, and player character information.

2. Determine and output an interest rate based on any one or more of the deposit time period, loan conditions and player character information to the player character.

3. Receive an acceptance of the interest rate and other terms from the player character.

4. Receive funds from the player character.

5. Create new deposit record.

6. Notify game server and player character that new deposit record was created.

[00144] Currency for use within the game may be earned by playing the game and/or by creating and selling virtual objects within the game to other players, transacting business within the game, awarded as prizes within the game, may be purchased from the bank or acquired by any means currency is typically acquired according to the parameters of the game. [00145] According to one or more embodiments, virtual currency may be acquired by purchasing it. An account holder may buy or sell virtual currency in exchange for real world currency. An exemplary schematic screen shot of such a transaction is shown in Fig. 9. A character may decide to purchase

currency at any point of the game, may purchase currency at regular intervals, or under specific conditions. For example, a player may indicate a threshold or a range of exchange rates that, when reached, or crossed, or within such range, the system could execute a purchase or sale of a predetermined or calculated amount of real or virtual currency.

[00146] Additionally, a bank may possess multiple virtual currencies. In one embodiment, a character may access funds in the currency of his choice. In another embodiment, the funds are in the currency of the game parameter of the location of the bank or bank branch being accessed. The different locations may be locations within the game, or locations in different games, for example a banking system could be linked between virtual worlds or between virtual worlds in different virtual games. Exchange rates may be instituted between the different types of currency and be fixed or variable. [00147] The exchange rate for virtual for virtual currency or virtual for real currency may be fixed in that the rate does not change for the duration of the game or segment of the game. Alternatively, the exchange rate may be variable. Such a variable exchange 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. 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, or g) any combination of the above.

[00148] Currency may also be accumulated by automatic deposits in virtual bank accounts. Such automatic deposits may come, for example, from scheduled or automatic purchases of virtual currency, for example on a fixed

date, after a fixed time span, or when the amount in the account falls below, reaches, or exceeds a particular threshold. In another embodiment, funds received by a player character such as a virtual salary or proceeds of a sale from a virtual product may be automatically transferred in whole or in part to the virtual bank account of the player character or the account of a player character designated by the character owed the virtual money. The amount to be transferred may be predetermined or established by the player, and/or may be calculated as a percentage or portion of a larger total amount. [00149] In another embodiment of the invention, a player character may withdraw funds from the virtual bank. An exemplary embodiment of a schematic screen shot of a withdrawal transaction is shown in Fig. 8. In one embodiment, the bank program determines the amount of currency in the player's account and permits the withdrawal of some fraction up to and including the entirety of the amount in the account. Such withdrawals may take place through the bank, or in alternative embodiments, withdrawals may take place in other areas of the virtual world such as at points of service, points of purchase, virtual automatic teller machines (ATM), through transfers between virtual and/or real banks or other processing entities, by agreement between players, or players and a game entity or other third party, any method generally used for accessing funds, or any combination of the above. In one embodiment, holds may be put on certain funds for withdrawal, i.e. until the underlying financial security such as a credit card has been charged or under other circumstances in which the available funds need to be verified. [00150] Types of accounts or types of transactions may be limited by the level of participation of the player or player character. Such limitations could depend upon the skill, experience, and sophistication of the authorized user and/or the player's real or virtual credit score and/or real or virtual current or predicted income levels. For example, players may advance through different levels of play and after achieving certain benchmark standards or having an account established for a particular length of time, they may be granted wider access to financial intermediaries and the services provided by such intermediaries.

[00151] In one embodiment, the currency in the accounts may earn interest. The interest rate may be fixed in that the rate does not change for the duration

of the game or segment of the game or for as long as the account is open or the player is in good standing. Alternatively, in another embodiment, the interest rate is pegged to a floating real world or virtual world interest rate, a percentage thereof, or an interest rate plus or minus a particular sum (i.e. prime +/- 2%). An exemplary real world interest rate would be the three month U.S. treasury bill yield to maturity. In another embodiment, the interest rate may be floating and determined by market forces such as exchanges in the virtual or real world or other economic indicators. Said interest 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) negotiation among the affected parties, f) the availability of funds, g) the current or predicted real or virtual credit score of the player, h) the current ratio of bank funds on deposit vs. the total amount of loans, i) by any real world or virtual rule, law or regulation, or j) any combination of the above. Such deposits may then earn interest at a rate determined as described above. The game or virtual bank server may periodically determine an average balance over a fixed time period, multiply the balance by the specified interest rate and pay the virtual interest as a deposit into the virtual account. Such compounding time periods may be continuously hourly, daily, weekly, monthly, yearly or as determined 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) negotiation among the affected parties, or f) any real or virtual world law or regulation or g) any combination thereof. [00152] According to one embodiment, bank server 14 may be configured to manage interest payments provided by a virtual bank using some or all of the following method steps:

1. Retrieve a deposit record and determine an interest payment based on the deposit record criteria.

2. Deposit payment into player character account.

3. Create new interest payment record.

4. Notify player character that interest payment was made.

[00153] The amount of interest paid on the account may vary depending on the type of account. In one embodiment, the account may require a minimum

balance. In a further embodiment, the interest earned on an account receiving automatic transfers or deposits may be higher than the interest earned by an account that does not receive regular infusions of virtual cash. In yet another embodiment, the account may earn more interest if the player agrees not to withdraw money within a certain term such as with, for example, a certificate of deposit. Additionally, higher interest rates may be available to characters who agree to limit their withdrawals i.e. for a particular term, or a particular number of withdrawals in a specified term. Such terms and the interest rates associated with them may be determined 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) negotiation among the affected parties, f) any real or virtual world law or regulation, or g) any combination of these.

[00154] According to one embodiment, player characters who deposit virtual cash could receive a higher interest rate if their virtual cash is or is not secured by a credit card, i.e. if all of their virtual cash is acquired by playing the game.

[00155] Interest information may be stored by any suitable means. In one embodiment, interest rates are stored in interest payment account database 1146 which may be encrypted and may comprise information such as:

1. Interest Account ID

2. Player Character ID 1-n

3. Credit Card # 1-n

4. Credit Line Secured 1-n

5. Conditions 1 -n

6. Virtual Cash Interest Rate

[00156] According to another embodiment, the bank can guaranty a deposit by locking credit cards lines associated with the deposit in an amount that is greater than, or a percentage of, or equal to an amount of virtual cash (and/or which amount may be adjusted based upon historical, current or projected inflation, exchange rates or other factors) that has been deposited by a player character. Player characters can receive a different interest payment (or other terms) for deposits that are secured in this manner. If the player character withdraws his deposit from the bank and the funds are not available,

the credit line used to cover the deposit can be charged the real cash value equal to the requested virtual cash withdrawal amount and/or the credit line can be released as appropriate.

[00157] In a further embodiment of the invention, the bank may issue a virtual debit card to a player character. Such a card may be used to withdraw money from virtual ATMs or to pay for virtual purchases. In one embodiment, the virtual debit card may be linked directly to a virtual bank account and the funds are deducted immediately. In another embodiment, there may be a delay prior to the deduction of the funds from the virtual account. The timing of the withdrawals may be established for a particular term, for the duration of the game or game segment. The timing of the withdrawals as well as the term of the timing may be established 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) negotiation among the affected parties, e) any real or virtual world law or regulation or f) any combination of these. [00158] In another embodiment, the virtual bank may also issue a virtual credit card which may be used to make virtual purchases. The virtual credit card may simply serve as a form of revolving credit, or it may have multiple balance segments each at a different interest rate, possibly with a single umbrella credit limit, or possibly with separate credit limits applicable to the various balance segments. Additionally, the bank may require payment of the credit card balance in full at the end of a specified term, or the credit balance may be permitted to accrue or continue indefinitely. The credit card may be a secured or unsecured credit card. A secured credit card is a type of credit card secured by a deposit account owned by the cardholder with real or virtual cash or real or virtual credit lines. Typically, the cardholder must deposit between 100% and 200% of the total amount of credit desired. Thus if the cardholder puts down $1000, he or she will be given credit in the range of $500-$1000. In an alternate embodiment, the credit card may be an unsecured credit card. The virtual credit card may charge interest and fees. Such fees and interest amounts may be determined by any suitable methods as described above 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) negotiation among the affected parties,

f) a specific economic index or indicator, g) any real or virtual world law or regulation or h) any combination of these. In one embodiment, such fees and interest rates are fixed. In another embodiment, such fees and interest rates are variable.

[00159] According to another embodiment, a real world credit card provider may offer an existing or potential credit card holder an option to add virtual currency processing to the real world credit card account. In this embodiment, players' real world credit cards also serve as virtual credit cards. In all other aspects, the virtual and real credit card transactions are identical to those disclosed herein. This embodiment may provide a benefit to the player character by consolidating the two accounts into a single account. In yet another embodiment, the credit card provider will maintain two or more balances, e.g., one real world and one virtual cash balance, associated with a single credit card account. In the event that the player requires virtual cash, the real world credit card could be charged, and/or in the event the player fails to meet a real world credit obligation, e.g., fails to make a minimum payment on time, the credit card provider may withdraw and exchange virtual currency from the player character's virtual currency account to cover or pay for the real world obligation. In such case, the credit card provider may or may not be required to first notify said player character about such an impending action so as to permit the player character to resolve the issue in a manner other than using virtual currency.

[00160] In a further embodiment, a player character agrees or is required to provide financial backing for the accounts in the bank by allocating a portion of a credit line on one or more credit cards or other financial instruments associated with the player account in exchange for a periodic interest payment. Such financial instruments include, but are not limited to, credit cards, bank accounts, private or public payment facilitator accounts (for example PayPal), investments, securities, financial instruments of another player character and/or non-playing third party such as a bank, credit institution, credit card company, mutual fund, hedge fund, brokerage firm, third party individual(s) or any combination of these. The credit line may be used to provide loans to other players, or provide security for the deposits in the bank regardless of whether the security is for the player's own deposits or

the deposits of another player. The credit line may be extended indefinitely or for fixed periods of time with payments due in part or in full at the end of specified terms. The game or virtual bank server may periodically determine an average balance over a fixed time period, multiply the balance by a specified interest rate, and pay the interest amount in virtual cash to a player account. Said interest rates may be fixed or floating and may be established or determined by any suitable method as described above 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) negotiation among the affected parties, f) a specific economic index or indicator, g) real or virtual world law or regulation or h) any combination of these.

[00161] According to an alternate embodiment, the allocation of the credit line serves to insure the virtual bank's ability to cover deposits in the bank. There may also be a reserve requirement imposed on the bank such that the bank can only lend a certain percentage of its total deposits. The reserve requirement may be established in founding the game or in the establishment of the bank. In one embodiment, the founders of the bank are required to secure the reserve requirement. Reserve requirements may be established 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) negotiation among the affected parties, f) virtual or real law or regulation or g) any combination of these. In one embodiment, the reserve requirement is 3 percent to 10 percent of a bank's total deposits, in other embodiments, the bank may be prohibited from making loans. The reserves or the entire amount on deposit may be guaranteed by the credit line of a real world credit card, which may be the player character's real world credit card and/or that of another player character and/or a non-playing third party, such as a bank, credit institution, credit card company, insurance company or any combination of these. In one embodiment, if more withdrawal requests on the bank exist than can be covered by the virtual cash the bank has on hand, the bank can charge the real cash value of the virtual cash shortfall to the credit lines that players or other entities have registered as financial backing to secure the bank's deposits (e.g., depositor's insurance or FDIC, or third party backing or

financial security instruments, etc.). In the event that a large number of players attempts to withdraw currency at the same time, i.e. if there is a run on the bank, the game server, bank server owners or other governing entity may manage the credit lines securing the deposits.

[00162] In another embodiment, bank server 14 could be configured to handle shortfalls using some or all of the following method steps:

1. Receive a request to withdraw a virtual cash deposit from the bank.

2. Determine that there is not enough virtual cash available to cover the withdrawal request and generate a virtual cash shortfall amount.

3. Determine a real cash to virtual cash conversion rate.

4. Determine a real cash value equal to virtual cash withdrawal shortfall

5. Optionally, notify affected parties of pending credit card charges.

6. Optionally, provide affected parties with the option to transfer virtual cash into the account to avoid actual credit card charges.

7. Determine available credit lines based on conditions.

8. Charge credit lines the real cash value of the remaining shortfall based on conditions.

9. Convert real cash to additional virtual cash.

10. Payout the requested virtual cash withdrawal.

[00163] According to another embodiment, the credit lines can be charged based on one or more conditions. For example, in the event of a shortfall, a player can receive a higher or premium interest rate or a specified virtual amount if he allows his credit card to be charged first or in a higher proportion relative to other credit cards securing the bank. Alternatively or additionally, a player could be paid a lower rate or specified amount if he only secures certain types of deposits or loans (e.g., less risky). In another embodiment, the more risky the loans, the higher the interest rate paid in return. The risk of deposits or loans may be determined by any one or more of the following, including but not limited to, a virtual credit score, a real credit score, a player's prior history, the type of transaction, the use of the proceeds on a loan, e.g., buying virtual property may be less risky than buying a weapon, and/or any reasonable means or a combination thereof. Such a rating system and the amounts of the payments may be established 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) negotiation among the affected parties, f) virtual or real world law or regulation or g) any combination of these. Alternatively, credit lines can be charged in equal increments until the total shortfall amount is covered. In another embodiment, the credit lines can be charged relative to the shortfall amount as compared with each player's committed amount, i.e., as a percentage of the shortfall. For example, if the total shortfall is $100 in real currency, and there are two credit cards securing the shortfall, one offering $1,000 and the other offering $100, the first card may be charged $90, while the second is charged $10, each representing that portion of the shortfall as a percentage of the commitments associated with the credit cards. Of course, a combination of these methods or any other terms as negotiated among the affected parties may be used to determine how a shortfall is allocated among the affected parties. For example, the allocation can be bilateral or multilateral, can be negotiated by the affected parties, determined according to pre-determined factors, or arbitrarily assigned by the bank.

[00164] According to one embodiment, bank server 14 may be configured to manage interest premium payments using some or all of the following method steps:

1. Retrieve interest record and generate a premium payment amount based on record data.

2. Deposit virtual payment into player character account.

3. Notify game server and player character that premium payment was made.

[00165] According to another embodiment, player characters that deposit virtual cash or allow their credit lines to secure the bank can specify what types of and amounts of virtual loans or virtual deposits they are willing to back. As non-limiting examples, virtual loans could be provided for:

1. Purchasing a fixed number and/or type or types of virtual asset(s).

2. Lending the virtual money for a fixed maximum time period.

3. Lending the virtual money to player characters with a certain amount of virtual assets in the game or a certain age or skill level in the game environment.

4. Lending the virtual money to player characters with a certain real or virtual credit score.

5. Lending virtual money at a specified interest rate, which rate may be fixed for the term of the loan or which may vary based upon any one or more variables including, the term, changes in the borrowers status, credit scores (real or virtual), assets (real or virtual), over time, rate of defaults on loans within the game environment in general or for the lender, tied to other interest rates (real or virtual), total amount of loans outstanding within the game and/or by the lender and/or the player character, etc.

6. Lending virtual money to player characters in exchange for services or goods.

7. A specific listing of player characters that are acceptable and/or unacceptable to the lender for whatever reason or no reason.

[00166] In one embodiment, interest rates charged and payable for loans may be customized on the basis of risk: i.e. reasons for or uses of the proceeds of the loan; the financial or business plan underlying the loan; default rate of the player character or virtual entity; credit worthiness of the borrower; type of virtual investment pursued by the borrower; portfolio of the bank; outstanding loans of the borrower; how much money the bank has available to lend; costs to the bank for obtaining the money; the term of the loan; or any combination thereof. Evaluation of the risk may be determined 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) negotiation among the affected parties, f) any real or virtual world law or regulation or f) any combination of these.

[00167] According to another embodiment, player characters can specify a maximum percentage of a loan, deposit, or other financial instrument they are willing to back. For instance, a player character may indicate he does not want to lend more than 10% of a given loan to any particular player character.

[00168] According to another embodiment, player characters can specify that a certain percentage of their cash be lent to other player characters with varying virtual credit scores or that currency not be lent to player characters who do not meet a certain minimum credit score. For instance 40% of the loans could go to player characters with a high virtual and/or real credit score, 30% to characters with a low virtual and/or real credit score, and 30% to characters with a mid virtual and/or real credit score. Based on this ratio of a diversified or pooled loan portfolio, a weighted interest rate can be determined and paid to the lender. Such interest rates may be fixed or variable and may be higher or lower depending on the amount of risk or other factors the player character is willing to assume.

[00169] Information regarding the virtual loans could be stored by any means applicable. In one embodiment, loan information is stored in Loan account database 148 and may be encrypted and/or may comprise information such as:

1. Loan Account ID

2. Player Character ID 1-n

3. Credit Card # 1-n

4. Conditions 1 -n

5. Amount

6. Payments

7. Interest Rate

8. Start Date

9. Payment Date(s)

10. Type

11.Automated withdrawal

12. Penalties (1-n)

[00170] The bank may also charge fees for its services, such as for the conversion of real world currency to virtual currency, fees for the conversions of different types of virtual currencies, the conversion of one virtual currency into another virtual currency, fees for the verification of financial instruments or securities, fees for loans, maintenance fees, withdrawal fees, checking fees, ATM fees, legal, collection and overdraft fees. In another embodiment,

the banks may also invest in other virtual or real world entities such as virtual securities (e.g. bonds, stocks etc.), in addition to traditional loan activities. [00171] The financial intermediaries may also be overseen by a managing entity such as the game server, the owner of the bank server, the town, a central financial institution or other governing entity charged in the game with overseeing financial transactions. In one embodiment, game server 12 may be configured to monitor the bank using some or all of the following steps:

1. Receive records of deposits and issued and outstanding loan obligations.

2. Receive interest and principal payment records.

3. Determine if payment records correspond to deposits and loan obligations.

4. If the data does not correspond, flag bank as suspect.

Suspect banks may have their assets immediately frozen, or may have their actions limited. Additionally, the credit lines securing the deposits of a suspect bank may be charged a fee if the status of the banks is set to suspect, or may be charged an amount equal to all or a portion of the deposits of record to make sure they will not default on a request to withdraw funds from a player character who has an account with them. [0097] One of the services provided by financial intermediaries is the transfer of funds between parties. Such transfers frequently take the form of loans. A simple loan provides the borrower with an amount of funds which at the maturity date must be repaid to the lender along with the interest payment. A fixed payment loan provides a borrower with an amount of funds that is to be repaid by making the same payment every term, consisting in part of the principal and interest for a set length of time. The source of the funds from the loan may be from other players who have placed funds with the financial intermediary or against assets belonging to the borrower that may or may not be held by the financial intermediary. Entities wishing to lend funds may be charged a fee for providing the loan. The fee may be charged by a virtual world governing entity, real world governing entity, game server, game owner, server owner, central financial institution, or any combination of the above. Such fees may be one time fees, recurring fees, charged per loan,

based on the amount of the loan, a flat fee, charged when the loan originates, charged when payments are made etc. Such fees may additionally take the form of a license.

[0098] In various embodiments, the present invention provides a system of public and private means of lending funds to player characters for use within the virtual world. Such funds permit the redistribution of financial assets and the expansion of the game and depth of play available. Funds may be lent through the issuing of bonds, virtual governing entity securities, and consumer and commercial loans or by any other means typically used to advance funds. These types of lending vehicles are collectively referred to as "loans" throughout the application for ease of description. In one embodiment, there may be a limit to the number of loans or the total amount of loans that any one financial intermediary may provide. Such a limit may be based on a percentage of funds held by the financial intermediary, or risk parameters. Such parameters may be established by the governing entity, a central financial institution, the game server, game owner, server owner, financial intermediary owner, or negotiation among the players. All such loans may be secured or unsecured.

[0099] According to one embodiment, a player character may request a loan from a virtual bank or other financial intermediary. In another embodiment, a character may obtain a loan from another character or business operated by a character including, for example, a pawn shop, a developer, a foundation, cooperative, or other business. [00100] It is to be understood that players may control one or more characters and each character may apply for and obtain one or more loans. In some embodiments, a player character may be limited from lending currency to himself, another player character controlled by the same player, or a player character that is a family member, guild member, or affiliated in some way the player character who deposited currency in the bank. [00101] For ease of description, the term "bank" is used throughout the present disclosure when describing an exemplary embodiment of a financial intermediary or other lending entity which may function as a lending institution, however it is understood that the processes as described

herein may apply to any type of financial intermediary or lending institution and the types of services they generally provide in the real world. [00102] A loan is obtained by applying for a loan, receiving terms of the loan, agreeing to the terms of the loan and receiving the funds. An exemplary system 100 configured to provide the virtual environment described above is shown in Fig. 13. As shown, system 100 may include a game server 102, a bank server 104, and a credit card issuer server 106. [00103] Game server 102 may include a Loan Creation Program

108, whereby a bank server can register a loan with the game server. Game server 102 may further include a simple Loan Payment Program 110, a complex Loan Payment Program (complex) 112, a Prohibit Sale of Virtual Assets Program 114, a Debit Card Issuance Program 116, a Debit Card Usage Program 118, a Loan Converted to Shares of Asset Program 120, a Loan request program (no bank) 122 and a Loan acceptance program (no bank) 124. Bank server 104 may equally be any other financial intermediary server including a contractual savings institution or investment intermediary server. Such servers 104 may include a simple Loan Generation Program 126, a complex Loan Generation Program 128, a register Loan with game server program 130, a Loan Payment Program (automatic) 132, a Loan Payment Program (invoice) 134, an Advertisement program 136, a Loan Payment Program (choice of real or virtual cash) 138, a Ping Credit Line 140, a prohibit Sale of Virtual Assets Program 142, a Release Credit Line when Loan is paid 144, a Debit Card Issuance Program 146, a Debit Card Usage Program 148, a Debit Card Issuance Program (register debit card with game server) 150, a Debit Card Usage Program (register debit card with game server) 152, a Loan Converted to Shares of Asset Program (bank managed) 154, and a Loan Converted to Shares of Asset Program (game server managed) 156. Server 104 may further include interest rate determination program, Credit Card Issuer Server 106 may include a Lock Credit Line Program 158, a Real Cash Payment Program 160, a Release Credit Line 162, and a Ping Credit Line program 164.

[00104] A Character may apply for the loan in a variety of ways.

In one embodiment, a loan may be granted based on a simple request. Such a request may be completed by any means desired, i.e. through the selection

of a loan in a bank, through e-mail, virtual written requests, instant messaging, screen request, or through a formal loan application. According to one embodiment, simple Loan Generation program 126 may be configured to create a loan using some or all of the following method steps:

1. Receive a request to borrow virtual currency;

2. Determine a virtual currency loan amount;

3. Output a loan offer including amount, interest rate and payment schedule to player character;

4. Record loan; and

5. Output virtual currency to player character account.

[00105] In another embodiment, characters may be required to complete a loan application. An application may request information such as details regarding the player or player character, the amount of the loan sought, the duration of the loan sought, real world financial information, real world credit information, real world credit rating, virtual world credit rating, the purpose of the loan, a business plan, collateral, proof of a virtual world job, proof of assets, other information typical for use in credit scoring or any combination thereof.

[00106] In a further embodiment, a loan may be applied for in an environment other than the game environment in which the lending entity is located. For example, a lending website could exist outside of the environs of the game. Once the loan agreement is established, an entity controlled by the loan issuer could transfer the appropriate amount of virtual currency to the character requesting the loan. In one embodiment, Loan Generation program 126 may be configured to create a loan using some or all of the following method steps:

1. Receive game type.

2. Receive game server.

3. Receive player character ID.

4. Receive Loan amount.

5. Receive Credit Card number.

6. Determine and output loan payment plan

7. Receive acceptance of plan

8. Secure loan with credit card

9. Output loan approved message.

10. Transmit loan to appropriate character in virtual world.

Such a website could be maintained by the game server, owner, manufacturer, or by a third party. Fees could be charged by the game or game server for such transactions and transfers into the game, or a license could be sold allowing such transactions to occur. Additionally, the game server or manufacturer could pay a fee to the host of the website for each loan that is generated.

[00107] In another embodiment, a player must guaranty the loan.

Such a guaranty may be the registration of a real world credit line. Such a credit line may be a credit card, private or public payment facilitator (i.e. paypal) or other financial security and/Or the financial security of another player character and/or a non-playing third party, such as a bank, credit institution, credit card company, mutual fund, brokerage account, hedge fund, insurance company, etc. or any combination of these or any other type of real world financial instrument or institution that provides a credit line or holds or secures assets for third parties. In this embodiment, Loan Generation Program 126 may then create a loan using some or all of the following method steps:

1. Receive a request to borrow virtual cash including a player character ID and a real world account number;

2. Validate real world account number and credit line amount

3. Determine a virtual loan amount based on credit line amount

4. Determine an interest rate and virtual payment schedule

5. Output a loan offer including a virtual cash loan amount, interest rate and virtual payment schedule to player character

6. Receive acceptance of loan offer from player character

7. Lock credit line

8. Create new loan record

9. Output virtual currency to player character account

[00108] An exemplary method for obtaining a loan is shown in the flow chart in Figure 14 in which the player completes a loan application and requests a loan. As shown in the flowchart, the lending entity determines if there is a real world credit line associated with the character which could be

used to guarantee the loan and verifies that the real world credit line is valid. Alternatively, a character may be given the option of using the credit line already on file or supplying an additional credit line to be used. The lending entity may then determine the amount to be lent, interest rate to be charged and payment terms in any order. The lending entity may further include fees in the terms of the loan. The character is then presented with the terms of the loan and may then either accept or reject the loan.

[00109] The terms of the loan may be determined by the financial intermediary, the game server, the owner of the server, by agreement between the characters, or by any other party to the negotiations. The terms may include such things as the amount of currency the bank is willing to lend to the character, the type of collateral the bank will require, the interest rate for the loan, the term of the loan, the payment schedule for the loan, an origination fee, commitment fee, any additional fees the bank may decide to charge, annual percentage rate, if there will be a balloon payment, or any combination thereof. In one embodiment, the character may be able to vary one or more of the terms of the loan such as interest rate, due date, grace period, penalties, service charge, transferability, fees, automatic repayment, payment of other obligations, and exchange value. In another embodiment, the terms are dictated by the lender.

[00110] In determining the terms of the loan, the bank or other lending entity may evaluate a number of factors including the creditworthiness of the character or player, the credit history of the player, the virtual and/or real credit history of the character applying for the loan, the real world credit lines available to the requestor; past delinquency rates; the length of time the character has existed; the skill level of the character and/or player; and the assets held by the character as well as any other type of information typically used in evaluating credit worthiness of a borrower; market forces, real world financial indicators, virtual world financial indicators, the bank or other lending entity's current portfolio, the growth rate of the game, the type of player account, inflation rates, the purpose of the loan, or other financial evaluators. In another embodiment, the bank may verify the character's virtual credit score. In another embodiment, the bank may verify the player's real world credit score. Virtual and real credit scores may be based on information such

as the types of bills owed by the character/player, the timeliness of payments, loans outstanding, credit lines available, length of credit history, new credit applications, income, marital status, length of time playing the game, or any combination of the above.

[00111] In one embodiment, in determining how much to lend, the bank may determine the amount arbitrarily, may agree to lend all or part of the amount requested, may determine what percentage of income whether virtual or real would go to paying back the loan, may determine how much debt the character has whether virtual or real, or may set maximum loan amounts depending on limits set 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) negotiation among the affected parties, f) any combination of the above.

[00112] In another embodiment, the character's credit score influences the terms of the loan. In a further embodiment, the player's credit score influences the terms of a loan. In a further embodiment, both the character's and the player's credit scores influence the terms of the loan. For example, the credit scores may determine whether to issue the loan, the interest rate to be charged, the fees to be charged and/or other term and restrictions of the loan.

[00113] Loan applications and credit histories may be stored by any means applicable. For example, a program may be introduced that tracks and displays all available credit lines, current loans, available loans, including their terms and conditions, such as interest rates, a listing of players wishing to borrow or loan currency, etc., and displays such information to interested player characters. Banks, and/or player characters may use this program to determine if they wish to loan or borrow virtual cash and/or commit part or all of their available real world credit line to the game, bank or player character(s), along with terms and conditions for its use. As shown in Figure 15, the bank or player characters willing to provide a loan to a character may indicate the amount of currency they are willing to lend. The borrower may then request an amount of a loan up to or equal to the amount the bank or other entity is willing to lend.

[00114] In another embodiment, a limit on the amount of currency that may be borrowed at any one time or by a given character or player may be set 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) negotiation among the affected parties, f) the player characters virtual or real net worth, g) debt to equity ratio, h) total virtual amount, i) total monthly payment amount, j) other financial constraints established by the lender, or k) virtual or real world rules and regulations, or I) any combination thereof. [00115] Loans may be secured or unsecured. An unsecured loan is a loan that is issued and supported only by the borrower's creditworthiness, rather than by some sort of collateral. A secured loan is a loan which is backed by collateral. Such collateral may belong to the character seeking the loan or to a third party. The collateral may be a real world credit line supported by a real world financial institution, a real world financial security, a real world asset, a virtual property or business, a virtual world asset, a real world property, a promise to perform certain services or any combination thereof.

[00116] In one embodiment, the collateral is a real world credit line, The player may indicate the amount of collateral in the form of the real world credit line he is willing to allocate against the virtual loan. According to one embodiment, real world credit lines can be frozen by the bank owner, and/or just periodically "pinged" to ensure their validity and that sufficient credit is available to underwrite the loan. The continuing availability of the real world credit line may be determined by any means applicable. According to one embodiment, Ping Credit Line program 140 may be configured to complete some or all of the following steps:

1. Determine that a player character has an outstanding virtual loan

2. Determine real and virtual cash value of loan

3. Retrieve credit card associated with loan

4. Ping credit card for the outstanding real cash value of the loan amount

5. If credit equal to loan amount is not available

6. Liquidate virtual assets of player character equal to virtual cash value of virtual loan

7. Deposit virtual cash in loan account to pay off loan [00117] In the event the real world credit line securing the loan is cancelled or closed, the system could receive notification that the real world credit card or credit line is no longer valid. Upon notification that the credit line is no longer valid, the bank, system, game owner, server owner, or other debt holder may require payment in full of the loan, require the player to provide a new credit line, require additional collateral to secure the loan, secure a secondary line of credit which was previously provided or may be secured from other player characters, notify other characters of the opportunity to purchase a loan, foreclose on virtual assets held by the defaulting character, freeze the virtual accounts of the character or player, or any combination thereof.

[00118] The lock on the real world credit line may be released when the loan is repaid. According to one embodiment, Release Credit Line when Loan is paid program 144 may be configured to:

1. Receive indication that final payment of virtual loan has been received

2. Retrieve credit card associated with virtual loan

3. Notify credit card issuer to release credit line

[00119] Alternatively, as the loan is paid down, a percentage of the real world credit line may be released in proportion to or in some other ratio with the amount paid. In this example, the real world credit line held is reduced as the loan is repaid, instead of waiting for the entire loan to be repaid, thus freeing real world credit lines for other purposes. Such a release could be managed by any means available. According to one embodiment, Release Credit Line when Loan is paid program 144 may be configured to:

1. Receive indication that a periodic payment of virtual loan has been received

2. Retrieve credit card associated with virtual loan

3. Notify credit card issuer to release an equal or other determined portion of the credit line.

[00120] A real world credit line can secure the loan payment amount, the entire loan amount, or a ratio of the two. In calculating the amount to be secured factors such as game growth rates, taxes, inflation

and/or exchange rates, credit worthiness of the character or player, riskiness of the venture or purpose of the loan, the amount of debt the character has outstanding or any combination thereof may be considered in determining the total amount to secure on the real world credit line. Such determinations and evaluations may be made 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) negotiation among the affected parties, f) any combination of the above.

[00121] In one embodiment, the amount of a real world credit line to be frozen can be based on the exchange rate of virtual currency for real currency. According to one embodiment, the exchange rate could be one for one. Alternatively, the exchange rate may be based on the exchange rate at the time of the formation of the loan. It may also be based on the exchange rate at the time the player's credit card is charged. In another embodiment, the exchange rate may be adjustable for the term of the loan. Such adjustments may be based on inflation, actual exchange rates, market forces or other economic indicators or a combination thereof. The exchange rate may be fixed in that the rate does not change for the duration of the game or segment of the game. Alternatively, the exchange 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. 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) negotiation among the affected parties, f) any combination of the above. The exchange rate may also be composed of any combination of the above methods. For example, the exchange rate could be fixed for a certain length of time and then change to market forces or vice versa.

Alternatively, there may be a cap on the amount of fluctuation in the exchange rate during the term of the loan.

[00122] In a further embodiment, the game may control the use of ihe proceeds of the loan, in one example, the game server or bank server could prohibit the player character from converting an amount of virtual cash or assets equal to, or greater or less than the loan amount into real cash. In another example, the game server or bank server could prohibit the (borrowing) player character from spending loan proceeds, i.e., virtual cash equal to, or any portion or percentage of, the balance of the loan on anything other than virtual assets and/or services specified by the loan. In a further example, the game server could prohibit the player character from reselling or otherwise encumbering the virtual assets purchased with the virtual loan until such time as the virtual loan is repaid,

[00123] Security for a loan may also be provided by a third party.

In one embodiment, the bank could secure the Joan with real world credit lines from other players. Characters may be willing to lend currency when interest rates meet a particular threshold, for example at s specified interest rate, which rate may be fixed for the term of the loan or which may vary based upon any one or more variables including, the term, changes in the borrowers status, credit scores (real or virtual), assets (real or virtual), over time, rate of defaults on loans within the game environment in genera! or for the lender, tied to other interest rates (real or virtual), total amount of loans outstanding within the game and/or by the lender and/or the player character, etc. Additionally, player characters could specify that a certain percentage of their currency be lent to other player characters with varying virtual credit scores. For Instance 40% of the loans could go to player characters with a high credit score, 30% to characters wiih a low credit score, and 30% to characters with a mid credit score. In an alternate embodiment, the bank could secure toe loan through the real world credit line or other collateral provided by the character requesting the loan in combination with the real world credit line from other players or a third party. In another embodiment, characters could review the statistics of other characters seeking loans and notify the bank or other financial intermediary that they are willing to supply a guaranty for a particular borrower(s). Private loans between players may also be conducted.

According to another embodiment, players can pay an additional up front or recurring fee so that their characters can issue or take loans from other player characters or NPCs. [00124] According to a further embodiment, a player character or virtual bank can loan currency to another player character and recei¥© loan payments without those loan payments being secured by a credit card. The first player character establishes a request for an amount of currency. A second player character {or, alternatively, two or more player characters or a virtual bank) agrees to faan the first player character the currency for a tetm and with an interest rate and the virtual; currency Is pfeced in escrow with the cβfiiraJ sefveL Yv'hθω file Sfsi player charaeier agrees io Hie loan terms of if is second player character, the central ssn/er releases the funds and tracks the payments due from the first player te the second player. This method rπsy slso be used with fosπs that are secured with a credit eard line of credit J00125I An exemplary method of obtaining third party security is provided in the flow chart in Figure 19. As shown in the flow chart, a character requests a loan and the bank submits the ban requsst to Git&r players or placer characters that hawe expressed an interest frt securing Joans. Once one or more players or characters have agreed to secure trie ϊΌBΏ, the borrower is presented with tie terms of the loan. The bank or server may then lock the mal worfef crecM line of the securing player or character according to the amount each has agreed to secure or some fracfen. thereof and deposits ilie loan in the borrower's account

[80126] In another embodiment, the collateral is a non-financial asset Such an asset includes any item of economic value including,, but rrol limited to _r a mάu&l object; a virtual skftt or attribute;: virtual property or .business; a real world object or property; a promise io perform certain services, or any combination thereof. fθ©127f In one embodiment, the safe or transfer of the stern pledged as cαiaietal may be feited bγ the- game- sereer _r barfc server, owner of Hie server, or one or more characters or virtual businesses. For example, a pawn shop may hold the assst in trust until the loan is paid. The sale or transfer of cαfatersf may be governed bψ a program such as Prohibit Sate of

Virtual Assets program 114 which may be configured to perform one or ail of the following steps:

1. Receive a request io sell a virtual item from a player character.

2. Determine if there is an outstanding loan or lien against either the player character or on the item.

3. If there is an outstanding toart or Ren. prohibit the sate of the item and notify player character. or

4. If the purchase price is equal to or exceeds the Ileo or toan amount, allow the sale of the item and immediately pay down the foart obligation with the proceeds. or

5. If the purchase price is equal to or exceeds the loan amount allow the sale of the item but lock up an amount of the proceeds of the sale equal to all or a portion of the outstanding loan amount.

[00128] The bank or other party providing the loan may desire part ownership in art asset in return for the loan. For example in one embodiment, the loan coufef be structured so that it is convertible for a percentage ownership of the item or asset that it was used to purchase (and/or In addition to additional assets and/or penalties). In this embodiment, the player character that took out the loan or tie- bank ihst issued the loaa c≤ά convert the loan obligation into a percentage ownership of tfts aεssiCε} that the Joan was used io purchase. The terms of the con¥ersϊon could be specified In the loan agreement and the conversion rate may change over time as the loan balance is reduced. In another embodiment, the bank coufrf obtain possession of the entire item or asset in the event of a default The bank could Uien sell or otherwise dispose of the asset. [00129] Such information or proceeds may be stored by any means available. According to one embodiment sycfr information is generated through Loan Converted to Shares of Asset program; 12G which may be configured io perform some or all of the following sieps.

1. Receive a request to convert all or a portion of an outstanding loan into shares of a virtual asset by a virtual bank server or player character.

2. Retrieve and amend loan obligation.

3. Retrieve and amend ownership structure of virtual asset.

4. Notify loan parties and owners of asset that loan has been converted into shares of a virtual asset.

[00130] According to another embodiment, rather than a loan, the bank could take a percentage of the venture that a pfayer character was presenting. The percentage could be as an owner or as virtual stock or stock options. In the event that the percentage is in stock or stock options, the bank may limit the amount of stock the business may issue such that the percentage ownership does not become diluted- in another emhadϊment _t the bank may receive a percentage of stock or stock options in the business with each issuance of new stock. This decision can be made by the game server based OR the venture arid the pEayer character credit scores or real wαrfd credit line and/or martL.al.yi

{80131] Additionally, the terms of the Joan may include interest.

The interest rate may be fixed in that the rate does not change for the duration of the game or segment of the game. Memattvety, in another embodiment, the interest rate is pegged tσ a floating real world or virtual world interest rate, a percentage thereof, or an inieresi rate plus or minus a particular sum {i.e. prime +/- 2%). An exemplary real world interest rate would be the three month ULS. treasury bill yield to maturity. Irt anothet embodiment [he interest rate may be determined by market forces such as exchanges in, the virtual or real world or other economic indicators. Said interest rales may further be established or determined by any suitable method including, but not limited to, a) the game martitfacturer, b) the owner(s) of the server(s) upon which the game resides, c) one or more playeF characters, d) maricet forces,, e) nsyoiiaϋujj among ilie affeelsd parties, f) the availability of funds, g) the current or predicted real or virtual credit score of the player, Ji) trie current ratio of bank funds on deposit vs. the total amount of loans, E) payment performance, J) adherence to toan restrictions or other terms, k} number of irjiϋaf or subsecjuejii defaults on loans by the player character, J) real or virtual credit scores, m) any other financial or other terms as determined by the lender and agreed upon by the- borrower Ft) by SFQ? real woilcl OF virtual rule, law or regulation:, or o) anγ combination: of the above.

[00132] In another embodiment, interest rates may be customized on the basis of risk: i.e. reasons for or uses of the proceeds of the loan; the financial or business plan underlying the loan; default rate of the borrower; credit worthiness of the borrower; type of virtual investment pursued by the borrower; portfolio of the bank; outstanding loans of the borrower; how much currency the bank has available to lend; costs to the bank for obtaining the currency; the term of the loan; or any combination thereof. Evaluation of the risk may be determined 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) negotiation among the affected parties, OF f) any combination of these.

[00133] In charging interest, the game or virtual bank server may periodically determine an average balance over a fixed time period, multiply the balance by the specified interest rate and charge the virtual interest rale to the account. Such compounding time periods may be continuously hourly, daily, weekly, monthly, yearly or as determined 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) negotiation among the affected parties, f) any real world or virtual rule, law or regulation, or g) any combination thereof.

[00134] The terms of the loan may Include various types of payment options including equal payments, in which equal payments are made wlihin specified terms such as daily, weekly, monthly, yearly or any fraction thereof. In one embodiment, part of each payment goes to the principal and the rest to interest payments, frt another embodiment it may b& an interest only loan. In an alternate embodiment, the equal _* payments rrta^r rβquire a final balloon payment In another embodiment, the interest only loan may require a final balloon payment. The loan may have a pre-payment penalty ϊn which payment before the end of the loan will incur a fee or othet penalty. In another embodiment, the loan may be paEd in full prior tσ the end of ihe ierm of ihe loan without penalty. Jn yet another embodiment, the loan may foe refinanced. According Io another embodiment, player characters can choose, at any time, whether they want a loan tα be charged to their virtual cash account or their credit card on f Ee or any combEitafEon of these options.

In a further embodiment, the payment option is provided by the bank or other entity providing the loan. In another embodiment, the payment option may be selected or proposed by the character as shown in Figure 16. Such payment information and receipt of payment may be stored by any means desired. According to one embodiment, simple loan payment program 110 may be configured to:

1. Receive an indication that a loan payment has been made

2. Store loan payment with loan record

[00135] The loan terms may also include fees. fn one embodiment, the fees are part of the interest rate, in another embodiment the fees must be paid separately. Such fees may be a percentage of the loan or a flat fee or a combination thereof. In one embodiment, the fees are expressed as part of the annual percentage rate. Fees may also be incurred if payments are late, for example, the payment may one amount if received by a first date, and a second higher amount if paid by a second date. Fees may also be charged to verify the availability of the credit line being used to guaranty the foan. fn one embodiment, a loan origination fee ϊs charged to the credit line to verify that the account is active.

[00136] According to another embodiment, the maximum loan amount, interest percentage rate, and pay period on the loan can be affected by any one or more of the following including:

1. The virtual or real world assets of a player character.

2. The level or skill level of a player character.

3. The trend or rate of change of the skill level of the player character.

4. The age of the character account.

5. The type of player account, e.g., basic or premium.

6. The player character's previous payment history or performance.

7. The existing outstanding debt or other virtual loans outstanding to the player character.

8. The player character's purpose or intended use of the proceeds of the virtual loan.

9. The current or projected interest rates and/or inflation rate and/or exchange rate(s) within the game and/or the real world.

10. The current or projected interest rates charged by the credit card companies.

11.The current or projected stability or future prospects of the game. [00137] According to another embodiment, the loan may be issued as a virtual debit card. The use of the card may be limited to purchases that are specified in the loan obligation or by the account (in the case of a loan not being involved). Player characters can give these debit cards to other player characters who can use the outstanding or remaining balance on them for virtual purchases specified when the debit card was created. Debit cards can be given to a first player character when a second player character relies on the first player character to purchase something for him, but cannot trust the player character with virtual cash that has unrestricted purchase parameters. Debit cards can be used to create in game payment vehicles that can only be used to purchase certain virtual assets and/or services. Debit cards can also be created that have access to specified amounts of funds. Such amounts may be a percentage of the cash available in the account or may be a fixed amount or a combination thereof such that there is a minimum or maximum percentage of available assets that can be used or minimum fixed amount and a percentage that is available. [00138] Information regarding the debit card may be stored by any means applicable. In one example, such information is stored on game server 102. In another embodiment such information is stored on bank server 104.

[00139] A Debit Card Database 168 or 172 may comprise information such as:

1. Bank ID

2. Debit Card ID

3. Debit Card Amount by category 1 -n

4. Debit Card Issue Date

5. Debit Card Conditions 1-n

[00140] In another embodiment, information regarding the debit card may be stored on game server 102 through Debit Card Issuance program 116 which may be configured to:

1. Receive an indication that a debit card was issued from a bank including player character info, bank info, debit card amount and conditions

2. Create and store debit card record

[00141] According to another embodiment, percentages of the debit card value can be allocated to different virtual asset classes. For instance, 50% of the value could be used to buy specific raw materials and 40% could be used to purchase services from specific NPCs and player characters to turn those raw materials into a specific product. The remaining 10% of the value could be used by a player character for anything, but, for example, only when the other 90% has been spent to create the specific product and that product has been deposited into the debit card issuer's account. The specific asset classes or services may be outlined in the loan application or determined by a) the bank, b) the game manufacturer, c) the owner(s) of the server(s) upon which the game resides, d) one or more player characters or e) any combination thereof. For example, if the loan is secured by another character, that character may require that a certain percentage of the purchases for the purposes of the loan be made from characters or businesses he designates.

[00142] Information regarding the issuance of the debit card may be stored according to any means applicable. In one embodiment, Debit Card Issuance program 148 may be configured to follow one or all of the following steps:

1. Receive a request to create a debit card including a virtual cash amount, a specified receiver of the card, and conditions (if any) for spending the virtual cash from one or more player characters.

2. Create debit card including usage conditions (if any).

3. Transfer cash from player characters) account(s) to debit card.

4. Output debit card to specified receiver.

5. Notify player character(s) and game server that debit card was created and issued.

6. Update debit card bank database.

[00143] Information regarding the allocations and usage of the debit card may stored according to any means applicable. In one

embodiment, such information may be stored on Debit Card Usage program 118 on the bank server which may be configured to follow some or all of the following steps:

1. Receive an indication that the purchase of a virtual item or service will be paid for with a virtual debit card.

2. Determine if purchase qualifies based on debit card conditions (if any).

3. If purchase is qualified, allow purchase and deduct virtual cash from the account balance.

4. If purchase is not qualified, disallow purchase.

5. Notify bank that purchase was attempted and made.

[00144] In another embodiment, Debit Card usage information may be stored on the game server and Debit Card usage program 150 may be configured to:

1. Receive request to use debit card from a player character to purchase an in game good or service or to pay a debt.

2. Determine if use falls within debit card condition parameters (if any)

3. Allow use if condition parameters allow it

4. Don't allow use if it falls outside of condition parameters

5. Notify player character using debit card, player character(s) who created debit card, and game server if debit card was used or not allowed to be used.

6. Update remaining cash balance

[00145] According to a further embodiment, the loan may be issued in the form of a virtual credit card in which the character may make purchases up to the amount of the loan using the virtual credit card or may give the virtual credit card to another party to make the purchases. The bank or entity supplying the loan may limit the use of the credit card to purchases in support of the reason for the loan, or may allow any purchases to be made. The credit on the credit card may additionally be allocated to different virtual asset classes as described above for virtual debit cards. Additionally, the character may be enabled to vary one or more of the credit terms of the credit card such as interest rate, due date, grace period, penalties, credit limit, service charge, transferability, weekly or monthly or annual fees, automatic

repayment, payment of other obligations, monetary advance, re-negotiated debt, and exchange value.

[00146] An exemplary method for obtaining a loan is provided in

Figure 18. According to the method in Figure 18, the character logs into an existing bank account and requests a loan. Based on the available credit provided by the real world credit line securing the account, the credit score either real or virtual or both of the character and the amount of outstanding debt the character and/or player may have, the bank or other entity determines the amount of currency it is willing to lend to the character. The character then indicates the amount it wishes to borrow and the bank or other entity determines the interest rate and other terms of the loan, though these steps may be performed in either order, i.e. the bank or other entity may determine the terms and interest rate for the loan prior to disclosing the amount it is willing to lend. The player may then be presented with payment options as shown in Figure 16 or payment options may be dictated by the lending entity and the character may then either accept or reject the terms and the loan as shown in Figure 17. According to one embodiment, complex Loan Generation program 128 may be configured to follow some or all of the following steps:

1. Receive a request to borrow virtual cash including a player character ID, a credit card number, and/or a real world credit line amount, an virtual asset to purchase or build with the loan,

2. Validate credit card number and real world credit line amount

3. Retrieve player character account to access credit score of player character

4. Determine a virtual cash loan amount based on real world credit line amount, virtual asset being purchased or created, and credit score of player character

5. Determine an interest rate and virtual cash payment schedule based on real world credit line amount, virtual asset being purchased or created, and player character credit score.

6. Output a loan offer including a virtual cash loan amount, interest rate and virtual cash payment schedule to player character

7. Receive acceptance of loan offer from player character

8. Lock real world credit line

9. Create new loan record

10. Output virtual cash to player character account

[00147] Alternatively, generation of a loan may create a written contract between the character and financial intermediary or between characters. An exemplary contract is shown in Figure 20. According to one embodiment, bank server 104 may be configured to perform some or all of the following steps:

1. Receive real world credit card number and credit line from a player character

2. Retrieve player character profile

3. Validate available credit line on real world credit card

4. Determine amount of virtual loan and interest rate based on real world credit line and player character profile

5. Output loan offer to player character

6. Receive acceptance of offer from player character

7. Lock real world credit line for all or a portion of loan value

8. Create Loan Contract

9. Output Loan Contract to Player Character

10. Receive virtual signature of contract from Player Character

11. Deposit Loan amount into player character account

[00148] Once the loan is generated, regardless of the type of loan or the lender, a system of payments is instituted. Payment of the loan may be made manually, in which the character submits each payment individually, or automatically, in which the game or bank server automatically removes funds from the character's account or charges the player's real world credit line when payments are due. In one embodiment, the character can elect to make loan payments with a fixed real cash value amount that is guaranteed against currency fluctuation. If either (i) the player account does not have adequate funds for the game server to withdraw the virtual loan payment amount or (ii) the player character does not pay the invoice sent by the bank then a real cash value can be determined for the virtual loan payment amount and charged to the credit card associated with the player character or, if applicable, with a third party or other player character who agreed to secure

the loan for the defaulting player character. In one embodiment, Loan Payment program 138 may be configured to perform some or all of the following steps:

1. Determine that a loan payment is due

2. Determine value of loan payment in real and virtual cash

3. Output notification to player character that loan payment is due including payment options and values

4. Receive payment option choice from player character

5. If option choice was virtual, remove virtual cash amount from player character account

6. If option was real, retrieve credit card associated with loan and charge real cash amount to credit card

[00149] Management of payments may be accomplished by any means applicable. In another embodiment, Loan Payment program 132 may be configured to follow some or all of the following steps:

1. Retrieve loan agreement

2. Determine if payment is due

3. If payment is due, determine virtual cash payment amount due

4. Withdraw amount from player character account

5. If player account does not have enough virtual cash to cover payment,

6. Determine a real cash value of the virtual payment

7. Retrieve credit card used to secure loan

8. Charge real cash value to credit card

9. Notify player that credit card was charged

[00150] According to a further embodiment the owner of the security may be notified that there is not enough virtual cash in the account to make the necessary payment and provide the owner of the security with a variety of options for making the payment. The owner of the security may elect to make a payment using virtual currency from another account, may elect to sell an asset to generate virtual currency to make the payment, buy virtual currency to pay the debt, or elect to have the underlying real world credit line guaranteeing the loan charged. In the event that the loan is guaranteed by a third party, the third party may charge a fee to the borrower

for missing a payment In such embodiments, Loan Payment program 132 may be configured to follow some or all of the following steps:

1. Retrieve loan agreement

2. Determine if payment is due

3. If payment is due, determine virtual cash payment amount due 4 Withdraw amount from player character account

5. if player account does not have enough; virtual cash to cover payment, notify owner of credit card securing said loan

6. If credit card owner chooses to pay debt with virtual cash, notify borrower and update loan balances due, along with any additional interest or penalties, otherwise:

7. Determine a real cash value of the virtual payment

8. Retrieve credit card used to secure loan

9. Charge real cash value to credit card

10. Notify player that credit card was charged

[00151] Additionally, characters may be notified; when payments are due. Such notificaton may take the place of email or other mail Io either the character or the player, instant messaging, screen alerts, or any other type of notification generally used; within the parameters or the virtual world In one embodiment, Loan Payment (invoice) program 134 may be configured to follow some or all of the following steps:

1. Retrieve loan agreement

2. Determine if payment is due

3. If payment is due, determine virtual cash payment amount

4 Determine advertisement(s) based on player character activity

5. Generate invoice including virtual cash payment amount, date due, end advertisements

6. Transmit payment to player character

7. Determine if virtual payment was made on or before date due

8. If virtual payment was not made

9. Determine a real cash value of virtual payment

10. Retrieve credit card associated with loan agreement

11. Charge real cash value of virtual payment to credit card

[00152] In a further embodiment, once a loan is applied for and approved, a character in the game transfers the virtual currency to the borrowing character. A reminder is sent to the borrowing character that payment is due and/αr a reminder is sent to the player. Such a reminder may islce the form of an e-mail, instant message, or other type of written or verbal communication commonly used in these environments. Jf the loan payment is not made in a timely manner in either virtual or real currency, the financial security underlying the debt is charged.

[00153] 15 ^" ifte loan is belween characters instead of through a financial intermediary, it may still be monitored by the game or bank server. According tα one embodiment Loan Payment (invoice) program 134 may be configured to:

1. Retrieve loan agreement

2. Determine if payment is due

3. If payment is due, determine virtual cash payment amount

4. Determine advertisemeπt(s} based on ptayer character activity

5. Generate invoice including virtual cash payment amount, date due, and advertisements

6. Transmit payment to player character

7. Determine if virtual payment was maefs on or before date dus

8. If virtual payment was not made notify owner of credit card securing said loan

9. If credit card owner chooses to pay debt with virtual cash, notify borrower and update Eosn balances due. along with any additional interest or penalties, otherwise:

10. Determine a real cash value of virtual payment

11. Retrieve credit card associated with loan agr≤≤-meni

1 Z Charge real cash value of virtual payment fa credit card J00154] According *o anoiher embodiment, some Joans may have priority over other loans, i.e., if a piayer character enters bankruptcy or otherwise defaults on any loan, some- loans may recover from the assets of the player character before those Qf other tαans. Priority Qf loans may be established at the time the loan is secured and/or based upon the date secured, for example, giving preference to toans secured earlier over those

secured later. Priority may also foe granted based on the type of loan obtained, or the type of underlying assets used to secure the loan. For example, a foaπ used to purchase property may have priority G¥βr a loan used to purchase a disposable asset or ¥ice wersa.

[«01551 ^ * ^e event that a character becomes delinquent in his payments, the character and/or player may have one or more limitations imposed upon his actions frt the? vfrtuaf worfd by a) the bank, b) ihe game manufacturer, c) the awneF(s} of the serø≥r(s) upon which the game resides, ύ) one or mors player characters or e) any combination thereof. According to one embodiment, Ihe delinquent player may be prevented from obtaining any further loans whether from a bank or another pfayer. In another embodiment, the delinquent player may. be blocked from converting wtusl currency tσ reaf currency. In a further embodiment, a lien may be imposed upon the asseis of the character, In yet another embodiment, the delinquent character may be excluded from transacting business, owning land, or engaging trr other contracts within the ¥irfua[ world. Additionally,, or alterπatreeEyv the assets of the delinquent player may be seized and sold to cover the debt. The real world credii line used to secure the debt may also be charged in real world currency to cower the amount due. in one embodiment, upon delinquency, the entϊre amount of the loan may becoms immedEateEy due. En another embodiment ihe virtual representation of the character such as an a¥atar can be altered to indicate that the character has a delinquent account. For example, a ¥ϊrfuai cαfeciσn agent could traE the avstar around, a ball and chain could be attached: to the foot αf the ¹ avatar _r a warning cmM feat over ihe lisad oϊ iiie a^aiar. etc. In a further embodiment, if a payment is missed, any preferential terms may be subject to change. For example, ihe interest rate could increase, payment terms could acceterate, guaranteed exchange rates coufd become variable,, caps on interest OF exchange rales could be removed, etc.

[00156] As shown, information regarding loans and the entities providing foaπs may be stored En game server 102 in a μlumlϊtf of databases including, as nαπ-EErrattng examples a Eoan account database tβδ αr a debit card database 168. A Loan Account Database 166, may include information such as:

1. Bank ID

2. Loan Account ID

3. Player Character ID 1-n

4. Credit Card # 1-n

5. Conditions 1-n

6. Amount

7. Payments

8. Interest Rate

9. Start Date

10. Payment Date(s)

11. Type

12. Automated withdrawal?

13. Penalties (1-n)

{00157] In another embodiment, loan creation information is stored on game server 102. According to one embodiment, toaπ creation program 108 may be configured to:

1. Receive an indication that a virtual loan has been created from a bank, including the loan amount* conditions, and bank ID and player character IDs

2. Create and Store virfysf toart record

According to a further embodiment, Loan Generation program 130 may be configured to:

1. Create a new loan record

2. Notify game server that loan reeorcf has been created

Such information may alternatively or additionally be siored on bank server 104 in Joan account database 170. Such information may pertain to past, present or pending bans. The database may also Ineftide [nforrnattork on loans which are guaranteed bγ a third party, including another pfayer. The daiafease may further include information regarding defaults if any or late payments on the loan, Addiiionally, the database may include information regarding the transfer of the loan amount to the character or pteyer sccαuπi Each toart will be assigned a unique ϊdentεRer such as a number or a ssquef ice of alphanumeric characters. For each loan identifier, the database links ihe loan Information with the character and player information.

Information generated from the loan may a!sσ be Jinked with the character's credit score.

[G0172] According to one or more embodiments, the present invention provides a virtual environment in which a first player character establishes a contract with either one or more other player characters, entitles (real or ¥ϊriual) or a game sen/en The contract may specify one or more virtual financial obligation values that the first player character is obligated to p&γ at a specified virtual or real time and date. The contract may additionally include a credit card number associated with the game account of the first pJayer. According to additional embodiments, in the event that the first player character fails to pay the virtual financial obligation vsfue specified by the contract, a reat cash value may be established that equals the virtuaE financial obligation value and ihe first player's credit card may be charged the real cash yalue amount. [0§ϊ73J Examples of in game contracts include, but are not limited ley

1. Virtual loans-a player character or entity can barrow virtual cash from another player character, entity or ihe game server. An interest rate and payment schedule can be established, and payments csπ be secured by the player character ¹ s or entity's credit card.

2. \Mual Item renla3-a player character or entity can reni an in game iem from another player character, entity or the game server, A virtual cash fee per unit time can he established and secured with the placer character's or ertfi/s credit card.

3. Virtual dividend payments for shares of a company-a player character or entity can take his virtual company public by seKtπg shares to other player characters or entities. He can guaraniy a virtual cash dividend for each share per unit time. He can secure ihe virtual cash dividend with his credit card.

4. Virtual finance options-® placer character or entity cart choose to pay far an in game item with ¥irtual cash aver time rather ihmn up front λ virtual cash payment amount and payment schedule is established, and the player or entity

secures the virtual cash payments with a credit card, ff the player character or entity cannot make a specified virtual cash payment amount on a scheduled payment date _t a reat cash value us determined for the payment amount and charged to his credit card. Virtual item creation-A first player character can agree to build an in game item for a second player character by a certain date. If the first player character does not buM the Item m ihe lime specified, either the virtual bank account or a credit card on fife can be charged a specified fee for each unEt of time that it Es fete. Atso _r Ef the first pfayer character took an advance and or raw materfaEs from the second player character, a virtual cash fee can be charged to ihe Hrsi playsf s credii card equal to ihe yirtuaJ cash value of the advance. If the first player character can make the virtual cash payment, a reaE cash vatue cart be determined that Es equal to the virtual cash value and charged to the first pfayef s credit card. , Virtual futures contracts on goods bought or sold on an exchange- a pteyer character can establish art agreement to buy or SeJI ₁ wiih yirtual cash, a particular amount of a game resource or item at a specified virtual or real time period. A real cash value Es determined that is equal to the virtual cash value of the buy αr seE offer, ff tfre player character ts urtabfe Io sell or purchase Ihe item at the specified time, either (i) a penalty, (ii) ail Qr a portion of ihe real cash value of the contract αr (El) arty combination of one and fesro above can be charged to the ptayer/s credit card- Virtual help with soiying a mission or other game parameter- a ilrst player character can agree to help a second player character to solve a mission or other game parameter wϊtrtϊn a gE¥en toe period. Ef the first pta^er character fatfe to hefp the second playar chamύBf complete ihe specified game parameter in the time .specified, a penalty fee can be

charged to his credit card. Alternatively, a first player character can agree to pay a second player character a specified virtual cash amount if the second player character agrees to help him to complete a mission or other game parameter. If the second player character helps the first player character to complete the game parameter, and the first player character does not pay the agreed to virtual obligation, the first ptayer/s credit card cart be charged; a penalty and or the real cash value of the virtual obligation.

8. Virtual Insurance Payments and Claims-a player character can insure art in-game item with another player character or a game server. A periodic; virtual cash- insurance premium- payment can be determined for the item. If the piayer character cannot make a periodic virtual cash insurance premium payment, then his credit card is charged the real cash ¥a[ue of the periodic payment and/or a resf cash fee. Alternatively, a first player character makes a claim on a virtual Insurance policy. The game server verifies that the virtual insurance claim is legitimate, determines a vtrfuaf claim value, and charges a second player character (wfrα issued the claim) the virtual claim yalue amount If the second player character cannot pay the virtual claim value, theft a cash value is determined and charged; to the second player's credit card art file.

9. Wiua! Shipping-a first piayer character can agree to ship an item for a second player character to a certain virtual location ϊrt the game before a certain virtual or real date. The shipment of the item is secured with a credit card associated will! the first piayer character, if the item is not shipped or arrives late or damaged, a virtual cash fee can ibe charged to the player character account If the first pfayer character account does not have enough virtual cash to cover the fee, a real cash value for the fee can be determined and charged to the credit card associated with the first piayer character.

Virtual Deposits and Interest Payments-a first player character deposits virtual money into an account with a virtual bank owned by one or more other player characters. The deposit balance and any periodic virtual interest due on the balance are secured by at feast one credit card associated with the player characters that own the virtual bank, ff the bank is unable to pay a requested withdrawal amount equal; or less than the virtual bank account balance, the credit card securing lhe deposit can be charged the real cash value of ihe requested withdrawal amount Also, if the bank, cannot make a periodic interest payment-, the credit card securing the interest payment can be charged the real cash value of the payment. Identification Verlication — a player character may yse a credit card as a means to identify himself as the owner of a player character and/or to establish: liability for a player character's actions, including whether or not a player character pays bills on lime, in full, etc. Loyalty/ Program Identification — a player character may use a credit card number as a unique identifier for use as an IB for ioyaity programs or frequent shopper programs and the like. tayaway financing - a player character may purchase art in game object, service or resource, placing it into a "tayaway ^1* account and have monthly or other periodic charges added to fijs credit carcϊ until such ilrne as the entire balance is paid off, at which time, the Player Character would receive the object, service or resource. Virtual Taxes-A player character can agree to pay a certain amount of taxes, tariffs, tolls to a government structure run by the game server or by player characters. IF* the event that a player character cannot make a tax payment a reaf casEi value for ihe yJrtual cash amount can fee determined and charged to a credit card associated with the player character.

15. Virtual Adjudfcation-ln the event of a dsspute between pfayer characters, a game server or player character operated trial can determine a virtual settlement that a first player character needs to pay to a second player character. The first player character is given a time period within which to pay the settlement. Jf the first player character cannot pay the virtual settlement by the time specified, a real cash vafu© is generated for the virtual settlement and charged to fits credit card.

18. Hacking the System or Breaking Rules-Player Characters can agree to pay penalties if they/ hack the system or break the rules. If it Es determined that a player character has broken the rules or hacked the system, the credit card associated with the player character account can be charged a specified penalty amount

[QQ02I According to one or more- embodiments of the present invention,, any financial account can be used by the player to secure the virtual contracts he establishes with his player characters. The following accounts are non- fϊmitϊng examples of the type of player character-owned accounts, that c&n be used, cndrøduatty or in any combination:,, to secure a virtual contract:

1. credit card

2. debit card linked to a bank account

3. a bank account

4. a checking account

5. an IRA account

6. paypai account

7. Play time carcf-a pteyer can buy a play time card that allows them to play for a speclfe period of time. A portion of the credit on the card can be locked up to secure virtual obligations in the game environment

8. persona! guaranty-a player can sign a personal guaranty that allows the game server to put a lien on the player's real world assets in ihe event of a default on a contract in a game environment.

9. Escrow account-a player character can place virtual or real items in escrow that he can use as collateral against in game contracts.

10. Margin account-a game server or first player character can establish a margin account for a second player character that the second player character can use to secure in game contracts, A margin account could be automatically givert to a player character by/ a game server απσe certain gam© attributes, skills, and levels have been reached.

11. Annuity account - a player character can allocate a portion or all of his payments due to htm under an annuity, such as a life insurance payout tottery winnings,, judgment award, reverse mortgage, or any other annuity based income.

[00174] The amount charged to the pJayefs credit card in the event of a default on a virtual contract can be:

12. The reaE cash value of the virtual: obligation that was not paid

13. A specified penalty amount

14. A penalty amount generated based on the default amount

15. A real cash amount either equat fo _r less than or greater than the virtual amount

16. Any combination of the above.

[0θ175J According to one or more embodiments of the present invention, the game server can automatically charge virtual cash values to the player character bank account or the game server cart noHfy a player character when a virtual cash value is due.

IWT7&1 According to one or more embodiments of tie present invention, Player Characters who have reached certain levels of the game or acquired certain amount of virtual value in a game may not be required to secure their contracts with a credit card. Such "financially secure" Player Characters may vouch for less financially secure player characters by offering their virtual value as collateral Alternatively or additionally, Player Characters may also receive margin dollars based on the level σr sfcEIEs they have obtained. (00177| According to one or more embodiments of the present invention, Player characters can be given a warning and a grace period if they do not

pay the virtual cash obligation on the virtual or reaf date specified or there is not sufficient virtual cash in their virtual cash account for the virtual obligation to be automatically withdrawn.

[0M7S1 According to one or more embodiments of the present invention, warnings may be delivered by any one or more of the following mechanisms including, but not limited to, in game alerts, In game Instant messaging, real world e-mail, voice mail,, postal mail _r or text messages, [β&179f According to one or more embodiments of ttie present inwentfαπ, Player characters could have the choice of using virtual or real cash to pay the virtual obligation when It becomes due. Characters could be offered this option on every purchase they make in a game environment For example, a player purchasing a game item in an in gams exchange can elect to pay real or ylrtual money during the transaction. The exchange Interface offers the choice between purchasing the item for real or virtual cash and the value of the item in- real and virtual cash is displayed. If the player selects virtual cash, the amount is debited from his virtual cash, account Ef the player selects real cash, the amount Is charged io his credit card on file.

[OGlSO] According to one or more embodiments of the present invention, when making a decision to use real or virtual cash to pay for an. item or service, the player character (aπdfar game server} may request bids from oiher player characters or entities to pay for ihe item at some level of exchange rale ihai differs from Ihe current exchange rate. For example, if a player character wishes to buy a virtual swore! and the price is: $10 USD or 100 units of in game> currency (e.g. ptece of gold. $LB _r βtc4 there may be third party player characters that may desire to pay the real cash value in exchange for some amount of LD, thai may be less or more than ihe current exchange rate. fβftlitlf According to one or more embodiments of the present En¥eπtϊαπ _r when a player's financial account cannot cover the real cash obligation specified by a virtual contract, the account can be suspended and the virtual assets owned by the player character cart be automatically liquidated and the proceeds divided acnαngst virtual contract holders (other player characters αr Ihe game server) in ratio of the contract values. Alternatively or additionally, some or all of the virtual assets owned by the player may be immediately sold

for their market yaiue. The assets may be sold one at a time (in any order specified by the rules of the game server i.e. most to least valuable, least to most valuable, most to least liquid, feast to most liquid, etc) untέt the virtual obligations of the player character have been met. If all the assets of the player character are sold and the virtual cash does cannot cover the virtual obligations, the cash can be paid to the creditors using any suitable means including, but not totted to _r : (i) on ratio equal to the obligation for each creditor compared to the total outstanding obligations- and/αr Qi) in order of priority. A creditor can be given priority based on (!) paying to be a priority creditor when the virtual contract is established; (ii) the amount of the obligation; (iii) the date the virtual contract was established; (tv) the remaining obligation- of the contract vs. the total obligation; or (v) paying off deb Ls to independent third party player characters or entities as opposed to those player characters / entities ihat are either own by or related to the indebted player character. [βαiS2] According to one or more embodiments of the present invention, the game server cart periodically/ ping the credit card or other fErtaπcraE account identifier of ihe player Io make sure Ihat there is adequate cash or credit line associated with the account to cover all the virtual obligations that the player has established: with his characters.

[OttlSS] According to one or more embodiments: of the present invention, Wnen a virtual obligation is established, an amount that is equal to or a percentage of that obligation can be locked on the credit card so that it cannot be used for anything other than covering the virtual obligation. [OQl&ff According to one or more embodiments of the present invention, when a virtual obligation is established, an interest in Bn insurance policy can be purchased for a fee ihat is charged to the credit card. According to one example of this embodiment, trt the event of a default, the insurance policy pays tie debt; however the player character's rating would be towered and/or future policies rejected outright If an insurance company (reaf or virtual) pays the debt, the insurance company could seek restitution from the defaulting player character.

[βttiSSf According iα one or more embodiments of the present tπvenϋαπ, the game server can conduct a preaulhorkation of the player credit card equal to the cash value of ihe virtual obligation when the virtual contract is

established. If the preauthorization fails, the contract cannot be executed and the appropriate parties (player characters and or game server) are notified. [001S61 According to one or more embodiments of the present invention, a player character may not be able to sell assets in a game or on an ^■ exchange between game servers or games If fie has contracts established in a game environment. Alternatively, an amount of the player character's assets equal to his vϊrtuaE cash obligations cannot be sold art art in game, Enter game server, or intra game exchange.

[061873 According to one or more embodiments of the present invention, when a player character creates a contract, the game server can upsell a credit card to that player character to use to secure the contract. Ef the pEayer character accepts the offer, he fls out a credit card; application. The application is submitted to the card issuing 'bank. If the bank accepts the application, a new card number is issued and used to secure the contract. [0&I8S] According to one or more embodiments of the present invention:,. when a player creates a game account, the game server can upseϋ a credit card that the player character can use to secure contracts {and pay for his monthly fees) As an incentive to sign up for the card, the card can be issued with a certain amount of credit fine that can be used to secure contracts with no payment obligation for the player. For example, the player could be given $50 worth of credit line to use to secure against in game contracts. If the player defaults on a contract in the game, the game can automatically charge the credit card account the specified penalty amount. As long as that amount is less than $50, then the player is not obligated to pay; off the balance on the credit card.

[0θ1S9] According to one or more embodiments of the present invention, a fee can be charged by a game server or player character who facilitates and enforces the contracts between other player characters and the game server. This fee can be a flat fee, a "per transaction" fee, or a percent of the total value of the contract or payment fee.

[0øl3iJ According to one or more embodiments of the present invention, rather than a real cash fee being charged to a credit card only when the virtual obligation cannot be paid with virtual cash, the player can Just pay a recurring real cash fee to borrow virtual cash in a game environment Either the game

server or the player character can issue the virtual loan and receive the monthly real cash fee. The monthly fee can be charged to the player character by the game server and a portion of the fee can be remitted, in real or virtual cash to a second player character who initiated the loan.

[00191] According to one or more embodiments of the present invention, a player character can rent a sum of virtual cash for a monthly real cash fee that is charged to his credit card. In this embodiment, a piayer pays a monthly real cash amount as long as he has borrowed a certain amount of money from a game server or other player character. According to one example of this embodiment, when the player character repays the loan, the real cash monthly fee may no longer collected by the game server. [QM92J According to one or more embodiments of the present invention, a player character can also rent a sum of virtual cash for a recurring virtual cash fee. If the player character cannot pay the recurring virtual cash fee, a real cash value is determined and charged to the player credit card. [00193} According to one or more embodiments of the present invention, a player character can be offered the choice to pay a basic monthly fee for his account, or an additional monthly fee for his account that includes an upfront loan of virtual cash.

[00194] The present disclosure also provides systems for securing contracts established in virtual environments. Accordingly, turning to Fig. 22, a suitable system 210 may include a centra! server 212 in electronic communication with any number of suitable programs including, for exampEe and without limitation: a Contract Generation Program 214; a Contract Enforcement Program 18; a Asset liquidation and Redistribution Program 218; a Credit Card Upsell Program 220; and a Virtual Cash to Real Cash Exchange Program 222.

[0&195] System 210 may further comprise any number of suitable databases. Examples of suitable databases include, but are not limited to, a player database 224, a player character database 226, a contract database 228, and a virtual bank database 230.

[0019Q Player database 224 may include information about each player who accesses the game. This Information may be provided to the game server by a player when the player registers to play the game, or at any other

suitable time and using any suitable means. Examples of player information include, but are not limited to: player ID, player contact information, player credit card information, and/or player character ID.

[00197] Player character database 226 may include information about each player character that participates, or is able to participate, in a game. Accordingly, it will be understood that according to some types of games, a single player may create and control more than one player character. Examples of information the player character database may maintain include, but are not limited to: player character ID, player character profile, player character asset(s), player character attribute(s), player character contract(s). Of course it will be understood that for many of these information categories, a given player character may have multiple entries. For example, a given player character may have any number of attributes which could be tracked and maintained by the player character database.

[0019S] Contract database 228 may include information about any virtual agreements entered into by player characters. Examples of infbrmatbn the contract database may maintain include, but are not limited to: contract ID, player character ID, Player character type, contract type, contract obligation(s). Of course it will be understood that for many of these information categories, a given contract may have multiple entries. For example, a given contract entered into by a given player character may have numerous contract obligations which can be tracked and maintained by the contract database. Examples of contract obKgattort EnfσFmatϊoπ that coufd be tracked and maintained by the contract database includes, but fs not froited to: player character, obligation type, obligation amount, obligation date, obligation penalty, obligation grace period, obligation warning message, and default rules.

[00199] Virtual bank database 230 may include information related to the methods and financial instruments used to guarantee certain in-game agreements. For example, the virtual bank database may include information including, but not limited to: player character owner, player character owner credit card number, account balance, maximum deposit limϊt, interest rate, interest payment schedule, player character account, and loan account number, ft will be appreciated that any of these categories of information may

include subcategorizable information. For example, the player character account information may include numerous sub-categories of information including character ID, character balance, character interest rate, and interest payment schedule. Alternatively or additionally, the loan account information may include sub-categories of information including character ID, loan amount, payment(s), interest rate, and credit card number. [00200] The following paragraphs describe various methods and steps therein according to the present disclosure: [00201] Establishing a Contract a. Loan i. Player Character to Game Server

1. Receive virtual contract initiation request including virtual cash loan amount from player character

2. Determine contract obligations and conditions of loan

3. Output obligation and conditions of loan

4. Receive acceptance of obligations and conditions

5. Retrieve or receive player credit card number associated with player character

6. Activate and store virtual loan contract along with loan amount, obligations, conditions, limits (if any) and player credit card

7. Issue virtual cash loan amount to player character ii. Player Character or entity to Player Character or Entity

1. Receive, store, and output and post virtual cash loan request from a first player character

2. Receive, store, and output response to virtual cash loan request including obligations and conditions from a second player character

3. Receive acceptance of obligations and conditions from first player character

4. Retrieve or receive credit card associated with first player character

5. Create, activate and store a virtual contract including obligations, conditions, and credit card

6. Receive virtual cash loan amount from second player character

7. Issue virtual cash loan amount to first player character b. Dividend i. Player Character (or Entity) to Player Character (or Entity)

1. Receive a request to sell shares of a virtual company including a guaranteed virtual cash dividend per time period per share amount from a first player character

2. Retrieve or receive a credit card associated with first player character

3. Store request to sell shares including credit card and dividend information.

4. Output request to sell shares

5. Receive a request to buy shares from a second player character

6. Receive virtual cash payment for shares from a second player character

7. Distribute virtual cash payment for shares to first player character

8. Receive shares for virtual cash payment

9. Distribute shares to second player character c. Finance Option i. Player Character to Game Server

1. Receive request to purchase an in game item with virtual cash from a player character

2. Generate and output one or more virtual offers to finance the item purchase that includes a number of virtual cash payments at a specified number of time period intervals

3. Receive an acceptance of a finance offer from the player character

4. Retrieve or Receive a credit card associated with the player character

5. Establish and store financing contract including the virtual cash payment amount, the number of payments, the dates for each payment, and the credit card information.

6. Output virtual item to player character, ii. Player Character to Player Character

1. Receive and post a request from a first player character to sell a virtual item, including a virtual purchase price and one or more finance option packages that include a finance payment price, a total number of finance payments, and a schedule of when the payments are due.

2. Receive virtual item from virtual account of first player character

3. Receive a request to purchase the virtual item from a second player character including an agreement to purchase the item with a finance option package.

4. Retrieve or Receive the credit card number associated with the second player character

5. Store request to purchase the virtual item with the credit card

6. Output virtual item to second player character account d. Item Creation i. Player Character to Player Character

1. Receive, Store and Output a request to assemble an in-game item, including at least one of (i) a virtual cash amount, (ii) a blueprint, (iii) in game natural resources and game items necessary to assemble the item, (iv) a date / time of expected delivery, and (v) the agreed upon or expected quality of the item or its constituent components.

2. Receive an acceptance of the offer by a second player character who has the appropriate skills

necessary to assemble the item, including the price and a time when the item will be complete.

3. Receive or retrieve a credit card associated with the second player character.

4. Store credit card with accepted offer to assemble an in-game item. e. Futures Contracts i. Player Character to Game Server

1. Receive a virtual offer to buy or sell an in game item or in game resource at a specified later date and price, including an offer amount from a player character

2. Accept offer

3. Retrieve or receive credit card associated with player character

4. Store credit card with offer

5. Receive offer amount from player character ii. Player Character to Player Character

1. Receive a virtual offer to buy or sell an in game item or in game resource at a specified later date and price, including an offer amount from a first player character

2. Receive an acceptance of the virtual offer from a second player character

3. Receive or retrieve a credit card associated with the first player

4. Create, activate, and store a virtual offer contract including the credit card number of the first player character

5. Receive virtual offer amount from second player character account

6. Transmit virtual offer amount to first player character account (less transaction fee if applicable) f. Help with Solving a Mission

i. Player Character to Player Character

1. Receive, store and output a virtual request for help in solving a virtual mission from a first player character including a mission, a date by which the mission must be complete, an amount to pay if the mission is completed and a penalty for not completing the mission

2. Receive an acceptance of the virtual request from a second player character

3. Receive or retrieve a credit card for both player one and player two

4. Store credit cards with request

5. Make request active

6. Determine if request was fulfilled by specified date

7. If request was fulfilled charge virtual payment amount to first player character virtual account. a. If first player character virtual account cannot fulfill payment amount, determine real cash value for virtual payment amount and charge real cash value to credit card or insurance policy associated with first player character

8. If request was not fulfilled, retrieve virtual penalty amount and charge amount to virtual account of second player character a. If virtual account of second player cannot cover virtual penalty amount, determine real cash value of virtual penalty and charge real cash value to credit card or insurance policy associated with second player character g. Insurance Premium i. Player Character to Player Character

1. Receive, store and output a virtual contract to insure a particular virtual item from a first player character

2. Receive an offer to accept the contract, including at least one virtual insurance premium amount from a second player character

3. Receive an acceptance of the virtual insurance premium amount from the first player character

4. Retrieve or receive a credit card for both the first and second player character

5. Activate virtual insurance contract and store credit card numbers with contract

6. When virtual premium is due, charge premium amount to virtual account of the first player character a. If the virtual premium payment cannot be taken from the virtual account of the first player character, determine a real cash value for the virtual premium and charge the real cash value to the player character's credit card ii. Player Character to Game Server

1. Receive a request to insure a virtual item from a player character

2. Generate and output at least one virtual insurance premium amount including at least one date when the premium amount is due.

3. Receive acceptance of virtual insurance premium amount

4. Create virtual insurance contract

5. Retrieve or receive a credit card associated with player character

6. Store credit card with virtual insurance premium amount. h. Insurance Claim i. Player Character to Player Character

1. Receive a virtual claim on an virtual insurance contract from a first player character

2. Determine if virtual claim is valid

3. If claim is valid, determine a virtual claim value based on virtual insurance contract

4. Determine a second player character who issued the virtual insurance contract

5. Output request for virtual payment for virtual claim value to a second player character

6. If second player character does not pay the virtual payment, determine a real cash value for the virtual claim value

7. Charge the real cash value to the credit card associated with the second player character. i. Shipping i. Player Character to Player Character

1. Receive a virtual item to ship from a first player character including a present virtual location and a requested virtual location

2. Determine and output a virtual shipping amount, delivery date, and real cash penalty amount

3. Receive acceptance of shipping amount and delivery date from a second player character

4. Receive or retrieve a credit card associated with second player character

5. Create shipping contract with virtual item, shipping amount delivery date, penalty amount, and credit card

6. Determine if item was delivered on or before delivery date

7. If item was delivered, charge shipping amount to first player character account

8. If item was not delivered, retrieve penalty amount

9. Charge penalty amount to credit card ii. Player Character to Game Server

1. Receive a virtual item to ship from a player character including a present virtual location and a requested virtual location

2. Determine and output a virtual shipping offer, including a virtual shipping amount, delivery date, and real cash penalty amount

3. Receive acceptance of the virtual shipping offer

4. Receive or retrieve credit card associated with player character

5. Deliver item

6. Charge shipping amount to player character a. If player character cannot pay shipping amount, retrieve real cash penalty amount and charge amount to player credit card, j. Virtual Bank Deposit i. Player Character to Game Server (set up virtual bank)

1. Receive a request to set up a virtual bank from a player character including one or more credit cards with corresponding credit lines

2. Set up virtual bank with an allowed deposit limit equal to the corresponding credit lines

3. Receive an interest rate amount

4. Store interest rate amount with virtual bank ii. Player Character to Player Character (receive deposit)

1. Output a bank deposit offer from a first player character, including a maximum deposit amount and an interest rate

2. Receive a request to make a virtual cash deposit from a second player character that is equal or less than the maximum deposit amount

3. Determine if second player character already has an account with the virtual bank a. If not, set up virtual bank account for second player character and deposit virtual cash funds Or

b. If so, deposit virtual cash funds into existing virtual bank account associated with second player character 4. Reduce maximum allowed deposit amount by virtual cash deposit k. Taxes i. Player character to game server or player character

1. Receive request from a player character to become a member of a virtual entity or use a virtual service

2. Generate and output a tax amount

3. Receive an acceptance of the tax amount from the player character

4. Retrieve or receive a credit card associated with the player character

5. Create a membership or permit including player character information and credit card number

I. Adjudication i. Player character to player character

1. Receive and Store a determination of a virtual settlement amount to be paid by a first player character to a second player character including a virtual cash amount and a due date

2. Receive or retrieve a credit card associated with the first player character

3. Store credit card with determination m. Breaking rules or hacking the game i. Player character to game server (initial agreement)

1. Receive request to create an account from a player

2. Output terms and conditions including agreement to charge penalty fees to a credit card in the event of rule breaking or hacking

3. Receive and store acceptance of terms, player information, and player credit card information

[00202] Enforcing a Contract

a. Loan, Dividend, Finance Payment, Insurance Premium ii. Player Character to Game Server

1. Determine that a virtual obligation payment is due

2. Charge obligation payment to player character account

3. If player character account cannot cover obligation payment, determine a real cash value of obligation (including fees and/or penalties and fines)

4. Charge real cash value to player credit card iii. Player Character to Player Character

1. Receive a complaint that a first player character could not pay a second player character a virtual obligation payment

2. Determine if complaint is valid

3. If complaint is valid determine or retrieve a real cash value of obligation payment

4. Charge real cash value to credit card associated with first player character

5. Pay second player character the virtual obligation payment (in real or virtual cash) b. Item Creation iv. Player Character to Player Character

1. Receive a complaint that a first player character did not complete the creation of an item for a second player character.

2. Verify that complaint is valid

3. If complaint is valid, retrieve a real cash penalty value associated with the item creation contract

4. Retrieve a credit card associated with a first player character

5. Charge real cash penalty value to credit card

6. Credit real or virtual account of second player character with penalty value (less applicable fees) c. Futures Contracts

v. Player Character to Game Server

1. Receive indication that player character could not fulfill futures contract

2. Retrieve or Generate a penalty amount

3. Charge penalty amount to virtual account of player character

4. If virtual account cannot cover penalty, retrieve player credit card

5. Determine a real cash value of the penalty amount

6. Charge amount to player credit card vi. Player Character to Player Character

1. Receive complaint from a first player character that a second player character could not fulfill a futures contract

2. Verify that complaint is accurate

3. Retrieve or generate a virtual penalty amount

4. Retrieve credit card of second player character

5. Charge second player character the virtual penalty amount

6. If second player character account cannot cover virtual penalty amount, generate a real cash value

7. Charge real cash value to credit card

8. Pay penalty arηount (in real or virtual cash) to the first player character, less any applicable fees. d. Help with Solving a Mission vii. Player Character to Player Character

1. Receive a complaint that a first player character has not successfully helped a second player character complete a mission

2. Verify complaint

3. If complaint is accurate, retrieve virtual penalty

4. Charge first player character account penalty amount

5. If first player character account cannot cover penalty amount, determine real cash value of penalty amount

6. Retrieve credit card associated with first player character

7. Charge real cash value of penalty amount to credit card e. Insurance Claim viii. Player Character to Game Server

1. Receive a complaint that a first player character has not paid an insurance claim to a second player character

2. Validate complaint

3. If complaint is validated, determine real cash value of claim

4. Retrieve credit card associated with first player character

5. Charge real cash value of claim to credit card (plus applicable fees)

6. Pay real or virtual cash value of claim to second player character (less applicable fees) f. Shipping Item ix. Player Character to Player Character

1. Receive complaint that a first player character did not deliver an item for a second player character

2. Validate complaint

3. If complaint is validated, determine a real cash penalty amount

4. Retrieve credit card of first player character

5. Charge penalty amount to credit card (plus applicable fees)

6. Determine a virtual cash value for the real cash penalty amount

7. Pay virtual cash value to account of second player character (less applicable fees) x. Player Character to Game Server

1. Deliver a virtual item to a specified virtual location

2. Charge shipping amount to player character account

3. If player character account cannot pay shipping amount, retrieve credit card associated with player character account

4. Determine a real cash penalty amount

5. Charge penalty amount to player credit card g. Virtual Bank Deposit xi. Player Character to Player Character

1. Receive a request from a first player character to withdraw funds from a virtual bank account owned by a second player character

2. Determine if the virtual bank has enough virtual cash to cover the withdrawal amount a. If yes, transfer funds from virtual bank account to first player character account b. If no, determine a real cash value for the withdrawal amount i. retrieve credit card associated with virtual bank ii. charge credit card real cash value of withdrawal amount (plus any fees) iii. transfer funds from virtual bank account to first player character account h. Virtual Bank Interest xii. Player Character to Player Character

1. Determine that interest is due on a balance deposited by a player character in a virtual bank account.

2. Calculate virtual cash interest payment

3. Determine if virtual bank has enough virtual cash on hand to cover interest payment a. If so, make interest payment b. If not, determine a real cash value of interest payment i. Retrieve credit card associated with virtual bank ii. Charge credit card real cash value iii. Convert real cash value into virtual cash and deposit into virtual bank iv. Transfer virtual cash from virtual bank to player character bank account, i. Taxes xiii. Player character to game server

1. Receive or Generate indication that a virtual tax is due

2. Determine virtual tax amount

3. Attempt to charge tax amount to virtual cash account of player character

4. If virtual cash account can cover tax amount, remove tax amount from account

5. If virtual cash account cannot cover tax amount: a. Determine a real cash value of the virtual tax amount b. Retrieve credit card associated with player character account c. Charge real cash value to player character account (plus applicable fee) d. Convert real cash value to virtual cash amount and deposit in virtual cash account of player

e. Remove virtual cash amount from player character virtual cash account xiv. Player character to player character

1. Receive or Generate indication that a virtual tax is due from a first player character to an entity controlled by one or more other player characters

2. Determine virtual tax amount

3. Attempt to charge tax amount to virtual cash account of player character a. If virtual cash account can cover tax amount, transfer virtual cash amount from first player character virtual cash account to virtual cash account of entity controlled by one or more other player characters

4. If virtual cash account cannot cover tax amount: a. Determine a real cash value of the virtual tax amount b. Retrieve credit card associated with first player character account c. Charge real cash value to first player character account (plus applicable fee) d. Convert real cash value to virtual cash amount and deposit in virtual cash account of first player e. transfer virtual cash amount from first player character virtual cash account to account of entity controlled by one or more other _x player characters j. Adjudication xv. Player character to player character

1. Retrieve determination on due date

2. Attempt to charge virtual settlement amount to first player character virtual cash account

3. If first player character virtual cash account can cover settlement amount, transmit amount (less applicable fees) to second player character virtual cash account

4. If first player character virtual cash account cannot cover settlement amount: a. Determine a real cash value for the virtual settlement amount b. Charge real cash value to credit card associated with first player character c. Convert real cash to virtual cash d. Transfer virtual cash (less applicable fees) to the virtual cash account of the second player character k. Breaking rules or hacking the game xvi. Player character to game server (infraction occurrence)

1. Determine that a player character has committed an infraction

2. Determine a penalty amount

3. Retrieve credit card associated with player character

4. Charge credit card penalty amount [00203] Locking player character accounts and liquidating assets a. Determine that a virtual obligation cannot be paid with a virtual account associated with a player character b. Determine a real cash value for the virtual obligation c. Retrieve credit card associated with player character d. Attempt to charge real cash value of virtual obligation to credit card e. If attempt fails, lock virtual assets of player character account, f. Post and sell virtual assets on appropriate in game marketplace or exchange g. Retrieve virtual creditor list

h. Determine % of player character asset value due to each virtual creditor i. Transmit appropriate % of asset value to each virtual creditor [00204] Generating warning message if virtual obligation cannot be met a. Determine that a virtual obligation cannot be paid with a virtual account associated with a player character b. Determine a real cash value for the virtual obligation c. Retrieve credit card associated with player character d. Attempt to charge real cash value of virtual obligation to credit

e. If attempt fails, output warning message to player character [00205] Disabling selling virtual assets if Player Character has virtual obligations a. Determine a total virtual obligation amount for a player character b. Set a minimum virtual asset limit for the player account based on the total virtual obligation amount c. Disallow selling of any player character assets below virtual asset minimum.

[00206] Periodic check of credit card validity a. Determine that a player character account has a virtual obligation secured by a credit card b. Retrieve credit card number c. Verify that credit card is valid and/or has enough remaining credit to cover virtual obligation. d. If credit card is not valid and/or does not have enough remaining credit to cover a virtual obligation, lock assets of player character account equal to total virtual obligation amount.

[00207] Credit card upselling during contract initiation a. Receive request to initiate a virtual contract from a player character b. Output offer to register for a credit card to secure the transaction c. Receive acceptance of offer, including player billing information d. Submit credit card application for approval

e. If credit card application is accepted, bind virtual contract with new credit card. f. If credit card application is denied, output request to player character to use a different credit card to bind virtual contract xvi i. Receive alternate credit card from player character xviii. Use alternate credit card to bind contract [00208] Credit card upselling during player set up a. Receive request to create new player account b. Output offer to register for a credit card, including an upfront virtual benefit if offer is accepted c. Receive acceptance of offer, including player billing information d. Submit credit card application for approval e. If credit card application is accepted, issue credit card, set up player account with credit card, and store virtual benefit with player account f. If credit card application is denied, output request for alternate credit card xix. Receive alternate credit card XX. Set up player account with alternate credit card [00209] Providing a choice between virtual cash or credit card charge a. Determine that a virtual obligation of a player character is due b. Determine a virtual and real cash value of the obligation c. Output notification that virtual offer is due, including choice to pay for virtual obligation with real or virtual cash xxi. Receive indication that virtual obligation will be paid with real cash xxii. Charge real cash value to credit card associated with player character account Or xxiii. Receive indication that virtual obligation will be paid with virtual cash xxiv. Charge virtual cash value to player character virtual account [00210] Real cash charge to credit card for virtual loan payment or rental

a. Determine that a virtual obligation of a player character is due b. Determine real cash value of virtual obligation c. Retrieve credit card associated with player character d. Charge real cash value of virtual obligation to credit card. [00211] According to one or more embodiments, the present invention provides a virtual environment in which a first player character establishes a contract with either one or more other player characters, entities (real or virtual) or a game server. The contract may specify one or more virtual financial obligation values that the first player character is obligated to pay at a specified virtual or real time and date. The contract may additionally include a credit card number associated with the game account of the first player. According to additional embodiments, in the event that the first player character fails to pay the virtual financial obligation value specified by the contract, a real cash value may be established that equals the virtual financial obligation value and the first player's credit card may be charged the real cash value amount.

[00212] Examples of in game contracts include, but are not limited to:

1. Virtual loans-a player character or entity can borrow virtual cash from another player character, entity or the game server. An interest rate and payment schedule can be established, and payments can be secured by the player character's or entity's credit card.

2. Virtual item rental-a player character or entity can rent an in game item from another player character, entity or the game server. A virtual cash fee per unit time can be established and secured with the player character's or entity's credit card.

3. Virtual dividend payments for shares of a company-a player character or entity can take his virtual company public by selling shares to other player characters or entities. He can guaranty a virtual cash dividend for each share per unit time. He can secure the virtual cash dividend with his credit card.

4. Virtual finance options-a player character or entity can choose to pay for an in game item with virtual cash over time

US2006/040346

95 rather than up front. A virtual cash payment amount and payment schedule is established, and the player or entity secures the virtual cash payments with a credit card. If the player character or entity cannot make a specified virtual cash payment amount on a scheduled payment date, a real cash value is determined for the payment amount and charged to his credit card.

5. Virtual item creation-A first player character can agree to build an in game item for a second player character by a certain date. If the first player character does not build the item in the time specified, either the virtual bank account or a credit card on file can be charged a specified fee for each unit of time that it is late. Also, if the first player character took an advance and or raw materials from the second player character, a virtual cash fee can be charged to the first player's credit card equal to the virtual cash value of the advance. If the first player character can make the virtual cash payment, a real cash value can be determined that is equal to the virtual cash value and charged to the first player's credit card.

6. Virtual futures contracts on goods bought or sold on an exchange- a player character can establish an agreement to buy or sell, with virtual cash, a particular amount of a game resource or item at a specified virtual or real time period. A real cash value is determined that is equal to the virtual cash value of the buy or sell offer. If the player character is unable to sell or purchase the item at the specified time, either (i) a penalty, (ii) all or a portion of the real cash value of the contract or (ii) any combination of one and two above can be charged to the player's credit card.

7. Virtual help with solving a mission or other game parameter- a first player character can agree to help a second player character to solve a mission or other game parameter within a given time period. If the first player character fails to help

the second player character complete the specified game parameter in the time specified, a penalty fee can be charged to his credit card. Alternatively, a first player character can agree to pay a second player character a specified virtual cash amount if the second player character agrees to help him to complete a mission or other game parameter. If the second player character helps the first player character to complete the game parameter, and the first player character does not pay the agreed to virtual obligation, the first player's credit card can be charged a penalty and or the real cash value of the virtual obligation.

8. Virtual Insurance Payments and Claims-a player character can insure an in-game item with another player character or a game server. A periodic virtual cash insurance premium payment can be determined for the item. If the player character cannot make a periodic virtual cash insurance premium payment, then his credit card is charged the real cash value of the periodic payment and/or a real cash fee. Alternatively, a first player character makes a claim on a virtual insurance policy. The game server verifies that the virtual insurance claim is legitimate, determines a virtual claim value, and charges a second player character (who issued the claim) the virtual claim value amount. If the second player character cannot pay the virtual claim value, then a cash value is determined and charged to the second player's credit card on file.

9. Virtual Shipping-a first player character can agree to ship an item for a second player character to a certain virtual location in the game before a certain virtual or real date. The shipment of the item is secured with a credit card associated with the first player character, if the item is not shipped or arrives late or damaged, a virtual cash fee can be charged to the player character account. If the first player character account does not have enough virtual cash to cover the fee,

a real cash value for the fee can be determined and charged to the credit card associated with the first player character.

10. Virtual Deposits and Interest Payments-a first player character deposits virtual money into an account with a virtual bank owned by one or more other player characters. The deposit balance and any periodic virtual interest due on the balance are secured by at least one credit card associated with the player characters that own the virtual bank. If the bank is unable to pay a requested withdrawal amount equal or less than the virtual bank account balance, the credit card securing the deposit can be charged the real cash value of the requested withdrawal amount. Also, if the bank cannot make a periodic interest payment, the credit card securing the interest payment can be charged the real cash value of the payment.

11. Identification Verification - a player character may use a credit card as a means to identify himself as the owner of a player character and/or to establish liability for a player character's actions, including whether or not a player character pays bills on time, in full, etc.

12. Loyalty Program Identification - a player character may use a credit card number as a unique identifier for use as an ID for loyalty programs or frequent shopper programs and the like.

13. Layaway financing - a player character may purchase an in game object, service or resource, placing it into a "layaway" account and have monthly or other periodic charges added to his credit card until such time as the entire balance is paid off, at which time, the Player Character would receive the object, service or resource.

14. Virtual Taxes-A player character can agree to pay a certain amount of taxes, tariffs, tolls to a government structure run by the game server or by player characters. In the event that a player character cannot make a tax payment a real cash

value for the virtual cash amount can be determined and charged to a credit card associated with the player character.

15. Virtual Adjudication-ln the event of a dispute between player characters, a game server or player character operated trial can determine a virtual settlement that a first player character needs to pay to a second player character. The first player character is given a time period within which to pay the settlement. If the first player character cannot pay the virtual settlement by the time specified, a real cash value is generated for the virtual settlement and charged to his credit card.

16. Hacking the System or Breaking Rules-Player Characters can agree to pay penalties if they hack the system or break the rules. If it is determined that a player character has broken the rules or hacked the system, the credit card associated with the player character account can be charged a specified penalty amount.

[00213] According to one or more embodiments of the present invention, any financial account can be used by the player to secure the virtual contracts he establishes with his player characters. The following accounts are non- limiting examples of the type of player character-owned accounts that can be used, individually or in any combination, to secure a virtual contract:

1. credit card

2. debit card linked to a bank account

3. a bank account

4. a checking account

5. an IRA account

6. paypal account

7. Play time card-a player can buy a play time card that allows them to play for a specific period of time. A portion of the credit on the card can be locked up to secure virtual obligations in the game environment

8. personal guaranty-a player can sign a personal guaranty that allows the game server to put a lien on the player's real

world assets in the event of a default on a contract in a game environment.

9. Escrow account-a player character can place virtual or real items in escrow that he can use as collateral against in game contracts.

10. Margin account-a game server or first player character can establish a margin account for a second player character that the second player character can use to secure in game contracts. A margin account could be automatically given to a player character by a game server once certain game attributes, skills, and levels have been reached.

11. Annuity account - a player character can allocate a portion or all of his payments due to him under an annuity, such as a life insurance payout, lottery winnings, judgment award, reverse mortgage, or any other annuity based income.

[00214] The amount charged to the player's credit card in the event of a default on a virtual contract can be:

1. The real cash value of the virtual obligation that was not paid

2. A specified penalty amount

3. A penalty amount generated based on the default amount

4. A real cash amount either equal to, less than or greater than the virtual amount.

5. Any combination of the above.

[00215] According to one or more embodiments of the present invention, the game server can automatically charge virtual cash values to the player character bank account or the game server can notify a player character when a virtual cash value is due.

[00216] According to one or more embodiments of the present invention, Player Characters who have reached certain levels of the game or acquired certain amount of virtual value in a game may not be required to secure their contracts with a credit card. Such "financially secure" Player Characters may vouch for less financially secure player characters by offering their virtual value as collateral. Alternatively or additionally, Player Characters may also receive margin dollars based on the level or skills they have obtained.

[00217] According to one or more embodiments of the present invention, Player characters can be given a warning and a grace period if they do not pay the virtual cash obligation on the virtual or real date specified or there is not sufficient virtual cash in their virtual cash account for the virtual obligation to be automatically withdrawn.

[00218] According to one or more embodiments of the present invention, warnings may be delivered by any one or more of the following mechanisms including, but not limited to, in game alerts, in game instant messaging, real world e-mail, voice mail, postal mail, or text messages. [00219] According to one or more embodiments of the present invention, Player characters could have the choice of using virtual or real cash to pay the virtual obligation when it becomes due. Characters could be offered this option on every purchase they make in a game environment. For example, a player purchasing a game item in an in game exchange can elect to pay real or virtual money during the transaction. The exchange interface offers the choice between purchasing the item for real or virtual cash and the value of the item in real and virtual cash is displayed. If the player selects virtual cash, the amount is debited from his virtual cash account. If the player selects real cash, the amount is charged to his credit card on fife.

[00220] According to one or more embodiments of the present invention, when making a decision to use real or virtual cash to pay for an item or service, the player character (and/or game server) may request bids from other player characters or entities to pay for the item at some level of exchange rate that differs from the current exchange rate. For example, if a player character wishes to buy a virtual sword and the price is: $10 USD or 100 units of in game currency (e.g. piece of gold, $LD, etc.), there may be third party player characters that may desire to pay the real cash value in exchange for some amount of LD, that may be less or more than the current exchange rate.

[00221] According to one or more embodiments of the present invention, when a player's financial account cannot cover the real cash obligation specified by a virtual contract, the account can be suspended and the virtual assets owned by the player character can be automatically liquidated and the proceeds divided amongst virtual contract holders (other player characters or

the game server) in ratio of the contract values. Alternatively or additionally, some or all of the virtual assets owned by the player may be immediately sold for their market value. The assets may be sold one at a time (in any order specified by the rules of the game server i.e. most to least valuable, least to most valuable, most to least liquid, least to most liquid, etc) until the virtual obligations of the player character have been met. If all the assets of the player character are sold and the virtual cash does cannot cover the virtual obligations, the cash can be paid to the creditors using any suitable means including, but not limited to,: (i) in ratio equal to the obligation for each creditor compared to the total outstanding obligations; and/or (ii) in order of priority. A creditor can be given priority based on (i) paying to be a priority creditor when the virtual contract is established; (ii) the amount of the obligation; (iii) the date the virtual contract was established; (iv) the remaining obligation of the contract vs. the total obligation; or (v) paying off debts to independent third party player characters or entities as opposed to those player characters / entities that are either own by or related to the indebted player character. [00222] According to one or more embodiments of the present invention, the game server can periodically ping the credit card or other financial account identifier of the player to make sure that there is adequate cash or credit line associated with the account to cover all the virtual obligations that the player has established with his characters.

[00223] According to one or more embodiments of the present invention, when a virtual obligation is established, an amount that is equal to or a percentage of that obligation can be locked on the credit card so that it cannot be used for anything other than covering the virtual obligation. [00224] According to one or more embodiments of the present invention, when a virtual obligation is established, an interest in an insurance policy can be purchased for a fee that is charged to the credit card. According to one example of this embodiment, in the event of a default, the insurance policy pays the debt; however the player character's rating would be lowered and/or future policies rejected outright. If an insurance company (real or virtual) pays the debt, the insurance company could seek restitution from the defaulting player character.

[00225] According to one or more embodiments of the present invention, the game server can conduct a preauthorization of the player credit card equal to the cash value of the virtual obligation when the virtual contract is established. If the preauthorization fails, the contract cannot be executed and the appropriate parties (player characters and or game server) are notified. [00226] According to one or more embodiments of the present invention, a player character may not be able to sell assets in a game or on an exchange between game servers or games if he has contracts established in a game environment. Alternatively, an amount of the player character's assets equal to his virtual cash obligations cannot be sold on an in game, inter game server, or intra game exchange.

[00227] According to one or more embodiments of the present invention, when a player character creates a contract, the game server can upsell a credit card to that player character to use to secure the contract. If the player character accepts the offer, he fills out a credit card application. The application is submitted to the card issuing bank. If the bank accepts the application, a new card number is issued and used to secure the contract. [00228] According to one or more embodiments of the present invention, when a player creates a game account, the game server can upsell a credit card that the player character can use to secure contracts (and pay for his monthly fees) As an incentive to sign up for the card, the card can be issued with a certain amount of credit line that can be used to secure contracts with no payment obligation for the player. For example, the player could be given $50 worth of credit line to use to secure against in game contracts. If the player defaults on a contract in the game, the game can automatically charge the credit card account the specified penalty amount. As long as that amount is less than $50, then the player is not obligated to pay off the balance on the credit card.

[00229] According to one or more embodiments of the present invention, a fee can be charged by a game server or player character who facilitates and enforces the contracts between other player characters and the game server. This fee can be a flat fee, a "per transaction" fee, or a percent of the total value of the contract or payment fee.

[00230] According to one or more embodiments of the present invention, rather than a real cash fee being charged to a credit card only when the virtual obligation cannot be paid with virtual cash, the player can just pay a recurring real cash fee to borrow virtual cash in a game environment. Either the game server or the player character can issue the virtual loan and receive the monthly real cash fee. The monthly fee can be charged to the player character by the game server and a portion of the fee can be remitted, in real or virtual cash to a second player character who initiated the loan. [00231] According to one or more embodiments of the present invention, a player character can rent a sum of virtual cash for a monthly real cash fee that is charged to his credit card. In this embodiment, a player pays a monthly real cash amount as long as he has borrowed a certain amount of money from a game server or other player character. According to one example of this embodiment, when the player character repays the loan, the real cash monthly fee may no longer collected by the game server. [00232] According to one or more embodiments of the present invention, a player character can also rent a sum of virtual cash for a recurring virtual cash fee. If the player character cannot pay the recurring virtual cash fee, a real cash value is determined and charged to the player credit card. [00233] According to one or more embodiments of the present invention, a player character can be offered the choice to pay a baste monthly fee for his account, or an additional monthly fee for his account that includes an upfront loan of virtual cash.

[00234] According to one or more embodiments of the present invention, a method for providing multiple purchase options for virtual purchases is provided. In an online game, a player character can open a screen or pop up window to purchase items from the game server or other player characters. The screen allows the player character to view the item for sale, and purchase the item with either virtual currency or real currency. The game server receives the desired item to purchase, retrieves the virtual currency price for the item, converts the virtual currency price into a real currency price based on a current exchange rate, and outputs the virtual and real currency price to the player character. The player character can choose whether he wants to make the purchase with real or virtual currency. If the player character selects

virtual currency, the virtual currency amount is debited from his virtual currency account with the game server and the item is added to his inventory. If the player selects real currency, the real currency amount is charged to his credit card on file and the virtual item is added to his virtual inventory. [00235] According to one or more embodiments of the present invention, any transaction in the game environment can allow the buyer to pay with multiple real and virtual cash currency types.

[00236] According to one or more embodiments of the present invention, a player character can place virtual items he has in inventory in escrow and list other virtual items or groups of items he is willing to trade for those items. When a second player character indicates he wants to purchase one of these items or groups of items that have been placed into escrow by the first player character and the second player character has one or more of the other virtual items the first player character wants, he can elect to exchange items rather than pay for them with real or virtual cash. According to a further embodiment, the game server can offer the ability to exchange items on the same purchase screen where it offers real and virtual cash payment options. [00237] According to one or more embodiments of the present invention, transactions can be paid for by exchanging items in the player character's inventory for those items he wishes to purchase. In such a case, the game server may only accept items from the player character that are in demand, and/or may convert both items into a common exchange rate to determine the number of such items needed to buy an item. In the case of a shortfall, a player character may use items in inventory in combination with real or virtual cash.

[00238] According to one or more embodiments of the present invention, a player character purchase screen may give the player character the ability to purchase a virtual item with one or a combination of multiple currency types and/or objects for barter.

[00239] According to one or more embodiments of the present invention, a player can select which types of currencies he wants to view on the purchase screen. Multiple types of virtual and real cash can be displayed and selected. For instance, the real currency values could be displayed in United States Dollars, Japanese Yen, and/or any other types of real world currency.

The virtual currency values could be denominated and displayed in Linden Dollars, World of Warcraft Gold, and/or any other types of virtual world currency.

[00240] According to one or more embodiments of the present invention, if the purchase is made with virtual cash, it can be paid for from a virtual cash account or using a virtual loan or virtual finance option. [00241] According to one or more embodiments of the present invention, the game server can track purchases up to some fixed dollar amount, and charge the sum to the player's credit card rather than charging the credit card each time a virtual purchase is made with real cash. Alternatively, the game server could charge a fixed dollar amount to the credit card associated with the player character and decrement that amount with real cash purchases in the game environment until the fixed dollar amount is depleted, at which time the credit card would then be charge the fixed dollar amount again. [00242] According to one or more embodiments of the present invention, Any financial account can be used by the player to secure the virtual contracts he establishes with his player characters. The following accounts owned by a player character can be used, individually or in any combination, to secure a virtual contract:

1. credit card

2. debit card linked to a bank account

3. a bank account

4. a checking account

5. an IRA account

6. a cellphone account such as one offered by Cingular Wireless

7. a standard telephone account such as one offered by Qwest

Communications

8. an Internet Service Provider Account such as one offered by Earthlink

9. a cable account such as one offered by Comcast

10. a DSL account such as one offered by Qwest Communications

11. paypal account

12. Play time card-a player can buy a play time card that allows them to play for a specific period of time. A portion of the credit on the

card can be locked up to secure virtual obligations in the game environment

13. Personal guaranty-a player can sign a personal guaranty that allows the game server to put a lien on the player's real world and/or virtual assets in the event of a default on a contract in a game environment.

14. Escrow account-a player character can place virtual or real items in escrow that he can use as collateral against in game contracts.

15. Margin account-a game server or first player character can establish a margin account for a second player character that the second player character can use to secure in game contracts. A margin account could be automatically given to a player character by a game server once certain game attributes, skills, and levels have been reached.

16. Annuity account - a player character can allocate a portion or all of his payments due to him under an annuity, such as a life insurance payout, lottery winnings, judgment award, reverse mortgage, or any other annuity based income.

17. Line of credit with a bank.

18. Indentured Service, i.e., a commitment to perform services in exchange for a measured amount of virtual cash.

[00243] According to this embodiment, player database 224 may include information about each player who accesses the game. This information may be provided to the game server by a player when the player registers to play the game, or at any other suitable time and using any suitable means. Examples of player information include, but are not limited to: player ID, player contact information, player credit card information, and/or player character ID.

[00244] Player character database 226 may include information about each player character that participates, or is able to participate, in a game. Accordingly, it will be understood that according to some types of games, a single player may create and control more than one player character. Examples of information the player character database may maintain include, but are not limited to: player character ID, player character profile, player

character asset(s), player character attribute(s), player character contract(s). Of course it will be understood that for many of these information categories, a given player character may have multiple entries. For example, a given player character may have any number of attributes which could be tracked and maintained by the player character database.

[00245] Contract database 228 may include information about any virtual agreements entered into by player characters. Examples of information the contract database may maintain include, but are not limited to: contract ID, player character ID, Player character type, contract type, contract obligation(s). Of course it will be understood that for many of these information categories, a given contract may have multiple entries. For example, a given contract entered into by a given player character may have numerous contract obligations which can be tracked and maintained by the contract database. Examples of contract obligation information that could be tracked and maintained by the contract database Includes, but is not limited to: player character, obligation type, obligation amount, obligation date, obligation penalty, obligation grace period, obligation warning message, and default rules.

[00246] Virtual bank database 230 may include information related to the methods and financial instruments used to guarantee certain in-game agreements. For example, the virtual bank database may include information including, but not limited to: player character owner, player character owner credit card number, account balance, maximum deposit limit, interest rate, interest payment schedule, player character account, and loan account number. It will be appreciated that any of these categories of information may include subcategorizable information. For example, the player character account information may include numerous sub-categories of information including character ID, character balance, character interest rate, and interest payment schedule. Alternatively or additionally, the loan account information may include sub-categories of information including character ID, loan amount, payment(s), interest rate, and credit card number. [00247] Turning next to Fig. 23, system 240 according to another embodiment of the present invention is shown. System 240 may include a central server 242 in electronic communication with any number of suitable

programs including, for example and without limitation: a Currency Exchange

Program 244; a Virtual Item Payment Program 246; and a Currency Selection

Preferences Program 248.

[00248] System 210 may further comprise any number of suitable databases. Examples of suitable databases include, but are not limited to, a player database 250, a player character database 252, a currency exchange database 254, an item database 256, and a market database 258.

[00249] Player database 250 may include information about each player who accesses the game. This information may be provided to the game server by a player when the player registers to play the game, or at any other suitable time and using any suitable means. Examples of player information include, but are not limited to: player character ID, character personal information, character real currency account information, and player character(s).

[00250] Player character database 252 may include information about each player character that participates, or is able to participate, in a game.

Accordingly, it will be understood that according to some types of games, a single player may create and control more than one player character.

Examples of information the player character database may maintain include, but are not limited to: character name, virtual cash currency preferences, real cash currency preferences, virtual cash account, account number, account balance, and virtual item ID. Of course it will be understood that for many of these information categories, a given player character may have multiple entries. For example, a given player character may have any number of attributes which could be tracked and maintained by the player character database.

[00251] Currency exchange database 254 may include information such as currency types and exchange rates.

[00252] Item database 256 may include Information about the various items that are available for use in the game. Examples of Information the item database may maintain includes item identification, item descriptors, and item attributes.

[00253] Market database 258 includes Information about the items that have been offered for sale/barter/etc, in the game. Examples of information

the market database may maintain includes item ID, item value, quantity available, and the items for which exchange is available. [00254] The following paragraphs describe various methods and steps therein according to the present disclosure: [00255J Establishing a Contract n. Loan i. Player Character to Game Server

1. Receive virtual contract initiation request including virtual cash loan amount from player character

2. Determine contract obligations and conditions of loan

3. Output obligation and conditions of loan

4. Receive acceptance of obligations and conditions

5. Retrieve or receive player credit card number associated with player character

6. Activate and store virtual loan contract along with loan amount, obligations, conditions, limits (if any) and player credit card

7. Issue virtual cash loan amount to player character ii. Player Character or entity to Player Character or Entity

1. Receive, store, and output and post virtual cash loan request from a first player character

2. Receive, store, and output response to virtual cash loan request including obligations and conditions from a second player character

3. Receive acceptance of obligations and conditions from first player character

4. Retrieve or receive credit card associated with first player character

5. Create, activate and store a virtual contract including obligations, conditions, and credit card

6. Receive virtual cash loan amount from second player character

7. Issue virtual cash loan amount to first player character o. Dividend

i. Player Character (or Entity) to Player Character (or Entity)

1. Receive a request to sell shares of a virtual company including a guaranteed virtual cash dividend per time period per share amount from a first player character

2. Retrieve or receive a credit card associated with first player character

3. Store request to sell shares including credit card and dividend information.

4. Output request to sell shares

5. Receive a request to buy shares from a second player character

6. Receive virtual cash payment for shares from a second player character

7. Distribute virtual cash payment for shares to first player character

8. Receive shares for virtual cash payment

9. Distribute shares to second player character p. Finance Option i. Player Character to Game Server

1. Receive request to purchase an in game item with virtual cash from a player character

2. Generate and output one or more virtual offers to finance the item purchase that includes a number of virtual cash payments at a specified number of time period intervals

3. Receive an acceptance of a finance offer from the player character

4. Retrieve or Receive a credit card associated with the player character

5. Establish and store financing contract including the virtual cash payment amount, the number of payments, the dates for each payment, and the credit card information.

6. Output virtual item to player character.

ii. Player Character to Player Character

1. Receive and post a request from a first player character to sell a virtual item, including a virtual purchase price and one or more finance option packages that include a finance payment price, a total number of finance payments, and a schedule of when the payments are due.

2. Receive virtual item from virtual account of first player character

3. Receive a request to purchase the virtual item from a second player character including an agreement to purchase the item with a finance option package.

4. Retrieve or Receive the credit card number associated with the second player character

5. Store request to purchase the virtual item with the credit card

6. Output virtual item to second player character account q. Item Creation i. Player Character to Player Character

1. Receive, Store and Output a request to assemble an in-game item, including at least one of (i) a virtual cash amount, (ii) a blueprint, (iii) in game natural resources and game items necessary to assemble the item, (iv) a date / time of expected delivery, and (v) the agreed upon or expected quality of the item or its constituent components.

2. Receive an acceptance of the offer by a second player character who has the appropriate skills necessary to assemble the item, including the price and a time when the item will be complete.

3. Receive or retrieve a credit card associated with the second player character.

4. Store credit card with accepted offer to assemble an in-game item.

r. Futures Contracts i. Player Character to Game Server

1. Receive a virtual offer to buy or sell an in game item or in game resource at a specified later date and price, including an offer amount from a player character

2. Accept offer

3. Retrieve or receive credit card associated with player character

4. Store credit card with offer

5. Receive offer amount from player character ii. Player Character to Player Character

1. Receive a virtual offer to buy or sell an in game item or in game resource at a specified later date and price, including an offer amount from a first player character

2. Receive an acceptance of the virtual offer from a second player character

3. Receive or retrieve a credit card associated with the first player

4. Create, activate, and store a virtual offer contract including the credit card number of the first player character

5. Receive virtual offer amount from second player character account

6. Transmit virtual offer amount to first player character account (less transaction fee if applicable) s. Help with Solving a Mission i. Player Character to Player Character

1. Receive, store and output a virtual request for help in solving a virtual mission from a first player character including a mission, a date by which the mission must be complete, an amount to pay if the mission is

completed and a penalty for not completing the mission

2. Receive an acceptance of the virtual request from a second player character

3. Receive or retrieve a credit card for both player one and player two

4. Store credit cards with request

5. Make request active

6. Determine if request was fulfilled by specified date

7. If request was fulfilled charge virtual payment amount to first player character virtual account. a. If first player character virtual account cannot fulfill payment amount, determine real cash value for virtual payment amount and charge real cash value to credit card or insurance policy associated with first player character

8. If request was not fulfilled, retrieve virtual penalty amount and charge amount to virtual account of second player character a. If virtual account of second player cannot cover virtual penalty amount, determine real cash value of virtual penalty and charge real cash value to credit card or insurance policy associated with second player character t. Insurance Premium i. Player Character to Player Character

1. Receive, store and output a virtual contract to insure a particular virtual item from a first player character

2. Receive an offer to accept the contract, including at least one virtual insurance premium amount from a second player character

3. Receive an acceptance of the virtual insurance premium amount from the first player character

4. Retrieve or receive a credit card for both the first and second player character

5. Activate virtual insurance contract and store credit card numbers with contract

6. When virtual premium is due, charge premium amount to virtual account of the first player character a. If the virtual premium payment cannot be taken from the virtual account of the first player character, determine a real cash value for the virtual premium and charge the real cash value to the player character's credit card ii. Player Character to Game Server

1. Receive a request to insure a virtual item from a player character

2. Generate and output at least one virtual insurance premium amount including at least one date when the premium amount is due.

3. Receive acceptance of virtual insurance premium amount

4. Create virtual insurance contract

5. Retrieve or receive a credit card associated with player character

6. Store credit card with virtual insurance premium amount. u. Insurance Claim i. Player Character to Player Character

1. Receive a virtual claim on an virtual insurance contract from a first player character

2. Determine if virtual claim is valid

3. If claim is valid, determine a virtual claim value based on virtual insurance contract

4. Determine a second player character who issued the virtual insurance contract

5. Output request for virtual payment for virtual claim value to a second player character

6. If second player character does not pay the virtual payment, determine a real cash value for the virtual claim value

7. Charge the real cash value to the credit card associated with the second player character. v. Shipping i. Player Character to Player Character

1. Receive a virtual item to ship from a first player character including a present virtual location and a requested virtual location

2. Determine and output a virtual shipping amount, delivery date, and real cash penalty amount

3. Receive acceptance of shipping amount and delivery date from a second player character

4. Receive or retrieve a credit card associated with second player character

5. Create shipping contract with virtual item, shipping amount delivery date, penalty amount, and credit card

6. Determine if item was delivered on or before delivery date

7. If item was delivered, charge shipping amount to first player character account

8. If item was not delivered, retrieve penalty amount

9. Charge penalty amount to credit card ii. Player Character to Game Server

1. Receive a virtual item to ship from a player character including a present virtual location and a requested virtual location

2. Determine and output a virtual shipping offer, including a virtual shipping amount, delivery date, and real cash penalty amount

3. Receive acceptance of the virtual shipping offer

4. Receive or retrieve credit card associated with player character

5. Deliver item

6. Charge shipping amount to player character a. If player character cannot pay shipping amount, retrieve real cash penalty amount and charge amount to player credit card, w. Virtual Bank Deposit i. Player Character to Game Server (set up virtual bank)

1. Receive a request to set up a virtual bank from a player character including one or more credit cards with corresponding credit lines

2. Set up virtual bank with an allowed deposit limit equal to the corresponding credit lines

3. Receive an interest rate amount

4. Store interest rate amount with virtual bank ii. Player Character to Player Character (receive deposit)

1. Output a bank deposit offer from a first player character, including a maximum deposit amount and an interest rate

2. Receive a request to make a virtual cash deposit from a second player character that is equal or less than the maximum deposit amount

3. Determine if second player character already has an account with the virtual bank a. If not, set up virtual bank account for second player character and deposit virtual cash funds

Or b. If so, deposit virtual cash funds into existing virtual bank account associated with second player character

4. Reduce maximum allowed deposit amount by virtual cash deposit x. Taxes

i. Player character to game server or player character

1. Receive request from a player character to become a member of a virtual entity or use a virtual service

2. Generate and output a tax amount

3. Receive an acceptance of the tax amount from the player character

4. Retrieve or receive a credit card associated with the player character

5. Create a membership or permit including player character information and credit card number y. Adjudication i. Player character to player character

1. Receive and Store a determination of a virtual settlement amount to be paid by a first player character to a second player character including a virtual cash amount and a due date

2. Receive or retrieve a credit card associated with the first player character

3. Store credit card with determination z. Breaking rules or hacking the game i. Player character to game server (initial agreement)

1. Receive request to create an account from a player

2. Output terms and conditions including agreement to charge penalty fees to a credit card in the event of rule breaking or hacking

3. Receive and store acceptance of terms, player information, and player credit card information

[00256] Enforcing a Contract

I. Loan, Dividend, Finance Payment, Insurance Premium ii. Player Character to Game Server

1. Determine that a virtual obligation payment is due

2. Charge obligation payment to player character account

3. If player character account cannot cover obligation payment, determine a real cash value of obligation (including fees and/or penalties and fines)

4. Charge real cash value to player credit card iii. Player Character to Player Character

1. Receive a complaint that a first player character could not pay a second player character a virtual obligation payment

2. Determine if complaint is valid

3. If complaint is valid determine or retrieve a real cash value of obligation payment

4. Charge real cash value to credit card associated with first player character

5. Pay second player character the virtual obligation payment (in real or virtual cash) m. Item Creation iv. Player Character to Player Character

1. Receive a complaint that a first player character did not complete the creation of an item for a second player character.

2. Verify that complaint is valid

3. If complaint is valid, retrieve a real cash penalty value associated with the item creation contract

4. Retrieve a credit card associated with a first player character

5. Charge real cash penalty value to credit card

6. Credit real or virtual account of second player character with penalty value (less applicable fees) n. Futures Contracts v. Player Character to Game Server

1. Receive indication that player character could not fulfill futures contract

2. Retrieve or Generate a penalty amount

3. Charge penalty amount to virtual account of player character

4. If virtual account cannot cover penalty, retrieve player credit card

5. Determine a real cash value of the penalty amount

6. Charge amount to player credit card vi. Player Character to Player Character

1. Receive complaint from a first player character that a second player character could not fulfill a futures contract

2. Verify that complaint is accurate

3. Retrieve or generate a virtual penalty amount

4. Retrieve credit card of second player character

5. Charge second player character the virtual penalty amount

6. If second player character account cannot cover virtual penalty amount, generate a real cash value

7. Charge real cash value to credit card

8. Pay penalty amount (in real or virtual cash) to the first player character, less any applicable fees. o. Help with Solving a Mission vii. Player Character to Player Character

1. Receive a complaint that a first player character has not successfully helped a second player character complete a mission

2. Verify complaint

3. If complaint is accurate, retrieve virtual penalty

4. Charge first player character account penalty amount

5. If first player character account cannot cover penalty amount, determine real cash value of penalty amount

6. Retrieve credit card associated with first player character

7. Charge real cash value of penalty amount to credit card p. Insurance Claim viii. Player Character to Game Server

1. Receive a complaint that a first player character has not paid an insurance claim to a second player character

2. Validate complaint

3. If complaint is validated, determine real cash value of claim

4. Retrieve credit card associated with first player character

5. Charge real cash value of claim to credit card (plus applicable fees)

6. Pay real or virtual cash value of claim to second player character (less applicable fees) q. Shipping Item ix. Player Character to Player Character

1. Receive complaint that a first player character did not deliver an item for a second player character

2. Validate complaint

3. If complaint is validated, determine a real cash penalty amount

4. Retrieve credit card of first player character

5. Charge penalty amount to credit card (plus applicable fees)

6. Determine a virtual cash value for the real cash penalty amount

7. Pay virtual cash value to account of second player character (less applicable fees) x. Player Character to Game Server

1. Deliver a virtual item to a specified virtual location

2. Charge shipping amount to player character account

3. If player character account cannot pay shipping amount, retrieve credit card associated with player character account

4. Determine a real cash penalty amount

5. Charge penalty amount to player credit card r. Virtual Bank Deposit xi. Player Character to Player Character

1. Receive a request from a first player character to withdraw funds from a virtual bank account owned by a second player character

2. Determine if the virtual bank has enough virtual cash to cover the withdrawal amount a. If yes, transfer funds from virtual bank account to first player character account b. If no, determine a real cash value for the withdrawal amount i. retrieve credit card associated with virtual bank ii. charge credit card real cash value of withdrawal amount (plus any fees) iii. transfer funds from virtual bank account to first player character account s. Virtual Bank Interest xii. Player Character to Player Character

1. Determine that interest is due on a balance deposited by a player character in a virtual bank account.

2. Calculate virtual cash interest payment

3. Determine if virtual bank has enough virtual cash on hand to cover interest payment a. If so, make interest payment b. If not, determine a real cash value of interest payment

i. Retrieve credit card associated with virtual bank ii. Charge credit card real cash value iii. Convert real cash value into virtual cash and deposit into virtual bank iv. Transfer virtual cash from virtual bank to player character bank account, t. Taxes xiii. Player character to game server

1. Receive or Generate indication that a virtual tax is due

2. Determine virtual tax amount

3. Attempt to charge tax amount to virtual cash account of player character

4. If virtual cash account can cover tax amount, remove tax amount from account

5. If virtual cash account cannot cover tax amount: a. Determine a real cash value of the virtual tax amount b. Retrieve credit card associated with player character account c. Charge real cash value to player character account (plus applicable fee) d. Convert real cash value to virtual cash amount and deposit in virtual cash account of player e. Remove virtual cash amount from player character virtual cash account xiv. Player character to player character

1. Receive or Generate indication that a virtual tax is due from a first player character to an entity controlled by one or more other player characters

2. Determine virtual tax amount

3. Attempt to charge tax amount to virtual cash account of player character a. If virtual cash account can cover tax amount, transfer virtual cash amount from first player character virtual cash account to virtual cash account of entity controlled by one or more other player characters

4. If virtual cash account cannot cover tax amount: a. Determine a real cash value of the virtual tax amount b. Retrieve credit card associated with first player character account c. Charge real cash value to first player character account (plus applicable fee) d. Convert real cash value to virtual cash amount and deposit in virtual cash account of first player e. transfer virtual cash amount from first player character virtual cash account to account of entity controlled by one or more other player characters u. Adjudication xv. Player character to player character

1. Retrieve determination on due date

2. Attempt to charge virtual settlement amount to first player character virtual cash account

3. If first player character virtual cash account can cover settlement amount, transmit amount (less applicable fees) to second player character virtual cash account

4. If first player character virtual cash account cannot cover settlement amount: a. Determine a real cash value for the virtual settlement amount

b. Charge real cash value to credit card associated with first player character c. Convert real cash to virtual cash d. Transfer virtual cash (less applicable fees) to the virtual cash account of the second player character v. Breaking rules or hacking the game xvi. Player character to game server (infraction occurrence)

1. Determine that a player character has committed an infraction

2. Determine a penalty amount

3. Retrieve credit card associated with player character

4. Charge credit card penalty amount [00257] Locking player character accounts and liquidating assets a. Determine that a virtual obligation cannot be paid with a virtual account associated with a player character b. Determine a real cash value for the virtual obligation c. Retrieve credit card associated with player character d. Attempt to charge real cash value of virtual obligation to credit card e. If attempt fails, lock virtual assets of player character account, f. Post and sell virtual assets on appropriate in game marketplace or exchange g. Retrieve virtual creditor list h. Determine % of player character asset value due to each virtual creditor i. Transmit appropriate % of asset value to each virtual creditor [00258J Generating warning message if virtual obligation cannot be met a. Determine that a virtual obligation cannot be paid with a virtual account associated with a player character b. Determine a real cash value for the virtual obligation c. Retrieve credit card associated with player character

d. Attempt to charge real cash value of virtual obligation to credit card e. If attempt fails, output warning message to player character [00259] Disabling selling virtual assets if Player Character has virtual obligations a. Determine a total virtual obligation amount for a player character b. Set a minimum virtual asset limit for the player account based on the total virtual obligation amount c. Disallow selling of any player character assets below virtual asset minimum.

[00260] Periodic check of credit card validity a. Determine that a player character account has a virtual obligation secured by a credit card b. Retrieve credit card number c. Verify that credit card is valid and/or has enough remaining credit to cover virtual obligation. d. If credit card is not valid and/or does not have enough remaining credit to cover a virtual obligation, lock assets of player character account equal to total virtual obligation amount.

[00261] Credit card upselling during contract initiation a. Receive request to initiate a virtual contract from a player character b. Output offer to register for a credit card to secure the transaction c. Receive acceptance of offer, including player billing information d. Submit credit card application for approval e. If credit card application is accepted, bind virtual contract with new credit card. f. If credit card application is denied, output request to player character to use a different credit card to bind virtual contract i. Receive alternate credit card from player character ii. Use alternate credit card to bind contract [00262] Credit card upselling during player set up a. Receive request to create new player account

b. Output offer to register for a credit card, including an upfront virtual benefit if offer is accepted c. Receive acceptance of offer, including player billing information d. Submit credit card application for approval e. If credit card application is accepted, issue credit card, set up player account with credit card, and store virtual benefit with player account f. If credit card application is denied, output request for alternate credit card i. Receive alternate credit card ii. Set up player account with alternate credit card [00263] Providing a choice between virtual cash or credit card charge a. Determine that a virtual obligation of a player character is due b. Determine a virtual and real cash value of the obligation c. Output notification that virtual offer is due, including choice to pay for virtual obligation with real or virtual cash i. Receive indication that virtual obligation will be paid with real cash ii. Charge reai cash value to credit card associated with player character account iii. Or iv. Receive indication that virtual obligation will be paid with virtual cash v. Charge virtual cash value to player character virtual account [00264] Real cash charge to credit card for virtual loan payment or rental a. Determine that a virtual obligation of a player character is due b. Determine real cash value of virtual obligation c. Retrieve credit card associated with player character d. Charge real cash value of virtual obligation to credit card. [00265] Selecting multiple Currency options a. Receive a request to set up currency options from a player character b. Retrieve available virtual and real cash options

c. Output options d. Receive option selection e. Store option selection with player character account [00266] Paying for a virtual item a. Receive a request for the price of a virtual item in a game environment b. Retrieve or receive real cash and virtual currency options for the player character i. Generate two or more prices for the item based on the currency options ii. Output prices iii. Receive a price selection c. if price selection is a virtual currency, debit price amount from player character virtual currency account d. if price selection is a real currency i. retrieve the credit card associated with the player character account ii. charge the price to the credit card b. Put virtual item in inventory of player character account [00267] Creating an Exchange Offer a. Receive a first virtual item to be sold or exchanged from a first player character b. Receive list of other virtual items that can be exchanged for the first virtual item c. Store Exchange Offer [00268] Fulfilling an Exchange Offer a. Receive a request to purchase a first virtual item from a first player character b. Determine that first virtual item has an exchange offer from a second player character c. Determine that the first player character has a second virtual item that can be exchanged for the first virtual item d. Output exchange offer to first player character

e. If offer is accepted, transfer second virtual item to second player character and first virtual item to first player character. [00269] According to ons embodiment methods and systems are disclosed that allow player characters in a massive multi player online video game to create relationships with each other. Examples of the types of relationships that can be created are:

1. Marriage

2. Parent/Child

3. Slave/Master

4. Affair

5. Enchanter/Enchanted

6. Boss/Employee

7. Gods/Worshipers

8. Government Officials

9. Sports Teams/Coaches

10. Guilds

11. General/Army

[00270] According to one embodiment, when a player character reaches a certain level in a video game, he is allowed the opportunity to have one or more of the above relationships with another player character. These relationships can be defined and/or limited by the player character's race and class in the game. Some of these relationships can allow the player character to develop additional relationships with subsequent player characters. These additional relationships may require the player character to reach another level in the game. Some levels of the game may be unobtainable by the player character unless they have developed certain relationships with other characters. Certain of these relationships may prevent or preclude certain other relationships with other player characters.

[00271] Relationships between player characters can provide additional benefits to one or more of the player characters in the relationship. Non- limiting examples of these benefits include:

1. A player character can receive some or all of the character attributes generated by another player character if they have a relationship (master/slave)

2. Player characters can have additional relationships with other player characters if they have a relationship with each other (marriage/children)

3. Attributes of a player character can be enhanced, modified, or transferred if they have a relationship with another character (children inherit attributes of parents)

4. The race or class of the player character can be altered as long as they have a relationship with another character (undead possess living player characters)

5. A player character can shorten, lengthen, or restart the life of another player character if they have a relationship (doctor/patient)

6. A player character cannot reach subsequent levels of a game or acquire certain character attributes unless they have one or more relationships with other characters, (mayor of city must have a wife and child)

[00272] Alternatively or additionally, relationships between characters can be limited based on character attributes including:

1. The race of the character

2. The class of the character

3. The number of player characters playing the game

4. The level of a player character

5. Whether or not a player character has a certain attribute or collection of attributes

6. Whether or not a player character has successfully completed a game parameter

7. How many hours the player plays with the player character in a given time period

8. According to another embodiment, relationships between characters can be lost according to certain game parameters. Examples of the types of game parameters according to which a relationship might be lost include, but are not limited to:

9. One of the characters in the relationship has the authority to sever the relationship and does so.

10. One of the characters in the relationship cancels his account with the game server

11. One of the characters in the relationship does not log enough play time in a given time period

12. Both of the characters mutually request and agree to sever the relationship

13. Other characters establish a relationship with a character that severs their relationship with the first character

14. A certain time period of real time or game time has lapsed

15. One character pays or fails to pay or provide a certain amount or number of attributes to the other character, then their relationship may be severed.

[00273] According to one embodiment, relationships may be established in a variety of ways. Examples of ways in which relationships between characters can be established include, but are not limited to:

1. By an in game negotiated virtual contract between the two player characters

2. Randomly or under proscribed rules controlled by the game server or within a peer-to-peer network

3. By a structure of rules defined by the game players, game server, or within a peer-to-peer network or a combination of these

4. When a new player character is created in the game, relationships are automatically established by the game server or within a peer- to-peer network between that character and the existing character's within the game.

[00274] According to one embodiment, each type of relationship may be defined and/or governed by various rules and/or limitations. Below are listed examples of relationships and governing rules and limitations for those relationships. It will be understood, however, that such relationships and limitations are provided only as examples of the types of relationships and limitations that could be used in a game and that none of the examples below should be construed as requirements for the embodiment. It will be further understood that rules and limitations may be added or deleted, individually or in groups, and that such rules and limitations may be static or fluid.

[00275] Marriage-Two players in a game reach a certain level of the game and are qualified to be married. The characters log in to a special screen of the game that displays other characters that are available to be married. Characters can display conditions for the marriage i.e. they need a certain dowry, prenuptials or will only marry a character of a certain class or level, or with sufficient resources, income or skills to contribute to the marriage. A player character can accept a marriage proposal or submit a counter offer. When both players agree to the terms of the marriage, then the system sets a flag in both of the character accounts indicating their newly formed relationship.

[00276] Different types of characters could have different marriage arrangements. For instance Taurens could be married to more than one other character, while Elves could only be married to one other character. Humans could get married at level 10 while elves could be married at level 15. Some races could have multiple marriages with fixed time limits. [00277] Parent/Child-Once two players have been married; they can have children once one or both of them have reached a certain level of the game. Once one or both characters have reached a proscribed level of the game, their character accounts are flagged as being eligible to have children. A new player character formed by a new player can only come into the game when two other players are eligible to have a child and agree to have a child. A new player can specify what gender, race and class he wants his player character (child) to bθ. The system can display what gender, races and classes need or want more children by displaying the family trees of player characters already in the game that are married and that desire children. Parents can only have children within a certain subset of classes. For instance a rogue and a wizard can only have warriors and paladins as children, etc. Additional criteria can be set up by the new player or the parents to further establish the relationship between them. For instance, parents can set up a contract with the child so that they take a certain percentage of his experience or game attributes, but agree to leave all of their wealth to the child in their will when they die. New characters can set parameters for becoming a child, for instance, the new player child may agree to give his parent(s) a certain percentage of his future experience points, in exchange for

certain attributes or other tangible or intangible property when his parent(s) acquire them. Once the parents and the child have agreed to a contract, the new player character is born into the game and is added to the family tree of the parents. The new child may then begin to play the game and strive to gain wealth and attributes, etc.

[00278] New player characters can only be added to the game environment by being offspring of other player characters. New players can elect to give a greater amount of their experience or game attributes to parents who are in a good family or who otherwise have desirable traits, attributes, wealth, etc. According to this example, so called "bad families" will have a cheaper "barrier to entry" for new players than "good families." A player can set up a profile of the type of character they want. When a married couple in the game is able to have a child, the new player character requests are analyzed and new children are created according to new player preferences. A new player can choose to have his player inserted into different ages based on different servers.

[00279] Some characters may be able to spawn children without marriages. For example, some races may not require the union of two characters in order for a parent to have a child. In these cases, children entering the game may suffer from deficits in income, attributes, or other characteristics. These deficits may plague the player throughout his life or only during childhood. An advantage of becoming a child out of wedlock is that there is no or little barrier to entry.

[00280] Slave/Master-A first player character may be captured by a second player character in the game. The first player character is made a slave to the second player character and some or all of his experience and attributes are given to his master until he is freed. A slave can be freed if a member of his family or the slave if a ransom is paid. The master can put out a ransom note, or he can keep it a secret that he has captured the first player character as a slave. Family members of the slave or the slave himself can log in to a special screen in the game to view the conditions of the ransom to free the slave/himself. If the family members or the slave agree to the conditions of the ransom, they can free the slave/himself. They can also free the slave by recapturing him in the game. All the slaves of a given race may

be freed based upon the outcome of a war. If a General and his Army defeats another General's Army, the victorious General may choose to free all the slaves of the other race through an "emancipation proclamation." Slaves freed in this fashion will have all that was taken from them, plus optional penalties that are established by the Game Server or within a peer-to-peer network or as otherwise agreed upon by the players. Alternatively, Generals may agree to conditions of surrender, which may determine the disposition of any slaves or other spoils of war. In such case, slaves may be freed but they may receive only a portion or none of their previously lost wealth or other attributes.

[00281] Slaves may be subject to various penalties or governed by additional game rules while they are being held in slavery. Examples of the types of penalties or additional game rules to which a slave might be subjected include, but are not limited to:

1. Slaves can play in the game in a limited capacity until they are free.

2. Slaves can be cut off from communication with their family.

3. Slaves can commit suicide to start over in the game. (This could result in bad karma for the player character resulting in a low reentry status.)

4. Slaves can create their own contracts with other player characters who can free them from being slaves.

5. Slaves can bargain with their masters to free them for a proscribed initial or future, i.e., to be paid price.

6. A slave can also be sold by its master to another master by posting the slave for sale on a special marketplace.

[00282] Affair-ln some instances, a married couple may not be able to produce offspring that compliment their team fighting abilities. For instance, a family may need more healers to have a well rounded fighting force, but none of the parents can have healers as children based on their classes. In this instance, a player character, once he reaches a certain level, can have an affair with a family member of another family so that they can have children of a specific class that they could not otherwise have. Children generated in this manner are members of both families. The stronger family has the right to absorb the bastard player into their family first. The concubine or weaker

40346

134 player character can negotiate a contract with the stronger player character in order to provide a bastard child to his family. In this manner, a family lacking in a certain class of character can go outside the family to generate those class types in their family, but must pay for the privilege by providing game attributes to the non family member who agrees to have the affair. [00283] Incest. Absent all other options to bear children, close family members may have children. In such cases, the offspring shall be created in a manner similar to all other child bearing methods, except that, there shall be a greater probability of the offspring being defective in one or more ways. Such defects might include an inability to obtain certain attributes or use certain objects, weapons or tools. Another defect type might be a general constraint on the speed with which a child achieves various objectives, levels, karma, or other attributes. The degree to which these defects manifest themselves in such offspring may be determined randomly or predetermined by a set of rules enforced by the server or peer-to-peer network, [00284] Enchanter/Enchanted-Undead players can build up their army/family by enchanting other player characters. When an undead character reaches a certain level, they are eligible to enchant a "living" player character and cause them to be undead. These newly undead players than are removed from their current family tree and added to the undead family tree. To become living again, an undead player would have to be unenchanted by a device or spell provided by his family or by paying another Enchanter to provide the spell for a fee. Alternatively, once a player character has become undead, their family can only kill them and allow them to be reentered into their family further down the family tree via reincarnation. [00285] If an undead character is killed, then the undead character that created him can be allowed to make another character undead. i.e. an undead character who has earned a credit to enchant a living character can reuse it if that living character that has become undead is killed. [00286] Gods/Worshipers-Some characters, i.e. the first characters that sign on to a server, can be made Gods of their races. These gods can have some control of rules governing the entire game environment and can also bless or curse characters. Player characters can become blessed by offering

W

135 attributes to the gods. They can nullify a curse by offering attributes to a god. Gods may be player characters or, in certain game versions, NPCs. [00287] The goals of Gods are that their race rules the world. They can add extra incentives to parent/child contracts so that new player characters join their race over other alternative races.

[00288] Gods can battle one another and their strength is based on the strength of the families in their races.

[00289] Only a certain x number of characters can be gods in a given game environment.

[00290] Boss/Employee-in a mafia type game, new player characters can be introduced into a game as employees of a boss. Once player characters reach certain levels or acquire certain attributes in a game environment, they are eligible to take on new players as employees. Employees have to give a certain amount of the experience or game attributes they acquire to their boss in exchange for the position and/or protection. If either party fails to fulfill the terms of the contract, the contract can be nullified and his boss no longer employs the employee. The contract may include terms that control contract dissolution.

[00291] In a fantasy game such as World of Warcraft, player characters can be hired as soldiers to other player characters and fight for their army under an agreed upon contract. Characters log in to a special screen in the game to view employment contracts of other player characters. [00292] Government Officials-Members of families who are strong qualify to be part of a race's government. Different races have different government structures. I.e. some governments require that all members of a race vote for someone to become a government official while others, the strongest players are automatically allowed into government positions. [00293] For example, the human race can have a republic government with votes for party members. The Tauren race can have a monarchy and determine government position based on which player is the strongest. [00294] Player's characters could also race to achieve certain levels in the game. The first person to reach a certain level in the game is allowed to be a government official over other characters in the game. A government official may be able to take an experience or attribute tax from other players.

Player characters may challenge current government officials in future elections, which may occur at prescribed times/dates or when a majority of players in a given race agree to hold new elections,

[00295] Divorces-two player characters that are married can go to a virtual or player character judge who can split up their attributes if they want a divorce. Alternatively, if the married couple entered into a prenuptial agreement, that agreement shall govern the split up of their attributes upon entering into a divorce.

[00296] Sports Teams/Coaches-ln a game that has teams or armies, a coach can recruit new player characters to be on his team based on how well his team is doing against other teams/armies. A coach can receive points for winning matches and, when a certain number of points have been obtained, he is entitled to recruit new player characters to be on his team/army. In this embodiment, player characters can be traded from one team to the next. [00297] Examples of assets or value that might be used to trade player characters include, but are not limited to:

1. Other player characters

2. Game Points

3. Game Credits

4. Attributes

[00298] According to this embodiment, there may be a virtual bench from which coaches can recruit if they are having a successful season. Alternatively, player characters could only be added to a team If other player characters could no longer play on a team due to injury or death. [00299] Alternatively or additionally, as an option to help improve the overall competitiveness of a given team, the Game Server or peer-to-peer network may randomly, or based upon preset conditions, grant a coach the right to obtain one or more additional players with specific skill sets. As an example, if one team were to become so strong that they consistently dominate all other teams, the Game Server or peer-to-peer network may grant one or more of the underperforming teams the right to add sufficient additional players with appropriate skills and experience so as to make them better able to compete against the dominate team.

W

137

[00300] Guilds- A player character in charge of a guild cannot add other player characters unless either he or his guild have obtained a certain level in the game, completed certain game parameters, or acquired enough game attributes to qualify to add characters to the guild. New player characters coming into the guild can do so with a contract that can be negotiated before they join the game environment. Players in a guild can renegotiate contracts with their guild, or can be recruited to other guilds who offer competitive contracts.

[00301] General/Soldier-A player character who is a general can recruit new player characters into his army when he successfully defeats another army in combat. New player characters entering the game environment can elect to join an army based on available slots and offers in contracts. A weaker army would have to give more to new recruits in order to have them join. A contract to join an army could include:

1. A rank or position in the army

2. A salary

3. A % of spoils obtained by the army

4. One or more attributes (swords, etc)

[00302] Alternatively, or additionally, to help ensure competitiveness among armies, the Game Server or peer-to-peer network may randomly or via proscribed rules, grant rights to underperforming teams to obtain new soldiers for free or for reduced fees.

[00303] According to yei another embodiment, the game rules may specify that a player character cannot enter the game environment unless a relationship is established between one or more player characters already in the game environment and himself. For example, the game rules may state that a player character has to enter the game as a child of two other player characters.

[00304] As a further embodiment, when two player characters are eligible to have offspring, the system can randomly insert twins a certain x number of times in the game. A twin may be another player character or an

NPC.

[00305] Accordingly, contracts between player characters may be formed in a wide variety of ways including, for example and without

limitations, by the game server, within a peer-to-peer network, or by player characters via a trade or exchange service.

[00306] According to one embodiment, a player character can view his family tree at any time during game play by logging in to a special family tree page.

[00307] According to another embodiment, a player character can be a god in the game and determine rules and settings that other player characters abide by. Accordingly, certain players, e.g. those with the oldest game accounts may be able to reach or achieve a god level that presides over other game players and manages player and game mechanics such as population growth. Thus, a god level player may, for example, have choices as to how new offspring are bom into the game.

[00308] According to another embodiment, certain attributes, classes, and special powers may only be available to player characters that have certain characteristics or attributes such as, for example and without limitations, players with a certain number of ancestors or who have been reincarnated a certain number of times.

[00309] Sexes and classes can be selected by any desired means, including, for example, by the character or randomly by the system.

[00310] According to one embodiment, characters may be generated as children based on genetically crossbreeding the parents. According to one method of this embodiment lists of player attributes for both parents are generated and random or average selections from both parents are compiled to form the child. Each attribute of the parent can be specified by the game server as dominant or recessive. The child created by the union receives one chromosome from each player character parent. Depending on which attributes are considered dominant and recessive, when the child is generated by the chromosomes of his parents, his attributes are determined. This embodiment also allows for mutations from one generation to the next.

Mutations randomly occur and provide new or enhanced attributes to the offspring of the children.

[00311] Certain toys or other in game or out of game attributes can only be available to characters and players in certain family trees or to those who

achieve certain levels, obtain certain attributes, or acquire required virtual objects, which may be exchanged for tangible goods and services.

[00312] According to one embodiment, player characters could only be allowed to be inserted in the game with particular characteristics, for example, as a particular race of the game.

[00313] Populations may be managed so that no race in a game environment dominates all other races or grows faster than other races. With this limitation enabled, even if player characters reach the required level in the game where they qualify to have a child, they may not be able to have a child if their race has a population substantially or unfairly greater than other races in the game. In this manner, the game server or peer-to-peer network can manage the number of player characters in each race, and even in each class of each race. Alternatively, player characters that are citizens of a particular city in a game may only have children when both (i) they qualify and (ii) the city is large/healthy enough to support additional player character populations.

[00314] According to anther embodiment, all, an average, or a portion of the attributes of parents can be passed on to their children. For example, a parent with an intelligence level of 12 can pass on 50% of his intelligence level to his child. As player characters age, attributes such as intelligence increase, so an older player character can pass on greater attribute levels than a younger player character.

[00315] According to another embodiment, in some ages and races, a player character can be too old to establish a relationship with another player character, even if his level allows it.

[00316] According to another embodiment, under certain game conditions, different races or classes of characters can have a child together, the offspring of which forms a new race. I.e. in the third era of a game, elves and humans can mate to form Halflings.

[00317] According to yet another embodiment, players could pay an extra fee for an account that allows their player characters to have certain relationships with other player characters.

[00318] According to another embodiment, the entire group of characters that have a relationship (i.e. family or army) may have to reach certain cumulative experience or game level in order to add new characters to

the group. Alternatively, a certain number of characters in the group may have to have a certain amount of experience or have obtained a certain level in the game before they, or other members of the group can have relationships with new or existing player characters.

[00319] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Environment Program

2. Billing Program

3. Character Relationship Program

4. Character Profile and Management Program

[00320] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database including, for example: i. Player GUID ii. Player Billing Info iii. Player Characters 1 -N iv. Account Type

2. Player Character Database including, for example: i. Player GUID ii. Character GUlD iii. Character Attributes 1 -n iv. Character Skills 1 - n with Current Level 1 -n v. Character Relationship(s) 1 -n (tree) vi. Relationship Type(s) 1-n

3. Relationship Type Database including, for example: i. Relationship Type ID ii. Relationship Type Name iii. Relationship Type Conditions / Restrictions 1-n

4. Relationship Contract Database including, for example: i. Relationship Contract ID ii. Relationship Character 1-n (tree)

iii. Relationship Conditions 1-n

5. Player Character Family Tree Database including, for example: i. Player Character ID ii. Player Character Relationship 1-n (tree)

[00321] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00322] A method to determine eligibility to form a relationship comprising: retrieving Player Character attributes 1-n, determining if attributes qualify for a relationship, and If attributes qualify for a relationship, flagging the character account as eligible for a relationship; and outputting the relationship availability to the player character.

[00323] A method to create a contract to establish relationship comprising: retrieving a request to form a relationship contract, outputting the relationship contract parameters, receiving relationship contract conditions; and creating new relationship contract record. [00324] A method to form a relationship comprising: retrieving a request to view relationship contracts, determining relationship contracts availability based on player character account and relationship contract conditions, outputting available relationship contracts, receiving an indication of acceptance of a relationship contract or a counter offer, creating a relationship based on agreed upon contract conditions; and updating the relationship contract record.

[00325] A method for a character to sever a relationship comprising: receiving a request to sever a relationship contract,

determine if the request is permitted based upon relationship contract conditions, and if the request is permitted, severing the relationship, and if the request is not permitted, outputting additional conditions that must be met in order for relationship to be severed; and updating the relationship contract record.

[00326] A method for a server to sever a relationship comprising: retrieving a relationship contract, determine if the contract is eligible to be severed, outputting the offer to sever contract to player characters, and if offer is accepted, severing the contract and updating relationship contract record.

[00327] A method for creating a child character based on attributes of parent characters comprising: determining that a child relationship contract is available for two player characters, receiving an indication that a player character desires to be a child of two player characters, generating a genetic profile of the child player character based in part on the genetic profile of the parent player characters, and creating a child player character with genetic profile.

[00328] A method to create a new player character related to existing player characters comprises: determining that a child relationship is available for one or more player characters, receiving (or generating) child relationship contract conditions, creating a child relationship contract, receiving a new player character request, outputting available child relationship contracts, receiving an acceptance of the child relationship contract, and

creating a new player character that is a child of one or more existing player characters.

[00329] A method to allow a player character to receive game attributes for completing a game parameter only if relationship with other player character exists comprising: receiving an indication that a game parameter has been completed by a player character, determining if the player character has a relationship with another player character, and if a relationship exists, releasing available game attributes for successful completion of game parameter.

[00330] A method to allow player character to attempt to complete a game parameter only if relationship with other player character exists comprising: receiving a request to attempt to complete a game parameter, determining if the player character has a relationship with another player character, outputting a "game parameter requires relationship message" if character does not have a relationship with another player character; and initiating game parameter if player character has a relationship with another player character.

[00331] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00332] According to yet another embodiment, the present disclosure provides methods and systems to allow for karma points, death and reincarnation of player characters in a video game, such as, for example, a massive multϊplayer online video game.

[00333] According to one embodiment, a fixed time limit is placed on the amount of virtual or actual time a player character can exist in a game environment. During their lifespan, player characters can acquire "Karma"

points based on their activity in the game. A player's life span can be set to expire within a range of ages that may be based on factors including, but not limited to, the player character's race, the character's class, a random number, and/or, the player's karma points from a previous life. [00334] According to one embodiment, the player character can extend or shorten his life by, for example and without limitations, getting killed a certain x times before they die, getting killed a certain x times by a certain method before they die, using game attributes, such as potions and armor (i.e. using the picture of Dorian Gray), purchasing or stealing life credits from another player character (i.e. buying medicine from a doctor or drinking the blood from slaves), earning karma points, and/or completing game parameters (i.e. finding the fountain of youth).

[00335] According to another embodiment, at the end of hfs fiTe, a player character can establish a will that allows other player characters to receive the game attributes he has acquired over his lifespan. The will may, but is not necessarily, limited to leaving game attributes to the player character's relatives. A will can be created, for example, by the player character, by the heirs of the player character, by the game server based on rules, or randomly. [00336] As yet another alternative or in addition to the previously described division of assets, the Game Server or Peer-to-peer network may randomly or predictably decide to distribute a portion or all of an estate to a player's race, and/or allocate a portion of the estate to "taxes" in which case the taxed portion of the estate is forever lost to the deceased's progeny. [00337] According to another embodiment, over the course of a lifespan in the game, a player character earns positive or negative karma points that are used when the player character is reinserted into the game after his death. Positive Karma points can be earned, for example and with limitation, by: completing game parameters, killing other player characters, assisting other player characters to obtain attributes or complete game parameters, and/or having relationships with other player characters, including assisting other characters. Negative Karma points can be gained, for example and without limiations, by: failing to fulfill contracts, killing one's own offspring, having a spell cast against the player, being killed, and/or havfng affairs or children out of wedlock.

[00338] According to another embodiment, when a player dies, the character may become a ghost. A ghost may play in the game environment, but may have limited character attributes and/or properties. These limited properties might include:

1. The ability to chat with other player characters or provide hints

2. The ability to curse items, player characters, or places in the game

3. The ability to inhibit or otherwise influence the movement of certain player characters

4. While a character is in ghost status, he can earn positive or negative karma points by helping or hurting other player characters.

5. The ability to possess other player characters-iπ this embodiment, when a player character becomes a ghost he may be able to insert his will into the body of another player character. This may be a way to create undead characters in the game. The ability to possess people may be limited to player characters of a certain rank, race, class, or other measurable attribute of the game. For instance, a player character with a great number of negative Karma points may be able to indefinitely possess another player character. Alternatively, a player character that has become a ghost may only be able to possess another player character if they have a high number of negative karma points, or some other acquired attribute of the game, but then only for a limited amount of time proportionate with the number of negative karma points they have acquired.

[00339] Alternatively, a player character may only possess another player character when the first player character has become a ghost and the second player character has become enchanted by an undead player in the game.

[00340] According to another embodiment, a player with a ghost character can develop a new player contract that allows him to be reinserted in to the game as a child of one or more of the members of his family. Once two player characters are able to have children, the player character can be

evil. I.e. a new player character established by a player whose previous player character had bad karma could only be in the ore, Tauren, or undead race.

[00352] Alternatively or additionally, only certain classes may be available to a new player character based on his karma points. For instance, a new player character with no karma points could only be inserted into the game as a beggar or slave. Once he has earned karma points with that player character, and that player character dies, the new character of the player can have more class choices available to him. i.e. the new player character could be a warrior, slave, beggar, or paladin because of the karma points he earned in a previous life in the game.

[00353] According to one embodiment, players could pay an extra fee to the server or to other player characters for their characters to be able to earn karma points in a game.

[00354] According to another embodiment, being reincarnated in a game allows the player character to enter at a higher level, or as a different class.

I.e., the number of times a player character has been reincarnated may effect the starting level and/or available class choices for that character. This may or may not be further regulated based upon the amount of positive or negative karma accumulated by the player character in previous lives.

[00355] According to another embodiment, a player character can assign attributes in his will to other player characters whether or not they have relationship contracts established.

[00356] According to another embodiment, a player character receiving a game attribute via an inheritance from another player character may have to fulfill certain conditions before he can acquire the attribute. For instance, the player character may have to reach a certain level, complete a certain game parameter, or acquire a certain game attribute or object in order for a game attribute that he has inherited to be released from escrow of the estate of the deceased player character.

[00357] According to another embodiment, rather than Karma being measured in points, it can be measured in game attributes or currency or any combination of these variables.

[00358] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of

removed from the game as a ghost and reinserted as a new player character that is the child of the other two player characters.

[00341] According to another embodiment, when a player character is reinserted in the game, his Karma points may be used to establish a variety of factors including, without limitation:

[00342] The character attributes he begins with in the game (e.g. a player character with good karma could start the game with a really good weapon).

[00343] His new player character lifespan (i.e. a player character with good karma could be given an extended lifespan).

[00344] What family he is allowed to be inserted in (e.g. a player with good karma could have the option to be reinserted as a child in a high ranking family in the game).

[00345] What other player characters are allowed to be his parents.

[00346] What race, class or other character type he is allowed to be in the game.

[00347] Whether or not he is allowed to be reinserted in the game.

[00348] His starting level in the game (i.e. a character with good Karma can start at level 10).

[00349] What level of karma he begins with (i.e., some portion of karma may be passed on to the reincarnated player).

[00350] How many or how quickly the player may create new offspring.

[00351] According to yet another embodiment, a player character that has no Karma that wants to play the game may be subject to certain restrictions or limitations. For example a player character with no Karma may be restricted to starting as a certain class of player character, e.g., a player with no karma needs to start as an Ore or Tauren and earn karma points by playing with a character that then dies. The karma points earned by the character could then allow the player to create a new character that is of a different class than the first, i.e. once the first character earned sufficient karma points, the second character developed by the player character could be in the human race rather than the Tauren race. Bad karma points could allow the player to insert a new character only in races that are classified as

the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. Character Insertion Program

3. Will Creation, Notification and Enforcement Program

4. Character Death Program

5. Character Reincarnation Program

[00359] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database including, for example, player GUlD, Player Billing Info, Player Account Type, and/or Character GUID 1-n

2. Character Database including, for example, Character GUiD, Character Relationships 1-n (tree), Character birth date, Character death date, Character will ID, Character Karma Points, and/or Character Attributes 1-n

3. inheritor Database including, for example, inheritor GUID, Relationships 1-n (tree), Will Database, Will GUiD, Character GUlD, Attributes 1-n, Attribute Inheritor assignment 1-n, and/or Will conditions 1-n.

4. Attribute Database including, for example, Attribute iD, and/or Character GUID,

5. Karma Database including, for example, Karma Attribute ID, Karma point requirement 1-n, and/or Character GUID 1-n.

[00360] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00361] A method wherein a character dies comprising:

Receiving an indication that character has reached lifespan time limit,

Outputting indication that character is deceased,

Updating character database,

Determining if player character qualifies to be a ghost, and

If character qualifies to be a ghost,

flag player character account as ghost and if player character does not qualify to be a ghost, cancel player character account.

[00362] A method where a character is reincarnated based on karma comprising:

Receiving an indication that player character is deceased; Retrieving player character karma points; Determining if player character qualifies for reincarnation; and If player character qualifies, retrieving reincarnation conditions Determining if player character or new relationship contract fulfills conditions; and if conditions are met:

Creating new player character from deceased player character;

Determining initial character attributes based on karma and reincarnation rules;

Endowing new player character with character attributes based on karma ;

Establishing new player character starting karma points; and

Updating new player character database

[00363] A method in which a character becomes ghost and possesses another character comprising:

Receiving an indication that character has deceased; Determining if player character qualifies to be a ghost; and If player character qualifies to be a ghost, flag player character account as ghost Receive indication that ghost desires to possess another player character Determine if conditions are satisfied to allow ghost to posses other player character; and if conditions are met;

Allow ghost to possess other player character; Notify possessed player; and update possessed player's database as being possessed.

[00364] A method to create a will in a game comprising:

Receiving a request to create a will;

Identifying player characters that are established as inheritors

Receiving and storing conditions of inheritance for each qualifying game attribute

Linking each qualifying attribute to one or more inheritors; and

Updating will database. [00365] A method to create a default will in a video game comprising:

Receiving an indication that character has deceased; determine if player character has established a will; and if player character has not established a will: creating a default will that equally divides the deceased's estate among his heirs; or, dividing the estate based upon a ratio that favors those heirs that are closest in relation to the deceased family tree; optionally taxing the estate; and

Updating Will Database [00366] A method to establish a Will comprising:

Receiving an indication that character has died

Determining if the character has qualifying game attributes that are not linked to an inheritor;

Outputting a list of attributes that are not linked to an inheritor

Receiving an inheritor for each qualifying game attribute.

Receiving conditions of inheritance for each qualifying game attribute; and

Placing items in escrow [00367] A method for receiving game attributes from a will comprising:

Placing inherited item in escrow

Outputting notice of game attribute in escrow to each inheritor including conditions

Receiving an indication that conditions are complete

Receive request to remove game attribute from escrow Determine if conditions have been fulfilled, and

Release game attribute to inheritor.

[00368] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00369] According to yet another embodiment, the present disclosure provides a method and system to allow for inheritance between player characters in a video game such as a MMPOV.

[00370] According to this embodiment, when a player character dies (see, e.g. above), he is able to have some or all of the attributes he acquires in the game be given to other player characters in the game. Before his death, the player character can establish a will that specifies which assets/attributes go to which other player characters.

[00371] At any time during game play, a player can assign his attributes to other player characters when he dies in the form of a virtual will. The conditions under which a player can assign attributes to other player characters may be subject to limitations. Non-limiting examples of the types of limitations that may exist include:

1. That the other player characters are in the same family as the player character

2. That the other player characters are in the same race as the player character

3. That the other player characters are in the same class as the player character

4. That every member of his family, based on position in the family tree, gets the same or relative percentage of the attributes available as other family characters.

5. That other player characters have the appropriate karma or other rating before they receive the attributes assigned to them in a will.

6. That other player characters do not have a lean or debt to a third player character, who can automatically receive the player character inheritance to offset the debt owed them. In this embodiment, the system can automatically use attributes to

offset debts, or a player character can use attributes he has inherited to offset debts without the system intervention. [00372] In an alternate embodiment, the system may determine a tax amount to charge to the player character account before the player character's attributes are given to his heirs. The system may determine a virtual equivalent cash value for each attribute that the player character owns that can also be assigned to another player character. The attributes may be assigned to player characters. When the first player character dies, the second player character may be notified that he is eligible to receive an attribute from the first player character. If the attribute is cash, the system may automatically remove the tax fee and distribute the cash to the player (assuming the inheritor meets all other inheritance criteria and there are no other offsets, taxes, or precedent liens or debts), if the attribute is an object, the system may determine a virtual cash value for the item and notify the player character who has inherited it that he must pay the tax portion of the cash value in order to collect and use the item. After settling all debts, liens or other encumbrances that take precedence over the player character's right to inherit the assets, the player character may elect either (i) to pay the tax due on the item or (it) sell the item and coHect the selling price less the tax percentage.

[00373] According to one embodiment, taxes can be assigned and collected by the system, or by a government that is comprised of and managed by player characters. The virtual money stored by the government of player characters can be used by them to improve shared attributes in the game environment or used to finance a war.

[00374] In another embodiment other player characters can contest a will and it can be distributed based on a group vote by a group of family members, a government official, a god, an individual family member, or other player character or group of player characters in the game. Such distribution determination may alternatively be governed by chance outcomes. [00375] According to another embodiment, players could pay an extra fee to the server so to help assure that their character can inherit attributes from their parents.

[00376] According to another embodiment , when a character is possessed, his game attributes could be distributed to his family based on his will, held by the game server, remain with the character or transfer over to his undead family.

[00377] In another embodiment, if no will is established, all attributes may be auctioned off and the attributes sent to the government of which the player character was a member.

[00378] In another embodiment, if no will is established, a default will may be created under which assets are divided among surviving family members. Assets may be distributed using any desired means. For example, assets may be divided using a percentage based upon closeness of the heir to the deceased's family tree. Distribution under a default will, may or may not adhere to the other distribution constraints outlined above.

[00379] In another embodiment, if no will is established, the assets of the deceased may be distributed by chance or lottery. In such case, any other player, regardless of class, status or other attributes, may inherit some or all of such assets.

[00380] In another embodiment, a potential heir may encumber their share of future, not yet distributed, attributes. This may be rn the form of a loan from a third party player.

[00381] In another embodiment, the character may assign certain attributes to himself once he has re-entered the game as the reincarnated child of his own offspring.

[00382] According to another embodiment, items that are sold that are also linked to an inheritor in a will be immediately removed from the will contract.

[00383] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. ^• Game Program

2. Will Creation, Notification and Enforcement Program

3. Attribute Distribution Program

4. Tax determination program

[00384] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database including, for example, i. Player GUID, ii. Player Billing Info iii. Player Account Type iv. Player Characters 1-n

2. Character Database including, for example, i. Character GUID ii. Character Attribute IDs iii. Character Will ID

3. Attribute Database including, for example, i. Attribute ID ii. Attribute Type iii. Attribute Descriptor iv. Attribute Value

4. Will Database including, for example, i. Inheritor GUID ii. inheritor Attribute 1-n iii. Attribute Condition 1-n

5. Tax Database including, for example, i. Global Tax Rate ii. Race Tax Rate iii. Family Tax Rate iv. Class Tax Rate v. Attribute Type Tax Rate vi. Character Tax Rate vii. Tax Rate rules 1-n viii. Tax Rate Conditions 1-n

[00385] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to:

[00386] A method of forming a will comprising:

Receive request to form a will from a player character Retrieve player character attributes Receive link of each attribute to one or more inheritors Save will [00387] A method to create a default will comprising:

Receive indication that character has deceased Determine if player character has established a will If player character has not established a will: create a default will that equally divides the deceased's estate among his heirs, or, alternatively, divide the estate based upon a ratio that favors those heirs that are closest in relation to the deceased family tree

Update Will Database

[00388] A method to distribute attributes to heirs comprising: Receive indication that a player character has died Generate list of inheritors (from a will or default will) Distribute player character attributes to inheritors based on player character and/or game server rules and conditions

Update player (i.e., heir) attribute database

[00389] A method of taxing will assets before distribution comprising: Receive game attributes flagged for inheritors Determine tax rules and conditions Determine taxes due based on rules and conditions Withhold taxes or place character attributes in escrow with tax payment conditions

[00390] A method to inform inheritors that tax fee is due comprising: Determine taxes due for a game attribute Retrieve inheritor of item Notify inheritor of the taxes due

[00391] A method to pay taxes and debts and retrieve item from escrow comprising:

Receive request to retrieve game attribute from escrow Receive tax payment for game item

Distribute remaining items to any third party owed by heir

Release remaining game attribute(s) to player character

Update player (i.e., heir) attribute database

[00392] A method to liquidate game assets to pay off/down debts or other encumbrances comprising:

Receive indication that player character has died

Determine debts

Determine values of game attributes of player character

Liquidate game attributes up to debt amount

Pay down/off debts of player character

Determine if additional game attributes remain

Distribute remaining attributes to inheritors based on will. [00393] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the incfuded steps nor should they be interpreted as necessarily excluding any additional steps. [00394] According to another embodiment, the present disclosure provides a Massive Multi Player Online Video Game that progresses in eras. According to this embodiment a game environment that progresses in discrete time frames, i.e., "ages" or "eras" is provided. At its inception, the game environment may begin with a certain structure that may include:

1. a virtual geography

2. a virtual map of the geography

3. a group of game parameters that can be completed by player characters

4. a maximum population of player characters

5. a list of available resources or game attributes

6. a max group of resources or game attributes

7. a group of available player races

8. a group of available player classes

9. a group of available player attributes

10. a maximum size of a player character family tree

11.The types of skills a player character can acquire and or develop 12. A group of available technologies

[00395] According to one embodiment, as the game progresses through time it may be altered in a number of ways, including without limitation, in the following ways:

1. The virtual geography may become larger or smaller

2. The map of the virtual geography may become larger, smaller or more or less defined

3. The group or number of game parameters may be changed, expanded, or reduced

4. The list or number of game resources and or attributes may be expanded, reduced, or altered

5. The maximum group or number of resources or game attributes may be expanded, reduced or altered

6. The list of available player races may be expanded, reduced or altered

7. a list of available player classes may be expanded, reduced or altered

8. a list of available player attributes may be expanded, reduced or altered

9. a maximum size of a player character family tree may be expanded, reduced or altered

10. The types of skills a player character can acquire and or develop may be expanded, reduced or altered

[00396] According to one embodiment, new alterations of the game environment can occur only when one or more events occur. Examples of the types of events that might allow alterations of the game environment to take place include, without limitation:

1. a certain amount of virtual or actual time elapses

2. one or more player characters complete a game parameter

3. the game environment reaches is max population setting

4. An available attribute or resource is discovered or depleted

5. a certain section of the game geography is discovered, explored, or developed

6. a certain number of relationships has been established or dissolved between player characters

7. a certain number of play cycles are completed

8. a war between races is won or lost

9. a certain number of players have entered or left the game [00397] According to one embodiment, player characters can build, find, and use time travel devices that allow them to move from the present state of the server to the past. Player characters can observe the past without altering the past. Time travel devices essentially serve as history books of a game environment.

[00398] Additionally or alternatively, by paying a fee or by acquiring a skill or through use of an acquired potion, players can travel back in time to replay a segment of the game to improve the outcome or to gain additional experience. Such replay episodes are restricted to solitary game play, such as completing a task, solving a puzzle, etc., i.e., replays that require multiple players are precluded. Players may improve their condition in the present through such time travel episodes.

[00399] According to one embodiment, different servers of the same game can be set or, optionally reset, to be on different eras of the game at the same time. A new player can elect to insert his character into any era of the game at any time.

[00400] According to one embodiment, if a certain attribute is not acquired by a player or group of players before an era of the game has elapsed, than that player or group of players can never obtain that attribute. There may be exceptions to this rule. For example, such as when a player or group of players travels back in time and successfully completes the task or acquires the attribute.

[00401] According to one embodiment, certain items and character mutations may only be available in certain epochs or eras of the game. [00402] According to one embodiment, a game that moves in Eras ends with an apocalypse.

[00403] According to one embodiment, an apocalypse may be triggered by the occurrence of one or more events. For example, an apocalypse may be triggered if one or more of the following occurs:

1. a certain number of a certain race, class, guild, or family exists in the game environment

2. a certain age is reached in the game environment

3. one or more player characters acquires a certain game attribute [00404] The Game Server starts an apocalypse or within a peer-to-peer network, this may be a random event or it may be initiated when the system determines that a game is stagnant or uninteresting.

[00405] According to one embodiment, an apocalypse allows one or more player characters of a player race, class, guild, or family to become a savior.

[00406] According to one embodiment, a savior can lead his army, which consists of other player characters of his race, class, guild, or family to total victory. Total victory may be defined as the domination of the game environment. When total victory is obtained, the game environment may be reset. The saviors may then become the founding members of the reset or new game environment.

[00407] According to one embodiment, a player character can become a savior by:

1. Acquiring a certain game attribute

2. Being reincarnated a certain number of times in the game

3. Being a certain x number in his family tree, guild, class, or race

4. Being sacrificed by his family, guild, class or race

[00408] According to one embodiment, each family, guild, class or race can sacrifice a player character so that player character can become eligible to become a savior.

[00409] According to another embodiment, a certain class, race, or family member must exist to perform the sacrifice ritual.

[00410] According to some embodiments, the sacrifice ritual can be:

1. Casting a spell on a player character

2. Killing a player character with a certain weapon

3. Applying a character attribute to a player character

4. Being randomly created by the server or network

5. Being endowed by a God with sufficient attributes or karma [00411] According to one embodiment, saviors can create special player characters as family members to wage the war of the apocalypse

[00412] According to one embodiment, the goal of the apocalypse era is to kill the savior and army of other race, class, guilds, or families first.

[00413] According to one embodiment, the last savior standing wins the game for his class, guild, race, or family.

[00414] According to one embodiment, when the age of the apocalypse occurs in the game environment, all player characters are notified.

[00415] According to one embodiment, progress and strengths of families, classes, races, or guilds; including whether or not that group of player characters includes a savior, can be displayed to all player characters in the game.

[00416] According to one embodiment, undead saviors can be treated as Satan and their minions as demons.

[00417] According to one embodiment, living saviors can be treated as

Christ and their minions are angels.

[00418] According to one embodiment, a player can pay an additional fee (real or imaginary) for his characters to have the ability to become saviors.

[00419] According to one embodiment, a player character may take part in a sacrificial ceremony in order to create a savior. Examples of sacrificial ceremonies include:

1. An ore priest tears the heart of the head of his family out of his chest and plants it into a clay statue. The statue becomes the savior

2. an undead wizard casts a spell on the head of his family, who is devoured by maggots, the maggots grow into flies that recombine into one or more saviors

3. A dwarf engineer plants a cyborg brain into the head of his family. The brain controls the body of the player character and he becomes the savior

4. A group of human druids burn the head of their family at the stake. The ashes are placed into an urn and the savior rises from the ashes.

5. The youngest or eldest family member or a virgin female family member is drawn and quartered on scared grounds and then the

body parts are cooked on a holy alter and subsequently devoured by the surviving family members.

[00420] According to one embodiment, the children of the human savior are born with wings and can fly.

[00421] According to one embodiment, certain classes can have a randomly placed super player characters created during each game era. Player characters that are super player characters have special attributes and skills (super scientist, artist, engineer, warrior, etc) essentially they are mutations that can discover a new innovation that can be traded with other families, races, or classes. Families that are more powerful have greater odds of creating super player characters.

[00422] According to one embodiment, families or guilds can discover technologies that can be traded with other families and guilds. Technologies are discovered when certain player characters reach certain levels of skill or acquire certain game attributes

[00423] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. Era Update Program

3. Savior Creation Program

4. Apocalypse Program

5. Reset Game Program

[00424] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database, including, for example, i. Player GUlD ii. Player Billing Info iii. Player Account Settings iv. Character GUIDs 1-n

2. Character Database including, for example, i. Character GUID

ii. Savior Qualifications 1-n iii. Savior Attributes 1 -n

3. Era Database including, for example, i. Era ID ii. Era Descriptor iii. Era Conditions 1-n iv. Era Time Start v. Era Time End vi. Era Populations 1-n vii. Era Classes 1-n viii. Era Races 1-n ix. Era Technologies 1-n x. Era Natural Resources 1 -n xi. Era Skills 1-n xi i. Era Rules 1-n xiii. Era limits 1-n xiv. Era territories 1-n xv. Available Game Parameters 1-n xvi. Available Game attributes 1 -n xvii. Family conditions 1-n

4. Historical Archive including, for example, i. Saved Game Result ID ii. Game area iii. Game time iv. Player characters involved v. Saved game result file

5. Sacrifice Rules Database including, for example, i. Sacrifice Rule ID ii. Sacrifice Rules 1-n iii. Probability of Sacrifice Success

[00425] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00426] A method for creating a new game environment comprising:

Receive request to create new game environment

Retrieve new era rules and conditions

Apply rules and conditions to game environment to create new game.

[00427] A method to alter a game environment when a new era occurs comprising:

Receive indication that era condition or rule has been fulfilled

Retrieve new era conditions and rules

Apply new era conditions to game environment

Create new era [00428] A method to facilitate time travel comprising:

Receive request to conduct time travel from a player character

Receive time travel conditions Determine if player character qualifies for time travel

If player character qualifies for time travel, retrieve saved game result based on time travel conditions

Output saved game result to player character [00429] A method to facilitate time travel game play comprising:

Complete Time Travel request

Temporarily reset game space conditions to the time and place as requested

Permit player to replay within discreet time and place conditions

Receive new outcome

Update historical records up to and including present records as if event actually occurred

Output saved game result to player character

Update player character attributes

[00430] A method to sacrifice a player character to create a savior character comprising:

Receive request to sacrifice player character Determine if sacrifice conditions are met Determine if player character qualifies to be sacrificed

Sacrifice player character

Randomly determine if sacrifice has succeeded

If sacrifice is successful, create savior from sacrificed player [00431] A method to create savior character(s) comprising:

Receive indication that Era qualifies for savior

Identify player characters that qualify to be saviors Determine if qualifying players have fulfilled savior conditions

Flag player character accounts as saviors if they have fulfilled savior conditions [00432] A method to reset game parameter to first era comprising:

Receive indication that apocalypse has occurred

Reset game parameter to first era

Populate game environment with player characters based on apocalypse results and apocalypse rules and conditions [00433] A method to randomly reset game parameter to first era comprising:

Receive random indication that apocalypse has occurred

Reset game parameter to first era

Populate game environment with player characters based on apocalypse results and apocalypse rules and conditions [00434] A method for creating a system generated apocalypse comprising:

Receive indication that apocalypse should be artificially generated due to stagnant game conditions

Cause apocalypse

Reset game parameter to first era

Populate game environment with player characters based on apocalypse results and apocalypse rules and conditions [00435] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00436] According to yet another embodiment, the present disclosure provides an in-game attribute that allows reverse outcomes of game parameters in video games such as a Massive IVϊultϊ Player Online Video Game.

[00437] According to this embodiment, an attribute in a massive multi player online video game exists that allows the player character who controls it to reverse the outcome of a game parameter. The player character performs a game parameter. Once the outcome of the game parameter is established, the player character can use the reverse outcome attribute to reverse the outcome of the game parameter.

[00438] Examples of attributes that can be used for reverse outcomes are:

1. A spell

2. An object

3. a player character

4. an in game character

5. a player pet

[00439] According to one embodiment, the "use reverse outcome attribute" can be limited. For example, the reverse outcome attribute may be limited to:

1. A certain race or class of player characters

2. A certain experience level of a player character

3. A certain time limit between uses

4. A maximum number of times the object can be used

5. A certain or increasing cost (in real or game currency)

[00440] Examples of game parameters in which the reverse outcome attribute may be employed include:

1. Player Character to Player Character-one player character defeats another player character in a duel. The defeated character uses the reverse outcome attribute which allows him to be the winner of the duel

2. Missions-a player character fails to complete a mission-the player character uses the reverse outcome attribute and the mission is flagged as completed by him.

3. Two player characters complete a game parameter together. One player character is rewarded with a game attribute for completing the mission. The other player character uses the

reverse outcome game parameter to be rewarded with the game attribute instead of the first player character.

[00441] According to one embodiment, some game parameters cannot be successfully completed unless a reverse outcome attribute is used [00442] According to one embodiment, a player character can nullify the use of a reverse outcome attribute by using another reverse outcome attribute, or by using a re-reverse outcome attribute.

[00443] According to one embodiment, a player character can be automatically endowed with a reverse outcome attribute when he reaches a certain level of the game.

[00444] According to one embodiment, reverse outcomes attributes could only be available in certain eras of the game

[00445] According to one embodiment, players could pay an extra fee to the server so that their characters can acquire and use reverse outcome attributes

[00446] According to one embodiment, players could have a limited in game or real time to use the device once a game parameter result has been determined.

[00447] According to one embodiment, players could obtain a "block game reversal" attribute, which, when used against a game reversal attribute, may certainly or only possibly block the other player's use of the reverse outcome attribute.

[00448] According Io one embodiment, a reverse outcome attribute may permit time travel. Players could then use the reverse outcome attribute to attempt to change the outcome of a completed even, action, etc. For example, if a player character fails to complete a mission, the player character may use the Time Travel attribute to attempt to complete the mission again, but now armed with foreknowledge of the game space and other game interactions, environmental conditions, etc. In this case, the outcome is not guaranteed to be reversed, only the possibility of a reversal is obtained by the player. As another example, where two player characters have dueled, the defeated character may use the Time Travel attribute to reset the game just prior to the duel, whereupon the player may again choose to dual or to make alternative choices before or during the dual in an effort to improve upon the outcome.

Again, a change in outcome is not guaranteed under this scenario, only the possibility of a reversal is granted.

[00449] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. Reverse Outcome Program

3. Time Travel Program

[00450] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database including, for example, i. Player GUID ii. Player Billing Information iii. Account Type iv. Characters 1-n-

2. Character Database including, for example, i. Character GUID ii. Qualifies for Reverse Outcome Game Attribute? iii. Game Attributes 1-n

3. Attribute Database including, for example, i. Attribute ID ii. Attribute Descriptor iϋ. Attribute Powers 1 -n iv. Attribute Reverse Outcome Probability

4. Game Parameter Database including, for example, i. Game Parameter ID ii. Descriptor iii. Conditions and Rules iv. Location

5. Attempted Game Parameter Database including, for example, i. Parameter ID ii. Time Start and End

iii. Parameter Result iv. Character IDs 1-n v. Saved Parameter Session

[00451] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00452] A method for allocating a reverse outcome attribute comprising: Receive indication that game parameter is complete Determine that successful game parameter completion qualifies player character for reverse outcome game parameter Determine if player character qualifies for reverse outcome game attribute

If player character qualifies for reverse outcome game attribute, provide/distribute attribute to character [00453] A method to use a reverse outcome attribute comprising: Receive game parameter outcome Store game parameter

Receive use of reverse outcome game attribute Determine if use of attribute is within time limit

Apply reverse game parameter outcome if use of attribute is within time limit.

[00454] A method to acquire a Nullify reverse outcome attribute comprising:

Receive indication that game parameter is complete Determine that successful game parameter completion qualifies player character for Nullify reverse outcome game parameter Determine if player character qualifies for reverse outcome game attribute

If player character qualifies for reverse outcome game attribute, provide/distribute attribute to character [00455] A method to Nullify reverse outcome attribute comprising: Receive and store game parameter outcome Receive use of reverse outcome game attribute Receive nullification of reverse outcome game attribute

Do not alter game parameter outcome

[00456] A method to acquire time travel attribute comprising: Receive indication that game parameter is complete Determine that successful game parameter completion qualifies player character for time travel game parameter Determine if player character qualifies for time travel outcome game attribute

If player character qualifies for time travel outcome game attribute, provide/distribute attribute to character

[00457] A method to use time travel attribute comprising: Receive game parameter outcome Store game parameter

Receive use of time travel outcome game attribute Determine if use of attribute is within time limit Apply time travel parameter outcome if use of attribute is within time limit by resetting game space to designated time and place with one or more characters affected

Permit player(s) to re-enact designated time and game event Record new outcome in historical and present database as if it had originally occurred as re-enacted.

[00458] A method to acquire block time travel attribute comprising: Receive indication that game parameter is complete Determine that successful game parameter completion qualffies player character for Block Time Travel game parameter Determine if player character qualifies for Block Time Travel game attribute

If player character qualifies for reverse outcome game attribute, provide/distribute attribute to character

[00459] A method to use block time travel attribute comprising: Receive and store game parameter outcome Receive use of Block Time Travel game attribute Determine probability of successful use of Block Time Travel game attribute

If successful do not alter game parameter outcome

[00460] Of course it wϊlf be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00461] According to another embodiment, the present disclosure provides a method to create in-game, objects from digital images of real life objects in a video game. According to one method of practicing this embodiment, one or more digital photographs of an object are scanned into a massive multi player online video game environment. The player character who scans in the digital photograph may specify a size and material for the object. Based on the material and size specified, a price may be generated to manufacture the object. The player character can pay the price (in virtual or actual dollars) and the game will assemble the object as specified by the digital images. [00462] According to another embodiment, the object can be assembled:

1. By the game server

2. By one or more computer generated character{s) in the game environment {i.e. a blacksmith that is a non player character)

3. By one or more player characters with the skills to assemble the item (i.e. a sword can be assembled by a player character with black smith skills)

[00463] According to another embodiment, materials to assemble the object can be obtained:

1. by purchasing from the game server

2. by purchasing from a computer generated character in the game server

3. by purchasing from a player character in the game server

4. by gathering them from the game environment (i.e. by mining ore)

5. by purchasing game tokens in the "real world" and exchanging them for materials in the virtual game space.

[00464] According to another embodiment, an in game price for assembling the object can be determined: 1. by the game server

2. by receiving bids from qualified computer generated characters

3. by receiving bids from qualified player characters

4. By outputting a price and receiving an acceptance of the output price by a player character to assemble the item.

5. Through an open, competitive market

[00465] According to another embodiment, a price for tokens in the "real world" for subsequent in game redemption may be determined:

1. by the game maker

2. by the store owner

3. Through an open, competitive bid or marketplace

4. Or, a discreet and finite number of tokens in general or by type of resource may be distributed to an auction site where players may bid for one or more tokens.

[00466] According to another embodiment, offers to assemble objects can be stored, made and presented: .

1. In a marketplace section of the game

2. In a trade chat window of the game

3. In an email that is sent to qualified non player characters

4. According to another embodiment, offers can include:

5. a time limit

6. a price (in virtual or real currency or other bartered items)

7. one or more digital photos of an item to assemble

8. a list of materials the object needs to be made from

9. a list of additional enchantments required to make the attribute [00467] According to another embodiment, rather than using one or more digital photographs to specify the item, an item design can be made in Photoshop, AutoCAD, 3d Studio Max, Maya, Visio, or another drawing and/or rendering program and submitted to the system to be manufactured. [0046S] According to another embodiment, a player character who has agreed to assemble the item can create it with any of the above programs as long as they own the necessary amount of virtual raw materials needed to assemble it.

[00469] According to another embodiment, players can pay an extra fee to the server to allow their characters to either import objects to assemble in the game or assemble these objects for other player characters.

[00470] According to another embodiment, player characters contracting to assemble an item can subcontract with other player characters to assemble components of the item.

[00471] Examples of attributes of a newly formed item that can be specified include:

1. shelf life

2. strength,

3. hit power or points

4. defends against

5. penetrates armor types

6. extends life by X days, weeks, months, years,

7. reduces life by X,

8. purchase price

9. depreciation rate

10. invisible y/n

11. reload rate

12. lifespan

13. dominate class

14. Recessive class, etc.

15. Improves recovery rate

16. Improves armor types generally or against specified weapons [00472] According to another embodiment, physical limitations can be assigned to a game object. For instance, the weight, size, and shape of the object can be limited based on the player character for which the item is being made. For instance a helmet has to have a certain diameter, a sword has to have a certain handle size and weight, etc

[00473] According to another embodiment, rather than money, player characters could pay or barter with contractors with other game attributes (items, raw materials, services, etc) in exchange for building a new item. [00474] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of

the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. Digital File Import Program

3. Object Creation Program

[00475] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Player Database including, for example, i. Player GUID ii. Player billing info iii. Account type iv. Characters 1-n

2. Character Database including, for example, i. Character GUlD ii. Character Attributes iii. Character Physical Limitations iv. New Items 1-n v. New item status

3. New Item Database including, for example, i. New Item ID ii. Character ID iii. New Item Digital images 1-n iv. New Item blueprints 1 -n v. New Item materials 1-n vi. New Item Construction Cost 1-n vii. New Item Salvage Vale 1 -n

4. New Item Contract Database including, for example, i. Contract ID ii. New Item ID iii. Item Materials 1-n iv. Item Blueprints 1-n v. Contract Price including, for example, vi. Contractor ID

vii. Subcontractor ID 1-n

[00476] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00477] A method to specify a new item comprising:

Receive digital image(s) of item from a player character

Generate blue print of item

Receive materials for each aspect of blueprint Determine physical limitations of item based on player character creating item and other conditions

If item is within physical limitations allowed, generate price to assemble item

Receive item price Assemble item

Output item to player character [00478] A method to create a new item contract comprising:

Generate blue print of item from digital images from a first player character

Receive list of materials Determine material amounts

Create and save request to assemble contract

Receive request to fulfill contract

Receive price to fulfill contract

Output price to fulfill contract to first player character

Receive acceptance of price

Output acceptance of price to second player character [00479] A method to create a new item comprising:

Receive request to assemble item from a player character Determine if player character qualifies to assemble item

If player character qualifies, output list of required materials

Receive appropriate materials

Assemble item

Output item to player character

[004S0] A method to fulfil! a new item contract comprising:

Assemble and Output item to a first player character Send item complete message Io second player character Receive payment amount or barter object from second player character

Receive item from first player character Release payment or barter object to first player character Release item to second player character

[00481] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00482] According to another embodiment, the disclosure provides methods and systems to provide inventory management of in-game items and attributes in a video game. Accordingly a game server or other system manages the number of particular objects that exist in a massive multi player online video game at any given time. Each computer or user generated item that exists in the game is given one or more maximum numbers and market value. When the market value for an item is reached in the game environment, then the maximum number is set to the amount specified. [00483] Alternatively, the game server can set a market value for an item based on the number of items that exist in the game. [00484] According to one embodiment, when a maximum number is adjusted in the game, additional items can be created by:

1. Allowing player characters to create the items

2. Allowing player characters to find the items on computer generated characters that they defeat in the game.

3. Allowing player characters to purchase the items from computer generated characters (NPCs)

4. According to one embodiment, the market value of the item can be determined in the game environment by:

5. The computer via computer generated characters that sell and stock the item

6. The player character to player character marketplace or auction

[00485] According to one embodiment, items can be destroyed in a game by player characters or computer generated characters or events when:

1. they are used as components to create another item

2. they are consumed

3. they are broken down into their constituent components

4. they are used in a game parameter that destroys or alters them

5. the real or virtual time limit for their existence expires

6. The era in which they are allowed to exist lapses

7. they are buried, burned or sacrificed to a God

[00486] According to one embodiment, in addition to allowing price to control the maximum number of items that exist in a game, the population on a game server can also control the maximum numbers of particular items that exist. Even more specifically the number of pfayer characters that are of a certain race or class can also have an effect on the maximum number of particular items that exist in a game.

[00487] According to one embodiment, in addition to items, races, classes, skills, and attributes of player characters can also be managed as inventory. For instance, certain skills can only be acquired by x number of player characters in a given game environment.

[00488] According to one embodiment, rather than adjusting levels of items, a maximum number of items can be created and fixed. Players can accumulate items and corner markets on them.

[00489] According to one embodiment, when certain items become available in a game, they make other existing items obsolete. I.e. when a game environment reaches a certain age, certain inventory items become available. The ability to create these items may make other items no longer available and/or less effective, valuable or useful.

[00490] As another alternative method, the number of items may also be established or limited via a vote by the majority of the players within a given game space.

[00491] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software

programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. New Item Creation Program

3. Item Management Program

4. Era Management Program

[00492] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Character Database including, for example, i. Character GUiD ϋ. Item ID 1-n

2. Item Database including, for example, i. Item ID ii. Item Quantity iii. Item Price iv. Maximum Quantity v. Maximum Price vi. Salvage Value By Era 1-n vii. Expiration Date viii. Quantity/Player Character Ratio ix. Quantity/Price Ratio x. Item Status

[00493] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00494] A method to create items in a game based on max items allowed comprising:

Retrieve Item ID Determine maximum number allowed based on conditions Determine if item id has equal or less than quantity to max allowed

If item id has less than max allowed, create new items [00495] A method to create items in game based on market price comprising:

Retrieve item id Determine whether item has exceeded a price threshold if itsm has exceeded price threshold, create new items in game [00496] A method to adjust maximum items in a game comprising:

Receive indication that game parameter has been completed Determine if game parameter completion alters max number of available items in game

If max number is altered, create new game items up to new maximum number; or Retrieve item id Determine if game conditions alter max quantity allowed of item id

Adjust max number allowed and create new items to maximum number if game conditions allow.

[00497] A method to determine market value of items in a game comprising:

Receive selling prices of an item id

Store each selling price of item id Determine value of Item based on range of selling prices [00498] A method to make items obsolete in game comprising:

Receive indication that game has advanced to new era

Retrieve item id(s) Determine if item is obsolete based on new era

Flag item record as obsolete based on new era conditions [00499] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps. [00500] According to yet another embodiment, the present disclosure provides methods and systems to facilitate favors between player characters in a Video Game.

[00501] According to this embodiment, a player character can perform a favor for another player character. Favors can be defined by the game server or by the player character's themselves. When one player performs an activity

that can be classified as a favor to a second player character, his player character account is flagged as being owed a favor by the second player character. Favors can be bought/sold by/io other player characters. [00502] According to one embodiment, activities that are considered favors may include:

1. Freeing a player character who is a slave

2. Helping or instructing a player character complete a game parameter

3. Performing an activity for a player character that the player character defines as a favor

4. Providing a game attribute or other object to a character without charge or below the current market value

[00503] According to one embodiment, the system can monitor and flag certain player character activity as favors, and keep track of favors performed automatically, or one player character can acknowledge that he owes another player character a favor by the first player character outputting a favor acknowledgement request and the second player character acknowledging that he owes the first player character a favor.

[00504] According to one embodiment, favors can be traded as currency.

[00505] According to one embodiment, favors can increase positive

Karma.

[00506] According to one embodiment, failure to oblige a player who requests a favor may increase negative Karma.

[00507] According to one embodiment, when a first player character owes a second player character a favor, the second player character can automatically force the first player character to perform an activity to neutralize the favor. For instance, the first player character may have the ability to complete a game parameter. The second player character can force the first player character to fulfill his obligation of owing a favor by forcing the first player character to help the second player character complete a game parameter.

[00508] According to one embodiment, when a first player character owes a second player character a favor, and the second player character

invokes the repayment of the favor, the second player character cannot continue normal game play until he has completed the game parameter required to fulfill his favor obligation. His game play can be inhibited by a pop up window that does not let him view the game world unless his favor is fulfilled.

[00509] According to one embodiment, when a first player character owes a second player character a favor, he can offer game attributes to fulfill the obligation of the favor.

[00510] According to one embodiment, certafn game parameters cannot be completed by a player character unless he is given a favor by another player character. For instance, a first player character cannot cross a bridge unless the monster that controls the bridge is first put to sleep. The only way for the monster to go to sleep is if he eats the meat of a sheep that is raised by a goat herder who only sells the meat to a certain class of player characters. A second player character of that class can perform a favor to the first player character not of that class by purchasing meat from the goat herder and providing it to the first player character so that he can feed it to the monster and cross the bridge while the monster sleeps. [00511] Another example would be: a second player character has enslaved the son of a first player character. The second player character will not speak to the first player character directly, but will speak through a third player character. The third player character can perform a favor for the first player character by speaking to the second player character about a ransom to free the first player character's son.

[00512] According to one embodiment, when a player character has no money, he can perform favors for other player characters. Once the favors are performed, they can be saved and invoked for later use, or sold back to the player characters that owe them or other player characters in the game environment.

[00513] According to one embodiment, player characters can post needed favors in a marketplace with the conditions thai must be fulfilled in order for the favor to be accomplished. Player characters can view favor requests in the marketplace and accept them If their attributes affow them to perform the favor. Favor requests can be posted with virtual or actual cash or

attribute values and the player character that completes the favor can elect to

(i) take the virtual or real cash or attribute, or (ii) allow the player character who requested the favor to owe him a favor in return.

[00514] According to one embodiment, favors or obligations to perform and/or to receive favors may be bought/sold or bartered among multiple players.

[00515] According to one embodiment, players may pay in real or virtual currency to absolve themselves of an owed favor or debt.

[00516] According to one embodiment, favors can be obtained from player characters who are gods or government officials in a game by giving donations or successful / accepted sacrifices to those characters.

[00517] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-fimitlng examples of software programs that might be used for ϊhe realization of the above embodiments include, but are not limited to:

1. Game Program

2. Favor Program

3. Contract Management Program

[00518] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Character Database including, for example i. Character GUlD ii. Character Attributes iii. Character Favors 1-n

2. Favor Contract Database including, for example i. Favor ID ii. Favor Type iii. Favor Value iv. Favor conditions v. Favor release conditions

3. Favor Type Database including, for example i. Favor Type ID ii. Favor Type conditions

iii. Favor Release Conditions 4. Contract Database including, for example i. Contract ID ii. Contract Conditions 1-n iii. Interface with Game and Favor Programs

[00519] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may be employed include, but are not limited to: [00520] A method comprising:

Receive favor contract creation request from a first player character

Receive conditions and release conditions of contract Store contract and bind first player to contract Receive indication that a second player character will perform the conditions of the player contract Bind second player to contract

Receive indication that second player has performed conditions of contract

Output conditions complete notification message to first player character

Receive indication that release conditions for favor contract have been completed by the first player character

Release first player character from favor contract with second player character [00521] A method to create a favor contract comprising:

Receive indication that action has been performed by a player character Determine if action obligates a second player to pay a favor to the first player character

Create Favor contract if action obligates second player Store Favor Contract [00522] A method to perform a favor comprising:

Receive indication that a second player character will perform the conditions of the player contract

Bind second player to contract

Receive indication that second player has performed conditions of contract

Output conditions complete notification message to first and second player character [00523] A method to fulfill a favor contract comprising:

Output conditions complete notification message to first player character

Receive indication that release conditions for favor contract have been completed by the first player character

Release first player character from favor contract with second player character [00524] A method to self or barter favors or favor contracts comprising:

Receive indication that a first player desires to sell or barter a favor or favor contract

Post ad on favor market or exchange page

Receive indication that a second player desires to purchase for virtual or real cash or barter for the purchase of a favor or favor contract and the offer price or terms

Output message to first player of second players offer

Receive indication of acceptance, rejection or counter offer from first player

Notify second player of acceptance, rejection or counter offer from first player

Upon acceptance of a first offer or a mutually agreed upon counter offer record transfer of favor or favor contract to second player and either virtual or real cash or a bartered item{s), or a substitute favor to first player.

Modify player database to reflect change in ownership/obligations of favor or favor contract and new ownership of consideration paid by second player

[00525] Of course it will be appreciated that such methods are provided for the purposes of example only and that none of the above methods should

be interpreted as necessarily requiring any of the included steps nor should they be interpreted as necessarily excluding any additional steps.

[00526] According to yet another embodiment, the present disclosure provides methods and systems to allow for genetic crossbreeding of parents to form children in a video game.

[00527] In this embodiment, player characters in a video game are assigned two chromosomes for each appropriate attribute they possess.

When two player characters have reached an appropriate level in a game and are eligible to have a child, the attributes of the child are generated by taking one chromosome from each parent and combining them to form the attributes for the child.

[00528] Appropriate attributes can include but are not limited to:

1. the physical appearance of the character including skin, height, weight, hair and eye color

2. the race of the character

3. the class of the character

4. the skills of the character

5. the strength, intelligence, stamina, wit, charisma, agility, etc of the character

6. the ability to improve any of said skills

[00529] According to another embodiment, rather than having two chromosomes of an attribute, the system can take the average attribute score provided by the two parents, or randomly select within a range between the two attribute scores of the parents in order to determine the attribute value of the child. These scores could be determined from the value of the attribute of the parent when the child is conceived, or from the value of the attribute of the parent when his character was created.

[00530] According to another embodiment, the current value, score or level of each parent's attributes may be used to determine which chromosomes are dominant or recessive.

[00531] According to another embodiment, the system could determine which attributes are more fully developed in a given child based upon environmental considerations such as how often the child employs or uses a given attribute. Those attributes used most often during childhood can

develop more fully while those less used may wane over time. The net overall growth of any given skill or attribute can therefore be a combination of the general proclivity to perform wsϋ as inherited from each parent and the child's use or actual development of said skill or attribute.

[00532] According to another embodiment, the system can randomly inject mutations into the attribute determination process so that children are not completely a product of the attributes of their parents. For instance, new attributes or different attributes can randomly occur in offspring. As an example, these mutations can occur:

1. Randomly

2. A certain number of times with each level of a family tree

3. A certain number of times in an era of the game

4. A certain number of times within each race and class of the game

5. More or less often depending on a character's race, class or family

6. More or less often depending on the era of the game environment

7. More or less often depending upon the child's actual usage or other development efforts.

8. Any combination of the above

[00533] According to another embodiment, particular attributes can have recessive and dominant chromosomes that mirror real life traits. For instance blue eyes are recessive and brown eyes are dominant. Alternatively, this may be determined by established game rules andior based upon parent's success and/or the child's environmental development as previously described.

[00534] According to another embodiment, before marrying or choosing to be a child of another player character, an existing or potential player character can view the genetic make up of the attributes of a player character, and, optionally, run a program io calculate the probabilities that a child will have certain attributes and characteristics given the known makeup of the parents.

{00535] According to another embodiment, the cost of marrying or being a child of a particular player character can be set by the system based on the attributes of the character and how desirable they are to have in potential offspring. According to another embodiment, Artificial Intelligence or Genetic Algorithms can be applied to this process to make it more rich and complex. [00536] Accordingly, the present disclosure provides for hardware and software that can be utilized to create one or more, or a combination of, any of the above-described embodiments. Non-limiting examples of software programs that might be used for the realization of the above embodiments include, but are not limited to:

1. Game Program

2. New Character Creation Program

[00537] Examples of databases that might be used for the realization of the above embodiments include, but are not limited to:

1. Character Database including, for example i. Character ID ii. Character inheritable attributes 1-n iii. Character Chromosomes

2. Mutation Database including, for example i. Mutation ID ii. Mutation descriptor iii. Mutation attributes 1-n

[00538] The present disclosure further provides methods by which the embodiments described above, alone or in combination, may be realized. Examples of methods that may foe employed include, but are not limited to: [00539] A method comprising:

Receive request to create new player character from one or more existing player characters Determine if one or more existing player characters qualify to create new player character

If existing ρiayer(s) qualify retrieve inheritable attributes: Apply new character creation program to attributes

Create new player character based on inheritable attributes of existing player character(s) and new character creation program; and

Allow new player character to enter game environment [00540] A method to create a new character from chromosomes of parents comprising:

Receive request to create new player character from one or more existing player characters Determine if existing player eharacier(s) qualify to create new player character

If character(s) qualify, retrieve character chromosomes Apply new character creation program to character chromosomes

Create new character based on existing player character chromosomes and new character creation program

Allow new player character to enter game environment [00541] A method to create a new character from average attributes of parents comprising:

Receive request to create new player character from one or more existing player characters Determine if existing player characters) qualify to create new player character

If character(s) qualify, retrieve character inheritable attributes Generate the average number of each inheritable attribute

Create new character based on average number of each inheritable attribute and

Allow new player character to enter game environment [00542] A method to apply a random mutation to a new character comprising:

Receive request to create new player character from one or more existing player characters

Determine if one or more existing player characters qualify to create new player character

If existing player(s) qualify retrieve inheritable attributes Apply new character creation program to attributes Retrieve mutation rules Determine if new character qualifies for mutation based on rules

Create new player character based on inheritable attributes of existing player character(s) new character creation program, and applicable mutation rules

Allow new player character to enter game environment [00543] According to one or more embodiments, the present invention provides methods and systems for pfayers to improve their progression through a video game by helping other player characters. [00544] According to one or more embodiments of the invention, "helpfulness," that is the amount of help a given player character has provided to other player characters is a measured trait in a video game. A character's helpfulness may be measured using any suitable method including, but not limited to, those methods that haye been previously used to measure other character traits (e.g. strength, health, intelligence, weapon ownership, skills, etc.) with which those of skill in the art will be familiar. For example, a game may include a running tally of help points that are associated with a particular player character. A player character's help point tally may be provided as part of the in-game display, or an item that is accessible (i.e. viewable) by a player before, during, or after game play - for example by accessing and then browsing through a game statistics menu. An in-game help point tally may be provided, for example, as a numerical figure that appears in a portion of the game screen, with or without additional information (e.g. other character trait tallies). Alternatively, an in-game help point talfy may be provided in the form of a bar graph, or through the use of any other suitable indicia. [00545] For ease of description, the present disclosure may make reference to help "points" when referring to a player character's acquisition, accumulation, or loss of helpfulness in a gam©. It should be understood, however, that a player's helpfulness need not be measured in terms of points

or absolute values or given a numerical (or other) measurement. Other systems, such as, for example, where a player character has a certain maximum amount of helpfulness that can be accumulated and the player controlling the character is provided with an indication as to what percentage of the maximum amount of helpfulness has been accumulated (e.g. a simple bar graph that increases and decreases in length as a player character is deemed more or less helpful or gives or receives more or less help) are contemplated by the present disclosure.

[00546] According to one or more embodiments, each player character may have an account that measures the amount of help the character has given to other characters. As the game progresses, a character may accumulate help points for helping other characters in the game. For example, character X may be attempting to solve a puzzle ϊn a game that character Y has already solved. Character Y may help character X solve the puzzle and may receive help points for doing so.

[00547] According to a first embodiment, the game system may manage, distribute and remove help points from the characters based on their actions without ramification to other players. Accordingly, in the example above, the system may pay character Y a given amount of help points without consequence to character X.

[00548] Alternatively, some or all of the help points gϊven to a character who gives help (e.g. character Y) may be paid by (or otherwise deducted from) the character who has received the rieip (e.g. character X). The help points paid may be deducted from the amount of help points that a character has earned. This embodiment creates a dynamic whereby in order for a character to receive help, the character must give help. Player characters may initially be given a certain number of help points which they can use when they first start the game, or, they may be required to initially help another character before they can receive any help at all. [00549] According to one or more embodiments, help points may be accumulated by assisting another character in completing, partially completing, or attempting to complete a game parameter. It will be understood that the type of assistance given may be dependant upon the

particular game parameter that the heipee (the character receiving the help) is attempting to complete.

[00550] As non-limiting examples, assistance may be given in the form of written notes (e.g. emails or instant messages including a text-based or other form of an answer or hint); lending or giving a virtual object that solves or helps to solve a puzzle or otherwise aids the heipee in completing the parameter; and/or performing a mission with the heipee. [00551] For example, a particular game may require that a player have collected one or more specific items, such as a key (or set of keys), before a specific door can be opened. A helper may be able to give another character help by: text messaging to the heipee the location of one or more of the keys or other instructions regarding how to obtain the key(s); giving or lending the heipee the key(s); and/or looking for the key(s) with the heipee. [00552] According to one embodiment, a helper may only receive help points if the heipee successfully completes the game parameter. Alternatively, the number of help points given to the helper (the character providing the help) may or may not be dependant upon the degree of success by the heipee \n completing the task.

[00553] Therefore, according to some embodiments, in the example above, the helper may only be given help points after the heipee successfully opens the door. Alternatively, the helper may be given help points after sending a text message with the location of one of the keys or giving the heipee the key(s), whether or not the heipee actually opens the door. [00554] According to some embodiments, help points are associated with a particular character, not a particular player. As such, a player who controls more than one character may have the characters help each other in order to accumulate help points. Alternatively, such intra-player helping may be disallowed by some game systems.

[00555] According to one or more embodiments, the accumulation and/or possession of help points may be a prerequisite for completion of other game parameters. For example, a character may be required to have a certain number of help points in order to advance to the next or a given level in the game, gain or purchase an in-game item or attribute, or perform a certain in-game action.

[00556] According to one or more embodiments, the character who is the first to complete a particular game parameter will have right to receive payment (either in help points or in some other form) for helping others to complete the game parameter. According to a further embodiment, a given game parameter may be designed such that only a limited number of characters can complete the parameter without help. Other characters will then have to find a character that has completed the parameter without help and convince that character to give help. As a still further embodiment, the game maybe designed so that if one of the characters that originally completed the parameter drops out of the game, a slot ts opened up for a new character to complete the parameter without help.

[00557] According to one or more embodiments, the amount of help a player can receive before giving help to another character may be limited or may depend upon other actions, such as the amount of help the character has given. In such an embodiment, upon spending a certain number of help points by receiving help, a player may be required to give help to another character before being alfowed to complete a game parameter. Alternatively or additionally, upon accumulating a certain number of help points by giving help, a player may be required to receive help before being allowed to complete a game parameter. As a further alternative, a character's success in the game (as measured, for example, by reaching increased levels, accumulation of points or items, amount of time spent in the game, puzzle solving, number of missions completed, etc.) may determine when and to/from whom the character can give or receive help.

[00558] For example, in a game in which players solve puzzles and accumulate experience points, a game may be designed such that a character can only receiye help for a certain time period or for a certain number of missions before the character must give another character help in order to advance to the next experience point level. Accordingly, such games may be designed to encourage players to decide whether they want to spend their time getting help to get past certain obstacles or giving help to improve their experience point rankings.

[00559] As a still further embodiment, a particular player character or an entire player account (and alf characters associated therewith) can be flagged

as being required to either give or receive help for a given game parameter before a particular character (or character account) is allowed to advance to a next level.

[00560] According to one or more embodiments, giving help to a particular character may itself be a game parameter. Specifically, a game may be designed wherein at least one of the game parameters requires that help must be given to a (perhaps specific) other character in order for the game parameter to be completed. It will be understood that in this embodiment the specific other player to whom the help must be given may be controlled by the player who is controlling the helper, controlled by another player, or a non-player character NPC (e.g. a computer-controlled character). The requirement that help be given to the other character may or may not be explicitly stated to the helper.

[00561] For example, a particular game may require that a player kill a specific monster in order to advance to a next level. The game may be designed such that the only way for the player to kill the monster is by giving a certain weapon to another character so that the other character can kill the monster. As an added level of complexity, the game may not tell the player that this is how the monster must be killed.

[00562] As a further alternative, a character may only receive help points or other rewards for helping when he gives help to a specific character. For example, a player may only receive help points when he gives a player who has been designated as his "buddy" help.

[00563] According to one or more embodiments of the invention, a particular game may include a virtual marketplace in which players can find potential helpers or helpees. According to this embodiment, players may be able to post requests and/or offers for help for other players to view. [00564] For example, a game may include a virtual marketplace in which players who are looking for help with completing a particular game parameter can post requests for help. Another player could then view and/or accept one or more requests. Alternatively, the potential helper could send the potential helpee an offer to help, which could then be accepted or rejected by the potential helpee. Once a request has been fulfilled (which, as explained

above, may or may not require successful completion of the game parameter by the helpee), the helper may receive help points or other compensation. [00565] According to a further embodiment, once a character has successfully assisted a given number of characters, the character may be given a reward in addition to the help points accumulated. For example, the character may be permitted to advance to a new level in the game. The number of characters that must be assisted by a particular helper may be defined, for example, by the game system. Alternatively or additionally, the game system may require a helper to give help in a given number of game parameters before giving the helper the additional reward. [00566] According to a still further embodiment, characters may need to fulfill certain conditions before they can agree to accept a help request or offer help. For example, only those characters who have completed a particular game parameter may be allowed to give help to a player attempting to complete that game parameter. Alternatively or additionally, only those characters who have accumulated a certain number of experience points, time in the game, depleted their help points to a certain level or who fulfill some other requirement may be allowed to give help. [00567] According to one or more embodiments, the number (or amount) of help points given for help with a certain game parameter may be determined using any suitable means, including, without limitation, a priori by the system, dynamically by the system, or market driven. For example, as mentioned above, a player may submit art offer of help to a player who has posted a request for help to an in-game marketplace. The offer may further include the number of help points the helpee must pay the helper in order to receive the help. Alternatively or additionally, players could post offers to help and potential helpees could contact them with a request for help and the amount of help points the helpee is willing to pay for the help. Players could then end up giving, receiving, accepting and/or rejecting help related bids. [00568] It will be appreciated that help need not be paid for exclusively by help points. For example, players may agree to help each other, "I'll help you with parameter A if you help me with parameter B," trade one or more in- game items or currency for help, or may other arrangements as is suitable for the conditions of a particular game.

[00569] According to one or more embodiments, a game may include various skill levels or training that must be earned by playing the game. Characters may be able to sell or trade skills or training to other players. The skill may be offered, for example, as a module available for purchase for a certain amount or to the highest bidder. As a further embodiment, a character who purchases a skill or training may be able to sell the skill or training to another character. According to a still further embodiment, a character who initially purchases a skill (or training) and later sells the skill, may have to pay a fee, such as g percentage of the transaction, to the character from whom the skill was initially purchased.

[00570] Turning now to Fig. 24, exemplary databases that might be included as some of the game databases residing on a central server are shown. As shown, game databases 318 may include a player database 324, a character database 326, a game parameter rules database 328 and a contract database 330.

[00571] Player database 324 may comprise data related to the players who access and play the game. As a non-limiting example, player database 324 may link a player's unique identifier (ID) with the player's name, address, and billing information. The player's ID may further be linked to the character(s) that are under the control of the player, this Information may be provided in the form of a unique identifier (character ID) associated with each character. Depending on the particular embodiment(s) of the present disclosure that are being used, the player database may further link the player with a list of game parameters and the various help that was given or received in order to complete the game parameter. The database may further link the player with a list of game parameters and an indication of whether help must be given or received by the player in order to complete the game parameter. [00572] Character database 326 may comprise data related to particular player characters in the game. As a non-limiting example, character database 326 may link a character's unique identifier (character ID) with game parameters that require that the character receive help in order to complete the parameter, game parameters that requires that the character give help in order to complete the parameter, and saved game results.

[00573] Game parameter rules database 328 may comprise data related to the various game parameters that may be encountered in the game and the help points or credits that may be associated therewith. As a non-limiting example, game parameter rules database 328 may link a game parameter's unique identifier {game parameter ϊD) with a game parameter title or name, a game parameter descriptor, the amount of help points or credits that may be received for giving help to another character for that game parameter, and the help point cost associated with the game parameter, i.e. the number of help points a character must pay in order to get help with the game parameter. It should be appreciated that a particular game may be designed such that the amount of help points awarded to a player character who gives help on a given parameter may, but need not necessarily,, be equivalent to the number of help points that another player character must pay in order to receive help with that parameter.

[00574] Furthermore, it should be appreciated that the amount a character must pay in order to receive help need not be equivalent to the amount of pay that is given to the character who is giving help. For example, a helpee may have to give up 100 gold pieces in order to pay a helper 10 gold pieces.

[00575] Contract database 330 may comprise data related to various contracts that may be formed between players or player characters in the game. Additionai examples of player contracts are provided in co-pending U.S. Patent Application Serial No. 11/355,232, which is hereby incorporated by reference in their entirety for ail purposes. As a non-limtting example, contract database 330 may associate a unique contract identifier (contract ID) with a game parameter iD, the character (or player) ID of the helper, and the character (or player) ID of the hetpee.

[00576] According to one or more embodiments, system 1 may be configured to qualify a character to give help. For example, system 1 may first retrieve a character account and determine the attributes of the character associated with the retrieved character account. The system may then identify the game parameters for which the character can give help based on the character's attributes and then flag the account as abfe to give help for the identified game parameters.

[00577] As a specifrc example, a game may be designed such that only characters who have completed a given scored game parameter with a score above a certain threshold can give help on that parameter. Having completed the parameter with a score above the threshold could then be an attribute that is associated with the character. Accordingly, system 1 may be configured to identify those characters that have that attribute (i.e. have completed the game parameter with a score higher than the threshold) and flag those character accounts as able to give help on that parameter. [00578] According to another embodiment, system 1 may be configured to qualify a character to receive help. For example, system 1 may first retrieve a character account and determine the attributes of the character associated with the retrieved character account. The system may then identify the game parameters for which the character can receive help based on the character's attributes and then flag the account as able to receive help for the identified game parameters.

[00579] As a specific example, a game may be designed such that only characters who have given help in the last three hours of game time can receive help. Having given help in the last three hours of game time could then be an attribute that is associated with the character. Accordingly, system 1 may be configured to identify those characters that have that attribute (i.e. have given help in the last three hours of game time) and flag those characters as able to receive help. In this example, this limitation may be applicable to all game parameters in the game. Alternatively, as with the example described above with regard to qualification to give help, this, or other, limitation(s) may be applied to only one or some of the game parameters in the game.

[00580] According to yet another embodiment, system 1 may be configured to generate a help contract between two (or more) players. For example, system 1 may be configured to receive a request to give or receive help for a game parameter. The system may then output the request to an appropriate character. The system may then receive acceptance of the request and create a new contract between the character requesting to give or receive help and the player accepting the offer to give or receive help.

[00581] According to stil! another embodiment, system 1 may be configured to apply points and/or credits to a character account for giving help. For example, system 1 may be configured to receive an indication that help has been given to a first character from a second character. The system may then determine the help points/credits earned by the second character for giving help to the first character. The number of help points/credits earned may be dependant upon _r for example, the type of help given, the difficulty of the game parameter in which the help was given, the success of the first character in completing the game parameter after receiving the help, or other factors. The system may then apply the help points/credits earned to the second character's account.

[00582] According to a stiff further embodiment, system 1 may be configured to deduct help points and/or credits from a character account for receiving help. For exampie, system 1 may be configured to receive an indication that help has been received by a first character for a given game parameter. The system may then determine the help point/credit cost of receiving help on that game parameter and deduct the help point/credit cost from the first character's account.

[00583] According to another embodiment, system 1 may be configured to advance a character to a next level once a given threshold level of help points have been obtained by the character. For example, system 1 may be configured to retrieve a character account, determine if the account has acquired a number of help points above the threshold level, and advance the character to the next level if the required number of help points has been acquired.

[00584] According to a further embodiment, system 1 may be configured to provide virtual items or attributes to a character for giving help. For example, system 1 may be configured to receive an indication that help has been given to a first character by a second character. The system may then determine if a virtual item and/or attribute is available for the help that was given. For example, the item and/or attribute may only be available if a certain type of help was given, if the help was given for a certain parameter, or if the help was given to a certain character. 1f the item and/or attribute is

available for the help that was given, the system may then be configured to provide to the item and/or attribute to the second character. [00585] Help may be passed on from one piayer, for example, an expert player, to another player, for example a novice player Accordingly, one or more embodiments of the present invention provide methods and system for characters to gain expert status and be rewarded by other characters for providing help in their field of expertise. As stated above, help may take a number of different forms. One form that help may take is as advice. While the discussion below is directed primarily to those situations where the help is provided in the form of advice, it should be understood that any of the methods and systems described befow may be modified for those situations where the help is provided in some other form.

[00586] Accordingly, one or more embodiments of the present invention provide methods and system for characters to gain expert status and get awarded by other characters for providing advice. [00587] According to an embodiment characters may be able to qualify to gain expert status for certain game parameters toy, for example, having successfully completed the game parameter or having successfully completed other similar game parameters. Once a character has gained expert status for a given parameter, that character may then provide advice to other nonexpert players to help them successfully complete the game parameter. For the purposes of ease of description, the character who receives advice will often be referred to as a "novice" character in the present disclosure. While it is often true that a novice character may be a character who is new to the game or who has tess experience in the game than the expert, it should be appreciated that the present disclosure does not require this to be the case. Accordingly, unless specifically status to the contrary, the term "novice" should be interpreted broadly to include any character (or player), regardless of experience level, who receϊyes help from another character (or player) and an "expert" shall be interpreted broadly to include any character (or player) regardless of experience level, who gives help to another character (or player).

[00588J According to some embodiments, a novice player can offer to contract with an expert player to receive advice about how to satisfy a given

game parameter. !f the expert accepts the offer, a binding and enforceable contract is created between the two characters. Once the parameter has been completed by the novice, the expert player is given a benefit and the novice player is given a deficit, according to the terms of the contract. Non- limiting examples of benefits and deficits are awards/payments of in-game currency, awards/deficits of point values, awards/deficits of skill levels, awards/deficits of in-game items, awards/deficits of real world currency, and/or combinations thereof.

[00589] According to one or more embodiments, a novice player may be required to qualify in order to request or receive advice. Qualification may, for example and without limitation, include: reaching a certain level in the game, acquiring a certain object, paying (e.g. for a subscription to expert services), and/or being a paying member of the game for a certain length of time. [00590] According to one or more embodiments, a novice player who desires to receive advice may be provided with a list of experts who are able to give advice. The novice player may be able to contact, via email, an in- game instant message, a voice over IP service, etc., any one of the experts on the list, if the expert is online, the expert may be notified that a novice would like to receive advice.

[00591] According to another embodiment, novices who are seeking advice may be able to post advice requests for example, on a message board. An expert who would like to provide advice may then browse through the advice requests and choose any requests that he would like to answer. [00592] According to another embodiment novices and/or experts may be rated. For example, once an expert works with a novice, the expert may be able to give feedback regarding the novice. This feedback may then be made available to any experts who consider providing advice to the novice. The feedback may be provided to experts in any suitable manner. For example, experts may rank a novice on a 1-10 scale for one or more characteristics such as quickness of learning, did what I asked, performed task successfully, annoying, took up too much time, etc. These rankings, or a composite thereof, may then be provided to the expert. Alternatively, experts may simply write free form or guided reviews and these reviews may be made available. Experts may then select a novice to help with the help of the rating

system. Correspondingly, novices may be able to provide feedback on the experts with whom they have worked.

[00593] According to another embodiment, experts may be able to provide to the game server a list of criteria which must be fulfilled by a novice before the expert is willing to iieip the novice. For example, the expert may be able to identify that he will help only novices who have gained a certain feedback ranking, reached a certain level in the game, spent a certain amount of time in the game, or the like. The system may then be configured to notify the expert when an adyice request has been received by a novice who fits some or all of the expert's criteria.

[00594] According to another embodiment, the system may be configured to select an expert for the novice. For example, in order to qualify as an expert, an expert must agree that he will provide help to any novice that is assigned to him by the system. Alternatively, the expert may be given the power to turn down a novice that has been suggested to him by the system. [00595] The system may select a novice for an expert using any reasonable means. For example, the system may be configured to select a novice by matching a specific request for advice submitted by a novice with a particular expert's field of expertise. Other factors such as whether the expert is online at the time the novice requests the advice may alόo be considered. Other mechanisms by which expert-novice pairings may be created include: basing the pairing on previous play by the expert {for example, an given expert may be assigned to provide advice each time a certain scenario or event unfolds in the game for which the expert has provided effective advice in the past and/or for which the expert has been highly rated), assigning the pairing at random, or basing the pairing on certain events. Suitable events include, for example, a new character joining the game (e.g. every new player gets an expert coach the first X hαurs/minutes/days of piay) _t or completing a new game parameter (e.g. each time a character attains a new game level, new character class, or new ability, the character gets an expert coach). [00596] According to one or more embodiments of the present invention, an expert may give advice on a completely voluntary basis. In such a case, a player may simply choose to become an expert when, and only if, he wants. However, a particular game may be designed such that players may need to

volunteer to be an expert in order to gain certain advantages in the game, such as, for example, advancement to a new level, attainment of certain items, or attainment of certain skills.

[00597] According to one or more embodiments, a player or character may have to qualify to become an expert. For example, a player may be able to become an expert when any of his characters reach a certain experience level. Alternatively, a player may only be allowed to gain expert status when an aggregate of ail experience of all characters in that player's account have reached a certain level. Moreover, qualification may be based on factors other than experience, such as ranking in the game, or other player's ratings of the player.

[00598] According to an embodiment, a player may be notified when he has qualified to be an expert. The game may offer the player the opportunity to be an expert by, for example, presenting a screen or pop-up window to the player presenting art offer to become art expert. Alternatively, once any qualifications are met, a player may request to be granted expert status. Upon becoming an expert, the player may be provided access to chat rooms, message boards, or other areas of the game that are available to experts. [00599] According to some embodiments, experts may designate one or more areas of expertise - that is one or more game-related aFeas in which they are willing to coach or provide other help. For example, a particular player may limit his expert advice to only a certain type of puzzle, a certain level of the game, a specific game parameter, etc.

[00600] Furthermore, according to some embodiments, experts may designate a specific price or price range for their advice. Alternatively, the cost could be determined by the gaming system. As stated above, the "price" need not necessarily be paid in in-game currency. For example, rather than simply stating that a character seeking advice must pay 10 gold pieces for advice, an expert may designate that he will only give adyice to a character who can give him a certain item in return for the advice. [00601] According to some embodiments, the cost of advice could be charged to the novice character upon receiving the advice. For example, experts could post specific pieces of advice on a message board. If a novice reads the posted advice (i.e. opens the message) the novice could

automatically be charged the cost associated with the advice. As another example, a novice may enter a chat session with one or more experts. Upon spending a certain predetermined amount of time in the chat session, the novice could be charged a specific cost/fee. Alternatively, the novice could be charged a fee per unit of time of the chat room.

[00602] According to one or more embodiments, an arbitration panel could be implemented to oversee and resolve any disputes or conflicts that might arise during the game. For example, a novice who is dissatisfied with the help that he received from an expert could submit a complaint to an arbitration panel. Similarly, an expert who is dissatisfied with the actions of a novice could submit a complaint to the arbitration panel The panel may be comprised of other experts, other novices and experts, non-players, etc. The panel members may be volunteers, or may be recruited on a voluntary or mandatory basis.

[00603] Upon receiving a complaint, the pane! may decide whether they vote in favor of the expert who gave the help or the novice who received the help. Whoever the panel decides against may be given some type of penalty. For example, if the panel decides that a particular character's claims have no merit, the novice may be flagged as a "whiner." This label may then be attached to the character for other potential helpers to see. Alternatively or additionally, the character (or player controlling the character) may be barred from submitting complaints to the arbitration panel for a given period of time. Moreover, future panels may be given access to previous arbitration decisions involving the complainant Alternative or additional penalties may include, without limitation, the character {or player controlling the character) being barred from providing/receiving help for a certain period of time, lowering of the expert's or novice's ranking, full or partial payment refund or reduction, etc.

[00604] According to some embodiments, for example those in which a novice is assigned an expert for a certain period of time, payment may be provided on an on-going (e.g. pay as you go) basis. In such a case, should the novice feel that the expert's advice is no longer helpful, the novice may simply stop paying.

[00605] According to some embodiments, some or all areas of expertise may requires some threshold competency before a character can be designated as an expert in that area. For example, a character may only be allowed to coach on a particular ability of they character has had that ability for X hours, days, weeks etc, used the ability X times, or achieved a certain number of results (e.g. X number of kills) with the ability. Alternatively or additionally, the threshold competency may be determined by asking the potential expert to take a test or perform some other action. Non-limiting examples of suitable areas of expertise include, reaching a level, using an ability, kill/death ratios, obtaining an object, solving a puzzle, accuracy with weapons, effective use of a weapon, killing a certain character/creature, starting out in the game, successfully navigating through a certain geographic area (e.g. the expert provides or in some way is a map), getting through a certain area using certain skills, game play techniques, or abilities, and/or speed of accomplishing any of the above.

[00606] Advice may be provided using any suitable means. For example, the game system may include an in-game communication system such as a chatroom, web interface, text messages, email system, voice communication system, etc. Alternatively or additionally, out of game communication system such as regular email, text messages, phone, and/or mail may be used.

[00607] According to another embodiment, experts may be able to observe the game play of novices and notify a novice if he has a suggestion. [00608] Alternatively or additionally, an off-line "replay" system could place the expert in the scenario with which the novice is seeking advice and the novice could watch the expert play that segment. Whether on-line or offline, one character (e.g. the novice) could shadow the other character (e.g. the expert) during certain parts of the game. The character who is shadowing could be shown on the screen as a "ghost" character. Moreover, the system could allow an expert player to temporarily take over the control of a given novice character. In such a case, the expert's character may be shown as a ghost following the novice character. Alternatively, the novice player may retain control of the novice character while the expert provides advice (for example over an in-game voice system) to the novice. Again, the expert's

character could be shown as a ghost following the novice character. As a further alternative, the expert could play the segment while the novice watches, in this case, the novice character could be shown as a ghost following the expert character.

[00609] In a further embodiment, novices could submit a segment of game play to an expert pool. Interested experts could each play the segment, essentially competing against each other. The expert with the best performance in the game segment could then be paired with the novice. Alternatively, the novice could be provided with a list of all the experts that completed the segment, along with a price list to see each expert's solution. The novice could then select which expert's advice he would like to receive. [00610] In another embodiment, experts could provide advice on a novice's saved game results. For example, game results could be posted on a message board, and experts could peruse the message board to find a novice they think they could help and/or who they think might pay them for their advice. Alternatively, a contract could be worked out between the expert and the novice and the results viewed by the expert only upon acceptance of the contract.

[00611] As stated above, according to some embodiments, novices may be allowed to rate the advice given to them by an expert. Ratings may be provided using any suitable means including, for example, picking a rating from a list (e.g. thumbs up, thumbs down, 1 through 5 stars, a numerical ranking between 1 and 10 _r etc.) for one or more characteristics and/or an overall ranking or entering a free-form text or voice message. According to some embodiments, the novice may be prompted to give a rating at the end of an advice session and may be required to do so before game play can resume. Alternatively, the novice may be able to defer the rating and go back to it when convenient. As a further alternative, deferred ratings may carry less weight, the longer a novice takes to provide them.

[00612] Alternatively or additionally, the game system may automatically rate the advice given by an expert. A system-based rating may be based on whether the player character who received the advice met certain objectives/goals that were the subject of the advice. These objectives/goals may be set by the novice, the expert, or the system. Accordingly, the system

may include a mechanism for determining whether the novice who received the advice actually followed the advice given by the expert. If the goals were set by the novice or expert, the system may include a mechanism for identifying the goals in order to determine whether or not they were met by the novice.

[00613] For example, if an expert gives a novice advice regarding how to finish a level, the expert's rating may depend upon the how long it took the novice to finish the level, the points and/or skills accumulated by the novice during the level, and/or future success in completing other similar levels. For example, the system may be configured to compare the average skill progress per time of a novice who has received help with the average skill progress per time of other novices.

[00614] According to one method of implementing this embodiment, when a character completes a given task (e.g. killing certain monster, finding a certain object), the system checks to see if an expert had given that character advice about that particular quest. W an expert had given advice to that character about that particular quest, the expert could be given a benefit. Accordingly, the system would be configured to record each instance of advice given from the expert to the player and nature of the advice given (i.e how to kill monster X, how to find object Y). The system would be further configured to determine that the novice's actions met the nature of the advice (monster X was killed, object Y was found.) If the advice was limited to a certain identified quest; for example, the system would have to determine whether the character's actions took place during the quest. For example, if monster X or object Y is only available during the identified quest, the system would know that the character was engaging in the identified quest at the time the action was performed.

[00615] Moreover, the system could be configured such that if a novice seeks advice from a second expert for advice on the same problem or task, some or all of the benefit that would have gone to the first expert is withheld. This withheld benefit may or may not be passed on to the second expert or refunded in full or in part to the novice.

[00616] According to an embodiment, expert ratings can be quantified and compared so that novices can shop for experts. This also provides

incentive for experts to give good advice, in order to increase their expert rating and help them increase revenue (in whatever form) from their advice. For example, for each expert, the system may list in a table the average skiii progress per time of the novices that the expert coached. The table may then show the expert who coached the characters with the fastest post-coaching progress. Alternatively, for each expert, the system may list in a table the ratio of what each novice gained in the month after coaching versus what the novices paid for the advice. The higher the ratio, the better the "payoff of the expert's advice. As a further alternative, for each expert, the system may compare the expert's novices ³ success rates before and after coaching. This would give a measure of how effective the expert's advice was for each novice.

[00617] It will be appreciated that all of the methods described above regarding providing ratings of experts may be similarly applied to the rating of novices.

[00618] According to another embodiment, awards from successful advice may trickle up an "advice ladder." For example, Character A may give advice to Character B. As Character B's successfully plays through the game, Character A may receive some benefit based on Character B's success. Eventually, Character B may become an expert and give advice to Character C. The game system may be configured such that Character Cs success is beneficial not only to Character B, but also to Character A. [00619] Turning now to Figs. 25 and 26, Fig. 25 provides a block diagram showing system 1 Including an expert management program 323. Fig. 26 provides a block diagram showing suitable exemplary databases that might be included in system 1 when system 1 includes an expert management program. As shown, an additional database, expert rules database 331 is included.

[00620] In the embodiment depicted in Fig. 25, in addition to the information described above with respect to Fig. 24, player database 324 may further include information regarding the player's expert settings. If expert status is awarded to the player, the status for the player could be identified. Alternatively, if expert status is awarded to the character, the status for each character in the player's account could be identified.

[00621] In the embodiment depicted in Fig. 24, in addition to the information described above with respect to Fig. 24, character database 326 could include information related to expert parameters associated with the character.

[00622] In the embodiment depicted in Fig. 26, in addition to the information described above with respect to Fig. 24, contract database 330 could include information related to the identification of the expert who is the party to an expert-novice contract.

[00623] The expert rules database 331 could include and associate information related to game parameter identification, game parameter name, game parameter descriptor, expert benefit associated with advice given to fulfill the game parameter, and cost to a novice for receiving a advice for that game parameter.

[00624] According to one embodiment, system 1 could be configured to allow players to pay extra to have abilities associated with expert status. For example, system 1 may be configured to receive player account set up information and output an offer to identify a player character as a potential expert. If the offer is accepted, system 1 may be configured to receive a billing rule for the potential expert status and apply the billing rule to the expert and novice player accounts.

[00625] According to another embodiment, system 1 could be configured to assign a player or player character to be an expert for a particular game parameter. For example, system 1 may be configured to receive an indication that a player character has completed a game parameter; determine if expert status if available for that parameter, output an offer to be an expert to the player character who has completed that game parameter, and, if the offer is accepted, flag the player character as an expert for that game parameter. [00626] According to stiJI another embodiment, system 1 could be configured to pay an expert character for advice given to a novice character. For example, system 1 may be configured to determine if an expert advice contract has been fulfilled. If an expert advice contract has been fulfilled, system 1 may be configured to retrieve payment criteria for the expert advice that was given and apply the payment criteria to the expert and novice player accounts.

Conclusion

[00627] 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.

[00628] 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.

[00629] Where a limitation of a first claim would cover one of a feature as well as more than one of a feature (e.g. _r 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).

[00630] 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.

[00631] 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. [00632] 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).

[00633] Similarly, where more than one device or article ts 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. [00634] 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. [00635] 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 skid in the art will recognize that the disclosed inventions) 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.

[00636] 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.

[00637] 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).

[00638] 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.

[00639] 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.

[00640] 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.

[00641] 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.

[00642] 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 withsrr 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. [00643] 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. [00644] Unless expressly specified otherwise, art 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 ail 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".

[00645] 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 fist are comprehensive of any category.

[00646] 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.

[00647] 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.

[00648] 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 daϊm, 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).

[00649] 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. [00650] 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 foe 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.

[00651] 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.

[00652] 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.