Banning verbal communication to and from a selected party in a game playing system

The present invention generally relates to methods and systems thereof for preventing oral communication by a particular player relating to the control of oral communication between electronic game players. More specifically, methods, records for preventing oral communication by a particular player, which selectively prevents oral communication between players playing a game using one or more electronic game consoles. It relates to a medium, a system for preventing verbal communication by a particular player, and a method for controlling verbal communication between players.

When playing a non-electronic game with one or more other people, such as a card game such as a bridge, the sociable dialogue and verbal interaction that occurs during the game usually makes the player much more enjoyable. To do. Oral communication is also an element of gameplay. This is because the comments made by the player to the opponent during the game cause the opponent to lose concentration and become clumsy, while the comments made to the team members are encouraging. This is because it is possible to improve the quality of play of team members. Therefore, communication between game-playing individuals is clearly an important element of the gaming experience.

Verbal communication between players, which is less important to gameplay, was lacking when players began playing electronic games over the Internet and other network links. Players at different sites were generally unable to communicate with each other. This is because the player's personal computer (PC) only conveys data related to playing the game over the network. The loss of verbal sociable dialogue, which is an integral part of gameplay when all players are in the same room, made playing games over the Internet less interesting. To address this issue, hardware and software have been developed to support voice communication between PCs over the network during gameplay. Around the same time, voice is transmitted over the Internet or other networks (ie, VoIP (voice over)). IP)), a technology has been developed that enables communication between networked parties without incurring the cost of long-distance telephones on traditional telephones. This research has led to the creation of various protocols that support VoIP communication, including the H.323 standard, SIP (Session Initiation Protocol), and MGCP / MEGACO (Media Gateway Control Protocol / Media Gateway Controller). Many of the features and technologies of VoIP are applicable to and have been used in schemes that allow oral communication between players of PC electronic games over networks. Examples of systems that provide voice communication between connected PCs during gameplay include Microsoft Corporation's SIDE WINDER GAME VOICE and Mindmaker Incorporated' GAME COMMANDER 2 devices and software. , TEAM SOUND Software, GameSpy Includes ROGER WILCO software from Industries) and FIRST CONACT software from Alienware Technology. The voice communication provided by these products greatly enhances the enjoyment of playing games on a PC connected via the Internet or other networks. Some of the above systems operate in peer-to-peer mode, where audio data is transferred directly between PCs over the network, while others receive audio data from one game player computer and that data. Transfer over a network to one or more other computers connected to that network to play games.

In contrast to PC gaming systems, where only one player is supported on each PC, multiplayer game consoles support multiple players on each console. A voice communication system has been developed for game consoles that enables oral communication between multiple players playing a game. Oral communication can occur between players on the same game console, or between players on different game consoles that are combined to communicate either directly or over a network such as the Internet. is there.

Oral communication during gameplay is generally a desirable feature, but can be annoying to one or more players in a game if abused or abused by a particular player. The cause of annoyance to the player may be repeated use of profane or sexually explicit words by a particular player, or simply words or comments that the player finds socially unacceptable. is there. Since each player has a personal reaction to certain verbal behavior, there is virtually no end to what causes a player to be offended by verbal communication with a particular player. Nevertheless, if any player is uncomfortable with the verbal communication of a particular player, it is important to allow that player to prevent further verbal communication with that particular other player. Conventional techniques allow a player to block verbal communication with an offensive player in a particular game played on a multiplayer game console, or an offensive player to a player during any game played on a multiplayer game console. Does not allow you to generally block talking or listening to the player.

It is possible to control verbal communication with other selected players by the game software and allow that control to cover only a single gameplay session. Alternatively, control of verbal communication may be better applied based on player data held at a central site, such as the services of online gaming services. Each time a player logs on through the game console to play a game over the network, that data is accessed to exclude verbal communication by any of the players, or verbal communication between certain players. It can be determined whether or not it is present. Actions by the player muting verbal communication with the selected player during the game should preferably not inform the selected player of the decision, and the player may otherwise in the game. The ability to communicate with the player must not be adversely affected. Mute processing by another player on the selected player remains in effect regardless of changes in aliases or changes in the gaming device used by the selected player to play the game over the network. There must be.

Parents block their children from participating in voice communication during gameplay, exposing them to light or profane words, or to children outside the scope of gameplay for harmful purposes. You may want to avoid being exposed to verbal communication with someone who may attempt to contact you. Parental blocking of the child's verbal communication must be remembered on the online gaming service and must still be valid when the child connects from a different game console. Conventional game voice communication systems cannot block verbal communication by selected players, such as children, who are participating in a game using a multiplayer game console.

Another area of control of verbal communication concerns the concept of cracking down on player behavior. Ideally, while playing a game on a network, some prohibition that the reaction of another player exposed to the behavior of a particular player during verbal communication is imposed on that player's further verbal communication. Must be a standard. Automated features on online gaming services, if a player's verbal behavior is considered too terrible (based on the number of complaints received from other players, or some other criterion) and justified. Alternatively, the online game service provider must be able to prevent the player from participating in verbal communication while playing the game. Prohibition of verbal communication by such a player can occur for a limited period of time, eg, a week, but if justified by subsequent unacceptable verbal behavior, that player's verbal communication. It is possible to permanently ban communication. Again, current voice communication systems apply this level of control to verbal communication by selected players on multiplayer game consoles that connect to other game consoles through the services of online game services. Is not possible.

As the prior art known to the applicant, there is no particular prior art document information to be described.

<p> The conventional system has various problems as described above, and further improvement is desired.</p><p> The present invention has been made in view of such circumstances, and an object of the present invention is to specify that oral communication with or from a party selected in the game playing system can be prohibited. The purpose is to provide a method and a system thereof for preventing oral communication by a player.</p>

<p> As mentioned above, voice communication between an individual playing a game on a PC connected via a network and one or more players playing a game using their own PCs is It is well known. However, the present invention relates to a multiplayer game console that allows verbal communication between players playing a game on one or more game consoles. Specifically, the present invention makes it possible to control verbal communication by a particular player during one or more games played on a multiplayer game console. In order to realize this function, data about each player participating in the game is retained. This data includes indicators pointing to specific players who are excluded from communicating verbally during gameplay. Blocking a player from communicating verbally is during the current game session, or during any game played with another player who chooses not to communicate verbally with that particular player, or in an online game. It applies during all games played by that particular player using the services of the service, or during all games played by that particular player using a particular multiplayer game console. Verbal communication with that particular player is prevented in response to indicators in the data and according to one of the criteria.</p><p> If the data contains an association between the other player who chooses not to communicate verbally with that particular player and the indicator indicating that particular player, that particular player is that particular player and that particular player. Verbal communication with other players is prevented in any game in which the player participates. To achieve this capability, data is retained for each player in the game being played over the network and accessed by a multiplayer game console.</p><p> It is also intended that the data can be created and retained locally by the game being played on the multiplayer game console. In that case, the data includes an association between the other player who chooses not to communicate verbally and an indicator indicating that particular player, and that particular player is the other player and that particular player. Prevent verbal communication with other players during the game in which they are both participants.</p><p> By allowing parents or authorized parties to select on the game console an option to determine if a minor child can participate in verbal communication while playing a game. , Provides another type of control of verbal communication. In that case, the indicator contained in the data points to the minor child as a particular player, and the parent or authorized party blocks verbal communication in the game played by the minor child. Indicates that is selected.</p><p> In most cases, the data, including the indicators, is accessed in the online gaming services used to play games over the network. In fact, an indicator that a particular player is excluded from verbal communication automatically depends on the number of complaints made by other players regarding the behavior of that particular player's verbal communication. It can also be created. For example, if a particular player uses excessively profane language in oral communication during gameplay and a sufficient number of other players complain, that particular player will be over a defined time interval. The use of voice communication can be automatically prevented and, if the problem persists, the ban can be made permanent. Players who are prevented from communicating verbally cannot avoid the problem simply by changing to a different alias or by using a different multiplayer game console. The indicator in the data is independent of any alias used by that particular player, and regardless of the game console used by that particular player to play the game over the network, that particular player. Point to.</p><p> A player excluded from communicating verbally with another player will not receive any instructions that such a decision has been made. Therefore, it is not clear that one player chose not to communicate with another. If a particular player is generally excluded from communicating verbally in all games, the display will be muted to all other players in the game in which that particular player participates. Indicates that it has been done.</p><p> Oral communication between players is preferably prioritized based on user-defined priorities. For example, the user can specify that verbal communication with another player is always prioritized, or the game-specific role that the player undertakes prioritizes one verbal communication over other verbal communication. It can be a criterion for setting. Therefore, oral communication from the team leader can be set to take precedence over oral communication from other members of the team. The game can define priorities, or the player can prioritize.</p><p> Another aspect of the invention is directed to a memory medium having multiple machine executable instructions for performing the steps of the method described above. Yet another aspect of the invention is directed to a system for preventing verbal communication by a particular player while playing an electronic game. The system provides a processor, a network interface adapted to communicate over the network with at least one multiplayer game console, and an input device for oral communication for each player who communicates verbally during the game. Includes a multiplayer game console with an output device and a memory that stores machine language instructions that allow the processor to perform multiple functions. The above functions are generally consistent with the steps of the method described above.</p><p> Many of the above aspects and accompanying advantages of the present invention will become more apparent as they are better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings.</p>

<p> According to the present invention, oral communication to and from a party selected in the gameplaying system can be prohibited.</p>

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

<u style="single">A game system as an example for carrying out the present invention</u> As shown in FIG. 1, the electronic game system 100 as an example supports a game console 102 and up to four user input devices such as controllers 104a and 104b. The game console 102 supports an internal hard disk drive (not shown in this figure) and various forms of portable optical storage media represented by the optical storage disk 108. Examples of suitable portable storage media include DVD (digital versatile disk) discs and CD (compact disc [disk])-ROM (read only memory) discs. In this gaming system, gaming programs are preferably distributed on DVD discs for use in game consoles, but other storage media are available instead, or other programs are available on the Internet or other. It is intended that it is possible to download via the network of.

On the front of the game console 102, four connectors 110a, 110b, 110c, 110d are provided for electrical connection to the controller. It is also contemplated that other types of connectors or wireless connections can be used instead. A power button 112 and a disc tray eject button 114 are also located on the front of the game console 102. The power button 112 controls the application of power to the game console, and the eject button 114 alternately opens and closes the tray (not shown) of the portable media drive 106 to allow the storage disk 108 to be inserted and removed. Allows the digital data on that disk to be read and loaded into memory, or stored on a hard drive for use by the game console.

The game console 102 connects to a television, or other display monitor, or screen (not shown) via an A / V (audio / visual) interface cable 120. Power cable When plug 122 is connected to a conventional AC line source (not shown), it transfers power to the game console. The game console 102 may further include a data connector 124 that transfers data to the network and / or the Internet over Ethernet® connections or over broadband connections. Alternatively, it is contemplated that it is possible to transfer data to the network and / or the Internet using a modem (not shown). As a further alternative, it is possible to link a game console directly to another game console via an Ethernet cross-over cable (not shown).

Each controller 104a and 104b is coupled to the game console 102 via a lead (or, in another intended embodiment, otherwise, via a wireless interface). In the illustrated embodiment, the controller is universal serial bus (USB) capable and is connected to the game console 102 via a USB cable 130. The game console 102 can be equipped with any of a wide variety of user devices for interacting with and controlling the game software. As shown in FIG. 1, each controller 104a and 104b includes a thumb stick 132a, 132b, 132c, a D pad 134, a button 136, and two triggers 138. The above controllers are merely representative and use other game input and game output mechanisms in place of those shown in FIG. 1 or those shown in FIG. 1 to control the game console 102. It can be used in addition to.

Detachable functional units or functional modules can optionally be inserted into controllers 104a, 104b to provide additional functionality. For example, with a portable memory unit (not shown), a user can store game parameters and insert the portable memory unit into a controller on another console to play a game on another game console. You will be able to carry that parameter. Other removable functional units are available for use with the controller. In connection with the present invention, a removable functional unit equipped with a voice communication module 140 is used to allow a user to communicate verbally with other users locally and / or over a network. become. A headset 142 is connected to the voice communication module 140, preferably a boom microphone 144 or other type of audio sensor, and a game that produces an input signal in response to incident sound. Includes headphones 146 or other types of audio transducers to produce audible sound in response to output signals from the console. In another intended embodiment (not shown), voice communication competence is included as an integral part of the controller (not shown), which is otherwise generally similar to controllers 104a and 104b. .. The controller shown in FIG. 1 is configured to contain two removable functional units or modules. However, more or less modules can be used instead.

The game system 100 can, of course, play games, but can also play music and videos on CDs and DVDs. Perform other functions by the game controller using digital data stored on a hard disk drive, or read from optical storage disk 108 on drive 106, or from an online source, or from a functional unit or module. Is intended to be possible.

<u style="single">Functional components for carrying out the present invention</u> Next, referring to FIG. 2, a functional block diagram, as an example, how components are provided to facilitate voice or verbal communication between players while playing an electronic game on a multiplayer game console. Indicates whether it will be. As mentioned above, this embodiment of the game console 100 can have up to four players on each console, and each player can be equipped with a controller and a voice communicator. .. Details of the voice communication module 140a are shown in relation to the associated controller 104a. Understand that controllers 104b, 104c, and 104d (if coupled to game console 100) can optionally include corresponding voice communication modules, such as those coupled to controller 104a, respectively. I want to be. In the current preferred embodiment, the voice communication module 140a includes a digital signal processor (DSP) 156, an analog-to-digital converter (ADC) 158, a digital-to-analog converter (DAC) 161 and a universal serial bus (USB) interface 163. including. In response to sound in the incident environment, the microphone 144 produces an analog output signal that is input to the ADC 158, which converts the analog signal to the corresponding digital signal. The digital signal from the ADC 158 is input to the DSP 156 for further processing and the DSP output is applied to the USB interface 163 to connect to the controller 104a. In this embodiment, the voice communication module 140a is connected to a functional unit port or functional module port on the controller 104a via a USB connection (not shown separately). Similarly, digital sound data coming from the game console 100 is transmitted via controller 104a and applied to USB interface 163 for interface. The digital signal is transmitted to the DSP 156, and the DSP 156 transmits the digital signal to the DAC 161. The DAC161 converts the digital signal into the corresponding analog signal used to drive the headphones 146.

A reference to the Multiplayer Game Console 100 shows some important functional components. However, it should be understood that other functional components valid for the present invention are also included, but are not shown. Specifically, the game console 100 includes a CPU (central processing unit) 150 and a memory 152 including both ROM and RAM (random access memory). DSP154 is also available. The digital signal generated by the ADC 158 in response to the analog signal from the microphone 144 is transmitted to the CPU 150 via the controller 104a, which is through an Ethernet® port (not shown in Figure 2) on the game console. Handles the coding of its voice stream signals for transmission to other local voice communication modules and other game consoles over a broadband connection.

An alternative embodiment uses DSP156 inside the voice communication module 140a to encode the digital signal generated by ADC158 in response to the analog signal from microphone 144. The encoded data is then transmitted to the CPU 150 via the controller 104a, which again encodes to other local voice communication modules and other game consoles over a broadband connection on the game console. Handles the transmission of converted data.

The multiplayer game console 100 is more conventional, either by connecting directly to another game console using a crossover Ethernet® cable, or by using a hub, switch, or other similar device. It is possible to connect to one or more other multiplayer gaming consoles over the network and / or a suitable cable modem, digital subscriber line (DSL) connection, or other suitable interface broadband connection. It is possible to connect to the Internet or other networks via. An alternative embodiment in which the multiplayer game console 100 is connected to the Internet or other network via a modem (not shown) is also contemplated. Digital signals transmitted as packets over a direct or network connection are delivered via the Ethernet® port on Game Console 100 (or from other voice communication modules and controllers connected to the same Game Console) CPU 150. The data packet is decrypted by the CPU and the digital sound data applied to the DSP154 for output mixing is recovered. The signal from the DSP 154 is transmitted to the destination voice communication module for the player, which is the receiver of the voice communication, for input via the USB interface 163.

An alternative embodiment uses a CPU to transmit encoded data packets through the controller 104a to the destination voice communication module 140a. The encoded data packet is then decoded by DSP156 inside the voice communication module 140a, the resulting decoded signal is transmitted to DAC161, which generates the corresponding analog signal that drives the headphones 146. To do.

In yet another intended alternative, the headphones and microphones for each player are coupled directly to the game console, and the functionality of the voice communication module is the CPU inside the game console, or other processor such as a DSP, and suitable. It can be done by the DAC module and the ADC module. Therefore, the positions of the components that process the sound signals to generate the sound data transmitted between the players and the components that generate the analog signals that drive the headphones of each player are not important to the present invention.

The CPU 150 also applies audio effects that change the characteristics of the sound of the player speaking into the microphone 144, and various effect selections can be used to change the nature of the sound. For example, a female player may have some audio effects that make her voice sound like a male fat voice, or some audio effects that make her voice elfin quality. Other desired audio effects can be selected to have different tonal and pitch characteristics. The available audio effects that the player can select depend on the game. Such audio effects can substantially change the sound of the player's audio so that the player is virtually unrecognizable, and one character in the game is another character. It is possible to add dramatic qualities or a better sense of reality to the character controlled by the player when it appears to speak to. Therefore, by voice effect, role playing (role) Playing) becomes easier and the true identity of the player is hidden. Players connected to the same game console 100 are only a few feet apart (1 foot is 30.48 cm) in the room where the game consoles are located, so even when they can hear each other directly. Due to changes in the player's audio due to the applied audio effects, the sound heard by other players receiving verbal communication through the headphones is significantly altered and the locality of the player's audio propagates to the players indoors. Sounds can be easily ignored.

In fact, a preferred embodiment of the Game Console 100, but not limited to in the present invention, is for up to 16 players for in-game oral communication over the Internet via a network or through an online gaming service. Designed in anticipation of being able to participate. Obviously, there is a practical limit to the number of verbal communications from other players that one can expect to join at one time. Therefore, it was assumed that the player could not understand the verbal communication from more than four other players speaking at the same time.

<u style="single">Gameplay scenario</u> There are different suitable scenarios, depending on the type of game and the number of players participating in a given game that affect the requirements for encoding and decoding voice communication signals. For example, there are three main scenarios that affect the requirements for voice communication. The first scenario, called "point-to-point," involves one player in each of the two interconnected game consoles, with each player participating in voice communication with the other player. In the second scenario, called "multipoint", there is still only one player participating in voice communication on each game console, but since the game is played with up to 16 players participating, Up to 16 game consoles are interconnected over the network. The third scenario is called "multiplayer on the game console". This is because up to 4 players per game console and up to 4 game consoles are interconnected via a network, and up to 16 players can play games at the same time and communicate verbally. This is because it becomes possible to take. For this final scenario, two or more players on a single game console are physically in the same room, but as mentioned above, each due to the audio changes brought about by the use of the audio effects option. It is also possible to use voice communication during the game as it can increase the enjoyment of the game and role playing by the player. Furthermore, the limit on the total number of game consoles / players mentioned in each of the above three scenarios can be considered as a soft limit. This is because there are no inherent hardware limits that exclude the participation of additional players or game consoles.

By designing the game according to one or more of the above three scenarios, the software designer sets the maximum predefined limit for the computational resources allocated to voice communication, and voice communication is the game. It is possible to avoid adversely affecting the quality of play. It is also possible to have unique requirements such that a particular game played on a multiplayer game console should be played only by a certain number of players. In this case, the nature of the game limits the number of oral communication channels required. For example, games such as chess are usually played using point-to-point scenarios. This is because chess usually involves only two players. The voice communication feature allows the two players to talk to each other while playing a chess game. For this point-to-point scenario, each game console only needs to implement one encoder and one decoder. This is because multiple encoders and decoders are not needed. During each audio frame update, the CPU on the game console updates the coding and decoding as needed. Using the 1.5 percent predefined coded CPU utilization limit and the 0.5 percent decrypted CPU utilization limit in this point-to-point scenario, the total CPU utilization required is only about 2.0 percent. ..

As shown in the functional block diagram of FIG. 4, the game console 102 is coupled to the game console 172 for voice communication. The microphone 144 responds to the voice of the player using the console 102, and the voice communication module connected to the microphone generates PCM (pulse code modulated) data input to the single stream encoder 160. In response to the PCM data, the encoder generates a compressed data packet, which is then transmitted over the network 170 to which the game console 172 is connected.

Alternatively, single stream coding can be done by the DSP of the voice communication module. In this embodiment, the microphone 144 responds to the voice of a player using the game console 102, the DSP156 is connected to the ADC158 to generate a compressed data packet, which in turn connects to network 170. It is sent to the game console 102 for transmission to the game console 172 via.

The compressed data from the game console 102 is input to the network queue 174 in the game console 172. The purpose of using network queues to receive compressed sound packet data from console 102 is to eliminate jitter and other timing anomalies that occur when the data is transmitted over network 170. The output of the single stream decoder is PCM data, which is then applied to the DAC inside the voice communication module of the player using the game console 172 to generate an analog output that drives the headphones 178.

In an alternative embodiment, the compressed data is transmitted from the game console 102 to the DSP 156 inside the voice communication module. The DSP decodes the compressed data and converts it into a corresponding PCM signal, which is applied to the DAC161 inside the voice communication module of the player using the game console 172 to drive the headphones 178. The corresponding analog output signal used for is generated.

Similarly, for verbal communication from a player using the console 172, the microphone 180 converts the incident sound into PCM data using the ADC inside the communication module to which the microphone 180 is connected, and this PCM data. Is input to the single stream encoder 182, and the encoder 182 generates compressed data transmitted via the network 170 to the network queue 162 inside the game console 102. The compressed data from the network queue 162 is input to the single stream decoder 168, and the decoder 168 generates PCM data input to the DAC converter inside the voice communication module to which the headphones 146 are connected. The DAC produces the corresponding analog sound signal. Thus, the headphones 146 receive an analog sound signal (with any added audio effects) that corresponds to the sound of the player connected to the console 172.

In a multipoint scenario where there is one player on each console, but multiple game consoles are participating in the game session, the game designer will say that all players are with all the other players playing the game. It is possible to decide whether to be able to communicate verbally, or if there is a team of a subset of players, only players on the same team should be able to talk to each other. .. For example, if the game being played in a multipoint scenario is a card game, there can be four individual players, one per game console, or two players each. It is possible that there are two teams. If there are four separate players, each game console implements one encoder and one 4: 1 decoder (described below). During the audio frame update, each console updates the encoding required to transmit utterances by a single player using the game console, and (up to) 3 people on other game consoles participating in the game. Update the decryption of speech data from any player among other players. For this scenario, with a predefined coding limit for 1.5 percent CPU utilization and a 4: 1 decoder limit for 1.3 percent CPU utilization, the four games used to play card games In each of the consoles, the total CPU usage is approximately 2.8 percent.

Figure 3 shows how the multipoint scenario is functionally implemented on each game console, but does not show the other game consoles. However, it is understood that the network 170 is coupled to other game consoles that communicate with the illustrated game console. As mentioned above, the game console includes a single stream encoder 160 that receives the PCM data generated by the ADC inside the player's voice communication module (not shown in Figure 3). The PCM data is input to the single stream encoder 160 and an audio frame of compressed data in the form of packets is generated for transmission over the network 170 to other game consoles. Similarly, packets of compressed data are transmitted from other game consoles to the illustrated game console over network 170. Each player participating in the game (or channel) has a network queue on the game console where data packets are temporarily stored and is selected engine 164a for mixing by the mixer 166a and for decoding by the decoder 168a. Ensures that jitter and other timing issues are minimized when packets of data compressed by are selected. The decoder 168a generates PCM data supplied to the DAC, and the DAC generates an analog signal that drives the headphones 146.

In an alternative embodiment, the selection engine 164a transmits two selected compressed data streams to DSP156 of the voice communication module (shown in FIG. 2) for mixing and decompression. The DSP156 generates a corresponding PCM signal that is fed to the DAC inside the voice communication module, and the DAC produces a corresponding analog signal that drives the headphones 146.

As shown in FIG. 3, network queues 162a, 162b, and 162c are provided to each of the other players, ie, up to N players, respectively.

In the multipoint scenario described above, there are only three network queues, as there are only three remaining players participating in the card game. Since the mixer 166a combines only two inputs at a time, the decoder 168a can only provide a player wearing headphones 146 with simultaneous PCM data about two players at a time. In contrast, an alternative embodiment is also shown in which the decoder 168b includes a mixer 166b that combines four data packets from the selection engine 164b at once to produce the output provided to the headphones 146. In this alternative embodiment, the player is provided with up to four other voice data packets at the same time.

Alternatively, the selection engine 164a can be used to transmit four selected compressed data streams to DSP156 inside the destination recipient's voice communication module. The DSP156 also generates the corresponding PCM signal supplied to the DAC inside the voice communication module and the corresponding analog signal that drives the headphones 146.

Figure 5 shows the functional details of the "multiplayer on game console" scenario. In FIG. 5, a game console 102 is connected to network 170 via network layer 206, thereby providing a game console 210 with players 216a and 216b, a game console 212 with a single player 218, and four players. It is connected to a game console 214 with 220a, 220b, 220c, and 220d. Players 200a, 200b, 200c, and 200d are connected to the game console 102, and each player includes a game controller having a voice communication module. In this scenario, all players on consoles 210, 212, and 214 each have voice communication encoded to produce a single stream of compressed data packets. The network layer 206 inside the game console 102 sends data packets from each of the remaining three game consoles to the network queue 162 for the second game console 210, the network queue 184 for the third game console 212, and the fourth game. Put in three separate network queues, including network queue 186 for console 214. The output from these three network queues inside the game console 102 is input to the decoder 168, and the output of the decoder 168 is applied to the output router 188, which determines the particular headphones that receive voice communication 190a-190d.

An alternative embodiment uses an egress router 188 to bypass the decoder 168 and pull data packets directly from network queues 162, 184, and 186. The output router 188 transmits the compressed data to the DSP inside the voice communication module of the destination receiver so that the player's headphones receive the voice communication 190a to 190d.

Therefore, each player 200a to 200d receives only voice communication destined for that player. Similarly, sound input from the corresponding microphones 202a, 202b, 202c, and 202d of each of the four players on the game console 102 is supplied to the input router 204, which routers the PCM data stream to the encoder 160. The output of the encoder 160 is coupled to the network layer 206 by selectively applying to. The network layer ensures that compressed data packets carrying sound data are transported over network 170 to the appropriate game consoles 210, 212, and 214. An output router inside each game console with multiple players determines which player receives voice communication from the player using the game console 102.

Another embodiment bypasses the input router 204 and encoder 160 by encoding the compressed data using a DSP inside the voice communication module of the speaking player.

<u style="single">Prioritization / round robin technology for coding</u> FIG. 6 shows a functional aspect of prioritization on a game console that handles voice communication by up to four players using the game console to play the game. During each voice interval, only two of the four encoder instances are active, so there are fewer encoders on the game console than there are players with voice communication skills. Therefore, although there are four microphones 211a, 211b, 211c, and 211d, not all digital PCM data from the ADC inside the voice communication module connected to each of these microphones is encoded at the same time. Each stream of PCM data is applied to the voice activation detection algorithm as shown in blocks 213a, 213b, 213c, and 213d. This algorithm determines when a player speaks into a microphone and produces PCM data that must be encoded for transmission to one or more other players in the game. In the worst case scenario, all four players are speaking at the same time and the voice activation detection algorithm needs to encode the PCM data from all four microphones connected to the game console. May indicate. However, in this preferred embodiment, only two audio streams can be encoded at a time, so the prioritization algorithm in block 215 determines the stream of PCM data input to the two parallel encoders 160a. Or select. These encoders generate compressed data in packetized frames transmitted over the network (game consoles are connected to one or more other game consoles over a link or network. (Assuming that). In the example shown in Figure 6, the prioritization algorithm encodes into the current frame for output over the network. In this regard, we have selected two streams of PCM data, including PCM data 217c and 217d, as having the highest priority. In contrast, the PCM data in streams 217a and 217b does not have an audio input, but if it contains audio data in the next frame of the compressed data, it is best to encode. Is marked as having the priority of.

A round robin coding method is used to allow two parallel encoders to encode voice communication from four players, allowing them to speak during any given voice data frame. Make sure that fewer encoders than the total number of players are needed on the game console. FIG. 12 provides details about the logical steps performed to allow round robin coding of audio frames, starting at start block 380. In step 382, an array of four PCM packets (one for each player) is assembled. If the player does not have voice communication, PCM silence packets are inserted into the array. Determination step 384 determines if the logic is executing the first loop for the current audio frame. If running, step 386 provides to prepare the precedence in the array using the variable priority (i), where i can have values 0, 1, 2, or 3. The logic then proceeds to step 390.

If the logic is not doing the first loop for the current audio frame, it proceeds to step 388 and uses the priority array generated in the previous loop for the current audio frame. The logic then proceeds to step 390 as well. At step 390, voice activation is detected and the PCM packet is marked to indicate whether the packet has voice content. The algorithm detects if the current sound level is significantly higher than the average (background) level, which indicates that the player with the microphone is probably currently speaking into the microphone. ing. Alternatively, it is possible to analyze the PCM packet to detect voice characteristics that are significantly different from the background noise characteristics. Step 392 then initializes the variable priorities index as equal to zero and the variable encodeops as equal to zero.

Determination step 394 determines if the priorities index variable is less than 4 and if the encodeops variable is less than 2. Since the determination step 394 is first reached immediately after step 392 in which the above two variables are initialized to zero, both criteria are satisfied and the process proceeds to step 402. In step 402, the variable PCM stream index is set equal to the variable priorities and the value i equals the priorities index variable. At the first pass for the audio frame, the PCM stream index variable is set equal to priorities [0].

Next, determination step 404 determines whether voice is detected for the PCM packet with an index equal to the PCM stream index. Again, along with the first path of this logic between audio frames, the determination step determines if audio has been detected for the PCM packet [PCM stream index]. If detected, step 406 moves the variable priorities [priorities index] at the end of the priority array to move the rank of all other elements after this variable one step forward. Step 408 then sets the variable encodeops equal to the previous value plus one, thereby incrementing this variable. If no audio is detected in determination step 404, step 410 sets the priorities index equal to the priorities index plus one, thereby incrementing this variable. After step 408 or 410, the logic proceeds to determination step 394.

If the priorities index variable equals 4 or the encodeops variable equals 2, the logic proceeds to step 396. In this step, the logic sets the audio detection properties for PCM Packet [priorities [0]] and PCM Packet [priorities [1]] to false. Next, step 398 provides parallel coding of PCM Packet [priorities [2]] and PCM Packet [priorities [3]]. Finally, in step 400, logic assembles an array of four compressed data packets for transmission over the network with respect to the current voice frame. Based on this logic, if all four players are actually speaking, the PCM packet will allow this round robin algorithm so that all players on the voice console can communicate with other players in the game. It will be clear that it is encoded to form a compressed packet using.

It may be helpful to follow an example where players 1, 2, 3, and 4 are all supposed to be talking at the same time. It keeps a history of the latest two encoded voices or two players. The logic starts by examining the current microphone packet for player 1. If the voice is detected by the algorithm, the voice is encoded. The same determination is then made for player 2. That is, if the audio is present in the microphone of player 2, the audio is encoded in the current audio frame. The initial history begins with the player in the order [1,2,3,4], at which point the order is updated to be the player [3,4,1,2]. The logic loops back after a predefined microphone coding interval to process audio data for the two players that were not previously processed. Currently, the history list is [3,4,1,2], and therefore a test is being performed to determine if player 3 audio is currently being input to player 3's microphone. If so, the audio is encoded. However, if player 3 is no longer speaking at this point, logic instead proceeds to player 4, which is supposed to be speaking. Therefore, the digital PCM voice packet for player 4 is encoded and the history is updated to [3,1,2,4]. The logic then goes to player 1 and encodes that player's voice to generate a new history [3,2,4,1]. The logic then starts with players 3 and 2. Assuming that player 3 has not spoken yet and therefore there is no audio in that player's microphone, the logic encodes the digital PCM packets for players 2 and 4 and the history list [3,1,2,4 ] Bring.

In one embodiment, for each skipped and unencoded player's PCM packet, the packet in front of that player is attenuated and played with respect to the audio frame. In the worst possible situation, when all players are talking and, in fact, there are four different players on different teams on the game console, every other PCM packet for each player is skipped. This technique has a slight adverse effect on the voice quality of each player, but this is a worst-case scenario, which usually occurs rarely during gameplay.

Note that the player's PCM packet, which is skipped and therefore must be filled by repeating the previous packet, is not transmitted over the network. Instead, the recurring PCM packet is handled by the receiving game console used by the recipient of the packet's destination. Therefore, in any one audio frame, at most two packets are sent from the game console instead of at most four. The queue buffers the previous packet and provides the previous packet to replace the skipped packet. Alternatively, the skipped packet is not queued by the receiving game console, and instead a notification that the packet was skipped by the transmitting game console is posted on the receiving game console for that channel. Inserted into the network queue.

The round robin coding technique works for only two audio frames at a time and repeats the other frames of the currently unencoded stream. As mentioned earlier, this can result in sound degradation when all four players on a game console are speaking, but this technology uses additional CPU resources for all four players. It is avoided to encode the player's audio separately. Encoding the audio of all four players separately using additional CPU resources can adversely affect gameplay.

In an alternative embodiment, one encoder per player is assigned to encode the utterance. However, this embodiment is less desirable. This is because it requires twice as many computational resources as the embodiments described above.

<u style="single">Voice communication over links / networks</u> Figure 10 shows the general steps applied to enable voice communication over a link or network. First, the game starts at step 330. Next, determination step 332 determines whether the player has stopped communicating with other players by voice. This condition may result from the player being banned or suspended from taking voice communication by an online gaming service due to a breach of the Code of Conduct or other service policies. Another reason voice can be blocked is that authorized individuals, such as parents, should not allow minor children to engage in voice communication with other players during the game. It depends on the decision. This option is available and can be set using the options provided on the game console for a particular player account. Once set, the data is stored on the online gaming service and the voice communication is blocked each time the player connects to the service. If the voice communication of the current player is blocked, step 334 determines that the game console does not have to handle the voice communication, and step 336 proceeds to the next speaker instead. Assuming that the next speaker is not excluded from taking voice communication by the settings on the game console, the logic goes to step 338 to get the PCM data from the ADC inside the voice communication module for that player. The logic then compresses the PCM audio data into compressed data in step 340. Step 342 applies some assigned audio effect to change the audio characteristics of the player when compressing the PCM audio data of the current player. In step 344, the compressed data is destined for the destination over network 346. It is transmitted to the receiving game console and reaches the recipient of the destination having the voice communication module. Step 348 prepares to process the next speaker on the game console transmitting the compressed data, thereby returning to decision step 332.

On a game console that receives voice communication over network 346, step 352 provides adding compressed data to the network queue for such data. Then, in step 354, the game console decompresses the compressed data drawn from the queue and generates the corresponding PCM data. Step 356 provides to add optional environmental effects, if any. Such effects are generally determined by the options offered in the game being played on the game console. For example, environmental effects can include adding reverberation, or, if the game's environment is inside a cave, introducing reverberation, or environmental effects can be, for example, audio on a small speaker. Bass boost (bass) for data playback It is possible to be involved in providing frequency band equalization by adding boost). Step 358 then mixes the audio streams received from multiple different players into a single output audio stream provided to the destination player. In step 360, this output audio stream is transmitted as PCM data to the DAC associated with the recipient player's headphones, which in turn produces the corresponding analog signal that drives the headphones. Thus, the player hears voice communication from each of the players that has been decrypted and mixed into the output voice stream.

<u style="single">Muted voice communication between players</u> Whenever one player is muted from voice communication by another player, another situation arises. When a player is muted in this way, that particular muted player cannot hear or speak to the player on the mute processing side. The player on the muting side must unmute the explicitly muted player to restore voice communication.

<u style="single">Handling of network data packets</u> FIG. 11 shows further details regarding receiving voice communication data as packets over network 346. Compressed data is received over the network from N other game consoles, as shown in blocks 350a and 350b. Each channel of compressed data is initially entered into one of N queues 351a-351b and is individually for each player on the connected game console (one or more players on each game console). Queue is provided. Block 364 then synchronizes the N queues that are formed to receive the compressed data. In this step, encoded compressed packets are obtained from all of the queues for the current voice frame. The selection engine 366 then determines in block 368 the compressed packets to be assembled for input to the decryption engine. The decryption engine decompresses the compressed data, decodes it, converts the data into PCM data, and then applies this PCM data to each of the connected voice peripheral communication modules 370 to 372. Then, each player using the voice communication module can hear the sound transmitted to himself / herself via the network.

Details related to the processing of the coded packets received from each queue are shown in Figure 7. At block 221 the CPU checks each queue to get an encoded compressed packet, or the queue does not have a packet from a player, but a packet about that player is in that queue. Notify the client CPU that it should have been inside. In this case, the CPU determines if the previous packet captured for that player from that queue was actually a valid encoded packet, and if so, the CPU , Copy the previous packet for that player so that it can be provided for further processing in the next block. However, if the previous packet for that player is also missing, the CPU attenuates the previous packet for that player. The purpose of this step is to skip packets during round robin coding and to minimize the perception of silence caused by missing packets resulting from dropped packets due to network conditions.

Next, in block 222, the packets acquired in block 221 are arranged, and all silent packets in the array are removed. The result is a subset of the packets originally served in the queue. By the above processing, all packets in the subset contain valid voice data.

Block 224 then provides to apply a channel mask to the audio data. Channels are associated with each player, and all players on a particular channel can communicate with each other by voice. For example, one channel can be used for voice communication between a player nominated as a team leader and a team member, allowing that player to communicate with all members of the team. Is. In addition, the team leader may select another channel to verbally communicate with another player nominated as a commander who can communicate with multiple team leaders, or the team leader may be another team leader. It is also possible to select yet another channel that allows communication only with. In this embodiment, each talking player is given a 16-bit word that defines a "talker channel" for that player. The game determines what each bit of a word about a speaker channel means, and indicates, for example, that the speaker channel is for a team, for a team leader, for a commander, and so on. In addition, each player can be assigned a "listener channel" that can receive utterances. When voice communication comes in over the network, the speaker channel is logically "AND" with the listener channel for a given player, and if the result is non-zero, that player performs voice communication. I can hear it. In this way, the game being played (or each player within the constraints of the game) selects any permutation that determines which player is combined to communicate voice with other players. be able to.

With reference to FIG. 7 again, block 224 allows each player to listen to only some channels and choose to use a channel mask. A channel mask is applied for each player on the game console, resulting in a maximum of four subsets of the audio stream, i.e. one subset for each player listening, based on the player's individual listener masks. Each listening individual has a list of candidate packets contained in different audio streams.

At block 226, a mute mask and user-defined priorities are provided. A preferred embodiment allows the player to selectively exclude further voice communication with the selected player, but the player mutes voice communication with a particular player during the current game session. It is also envisioned that it is possible to selectively do only what to do. In this alternative embodiment, each player on the game console can choose to mute people on the listening channel. The audio stream from the player muted by that player is then removed from the list of candidate audio streams for that player on the game console. All remaining audio streams for each player are sorted by user-defined priorities. In this step, one audio stream can always have the highest priority. For example, the game (or, if the game allows that option), selectively configures the channels that the team members join to have voice communication with the team leader, and that channel is each of the team members. It is possible to have the highest priority for. In addition, the volume of the incoming audio stream also serves as a criterion for determining the priority of the channel for a given player, and it is possible for the player to always listen to the loudest audio stream. Alternatively, or even more, if the rendering of an audio stream begins, the game waits for the audio stream to end, regardless of the volume of the other audio stream that started later, before the audio stream ends. Make sure that the statement is not interrupted "mid-stream". As a further alternative, or in addition, it is possible to define other priorities for each audio channel. For example, it is possible to apply priorities related to game-specific roles.

After block 226, the decryption engine type 1 shown in block 228 or the decryption engine type 2 shown in block 230 is also used to apply the mute mask and the priority defined by the user / game. Apply decryption to the dropped audio stream. At block 228, the decoding engine type 1 allocates a decoder to mix and decrypt for each player's method. The algorithm selects the first N packets in the array of packets for each player. If the list contains less than N elements, use silent compressed data packets instead of non-existent packets to avoid spikes in the CPU processing of voice packets.

At block 230, when applying decoding using engine type 2, a decoder is assigned to perform decoding and mixing with DSP methods. According to this algorithm, until the maximum number of decrypted packets is reached, the end of candidate packets is reached, or the end of the candidate packet list is reached, from the arrayed list of packets, if the list is not empty, the current Players are acquired. If the beginning of the list of arranged packets is not previously selected, the beginning of the list is selected to be decrypted and the counter is incremented for the decrypted packets. The head of the list is then removed from the arranged list. The algorithm then proceeds to the next player, which becomes the current player. For example, after player 4, player 1 then becomes the current player again. If there are decryption slots left to decode additional voice packets, the silent packets are applied to the parallel decoder to avoid spikes in the CPU processing of the voice packets.

<u style="single">Decryption engine, types 1 and 2</u> FIG. 8 shows details about the functional aspects of the decryption engine type 1. As shown in FIG. 8, the coded streams 1 through N, represented by codes 240, 242, and 244, are used in the selection engine 257 to select two coded streams for decoding for each player's headphones. Provide compressed data. In this case, the encoded stream 1.1 and the encoded stream 1.2 are selected for input to the decoder 168a, where the streams are mixed by the mixer 252 prior to decoding. The output of the decoder is the PCM data supplied to the DAC inside the voice communication module with respect to the headset 248. Similarly, for each of the other player's headphones, another decoder 168b receives an audio stream encoded as compressed data, which is mixed and decoded. As shown, the decoder for the fourth player includes a mixer 254 that mixes the encoded audio streams 4.1 and 4.2, and the decoder provides the analog signal that drives the headphones 250 for the fourth player on the audio console. It is designed to generate PCM data supplied to the provided DAC. Of course, there are cases where less than four players are using the game console, in which case less than four decoders need to be active.

An alternative embodiment for both Decryption Engine Type 1 and Decryption Engine Type 2 transmits the prioritized voice stream (in block 226) directly to the DSP inside the destination recipient's voice communication module. ..

The functional aspect of the Type 2 decoding engine is shown in Figure 9A. Again, the encoded streams 1 through N represented by the codes 240, 242, and 244 are input to the selection engine 260, which is listening and has an audio stream directed to it. Select a maximum of 4 decoder streams and a minimum of 1 decoder stream for each player. In this case, four parallel decoders 262 receive the compressed data of four selected encoded audio streams. The decoder then decodes the compressed data and feeds the resulting PCM data to the mixer for each player to which the audio stream is directed. In this case, the first player receives two audio streams from another player mixed by the mixer 270 inside the mixer identified by code 264. Although not shown, each of the other players receiving voice communication from other players in the game also has a separate mixing bin to which the output of the four parallel decoders is applied for mixing. For example, a fourth player receives three audio streams mixed by mixer 272 inside the mixer identified by code 266. The resulting PCM data is then applied to the headset 250 for the fourth player. Thus, each player can receive one or four audio streams mixed by a four-in-one mixing bin assigned to that player.

Another embodiment (in block 260) bypasses the decoder 262 and the mixers 264 and 266 and transmits the compressed data to the DSP of the voice communication module coupled to the headphones 248 and 250, respectively.

An alternative technique for use with a Type 2 decryption engine is shown in Figure 9B. In this embodiment, the relative arrangement of the decoder and mixer is reversed from that shown in FIG. 9A. Specifically, each player has a two-stream mixer that is combined to receive and mix compressed data that arrives over the network. A 2-stream mixer 280 is provided to player 1, a 2-stream mixer 282 is provided to player 2, a 2-stream mixer 284 is provided to player 3, and a 2-stream mixer 286 is provided to player 4. Therefore, the compressed data of up to two audio streams was input to each of the above mixers per player, mixed, and single mixed from each mixer for input to the 4-stream parallel decoder 288. A stream is provided. The decoder then decodes the compressed data to generate PCM data that is fed to the headphones 248, 252, 253, and 250 of each player that is the recipient of voice communication from another player. ..

In yet another embodiment, the compressed data transmitted to the two-stream mixers 280, 282, 284, and 286 is decoded by the DSP of the voice communication module coupled to headphones 248, 252, 253, and 250, respectively. To be done.

<u style="single">Control voice communication with other players</u> As mentioned above, the player has the option to exclude further voice communication with a particular player due to behavioral issues or for other reasons. For example, if one particular other player tends to use excessively profane language, the player may choose not to communicate further with that other player. Each game generally provides an option for the player to mute voice communication with another player for the current and future game sessions, and for the player to be another player only in the current game session. It is also intended that it is possible to mute voice communication with. Figures 13, 13A, and 13B show this control of voice communication as "My Game (MY). Dialog boxes 430 and 450 are shown as examples that can be implemented in a game called "GAME)". This fictitious game lists each of the players, as shown in player list box 432. The player list box 432 contains six players with the first listed player selected, as indicated by the selection bar 434. This player, who plays the game using the alias "Avenger", has voice communication skills in the same row as the alias, as indicated by the speaker symbol 436 in one column of the dialog. Players using the aliases "Iceman" and "Raceox" respectively are clear from the lack of speaker symbol 436 in that column in either of the above aliases in the same row. As you can see, it does not have voice communication skills. From voice communication with the current player looking at the player list box 432, a radio button 438 is provided that allows any player on the listed player to be muted. In this case, the avenger is selected by the player, as indicated by radio button 438. When a player is selected, a window 440 opens that identifies the selected player and indicates that this player is currently one of the participants in the game and has a voice communication module. If the player looking at the player list box 432 clicks the select button 442, the voice communication status select 450, which includes an option bar 452 that can switch to a different state, opens. As shown in FIG. 13A, option bar 452 indicates that the selected player is able to communicate verbally with the player selecting this option. In Figure 13B, the options bar has been switched to state 454, which Indicates that the player looking at that state wants the selected player to be muted for the current game session. The speaker symbol 436 changes according to the choices made by the player. Instead of what is shown in Figure 13, if the player chooses the option to mute the particular player selected, a dash box will appear around the speaker symbol shown. This type of mute processing ends after the current game session. On the other hand, if a particular player is selectively locked out, a dash heavy-bar box is added around the speaker symbol 436. In that case, the decision to mute a player can only be turned off by the player making the decision from within the game session, or by using the system controls on the game console. Yet another symbol (not shown) is voice communication about the corresponding player via loudspeakers (eg, television speakers or monitor speakers) connected to the recipient player's game console rather than through headphones. Used to indicate that it will be regenerated. This option can be selected by players who prefer not to wear a headset, but it is less desirable. This is because the player does not use the microphone to communicate verbally with other players. box) appears. This type of mute processing ends after the current game session. On the other hand, if a particular player is selectively locked out, a dash heavy-bar box is added around the speaker symbol 436. In that case, the decision to mute a player can only be turned off by the player making the decision from within the game session, or by using the system controls on the game console. Yet another symbol (not shown) is voice communication about the corresponding player via loudspeakers (eg, television speakers or monitor speakers) connected to the recipient player's game console rather than through headphones. Used to indicate that it will be regenerated. This option can be selected by players who prefer not to wear a headset, but it is less desirable. This is because the player does not use the microphone to communicate verbally with other players. box) appears. This type of mute processing ends after the current game session. On the other hand, if a particular player is selectively locked out, a dash heavy-bar box is added around the speaker symbol 436. In that case, the decision to mute a player can only be turned off by the player making the decision from within the game session, or by using the system controls on the game console. Yet another symbol (not shown) is voice communication about the corresponding player via loudspeakers (eg, television speakers or monitor speakers) connected to the recipient player's game console rather than through headphones. Used to indicate that it will be regenerated. This option can be selected by players who prefer not to wear a headset, but it is less desirable. This is because the player does not use the microphone to communicate verbally with other players. box) is added around the speaker symbol 436. In that case, the decision to mute a player can only be turned off by the player making the decision from within the game session, or by using the system controls on the game console. Yet another symbol (not shown) is voice communication about the corresponding player via loudspeakers (eg, television speakers or monitor speakers) connected to the recipient player's game console rather than through headphones. Used to indicate that it will be regenerated. This option can be selected by players who prefer not to wear a headset, but it is less desirable. This is because the player does not use the microphone to communicate verbally with other players. box) is added around the speaker symbol 436. In that case, the decision to mute a player can only be turned off by the player making the decision from within the game session, or by using the system controls on the game console. Yet another symbol (not shown) is voice communication about the corresponding player via loudspeakers (eg, television speakers or monitor speakers) connected to the recipient player's game console rather than through headphones. Used to indicate that it will be regenerated. This option can be selected by players who prefer not to wear a headset, but it is less desirable. This is because the player does not use the microphone to communicate verbally with other players.

Several players give negative feedback about a particular player based on their verbal behavior, which is considered unacceptable, such as excessive use of profane words or use of sexually explicit words. When provided, the online gaming service will automatically determine that the number of complaints received has exceeded the threshold and prevent that particular player from further voice communication. This ban can permanently lock a particular player out of voice communication if a further complaint is received beyond the threshold, initially for a limited period of time, such as a week. Certain players thus banned will first be notified of a temporary suspension of their voice communication skills, and then if that player's behavior results in a permanent suspension, the result will be. You will be notified. Each time a player logs in to an online game service on the game console, a permission flag is downloaded to the game console as part of the sign-in process. This flag contains information about various aspects of the system. One of the flags determines if a particular player has permission to join the audio channel. Thus, if a particular player violates any provision of service or code of conduct, the bits that control the player's ability to communicate by voice can be modified to exclude such voice communication. is there.

When a player chooses to exclude a particular player from voice communication, the identity of that particular player is preferably transmitted to an online gaming service and stored in relation to the identity of the player who made the choice. In future sessions of any game, the player making such a decision will not receive any voice communication from that particular other player and will not transmit any voice communication to that particular other player. To do so. This decision is not clear to that particular other player. For, a dialog box showing a player's status in the game simply displays an indication on the view of that particular other player that the player making the decision lacks voice communication skills, and that decision. This is because the dialog displayed to the player who performed the above shows the muted status of that particular other player. Therefore, even if the particular player changes the alias used or signs on using a different game console, the prohibition of voice communication about that particular player by the player remains in effect.

When participating in a game via the Internet or other networks, the player optionally plays the game only with players who have agreed to a particular wording in voice communication, depending on the game being played. It is possible to select. In addition, the player can optionally choose to play the game only with a player having voice communication ability. Similarly, a player who does not have voice communication ability can selectively play a game only with another player who also does not have voice communication ability. These decisions typically apply only to current game sessions.

Although the present invention has been described in the context of preferred embodiments of the invention, it will be appreciated by those skilled in the art that it is possible to make many other modifications to the invention within the scope of the claims. Therefore, the scope of the present invention is not limited by the above description at all, and all of them are defined in relation to the scope of claims.

<figref num="1">It is a figure which shows the outline of the multiplayer game console and the voice communication system of embodiment of this invention.</figref><figref num="2">It is a block diagram which shows the multiplayer game console and voice communication module of FIG. 1 of the Embodiment of this invention.</figref><figref num="3">It is a functional block diagram which shows the multiplayer game console which has the voice communication ability of embodiment of this invention.</figref><figref num="4">It is a functional block diagram which shows two multiplayer game consoles connected by the point-to-point communication through the network of embodiment of this invention.</figref><figref num="5">FIG. 3 is a block diagram showing a first multiplayer game console coupled to communicate with three other multiplayer game consoles via a network of embodiments of the present invention.</figref><figref num="6">FIG. 5 is a functional block diagram showing prioritized coding for a plurality of players on a game console having two parallel encoders of the embodiment of the present invention.</figref><figref num="7">It is a logical diagram which shows the step used by this invention when selecting the packet to be decoded on the multiplayer game console of embodiment of this invention from a queue.</figref><figref num="8">It is a functional block diagram which shows the type 1 decoding engine used in the multiplayer game console of embodiment of this invention.</figref><figref num="9A">It is a functional block diagram which shows the type 2 decoding engine used in the multiplayer game console of embodiment of this invention.</figref><figref num="9B">It is a block diagram which shows the detail of the mixer of FIG. 9A and the 4-stream parallel decoder of the Embodiment of this invention.</figref><figref num="10">FIG. 5 is a logical diagram illustrating further details of the steps for sending and receiving encoded packets of sound data over the network of embodiments of the present invention.</figref><figref num="11">It is a functional block diagram which shows how the audio stream is received, queued, and decoded for each player on the multiplayer game console of the embodiment of the present invention.</figref><figref num="12">It is a flow chart which shows the step which performs the round robin coding of the sound packet of embodiment of this invention.</figref><figref num="13">It is a figure which shows the user interface as an example for selecting a voice option in a game which uses voice communication between players of embodiment of this invention.</figref><figref num="13A">It is a figure which shows one option which a player can choose to control or exclude voice communication with another player in the multiplayer game of embodiment of this invention.</figref><figref num="13B">It is a figure which shows another option which a player can choose to control or exclude voice communication with another player in the multiplayer game of embodiment of this invention.</figref>

Code description

100 electronic game system 102 Game Console 104a, 104b, 104c, 104d controllers 140, 140a, 140b, 140c, 140d voice communication module 144 microphone 146 headphones 150 CPU 152 memory 154, 156 Digital signal processor 158 analog-to-digital converter 160 single stream encoder 160a two parallel encoders 161 Digital-to-analog converter 162 Network queue 162a, 162b, 162c network queue 163 USB interface 164a, 164b selection engine 166a, 166b Mixer 168 decoder 168a, 168b decoder 170 network 172 game console 174 Network queue 176 Single stream decoder 178 headphones 180 microphone 182 encoder 184, 186 Network queue 188 Output router 190a, 190b, 190c, 190d voice communication 200a, 200b, 200c, 200d players 202a, 202b, 202c microphone 204 router 206 Network layer 210 game console 211a, 211b, 211c, 211d microphones 212 Game Console 213a, 213b, 213c, 213d 214 game console 215 Prioritization algorithm 216a, 216b player 217a, 217b, 217c, 217d 218 player 220a, 220b, 220c, 220d 240, 242, 244 streams 248 headset 250 headphones 252 Mixer 253 headphones 254 Mixer 257, 260 selection engine 262 4 parallel decoders 264, 266, 270, 272 Mixer 280, 282, 284, 286 2 Stream Mixer 288 4 Stream Parallel Decoder