ON-LINE GAMING AUTHENTICATION

Abstract

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.

Description

TECHNICAL FIELD

The technical field relates generally to computer processing and more specifically to online gaming.

BACKGROUND

In 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).

SUMMARY

This 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

FIG. 1 is a block diagram of an example system for implementing online gaming authentication.

FIG. 2 is a depiction of an example table comprising system types and corresponding machine IDs.

FIG. 3 is a flow diagram of an example process for online gaming authentication.

FIG. 4 is a diagram of an exemplary processor for online gaming authentication.

FIG. 5 is a depiction of a suitable computing environment in which online gaming authentication can be implemented.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG. 1 is a block diagram of an example system for implementing online gaming authentication. In an example configuration, a secure gateway 12 performs authentication. The secure gateway 12 can comprise any appropriate processor and/or service configured to perform authentication. For example, the secure gateway 12 can comprise a component (e.g. server) of a gaming service, such as an XBOX® LIVE service, and/or the secure gateway 12 can represent the service.

The secure gateway 12 authenticates each machine that attempts to enter a game session. Machines are represented, in FIG. 1, by machine 14, machine 16 through machine 26. Any appropriate number of machines can be authenticated by the secure gateway 12. A machine can comprise any appropriate device such as an XBOX® console, and XBOX® 360 console, a PC, or a combination thereof, for example. In an example embodiment, the first time a machine registers with an online service, the machine is authenticated by the secure gateway 12. In an example embodiment, the secure gateway 12 queries the machine attempting to enter the session for an indication of system type (e.g., XBOX® 360, XBOX®, PC) and an indication of the identity of the machine. The identity of the machine (ID) can comprise any appropriate indication of the machine such as the serial number of the machine. The authentication information is stored by the secure gateway 12.

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 FIG. 1), and other machines, upon authentication by the secure gateway 12 are provided session tickets or the like, to establish respective secure channels between the host machine and the authenticated machines. A secure channel can comprise any appropriate means secure communications, such as encryption, digital signatures, obfuscation, or a combination thereof. Interfaces 18, 20, 22, 24, and 28 represent interfaces, respectively, between the machine 14 and the secure machine 16, between the machine 14 and the secure gateway 12, between the machine 16 and the secure gateway 12, between the machine 26 and the secure gateway 12, and between the machine 14 and the secure machine 26. Each of the interfaces 18, 20, 22, 24, and 28 can comprises any appropriate interface, such as a wireless interface, a wired interface, a network, or a combination thereof.

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 FIG. 1), and other machines, upon authentication by the secure gateway 12 are provided session tickets or the like, to establish respective secure channels between the host machine and the authenticated machines. A secure channel can comprise any appropriate means secure communications, such as encryption, digital signatures, obfuscation, or a combination thereof. Interfaces 18, 20, 22, 24, and 28 represent interfaces, respectively, between the machine 14 and the secure machine 16, between the machine 14 and the secure gateway 12, between the machine 16 and the secure gateway 12, between the machine 26 and the secure gateway 12, and between the machine 14 and the secure machine 26. Each of the interfaces 18, 20, 22, 24, and 28 can comprises any appropriate interface, such as a wireless interface, a wired interface, a network, or a combination thereof.

FIG. 2 is a depiction of an example table 30 comprising system types and corresponding machine IDs. When the secure gateway 12 (See FIG. 1) receives the system type and ID of a machine attempting to participate in a game session, the secure gateway 12 determines if the system type and ID are valid. In an example embodiment, the first time the secure gateway 12 receives the system type and ID for a specific machine, the secure gateway 12 associates the received system type and ID and stores the received system type and ID in the table 30. When that machine subsequently attempts to enter a game session, the secure gateway 12 queries the machine, and checks the received system type and ID with the system type and ID stores in the table 30 for that machine. If the received system type and ID match the stored system type and ID, the secure gateway 12 determines that the system type and ID are valid, and take appropriate action, such as forwarding a request to join a game session to a host machine. If the received system type and ID do not match the stored system type and ID, the secure gateway 12 determines that the received system type and ID are not valid, and the secure gateway 12 takes appropriate action, such as not forwarding a request to join a game session to a host machine.

FIG. 3 is a flow diagram of an example process for online gaming authentication. As described above, a query for a system type and machine ID are provided at step 34. In an example embodiment, the query is in response to a request to participate in an online game session, the query is provided during an authentication process, or the like. As described above, the query can comprise a request for requester system type (e.g., system type of the machine requesting participation) and requester identification (e.g., ID of the machine requesting to participate). The response is received at step 36. The response is analyzed to determine if it comprises a system type and ID, if the system type is allowed, if the system type and ID are valid.

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.

FIG. 4 is a diagram of an exemplary processor 54 for online gaming authentication. The processor 54 comprises a processing portion 56, a memory portion 58, and an input/output portion 60. The processing portion 56, memory portion 58, and input/output portion 60 are coupled together (coupling not shown in FIG. 4) to allow communications therebetween. The input/output portion 60 is capable of providing and/or receiving components utilized to perform online gaming authentication as described above. For example, the input/output portion 60 is capable of receiving a request to participate in an online game session, provide a query for a system type and ID, receive a response to a query, providing a request to join an online game session to a selected machine (e.g., host machine), or a combination thereof.

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.

FIG. 5 and the following discussion provide a brief general description of a suitable computing environment in which online gaming authentication can be implemented. Although not required, various aspects of online gaming authentication can be described in the general context of computer executable instructions, such as program modules, being executed by a computer, such as a client workstation or a server. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, implementation of online gaming authentication can be practiced with other computer system configurations, including hand held devices, multi processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Further, online gaming authentication also can be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

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 FIG. 5, an exemplary general purpose computing system includes a conventional computing device 560 or the like, including a processing unit 521, a system memory 562, and a system bus 523 that couples various system components including the system memory to the processing unit 521. The system bus 523 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 564 and random access memory (RAM) 525. A basic input/output system 566 (BIOS), containing basic routines that help to transfer information between elements within the computing device 560, such as during start up, is stored in ROM 564. The computing device 560 may further include a hard disk drive 527 for reading from and writing to a hard disk (hard disk not shown), a magnetic disk drive 528 (e.g., floppy drive) for reading from or writing to a removable magnetic disk 529 (e.g., floppy disk, removal storage), and an optical disk drive 530 for reading from or writing to a removable optical disk 531 such as a CD ROM or other optical media. The hard disk drive 527, magnetic disk drive 528, and optical disk drive 530 are connected to the system bus 523 by a hard disk drive interface 532, a magnetic disk drive interface 533, and an optical drive interface 534, respectively. The drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the computing device 560. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 529, and a removable optical disk 531, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in the exemplary operating environment. Likewise, the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.

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 FIG. 5 also includes a host adapter 555, Small Computer System Interface (SCSI) bus 556, and an external storage device 562 connected to the SCSI bus 556.

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 FIG. 5. The logical connections depicted in FIG. 5 include a local area network (LAN) 551 and a wide area network (WAN) 552. Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.

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.