US20080090628A1

US20080090628A1 - Method and System to Allow for Inheritance between Characters in a Virtual Environment

Info

Publication number: US20080090628A1
Application number: US11/735,103
Authority: US
Inventors: Raymond Mueller; Andrew Van Luchene
Original assignee: Leviathan Entertainment LLC
Current assignee: Leviathan Entertainment LLC
Priority date: 2005-10-14
Filing date: 2007-04-13
Publication date: 2008-04-17

Abstract

A method and system are provided to allow inheritance between player characters. The method provides a player character with an ability to designate one or more character attributes acquired in a virtual environment to one or more other player characters. The inheritance method and system includes multiple options for gameplay, e.g. will creation, debt satisfaction, taxation, distribution.

Description

PRIORITY CLAIM

The following application claims priority to U.S. patent application Ser. No. 11/621,886, “Video Game with Reverse Outcome Game Attributes” filed Jan. 10, 2007, and 11/368,143, “Video Game Methods and Systems” filed Mar. 3, 2006, which claims the benefit of U.S. Provisional Patent Application No. 60/727,121 “Methods, Processes and Systems to Enhance a Player Experience of a Video Game” filed Oct. 14, 2005, each of which is hereby incorporated by reference.

BACKGROUND

Virtual Environments which are accessible to multiple subscribers via a server are well known. For example, hundreds of thousands of players access games known as massive multi player online games (MMOGs). Players of these games customarily access a game repeatedly (for durations typically ranging from a few minutes to several days) over 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. Virtual communities like Linden Lab's “Second Life” provide a three-dimensional metaverse in which people (who may or may not pay a fee for the right to access the metaverse) create avatars that are able to interact with other avatars as well as the local environment. It would be advantageous to provide improved methods and apparatus for increasing the enjoyment and/or longevity of these virtual environments.

SUMMARY OF THE INVENTION

The present invention provides a virtual environment with a gameplay method allowing for inheritance between player characters. According to a first aspect, the method provides gameplay by providing a first player character with an ability to designate one or more character attributes acquired in the virtual environment to another player character upon death of the first player character. The method further includes receiving a request to create a will from the first player character; identifying at least one character attribute of the first player character; receiving information from the first player character linking a second player character to a selected character attribute of the first player character, wherein the second player character becomes entitled to inherit the selected character attribute upon death of the first player character; and saving the information to a database.
According to a second aspect, the method provides gameplay by allowing inheritance of character attributes between player characters; upon death of a first player character, determining a second player character to be an inheritor entitled to receive at least one character attribute of the first player character; determining taxes on said at least one character attribute based on tax rules and conditions; and receiving taxes before releasing said at least one character attribute to the second player character.
In a third aspect of the present invention, a computer program embodied on a computer readable medium for providing a game environment includes an inheritance module for allowing a player character to transfer one or more character attributes to at least one inheritor after death of the player character; the inheritance module further including: a will module for identifying one or more character attributes and determining at least one inheritor; an accounting module for paying debts of the player character; and an attribute distribution module for distributing one or more character attributes of the player character to at least one inheritor.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a wide area network in which a virtual environment exists in one embodiment of the invention.
FIG. 2 is a schematic diagram of a wide area network in which a virtual environment exists in another embodiment of the invention.
FIG. 3 is a schematic diagram of one embodiment of an inheritance program in communication with a plurality of databases.
FIG. 4 is a flowchart illustrating one embodiment of a method for creating a will.
FIG. 5 is a flowchart illustrating one embodiment of a method for creating a default will.
FIG. 6 is a flowchart illustrating an inheritance program in accordance with one embodiment of the invention.
FIG. 7 is a flowchart illustrating details of step 126 of FIG. 6 in accordance with one embodiment of the invention.
FIG. 8 is a flowchart illustrating more details of step 126 of FIG. 6 in accordance with one embodiment of the invention.
FIG. 9 is a flowchart illustrating details of steps 128, 130, and 132 of FIG. 6 in accordance with one embodiment of the invention.

DETAILED DESCRIPTION

In one or more embodiments, the present invention provides a metaverse that allows for inheritance between player characters. When a player character dies (for example, as disclosed in U.S. patent application Ser. No. 11/735,082 entitled Method and System for Karma Accumulation, Death and Post-Death Gameplay in a Virtual Environment, hereby incorporated by reference in its entirety), one or more character attributes he acquired in the game may be transferred to other player characters in the game. Character attributes, as used herein, may include any quality, trait, feature or characteristic a particular player character can have that is stored in a corresponding player character account. Character attributes may include, but not be limited to: assets, character score, virtual object, physical appearance of a character, emblem or mark, synthetic voice, virtual money, virtual help points or credits, ability to join groups of other players at a later time, score for subsequent matching of later game parameters, relationship with another character, a genetic profile or makeup, karma points, etc. A character attribute may also be referred to as “game attribute”.
Referring to FIG. 1, a system 8 for inheritance includes a metaverse that may be created and maintained by a game program 10 residing in a video game central server 12 and/or video game consoles 14. As used herein, a metaverse may include a collection of online virtual environments which are accessible to one or more players of one or more online games or communities. For example, Massive Multiplayer Online Role Playing Games (MMORPGs) may include a virtual game environment generated by game program 10. In this game environment (referred to herein as “game”), players may access the game at video game consoles 14 via a wide area network 16. It should be understood, that the term “game” is intended to encompass any online or virtual environment in which players may interact with each other and/or the environment via characters or avatars. Unless specifically stated, the term “game” is not intended to limit the disclosure to only those environments that are competitive in nature. Accordingly, the term game is intended to encompass virtual communities such as Linden Labs' Second Life.
The game program includes an inheritance module 18, namely a piece of code allowing for inheritance between player characters. Inheritance module 18 may retrieve and store information in various databases 20. These databases may be located locally in the video game central server, in external servers and/or mass storage devices 22.
Video game consoles 14 may include a local version 24 of the game program 10. The local version 24 of the game program may include local player character accounts 26 and a local inheritance module 28 for access and/or communication with corresponding features in game program 10. A player located at a video game console 14 may have multiple player character accounts, each corresponding to a player character (persona) the player has created for playing the game. It should be noted that a person or entity who enters the metaverse, regardless of purpose, is considered to be “playing a game,” and therefore the person or entity is considered a “player.”
In FIG. 2, a peer-to-peer network is shown with a game program 10′ running on video game consoles 14′ in an alternate embodiment 8′ of a system for inheritance. Consoles 14′ communicate via a wide area network 16′ and have the ability to access databases 20′ that may be located in each console. An inheritance module 18′ is located in one or both game programs 10′, and similarly player character accounts 26′ reside in each console. Additional consoles may be connected and share information and resources accordingly.
Turning to FIG. 3, in accordance with one embodiment of the invention, a schematic diagram shows an inheritance program 18 including a will module 30 for identifying one or more character attributes and determining at least one inheritor; an accounting module 32 for paying debts of the player character; and an attribute distribution module 34 for distributing one or more character attributes of the player character to at least one inheritor. The methods and embodiments, as described below, may be implemented into the game, inheritance program, and/or modules. The inheritance program may require retrieving and storing of information in one or more databases, e.g., a player database 36, character database 38, attribute database 40, will database 42, and a tax database 44.
Player database 36 may include fields such as: player GUID 46, player billing info 48, player account type 50, and player character GUID 52. A GUID refers to a unique number for identifying a particular player, item, or other database entry. A player using a unique ID 46 may be identified and is linked to player billing information 48. The player account type 50 may indicate the kind of gameplay that is permissible. For example, the player may have paid an additional fee for enhanced features and needs to be indicated as such. The player character GUID 52 identifies and associates the player character with a player account.
In character database 38, the fields of character GUID 54, character attribute ID 56, character will ID 58, and character relationship 60 serve to identify the player character, his character attributes, his will, and his relationships including relatives and parties to contracts, respectively.
The attribute database 40 may include exemplary fields such as attribute ID 62, attribute type 64, attribute descriptor 66, and attribute value 68. The attribute ID 62 is used to identify the attribute. The attribute type 64 specifies what kind of attribute it is. For example, attribute types may be cash, food, tools, weapons, trinkets, armor, potions, spells, scrolls, quest objects, etc. The attribute descriptor 66 may be a word, phrase, or alphanumerical term to describe the attribute, an arbitrary code, or a search parameter. The attribute value 68 may be a virtual equivalent cash value or other value which may be used for calculation purposes within the inheritance program.
The will database 42 may include fields inheritor GUID 70, inheritor attribute 72, attribute condition 74, and will GUID 75. The inheritor GUID 70 serves to identify a player character (inheritor) who is selected via a will or default will to receive a character attribute, which may be inputted in the inheritor attribute field 72. The player character (will maker) specifies attribute conditions that need to be fulfilled before inheritance. The will GUID links the information.
The tax database 44 holds information such as: global tax rate 76, race tax rate 78, family tax rate 80, class tax rate 82, attribute type tax rate 84, character tax rate 86, tax rate rules 88, and tax rate conditions 90. The global, race, family, class, attribute type, and character tax rates store current rates and may change periodically depending on the region in which the character avatar is located. The tax rate rules 88 and tax rate conditions 90 are used to determine whether something needs to be taxed as well as at which applicable rate.
These databases may be interdependent, e.g., if one variable changes in the database, a variable in another databases may change automatically as well. Other databases and other fields within databases may be employed and are not limited to the schematics as shown in FIG. 3.
Referring to FIG. 4, a flowchart shows a method 90 for allowing the creation a will by a player character. In step 92, the method includes receiving a request to create a will. Generally, a player character can create a will at any point in the game. For example, there may be a prompt asking whether the player character wishes to create a will that arises due to the player character acquiring a new character attribute, achieving a milestone, etc. In another example, the player character can only create a will at an in-game marketplace after exchanging or purchasing character attributes and/or at other specific times or places.
In step 94, the method identifies character attributes belonging to the player character and in step 96, determines potential inheritors. In determining potential inheritors, the method may identify relatives from a family tree. In generating a list of relatives, the closeness of relationship of the family member may be provided to the player character. In one embodiment, the method may generate a default will as reference for the player character. In another embodiment, the method refers to a log to find records of other player characters that this player character has had contact with and has had relatively recent player account activity for a larger potential inheritor pool.
After being provided with potential inheritors, and having character attributes as reference, the player character may choose who he wants to inherit selected character attributes, and specify a condition that an inheritor must fulfill before he can acquire the attribute. The inheritor may be required to reach a certain level, complete a certain game parameter (i.e., any part of a game experience), or acquire a certain game attribute or object in order for the character attribute to be released to him. For example, the player character may leave his magic wand to his nephew, but only on the condition his nephew has a rabbit. At step 98, the method includes receiving a selected character attribute, inheritor(s), and condition(s) of inheritance, also referred to as “attribute condition”.
The player character may select more than one inheritor to inherit a character attribute. It will be treated as selecting a primary inheritor and a secondary inheritor as backup if the primary inheritor is not able to inherit. In an alternate embodiment, the selected inheritors may be treated as joint inheritors and share the character attribute. Further, as long as a character attribute and at least one inheritor or condition is specified, it is not necessary that both the inheritor and the condition be entered. If both are not specified or are invalid, the method may use a default will, as described below.
Method 90 may include, at 100, determining whether assignments and/or conditions are permissible as may be typically determined by governing rules. These rules are generally predetermined by a game designer (as used herein, a game designer may include a person who develops the game and/or sets rules of gameplay) or alternatively, a government with player character constituents. For example, a player character may be restricted to only assigning character attributes to other player characters (inheritors) who are in the same family, race, or class as the player character; other player characters who have a relationship with the player character established by a formalized contract (for example, as disclosed in U.S. patent application Ser. Nos. 11/279,991, 11/611,050, 11/355,232, and 11/624,662, each of which are hereby incorporated by reference); other player characters who have/are the appropriate karma, age, or other rating; other player characters who do not have a debt to a third player character, combinations of the above, etc. In another embodiment, the governing rules permit other player characters to overcome certain restrictions before the player character's death or other predetermined time. In another embodiment, the governing rules do not preclude a player character from assigning character attributes to other player characters without established relationships. For example, the player character is permitted to assign character attributes to a randomly-selected charity.
If the assignment and/or condition is determined to be non-compliant, method 90 proceeds to give a warning at 102 before moving to step 104. Alternatively, method 90 precludes the player character from proceeding until a valid assignment or condition is entered.
In step 104, the method links the character attribute(s), inheritor(s), and/or the condition(s) of inheritance. Method 90 includes entering this information into the will database at 106 and updating accordingly.
Referring to FIG. 5, a method 108 for creating a default will is shown. At 110, the method includes identifying character attributes not linked to an inheritor. At 112, the method includes determining player characters eligible for inheritance, including compliance with governing rules. This may be done by constructing or accessing a family tree. Method 108 includes, at 114, using a succession algorithm to determine inheritors. For example, the eldest offspring is to receive all character attributes. The succession algorithm is discussed in more detail below. At 116, character attribute(s), inheritor(s), and/or default condition(s) of inheritance are linked, and at step 118, updated in the will database.
FIG. 6 shows a flowchart illustrating one embodiment of an inheritance program for a game at 144. At step 120, the inheritance program includes receiving an indication that the player character died. At 122, the program identifies character attributes belonging to the deceased player character. In an alternate embodiment, the program includes a step of retrieving the character attributes and immediately placing them in escrow. The program may wait and require a request from an inheritor to redeem a character attribute. Back at step 124, program 144 further includes determining inheritors and/or attribute conditions. In this step, the program may use a will module and/or access a will database to obtain information linking character attributes to inheritors and attribute conditions.
At step 126, the program includes determining rules and conditions. Referring to FIGS. 7 and 8, step 126 is expanded in detail. Step 126 includes determining whether the inheritors and/or attribute conditions are in accordance with governing rules at 146. If yes, the inheritors and/or attribute conditions are compliant, move to step 148 and proceed to an accounting method in FIG. 8. If no, the invalid inheritors and/or attribute conditions are deleted in step 150 and substituted with default selections, as generated through the method shown in FIG. 5.
FIG. 8 shows an accounting method or module 152 including a valuation of character attributes submodule 154, satisfaction of debt submodule 156, and inheritor taxation submodules 158. Valuation of character attributes includes a step 160 of determining a virtual equivalent cash value of the character attributes. In an alternate embodiment, step 160 may be used within other modules at different times as needed. The virtual equivalent cash value of each character attribute may be determined by a game designer, fair market value within the virtual environment, length of time owned or held by the player character, rarity, difficulty of obtaining, etc.
Submodule 156 settles the debt of the deceased player character first before distribution of any character attributes. In an alternate embodiment, there may be exceptions due to the nature of the character attribute, where the character attribute cannot be held in escrow for an extended period of time, and therefore an inheritor is allowed to retrieve the character attribute.
In step 162, submodule 156 includes determining debts and encumbrances. Any promissory notes and personal debts should be paid off, and title should be cleared from all character attributes. There may be a priority list for debt repayment. At step 164, the submodule includes determining an order of character attributes to use to pay off debts. Typically, the character attribute of money or currency is used first before selling objects. The system automatically withholds the tax and the cash is ready for distribution to the inheritor. This step may weigh other consideration, such as if the player character had a will. For example, if there is a choice between selling one of two character attributes and one of them was designated for an inheritor, then that character attribute would not be sold, if possible. As an alternative, the player character is permitted to specify the order of character attributes to use to pay off debts. In another alternative, the system may follow an order of selling from the least costly character attribute to the most costly, or selling from the most recently-acquired character attribute to the longest-held.
When the debt ends up greater than the value of the character attributes, all the character attributes are liquidated and used to pay debt. There may be no inheritance for other player characters. In an alternate embodiment, the inheritors may still be notified and given a chance to inherit a character attribute that was willed to the inheritor. In this circumstance, the inheritor is required to pay for the character attribute, and other applicable fees.
At 166, the submodule includes liquidating character attributes up to the debt amount and at 168, paying off debts of the player character. At 170, the submodule includes determining remaining character attributes. For example, a player character who does not have any debts would still have the same number of remaining character attributes as he did when he died.
At 172, a determination needs to be made regarding whether a tax has been assessed. If the tax has not been assessed, the submodule moves to step 174 in determining tax rules and conditions based on remaining character attributes. For example, if taxation is on a per attribute basis and the player character has amassed a large number of character attributes, his account may be required to pay a substantial tax. Taxation may be assessed against a portion or all of the player character's game attributes upon his death. For example, all game attributes are taxed except for food items. In another example, regardless of attribute type, all game attributes are taxed at predetermined percentage of the virtual equivalent cash value of the game attributes.
At step 176, a determination of the tax due is made and the amount is treated as a debt. The method returns to step 166 to pay the debt. Typically, the amount of tax due is determined based on a certain percentage of the virtual equivalent cash value of the remaining character attributes. This percentage may vary depending on governing rules, e.g. place where player character died. If the remaining character attributes are worth very little, this tax may not be assessed. In an alternate embodiment, this tax is not assessed regardless of the value of the character attributes. At 172, since the tax was already previously assessed, proceed to step 178 for updating the databases.
In the inheritor taxation submodule 158, computation of inheritance tax is performed. The submodule includes at 180, identifying remaining character attributes and corresponding linked inheritor(s); at 182, determining tax rules and conditions for inheritance; at 184, determining taxes due from inheritor(s); and at 186, placing character attributes in the deceased player character's escrow with tax payment conditions. Rules for inheritance tax typically are dependent on a predetermined percentage of the virtual equivalent cash value.
Returning to FIG. 6, the inheritance program 144 includes, at 128, providing notification to inheritors, at 130, determining whether conditions are satisfied, and at 132, determining where character attributes go. These steps are shown in more detail in FIG. 9. Referring now to the figure, step 128 provides notification by retrieving a linked inheritor of a character attribute at step 188. Step 128 may further include, at step 190, notifying the inheritor of origin and other general miscellaneous information about the character attribute, e.g. the name of the player character who died. Step 128 further includes notifying the inheritor of tax payment conditions at step 192. At 194, the inheritor may be notified of attribute conditions which the deceased player character has imposed.
At step 196, step 128 provides the inheritor with options. For example, options may include: immediately claiming the character attribute by paying the tax due; if the inheritor cannot pay the inheritance tax or has not satisfied an attribute condition, paying a fee to extend a deadline; selling the item and collecting the selling price less the tax percentage; refusing the inheritance; requesting a summary or status of the distribution of the player character game attributes; initiating a will contest; etc. In an alternate embodiment, step 128 notifies linked inheritors to character attributes that were sold to pay off debt. Since these inheritors receive nothing, they may wish to contest the will in an attempt to achieve a different outcome for character attribute distribution.
It should be noted that in another embodiment, other player characters can contest a will and the deceased player character attributes 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, e.g. dice rolling, drawing straws, etc.
Returning to determining whether conditions are satisfied, step 130 includes, at step 198, checking for receipt of tax for character attribute. If an inheritor has not paid the tax, the program continues to step 200 in which the character attribute is left in escrow, and to step 202, which returns to step 136 of the inheritance program. If the inheritor has paid the tax, step 198 advances to step 204 where a determination is made concerning whether attribute conditions have been satisfied. If no, attribute conditions have not been satisfied, the character attribute remains in escrow in step 200. The method returns to step 136 of FIG. 6. If yes, the program continues to step 132 to determine where character attributes go.
In an alternate embodiment, if the attribute conditions have been satisfied, but the tax has not been paid, the method releases the character attribute to the inheritor. However, the inheritor will have a tax lien on the property. Alternatively, the method sends the character attribute to escrow for the inheritor until the inheritor pays tax to redeem the character attribute. The character attribute is then considered disposed of properly and no longer considered part of the deceased player character's estate.
In determining where character attributes go, step 132 includes a step 206 that automatically distributes character attributes to any third party owed by the inheritor. In one embodiment, the inheritor can encumber a character attribute that was a specific bequest to him. For example, the inheritor can take a loan from a third party player by using the character attribute as collateral. If the inheritor cannot repay the loan, the third party player is entitled to the character attribute as satisfaction of the loan. In another embodiment, the inheritor can determine the order of debt repayment. Step 206 may follow the predetermined order or take it into account in distributing the remaining character attributes. In another embodiment, the game can automatically use character attributes to offset debts (partial repayment of debts), or alternatively, a player character can use attributes he has inherited to offset debts without system intervention. A notification to the third party may be generated to accompany the character attribute and/or debt repayment.
At step 208, step 132 includes releasing the character attribute to the inheritor. At this point, the character attribute belongs to the inheritor and is then recorded as such in the database(s) at step 134 of FIG. 6.
Turning back to FIG. 6, the inheritance program includes step 136 to determine whether there are any remaining character attributes held in escrow for the deceased player character. If yes, the method moves to step 138 to listen. There may be requests for character attributes from inheritors. For example, an inheritor who previously could not satisfy an attribute condition, but now could, may ask to redeem the character attribute. At step 140, the method includes receiving a request for a character attribute from an inheritor and returns to step 130 for determining whether conditions have been satisfied, and continues accordingly until step 136 determines that there are no more character attributes in the player character's escrow, then the inheritance program ends at step 142. Alternatively, the step of listening at 138 may include a time-out mechanism that exits the program upon expiration of a predetermined amount of time.
There are many other variations of inheritance gameplay falling within the scope of the invention, some of which are further described below.
In one embodiment, taxes can be assessed 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 the government to improve shared attributes in the game environment, to finance a war, or to fund public interest projects. Taxation schemes for a virtual environment are discussed, for example, in U.S. patent application Ser. No. 11/696,080, “System and Method to Levy and Collect Taxes in a Virtual Environment,” filed Apr. 3, 2007, which is hereby incorporated by reference.
In another embodiment, as a form of inheritance insurance, players could pay an extra fee or premium to the game server and/or change player attributes to assure that their characters can inherit character attributes from their parents and/or other relatives. Player characters may also forego certain character attributes to guarantee inheritance. Player-to-player contracts allowing automatically transfer of acquired game attributes, such as a will contract, may also be formed.
In another embodiment, the game may be configured to provide for a situation in which something happens to a player character such that the character is no longer considered “alive,” for a period of the game, e.g. the player character is possessed by an undead character, becomes a vampire, becomes a zombie, etc. In such a case, the player character's game attributes could be distributed to his family based on his will, held by the game server, remain with the player character, or transfer all or a portion of his character attributes over to the undead character or the undead character's family.
In another embodiment, if no will is established, all character attributes are auctioned off and the attributes go to the government of which the player character was a member or where the player character died. Alternatively, the character attributes of the deceased player character may be distributed by chance or lottery. In such a case, any other player character, regardless of class, status or other attributes, may inherit some or all of such assets.
As another alternative, a default will using any succession algorithms to determine inheritors may be employed. For example, character attributes may be divided based upon a ratio that favors those relatives that are closest in relation to the deceased player character's family tree. In another example, character attributes may be divided equally among all relatives. As yet another alternative or in addition to the previously described division of attributes, the game server or peer-to-peer network may randomly or predictably decide to distribute a portion or all of an estate to a group of players based on any number of factors including, but not limited to, a player's race, nationality, friendships or other non-blood or marital relationships formed in the game, etc.
The default will's succession algorithm may follow any of the hereditary succession models to determine who inherits a character attribute. Hereditary succession models may include male or female primogeniture, seniority, partible inheritance, proximity of blood, ultimogeniture, distribution per capita, distribution by represention, etc.
According to some embodiments, the entity able to distribute attributes based on a virtual will may be limited to a particular player character or non-player character or a particular type of player character or non-player character. For example, in some embodiments, only judges or attorneys may be able to distribute attributes based on a virtual will. In other embodiments, only a particular one or set of judges or attorneys may be able to distribute attributes based on a virtual will.
In another embodiment, where there are no identifiable or eligible inheritors, the character attributes may be distributed to the local government of where the player character died, or where the character attributes are located. Alternatively, the character attributes may be destroyed or held in escrow indefinitely.
In an alternate embodiment, the limitations and constraints of the inheritance system may vary from region to region within the metaverse. For example, the succession model used in a default generally follow the rules of the region where the player character dies. In another example, within certain regions, the player character creating a will cannot assign his character attributes to a player character outside of his race and/or class. In another example, a local government controlled by other player characters may set absurdly high tax rates. In another example, in male primogeniture societies, females may be discouraged or precluded from inheriting at all, and the character attribute may be heavily taxed to a female inheritor.
In another embodiment, it may be possible for a player character to assign character attributes to himself as an inheritor. For example, if he re-enters the game as the reincarnated child of his own offspring, he may inherit the character attributes as long as he fulfills all the conditions for inheritance.
In another embodiment, prior to the player character's death, character attributes linked to an inheritor that are sold, used up by the player character, or otherwise no longer in the player character's possession may be immediately removed from and updated in the will database periodically, or at certain checkpoints in the game. Notification may be provided to the inheritor. Alternatively, once the will is created, the will remains intact and unchanged, and the missing character attribute has no effect on gameplay while the player character is alive.
In another embodiment, the player character can determine where his character attributes go after his death. For example, there may be a limited period of time where the player character can settle his affairs and oversee the distribution of his character attributes, with partial or no system intervention or constraints.
According to another embodiment, various events related to inheritance may be relayed to affected individuals via an alert system. A suitable alert system is described, for example, in U.S. patent application Ser. No. 11/676,848 “Virtual Environment with Alerts” filed Feb. 20, 2007, which is hereby incorporated by reference. For example, news of a player's death, will reading, inheritance, etc. could all be relayed via an alerts system. The parties to whom the information is relayed may include, for example, family members, whether or not they will inherit, heirs, and various community members, whether or not they will inherit.
Furthermore, an alert system such as that described in U.S. patent application Ser. No. 11/676,848 could be employed during a dispute over a will.
In addition, an alert system could be used to notify players when inherited items are available to transferred to an account.
The term “product” means any machine, manufacture and/or composition of matter, unless expressly specified otherwise.
The term “process” means any process, algorithm, method or the like, unless expressly specified otherwise.
Each process (whether called a method, algorithm or otherwise) inherently includes one or more steps, and therefore all references to a “step” or “steps” of a process have an inherent antecedent basis in the mere recitation of the term ‘process’ or a like term. Accordingly, any reference in a claim to a ‘step’ or ‘steps’ of a process has sufficient antecedent basis.
The terms “an embodiment”, “embodiment”, “embodiments”, “the embodiment”, “the embodiments”, “one or more embodiments”, “some embodiments”, “certain embodiments”, “one embodiment”, “another embodiment” and the like mean “one or more (but not all) embodiments of the disclosed invention(s)”, unless expressly specified otherwise.
The term “variation” of an invention means an embodiment of the invention, unless expressly specified otherwise.
A reference to “another embodiment” in describing an embodiment does not imply that the referenced embodiment is mutually exclusive with another embodiment (e.g., an embodiment described before the referenced embodiment), unless expressly specified otherwise.
The terms “including”, “comprising” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.
The term “consisting of” and variations thereof mean “including and limited to”, unless expressly specified otherwise.
The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.
The term “plurality” means “two or more”, unless expressly specified otherwise.
The term “herein” means “in this patent application, including anything which may be incorporated by reference”, unless expressly specified otherwise.
The phrase “at least one of”, when such phrase modifies a plurality of things (such as an enumerated list of things) means any combination of one or more of those things, unless expressly specified otherwise. For example, the phrase “at least one of a widget, a car and a wheel” means either (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car, (v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, a car and a wheel.
Numerical terms such as “one”, “two”, etc. when used as cardinal numbers to indicate quantity of something (e.g., one widget, two widgets), mean the quantity indicated by that numerical term, but do not mean at least the quantity indicated by that numerical term. For example, the phrase “one widget” does not mean “at least one widget”, and therefore the phrase “one widget” does not cover, e.g., two widgets.
The phrase “based on” does not mean “based only on”, unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on”.
The term “represent” and like terms are not exclusive, unless expressly specified otherwise. For example, the term “represents” 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”.
The term “whereby” is used herein only to precede a clause or other set of words that express only the intended result, objective or consequence of something that is previously and explicitly recited. Thus, when the term “whereby” is used in a claim, the clause or other words that the term “whereby” modifies do not establish specific further limitations of the claim or otherwise restricts the meaning or scope of the claim.
The term “e.g.” and like terms means “for example”, and thus does not limit the term or phrase it explains. For example, in the sentence “the computer sends data (e.g., instructions, a data structure) over the Internet”, the term “e.g.” explains that “instructions” are an example of “data” that the computer may send over the Internet, and also explains that “a data structure” is an example of “data” that the computer may send over the Internet. However, both “instructions” and “a data structure” are merely examples of “data”, and other things besides “instructions” and “a data structure” can be “data”.
The term “determining” and grammatical variants thereof (e.g., to determine a price, determining a value, determine an object which meets a certain criterion) is used in an extremely broad sense. The term “determining” encompasses a wide variety of actions and therefore “determining” can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” can include resolving, selecting, choosing, establishing, and the like.
The term “determining” does not imply certainty or absolute precision, and therefore “determining” can include estimating, predicting, guessing and the like.
The term “determining” does not imply that mathematical processing must be performed, and does not imply that numerical methods must be used, and does not imply that an algorithm or process is used.
The term “determining” does not imply that any particular device must be used. For example, a computer need not necessarily perform the determining.
It will be readily apparent to one of ordinary skill in the art that the various processes described herein may be implemented by, e.g., appropriately programmed general purpose computers and computing devices. Typically a processor (e.g., one or more microprocessors, one or more microcontrollers, one or more digital signal processors) will receive instructions (e.g., from a memory or like device), and execute those instructions, thereby performing one or more processes defined by those instructions.
A “processor” means one or more microprocessors, central processing units (CPUs), computing devices, microcontrollers, digital signal processors, or like devices or any combination thereof.
Thus a description of a process is likewise a description of an apparatus for performing the process. The apparatus can include, e.g., a processor and those input devices and output devices that are appropriate to perform the method.
Further, programs that implement such methods (as well as other types of data) may be stored and transmitted using a variety of media (e.g., computer readable media) in a number of manners. In some embodiments, hard-wired circuitry or custom hardware may be used in place of, or in combination with, some or all of the software instructions that can implement the processes of various embodiments. Thus, various combinations of hardware and software may be used instead of software only.
The term “computer-readable medium” refers to any medium that participates in providing data (e.g., instructions, data structures) which may be read by a computer, a processor or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying data (e.g. sequences of instructions) to a processor. For example, data may be (i) delivered from RAM to a processor; (ii) carried over a wireless transmission medium; (iii) formatted and/or transmitted according to numerous formats, standards or protocols, such as Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP, TDMA, CDMA, and 3G; and/or (iv) encrypted to ensure privacy or prevent fraud in any of a variety of ways well known in the art.
Thus a description of a process is likewise a description of a computer-readable medium storing a program for performing the process. The computer-readable medium can store (in any appropriate format) those program elements which are appropriate to perform the method.
Just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of an apparatus include a computer/computing device operable to perform some (but not necessarily all) of the described process.
Likewise, just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of a computer-readable medium storing a program or data structure include a computer-readable medium storing a program that, when executed, can cause a processor to perform some (but not necessarily all) of the described process.
Where databases are described, it will be understood by one of ordinary skill in the art that (i) alternative database structures to those described may be readily employed, and (ii) other memory structures besides databases may be readily employed. Any illustrations or descriptions of any sample databases presented herein are illustrative arrangements for stored representations of information. Any number of other arrangements may be employed besides those suggested by, e.g., tables illustrated in drawings or elsewhere. Similarly, any illustrated entries of the databases represent exemplary information only; one of ordinary skill in the art will understand that the number and content of the entries can be different from those described herein. Further, despite any depiction of the databases as tables, other formats (including relational databases, object-based models and/or distributed databases) are well known and could be used to store and manipulate the data types described herein. Likewise, object methods or behaviors of a database can be used to implement various processes, such as the described herein. In addition, the databases may, in a known manner, be stored locally or remotely from any device(s) which access data in the database.
Various embodiments can be configured to work in a network environment including a computer that is in communication (e.g., via a communications network) with one or more devices. The computer may be connected to 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.
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.
Of course, it will be appreciated that the systems and 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.
The invention is described with reference to multiple 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. Accordingly, the subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various systems, methods and configurations, and other features, functions, and/or properties disclosed herein.
Where a limitation of a first claim would cover one of a feature as well as more than one of a feature (e.g., a limitation such as “at least one widget” covers one widget as well as more than one widget), and where in a second claim that depends on the first claim, the second claim uses a definite article “the” to refer to the limitation (e.g., “the widget”), this does not imply that the first claim covers only one of the feature, and this does not imply that the second claim covers only one of the feature (e.g., “the widget” can cover both one widget and more than one widget).
Each claim in a set of claims has a different scope. Therefore, for example, where a limitation is explicitly recited in a dependent claim, but not explicitly recited in any claim from which the dependent claim depends (directly or indirectly), that limitation is not to be read into any claim from which the dependent claim depends.
When an ordinal number (such as “first”, “second”, “third” and so on) is used as an adjective before a term, that ordinal number is used (unless expressly specified otherwise) merely to indicate a particular feature, such as to distinguish that particular feature from another feature that is described by the same term or by a similar term. For example, a “first widget” may be so named merely to distinguish it from, e.g., a “second widget”. Thus, the mere usage of the ordinal numbers “first” and “second” before the term “widget” does not indicate any other relationship between the two widgets, and likewise does not indicate any other characteristics of either or both widgets. For example, the mere usage of the ordinal numbers “first” and “second” before the term “widget” (1) does not indicate that either widget comes before or after any other in order or location; (2) does not indicate that either widget occurs or acts before or after any other in time; and (3) does not indicate that either widget ranks above or below any other, as in importance or quality. In addition, the mere usage of ordinal numbers does not define a numerical limit to the features identified with the ordinal numbers. For example, the mere usage of the ordinal numbers “first” and “second” before the term “widget” does not indicate that there must be no more than two widgets.
When a single device or article is described herein, more than one device/article (whether or not they cooperate) may alternatively be used in place of the single device/article that is described. Accordingly, the functionality that is described as being possessed by a device may alternatively be possessed by more than one device/article (whether or not they cooperate).
Similarly, where more than one device or article is described herein (whether or not they cooperate), a single device/article may alternatively be used in place of the more than one device or article that is described. For example, a plurality of computer-based devices may be substituted with a single computer-based device. Accordingly, the various functionality that is described as being possessed by more than one device or article may alternatively be possessed by a single device/article.
The functionality and/or the features of a single device that is described may be alternatively embodied by one or more other devices which are described but are not explicitly described as having such functionality/features. Thus, other embodiments need not include the described device itself, but rather can include the one or more other devices which would, in those other embodiments, have such functionality/features.
Numerous embodiments are described in this patent application, and are presented for illustrative purposes only. The described embodiments are not, and are not intended to be, limiting in any sense. The presently disclosed invention(s) are widely applicable to numerous embodiments, as is readily apparent from the disclosure. One of ordinary skill in the art will recognize that the disclosed invention(s) may be practiced with various modifications and alterations, such as structural, logical, software, and electrical modifications. Although particular features of the disclosed invention(s) may be described with reference to one or more particular embodiments and/or drawings, it should be understood that such features are not limited to usage in the one or more particular embodiments or drawings with reference to which they are described, unless expressly specified otherwise.
The present disclosure is neither a literal description of all embodiments of the invention nor a listing of features of the invention which must be present in all embodiments.
Neither the Title (set forth at the beginning of the first page of this patent application) nor the Abstract (set forth at the end of this patent application) is to be taken as limiting in any way as the scope of the disclosed invention(s). An Abstract has been included in this application merely because an Abstract of not more than 150 words is required under 37 C.F.R. § 1.72(b).
The title of this patent application and headings of sections provided in this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.
Devices that are described as in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. On the contrary, such devices need only transmit to each other as necessary or desirable, and may actually refrain from exchanging data most of the time. For example, a machine in communication with another machine via the Internet may not transmit data to the other machine for long period of time (e.g. weeks at a time). In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.
A description of an embodiment with several components or features does not imply that all or even any of such components/features are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention(s). Unless otherwise specified explicitly, no component/feature is essential or required.
Although process steps, algorithms or the like may be described in a sequential order, such processes may be configured to work in different orders, and may be included in modules different from what was described. 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. To illustrate as an example, the step of notification to inheritors may occur multiple times due to notifications given to apprise the inheritor of status in the inheritance process. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to the invention, and does not imply that the illustrated process is preferred.
Although a process may be described as including a plurality of steps, that does not imply that all or any of the steps are essential or required. Various other embodiments within the scope of the described invention(s) include other processes that omit some or all of the described steps. Unless otherwise specified explicitly, no step is essential or required. For example, the step of notification to inheritors is not necessary in a situation where there are no inheritors available. In another example, if tax collection is not utilized or implemented in the virtual environment, tax-related steps are not applicable and should not be considered part of the method or program.
Although a product may be described as including a plurality of components, aspects, qualities, characteristics and/or features, that does not indicate that all of the plurality are essential or required. Various other embodiments within the scope of the described invention(s) include other products that omit some or all of the described plurality.
Unless expressly specified otherwise, an enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are mutually exclusive. Therefore it is possible, but not necessarily true, that something can be considered to be, or fit the definition of, two or more of the items in an enumerated list. Also, an item in the enumerated list can be a subset (a specific type of) of another item in the enumerated list. For example, the enumerated list “a computer, a laptop, a PDA” does not imply that any or all of the three items of that list are mutually exclusive—e.g., an item can be both a laptop and a computer, and a “laptop” can be a subset of (a specific type of) a “computer”.
Likewise, unless expressly specified otherwise, an enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are collectively exhaustive or otherwise comprehensive of any category. For example, the enumerated list “a computer, a laptop, a PDA” does not imply that any or all of the three items of that list are comprehensive of any category.
Further, an enumerated listing of items does not imply that the items are ordered in any manner according to the order in which they are enumerated.
In a claim, a limitation of the claim which includes the phrase “means for” or the phrase “step for” means that 35 U.S.C. § 112, paragraph 6, applies to that limitation.
In a claim, a limitation of the claim which does not include the phrase “means for” or the phrase “step for” means that 35 U.S.C. § 112, paragraph 6 does not apply to that limitation, regardless of whether that limitation recites a function without recitation of structure, material or acts for performing that function. For example, in a claim, the mere use of the phrase “step of” or the phrase “steps of” in referring to one or more steps of the claim or of another claim does not mean that 35 U.S.C. § 112, paragraph 6, applies to that step(s).
With respect to a means or a step for performing a specified function in accordance with 35 U.S.C. § 112, paragraph 6, the corresponding structure, material or acts described in the specification, and equivalents thereof, may perform additional functions as well as the specified function.
Computers, processors, computing devices and like products are structures that can perform a wide variety of functions. Such products can be operable to perform a specified function by executing one or more programs, such as a program stored in a memory device of that product or in a memory device which that product accesses. Unless expressly specified otherwise, such a program need not be based on any particular algorithm, such as any particular algorithm that might be disclosed in this patent application. It is well known to one of ordinary skill in the art that a specified function may be implemented via different algorithms, and any of a number of different algorithms would be a mere design choice for carrying out the specified function.
Therefore, with respect to a means or a step for performing a specified function in accordance with 35 U.S.C. § 112, paragraph 6, structure corresponding to a specified function includes any product programmed to perform the specified function. Such structure includes programmed products which perform the function, regardless of whether such product is programmed with (i) a disclosed algorithm for performing the function, (ii) an algorithm that is similar to a disclosed algorithm, or (iii) a different algorithm for performing the function.
The present disclosure provides, to one of ordinary skill in the art, an enabling description of several embodiments and/or inventions. Some of these embodiments and/or inventions may not be claimed in this patent application, but may nevertheless be claimed in one or more continuing applications that claim the benefit of priority of this patent application. Applicants intend to file additional applications to pursue patents for subject matter that has been disclosed and enabled but not claimed in this patent application.

Claims

1. A method of providing gameplay in a virtual environment comprising:

providing a first player character with an ability to designate one or more character attributes acquired in the virtual environment to another player character upon death of the first player character by:

receiving a request to create a will from the first player character;

identifying at least one character attribute of the first player character;

receiving information from the first player character linking a second player character to a selected character attribute of the first player character, wherein the second player character becomes entitled to inherit the selected character attribute upon death of the first player character; and

saving the information to a database.

2. The method of claim 1, wherein the information includes an attribute condition that must be fulfilled before the second player can inherit the selected character attribute.

3. The method of claim 1, whereby providing the first player character with the ability to distribute one or more character attributes further includes receiving information from the first player character linking a third player character to the selected character attribute, wherein the third player character is entitled to inherit the selected character attribute upon failure of the second player character to inherit.

4. The method of claim 1, wherein the second player character is required to be related to the first player character.

5. The method of claim 4, wherein the second player character is related by a contractual relationship.

6. The method of claim 1, wherein the second player character is required to be from the same race as the first player character.

7. The method of claim 1, wherein the second player character is required to be from the same class as the first player character.

8. The method of claim 1, further comprising providing an ability to distribute one or more character attributes acquired in the virtual environment to another player character upon death of the first player character by creating a default will.

9. The method of claim 8, wherein creating a default will includes using a succession algorithm to determine inheritors.

10. A computer program embodied on a computer readable medium for providing a game environment comprising:

an inheritance module for allowing a player character to transfer one or more character attributes to at least one inheritor after death of the player character; the inheritance module further comprising:

a will module for identifying one or more character attributes and determining at least one inheritor;

an accounting module for paying debts of the player character; and

an attribute distribution module for distributing one or more character attributes of the player character to at least one inheritor.

11. The computer program of claim 10, wherein the accounting module further includes liquidating character attributes to pay debts of the player character.

12. The computer program of claim 11, wherein the accounting module further includes determining an order of character attributes to liquidate to pay debts of the player character.

13. The computer program of claim 10, wherein paying debts of the player character occurs before distributing one or more character attributes of the player character to at least one inheritor.

14. The computer program of claim 10, wherein the accounting module further includes determining taxes.

15. The computer program of claim 10, wherein the will module further includes linking one or more character attributes to at least one inheritor.

16. The computer program of claim 15, wherein the will module further includes:

receiving at least one attribute condition specified for a selected character attribute linked with at least one inheritor; and

linking said at least one attribute condition to the selected character attribute linked with said at least one inheritor.

17. The computer program of claim 10, wherein the will module further includes linking a plurality of inheritors to one character attribute.

18. A method of providing gameplay in a virtual environment comprising:

allowing inheritance of character attributes between player characters;

upon death of a first player character, determining a second player character to be an inheritor entitled to receive at least one character attribute of the first player character;

determining taxes on said at least one character attribute based on tax rules and conditions; and

receiving taxes before releasing said at least one character attribute to the second player character.

19. The method of claim 18 wherein determining taxes includes determining a virtual equivalent cash value of said at least one character attribute.

20. The method of claim 18 wherein taxes are paid out of an account of the first player character.