U.S. patent application number 11/425258 was filed with the patent office on 2007-12-20 for transfer of features between gaming devices.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Paul Machacek, Christopher Stamper, Timothy Stamper.
Application Number | 20070293319 11/425258 |
Document ID | / |
Family ID | 38833721 |
Filed Date | 2007-12-20 |
United States Patent
Application |
20070293319 |
Kind Code |
A1 |
Stamper; Timothy ; et
al. |
December 20, 2007 |
Transfer of Features Between Gaming Devices
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.
Inventors: |
Stamper; Timothy; (Twycross,
GB) ; Machacek; Paul; (Twycross, GB) ;
Stamper; Christopher; (Twycross, GB) |
Correspondence
Address: |
LEE & HAYES PLLC
421 W RIVERSIDE AVENUE SUITE 500
SPOKANE
WA
99201
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
38833721 |
Appl. No.: |
11/425258 |
Filed: |
June 20, 2006 |
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 13/75 20140902;
A63F 2300/5533 20130101; G06Q 30/06 20130101; A63F 2300/552
20130101; A63F 13/12 20130101; A63F 2300/609 20130101; A63F 13/77
20140902; A63F 2300/5586 20130101 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
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. 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. 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. 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. 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. 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. 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. A method according to claim 1, wherein the code relating to a
required feature comprises ownership information.
9. A method according to claim 8, wherein the ownership information
identifies a gaming device, a gamer or a group of gamers.
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. 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. 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. 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. 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. 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. A method according to claim 13, wherein the code relating to
the set of required features is received from the remote
device.
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. A method according to claim 17, wherein the remote device is
one of the plurality of gaming devices.
19. A method according to claim 13, wherein the remote device
comprises a server.
Description
BACKGROUND
[0001] Games consoles, such as Xbox 360.TM., 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.TM.) connected together via a server 102 (e.g. an Xbox
Live.RTM. 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 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. 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 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.
[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.RTM., Xbox360.TM. 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.
* * * * *