WO2007149147A1 - Transfer of features between gaming devices - Google Patents
Transfer of features between gaming devices Download PDFInfo
- Publication number
- WO2007149147A1 WO2007149147A1 PCT/US2007/010445 US2007010445W WO2007149147A1 WO 2007149147 A1 WO2007149147 A1 WO 2007149147A1 US 2007010445 W US2007010445 W US 2007010445W WO 2007149147 A1 WO2007149147 A1 WO 2007149147A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- gaming devices
- features
- game
- gaming
- feature
- Prior art date
Links
Classifications
-
- A63F13/12—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/70—Game security or game management aspects
- A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/70—Game security or game management aspects
- A63F13/75—Enforcing rules, e.g. detecting foul play or generating lists of cheating players
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features 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/50—Features 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/55—Details of game data or player data management
- A63F2300/552—Details 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
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features 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/50—Features 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/55—Details of game data or player data management
- A63F2300/5526—Game data structure
- A63F2300/5533—Game 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
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features 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/50—Features 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/55—Details of game data or player data management
- A63F2300/5586—Details of game data or player data management for enforcing rights or rules, e.g. to prevent foul play
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features 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/60—Methods for processing data by generating or executing the game program
- A63F2300/609—Methods for processing data by generating or executing the game program for unlocking hidden game elements, e.g. features, items, levels
Definitions
- Games consoles such as Xbox 360TM
- Xbox 360TM have been developed which enable a gamer to play games with other gamers over a network.
- the game play is controlled by a server although the software for running the game resides on the individual games consoles.
- each gamer 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.
- 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.
- 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.
- FIG. 1 is a schematic diagram of a network of gaming devices
- FIG- 2 shows an example flow diagram of the operation of a server
- FIGS. 3 & 4 show example flow diagrams of steps of the flow diagram in FIG.2 in more detail
- FIG. 5 shows the virtual positions of many characters in a game world
- FIG. 6 shows an example flow diagram of a method of limiting the transfer of features
- FIG. 7 shows an example flow diagram of a step of the flow diagram in FIG.2 in more detail
- FIG. 8 shows a schematic diagram of a console
- FIG. 9 shows an example flow diagram for the purging of data
- FIG. 10 shows a schematic diagram of a server
- FIG. 11 is a schematic diagram of another network of gaming devices.
- FIG. 1 is a schematic diagram of a network 100 of gaming devices.
- the network comprises four gaming devices 101 (e.g. Xbox 360TM) 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).
- 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).
- the game can start (not shown in FIG. 2).
- a common scripting language may be used to transfer the features.
- XML extensible mark-up language
- the server may not have the required code to enable it to distribute the code to the gaming devices without it.
- the server may first identify the differences (step 203a) and then identify what code it does not hold (step 203b). Having identified what code it needs (in step 203b), the server then uploads that code not held at the server from a gaming device which does hold the code (step 204a) and then transfers the differences to all devices as required (step 204b), as described above.
- the features 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.
- 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).
- 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.
- Polling of devices 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).
- 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.
- the code relating to a particular feature e.g. a new weapon
- 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.
- LOD level of detail
- 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.
- 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.
- an acceptable timeframe e.g. a maximum delay time may be predetermined
- 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.
- this may be upgraded automatically by transferring the higher quality LOD versions in the background, e.g. whilst the game is proceeding.
- FIG. 5 shows the virtual positions of many characters 501-504 in a game world, each character being controlled by a gaming device.
- steps 203 and 204 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.
- an area 505 is defined around the position of a particular character 501 controlled by a 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.
- FIG. 6 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).
- 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.
- 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.
- the subset associated with that gaming device may comprise the sum of multiple subsets, one associated with each of the characters being controlled.
- 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.
- the size of the area used to identify the subset of devices 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.
- 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.
- 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).
- 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.
- 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.
- more than one area may be defined around each character to determine a plurality of subsets of devices associated with each device.
- 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.
- 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.
- 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.
- feature code may exist in multiple different quality versions.
- 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.
- 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.
- 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).
- the set of features to be transferred was determined based on the locations of characters (as shown in FIG. 5).
- 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.
- 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.
- 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).
- the multiple areas which may be defined 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.
- 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.
- 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.
- 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 gamer who purchased them) without having to pay for them. Consequentially, it may be advantageous for features to be tagged with ownership information.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- both a central register and individual inventories associated with a gamer / gaming device may be used.
- 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.
- 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.
- 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.
- 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.
- items which (for whatever reason) become "faulty” or “corrupted” may be suspended from use until corrected, or removed altogether.
- 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.
- 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 202a) and for each feature identified in the attribute information, the ownership of each feature is checked (step 202b).
- the received attribute information is then filtered (step 202c) 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.
- 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.
- 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
- 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.
- features with ownership information 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).
- 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).
- 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).
- 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.
- 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).
- 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.
- 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.
- 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.
- 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).
- 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?").
- 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.
- the differences in feature sets held by different gaming devices are transferred to devices to provide a common feature set.
- 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).
- 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.
- 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 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.
- 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.
- 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 100MB free memory etc).
- 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 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.
- 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.
- 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.
- 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.
- the difference calculation is performed centrally by a host (such as a server or a gaming device).
- 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)..
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- features are identified with particular gamers or with the gaming devices with which a gamer is associated.
- 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.
- 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).
- 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.
- 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.
- 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).
- a dedicated circuit such as a DSP, programmable logic array, or the like.
- the terms 'gaming device 1 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®, Xbox360TM etc), computers, PDAs, and mobile telephones.
- dedicated games consoles e.g. Xbox®, Xbox360TM etc
- computers PDAs
- mobile telephones e.g., cellular telephones
- 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).
- 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).
- 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 1 includes PCs, servers, mobile telephones, personal digital assistants and many other devices [0066]
- 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.
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP07756150A EP2036021A1 (en) | 2006-06-20 | 2007-04-30 | Transfer of features between gaming devices |
JP2009516484A JP2009540920A (en) | 2006-06-20 | 2007-04-30 | Feature distribution between game machines |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/425,258 US20070293319A1 (en) | 2006-06-20 | 2006-06-20 | Transfer of Features Between Gaming Devices |
US11/425,258 | 2006-06-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2007149147A1 true WO2007149147A1 (en) | 2007-12-27 |
Family
ID=38833721
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2007/010445 WO2007149147A1 (en) | 2006-06-20 | 2007-04-30 | 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 (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011527051A (en) * | 2008-06-30 | 2011-10-20 | マイクロソフト コーポレーション | A platform independent ecosystem for the creation, consumption and trading of user-created digital content |
Families Citing this family (52)
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 |
EP2127410A4 (en) * | 2007-03-14 | 2010-04-28 | M Biz Global Company Ltd | 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 |
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 |
US7921128B2 (en) * | 2008-02-05 | 2011-04-05 | International Business Machines Corporation | Method and system for merging disparate virtual universes entities |
US8137199B2 (en) * | 2008-02-11 | 2012-03-20 | Microsoft Corporation | 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 |
US8539364B2 (en) * | 2008-03-12 | 2013-09-17 | International Business Machines Corporation | Attaching external virtual universes to an existing virtual universe |
JP4569654B2 (en) * | 2008-03-26 | 2010-10-27 | ブラザー工業株式会社 | device |
US20120246585A9 (en) * | 2008-07-14 | 2012-09-27 | Microsoft Corporation | System for editing an avatar |
US8446414B2 (en) * | 2008-07-14 | 2013-05-21 | Microsoft Corporation | Programming APIS for an extensible avatar system |
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 |
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 |
US8326855B2 (en) * | 2009-12-02 | 2012-12-04 | International Business Machines Corporation | System and method for abstraction of objects for cross virtual universe deployment |
US8024469B1 (en) * | 2010-03-05 | 2011-09-20 | Brass Monkey Inc. | System and method for connecting network sockets between applications |
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 |
WO2012050618A1 (en) | 2010-10-16 | 2012-04-19 | James Charles Vago | Multimedia methods, devices and systems |
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 |
ES2730740T3 (en) * | 2011-09-29 | 2019-11-12 | Sony Interactive Entertainment Europe Ltd | Video game support system and method |
US20130104025A1 (en) * | 2011-10-20 | 2013-04-25 | Microsoft Corporation | Enabling immersive search engine home pages |
JP5986371B2 (en) * | 2011-12-01 | 2016-09-06 | 任天堂株式会社 | GAME SYSTEM, GAME DEVICE, GAME PROGRAM, AND GAME CONTROL METHOD |
US8795087B2 (en) | 2012-02-14 | 2014-08-05 | Empire Technology Development Llc | Load balancing in cloud-based game system |
JP5529924B2 (en) * | 2012-06-04 | 2014-06-25 | 株式会社コナミデジタルエンタテインメント | GAME CONTROL DEVICE, GAME CONTROL METHOD, PROGRAM, GAME SYSTEM, INFORMATION PROCESSING DEVICE |
JP5529923B2 (en) * | 2012-06-04 | 2014-06-25 | 株式会社コナミデジタルエンタテインメント | GAME CONTROL DEVICE, GAME CONTROL METHOD, PROGRAM, GAME SYSTEM, INFORMATION PROCESSING DEVICE |
US9037725B2 (en) * | 2012-10-18 | 2015-05-19 | 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 |
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 |
US10478723B2 (en) | 2014-06-30 | 2019-11-19 | Microsoft Technology Licensing, Llc | Track based play systems |
US10518188B2 (en) | 2014-06-30 | 2019-12-31 | Microsoft Technology Licensing, Llc | Controlling physical toys using a physics engine |
US10537821B2 (en) | 2014-06-30 | 2020-01-21 | Microsoft Technology Licensing, Llc | Interactive play sets |
US10369477B2 (en) | 2014-10-08 | 2019-08-06 | Microsoft Technology Licensing, Llc | Management of resources within a virtual world |
US9696757B2 (en) * | 2014-10-08 | 2017-07-04 | Microsoft Corporation | Transfer of attributes between generations of characters |
DE102016002792B4 (en) * | 2015-03-09 | 2022-04-28 | Hid Global Corporation | Biometric secret binding scheme with enhanced privacy protection |
US10733415B1 (en) | 2015-06-08 | 2020-08-04 | Cross Match Technologies, Inc. | Transformed representation for fingerprint data with high recognition accuracy |
US10456672B2 (en) * | 2016-05-19 | 2019-10-29 | Google Llc | Methods and systems for facilitating participation in a game session |
JP6614462B2 (en) * | 2017-10-06 | 2019-12-04 | 株式会社セガゲームス | Program and information processing apparatus |
EP4336800A2 (en) | 2017-10-10 | 2024-03-13 | Google LLC | Distributed sample-based game profiling with game metadata and metrics and gaming api platform supporting third-party content |
US11140207B2 (en) | 2017-12-21 | 2021-10-05 | Google Llc | Network impairment simulation framework for verification of real time interactive media streaming systems |
WO2019182752A1 (en) | 2018-03-22 | 2019-09-26 | Google Llc | Methods and systems for rendering and encoding content for online interactive gaming sessions |
US11077364B2 (en) * | 2018-04-02 | 2021-08-03 | Google Llc | Resolution-based scaling of real-time interactive graphics |
KR102493861B1 (en) | 2018-04-02 | 2023-01-31 | 구글 엘엘씨 | Methods, devices and systems for interactive cloud gaming |
CN111417978A (en) | 2018-04-10 | 2020-07-14 | 谷歌有限责任公司 | Memory management in game rendering |
EP3807766B1 (en) | 2018-11-16 | 2021-10-27 | Google LLC | Shadow tracking of real-time interactive simulations for complex system analysis |
US11571626B2 (en) | 2020-11-02 | 2023-02-07 | Microsoft Technology Licensing, Llc | Software ownership validation of optical discs using secondary device |
JP2024003390A (en) * | 2022-06-27 | 2024-01-15 | 任天堂株式会社 | System, program, method, and information processing device |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5772512A (en) * | 1996-07-31 | 1998-06-30 | Clutchability, L.L.C. | Electronic football game |
KR20000037507A (en) * | 2000-04-29 | 2000-07-05 | 강서규 | 'MutiBahng' Network Business Model |
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 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0965084A1 (en) * | 1996-03-21 | 1999-12-22 | MPATH Interactive Inc. | Network match maker for selecting clients based on attributes of servers and communication links |
US20030014513A1 (en) * | 2000-12-27 | 2003-01-16 | Ruths Derek Augustus Samuel | System and method for collaborative data resource representation |
JP4280901B2 (en) * | 2002-02-05 | 2009-06-17 | 株式会社セガ | Voice chat system |
KR20040042121A (en) * | 2002-11-13 | 2004-05-20 | 주식회사 엔씨소프트 | A method and apparatus for providing on-line game |
JP4073885B2 (en) * | 2003-06-17 | 2008-04-09 | 任天堂株式会社 | GAME SYSTEM, GAME DEVICE, AND GAME PROGRAM |
US20050143174A1 (en) * | 2003-08-19 | 2005-06-30 | Goldman Daniel P. | Systems and methods for data mining via an on-line, interactive game |
US20060183550A1 (en) * | 2005-02-08 | 2006-08-17 | Gagner Mark B | Information transfer to gaming machines |
-
2006
- 2006-06-20 US US11/425,258 patent/US20070293319A1/en not_active Abandoned
-
2007
- 2007-04-30 JP JP2009516484A patent/JP2009540920A/en not_active Withdrawn
- 2007-04-30 KR KR1020087030868A patent/KR20090021172A/en not_active Application Discontinuation
- 2007-04-30 EP EP07756150A patent/EP2036021A1/en not_active Withdrawn
- 2007-04-30 CN CNA2007800228726A patent/CN101473341A/en active Pending
- 2007-04-30 RU RU2008150478/09A patent/RU2008150478A/en not_active Application Discontinuation
- 2007-04-30 WO PCT/US2007/010445 patent/WO2007149147A1/en active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5772512A (en) * | 1996-07-31 | 1998-06-30 | Clutchability, L.L.C. | Electronic football game |
KR20000037507A (en) * | 2000-04-29 | 2000-07-05 | 강서규 | 'MutiBahng' Network Business Model |
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 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011527051A (en) * | 2008-06-30 | 2011-10-20 | マイクロソフト コーポレーション | A platform independent ecosystem for the creation, consumption and trading of user-created digital content |
Also Published As
Publication number | Publication date |
---|---|
JP2009540920A (en) | 2009-11-26 |
CN101473341A (en) | 2009-07-01 |
EP2036021A1 (en) | 2009-03-18 |
RU2008150478A (en) | 2010-06-27 |
US20070293319A1 (en) | 2007-12-20 |
KR20090021172A (en) | 2009-02-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20070293319A1 (en) | Transfer of Features Between Gaming Devices | |
US9895612B2 (en) | Platform for associating characteristics of a digital asset with multiple media sources | |
KR101309396B1 (en) | Non-transitory computer-readable record medium, game system and information processing device | |
US8533076B2 (en) | Online game commerce system | |
US9138647B2 (en) | Game play skill training | |
US8388440B2 (en) | Network account linking | |
CN103262065A (en) | Method and system for transferring application state | |
CN101329707A (en) | System and method for providing rank of game head portrait | |
KR20130116956A (en) | Secure transfer of online privileges including non-financial options | |
WO2009102308A1 (en) | Systems methods and computer program products for remotely controlling actions of a virtual world identity | |
KR100479956B1 (en) | caracter management system and service method thereof | |
KR101781250B1 (en) | Game service method and system | |
US20150224399A1 (en) | Systems and methods for managing gameplay history | |
US11457277B2 (en) | Context-based action suggestions | |
US20230372823A1 (en) | System and Method for Providing Conditional Access to Virtual Gaming Items | |
KR101229728B1 (en) | Method and server for inviting companion in online game | |
US20130281214A1 (en) | Game system | |
KR101986253B1 (en) | Game item traiding intermediation method and game item traiding intermediation apparatus | |
KR20130037778A (en) | Method and device for providing character transferring service using that | |
CN102262708A (en) | Method for displaying information about use of hack tool in online game | |
CN111318016B (en) | Map element display method and device, storage medium and electronic device | |
KR101183731B1 (en) | Method and server for providing service of using item | |
KR101178325B1 (en) | Method and system for controlling team play of online game | |
JP7174913B2 (en) | Game program, server device and game system | |
KR102060519B1 (en) | Method and apparatus providing game service for settlement of user based on analysis of user data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200780022872.6 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07756150 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020087030868 Country of ref document: KR |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2008150478 Country of ref document: RU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2009516484 Country of ref document: JP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2007756150 Country of ref document: EP |