US20070197293A1

US20070197293A1 - System and method for alias addressing during effectuation a push-to-talk service in a multiplayer gaming environment

Info

Publication number: US20070197293A1
Application number: US11/358,882
Authority: US
Inventors: Teemu Jalava; Thane Frivold
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2006-02-20
Filing date: 2006-02-20
Publication date: 2007-08-23
Also published as: WO2007096721A2; WO2007096721A3

Abstract

A client for effectuating a push-to-talk service in a gaming environment includes a processor capable of operating a game client, where the client has an associated alias address in a gaming architecture and multimedia service address in a multimedia service architecture. The game client interacts with the gaming architecture to play an electronic game. During this interaction, the game client can then join the push-to-talk session in the multimedia service architecture, where joining the session includes sending a request to the multimedia service architecture, the request including the multimedia service address of the client. The request is routed through the gaming architecture such that the gaming architecture can modify the request to include the alias address of the client, and forward the modified request to the multimedia service architecture. The multimedia service architecture can then join the client to the push-to-talk session based upon the alias address.

Description

FIELD OF THE INVENTION

The present invention generally relates to systems and methods of operating a multiplayer game and, more particularly, relates to systems and methods of effectuating a push-to-talk service in a game operated by a plurality of clients.

BACKGROUND OF THE INVENTION

Electronic games have become a widespread entertainment feature and are well known in the state of the art as video games or gaming machines. To increase the fun of the game many video games offer the option to play against a computer or against other persons. Some games can be played in a one, two or more player mode, to provide virtual adventures, or to economize expensive gaming equipment. There are actually many different gaming simulations such as sports games, car races, strategy games and even war games available. The attraction of some of these games resides in the fact that the games can be played via networks such as the Internet, enabling remote users to access and play different games with or against other real and/or virtual players, while being in different rooms, homes, towns, countries or even continents.
Typically, electronic games are implemented using application-level gaming infrastructure providing, for example, login, gamer identity, game session or user searches, match-making services or the like. In this regard, by implementing such games using application-level gaming infrastructure, the games are adapted to operate on top of TCP/IP or other protocols as well as alongside other non-gaming applications, thereby ensuring that no need exists for dedicated gaming networks.
During play of electronic games, as in a number of other computing contexts, users desire to communicate with one another. Desktop computers, game consoles, workstations and other wireline computers that provide gaming applications currently allow users to communicate via e-mail, video conferencing, instant messaging (IM) and voice-over-IP (VoIP) to name a few communication applications. Mobile devices, such as mobile telephones, handheld computers, personal digital assistants (PDAs) and the like, which are increasingly also providing gaming applications, also assist in day-to-day communication. Mobile/wireless telephones have conventionally served as voice communication devices, but through technological advancements have recently proved to be effective devices for communicating data, graphics, etc. Wireless and landline technologies continue to merge into a more unified communication system, as user demand for seamless communications across different platforms increases.
Although a number of communication services are currently implemented in the game environment, it is typically desirable to improve upon existing technologies. In this regard, as a number of the current communication systems are proprietary, it would be desirable to design a communication system that draws from existing infrastructures, particularly in the context of mobile devices that are already limited in their computing power, storage space and bandwidth. It would be further desirable for such a system to permit users to have a manner of control over their contact address in implementing communication service in the gaming environment, thereby providing a manner of control over the other users capable of communicating with the client via the communication service within the gaming environment, and also outside the gaming environment.

SUMMARY OF THE INVENTION

In light of the foregoing background, exemplary embodiments of the present invention provide an improved client, network entity, method and computer program product for effectuating a push-to-talk service, such as a push-to-talk over cellular (PoC) service, in a multiplayer gaming environment. Exemplary embodiments of the present invention provide a means for a client, operating in a gaming architecture, to also operate in a multimedia service architecture to effectuate a push-to-talk session. The push-to-talk session can then be utilized by the gaming architecture to enable other clients operating in the gaming architecture to join the push-to-talk session. Exemplary embodiments of the present invention are capable of being implemented in a manner utilizing both a gaming architecture and a multimedia service architecture, without requiring integration of one architecture into the other. Further, exemplary embodiments of the present invention provide for alias address routing while operating in both the gaming architecture and multimedia service architecture to thereby provide a manner of control over the availability of a multimedia service address with which the client may be addressed in the multimedia service architecture outside the gaming environment.
According to one aspect of the present invention, a client is provided for effectuating a push-to-talk service in a gaming environment. The client includes a processor capable of operating a game client, where the client has an associated alias address in a gaming architecture and an associated multimedia service address in a multimedia service architecture. In this regard, the game client is capable of interacting with the gaming architecture to play an electronic game. During interaction with the gaming architecture, the game client is capable of receiving at least one parameter of a push-to-talk session in the multimedia service architecture. The game client is then capable of joining the push-to-talk session in the multimedia service architecture based upon the parameter(s) while the client interacts with the gaming architecture, joining the push-to-talk session including sending a request to the multimedia service architecture, where the request includes the multimedia service address of the client. The game client is capable of sending the request such that the request is routed through the gaming architecture. The gaming architecture, then, is capable of modifying the request to include the alias address of the client, and forwarding the modified request to the multimedia service architecture. The multimedia service architecture can thereafter join the client to the push-to-talk session based upon the alias address.
More particularly, the game client can be capable of receiving at least one parameter including a routing address identifying a first network entity (e.g., event server) in the gaming architecture, where the routing address can be associated with a session address identifying the push-to-talk session at a second network entity (e.g., controlling server) in the multimedia service architecture. In such instances, the game client can be capable of sending a request such that the request is routed through the first network entity identified by the routing address. Further, the game client can be capable of sending a request to a third network entity (e.g., participating server) in the multimedia service architecture, where the third network entity is capable of forwarding the request to the first network entity identified by the routing address. Irrespective of exactly how the first network entity receives the request, however, the first network entity can thereafter forward the modified request to the second network entity identified by the session address, where the second network entity can thereafter be capable of joining the client to the push-to-talk session identified by the session address.
The game client can be further capable of establishing a push-to-talk session in the multimedia service architecture before joining the push-to-talk session. In establishing the push-to-talk session, the game client can be capable of receiving at least one associated session parameter, where the session parameters include the session address. The game client can be capable of transferring at least one of the session parameters to the gaming architecture. The gaming architecture can thereafter be capable of associating the session address with the routing address and advertising the associated routing address for receipt by the client.
According to other aspects of the present invention, a network entity, method and computer program product are provided for effectuating a push-to-talk service in a gaming architecture. Exemplary embodiments of the present invention therefore provide an improved client, network entity, method and computer program product for effectuating a push-to-talk service in a gaming architecture. By operating the client within the gaming architecture to play an electronic game, and within a multimedia service architecture to participate in a push-to-talk session, exemplary embodiments of the present invention are capable of effectuating a push-to-talk service within a gaming architecture. Also, by effectuating the push-to-talk service via the client, the gaming architecture and the multimedia service architecture need not be integrated with one another, and can accordingly be maintained separate from one another. Further, by routing a request to join the push-to-talk session through the gaming architecture, the push-to-talk session can be effectuated based upon an alias address of the client, as opposed to a multimedia session address of the client. In this manner, the client can control the other clients capable of communicating with the client via the multimedia service architecture within the gaming environment, and also outside the gaming environment. As such, the client, network entity, method and computer program product of exemplary embodiments of the present invention may solve the problems identified by prior techniques and/or provide additional advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
FIG. 1 is a block diagram of one type of terminal and system that would benefit from exemplary embodiments of the present invention;
FIG. 2 is a schematic block diagram of an entity capable of operating as a mobile station, game server, routing server, personal computer (PC) system, game console and/or PoC server, in accordance with exemplary embodiments of the present invention;
FIG. 3 is a schematic block diagram more particularly illustrating a mobile station in accordance with one embodiment of the present invention;
FIG. 4 is a schematic block diagram of various network entities of the system of FIG. 1 configured in a multiplayer gaming architecture, in accordance with one embodiment of the present invention;
FIG. 5 is a schematic block diagram of various network entities of the system of FIG. 1 configured in an IP multimedia subsystem (IMS) architecture, in accordance with one embodiment of the present invention;
FIG. 6 is a schematic block diagram of various network entities of a client operating in both a gaming architecture and an IMS architecture, in accordance with one embodiment of the present invention;
FIG. 7 is a schematic block diagram of a multi-layer protocol stack of a client operating in both a gaming architecture and an IMS architecture, in accordance with one embodiment of the present invention; and
FIGS. 8 a and 8 b are control flow diagrams including various steps in a method of effectuating a PoC service in a multiplayer gaming environment, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
Referring to FIG. 1, an illustration of one type of system that would benefit from the present invention is provided. The system, method and computer program product of exemplary embodiments of the present invention will be primarily described in conjunction with mobile communications applications. It should be understood, however, that the system, method and computer program product of exemplary embodiments of the present invention can be utilized in conjunction with a variety of other applications, both in the mobile communications industries and outside of the mobile communications industries. For example, the system, method and computer program product of exemplary embodiments of the present invention can be utilized in conjunction with wireline and/or wireless network (e.g., Internet) applications.
The system can include one or more mobile stations 10, each having an antenna 12 for transmitting signals to and for receiving signals from one or more base stations (BS's) 14, one of each being shown in FIG. 1. The base station is a part of one or more cellular or mobile networks that each includes elements required to operate the network, such as one or more mobile switching centers (MSC) 16. As well known to those skilled in the art, the mobile network may also be referred to as a Base Station/MSC/Interworking function (BMI). In operation, the MSC is capable of routing calls, data or the like to and from mobile stations when those mobile stations are making and receiving calls, data or the like. The MSC can also provide a connection to landline trunks when mobile stations are involved in a call.
The MSC 16 can be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN). The MSC can be directly coupled to the data network. In one typical embodiment, however, the MSC is coupled to a Gateway (GTW) 18, and the GTW is coupled to a WAN, such as the Internet 20. In turn, devices such as processing elements (e.g., personal computers, server computers or the like) can be coupled to the mobile station 10 via the Internet. For example, as explained below, the processing elements can include one or more processing elements associated with one or more game servers 22, routing servers 24, event servers 25 (e.g., session initiation protocol (SIP) event servers), personal computer (PC) systems 26, game consoles 28, or the like, one of each being illustrated in FIG. 1 and described below. As will be appreciated, the processing elements can comprise any of a number of processing devices, systems or the like capable of operating in accordance with exemplary embodiments of the present invention.
The BS 14 can also be coupled to a Serving GPRS (General Packet Radio Service) Support Node (SGSN) 30. As known to those skilled in the art, the SGSN is typically capable of performing functions similar to the MSC 16 for packet switched services. The SGSN, like the MSC, can be coupled to a data network, such as the Internet 20. The SGSN can be directly coupled to the data network. In a more typical embodiment, however, the SGSN is coupled to a packet-switched core network, such as a GPRS core network 32. The packet-switched core network is then coupled to another GTW, such as a GTW GPRS support node (GGSN) 34, and the GGSN is coupled to the Internet.
The GGSN 30 and Internet 20 can be coupled to a IP multimedia subsystem (IMS) 36 that includes various entities for the provision of multimedia services, such as in a manner defined by the third generation partnership project (3GPP). As explained in greater detail below, the IMS can be coupled to an application server for providing the push-to-talk over cellular (PoC) service, also known as PTT, push-to-talk service or the like. Thus, as shown, the application server providing the PoC service is referred to as a PoC server 38, one or more of which may be coupled to the IMS.
Although not every element of every possible network is shown and described herein, it should be appreciated that the mobile station 10 may be coupled to one or more of any of a number of different networks. In this regard, mobile network(s) can be capable of supporting communication in accordance with any one or more of a number of first-generation (1G), second-generation (2G), 2.5G and/or third-generation (3G) mobile communication protocols or the like. More particularly, one or more mobile stations may be coupled to one or more networks capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, one or more of the network(s) can be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. In addition, for example, one or more of the network(s) can be capable of supporting communication in accordance with 3G wireless communication protocols such as Universal Mobile Telephone System (UMTS) network employing Wideband Code Division Multiple Access (WCDMA) radio access technology. Some narrow-band AMPS (NAMPS), as well as TACS, network(s) may also benefit from exemplary embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones).
One or more mobile stations 10 (as well as one or more processing elements, although not shown as such in FIG. 1) can further be coupled to one or more wireless access points (APs) 36. The AP's can be configured to communicate with the mobile station in accordance with techniques such as, for example, radio frequency (RF), Bluetooth (BT), infrared (IrDA) or any of a number of different wireless networking techniques, including WLAN techniques. The APs may be coupled to the Internet 20. Like with the MSC 14, the AP's can be directly coupled to the Internet. In one embodiment, however, the APs are indirectly coupled to the Internet via a GTW 18. As will be appreciated, by directly or indirectly connecting the mobile stations and the user processors (e.g., game servers 22, routing servers 24, event servers 25, personal computer (PC) systems 26, game consoles 28, PoC servers 38, etc.) and/or any of a number of other devices to the Internet, whether via the AP's or the mobile network(s), the mobile stations and user processors can communicate with one another to thereby carry out various functions of the respective entities, such as to transmit and/or receive data, content or the like. As used herein, the terms “data,” “content,” “information,” and similar terms may be used interchangeably to refer to data capable of being transmitted, received and/or stored in accordance with exemplary embodiments of the present invention. Thus, use of any such terms should not be taken to limit the spirit and scope of the present invention.
Although not shown in FIG. 1, in addition to or in lieu of coupling the mobile stations 10 to game servers 22, routing servers 24, event servers 25, personal computer (PC) systems 26 and/or game consoles 28 across the Internet 20, one or more such entities may be directly coupled to one another. As such, one or more network entities may communicate with one another in accordance with, for example, RF, BT, IrDA or any of a number of different wireline or wireless communication techniques, including LAN and/or WLAN techniques.
Referring now to FIG. 2, a block diagram of an entity capable of operating as a mobile station 10, game server 22, routing server 24, event servers 25, personal computer (PC) system 26, game console 28 and/or PoC server 38, is shown in accordance with one embodiment of the present invention. Although shown as separate entities, in some exemplary embodiments, one or more entities may support one or more of a mobile station, game server, routing server, event server, personal computer (PC) system and/or game console, logically separated but co-located within the entit(ies). For example, a single entity may support a logically separate, but co-located, game server and routing server. Also, for example, a single entity may support a logically separate, but co-located personal computer and game console. Additionally or alternatively, a single entity may support a logically separate, but co-located game server and one or more of a mobile station, PC system and/or game console. Further, for example, a single entity may support a logically separate, but co-located game server and event server.
The entity capable of operating as a mobile station 10, game server 22, routing server 24, event servers 25, personal computer (PC) system 26, game console 28 and/or PoC server 38 includes various means for performing one or more functions in accordance with exemplary embodiments of the present invention, including those more particularly shown and described herein. It should be understood, however, that one or more of the entities may include alternative means for performing one or more like functions, without departing from the spirit and scope of the present invention. More particularly, for example, as shown in FIG. 2, the entity includes a processor 40 connected to a memory 42. The memory can comprise volatile and/or non-volatile memory, and typically stores content, data or the like. For example, the memory typically stores content transmitted from, and/or received by, the entity. Also for example, the memory typically stores client applications, instructions or the like for the processor to perform steps associated with operation of the entity in accordance with exemplary embodiments of the present invention. As explained below, for example, the memory can store client application(s) including a configuration utility, content manager and/or display manager. In this regard, when executed, the configuration utility may function to configure a source of content to receive or otherwise provide content. The content manager, when executed, may function to manage the receipt of content from the source, and/or the use of content received from the source. And the display manager may function to manage presentation of content received from the source.
As described herein, the client application(s) each comprise software operated by the respective entities. It should be understood, however, that any one or more of the client applications described herein can alternatively comprise firmware or hardware, without departing from the spirit and scope of the present invention. Generally, then, the mobile station 10, game server 22, routing server 24, event servers 25, personal computer (PC) system 26, game console 28 and/or PoC server 38 can include one or more logic elements for performing various functions of one or more client application(s). As will be appreciated, the logic elements can be embodied in any of a number of different manners. In this regard, the logic elements performing the functions of one or more client applications can be embodied in an integrated circuit assembly including one or more integrated circuits integral or otherwise in communication with a respective network entity (i.e., mobile station, game server, routing server, event server, personal computer (PC) system, game console and/or PoC server, etc.) or more particularly, for example, a processor 30 of the respective network entity. The design of integrated circuits is by and large a highly automated process. In this regard, complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate. These software tools, such as those provided by Avant! Corporation of Fremont, Calif. and Cadence Design, of San Jose, Calif., automatically route conductors and locate components on a semiconductor chip using well established rules of design as well as huge libraries of pre-stored design modules. Once the design for a semiconductor circuit has been completed, the resultant design, in a standardized electronic format (e.g., Opus, GDSII, or the like) may be transmitted to a semiconductor fabrication facility or “fab” for fabrication.
In addition to the memory 42, the processor 40 can also be connected to at least one interface or other means for displaying, transmitting and/or receiving data, content or the like. In this regard, the interface(s) can include at least one communication interface 44 or other means for transmitting and/or receiving data, content or the like, as well as at least one user interface that can include a display 46 and/or a user input interface 48. The user input interface, in turn, can comprise any of a number of devices allowing the entity to receive data from a user, such as a keypad, a touch display, a joystick or other input device.
Reference is now made to FIG. 3, which illustrate one type of mobile station 10, a mobile telephone, which would benefit from exemplary embodiments of the present invention. It should be understood, however, that the mobile station illustrated and hereinafter described is merely illustrative of one type of mobile station that would benefit from the present invention and, therefore, should not be taken to limit the scope of the present invention. While several exemplary embodiments of the mobile station are illustrated and will be hereinafter described for purposes of example, other types of mobile stations, such as portable digital assistants (PDAs), pagers, laptop computers, mobile gaming devices and other types of electronic systems, can readily employ the present invention.
The mobile station 10 includes various means for performing one or more functions in accordance with exemplary embodiments of the present invention, including those more particularly shown and described herein. It should be understood, however, that the mobile station may include alternative means for performing one or more like functions, without departing from the spirit and scope of the present invention. More particularly, for example, as shown in FIG. 3, in addition to an antenna 12, the mobile station 10 can include a transmitter 50, receiver 52, and controller 54 or other processor that provides signals to and receives signals from the transmitter and receiver, respectively. These signals include signaling information in accordance with the air interface standard of the applicable cellular system, and also user speech and/or user generated data. In this regard, the mobile station can be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, the mobile station can be capable of operating in accordance with any of a number of first generation (1G), second generation (2G), 2.5G and/or third-generation (3G) communication protocols or the like. For example, the mobile station may be capable of operating in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, the mobile station may be capable of operating in accordance with 2.5G wireless communication protocols GPRS, EDGE, or the like. Further, for example, the mobile station may be capable of operating in accordance with 3G wireless communication protocols such as UMTS network employing WCDMA radio access technology. Some NAMPS, as well as TACS, mobile stations may also benefit from the teaching of this invention, as should dual or higher mode phones (e.g., digital/analog or TDMA/CDMA/analog phones).
It is understood that the controller 54 includes the circuitry required for implementing the audio and logic functions of the mobile station 10. For example, the controller may be comprised of a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. The control and signal processing functions of the mobile station are allocated between these devices according to their respective capabilities. The controller can additionally include an internal voice coder (VC) 54 a, and may include an internal data modem (DM) 54 b. Further, the controller may include the functionally to operate one or more client software programs such as those indicated above, which may be stored in memory (described below).
The mobile station 10 also comprises a user interface including a conventional earphone or speaker 56, a ringer 58, a microphone 60, a display 62, and a user input interface, all of which are coupled to the controller 54. Although not shown, the mobile station can include a battery for powering the various circuits that are required to operate the mobile station, as well as optionally providing mechanical vibration as a detectable output. The user input interface, which allows the mobile station to receive data, can comprise any of a number of devices allowing the mobile station to receive data, such as a keypad 54, a touch display (not shown), a joystick (not shown) or other input device. In exemplary embodiments including a keypad, the keypad includes the conventional numeric (0-9) and related keys (#, *), and other keys used for operating the mobile station.
The mobile station 10 can also include one or more means for sharing and/or obtaining data. For example, the mobile station can include a short-range radio frequency (RF) transceiver or interrogator 66 so that data can be shared with and/or obtained from electronic devices in accordance with RF techniques. The mobile station can additionally, or alternatively, include other short-range transceivers, such as, for example an infrared (IR) transceiver 68, and/or a Bluetooth (BT) transceiver 70 operating using Bluetooth brand wireless technology developed by the Bluetooth Special Interest Group. The mobile station can therefore additionally or alternatively be capable of transmitting data to and/or receiving data from electronic devices in accordance with such techniques. Although not shown, the mobile station can additionally or alternatively be capable of transmitting and/or receiving data from electronic devices according to a number of different wireless networking techniques, including WLAN techniques such as IEEE 802.11 techniques or the like.
The mobile station 10 can further include memory, such as a subscriber identity module (SIM) 72, a removable user identity module (R-UIM) or the like, which typically stores information elements related to a mobile subscriber. In addition to the SIM, the mobile station can include other removable and/or fixed memory. In this regard, the mobile station can include volatile memory 74, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The mobile station can also include other non-volatile memory 76, which can be embedded and/or may be removable. The non-volatile memory can additionally or alternatively comprise an EEPROM, flash memory or the like. The memories can store any of a number of software applications, instructions, pieces of information, and data, used by the mobile station to implement the functions of the mobile station.
As will be appreciated, a number of the entities of the system of FIG. 1 can be configured in any of a number of different architectures to perform any of a number of functions, such as to manage a multiplayer game. For example, the entities of the system of FIG. 1 can be configured to manage a multiplayer game in a centralized client-server architecture, decentralized architecture and/or proxy architecture, each of which are explained above in the background section. Additionally or alternatively, for example, the entities of the system of FIG. 1 can be configured in an architecture given in the Scalable Network Application Package (SNAP) (formerly Sega Network Application Package) provided by Nokia Corporation for applications such as in the context of multiplayer gaming.
Reference is now made to FIG. 4, which illustrates a multiplayer gaming architecture 78 in accordance with one embodiment of the present invention. As shown, one or more mobile stations 10, PC systems 26 and/or game consoles 28 may operate as clients 80 in the gaming architecture that also includes one or more game servers 22 and/or routing servers 24. In the illustrated architecture, similar to a conventional client-server architecture (see background section above), the game servers operate games and maintain the state of those games. As will be appreciated, however, the routing servers and/or one or more of the clients themselves may alternatively operate portions, or all, of the games and maintain the state of those games. Accordingly, the client and/or routing server may also support a game server. As used herein, then, although games can be operated by one or more network entities, including game servers, routing servers and/or client(s), the following description may refer to a game server as operating the games for purposes of illustration. Irrespective of the network entit(ies) that operate the games, however, the clients operate game clients that communicate with those network entit(ies) to continuously change the game state of the games operated and maintained by the network entit(ies) to thereby play those games.
Also in the illustrated architecture 78, the clients 80 are operatively coupled to routing servers 24 which, in turn, are coupled to the game servers 22. Thus, the routing servers route data packets between one or more clients and the game servers, and/or other clients, to facilitate the operation of each entity in the architecture. As shown, the routing servers can be coupled between groups of clients and one or more game servers, directly or indirectly via one or more other routing servers. In this regard, one or more routing servers can also be coupled to other routing servers such that the routing servers can also be coupled between one or more clients and one or more groups of other clients, such as groups of clients coupled to other routing servers.
Referring to FIG. 5, an IMS architecture 82 is shown for providing PoC service to a plurality of mobile stations 10, PC systems 26 and/or game consoles 28 operating as clients 80. Within the IMS architecture, the clients may connect to application servers that are generally connected to the IMS architecture. In FIG. 5, such application servers for providing a PoC service are shown as PoC servers 38. In this regard, the PoC servers can include a controlling PoC server 38 a generally providing centralized PoC session handling and media distribution. In addition, the PoC servers can include one or more participating PoC servers 38 b generally providing session handling, such as SIP session handling on behalf of clients, as well as media relay functions between clients and a controlling PoC server. Although shown as separate entities, it should be understood that a single entity may support a logically separate, but co-located, controlling PoC server and participating PoC server.
To connect the clients to the PoC servers 38, the IMS architecture 82 includes an IMS core 85 including a number of network entities known as servers. As shown, for example, the IMS architecture can include a number of call session (or state) control functions (CSCFs) to handle different functions. The CSCFs may, in turn, be divided into various categories such as a proxy CSCF (P-CSCF) 84 and an interrogating/serving CSCF (I/S-CSCF) 86. Briefly, the P-CSCF provides the clients 80 with a gateway or entry point into the IMS architecture. The I/S-CSCF, which may alternatively comprise separate entities, operates as the authentication contact point within the IMS architecture for connections to clients (the interrogating function), and performs the session control services for the clients, providing the call intelligence and business logic (the serving function).
The signaling between the clients 80 and the appropriate CSCFs 84 and 86 is typically routed via a radio access network, such as the GPRS network or backbone 32. The user plane session set-up signaling for a client is routed via and controlled by the PoC servers 38. That is, the PoC servers control both the control plane and the user plane of the client. It shall be appreciated that the control plane traffic between the client and the PoC servers is typically routed via the IMS architecture 82, such as in accordance with SIP. The user plane traffic between the client and the PoC server, on the other hand, is typically routed from the radio access (e.g., GPRS) network to the PoC server, such as in accordance with the respective radio access network.
Referring now to FIGS. 6, 7, 8 a and 8 b, exemplary embodiments of the present invention provide an improved framework for providing a communication service, such as the PoC service within the IMS architecture 78, to a client 80 playing a multiplayer game in a gaming architecture 78. In this regard, in accordance with exemplary embodiments of the present invention, the client has an associated PoC address within the IMS architecture. To effectuate the communication service to a client playing a multiplayer game, the client may also have an associated alias address within the gaming architecture. Thus, while effectuating the communication service in a multiplayer gaming environment, the client may be addressed by its alias address instead of its PoC address with which the IMS architecture otherwise addresses the client outside the multiplayer gaming environment. By addressing the client within the gaming environment by its alias address, the client may further control the other clients capable of communicating with the client via the communication service within the gaming environment, and also outside the gaming environment.
More particularly, FIGS. 6, 7, 8 a and 8 b illustrate functional block diagram, protocol stack and method, respectively, of providing communication service within a multiplayer game environment in accordance with exemplary embodiments of the present invention. As shown and described herein, consider an event server 25 and controlling PoC server 38 a having addresses in the form of SIP URIs (uniform resource indicators) such as “poc.gaming.com” and “poc.host.com” that identify the event server and controlling PoC server (e.g., domain name, IP address, etc.), respectively. Also, consider a client 80 having PoC and alias addresses in the form of SIP URIs such as “user@poc.host.com” (identifying the client at the participating PoC server, and when the participating and controlling PoC servers are co-located within the same entity, the controlling PoC server) and “alias@gaming.host.com” (identifying the client at the event server), respectively. It should be understood, however, that the event server, controlling PoC server and client can have any of a number of different associated addresses without departing from the spirit and scope of exemplary embodiments of the present invention. It should further be understood that whereas a single entity may support both the participating and controlling PoC servers (e.g., both at address “poc.host.com”), the participating and controlling PoC servers may comprise separate entities, and accordingly have separate addresses.
As shown in FIG. 6, then, a client 80 operates within a gaming architecture 78 to send data packets to and/or receive data packets from a game server 22 (via one or more routing servers 24) to play a multiplayer game. In this regard, the game server is capable of establishing and maintaining a game session 90 for a plurality of clients, the game server operating the game and maintaining the state of that game based at least in part on data packets received from the clients. As the client operates in the gaming architecture, the client is also capable of operating within an IMS architecture 82 (the core 85 of which is not shown in FIG. 6 for purposes of clarity) to directly or indirectly send data packets to and/or receive data packets from a controlling PoC server 38 a to receive a push-to-talk type communication service. In this regard, the controlling PoC server is capable of establishing and hosting a PoC session 92 between a plurality of clients, with the controlling PoC server passing data packets between the clients such that the clients, or more particularly client users, participate in a PoC session therebetween. Further, to provide the communication service to the client as the client operates in the gaming architecture, the game server 22 is made aware of the IMS architecture and its capabilities, as well as a PoC session address associated with the PoC session. The PoC session address, then, can be associated with a routing address 94 for use in alias address routing in accordance with exemplary embodiments of the present invention, as explained below. Also for use in alias addressing, the client's PoC address can be associated with an alias address also associated with the client, such as at the game server or another entity (e.g., event server 25) in communication therewith.
Reference is now made to FIG. 7, which illustrates the protocol stack of a client 80 operating in both the gaming architecture 78 and the IMS architecture 82. As shown, the application layer includes both a game client and a PoC client that each operate above a session layer that includes both a game session and a PoC session. The game client includes a game-PoC module operating on top of the PoC session so that when an existing PoC session is created via the PoC client, the same session can be later controlled by the game client via the game-PoC module without requiring the user to switch between the different clients. In this regard, to effectuate communication between the application layer and the session layer for providing communication service in the multiplayer game environment, the client includes one or more game application programming interfaces (APIs) interfacing between the game client and the game service. Likewise, the client includes one or more PoC APIs interfacing between the game-PoC module and the PoC service, and between the PoC client and the PoC service.
Now with reference to FIGS. 8 a and 8 b, a method of effectuating a PoC service in a multiplayer gaming environment includes providing a plurality of clients 80 capable of interacting with a game server 22 to thereby play an electronic game. For example, a plurality of clients, or client users, may register with the game server to play an electronic game operated and maintained by the game server, such as by means of game clients operated by the respective clients. Then, to play the electronic game operated and maintained by the game server, a registered client user may operate the game client to log in or otherwise authenticate to the game server to initiate or join a game session, and thereafter interact with the game server to play the electronic game during the game session. The client is accordingly operating in a gaming architecture 78 including the respective game server.
As the clients 80, or more particularly the game clients operated by the clients, interact with the game server 22 during the game session, the game server may send a client a request to establish one or more PoC sessions within an IMS architecture 82. Alternatively, before or as a client interacts with the game server, the client may desire to establish one or more PoC sessions within the IMS architecture irrespective of a request from the game server. In response to the request or a self-initiated trigger, the client can initiate or otherwise establish one or more PoC sessions with one or more controlling PoC servers 38 a, via one or more participating PoC servers 38 b, within the IMS architecture. In this regard, in establishing each PoC session, a number of parameters can be established or otherwise determined by which the session may be joined by the client as well as other clients. For example, the PoC server may assign a session address or other identifier that may be transferred to the client for accessing the PoC session. Other parameters may include, for example, an address or other identifier of the PoC server, as well as any other parameters that may define requirements of joining the PoC session. More particularly, for example, consider the controlling PoC server having the address “poc.host.com,” where the controlling PoC server supports a PoC session having an identifier such as “session1.” In such an instance, the parameter(s) established or otherwise determined in establishing the respective PoC session can include the session address “session1@poc.host.com.”
By initiating or otherwise establishing the PoC session(s), the client 80 is enabled to operate in the IMS architecture 82. To operate in the IMS architecture while in the gaming environment, however, the client may not immediately join the established PoC session(s). Instead, the client may join the established PoC session(s) via an event server 25 in the gaming architecture 78 such that the client may be addressed by an alias (e.g., alias SIP address) as opposed to a client PoC address (e.g., PoC SIP address) with which the IMS architecture otherwise addresses the client outside the multiplayer gaming environment, as explained below.
After the PoC session(s) have been established, the session parameter(s) can be transferred to the game server 22 that originally requested the client to establish the PoC session. In this regard, the parameter(s) may be transferred from the controlling PoC server 38 a to the participating PoC server 38 b, from the participating PoC server to the client 80, and from the client to the game server. It should be understood, however, that one or more of the parameters may alternatively be transferred to the game server more directly from the controlling PoC server, if so desired. And in yet other instances, one or more of the parameters may already be known to the game server, such as the address of the controlling PoC server effectuating the PoC session. Irrespective of how the parameter(s) are transferred to the game server, however, the game server can thereafter advertise session parameter(s) to the clients playing the multiplayer game, including the client that established the PoC session(s).
Before advertising the session parameters to the clients, however, the game server or another entity (e.g., event server 25) in communication with the game server can associate one or more of the PoC session parameters with one or more routing parameters. In this regard, the game server (or other entity) can associate the session address established by the IMS architecture 82 with a routing address 94 established by the gaming architecture 78. Continuing the above example, then, the session address “session1@poc.host.com” can be associated with a routing address such as “game1@gaming.host.com,” where “game1” identifies a PoC session being effectuated during gaming session within which the client that established the PoC session(s) is playing, and “gaming.host.com” identifies the event server in the gaming architecture. By associating one or more PoC session parameters with respective routing parameters, the routing parameters can be utilized to perform alias address routing in effectuating the established PoC session(s) in accordance with exemplary embodiments of the present invention.
Thus, after associating PoC session parameter(s) with respective routing parameter(s), the game server 22 can thereafter advertise the routing parameter(s) (e.g., routing address) and any PoC session parameter(s) not otherwise associated with routing parameter(s) to clients 80 playing the multiplayer game, including the client that established, but did not immediately join, the PoC session(s). For example, the game server may advertise the routing/PoC session parameter(s) to clients of the same game session. Further, within a game session, the game server may advertise the parameter(s) to the client that established the PoC session and other clients associated therewith, such as other clients on a team with the respective client within the game. Alternatively, a client on a team playing a game against another team may receive a request to establish two PoC sessions. After establishing the PoC sessions and transferring parameters for each PoC session to the game server, the game server can advertise one set of parameter(s) to the clients of each team. The members of each team may then join in a respective PoC session.
As the game server 22 advertises the routing/PoC session parameter(s) of the PoC session to the clients 80 including the client that established the PoC session, the clients receiving the advertised parameter(s) can, if so desired, join the PoC session based upon the respective parameter(s). In this regard, the game-PoC modules of one or more clients can receive the advertised routing/PoC session parameter(s) and request to join the PoC session based upon the client's PoC address (e.g., “user@poc.host.com”) and the routing/PoC session parameter(s), including the routing address (e.g., “game1@gaming.host.com”), as shown in FIG. 8 b. In accordance with SIP, for example, the client can send an SIP INVITE request to the controlling PoC server 38 a via a participating PoC server 38 b, where the SIP INVITE request identifies the routing address and client PoC address. As the routing address identifies the event server 25 (e.g., “gaming.host.com”) in the gaming architecture, however, the participating PoC forwards the request to join the PoC session to the event server 25 instead of the controlling PoC server, the event server thereby being capable of operating as a controlling PoC server with respect to the participating PoC server.
Upon receiving the request to join the PoC session from the participating PoC server 38 b, the event server 25 can modify the request to replace the routing address and client PoC address in the request with the associated PoC session address and client alias address, respectively. More particularly, for example, the event server can replace the routing address “game1@gaming.host.com” with the PoC session address “session1@poc.host.com,” and replace the client PoC address “user@poc.host.com” with the alias address “alias@gaming.host.com.” After replacing the routing address and client PoC address, the event server can forward the request to join the PoC session to the controlling PoC server 38 a. In this manner, the event server may function as a participating PoC server with respect to the controlling PoC server. Upon receiving the request, then, the controlling PoC server can join the respective client 80, whether the client that initiated the PoC session or another client, to the PoC session (e.g., “session1”) based upon the client's alias address. As can be seen, then, by routing the request through the event server based upon the routing address, the event server can shield the client's PoC address from the controlling PoC server, and thus the PoC session, such that other clients operating in the PoC session need not be made aware of the client's PoC address during effectuation of the PoC session.
As further shown, after joining the client 80 to the PoC session, the controlling PoC server 38 a can forward an acknowledgement (ACK) message back to the event server 25, where the ACK message is sent based upon or otherwise including the client's alias address (e.g., “alias@gaming.host.com”), as well as the PoC session address (e.g., “session1@poc.host.com”). Upon receiving the ACK message, the event server can, similar to before, replace the alias address and PoC session address with the associated client PoC address and routing address, respectively. After replacing the alias address and PoC session address, the event server can forward the ACK message to the participating PoC server 38 b, which upon receipt of the ACK message, can forward the message to the client.
As clients 80 join the PoC session, those clients can effectuate the PoC session based upon their respective alias addresses, the event server being capable of forwarding messages to the controlling PoC server based upon the clients' respective alias addresses, and forwarding messages from the controlling PoC server based upon the clients' respective PoC addresses. Accordingly, while the clients play a multiplayer game within the gaming architecture 78, the clients can simultaneously participate in a PoC service of the PoC server within the IMS architecture 82. As clients may join the game session at one or more instances after the game server initially advertises the parameter(s) of the PoC session, or as one or more clients may otherwise subsequently desire to join the PoC session, the game server may periodically advertise the parameter(s). Additionally or alternatively, the game server may advertise the parameter(s) to new clients joining the game session.
As shown and explained herein, clients 80 participate in a PoC session in an IMS architecture 82 while operating in a gaming architecture. It should be understood, however, that the IMS architecture is only one of a number of different types of architectures via which a push-to-talk session is capable of being effectuated in accordance with exemplary embodiments of the present invention. Likewise, PoC is only one of a number of different types of push-to-talk communication services capable of being provided to clients operating in a gaming architecture in accordance with exemplary embodiments of the present invention.
According to one aspect of the present invention, the functions performed by one or more of the entities of the system, such as the game server 22, routing server 24, event server 25, PoC server 38 and/or client 80 (e.g., mobile station 10, PC system 26, game console 28, etc.), may be performed by various means, such as hardware and/or firmware, including those described above, alone and/or under control of a computer program product (e.g., game client, game-PoC module, PoC client, etc.). The computer program product for performing one or more functions of exemplary embodiments of the present invention includes a computer-readable storage medium, such as the non-volatile storage medium, and software including computer-readable program code portions, such as a series of computer instructions, embodied in the computer-readable storage medium.
In this regard, FIGS. 8 a and 8 b are control flow diagrams of methods, systems and program products according to exemplary embodiments of the present invention. It will be understood that each block or step of the control flow diagrams, and combinations of blocks in the control flow diagrams, can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (i.e., hardware) to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the control flow diagrams block(s) or step(s). These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the control flow diagrams block(s) or step(s). The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the control flow diagrams block(s) or step(s).
Accordingly, blocks or steps of the control flow diagrams support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that one or more blocks or steps of the control flow diagrams, and combinations of blocks or steps in the control flow diagrams, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A client for effectuating a push-to-talk service in a gaming environment, the client comprising:

a processor capable of operating a game client, the game client being capable of interacting with a gaming architecture to play an electronic game, wherein the game client is capable of interacting with the gaming architecture so as to receive at least one parameter of a push-to-talk session in a multimedia service architecture, and wherein the client has an associated alias address in the gaming architecture, and an associated multimedia service address in the multimedia service architecture,

wherein the game client is capable of joining the push-to-talk session in the multimedia service architecture based upon the at least one parameter while the client interacts with the gaming architecture, wherein the game client is capable of joining the push-to-talk session including sending a request to the multimedia service architecture, the request including the multimedia service address of the client, and

wherein the game client is capable of sending the request such that the request is routed through the gaming architecture, the gaming architecture being capable of modifying the request to include the alias address of the client, and capable of forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

2. A client according to claim 1, wherein the game client is capable of receiving at least one parameter including a routing address identifying a first network entity in the gaming architecture, and

wherein the game client is capable of sending a request such that the request is routed through the first network entity identified by the routing address.

3. A client according to claim 2, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the game client is capable of sending a request such that the first network entity is capable of forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

4. A client according to claim 3, wherein the game client is capable of sending a request to a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.

5. A client according to claim 3, wherein the game client is further capable of establishing a push-to-talk session in the multimedia service architecture, the game client being capable of establishing the push-to-talk session including receiving at least one associated session parameter, the session parameters including the session address, and

wherein the game client is capable of transferring at least one of the session parameters to the gaming architecture, the gaming architecture thereafter being capable of associating the session address with the routing address and advertising the associated routing address for receipt by the client.

6. A network entity for effectuating a push-to-talk service in a gaming environment, the network entity comprising:

a processor capable of operating an application in a gaming architecture as a client interacts with the gaming architecture to play an electronic game, the application being capable of receiving a request to join the client to a push-to-talk session in a multimedia service architecture, wherein the request includes a multimedia service address associated with the client in the multimedia service architecture, the application capable of receiving the request based upon at least one parameter of the push-to-talk session received by the client during interaction with the gaming architecture,

wherein the application is capable of modifying the request to include an alias address associated with the client in the gaming architecture, and

wherein the application is capable of forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

7. A network entity according to claim 6, wherein the at least one parameter of the push-to-talk session received by the client includes a routing address identifying the network entity in the gaming architecture, and

wherein the application is capable of receiving a request based upon the routing address identifying the network entity.

8. A network entity according to claim 7, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the application is capable of forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

9. A network entity according to claim 8, wherein the application is capable of receiving a request via a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the network entity identified by the routing address.

10. A client for effectuating a push-to-talk service in a gaming environment, the client comprising:

a first means for interacting a client with a gaming architecture to play an electronic game, wherein the first means is adapted to interact with the gaming architecture to receive at least one parameter of a push-to-talk session in a multimedia service architecture, and wherein the client has an associated alias address in the gaming architecture, and an associated multimedia service address in the multimedia service architecture; and

a second means for joining the client to the push-to-talk session in the multimedia service architecture based upon the at least one parameter while the client interacts with the gaming architecture, wherein the second means is adapted to join the client including sending a request to the multimedia service architecture, the request including the multimedia service address of the client, and

wherein the second means is adapted to send the request such that the request is routed through the gaming architecture, the gaming architecture being capable of modifying the request to include the alias address of the client, and capable of forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

11. A client according to claim 10, wherein the first means is adapted to receive at least one parameter including a routing address identifying a first network entity in the gaming architecture, and

wherein the second means is adapted to send a request such that the request is routed through the first network entity identified by the routing address.

12. A client according to claim 11, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the second means is adapted to send a request such that the first network entity is capable of forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

13. A client according to claim 12, wherein the second means is adapted to send a request to a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.

14. A client according to claim 12 further comprising:

a third means for establishing a push-to-talk session in the multimedia service architecture, the third means being adapted to establish the push-to-talk session including receiving at least one associated session parameter, the session parameters including the session address; and

a fourth means for transferring at least one of the session parameters to the gaming architecture, the gaming architecture thereafter being capable of associating the session address with the routing address and advertising the associated routing address for receipt by the client.

15. A network entity for effectuating a push-to-talk service in a gaming environment, the network entity comprising:

a first means for receiving a request to join a client to a push-to-talk session in a multimedia service architecture, wherein the request includes a multimedia service address associated with the client in the multimedia service architecture, the request being received in a gaming architecture as the client interacts with the gaming architecture to play an electronic game, and being received based upon at least one parameter of the push-to-talk session received by the client during interaction with the gaming architecture;

a second means for modifying the request to include an alias address associated with the client in the gaming architecture; and

a third means for forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

16. A network entity according to claim 15, wherein the at least one parameter of the push-to-talk session received by the client includes a routing address identifying the network entity in the gaming architecture, and

wherein the first means is adapted to receive a request based upon the routing address identifying the network entity.

17. A network entity according to claim 16, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the third means is adapted to forward the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

18. A network entity according to claim 17, wherein the first means is adapted to receive a request via a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the network entity identified by the routing address.

19. A method of effectuating a push-to-talk service in a gaming environment, the method comprising:

interacting a client with a gaming architecture to play an electronic game, wherein the interacting step includes receiving at least one parameter of a push-to-talk session in a multimedia service architecture, and wherein the client has an associated alias address in the gaming architecture, and an associated multimedia service address in the multimedia service architecture; and

joining the client to the push-to-talk session in the multimedia service architecture based upon the at least one parameter while the client interacts with the gaming architecture, wherein the joining step includes sending a request to the multimedia service architecture, the request including the multimedia service address of the client, and

wherein the sending step comprises sending the request such that the request is routed through the gaming architecture, the gaming architecture being capable of modifying the request to include the alias address of the client, and capable of forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

20. A method according to claim 19, wherein the receiving step comprises receiving at least one parameter including a routing address identifying a first network entity in the gaming architecture, and

wherein the sending step comprises sending a request such that the request is routed through the first network entity identified by the routing address.

21. A method according to claim 20, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the sending step comprises sending a request such that the first network entity is capable of forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

22. A method according to claim 21, wherein the sending step comprises sending a request to a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.

23. A method according to claim 21 further comprising:

establishing a push-to-talk session in the multimedia service architecture, the establishing step including receiving at least one associated session parameter, the session parameters including the session address; and

transferring at least one of the session parameters to the gaming architecture, the gaming architecture thereafter being capable of associating the session address with the routing address and advertising the associated routing address for receipt by the client.

24. A method of effectuating a push-to-talk service in a gaming environment, the method comprising:

receiving a request to join a client to a push-to-talk session in a multimedia service architecture, wherein the request includes a multimedia service address associated with the client in the multimedia service architecture, the request being received in a gaming architecture as the client interacts with the gaming architecture to play an electronic game, and being received based upon at least one parameter of the push-to-talk session received by the client during interaction with the gaming architecture;

modifying the request to include an alias address associated with the client in the gaming architecture; and

forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

25. A method according to claim 24, wherein the at least one parameter of the push-to-talk session received by the client includes a routing address identifying a first network entity in the gaming architecture, and

wherein the receiving step comprises receiving a request at the first network entity identified by the routing address.

26. A method according to claim 25, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the forwarding step comprises forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

27. A method according to claim 26, wherein the receiving step comprises receiving a request at the first network entity via a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.

28. A computer program product for effectuating a push-to-talk service in a gaming environment, wherein the computer program product comprises at least one computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising:

a first executable portion for interacting a client with a gaming architecture to play an electronic game, wherein the first executable portion is adapted to interact with the gaming architecture including receiving at least one parameter of a push-to-talk session in a multimedia service architecture, and wherein the client has an associated alias address in the gaming architecture, and an associated multimedia service address in the multimedia service architecture; and

a second executable portion for joining the client to the push-to-talk session in the multimedia service architecture based upon the at least one parameter while the client interacts with the gaming architecture, wherein the second executable portion is adapted to join the client by sending a request to the multimedia service architecture, the request including the multimedia service address of the client, and

wherein the second executable portion is adapted to send the request such that the request is routed through the gaming architecture, the gaming architecture being capable of modifying the request to include the alias address of the client, and capable of forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

29. A computer program product according to claim 28, wherein the first executable portion is adapted to receive at least one parameter including a routing address identifying a first network entity in the gaming architecture, and

wherein the second executable portion is adapted to send a request such that the request is routed through the first network entity identified by the routing address.

30. A computer program product according to claim 29, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the second executable portion is adapted to send a request such that the first network entity is capable of forwarding the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

31. A computer program product according to claim 30, wherein the second executable portion is adapted to send a request to a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.

32. A computer program product according to claim 30 further comprising:

a third executable portion for establishing a push-to-talk session in the multimedia service architecture, the third executable portion being adapted to establish the push-to-talk session including receiving at least one associated session parameter, the session parameters including the session address; and

a fourth executable portion for transferring at least one of the session parameters to the gaming architecture, the gaming architecture thereafter being capable of associating the session address with the routing address and advertising the associated routing address for receipt by the client.

33. A computer program product for effectuating a push-to-talk service in a gaming environment, wherein the computer program product comprises at least one computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising:

a first executable portion for receiving a request to join a client to a push-to-talk session in a multimedia service architecture, wherein the request includes a multimedia service address associated with the client in the multimedia service architecture, the request being received in a gaming architecture as the client interacts with the gaming architecture to play an electronic game, and being received based upon at least one parameter of the push-to-talk session received by the client during interaction with the gaming architecture;

a second executable portion for modifying the request to include an alias address associated with the client in the gaming architecture; and

a third executable portion for forwarding the modified request to the multimedia service architecture, the multimedia service architecture thereafter being capable of joining the client to the push-to-talk session based upon the alias address.

34. A computer program product according to claim 33, wherein the at least one parameter of the push-to-talk session received by the client includes a routing address identifying a first network entity in the gaming architecture, and

wherein the first executable portion is adapted to receive a request at the first network entity identified by the routing address.

35. A computer program product according to claim 34, wherein the routing address is associated with a session address identifying the push-to-talk session at a second network entity in the multimedia service architecture, and

wherein the third executable portion is adapted to forward the modified request to the second network entity identified by the session address, the second network entity thereafter being capable of joining the client to the push-to-talk session identified by the session address.

36. A computer program product according to claim 35, wherein the first executable portion is adapted to receive a request at the first network entity via a third network entity in the multimedia service architecture, the third network entity being capable of forwarding the request to the first network entity identified by the routing address.