Multi-user application program interface

Multi-user application program interface

FIELD OF THE INVENTION The present invention relates generally to computer networks, and more particularly, to applications executed by multiple users over a computer network.

Local area networks and computer networks such as the Internet are increasingly being used as backbones for various transactions and interactions between parties. From online banking, where bank customers can initiate financial transactions via computer networks, to online gaming, where gamers can participate in real-time games via the Internet, service providers increasingly support a variety of services via computer networks. Currently, there are a variety of different computer network configurations that facilitate the transactions and interactions that occur.

Many online applications include multi-user applications that run on computer systems and allow multiple geographically separated participants to interact with computer programs and other participating users within the application environment. For example, games are popular multi-user applications that are growing in popularity. Aircraft simulation games allow multiple participants to control each participant's virtual aircraft in the air, and allow participants to interact with other participants in their aircraft in the same air. Thus, an online gaming application provides a single application environment or domain coordinated by multiple participants.

To support multi-user applications, such as online games, used by geographically dispersed application users, such as game participants, and to support real-time interactions between users within the application environment, information about all participants in the environment is shared. it is necessary to do For example, in an aircraft simulation application, information about the aircraft will be shared for each participant, including aircraft size, speed, altitude in three-dimensional space, appearance details, and virtual environment details (such as buildings and terrain). . This information enables each player's computer to properly track the game's development and determine the actions performed by each of the players. This allows each participant to obtain a properly depicted visual image on the participant's visual display.

The amount of information that must be shared among all participants can be intimidating and create bandwidth disruptions. The amount of information that must be shared among the participants is large enough to interfere with the development of online games and other online multi-user applications. A technique for distributing management of online applications is disclosed in US Pat. No. 5,841,980 to R. Waters et al. entitled 'Distributed System for Communication Networks in Multi-User Applications'. has been disclosed.

The '980 patent describes a system configuration in which the functionality of a monolithic server is distributed through multiple servers serving multiple local users. Thus, while previously a single server served as the source of all application information such as game state, the '980 patent describes a situation in which game server functions are distributed across multiple computers. It is free for users (online participants) to log in to most convenient servers. In this way, there is no single "choke point" that may inhibit gameplay, and bandwidth requirements for the online gaming community are reduced. Even if the overall bandwidth requirement decreases, the full capacity of data that must be transmitted between users to support an online environment can create local pockets of strained bandwidth capacity.

Other multi-user applications provide a rather cumbersome user interface and can be inefficient for the operation of the application server. For example, some online gaming portals provide links to gaming sites of interest. The server providing the game portal web site provides links to game pages or game web sites. Thus, the game portal redirects the user to the appropriate game server or host for information about the game in progress. This places an additional operational burden on the game server.

Unfortunately, current multi-user applications are not configured for maximum efficiency of operation and cannot support multiple application users preparing a viable opportunity for online gaming. Accordingly, there is a need for an improved, more efficient online multi-user application environment. The present invention meets this need.

The present invention provides a multi-user online network application configuration in which application level information is maintained on a portal or lobby server rather than on each individual application server or host machine. Thus, users can know about and select a desired application, such as an airplane online game, through communication with the lobby server. After proper authentication processing, users may contact an associated application server, such as a game host, to initiate participation. Thus, the function of the game server is split between the lobby server and the application server. Thus, the lobby server can reduce bandwidth requirements and other operational demands on the application server. Applications may include, for example, multi-user interactive gaming applications. This improves the efficiency of the operation. In another aspect of the present invention, real-time cross-application communication is facilitated through a lobby server concept. Accordingly, a user participating in one application can communicate with a user participating in another application. Thus, a first user may be logged in to the lobby server and participate in the aircraft online gaming environment through the application server, and a second user may be logged in to the same lobby server but participate in a different application, such as a financial package or a different online game. can The first user and the second user may communicate with each other if they wish, or they may choose to participate in their respective environments separate from each other with respect to communication.

In another aspect of the present invention, multiple lobby servers and application servers are provided and are configured so that complete information regarding an online environment can be obtained. In this way, a number of tasks that must be performed to support system operation can be performed depending on which machine is most suitable for performing the task. In another aspect of the present invention, a multi-user application environment provides a common data model for maintaining user information. For example, a ladder ranking system is established in the context of an online game where user achievements are recorded and shared between users and between different applications (ie, games).

Other features and advantages of the present invention will become apparent from the detailed description of preferred embodiments, illustrating by way of example the principles of the invention.

1 shows a computer network system running a multi-user application constructed in accordance with the present invention;

Fig. 2 is a detailed block diagram of the system shown in Fig. 1;

Figure 3 is a flow chart of the operations performed by the system of Figure 1;

Fig. 4 is a flow diagram illustrating additional system operation other than that shown in Fig. 3;

Fig. 5 is a flow diagram illustrating additional system operation other than that shown in Fig. 3;

Fig. 6 is a block diagram of a computer in the network shown in Fig. 4, showing the hardware components;

Fig. 7 is a block diagram of a computer entertainment system in the network shown in Fig. 1, showing the hardware components;

<u>system structure</u>

1 is a computer network system 100 having one or more network devices having one or more client computers 102 in communication with an authentication server 104 to gain access to the system including participating in a multi-user online application. ) is a block diagram of As discussed below, a client computer may include computer 102a configured in a classic client-server configuration, or in a peer-to-peer configuration, or may combine the functionality of a client computer with the functionality of another computer. and a computer 102b configured in an integrated server configuration. A reference to a client computer 102 is understood as a collective reference to a configuration, or a reference to one configuration subgroup 102(a), 102(b) or the other) is understood as a specific subgroup. The authentication server determines whether authentication is permitted by consulting the database server 106 for user records. The authentication server also communicates with the universe manager computer 108 that maintains records about online users and helps manage online applications, or universes.

After the authentication server 104 continues to authenticate the user 102 , the user can participate in an online multi-user application by first communicating with the lobby server 110 to obtain application-level information. The application-level information may include information about the application and participating users. In the context of an online game application, for example, the lobby server 110 may provide information about a game and information about a currently participating user. After selecting the online multi-user application, the user is redirected to the appropriate application server 112 where it receives sufficient information to allow the user to participate in the online environment of the multi-user application. Accordingly, application level information is maintained on the lobby server 110 rather than on each individual application server or host machine 112 . Thus, the user can know about and select a desired application, such as an airplane online game, through communication with the lobby server, leaving the application server free to host a particular application.

1, a lobby server 110 and an application server 112 are used to illustrate that the functions of these servers may be distributed across multiple computers that integrally provide the functions, or may be provided by one or more independent network computers. It is shown as a cloud shape. For example, the application server 112 may include a dedicated application server computer 114 that functions as a distributed memory engine (DME). Alternatively, as described below, the application server may comprise a combination of an application server 112 operating in proxy capacity and an integration server 102(b) to provide an interface to the universe manager 108 . Similarly, the functionality of the lobby server 110 may be provided by a dedicated lobby server that communicates directly with the client 102 , or the lobby server functionality may be provided by another computer in communication with the client, such as an authentication server or universe manager 108 . can be provided by

Thus, the function of the game server is split between the lobby server and the application server. Thus, the lobby server can reduce bandwidth requirements and other operational demands on the application server. Applications may include, for example, multi-user interactive gaming applications. This improves the efficiency of the operation.

According to the present invention, real-time cross-application communication as well as cross-user communication is facilitated through the lobby server concept. A user participating in one application may communicate with a user participating in a different application. Thus, the first user may be logged into the server and participate in the aircraft online gaming environment through the application server, and the second user may be logged into the same lobby server, but may participate in different applications such as financial packages or different online games. have. The first user and the second user may communicate with each other if they wish, or they may choose to participate in their respective environments separate from each other with respect to communication.

The universe manager 108 plays a full administrative role, maintaining information about the system and registered and logged on users (clients) 102 , the authentication server 104 , the lobby server 110 , and the application server 112 . communicate with users through The lobby server 110 provides application level information to users, acting as a source of application information and an application portal for clients 102 . For example, unlike a typical game portal server that only provides a link to a game site, a lobby server provides information about a game in progress and game-level information, such as information about players actively participating in the game. can provide The application server 112 provides a real application environment. For example, in a situation where the online application is a game, the application server may provide the player participants, audio and graphic information, and the client 102 to fully participate in the online gaming experience for the game operated by the particular application server 112 . It provides a real game play environment with any other data needed. In this way, many tasks that must be performed to support system operation can be performed depending on which machine is most suitable for performing the task.

As described above, the authentication server 104 communicates with the database server 106 for authentication, application information, and the like. 2 illustrates a database server in detail, and shows that a database server may include multiple servers and connected database storage. For example, FIG. 2 illustrates an authentication data server 202 and a connected authentication database 204 , a transaction data server 206 and a connected transaction database 208 , and an application data server 210 and a connected application database 212 . It shows a database server 106 that contains. The operation and configuration of these components will be better understood with reference to the following description.

<u>system behavior</u>

3, 4, and 5 are flow diagrams illustrating the functionality of a system configured in accordance with the present invention to provide improved operation of an online multi-user application.

In a first operation, indicated by flowchart block 301, a user connects to a network domain name, such as a game portal or other Internet site, to access and log in to a multi-user application, such as an online game. In the next operation, the user is redirected to one of the authentication servers. This operation (indicated by block 302) may include operation through a load balancer or similar configuration for server workload management. In the next block 303, the user is assigned a session key by the authentication server. A session key remains active during a current online session by a user and is associated with a privilege level, providing a means for various system components (shown in Figure 1) to determine the level of access to be granted to the user. Then, at block 304, after the user supplies account login information to the authentication server, the authentication server sends an authentication request to the authentication data server (of the database server), as shown in block 305 . The account login includes the user's registered account number or other identifier from which the user's right to access can be determined. In the next operation (block 306), the authentication request is processed with appropriate load balancing and directed to a particular one of the authentication servers.

In a next block 307, the authentication data server communicates directly with the authentication database to determine whether the user's login is accepted. For example, this action may include checking the user's account history to ensure that all appropriate fees have been paid and the user continues to authenticate or entitle. To maintain a history of the user, this operation 307 includes sending a transaction record (login attempt) to a transaction data server for non-volatile storage. Also, this write operation may include a load balancing operation.

At a next block 308, the success or failure of the login attempt is reported to the authentication server. The login result is sent to the user and also sent to the transaction data server. At a next block 309, similar processing operations are repeated for the username login procedure. As shown in block 310, another similar login procedure occurs for the user's screen name in accordance with the application identification. If the screen name login is successful, the authentication server assigns the user to the lobby server and also prompts the universe administrator for a session privilege level, giving the user all appropriate access during the session. The authentication server knows the available lobby servers corresponding to the application ID provided by the user by requesting the appropriate application server from the universe manager. The universe manager keeps track of the available lobby servers through a "heartbeat" sent by the lobby server to the universe manager while the lobby server is running. This process is then represented by block 310 .

Next, at block 311, the user disconnects from the authentication server and establishes communication with the assigned lobby server. In block 312, the user queries the session key obtained from the authentication server in block 303 and also queries the application ID using the assigned lobby server. The lobby server uses the universe manager to query data as well as privilege levels. The user's privileges are upgraded when the query is successful.

In the next phase of system operation, at block 313 , the user successfully completes a login with the lobby server and is thus entitled to participate in system-wide functions. These functions may include, for example, chatting, group or community management, player-matching activities such as team or clan work, and result or competitive standing and ladder progression. Requests from users for information about available chat channels, available games, other users' locations, messaging features, etc. are sent from the lobby server to the universe manager. If the request for information involves non-volatile storage, the request is sent to the appropriate database server (FIG. 2).

One of the system-wide functions a user may want to participate in the next successful connection with the lobby server may involve using an application. In the context of an online gaming environment, an application is a game. Those skilled in the art will understand that other online multi-user applications may be included. As noted above, clients may participate in online games as part of a client-server configuration or peer-to-peer configuration, or as part of an integrated application server and client configuration. Figure 4 relates to a user operating in a client-server or peer-to-peer configuration, and Figure 5 relates to a user operating in an integrated application server configuration.

In FIG. 4 , the first action (which occurs when the user wants to join the game after completion of the last block in FIG. 3 ) is to send the user's application (game) request to the universe manager. In the process of Figure 4, the client is configured as a classic client-server configuration or a peer-to-peer configuration. The universe manager assigns the user to the appropriate game server for the requested game. The game server maintains the universe manager evaluation status through continuous and periodic heartbeat reporting in a form similar to the lobby server. In this way, the universe manager knows the state of the system and can manage and respond to requests from lobby servers and application servers. After the first processing operation shown in Figure 4 (block 414), the assigned application server assigns a server specific key to the user (block 415). Keys provide an extra measure of security to prevent unauthorized access. The authentication server requests the key from the universe manager or assigned application server, and sends the key through the universe manager to the user and to the lobby server.

Next at block 416, the user is contacted with the assigned application server, if provided with the server-specific key received from block 415. The user disconnects from the application server if the server-specific key does not match the record in the application server. In the case of a match, the user is allowed to maintain a connection with the application server. The user maintains a connection to the lobby server during use of the application, such as during a game playing session. At block 417, periodic user reports are sent from the application-engaging user to the user's lobby server. In addition, the application server hosting the application for all participants (such as a game hose) sends periodic reports on the status of the application to the application host. Since the lobby server and the application server do not communicate directly, the processing load on the lobby server is well managed.

At the end of the application session (block 418), the user disconnects from the application server and returns to normal activity including all available lobby functions via the lobby server. As mentioned, these functions may include chatting, group or community management, messaging, and the like. These functions are available to the user at any time the user is connected to the lobby server, including during application use (eg, during game play).

When a user performs a logout procedure, or when a user times out from an active connection due to inactivity, the user's session is cleaned from the universe manager's active record. This is shown in the next block 419. When the user wants to participate in another application, the user has to go through authentication processing including login processing again.

In addition to operating in a network configuration in which applications are served by a dedicated application server, the network may operate in a configuration in which multi-user applications are served by an aggregation server. The integration server refers to a user (client) machine configured with an integration server application that provides application functions to the user machine. A system implementing this method of operation is described in "Application Development Interfaces for Multi-User Applications Executable over a Communication Network ( Application Development Interface for Multi-User Applications Executable Over Communication Networks). The disclosure of this application is incorporated herein by reference. As described above, when a user wants to join a game, the system operation moves from the description of FIG. 3 to that of FIG. 4 (dedicated application server) or FIG. 5 (integrated server).

Referring to Figure 5, the first action under the aggregation server is for a user who wants to host an application (such as an online game) to initialize an integrated server application installed on the user's computer. The aggregation server application connects to a suitable domain name, such as a game portal website. Thereafter, the integration server executes authentication processing with the authentication server in processing similar to the initial login processing described in relation to FIG. 3 . These operations are represented by the first block 514 of FIG. 5 .

Upon successful authentication with the authentication server, the hosting user's integration server application generates a periodic server report to be sent to the proxy application server. As mentioned above, the proxy application server is contained within the application server cloud 112 of FIG. 1 . The proxy application server may include an application other than the integrated server application at the hosting user or may be integrated with the integrated server application, or the proxy application server may include a separate server that is another node in the FIG. 1 network and is the hosting user's computer. have. In some cases, the user's aggregation server application provides periodic and constant "heartbeat" reports to the proxy application server to verify the operation of the hosted application and provide status information to the proxy application server. The proxy application server communicates with the universe manager to provide the universe manager with application state information received from the hosting user machine. The universe manager includes these reports in data collection when similar to reports from dedicated application servers and any other integration servers. These reporting operations are represented by the second block 515 of FIG. 5 .

In the next action, block 516, the user notifies the assigned lobby server of his/her status as an active application server . These new running applications are made available over the network. After that, the lobby server registers these new applications with the universe manager, which adds application information suitable for data collection. These actions are performed by the universe manager in a manner similar to running in response to network applications and any other servers that become available.

After the new application is registered with the universe manager, the network node gets to know the application through each lobby server. Thus, the application becomes available to network users who can participate in the program environment established by the aggregation server. For example, if the application is a multi-user game, other network users can join the game in progress, as managed by the hosting user's aggregation server. The process of joining an ongoing game includes the same operations as described above with respect to blocks 414 , 415 , 416 , and 417 of FIG. 4 . These operations include communicating with the appropriate application server, receiving a server-specific key, providing the key to the server, authenticating, and providing a constant "heartbeat" report to the lobby server. These aggregation server operations are represented by "join" block 517 of FIG. 5 .

At the end of the application session (block 518), the participating user may disconnect from the aggregation server and return to normal activity including all available lobby functions via the lobby server. As noted above, these functions may include chatting, group or community management, messaging, and the like. As noted above, these functions are available any time the user is connected to the lobby server, including during application use (eg, during game play). In case the hosting user (integration server) wishes to exit hosting the application, the network system (Figure 1) provides the desired The same procedure can be implemented.

When the user performs a logout procedure, or when the user times out from the active state due to inactivity, the user's session is cleared from the universe manager's active record. This is indicated in the next block 519. When the user wants to participate in another application, the user has to go through the authentication process again, including the login process.

<u>ladder ranking </u>

An application program interface that is shared in common with all of the components shown in Figure 1 includes provision for a ladder ranking engine. A ladder ranking is a list of users organized and classified according to a predetermined variable or metric. Ladder ranking is most easily understood in the context of a gaming application, where predetermined variables refer to wins, losses, points scores, and the like. As the user improves performance, the user's ranking improves, which means that the user moves up the "ladder" of the ranked user. Accordingly, ladder ranking information can be used for various competitive purposes, such as contests and tournaments.

Ladder ranking information is collected through the ability of each multi-user application to periodically report application status to the corresponding application server. The state may include information such as the player's progress in the game. Then, the application server stores the information in the database of the system indexed according to the currently used application and the user's account information. This information is managed by a ladder engine that can run anywhere in the network, for example, the universe manager, and the data can be stored in the universe manager's data storage device or database server (FIG. 1).

Preferably, the system interface provides any registered user to request the ladder ranking provided through the ladder ranking engine. The request may come from the user through the application the user is currently participating in. This ensures that non-participants cannot erroneously obtain ladder ranking information. A ladder ranking request may be received by a lobby server or an application server from a user, and the request may be sent to a ladder ranking engine in the universe manager or any other network entity that manages the ladder ranking. When a ladder ranking list is requested, all user accounts for the specified application are stored based on the stored user performance data. Preferably, the application state information includes multiple statistics that may be simultaneously stored in a database. For example, a gaming application may track wins, losses, points scores, points allowed, and other important performance statistics. Each metric may be stored, generating a ladder ranking according to the metric selected by the user requesting the ladder ranking. The ladder ranking engine also provides for storing or retrieving ladder rankings in ascending or descending order. For example, ladder rankings may be provided in order from highest point to lowest point or from lowest point to highest point.

The various servers and databases in the system have no knowledge of the nature of the statistics. That is, the server cannot examine the underlying data to understand the difference between wins and losses or points and goals. Rather, various applications define the data to be collected for that application, and the server and database simply store the collected data in a database. Thus, each application defines its own data collection format supported by the database server.

The data may be contained in a 256-byte data field assigned to each user's account for each application the system interfaces with. For example, application code may implement a ladder ranking function by enumerating data parameters of sort order, start byte, and end byte. Upon receiving a ladder ranking message with these parameters, the system's server or database retrieves all data fields for all accounts associated with the calling application. The data in each data record between the start byte position and the end byte position is treated as an integer value. Then, a classification operation is performed on the retrieved data in ascending or descending order according to the value of the user-supplied sort order parameter. The sorted integers are then displayed to the user according to known headings for integer data. For example, certain applications store performance data in the following order: number of wins, number of losses, point score, and points allowed. When performance data is retrieved, the data can be analyzed to extract the requested data for appropriate display. Different applications may store different performance parameters in a different order known to the corresponding application server. In this way, the ladder ranking engine provides a powerful and generic cross-application ladder ranking system.

<u>clan engine</u>

Another feature of the system described herein is a clan engine that allows a designated user of any trusted application, referred to as a "leader", to designate and create a clan. After that, the leader sends invitations to other users joining the clan. The system waits for any invitation sent to a registered user who is not online at the time the invitation was sent, for delivery on the inviter's next login. A user receiving a clan invitation can respond positively or negatively and, if desired, become a member of the clan.

The system supports various clan features. Members of the clan can send private electronic messages to members of the clan. Clan messages can be stored on the system's servers until delivery, which occurs when each member completes the next login process. The system will allow the clan to elect new leaders and set up various organizational structures for the clan. An example of an organizational structure is a dictatorship in which one leader manages all decisions of a clan, or a democracy in which all members and leaders have equal voting rights in clan decisions. The leader initiating the clan may choose to utilize these or other configurations.

Various clan data including clan membership list, clan activity tracking, clan electronic messaging, etc. are all saved by the system's database server. The clan function is accessed via the program interface according to the invention in a manner similar to that described above for ladder ranking data. This allows many individual functions for each clan to be provided and assigned or deleted, making each clan's constituent roles and actions potentially exclusive. The program interface also allows clan functions to be used in a generic way for multiple applications. For example, in a game context, the same team or clan functionality may apply whether the application is a flight simulator, a car racing game, or an action-shooting game.

In addition, multiple applications can share the same clan and membership servers and databases at the same time without interfacing with each other. A user account is associated with one or more clans in a clan that extends through the same application or multiple applications, without any impact on user accounts or clan functions.

The clan engine according to the present invention manages clan data using server-side processing rather than relay offline, web-based clan management techniques or client-side coordination, which are not built into the actual application itself. Accordingly, any application developed for the program interface described herein may utilize the clan processing built into the interface specification, server, and database of the FIG. 1 system.

<u>network device structure</u>

The network computer apparatus (client and server) shown in the block diagram of FIG. 1 includes nodes of the computer network system 100 . FIG. 6 is a block diagram of a computer in the system 100 of FIG. 1, showing hardware components included in one of the computers that provide the functions of a server and a client. One of ordinary skill in the art will understand that the server and client shown in FIG. 1 may have the same computer architecture, or may have other architectures consistent with the capabilities and respective functions described herein.

6 shows an example computer 600 including any networked computer. Each computer 600 operates under the control of a central processing unit (CPU) 602 and associated integrated circuit chips, such as a "Pentium" microprocessor available from Intel Corporation of Santa, California, USA. A computer user may enter commands and data from a keyboard and computer mouse 604 , and may view input and computer output on a display 606 . Typically, the display is a video monitor or flat panel display. The computer 600 also includes a direct access storage device (DASD) 608, such as a hard disk drive. Typically, memory 610 includes volatile semiconductor random access memory (RAM). Preferably, each computer has a program product reader 612 that houses a program product storage 614 from which the program product reader can read data (and additionally write data). The program product reader may include, for example, a disk drive, and the program product storage device may include a removable storage medium such as a magnetic floppy disk, CD-R disk, CD-RW disk, or DVD disk.

Each computer 600 may communicate with other computers on a computer network 620 (such as the Internet or an intranet) via a network interface 618 that enables communication over the network 620 and the connection 622 between the computers. can Network interface 618 typically includes, for example, a network interface card (NIC) or modem that allows communication over various networks.

CPU 602 operates under the control of programming steps temporarily stored in memory 610 of computer 600 . When programming steps are executed, the computer performs its functions. Thus, the programming step implements the functionality of each client or server. The programming steps may be received from the DASD 608 via a program product storage drive 614 , or via a network connection 622 . Program product storage drive 612 may receive program product 614 , read programming steps written therein, and transfer programming steps to memory 610 for execution by CPU 602 . As noted above, the program product storage device has computer-readable instructions recorded thereon and may include any one of multiple removable media including magnetic floppy disks and CD-ROM storage disks. Other suitable program product storage devices may include magnetic tape and semiconductor memory chips. In this way, the processing steps necessary for operation according to the invention can be incorporated into the program product.

Alternatively, the program steps may be received in the working memory 610 via the network 620 . In the network method, the computer program steps into the memory 610 via the network interface 618 after network communication has been established over the network connection 622 by well-known methods understood by those skilled in the art without further explanation. Receive data containing Thereafter, the program steps are executed by the CPU 602 to include computer processing.

All network computers in the network system 100 shown in FIG. 1 may have a structure similar to that shown in FIG. 6 , so that the detailed description of the computer 600 in FIG. 6 applies to all computers in the system 100 . you will understand that you can It will be understood that any networked computer may have another structure as long as the computer can communicate with the other computers shown in FIG. 4 and support the functions described herein.

For example, referring to FIG. 7 , the client computer 102 may include a computer entertainment system, such as a video game console system 700 . 7 is a block diagram of an exemplary hardware configuration of a video game console system 700 .

The video game console system 700 includes a central processing unit (CPU) 701 coupled with a main memory 705 . The CPU 701 operates under the control of programming steps stored in the OS-ROM 760 or transferred from the game program storage medium to the main memory 705 . The CPU 701 is configured to process information and execute instructions according to programming steps.

The CPU 701 is communicatively coupled to an input/output processor (IOP: 720) via a dedicated bus 725 . IOP 720 couples CPU 701 to OS ROM 760, which includes non-volatile memory that stores program instructions, such as an operating system. Preferably, the command is sent to the CPU via the IOP 720 at the start of the main unit 700 .

The CPU 701 is communicatively coupled to a graphics processing unit (GPU: 710 ) via a dedicated bus 715 . The GPU 710 is a drawing processor configured to perform drawing processing and formulate an image according to an instruction received from the CPU 701 . For example, the GPU 710 may represent a graphic image based on a display list received from the CPU 701 and generated by the CPU. The GPU may include a buffer for storing graphics data. The GPU 710 outputs an image to the AV output device 790 connected to the console system 700 .

The IOP 720 controls data exchange between the CPU 700 and a plurality of peripheral components according to instructions stored in the IOP memory 730 . Peripheral components may include one or more input controllers 722 , memory card 740 , USB 745 , and IEEE 1394 serial bus 750 . Bus 755 is also communicatively coupled to IOP 720 . The bus 755 is linked to several additional components including an OS ROM 760 , a sound processor unit (SPU: 765 ), an optical disk unit 775 , and a hard disk drive (HDD: 780 ).

The SPU 765 is configured to generate sounds such as music, sound effects, and voices according to instructions received from the CPU 701 and the IOP 720 . SPU 765 may include a sound buffer in which waveform data is stored. The SPU 765 generates a sound signal and sends the signal to the speaker.

The disk control unit 775 may include, for example, an optical disk drive that receives a removable storage medium such as a magnetic floppy disk, an optical CD-ROM disk, a CD-R disk, a CD-RW disk, a DVD disk, and the like. have.

The memory card 740 may include a storage medium in which the CPU 701 can record and store data. Preferably, the memory card 740 can be inserted into and removed from the IOP 720 . A user may use the memory card 740 to store or save data. Also, preferably, the video game system 700 may be provided with one or more hard disk drives (HDD: 780) on which data may be recorded and stored.

Preferably, a data I/O interface, such as an IEEE 1394 serial bus 750 or a universal serial bus (USB: 745) interface, allows data to be transferred into and out of the video game system 700, such as the network shown in FIG. communicatively coupled to an IOP 720 to enable transmission.

In the above, preferred embodiments of the present invention have been described in order to convey the knowledge of the present invention. However, there are many configurations for systems and applications not specifically described herein in which the present invention may be used. Accordingly, the present invention is not limited to the specific embodiments described herein, and the present invention has broad applicability with respect to multi-user applications. Accordingly, all modifications, variations, or equivalent arrangements and implementations falling within the scope of the appended claims are considered to be within the scope of the present invention.