ON-LINE GAMING AUTHENTICATION
A game device, such as a game console or a PC, is authenticated before joining an online gaming session. When the device registers with the gaming service, the device is queried for its system type (e.g., XBOX®, XBOX® 360, and PC) and a device identifier (e.g., serial number). The first time the device registers with the gaming service, the devices system type and identifier are stored. Each subsequent time the device registers with the gaming system, the device query response is compared with the stored system type and identifier. If the system type and identifier match, the device is allowed to participate in the game session. Additionally, the device system type is analyzed to determine if the device is allowed to participate in the game session. For example, a PC would not be allowed to participate in an XBOX® only game session.
Latest Microsoft Patents:
The technical field relates generally to computer processing and more specifically to online gaming.
BACKGROUNDIn today's gaming environment, multi-player online gaming is common. In some scenarios, players utilize different classes of systems. For example, during a game session, one player can utilize an XBOX 360 system, another player an XBOX system, another player a Personal Computer (PC), or combinations thereof. A problem with utilizing multiple classes of systems in a multi-player game session is that some classes of systems have weaker inherent security mechanisms than other classes of systems. For example, a PC may be modifiable to perform actions that are not possible with an XBOX 360 system (e.g., hacking the PC to alter game parameters such as provide additional ammunition, alter debuggers, or the like).
SUMMARYThis Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description Of Illustrative Embodiments. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A system is authenticated before joining an online gaming session. In an example embodiment, an online service authenticates machine types before allowing each machine to join a session. When a machine registers to join the online service, the machine is requested to identify and authenticate its type (e.g., XBOX®, PC, XBOX® 360). Also, the machine is queried for an identifier (ID) indicative of the specific machine, such as a serial number or the like. Thereafter, each time a machine attempts to join a session, the machine is evaluated to determine if the machine type and ID match. Also, the machine is evaluated to determine if the machine type is allowed to participate in the session (e.g., PC may not be allowed to participate in an XBOX® only game session). If the machine is not of the proper type and/or the machine type and ID do not match, appropriate action is taken by the service, such as preventing the machine from joining the session, or the like.
The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating online gaming authentication, there is shown in the drawings exemplary constructions thereof, however, online gaming authentication is not limited to the specific methods and instrumentalities disclosed.
The secure gateway 12 authenticates each machine that attempts to enter a game session. Machines are represented, in
To join an online game session, a machine provides a request to the secure gateway 12 to participate in the game session. The secure gateway 12 queries the machine attempting to enter the session (the requesting machine) for an indication of system type and an indication of the identity (ID) of the machine. Upon receiving a response to the query, the secure gateway 12 provides information pertaining to the requesting machine to a machine hosting the game session, or to a selected machine already participating in the game session. The information comprises at least the indication of system type and the ID of the requesting machine. The selected machine determines if the requesting machine is allowed to participate in the game session in accordance with the system type and ID. If the requesting machine is allowed to participate in the game session, the requesting machine can participate in the game session via the secure gateway 12, and/or directly with the selected machine. If the selected machine determines that the requested machine is not allowed to participate in the game session, the request is denied. In an example embodiment, if the requesting machine is allowed to participate in the game session, the selected machine informs the secure gateway 12 that the requesting machine is allowed to participate in the game session and the secure gateway 12 issues a session ticket, or the like, allowing the establishment of a secure channel between the requesting machine and the selected machine (e.g., host machine).
For example, assume the following: the machine 14 has previously been authenticated, the system type of the machine 14 is XBOX®, the system type of the machine 16 is XBOX®, the system type of the machine 26 is PC, and the game session is an XBOX® only game session. When the machine 16 requests to participate in the game session being hosted by the machine 14, the secure gateway 12 queries the machine 16 for system type and ID. The machine 16 provides to the secure gateway 12, via interface 22, an indication of the system type and ID. The secure gateway 12 analyzes the response and determines that the system type of the machine 16 is XBOX® and the system type and ID are valid. The secure gateway 12 provides, to the machine 16, a session ticket or the like, to allow the machine 14 and the machine 16 to establish a secure channel 18 for communication therebetween. When the machine 26 requests, via interface 24, to participate in the game session being hosted by the machine 14, the secure gateway 12 queries the machine 26 for system type and ID. The machine 26 provides to the secure gateway 12 an indication of the system type and ID. The secure gateway 12 analyzes the response and determines that the system type of the machine 16 is PC and the system type and ID are valid. Because the game session is an XBOX® only game session, the secure gateway 12 does not provide a session ticket or the like to the machine 26.
In an example embodiment, one machine functions as a host of a game session (e.g., the machine 14 in
For example, assume machine 16 wants to connect to machine 14 to participate in a game session hosted by machine 14. The machine 14 will not accept a request directly from the machine 16 to join the game session. So, instead of the machine 16 sending a connection request directly to machine 14, the machine 16 sends to the secure gateway 12, along with authorization data pertaining to the machine 16, a request to forward the connection request to machine 14. The authorization data includes the machine's 16 type and ID, and optionally other data such as the ID of the user on the machine 16, the privileges of the user on the machine 16 (e.g., is the user of machine 16 allowed to talk over the microphone during the game session, or the like). The secure gateway 12 determines if the authorization data is valid. For example, the secure gateway 12 can compare the authorization data with information stored in the secure gateway 12 pertaining to the machine 16. If the secure gateway 12 determines that the authorization data is not valid, the request by the machine 16 to forward the connection request to the machine 14 is denied. If the secure gateway 12 determines that the authentication data is valid, the secure gateway 12 provides, to the machine 14, the connection request from the machine 16.
The machine 14, utilizing the forwarded connection request from the secure gateway 12, establishes a connection for game play with the machine 16. During the connection process, the machine 16 can not lie about its type of machine, because the secure gateway 12 knows what type of machine it is and will verify same. Upon the connection request being forwarded to the machine 14, subsequent communications between the machine 14 and the machine 16 can occur directly between the two machines 14, 16. It is the initial connect request that is forwarded and verified via the secure gateway 12.
A another example, assume the following: the machine 14, the machine 16, and the machine 26 have previously been authenticated to the secure gateway 12; the system type of the machine 14 is XBOX®; the system type of the machine 16 is XBOX®; the system type of the machine 26 is PC; and the game session is an XBOX® only game session. When the machine 16 sends a request, via the interface 22, to the secure gateway 12 to participate in the game session being hosted by the machine 14, the secure gateway 12 queries the machine 16 for system type and ID. The machine 16 provides to the secure gateway 12, via interface 22, an indication of the system type and ID. The secure gateway 12 analyzes the response and determines that the system type of the machine 16 and ID are valid. The secure gateway 12 forwards the request from the machine 16 to the machine 14. The machine 14 initiates establishment of a secure channel 18 for communication between the machine 14 and the machine 16. When the machine 26 provides a request, via the interface 24, to participate in the game session being hosted by the machine 14, the secure gateway 12 queries the machine 26 for system type and ID. The machine 26 provides to the secure gateway 12 an indication of the system type and ID. The secure gateway 12 analyzes the response and determines that the system type and ID of the machine 16 are valid. The secure gateway 12 forwards the request from the machine 26 to the machine 14. The machine 14, because the game session is an XBOX® only game session, does not allow the machine 16 to participate in the game session. Thus, the machine 14 does not initiate the establishment of a secure channel (e.g., via the interface 28) between the machine 14 and the machine 26 for the game session.
In an example embodiment, one machine functions as a host of a game session (e.g., the machine 14 in
At step 40, it is determined if it is the first time that the particular machine requesting to participate in the online game session has made such a request. This can be determined, for example by analyzing stored information pertaining to system types and corresponding ID. This can be accomplished, for example, by analyzing table 30 for an ID matching the ID received in the response. If it is the first time (e.g., no ID matching the received ID is found in table 30), the received system type and ID are associated and stored at step 42. The system type and ID can be stored in any appropriate type of storage medium, such as semiconductor memory, magnetic memory, optical memory, flash memory, or a combination thereof, for example. At step 50, the request to join a game session is forward to a selected machine, such as a machine hosting the game session for example. At step 52, it is determined if the received system type is allowed to participate in the online game session. For example, a game session can be limited to one type of system (e.g., XBOX®). If the system type is allowed (at step 52), the request to participate in the online game session is granted at step 53. If, at step 50, the system type is not allowed, the request to participate in the online game session is denied at step 48.
If at step 40, if it is determined that it is not the first time the particular machine requesting to participate in the online game session has made such a request, the received system type and ID (received in the response to the query) are compared to the stored system type and ID associated therewith for that machine, at step 44. This can be accomplished, for example, by comparing the received system type and ID with the corresponding ID and system type associated therewith stored in table 30. At step 46 it is determined if the received system type and ID are valid. For example, if the received system type and ID match the stored system type and ID for a respective machine, the received system type and ID are valid. If the received system type and ID do not match the stored system type and ID for a respective machine, the received system type and ID are not valid. If, at step 46, it is determined that the received system type and ID are not valid, the request to participate in the online game session is denied at step 48. In an example embodiment, the request to join a game session is not forward to a selected machine, such as a machine hosting the game session, at step 48. If, at step 46, it is determined that the received system type and ID are valid, the process proceeds to step 50 and continues as described above.
The processing portion 56 is capable of performing online gaming authentication as described above. For example, the processing portion 56 is capable of determining if a machine is requesting to participate in an online game session for the first time, comparing stored system type and ID with received system type and ID, determining if a system type is allowed to participate in a game session, allow participation in an online game session, deny participation in an online game session, or a combination thereof.
The processor 54 can be implemented as a client processor and/or a server processor. In a basic configuration, the processor 54 can include at least one processing portion 56 and memory portion 58. The memory portion 58 can store any information utilized in conjunction with performing online gaming authentication. For example, the memory portion 58 can store indications of system types, indications of machine IDs, or a combination thereof. Depending upon the exact configuration and type of processor, the memory portion 58 can be volatile (such as RAM) 62, non-volatile (such as ROM, flash memory, etc.) 64, or a combination thereof. The processor 54 can have additional features/functionality. For example, the processor 54 can include additional storage (removable storage 66 and/or non-removable storage 68) including, but not limited to, magnetic or optical disks, tape, flash, smart cards or a combination thereof. Computer storage media, such as memory portion 58, 62, 64, 66, and 68, include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, universal serial bus (USB) compatible memory, smart cards, or any other medium which can be used to store the desired information and which can be accessed by the processor 54. Any such computer storage media can be part of the processor 54.
The processor 54 can also contain communications connection(s) 74 that allow the processor 54 to communicate with other devices, such as other devices, for example. Communications connection(s) 56 is an example of communication media. Communication media typically embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media. The processor 54 also can have input device(s) 72 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 70 such as a display, speakers, printer, etc. also can be included.
A computer system can be roughly divided into three component groups: the hardware component, the hardware/software interface system component, and the applications programs component (also referred to as the “user component” or “software component”). In various embodiments of a computer system the hardware component may comprise the central processing unit (CPU) 521, the memory (both ROM 564 and RAM 525), the basic input/output system (BIOS) 566, and various input/output (I/O) devices such as a keyboard 540, a mouse 562, a monitor 547, and/or a printer (not shown), among other things. The hardware component comprises the basic physical infrastructure for the computer system.
The applications programs component comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users). In an example embodiment, application programs perform the functions associated with online gaming authentication as described above.
The hardware/software interface system component comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel. An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system. A purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.
The hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system. The application programs interact with the hardware/software interface system by requesting services via an application program interface (API). Some application programs enable end-users to interact with the hardware/software interface system via a user interface such as a command language or a graphical user interface (GUI).
A hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.
A hardware/software interface system shell (referred to as a “shell”) is an interactive end-user interface to a hardware/software interface system. (A shell may also be referred to as a “command interpreter” or, in an operating system, as an “operating system shell”). A shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users. In contrast to a shell, a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.
As shown in
A number of program modules can be stored on the hard disk, magnetic disk 529, optical disk 531, ROM 564, or RAM 525, including an operating system 535, one or more application programs 536, other program modules 537, and program data 538. A user may enter commands and information into the computing device 560 through input devices such as a keyboard 540 and pointing device 562 (e.g., mouse). Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to the processing unit 521 through a serial port interface 546 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 547 or other type of display device is also connected to the system bus 523 via an interface, such as a video adapter 548. In addition to the monitor 547, computing devices typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary environment of
The computing device 560 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 549. The remote computer 549 may be another computing device (e.g., personal computer), a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computing device 560, although only a memory storage device 550 (floppy drive) has been illustrated in
When used in a LAN networking environment, the computing device 560 is connected to the LAN 551 through a network interface or adapter 553. When used in a WAN networking environment, the computing device 560 can include a modem 554 or other means for establishing communications over the wide area network 552, such as the Internet. The modem 554, which may be internal or external, is connected to the system bus 523 via the serial port interface 546. In a networked environment, program modules depicted relative to the computing device 560, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
While it is envisioned that numerous embodiments of online gaming authentication are particularly well-suited for computerized systems, nothing in this document is intended to limit the invention to such embodiments. On the contrary, as used herein the term “computer system” is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.
The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatuses for implementing online gaming authentication, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for implementing online gaming authentication.
The program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations. The methods and apparatuses for implementing online gaming authentication also can be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of online gaming authentication. Additionally, any storage techniques used in connection with online gaming authentication can invariably be a combination of hardware and software.
While online gaming authentication has been described in connection with the example embodiments of the various figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same functions of online gaming authentication without deviating therefrom. Therefore, online gaming authentication as described herein should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.
Claims
1. A method for online gaming authentication, the method comprising:
- providing a query for a requester system type and requester identification;
- responsive to providing the query, receiving a query response comprising a requester system type and requester identification;
- determining if the received requester system type and received requester identification are valid;
- if the received requester system type and received requester identification are determined to be valid, forwarding the request to participate in the online game session; and
- if the received requester system type and received requester identification are determined to be not valid, denying the request to participate.
2. A method in accordance with claim 1, further comprising:
- determining if the received requester system type is an allowed system type; and
- if the received requester system type is not an allowed system type, denying the request to participate.
3. A method in accordance with claim 2, wherein a received requester system type is determined to not be an allowed system type if the online game session is limited to other than the received requester system type.
4. A method in accordance with claim 1 further comprising, determining if the received requester identification was included in a previous query response.
5. A method in accordance with claim 4, further comprising, if the received requester identification was not included in a previous query response, storing the received requester system type and received requester identification of the query response.
6. A method in accordance with claim 5, further comprising:
- if the received requester identification was included in a previous query response, comparing the received requester system type and received requester identification with the stored requester system type and requester identification; and
- if the received requester system type and received requester identification match the stored requester system type and requester identification, determining that the received requester system type and received requester identification are valid.
7. An online gaming authentication system comprising:
- an input/output portion configured to: provide a query for a requester system type and requester identification; receive a query response comprising a requester system type and requester identification; and forward the request to participate in the online game session;
- a processor portion configured to: determine if the received requester system type and received requester identification are valid; if the received requester system type and received requester identification are determined to be valid, forward the request to participate; and if the received requester system type and received requester identification are determined to be not valid, deny the request to participate; and
- a memory portion configured to store the received requester system type and received requester identification.
8. A system in accordance with claim 7, the processor portion further configured to:
- determine if the received requester system type is an allowed system type; and
- if the received requester system type is not an allowed system type, deny the request to participate.
9. A system in accordance with claim 8, wherein a received requester system type is determined to not be an allowed system type if the online game session is limited to other than the received requester system type.
10. A system in accordance with claim 7 the processor portion further configured to determine if the received requester identification was included in a previous query response.
11. A system in accordance with claim 10, the processor portion further configured to, if the received requester identification was not included in a previous query response, store, in the memory portion, the received requester system type and received requester identification of the query response.
12. A system in accordance with claim 11, the processor portion further configured to:
- if the received requester identification was included in a previous query response, compare the received requester system type and received requester identification with the stored requester system type and requester identification; and
- if the received requester system type and received requester identification match the stored requester system type and requester identification, determine that the received requester system type and received requester identification are valid.
13. A computer-readable medium having stored thereon computer-executable instruction for online gaming authentication, by performing the steps of:
- providing a query for a requester system type and requester identification; responsive to providing the query, receiving a query response comprising a requester system type and requester identification;
- determining if the received requester system type and received requester identification are valid;
- if the received requester system type and received requester identification are determined to be valid, forwarding the request to participate;
- if the received requester system type and received requester identification are determined to be not valid, denying the request to participate; and
- storing the received requester system type and received requester identification.
14. A computer-readable medium in accordance with claim 13, the computer-executable instructions further for:
- determining if the received requester system type is an allowed system type; and
- if the received requester system type is not an allowed system type, denying the request to participate.
15. A computer-readable medium in accordance with claim 14, wherein a received requester system type is determined to not be an allowed system type if the online game session is limited to other than the received requester system type.
16. A computer-readable medium in accordance with claim 13 the computer-executable instructions further for determining if the received requester identification was included in a previous query response.
17. A computer-readable medium in accordance with claim 16, the computer-executable instructions further for, if the received requester identification was not included in a previous query response, storing the received requester system type and received requester identification of the query response.
18. A computer-readable medium in accordance with claim 17, the computer-executable instructions further for:
- if the received requester identification was included in a previous query response, comparing the received requester system type and received requester identification with the stored requester system type and requester identification; and
- if the received requester system type and received requester identification match the stored requester system type and requester identification, determining that the received requester system type and received requester identification are valid.
Type: Application
Filed: Mar 30, 2007
Publication Date: Oct 2, 2008
Applicant: Microsoft Corporation (Redmond, WA)
Inventors: Ling Tony Chen (Bellevue, WA), Daniel Monteiro Casasanta Caiafa (Redmond, WA)
Application Number: 11/694,284
International Classification: A63F 9/24 (20060101);