New! View global litigation for patent families

US20070293319A1 - Transfer of Features Between Gaming Devices - Google Patents

Transfer of Features Between Gaming Devices Download PDF

Info

Publication number
US20070293319A1
US20070293319A1 US11425258 US42525806A US2007293319A1 US 20070293319 A1 US20070293319 A1 US 20070293319A1 US 11425258 US11425258 US 11425258 US 42525806 A US42525806 A US 42525806A US 2007293319 A1 US2007293319 A1 US 2007293319A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
gaming
devices
device
features
feature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11425258
Inventor
Timothy Stamper
Paul Machacek
Christopher Stamper
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/77Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/12Video games, i.e. games using an electronically generated display having two or more dimensions involving interaction between a plurality of game devices, e.g. transmisison or distribution systems
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/75Enforcing rules, e.g. detecting foul play or generating lists of cheating players
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/06Buying, selling or leasing transactions
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/552Details of game data or player data management for downloading to client devices, e.g. using OS version, hardware or software profile of the client device
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5526Game data structure
    • A63F2300/5533Game data structure using program state or machine event data, e.g. server keeps track of the state of multiple players on in a multiple player game
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5586Details of game data or player data management for enforcing rights or rules, e.g. to prevent foul play
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60Methods for processing data by generating or executing the game program
    • A63F2300/609Methods for processing data by generating or executing the game program for unlocking hidden game elements, e.g. features, items, levels

Abstract

A method of connecting gaming devices together is described which enables multi-party gaming between devices with different feature sets. A device receives data from several gaming devices and determines which features each gaming device requires These required features are those which are not held at the particular device but are held by one or more of the other devices. Code relating to the particular features required by each gaming device is then transferred to each of the gaming devices.

Description

    BACKGROUND
  • [0001]
    Games consoles, such as Xbox 360™, have been developed which enable a gamer to play games with other gamers over a network. Typically the game play is controlled by a server although the software for running the game resides on the individual games consoles. In order for a group of gamers to play a game together over the network (also referred to a live game or an online game), each gamer must have a license for the game (e.g. obtained when the game is purchased on a disc or downloaded) and each gamer must have the same features for that game. Where gamers have different feature sets, they cannot play an online game together because it would result in their games console receiving data that it cannot interpret. The problem is exacerbated by the increasing ability of gamers to purchase additional levels, weapons etc for a game, for example through micropayments.
  • SUMMARY
  • [0002]
    The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
  • [0003]
    A method of connecting gaming devices together is described which enables multi-party gaming between devices with different feature sets. A device receives data from several gaming devices and determines which features each gaming device requires. These required features are those which are not held at the particular device but are held by one or more of the other devices. Code relating to the particular features required by each gaming device is then transferred to each of the gaming devices.
  • DESCRIPTION OF THE DRAWINGS
  • [0004]
    The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
  • [0005]
    FIG. 1 is a schematic diagram of a network of gaming devices;
  • [0006]
    FIG. 2 shows an example flow diagram of the operation of a server;
  • [0007]
    FIGS. 3 & 4 show example flow diagrams of steps of the flow diagram in FIG. 2 in more detail;
  • [0008]
    FIG. 5 shows the virtual positions of many characters in a game world;
  • [0009]
    FIG. 6 shows an example flow diagram of a method of limiting the transfer of features;
  • [0010]
    FIG. 7 shows an example flow diagram of a step of the flow diagram in FIG. 2 in more detail;
  • [0011]
    FIG. 8 shows a schematic diagram of a console;
  • [0012]
    FIG. 9 shows an example flow diagram for the purging of data;
  • [0013]
    FIG. 10 shows a schematic diagram of a server; and
  • [0014]
    FIG. 11 is a schematic diagram of another network of gaming devices.
  • [0015]
    Like reference numerals are used to designate like parts in the accompanying drawings.
  • DETAILED DESCRIPTION
  • [0016]
    The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
  • [0017]
    As described above, gamers with different feature sets are currently prevented from playing an online game together because it would result in their games console receiving data that it cannot interpret. The problem of mis-matched feature sets is exacerbated by the increasing ability of gamers to purchase additional features, such as additional levels, weapons etc and the ability of gamers to create their own custom features (egg. avatars, custom vehicles, custom landscapes etc). In addition to gamers purchasing additional software features, gamers may also purchase additional peripherals for their gaming devices (e.g. guns etc).
  • [0018]
    FIG. 1 is a schematic diagram of a network 100 of gaming devices. The network comprises four gaming devices 101 (e.g. Xbox 360™) connected together via a server 102 (e.g. an Xbox Live® Server). Each gaming device comprises a console 103, a display 104 and a controller 105. The connections may be wired or wireless, direct or indirect (e.g. over the internet). It will be appreciated that a network may comprise more or fewer devices and that each device may have one or more controllers connected to it, with different gamers using different controllers to play the same game. The operation of the server 102 can be described with reference to FIG. 2. The server receives requests from each of the gaming devices 103 to join a game (step 201) and in response to these requests, the server polls each of the gaming devices for attribute information pertaining to the game in question. The attribute information may include details of levels, weapons, avatars and other features of the game (step 202). Having received the attribute information, the server determines the differences in feature sets held by each of the devices (step 203) and transfers the required features to each console such that they have a common feature set (step 204). Once each gaming device has the same feature set, the game can start (not shown in FIG. 2)
  • [0019]
    In an example, a common scripting language may be used to transfer the features. In another example, XML (extensible mark-up language) may be used as an interface for sharing attribute information between gaming devices.
  • [0020]
    In some situations, for example where gamers have created their own features (such as new personalized avatars) or where gamers have purchased third party software or hardware (e.g. a gun, a steering wheel etc), the server may not have the required code to enable it to distribute the code to the gaming devices without it. In such a situation, (as shown in FIGS. 3 and 4), the server may first identify the differences (step 203 a) and then identify what code it does not hold (step 203 b). Having identified what code it needs (in step 203 b), the server then uploads that code not held at the server from a gaming device which does hold the code (step 204 a) and then transfers the differences to all devices as required (step 204 b), as described above. Where the features have been created by the gamer, they may be made from sub-features from a standard library or they may be totally new and may be in a standard data format, (such as JPEG for avatars or other visual information) to enable them to be imported into the game. Where new hardware has been purchased by a gamer, the code may relate to the display of the new feature (e.g. the image for the gun) or other parameters relating to the hardware. The code may also include control information, drivers or emulators for the hardware which may enable other gamers to have the functionality of the hardware, with perhaps limited functionality, where they have alternative compatible hardware (e.g. an alternative peripheral, such as a different gun).
  • [0021]
    This enables gaming devices with different feature sets to be connected together in order that gamers can play a multi-party game. By transferring only the differences, the data transfer is minimized which minimizes delays due to transmission between the host and the gaming devices. The method also enables custom or third party features to be shared between gaming devices.
  • [0022]
    By transferring the features to the gaming devices prior to commencement of any game play, this method avoids problems which might otherwise be caused by low data rate connections between the gaming devices and the server. If, instead, the differential features were downloaded by the server to the gaming device when required (e.g. when entering a new level or when a new weapon is about to be used, where only one of the gaming devices has the required attributes for the new level or weapon), a poor network connection would result in delays in rendering the correct display by the console.
  • [0023]
    If a new gaming device requests to connect to the game after it has started (i.e. after the initial transfer of differences as shown in FIG. 2) or one of the original devices disconnects and subsequently requests to reconnect (e.g. if the disconnection was unplanned), the server may only poll the joining device (as in step 202) and then compare the data to the common feature set established for the other devices (in steps 202-204). The server may then identify the differences between the joining device and the common feature set and transfer any required code to the joining device. If the joining device has features that are not part of the common feature set, code will also be transferred to all the other devices.
  • [0024]
    Polling of devices (step 202) may be repeated periodically during game play (e.g. every 5 minutes or in response to a trigger) to determine whether any gaming devices have obtained additional features. In such situations, code transfer will only occur (step 204) where new differences are identified (in step 203).
  • [0025]
    In some situations, the bandwidth between a gaming device and the server may be limited such that it may not be possible to transfer all the additional feature information to a gaming device. In that situation the code relating to a particular feature (e.g. a new weapon) may be replaced by a smaller size file containing basic descriptive attributes relating to the feature (e.g. the polygon model, animations, textures etc may not be transferred in their entirety). This would enable the object's functionality to remain intact for the owner who would be able to use and see the feature as normal whilst the other gaming devices may only display a simplified version of the feature or a standard graphic when it is being used.
  • [0026]
    In an example, several different quality models of the same object (or other feature) may exist with each model providing a different level of detail (LOD) relating to the feature. For example, a vehicle may be modeled three times, one in high detail for close up viewing, one in medium detail and one in low detail for viewing at a distance. The lower detail model will therefore have fewer polygons, textures, animations and general detail than the high quality model with the medium quality being somewhere between the two. The low quality model therefore is a smaller block of data which is much easier to transfer over a network to other gaming devices. Having determined which feature code needs to be transferred between devices (in step 203) the server may (as part of step 204) assess the available bandwidth to each gaming device and determine whether it is possible to transfer the highest quality versions of any feature code within an acceptable timeframe (e.g. a maximum delay time may be predetermined). In a situation where the high LOD model cannot be transferred in an acceptable time period, the server may then determine whether the medium LOD code versions can be transferred and if not it will transfer the low LOD feature code to gaming devices with restricted bandwidth connections to the server. It will be appreciated that there may be more or less than 3 LOD versions for each feature and the number of LOD versions of a feature may depend on the nature of that feature. For example, a knife is small and may require only one LOD (as it can only be seen close up) whereas an aeroplane may require five, for instance (for views from varying distances). The transfer of the different LODs enables the original owners of the features to still use the feature with the display looking normal to them whilst the other gaming devices will be able to understand the new features, display them and enable a gamer to interact with them but they may be graphically downgraded.
  • [0027]
    In the situation where a reduced quality feature is transferred to a gaming device, this may be upgraded automatically by transferring the higher quality LOD versions in the background, e.g. whilst the game is proceeding. This would result in all gaming devices eventually receiving the highest quality LOD versions of each feature it required whilst providing a quick solution to immediate usage when there is a bandwidth restriction on a connection.
  • [0028]
    In some situations, for example when a game is played by very large numbers of gamers (e.g. a MMORPG, a massively multiplayer online role-playing game), it may not be possible to transfer all the features before the game starts or at a pause in the game play (e.g. prior to the start of a new race in a racing simulator driving game) because gamers are constantly joining and leaving the game. Furthermore, with a very large number of gamers, the differences in attributes held by each of the gaming devices may be very large (e.g. each of the millions of gamers may have their own customized avatar). In such a situation, the transfer of features between gaming devices may be limited according to predetermined parameters and examples of a limiting method are described below with reference to FIG. 5.
  • [0029]
    FIG. 5 shows the virtual positions of many characters 501-504 in a game world, each character being controlled by a gaming device. In determining the differences in attributes between devices and transferring those differences to a particular gaming device (in steps 203 and 204), only those differences which relate to the gaming devices whose characters are close to the gaming character of the particular device in the gaming world are transferred to that device. In the example shown in FIG. 5, an area 505 is defined around the position of a particular character 501 controlled by a first gaming device. Code relating to differences in features between that first gaming device and the gaming devices controlling any characters within the area 505 are transferred to the first gaming device, however, code relating to differences between the first gaming device and other gaming devices which are controlling characters outside of the area 505 are not transferred to the first gaming device. A second area 506 is defined around the position of another character 502 controlled by a second gaming device. Code relating to differences in features between that second gaming device and other gaming devices that are controlling characters within the second area 506 are transferred to the second gaming device.
  • [0030]
    An example flow diagram of the method is shown in FIG. 6. The server polls all the devices playing a particular game for attribute information (step 601) and, for each device, identifies a subset of devices associated with that device (step 602), e.g. in the example of FIG. 5, subset of devices associated with the first gaming device comprises all those devices controlling characters located within area 505. The server then identifies the differences in attributes between the particular device and the other members of a subset (step 603). These two steps (steps 602-603) are repeated for each device and the server transfers to each device the code associated with the identified differences in features (from step 603) between that device and the other devices within its subset (step 604).
  • [0031]
    It will be appreciated the order of method steps is provided by way of example only and for example, the server may identify all the differences between a device and the other devices in the game and then filter those differences based on the subset, etc.
  • [0032]
    The method may be implemented by the server periodically, e.g. every 30 seconds or whenever characters move within the game such that the subset of device associated with a particular devices changes. This may result in the method being implemented by the server on a quasi-continuous basis, with small amounts of code being transferred quasi-continuously to each of the gaming devices.
  • [0033]
    Where a gaming device controls more than one character, the subset associated with that gaming device may comprise the sum of multiple subsets, one associated with each of the characters being controlled.
  • [0034]
    According to the method described above, if the first gaming device (controlling character 501) holds a feature set A, B and C whilst the second gaming device (controlling character 502) holds a feature set A, B, C and D, the code relating to feature D will be transferred by the server to the first gaming device. However, if a third gaming device (controlling character 503) holds a feature set A, B, C and E, the code relating to feature E will be transferred by the server to the second gaming device (because character 503 is within area 506) and not to the first gaming device (because the character 503 is not within area 505) and this leads to a further mismatch between features held by the first and second gaming devices. However, the first gaming device will still be able to operate properly because, as character 503 is not close to character 501, the first gaming device will not need to display or otherwise use any of the features held by the third gaming device. Consequently, the transfer of features between gaming devices (e.g. in step 604) may be limited by one or more parameters, such as the ownership and/or control of the particular features. This is described in more detail below.
  • [0035]
    By limiting the transfer of information between gaming devices playing the same game, delays due to poor network connections between the gaming devices and the server can be minimized.
  • [0036]
    The size of the area used to identify the subset of devices (as described above) may be variable according to one or more predetermined parameters. The size of the area may be fixed for a particular device or may vary dynamically. In an example, the size of the area may be varied according to the data rate of the connection between the particular gaming device and the server. Where a gaming device has a high data rate connection to the server, the area for that device may be larger. In another example, the size of the area may depend on a service level paid for by a gamer (e.g. a higher service level demanding a higher fee may offer a larger area) in a further example, the size of the area may be dependent on the amount of data to be transferred, such that there is a target data rate for the transfer of data from the server to a gaming device. With such a target data rate, the size of the area will change dependent on the amount of feature code to be transferred (e.g. according to the density of characters with new features). Use of a target data rate may increase the efficiency of usage of the link between the server and the gaming device. In another example, the area may be varied such that the feature sets for a predetermined number of gaming devices are compared (e.g. 10 gaming devices). It will be appreciated that there may not be a 1:1 relationship between characters and gaming devices because a single device may have multiple controllers each used by a different gamer to control a different character in the game world.
  • [0037]
    In another example, more than one area may be defined around each character to determine a plurality of subsets of devices associated with each device. For example, the first gaming device (controlling character 501) may have a first associated subset containing all those devices controlling characters within a first area 505 and a second associated subset containing all those devices controlling characters within a second area 507 and not within the first area 505. The transfer of features to the first gaming device (based on differences between that device and those in each of the first and second associated subsets) may be limited according to different parameters. For example, all the code relating differences between the first device and those devices in the first associated subset may be transferred to the first device, whilst only the code relating to the avatar (or other display) differences between the first device and those devices in the second associated subset may be transferred to the first device. This would enable the first device to display each of the characters (or items) in the second area 507 (and not the first area 505) correctly, but the first device would not receive other differences, e.g. differences in levels owned, differences in weapons, strengths, etc. In another example, low resolution avatar code may be transferred relating to those characters in the second area 507 whilst high resolution avatar code may be transferred relating to those characters in the first area 505. Progressive downloading techniques may be used to first download a lower quality image and then to continue to download further data and improve the quality of the image displayed.
  • [0038]
    In another example, as described above feature code may exist in multiple different quality versions. In an example, high LOD code may be transferred relating to features located in a first area 505 whilst a low LOD code may be transferred relating to those features in a second area 507. Again, progressive downloading or other techniques may be used to subsequently download the high LOD code for features in area 507 if there is available capacity over the connection.
  • [0039]
    In another example, multiple areas may be defined and each area may have different predetermined rules on which features are transferred (e.g. different levels of detail, different types of features etc).
  • [0040]
    In the above description, the set of features to be transferred was determined based on the locations of characters (as shown in FIG. 5). In addition to, or instead of this, features may be transferred according to the level of effect (LOE) of a feature. LOE is similar to LOD (described above) but covers the level (or degree) of an object's effect rather than the size of the code. For example, if three different weapon types are considered: a knife, a tank and a bomb. A knife is a small object that can only be seen close up. It also has a small level of effect, i.e. it can only be used locally whereas a tank is a large object which can be seen and heard a long way off and also has a high level of effect because it can attack things from a large distance. Finally, a bomb may be a physically small feature with a much larger LOE because although it may be a very long way away (such that it cannot be seen) it may still affect a character. The devices having a high LOE may require their feature codes to be transferred even though they may be located further from a character than those with a low LOE (where the feature code may not need to be transferred). In the example shown in FIG. 5 therefore, the first gaming device (controlling character 501) may have a first associated subset containing all those devices controlling characters within a first area 505 and a second associated subset containing all those devices controlling features with a high LOE which are located within a much larger area (e.g. second area 507).
  • [0041]
    In another example, the multiple areas which may be defined (as described above) may be used to determine subsets of devices (for subsequent transfer of features) according to feature size (in addition to or instead of using LOD and/or LOE as described above). For example, small features such as the knife mentioned above may only be transferred if they relate to the first area 505 whilst larger devices which may therefore be seen at a larger distance may have their feature code transferred when they are in the second area 507.
  • [0042]
    The transfer of features between gaming devices may be prioritized based on the type of feature to be transferred. This prioritization may operate independently or in conjunction with any of the other techniques described herein. For example, the highest priority feature data to transfer may be whether a character is a bipedal humanoid, a quadraped, an armored car, a bird etc. The next priority may be similar information and basic functionality for any object being carried by that character, with the next priority being animations for special moves of that character. This may be followed by low LOD textures, higher level model detail and then higher LOD textures. By using such a prioritization, the receiving gaming device obtains the most important feature information about objects in a game first and less important information regarding specifics of animation or objects carried subsequently.
  • [0043]
    In the methods described above, code relating to features is transferred between the server or a gaming device and another gaming device when one or more gaming devices hold a particular feature. Whilst this enables gamers with different features sets to participate in games together, it may be necessary to control the subsequent use of those transferred features by the recipient gaming devices, particularly where the features are ones which have been paid for, earned etc. A gamer, having purchased a number of new weapons, would be reluctant to play a game with other gamers who have not purchased those weapons if it meant that those other gamers were subsequently able to use the weapons (e.g. when not playing with the garner who purchased them) without having to pay for them. Consequentially, it may be advantageous for features to be tagged with ownership information.
  • [0044]
    There are a number of different ways in which code relating to a feature may be tagged with ownership information. In a first example, the code may contain embedded ownership information, which may be encrypted. The ownership information may comprise an identifier associated with a gamer (e.g. a gamertag, an account/subscription number etc) or an identifier associated with a gaming device (e.g. the unique ID for a particular gaming device) or an identifier associated with a group or category of gamers. The features may in some situations only be enabled for use (by the server or the gaming device) when the identified owner is participating in the game play. This may be achieved by encrypted code being transferred between gaming devices and the encryption key being held by the owner. Use of the gaming devices may then be limited to the situation where the recipient gaming devices have access to the encryption key. In another example, the ownership information may comprise no ownership details but instead may indicate that no further change of ownership is permitted (e.g. that the feature is on loan as a volatile asset), In this manner the owner's privacy is kept intact whilst the feature code can be sent to other gaming devices. Where ownership information is flagged in this manner the feature code may then be discarded and not permanently held at the end of a gaming session or at another appropriate time. Use of encryption and/or digital signatures may prevent tampering of the ownership information. Digital Rights Management methods may be used to prevent copying of the code.
  • [0045]
    In a second example, each gamer or gaming device may have an associated inventory of features owned by that gamer or device. Each feature may have a unique ID which is securely attached to the object or encrypted within the object. This ID can be used to link the feature to the inventory. The inventory may be stored either on the gaming device or at the server and may be encrypted to prevent tampering. Again, the server or the gaming device may prevent use of features which are not owned by anyone who is participating in the game by checking the features against stored inventories.
  • [0046]
    In a third example, the server may maintain a central ownership register for features of a game. This register may be checked by the server and gaming devices before enabling any features which are downloaded to devices (e.g. in step 204 or 604). Use of such a central register may be advantageous because it is more secure. The register may also record any transfer of ownership. By using a register in this way, the amount of data held can be remotely expanded (e.g. by including a full ownership history and/or a list of key events in the feature's lifespan) without expanding the actual size of the feature's data which would make it larger to transfer when transferring it between gaming devices. In another example, both a central register and individual inventories associated with a gamer/gaming device may be used.
  • [0047]
    The transfer of ownership of an object or other feature may occur within the game (as described below) or external to the game (e.g. via a web sales/auction site). Where the transfer occurs external to a game, the transfer may only take effect when the gamers meet within a game world. At this point the ownership tag (or other ownership information, for example in a register) may be updated.
  • [0048]
    The server and/or the gaming devices may be arranged to reject objects or features where the identifiers have been tampered with or where false identifiers have been inserted into feature data. Furthermore, objects may be automatically removed or added depending on other circumstances or criteria. In an example, if an object is sold to another person via a web sales site, the object may be automatically added once the seller and buyer meet in a game world. The object may have been previously temporarily removed/suspended following the transaction between the buyer and the seller. In another example, if the buyer defaults with their payment after the ownership of the item/feature has been transferred, then the seller may be able to request the removal of control of the feature until the dispute between seller and buyer has been resolved. In a further example, there may be ways that an item could be stolen in the game that was beyond the accepted bounds of stealing and so the item may need to be suspended or disabled (e.g. by a moderator) until the situation had been resolved. In other examples, items which (for whatever reason) become “faulty” or “corrupted” may be suspended from use until corrected, or removed altogether, In a further example, items that might have entered the game world and which are deemed “undesirable” by gamers, a moderator or other controlling entity, may also suspended, deleted or otherwise removed from game play.
  • [0049]
    As mentioned above, the transfer of features between gaming devices may, in some situations, (e.g. in step 604), be limited by one or more parameters, such as the ownership of the particular features. FIG. 7 shows an example flow diagram of step 202 in more detail which incorporates such a limitation. The devices are polled for attribute information (step 202 a) and for each feature identified in the attribute information, the ownership of each feature is checked (step 202 b). The received attribute information is then filtered (step 202 c) to remove references to any features which are not owned by either the device from which the attribute information was received or a gamer logged in (or associated with in any other way) that device. Consequently in subsequent steps (e.g. of FIGS. 2 or 6) the comparison of difference only relates to attributes which are owned by the device/gamer and therefore the transfer of code relating to features (in step 204 or 604) is similarly limited.
  • [0050]
    In the specific example described above in relation to FIG. 5, the first gaming device (controlling character 501 owns features A, B and C whilst the second gaming device (controlling character 502) owns features A, B, C and D, and the third gaming device (controlling character 503) owns features A, B, C and E. Consequently, code relating to feature D will be transferred by the server to the first gaming device and code relating to feature E will be transferred by the server to the second gaming device. This leads to the first gaming device holding features A-D, whilst only owning features A-C and the second gaming device holding features A-E, whilst owning features A-D. Although the features held by the first and second gaming devices are not the same, there is no requirement for further transfer of features because the first gaming device holds all the features which are owned by the second gaming device (the second gaming device is in the area 505 associated with the first gaming device) and vice-versa (the first gaming device is in the area 506 associated with the second gaming device).
  • [0051]
    Although the description above refers to characters within a game, the methods described are also applicable to other controllable objects within a game, such as vehicles, or other user defined objects, such as buildings, scenery etc.
  • [0052]
    Although the example described above shows the transfer of feature code being limited by both area and ownership, the two filters may be implemented independently (e.g. by filtering only on ownership) and the transfer of feature code may be filtered using any suitable parameter(s) including LOD, LOE etc.
  • [0053]
    In addition to tagging features with ownership information (e.g. in the code or via an inventory/register as described above), they may be tagged with other information, (e.g. scope of usage, time stamps etc) which may be more transient (e.g. identity of controlling device/gamer, which may be different to the owner). For example the features may be tagged with information detailing which device can use the feature for a limited period of time. This may be used to enable the feature's control to be transferred during a game from the owning device (e.g. the owner or the device with which the owner is associated where ownership is linked to a gamer rather than a gaming device) to another device (e.g. if a new weapon is taken in the gaming world by another character). Such applications are described in more detail below. The feature may be tagged with the other information in the same way as the ownership information, as described above, or in a different way. In particular, it may not be necessary to encrypt this information where the information is transient and expires at some point in the future because there may be less concern about tampering. Where the controlling entity and the owning entity are different, it may be necessary for the server to check that the owning entity is not, in the time period specified, using the particular feature. In such an example, the transfer of feature code may be limited by both ownership and control, (particularly where also limited by area).
  • [0054]
    The features transferred to gaming devices using the methods as described above, may be used in different ways by the device within subsequent game play. In a first example, the feature code may be used to ensure that the display is correctly rendered at the receiving device (e.g. to correctly display the image of a new weapon purchased by another gamer). In another example, the device may be able to use all the features received in the game play, for example, if a new weapon has been purchased by another gamer and the associated code transferred to the device, the new weapon may be available to all those playing the game. Where the new feature relates to new hardware (e.g. a new gun) the code may be used to enable other gaming devices to emulate that hardware using an existing controller or other peripheral. The manner in which features may be used may be specified by the server or may alternatively be specified within the feature code.
  • [0055]
    Where the feature is not available for full use by all devices, the control of the feature may be enabled to change during game play (e.g. if a character steals/borrows/loans an item). In such a situation, a control tag associated with the feature may be changed such that a different device has full use of the feature (for a limited time) whilst the owning device does not. As described above, an inventory or central register may be used in addition to or instead of a control tag to record control (and ownership). Therefore the transfer of control may be recorded in an inventory, a register or by any other suitable means. Such transfer of control may be accompanied by a micropayment between the owner and the gamer taking control of the device. It may further be possible for the feature to be sold or exchanged within the game world, for example in return for a micropayment or another feature, and in such a situation the ownership information may be updated (e.g. in an ownership tag, an inventory, a register etc).
  • [0056]
    The use of features within the game may be linked to an advertising/sale window such that if a character controlled by a first gaming device is approached/attacked by a character which owns a different feature (e.g. a new weapon), a window may appear providing details on that different feature (e.g. “You have just been attacked using weapon X” or “You have just been attacked by a character having new skill Y” etc). The details may include a description of the feature and a link/button to purchase the feature (e.g. in return for a micropayment) either from a store (e.g. from a store operated by the server) or the current owner (e.g. “You have just been attacked using weapon X. Would you like to purchase weapon X?”).
  • [0057]
    Information on the differences in feature sets owned by each gamer may be available for display to each gamer, for example in the form of an upgrade (or feature) list. This would enable a gamer to review the features held by others participating in the same game and decide whether they wished to upgrade, to continue to play the game etc. This list may include links to enable the features to be purchased or borrowed for a limited period, e.g. as a trial. Inventory information may be collected by the server by polling all devices (as in step 202) when they connect to the server (e.g. prior to receiving the request to connect to a game) and this would enable the information to be displayed to a gamer before they decide to join a game.
  • [0058]
    In the examples described above, the differences in feature sets held by different gaming devices are transferred to devices to provide a common feature set. However, in another example, a feature that is not owned by any of the devices may be transferred to each of the devices by the server, for example, as part of a free trial of the feature for a specified number of games (e.g. for one game) or a limited period of time (e.g. for 24 hours). In such a situation, an advertising/sale window (as described above) may presented to a gamer via the display of a gaming device (e.g. at the end of the game or towards the end of the 24 hour trial period), to provide a quick and easy method of the gamer purchasing the feature during or at the end of the trial period.
  • [0059]
    In the situation where a device is able to use all the features received from the server although the device does not own the feature or where a device has taken control of a feature that it does not own, if the actual owner of the feature stops participating in the game, the feature may continue to be available for the other devices participating in the game until the game is completed. If a gaming device is inadvertently disconnected (and may rejoin within a small time period) this may reduce the churn of features (which might degrade playing experience) and minimize transfer of feature code. In another example, as soon as the owner of the feature drops out, the server may send a signal to all the devices which disables the use of the feature.
  • [0060]
    Having received additional feature data, as described above, this data is stored at the gaming device e.g. in the memory 801 (as shown in FIG. 8) internal to the console 103 or in external memory. FIG. 8 shows a schematic diagram of a console 103 in more detail. The console comprises a processor 802 connected to the memory 801, a display I/O 803, a controller I/O 804 and a network interface 805. The memory 801 is arranged to store instructions to cause the processor 802 to perform some or all of the method steps described above. The memory may also be used to store feature data received (as mentioned above). The feature data received (over the network via the network interface 805) may be retained by the gaming device until it is deleted in response to a command input by a user (i.e. manual deletion e.g. in response to a signal received via the controller I/O 804) or it may be automatically deleted. The features downloaded may be deleted at the end of a game, at the end of a session, when the device is switched off (or put into standby), after a predetermined period of time (e.g. after 24 hours of non-use of a feature) or at any other suitable point. In another example, a signal may be received from the server when the owner of a feature drops out and this signal may trigger the automatic deletion of the relevant feature. The trigger may, in another example, be received from the owning gaming device. In another example, the code may be deleted when the amount of memory associated with the gaming device (internal and/or external) which is full reaches a threshold level (e.g. when the memory gets to 90% full or when there is only 100 MB free memory etc).
  • [0061]
    An example flow diagram for the purging of data is shown in FIG. 9. A trigger to purge the memory is received by a gaming device (step 901). This trigger may be received from outside the device (e.g. from the server or another gaming device) or may be generated within the device (e.g. when the amount of memory which is full exceeds a threshold or in response to an input to the controller etc). The device then identifies all the features of a game where code is stored at the device but where the feature is not owned by the device or associated gamers (step 902) and of these identified features, all the features which are not owned by anyone in current game play are identified (step 903) and the code relating to these remaining identified features is then deleted (step 904). Where the game play has already stopped, step 903 will not filter out any features because there are no devices/gamers in current game play.
  • [0062]
    The above description relates to a network of gaming devices 101 connected by a server 102 as shown in FIG. 1 and shown in more detail in FIG. 10. The server 102 comprises a processor 1001, a memory 1002 and a network interface 1003. The memory 1002 may be arranged to store code relating to features of the game and/or instructions to cause the processor to perform one or more of the steps of any of the methods described herein. However, the methods described above may also be applied to a network 1100 of gaming devices 101 which are inter-connected without control by a server, as shown in FIG. 11. These gaming devices may be connected directly to each other (e.g. via a network, via direct links etc) or may be connected to each other via other intermediate devices (e.g. other gaming devices), for example in a peer-to-peer network. In such a network, one of the gaming devices may act as a host and control the transfer of features (e.g. perform the method steps 202-204). A gaming device may be identified at random to act as host or the host may be selected based on predetermined criteria, such as, first to join or request to join the game, the one with the largest feature set, the one with the largest differences to the other devices etc. If the identified host disconnects or otherwise stops participating in the game, one of the other devices becomes the host. Where a gaming device acts as host, they may not hold the code for all the features and therefore may need to upload code from other gaming devices, as shown in FIGS. 3 and 4.
  • [0063]
    In the methods described above, the difference calculation is performed centrally by a host (such as a server or a gaming device). However, the methods may be performed in a distributed manner (whether or not a server is present) with each gaming device determining what feature data it requires and requesting it from the gaming device holding the appropriate code (e.g. each gaming device performs steps 202-204) or from the server (if present).
  • [0064]
    In another example, the gaming devices 101 shown in FIG. 11 may operate in a peer-to-peer scenario where no one gaming device is dominant. Each gaming device may use standard peer-to-peer techniques to communicate and transfer feature data in a complex parallel networking mesh between each other. In an example implementation, the first gaming device may compile a list of its feature set and then send the list to the next gaming device which analyses this list, notes in it what extra features are held by that gaming device and which of the previous gaming devices features it does not hold. This list can then be sent on to each of the gaming devices in turn with each recipient gaming device annotating the list as described above. Having been annotated by all the gaming devices the list is passed back to the first gaming device. At this point each gaming device in the system is aware of which features are held by the other gaming devices and which gaming devices require feature data that they hold. The gaming devices can then stream out the required feature data to those other gaming devices which need it.
  • [0065]
    In another example in this peer-to-peer scenario, each gaming device sends a list of the features that it holds to each of the other gaming devices in the network. Having received a list from each of the other gaming devices in the network, any gaming device can determine which gaming devices need to be sent code that it holds. The code can then be streamed to the other gaming devices who require those features. Alternatively, gaming devices can, using the list received, request feature data from a particular other gaming device in the network (rather than have it streamed to them without first requesting it). It will be appreciated that there may be other ways in which the data relating to feature sets can be shared between gaming devices in a peer to-peer network such that code relating to differences in feature sets can be subsequently transferred between gaming devices.
  • [0066]
    In the examples described above, the code relating to the game runs on the gaming device. If however the code runs on the server, the methods described above are also applicable. In such a situation, the server checks the attributes (or inventories) associated with each gaming device and instead of downloading the differences to the gaming devices, the server enables all the devices participating in a game to have access to all of the features owned by any of the devices connected to the particular game.
  • [0067]
    Although the examples described above relate to multiple gaming devices participating in the same game, the methods described above may also be used to join together separate gaming worlds. In an example, there may be an overlap between some of the objects/features/upgrades in two separate gaming worlds. For example, world A might have guns and knives, but world B might have guns and bombs. Therefore the concept of knives and bombs may be only known to their respective worlds but guns may be common and may therefore be meaningfully transferred where two games worlds are connected. In such a situation, XML may be used to export a world or its data, whether for guns, knives or bombs, and the receiving world may only take from that the data relevant to objects understood in the receiving world. Therefore, in the example given above world A may transfer XML detailing all guns and knives but world B may only take the guns data from the XML data received and ignore the knives data. XML is just one such possible mechanism which may be used and others may be alternatively used.
  • [0068]
    In the above description, features are identified with particular gamers or with the gaming devices with which a gamer is associated. In another example, identifiers may be used which are associated with a group or category of gamers. The use of such an identifier associated with a group or category of gamers enables features to be associated, for example, with a particular team, rank or achievement level within the game world or gaming community. Such features may comprise privileges which are associated with the particular group or category of gamers.
  • [0069]
    Although the present examples are described and illustrated herein as being implemented in a network of gaming devices, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of networks with any number of gaming devices. The networks need not be dedicated to gaming and the gaming devices may be able to perform many other functions (as described below),
  • [0070]
    The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
  • [0071]
    This acknowledges that software can be a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions, (and therefore the software essentially defines the functions of the register, and can therefore be termed a register, even before it is combined with its standard hardware). For similar reasons, it is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
  • [0072]
    Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
  • [0073]
    The terms ‘gaming device’ and ‘gaming console’ are used herein to refer to any device on which a user can play a game, including, but not limited to, dedicated games consoles (e.g. Xbox®, Xbox360™ etc), computers, PDAs, and mobile telephones. Although the gaming devices shown above comprise a console, a display and a controller, this is by way of example only and it will be appreciated that some/all of the functions may be integrated (e.g. into a handheld gaming device) or that the device may not comprise all the features (e.g. the console may be connected to a television which although used to display the game is not part of the gaming device itself).
  • [0074]
    The term ‘feature’ is used herein to refer to any aspect of a game, including, but not limited to, items (such as weapons, belongings, vehicles etc), backgrounds/environments (e.g. buildings, interiors, terrains et), music, avatars, models, textures, animations, other abilities/methods, game levels and upgrades. An ability/method may include tactical commands, moves etc which may be obtained through training, experience, buying, hiring, stealing, promotion etc. Where an ability/method is obtained through experience, training or promotion, the ability/method may be associated with a group of gamers (as described above).
  • [0075]
    The term ‘computer’ is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term ‘computer’ includes PCs, servers, mobile telephones, personal digital assistants and many other devices
  • [0076]
    The ideas and individual aspects of any of the methods described above may be used independently or in any combination. Where the examples described above show ideas used in combination, this is by way of example only and does not imply any limitation in the way they may be implemented.
  • [0077]
    Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.
  • [0078]
    The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. It will be appreciated that the repeating of steps within methods (e.g. the loop back from step 603 to step 602 in FIG. 6) is shown by way of example only and may be implemented in different ways (e.g. loop back from step 604 to step 602 in FIG. 6).
  • [0079]
    It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. The above specification examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims (19)

  1. 1. A method of connecting gaming devices together to enable a multi-party game, the method comprising:
    receiving data from a plurality of gaming devices, the data detailing features of a game associated with each of the plurality of gaming devices;
    determining one or more required features associated with a first of the plurality of gaming devices, wherein a required feature comprises a feature associated with one of the plurality of gaming devices and not associated with the first of the plurality of gaming devices;
    transmitting code relating to the required features to the first of the plurality of gaming devices; and
    repeating the determining and transmitting steps for each of the plurality of gaming devices.
  2. 2. A method according to claim 1, further comprising, prior to transmitting code:
    accessing a store of code relating to features of the game;
    determining if the code relating to each of the required features is stored in the store; and
    if not, requesting the code from one of the plurality of gaming devices.
  3. 3. A method according to claim 1, wherein transmitting code relating to the required features to the first of the plurality of gaming devices comprises:
    filtering the required features according to predetermined parameters; and
    transmitting code relating to the filtered required features to the first of the plurality of gaming devices.
  4. 4. A method according to claim 3, wherein filtering the required features according to predetermined parameters comprises:
    identifying a subset of the plurality of gaming devices associated with the first of the plurality of gaming devices according to predetermined parameters; and
    filtering the required features such that the filtered required features comprise one or more features associated with one of the subset of the plurality of gaming devices and not associated with the first of the plurality of gaming devices.
  5. 5. A method according to claim 4, wherein identifying a subset of the plurality of gaming devices associated with the first of the plurality of gaming devices comprises:
    determining a game position for objects in the game controlled by each of the plurality of gaming devices;
    defining an area around a game position for an object controlled by the first of the plurality of gaming devices based on predetermined parameters;
    identifying any objects located with the area; and
    determining the one or more of the plurality of gaming devices controlling the identified objects.
  6. 6. A method according to claim 4, wherein the predetermined parameters comprise one or more of: a data rate of a connection to the first of the plurality of gaming devices, and a target data transfer rate to the first of the plurality of gaming devices.
  7. 7. A method according to claim 3, wherein filtering the required features according to predetermined parameters comprises:
    determining ownership information for each of the required features; and
    filtering the required features to remove any features not owned by one of the plurality of gaming devices or a gamer associated with one of the plurality of gaming devices.
  8. 8. A method according to claim 1, wherein the code relating to a required feature comprises ownership information.
  9. 9. A method according to claim 8, wherein the ownership information identifies a gaming device, a gamer or a group of gamers.
  10. 10. A method according to claim 1, wherein the method further comprises, prior to receiving data from a plurality of gaming devices:
    receiving a request from each of the plurality of gaming devices to participate in the game; and
    requesting data from each of the plurality of gaming devices, the data detailing features of a game associated with each of the plurality of gaming devices.
  11. 11. A method according to claim 1, further comprising:
    enabling the use of the required features by a receiving one of the plurality of gaming devices according to predefined rules.
  12. 12. One or more device readable media with device-executable instructions for performing steps comprising:
    receiving data from a plurality of gaming devices, the data detailing features of a game associated with each of the plurality of gaming devices;
    determining one or more required features associated with a first of the plurality of gaming devices, wherein a required feature comprises a feature associated with one of the plurality of gaming devices and not associated with the first of the plurality of gaming devices;
    transmitting code relating to the required features to the first of the plurality of gaming devices; and
    repeating the determining and transmitting steps for each of the plurality of gaming devices.
  13. 13. A method of connecting a plurality of gaming devices together to enable a multi-party game, the method comprising, at a first of the plurality of gaming devices:
    sending data detailing features of a game associated with the first of the plurality of gaming devices to a remote device;
    receiving code relating to a set of required features, wherein a required feature comprises a feature associated with another of the plurality of gaming devices and not associated with the first of the plurality of gaming devices; and
    storing the received code.
  14. 14. A method according to claim 13, further comprising, prior to sending data detailing features of the game:
    sending a request to participate in the game to the remote device; and
    receiving a request for data from the remote device, the data detailing features of a game associated with the first of the plurality of gaming devices.
  15. 15. A method according to claim 13, further comprising:
    receiving a trigger to purge received code;
    determining ownership information for each required feature; and
    deleting received code relating to any required features not owned by any gaming devices connected to the remote device or by gamers associated with any of the gaming devices connected to the remote device.
  16. 16. A method according to claim 13, wherein the code relating to the set of required features is received from the remote device.
  17. 17. A method according to claim 13, wherein the code relating to the set of required features is received from one or more of the plurality of gaming devices.
  18. 18. A method according to claim 17, wherein the remote device is one of the plurality of gaming devices.
  19. 19. A method according to claim 13, wherein the remote device comprises a server.
US11425258 2006-06-20 2006-06-20 Transfer of Features Between Gaming Devices Abandoned US20070293319A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11425258 US20070293319A1 (en) 2006-06-20 2006-06-20 Transfer of Features Between Gaming Devices

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US11425258 US20070293319A1 (en) 2006-06-20 2006-06-20 Transfer of Features Between Gaming Devices
RU2008150478A RU2008150478A (en) 2006-06-20 2007-04-30 The transfer characteristics between gaming devices
CN 200780022872 CN101473341A (en) 2006-06-20 2007-04-30 Transfer of features between gaming devices
PCT/US2007/010445 WO2007149147A1 (en) 2006-06-20 2007-04-30 Transfer of features between gaming devices
KR20087030868A KR20090021172A (en) 2006-06-20 2007-04-30 Transfer of features between gaming devices
EP20070756150 EP2036021A1 (en) 2006-06-20 2007-04-30 Transfer of features between gaming devices
JP2009516484A JP2009540920A (en) 2006-06-20 2007-04-30 Feature delivery between game machines

Publications (1)

Publication Number Publication Date
US20070293319A1 true true US20070293319A1 (en) 2007-12-20

Family

ID=38833721

Family Applications (1)

Application Number Title Priority Date Filing Date
US11425258 Abandoned US20070293319A1 (en) 2006-06-20 2006-06-20 Transfer of Features Between Gaming Devices

Country Status (7)

Country Link
US (1) US20070293319A1 (en)
EP (1) EP2036021A1 (en)
JP (1) JP2009540920A (en)
KR (1) KR20090021172A (en)
CN (1) CN101473341A (en)
RU (1) RU2008150478A (en)
WO (1) WO2007149147A1 (en)

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080004094A1 (en) * 2006-06-30 2008-01-03 Leviathan Entertainment, Llc Method and System to Provide Inventory Management in a Virtual Environment
US20090037905A1 (en) * 2007-08-03 2009-02-05 Hamilton Ii Rick Allen Method for transferring inventory between virtual universes
US20090125819A1 (en) * 2007-11-08 2009-05-14 Hamilton Ii Rick Allen Method and system for splitting virtual universes into distinct entities
US20090178143A1 (en) * 2008-01-07 2009-07-09 Diginome, Inc. Method and System for Embedding Information in Computer Data
US20090175521A1 (en) * 2008-01-07 2009-07-09 Diginome, Inc. Method and System for Creating and Embedding Information in Digital Representations of a Subject
US20090198664A1 (en) * 2008-02-05 2009-08-06 Hamilton Ii Rick Allen Method and system for merging disparate virtual universes entities
US20090210324A1 (en) * 2008-02-15 2009-08-20 Bhogal Kulvir S Tracking of Shared Inventory in a Virtual Universe
US20090235183A1 (en) * 2008-03-12 2009-09-17 Hamilton Rick A Attaching external virtual universes to an existing virtual universe
US20090248862A1 (en) * 2008-03-26 2009-10-01 Brother Kogyo Kabushiki Kaisha Device and Computer Readable Medium
US20100009747A1 (en) * 2008-07-14 2010-01-14 Microsoft Corporation Programming APIS for an Extensible Avatar System
US20100023885A1 (en) * 2008-07-14 2010-01-28 Microsoft Corporation System for editing an avatar
US20100026698A1 (en) * 2008-08-01 2010-02-04 Microsoft Corporation Avatar items and animations
US20100100446A1 (en) * 2007-03-14 2010-04-22 Kim Hyong-Suk Method for advertising using mobile multiplayer game and system thereof
US20100306675A1 (en) * 2009-06-01 2010-12-02 International Business Machines Corporation Peer-to-peer based content delivery in a virtual universe
US20100331084A1 (en) * 2009-06-24 2010-12-30 Aperture Investments Llc System and method for a wrap-around gaming experience
US20110055733A1 (en) * 2009-09-03 2011-03-03 International Business Machines Corporation System and Method for Locating Missing Items in a Virtual Universe
US20110219130A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US20120142430A1 (en) * 2008-02-11 2012-06-07 Microsoft Corporation Partitioned artificial intelligence for networked games
US20120311504A1 (en) * 2011-06-03 2012-12-06 Van Os Marcel Extensible architecture for navigating a hierarchy
US20130104025A1 (en) * 2011-10-20 2013-04-25 Microsoft Corporation Enabling immersive search engine home pages
US20130143667A1 (en) * 2011-12-01 2013-06-06 Nintendo Co., Ltd. Game system, game apparatus, storage medium and game controlling method
US20130254336A1 (en) * 2009-12-02 2013-09-26 International Business Machines Corporation System and method for abstraction of objects for cross virtual universe deployment
US8613648B2 (en) 2010-11-02 2013-12-24 Wms Gaming Inc. Multi-game video poker machine and system with asymmetrically accessible customization features
US8613674B2 (en) 2010-10-16 2013-12-24 James Charles Vago Methods, devices, and systems for video gaming
US20140115144A1 (en) * 2012-10-18 2014-04-24 Bigpoint Inc. Online game system, method, and computer-readable medium
US20140113727A1 (en) * 2012-10-18 2014-04-24 Bigpoint Inc. Online game system, method, and computer-readable medium
WO2015012786A1 (en) * 2013-07-22 2015-01-29 Empire Technology Development Llc Game load management
US20150105154A1 (en) * 2011-09-29 2015-04-16 Sony Computer Entertainment Europe Limited Gaming assistance system and method
US20150141120A1 (en) * 2013-11-15 2015-05-21 Ol2, Inc. Systems and methods for providing cross platform access to interactive content
US9237115B2 (en) 2012-02-14 2016-01-12 Empire Technology Development Llc Load balancing in cloud-based game system
US9251318B2 (en) 2009-09-03 2016-02-02 International Business Machines Corporation System and method for the designation of items in a virtual universe
US9269233B2 (en) 2010-07-21 2016-02-23 Bally Gaming, Inc. Poker game system and system with a secondary award feature having an expected value dependent on the ranking of a primary game outcome
US20160269178A1 (en) * 2015-03-09 2016-09-15 Crowd Ip Box Ug (Haftungsbeschraenkt) Privacy-Enhanced Biometrics-Secret Binding Scheme

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090327094A1 (en) * 2008-06-30 2009-12-31 Microsoft Corporation Platform independent ecosystem for creation, consumption and trade of user-generated digital content
JP5529924B2 (en) * 2012-06-04 2014-06-25 株式会社コナミデジタルエンタテインメント Game control device, game control method, a program, a game system, the information processing apparatus
JP5529923B2 (en) * 2012-06-04 2014-06-25 株式会社コナミデジタルエンタテインメント Game control device, game control method, a program, a game system, the information processing apparatus

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5772512A (en) * 1996-07-31 1998-06-30 Clutchability, L.L.C. Electronic football game
US6128660A (en) * 1996-03-21 2000-10-03 Hearme Network match maker
US20030014513A1 (en) * 2000-12-27 2003-01-16 Ruths Derek Augustus Samuel System and method for collaborative data resource representation
US20040002382A1 (en) * 2002-06-27 2004-01-01 Inventec Appliances Corp. Method enabling mobile telephone game playing capability on wireless networks
US20040068724A1 (en) * 2002-08-30 2004-04-08 Gardner Richard Wayne Server processing for updating dataset versions resident on a wireless device
US20040109023A1 (en) * 2002-02-05 2004-06-10 Kouji Tsuchiya Voice chat system
US20040259642A1 (en) * 2003-06-17 2004-12-23 Shoya Tanaka Game system, game apparatus, storage medium storing game program and game data exchange method
US20050137015A1 (en) * 2003-08-19 2005-06-23 Lawrence Rogers Systems and methods for a role-playing game having a customizable avatar and differentiated instant messaging environment
US20060142085A1 (en) * 2002-11-13 2006-06-29 Ncsoft Corporation Method and apparatus for providing on-line game
US20060183550A1 (en) * 2005-02-08 2006-08-17 Gagner Mark B Information transfer to gaming machines

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000037507A (en) * 2000-04-29 2000-07-05 강서규 'MutiBahng' Network Business Model

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128660A (en) * 1996-03-21 2000-10-03 Hearme Network match maker
US5772512A (en) * 1996-07-31 1998-06-30 Clutchability, L.L.C. Electronic football game
US20030014513A1 (en) * 2000-12-27 2003-01-16 Ruths Derek Augustus Samuel System and method for collaborative data resource representation
US20040109023A1 (en) * 2002-02-05 2004-06-10 Kouji Tsuchiya Voice chat system
US20040002382A1 (en) * 2002-06-27 2004-01-01 Inventec Appliances Corp. Method enabling mobile telephone game playing capability on wireless networks
US20040068724A1 (en) * 2002-08-30 2004-04-08 Gardner Richard Wayne Server processing for updating dataset versions resident on a wireless device
US20060142085A1 (en) * 2002-11-13 2006-06-29 Ncsoft Corporation Method and apparatus for providing on-line game
US20040259642A1 (en) * 2003-06-17 2004-12-23 Shoya Tanaka Game system, game apparatus, storage medium storing game program and game data exchange method
US20050137015A1 (en) * 2003-08-19 2005-06-23 Lawrence Rogers Systems and methods for a role-playing game having a customizable avatar and differentiated instant messaging environment
US20060183550A1 (en) * 2005-02-08 2006-08-17 Gagner Mark B Information transfer to gaming machines

Cited By (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080004094A1 (en) * 2006-06-30 2008-01-03 Leviathan Entertainment, Llc Method and System to Provide Inventory Management in a Virtual Environment
US20100100446A1 (en) * 2007-03-14 2010-04-22 Kim Hyong-Suk Method for advertising using mobile multiplayer game and system thereof
US8713181B2 (en) * 2007-08-03 2014-04-29 International Business Machines Corporation Method for transferring inventory between virtual universes
US20090037905A1 (en) * 2007-08-03 2009-02-05 Hamilton Ii Rick Allen Method for transferring inventory between virtual universes
US20090125819A1 (en) * 2007-11-08 2009-05-14 Hamilton Ii Rick Allen Method and system for splitting virtual universes into distinct entities
US8140982B2 (en) 2007-11-08 2012-03-20 International Business Machines Corporation Method and system for splitting virtual universes into distinct entities
US20090178143A1 (en) * 2008-01-07 2009-07-09 Diginome, Inc. Method and System for Embedding Information in Computer Data
US20090175521A1 (en) * 2008-01-07 2009-07-09 Diginome, Inc. Method and System for Creating and Embedding Information in Digital Representations of a Subject
US20090198664A1 (en) * 2008-02-05 2009-08-06 Hamilton Ii Rick Allen Method and system for merging disparate virtual universes entities
US20110113018A1 (en) * 2008-02-05 2011-05-12 International Business Machines Corporation Method and system for merging disparate virtual universes entities
US7921128B2 (en) 2008-02-05 2011-04-05 International Business Machines Corporation Method and system for merging disparate virtual universes entities
US8019797B2 (en) 2008-02-05 2011-09-13 International Business Machines Corporation Method and system for merging disparate virtual universes entities
US20120142430A1 (en) * 2008-02-11 2012-06-07 Microsoft Corporation Partitioned artificial intelligence for networked games
US9327194B2 (en) * 2008-02-11 2016-05-03 Microsoft Technology Licensing, Llc Partitioned artificial intelligence for networked games
US9754234B2 (en) * 2008-02-15 2017-09-05 International Business Machines Corporation Tracking of shared inventory in a virtual universe
US20090210324A1 (en) * 2008-02-15 2009-08-20 Bhogal Kulvir S Tracking of Shared Inventory in a Virtual Universe
US20090235183A1 (en) * 2008-03-12 2009-09-17 Hamilton Rick A Attaching external virtual universes to an existing virtual universe
US8539364B2 (en) * 2008-03-12 2013-09-17 International Business Machines Corporation Attaching external virtual universes to an existing virtual universe
US20090248862A1 (en) * 2008-03-26 2009-10-01 Brother Kogyo Kabushiki Kaisha Device and Computer Readable Medium
US8782205B2 (en) * 2008-03-26 2014-07-15 Brother Kogyo Kabushiki Kaisha Device and computer readable medium
US20100009747A1 (en) * 2008-07-14 2010-01-14 Microsoft Corporation Programming APIS for an Extensible Avatar System
US20100023885A1 (en) * 2008-07-14 2010-01-28 Microsoft Corporation System for editing an avatar
US8446414B2 (en) 2008-07-14 2013-05-21 Microsoft Corporation Programming APIS for an extensible avatar system
US20100026698A1 (en) * 2008-08-01 2010-02-04 Microsoft Corporation Avatar items and animations
US8384719B2 (en) 2008-08-01 2013-02-26 Microsoft Corporation Avatar items and animations
US8276084B2 (en) * 2009-06-01 2012-09-25 International Business Machines Corporation Peer-to-peer based content delivery in a virtual universe
US20100306675A1 (en) * 2009-06-01 2010-12-02 International Business Machines Corporation Peer-to-peer based content delivery in a virtual universe
US20100331084A1 (en) * 2009-06-24 2010-12-30 Aperture Investments Llc System and method for a wrap-around gaming experience
US9251318B2 (en) 2009-09-03 2016-02-02 International Business Machines Corporation System and method for the designation of items in a virtual universe
US8788952B2 (en) * 2009-09-03 2014-07-22 International Business Machines Corporation System and method for locating missing items in a virtual universe
US20110055733A1 (en) * 2009-09-03 2011-03-03 International Business Machines Corporation System and Method for Locating Missing Items in a Virtual Universe
US9882961B2 (en) * 2009-12-02 2018-01-30 International Business Machines Corporation System and method for abstraction of objects for cross virtual universe deployment
US20130254336A1 (en) * 2009-12-02 2013-09-26 International Business Machines Corporation System and method for abstraction of objects for cross virtual universe deployment
US20110219062A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and Method for Two Way Communication and Controlling Content on a Display Screen
US8171145B2 (en) * 2010-03-05 2012-05-01 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US20110219130A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US8166181B2 (en) * 2010-03-05 2012-04-24 Brass Monkey, Inc. System and method for two way communication and controlling content on a display screen
US9269233B2 (en) 2010-07-21 2016-02-23 Bally Gaming, Inc. Poker game system and system with a secondary award feature having an expected value dependent on the ranking of a primary game outcome
US8613674B2 (en) 2010-10-16 2013-12-24 James Charles Vago Methods, devices, and systems for video gaming
US9058717B2 (en) 2010-11-02 2015-06-16 Wms Gaming Inc. Multi-game video poker machine and system with asymmetrically accessible customization features
US8613648B2 (en) 2010-11-02 2013-12-24 Wms Gaming Inc. Multi-game video poker machine and system with asymmetrically accessible customization features
US20120311504A1 (en) * 2011-06-03 2012-12-06 Van Os Marcel Extensible architecture for navigating a hierarchy
US9827493B2 (en) * 2011-09-29 2017-11-28 Sony Interactive Entertainment Europe Limited Gaming assistance system and method
US20150105154A1 (en) * 2011-09-29 2015-04-16 Sony Computer Entertainment Europe Limited Gaming assistance system and method
US9669310B2 (en) 2011-09-29 2017-06-06 Sony Computer Entertainment Europe Limited Gaming assistance system and method
US20130104025A1 (en) * 2011-10-20 2013-04-25 Microsoft Corporation Enabling immersive search engine home pages
US9108112B2 (en) * 2011-12-01 2015-08-18 Nintendo Co., Ltd. Game system, game apparatus, storage medium, and game controlling method for game play using a plurality of game apparatuses
US20130143667A1 (en) * 2011-12-01 2013-06-06 Nintendo Co., Ltd. Game system, game apparatus, storage medium and game controlling method
US9237115B2 (en) 2012-02-14 2016-01-12 Empire Technology Development Llc Load balancing in cloud-based game system
US9531797B2 (en) 2012-02-14 2016-12-27 Empire Technology Development Llc Load balancing in cloud-based game system
US9037725B2 (en) * 2012-10-18 2015-05-19 Bigpoint Inc. Online game system, method, and computer-readable medium
US20140115144A1 (en) * 2012-10-18 2014-04-24 Bigpoint Inc. Online game system, method, and computer-readable medium
US20140113727A1 (en) * 2012-10-18 2014-04-24 Bigpoint Inc. Online game system, method, and computer-readable medium
WO2015012786A1 (en) * 2013-07-22 2015-01-29 Empire Technology Development Llc Game load management
US9358467B2 (en) 2013-07-22 2016-06-07 Empire Technology Development Llc Game load management
US9694280B2 (en) * 2013-11-15 2017-07-04 Sony Interactive Entertainment America Llc Systems and methods for providing cross platform access to interactive content
US20150141120A1 (en) * 2013-11-15 2015-05-21 Ol2, Inc. Systems and methods for providing cross platform access to interactive content
US20160269178A1 (en) * 2015-03-09 2016-09-15 Crowd Ip Box Ug (Haftungsbeschraenkt) Privacy-Enhanced Biometrics-Secret Binding Scheme

Also Published As

Publication number Publication date Type
RU2008150478A (en) 2010-06-27 application
JP2009540920A (en) 2009-11-26 application
EP2036021A1 (en) 2009-03-18 application
KR20090021172A (en) 2009-02-27 application
CN101473341A (en) 2009-07-01 application
WO2007149147A1 (en) 2007-12-27 application

Similar Documents

Publication Publication Date Title
Schilling Technological leapfrogging: Lessons from the US video game console industry
Consalvo Cheating: Gaining advantage in videogames
US7729946B2 (en) Online game advertising system
US7822809B2 (en) Creating an interactive gaming environment
US20100287011A1 (en) Method and System of Location-Based Game for Improving Mobile Operator's Profit
US20020002074A1 (en) Method for an online player game payment system
US8137193B1 (en) Supply delivery for interactive social games
Kabus et al. Addressing cheating in distributed MMOGs
US20080004093A1 (en) Methods and System for Creating In Game Objects
US20020120722A1 (en) Computer system and usage method thereof
US20120021835A1 (en) Systems and methods for server based video gaming
Shapiro et al. The art of standards wars
US7955175B1 (en) Role based game play on a social network
US20080113809A1 (en) Achievement incentives within a console-based gaming environment
US5964660A (en) Network multiplayer game
US6745236B1 (en) Networked computer game system with persistent playing objects
US20080004094A1 (en) Method and System to Provide Inventory Management in a Virtual Environment
US20060148568A1 (en) Device and method for wirelessly accessing game media
US20100167823A1 (en) Systems and methods for accessing online content during online gaming
US20080070690A1 (en) Credit Cards in a Virtual Environment
US20080026847A1 (en) Massive Multi Player Online Video Game that Progresses in Eras
US20040128145A1 (en) Digital content selling method and system using communication network
US20120231891A1 (en) Systems and methods of virtual goods trading using ratings to ascribe value to virtual goods
US6758746B1 (en) Method for providing customized interactive entertainment over a communications network
US20080039166A1 (en) Systems and methods for multi-character online gaming

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STAMPER, TIMOTHY;MACHACEK, PAUL;STAMPER, CHRISTOPHER;REEL/FRAME:018197/0503

Effective date: 20060829

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0509

Effective date: 20141014