Multi-user application program interface

Multi-user application program interface

Technical field

The present invention generally relates to computer networks, and particularly relates to applications executed by multiple users on the computer network.

Background technique

Computer networks such as local area networks and the Internet are increasingly used as hubs for various transactions and interactions between parties. From online banking where bank customers can initiate financial transactions on a computer network to online games where game players can participate in real-time games on the Internet, service providers increasingly support a variety of services on computer networks. Various computer network structures currently exist to facilitate transactions and interactions that occur.

Many online applications involve multi-user applications, which are computer programs that execute on a computer system and allow multiple geographically separated participants to interact with the computer programs and other participating users in the application environment. For example, games are popular multi-user applications that are becoming more and more popular. Aircraft simulation games can allow multiple participants to fly their respective virtual aircraft in an airspace, and can allow participants to interact with other participants in their respective aircraft in the same airspace. Therefore, online gaming applications provide a single application environment or universe manipulated by multiple participants.

In order to support multi-user applications such as online games with geographically dispersed application users such as game participants, and to support real-time interaction between users in the application environment, it is necessary to share information about each participant in the environment. For example, in aircraft simulation applications, it is necessary to share information about each participant's aircraft, including aircraft size, speed, three-dimensional space height, appearance details, virtual environment details (such as buildings and terrain), etc. This information allows each participant's computer to correctly remember the game development and determine the actions performed by each participant. This allows each participant to obtain a virtual image of the correct representation on his viewing display.

The amount of information that must be shared among all participants can be staggering and can cause bandwidth issues. The amount of information that must be shared between participants is so great that it limits the development of online games and other online multi-user applications. A technology for distributed management of online applications is in the U.S. patent named "Distributed System for Communication Networks in Multi-User Applications" by R. Waters et al. It is described in No.5,841,980.

The '980 patent describes a system structure in which the functions of a huge server are distributed among multiple servers, where each server serves multiple local users. Therefore, although a single server used to be used as the source of all application information such as game status, the '980 patent describes a situation where the game server functions are distributed among multiple computers. Users (online participants) are free to log in to their most convenient server. In this way, there is no single "bottleneck" that may limit game play and reduces the bandwidth requirements of the online gaming community. Even when the overall bandwidth requirement is reduced, the amount of pure data that must be transmitted between users to support the online environment may lead to a local pocket of tight bandwidth capacity.

Other multi-user applications provide somewhat cumbersome user interfaces and may be inefficient for the operation of the application server. For example, some online gaming portals provide links to gaming websites of interest. The server that provides the game portal website only provides links to the game webpage or game website. Therefore, the game portal will redirect the user to the appropriate game server or host to obtain information about the current game. This imposes an additional workload on the game server.

Unfortunately, current multi-user applications are not configured for maximum work efficiency and cannot support a large number of application users to create opportunities for survival for online games. Therefore, there is a need for an improved and more efficient online multi-user application environment. The present invention satisfies this need.

Summary of the invention

The present invention provides a multi-user online network application structure in which application-level information is maintained on a portal or lobby server instead of on each application server or host machine. Therefore, users can understand and select desired applications such as aircraft online games through communication with the front office server. After proper authorization processing, users can contact relevant application servers such as game consoles to start their participation. In this way, the function of the game server is divided between the front office server and the application server. Therefore, the front office server can reduce the bandwidth requirements and other work requirements of the application server. Applications may include, for example, multi-user interactive gaming applications. This will improve work efficiency. In another aspect of the invention, real-time cross-application communication is facilitated through the front office server concept. In this way, users participating in one application can communicate with users participating in different applications. Therefore, the first user can log in to the front office server and participate in the aircraft online game environment through an application server. At the same time, the second user can log in to the same front office server, but can participate in different applications such as financial packages or different applications. online game. If desired, the first user and the second user can communicate with each other, or they can choose to participate in separate environments that are isolated from each other in communication.

In another aspect of the present invention, multiple front office servers and application servers are provided, and these servers are configured to obtain complete information about the online environment. In this way, many tasks that must be performed to support the operation of the system can be performed according to the machine most suitable for performing the task. In another aspect of the present invention, the multi-user application environment provides a common data model for maintaining user information. For example, a stepped ranking system can be established in the context of an online game where user achievements are recorded and shared between users and between different applications (ie games).

Other characteristics and advantages of the present invention will become clear through the following description of a preferred embodiment as an example to illustrate the principle of the present invention.

Description of the drawings

Fig. 1 is an exemplary diagram of a computer network system on which a multi-user application configured according to the present invention runs; Fig. 2 is a detailed block diagram of the system shown in Fig. 1; Fig. 3 is a flowchart of operations performed by the system of Fig. 1 Figure 4 is a flowchart showing other system operations in addition to those shown in Figure 3; Figure 5 is a flowchart showing other system operations in addition to those shown in Figure 3; Figure 6 is the network shown in Figure 1 A block diagram of the computer in, which shows various hardware components; Fig. 7 is a block diagram of a computer entertainment system in the network shown in Fig. 1, which shows various hardware components.

detailed description

System configuration Fig. 1 is a block diagram of a computer network system 100, which is composed of one or more network devices, where the network devices include one or more client computers 102, and the client computers 102 communicate with an authorization server 104 to access the system. Including participation in multi-user online applications. As described further below, the client computer may include a computer 102(a) configured in a classic client-server structure or a peer-to-peer structure, or may include an integrated server that combines other computer functions with client computer functions. The configuration of the computer 102(b). It should be understood that the reference to the client computer 102 is a uniform reference to any structure, or a reference to a structure subgroup 102(a), 102(b) or other is a reference to a specified specific subgroup. The authentication server determines whether to grant authorization by querying the database server 106 for user records. The authentication server also communicates with a universe manager computer 108, which maintains records about online users and helps manage the online application environment or the world.

After the authentication server 104 authorizes the user 102 to continue, the user can participate in the online multi-user application by first communicating with the front office server 110 to obtain application-level information. Application-level information may include information about the application and its participating users. For example, in the context of an online game application, the front office server 110 may provide information about the game and about currently participating users. After selecting the online multi-user application, the user is redirected to the appropriate application server 112, from which the user receives information sufficient to allow the user to join the online environment of the multi-user application. Therefore, the application-level information is maintained on the front office server 110 rather than on individual application servers or host machines 112. Therefore, users can understand and select required applications, such as aircraft online games, through communication with the front office server, thereby allowing the application server to freely host their specific applications.

In FIG. 1, the front office server 110 and the application server 112 are shown in a cloud shape to indicate that the functions of these servers may be distributed among multiple computers that provide the functions in common or may be provided by one or more independent network computers. 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 further below, the application server may include a combination of the integrated server 102(b) and the application server 112 that acts as an agent to provide an interface to the unified manager 108. Similarly, the functions of the front office server 110 may be provided by a dedicated front office server that directly communicates with the client 102, or the functions of the front office server may be provided by other computers that communicate with the client, such as an authentication server or a unified manager 108.

In this way, the function of the game server is divided between the front office server and the application server. Therefore, the front office server can reduce the bandwidth requirements and other work requirements of the application server. Applications may include, for example, multi-user interactive gaming applications. This will improve work efficiency.

According to the present invention, real-time cross-user communication and cross-application communication are facilitated through the front office server concept. Users participating in one application can communicate with users participating in different applications. In this way, the first user can log in to the front office server and participate in the aircraft online game environment through the application server, while the second user can log in to the same front office server, but can participate in different applications in different programming environments such as financial packages or different online game. If they wish, the first user and the second user can communicate with each other, or they can choose to participate in separate environments that are isolated from each other in communication.

The unified manager 108 plays a role of overall management, maintains information about users (clients) 102 registered with the system and logged in, and communicates with users through the authorization server 104, the front office server 110, and the application server 112. The front office server 110 provides users with application-level information, thereby acting as an application portal and application information source for the client 102. For example, unlike a typical game portal server that only provides a link to a game website, the lobby server provides information about the current game and may provide game-level information such as information about players participating in the game online. The application server 112 provides an actual application environment. For example, in the case where the online application is a game, the application server provides an actual game playing environment for the game managed by the specific application server 112, including player participants, audio and graphic information, and the client 102 fully participates in the online game experience. Other data. In this way, many tasks that must be performed to support the operation of the system can be performed according to the machine 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. FIG. 2 shows detailed information of the database server, and shows that the database server may include multiple servers and related database storage. For example, FIG. 2 shows a database server 106 including an authentication data server 202 and a related authentication database 204, a transaction data server 206 and a related transaction database 208, and an application data server 210 and a related application database 212. The operation and structure of these components will be better understood with reference to the following description.

System Operation Figures 3, 4, and 5 are flowcharts showing the functions of a system constructed in accordance with the present invention to provide improved online multi-user application operation.

In the first operation represented by block 301 of the flowchart, the user connects to a network domain name such as a game portal or other Internet website in an attempt to access and log in 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 (represented by block 303) may include operations through a load balancer or similar structure for server workload management. In the next block 303, the authentication server assigns a session key to the user. The session key will remain valid during the user's current online session and will be associated with a privilege level, thereby providing a means for each system component (shown in Figure 1) to determine the level of access to be given to the user. Then, in block 304, the user provides account login information to the authentication server, and then as shown in block 305, the authentication server forwards the authentication request to the authentication data server (of the database server). Account login involves the user's registered account or other identifier through which the user's access rights can be determined. In the next operation (block 306), the authentication request is processed with appropriate load balancing and directed to a specific authentication server.

In the next block 307, the authentication data server directly communicates with the authentication database to determine whether user login should be accepted. This operation may involve, for example, checking the user's account history to ensure that all appropriate fees have been paid, and that the user has all authorizations or qualifications to proceed. In order to maintain user history, this operation 307 also involves sending transaction records (login attempts) to the transaction data server for non-volatile storage. The recording operation may also involve a load balancing operation.

In the next block 308, the success or failure of the login attempt is reported to the authentication server. The registration result is forwarded back to the user and the transaction data server. In the next block 309, similar processing operations are repeated for the user name login process. As shown in block 310, for the user's screen name, together with the application identifier, another similar login operation is performed. If the screen name login is successful, the authentication server will assign the user to a front office server, and will also promote the session authority level to the unified manager, so that the user will be granted all appropriate access during the session. It should be noted that by requesting an appropriate application server from the unified manager, the authentication server knows the available front office server corresponding to the application ID provided by the user. The unified manager learns about the available front office servers through the "heartbeat" report that the front office server continuously sends to the unified manager when it is running. This process is represented by the next block 310.

Next, in block 311, the user disconnects from the authentication server and establishes communication with the assigned lobby server. In block 312, the user verifies the session key obtained from the authentication server in block 303 to the assigned lobby server, and also verifies the application ID. The front office server verifies the data and the authority level to the unified manager. User permissions are upgraded upon successful authentication.

In the next stage of system operation, at block 313, the user successfully completes the login to the front hall server and is therefore entitled to participate in system-wide functions. These functions may include, for example, chat, group or community management, player cooperation activities such as team or clan tasks, and achievements or competitive rankings and ladder progress. Any user requests for information about available chat channels, available games, other user locations, messaging capabilities, etc. are forwarded from the front office server to the unified manager. If the information request involves non-volatile storage, forward the request to the appropriate database server (Figure 2).

One of the system-wide functions that the user may want to participate in after a successful connection with the front office server may include the use of an application. In the context of an online gaming environment, the application is a game. Those skilled in the art should understand that other online multi-user applications may be involved. As mentioned above, the client can participate in online games as part of a client-server structure or a peer-to-peer structure or a part of an integrated application server and client structure. Figure 4 relates to users working in a client-server or peer-to-peer structure, and Figure 5 relates to users working in a comprehensive application server structure.

In FIG. 4, the first operation (occurring when the user wants to join the game after completing the last box in FIG. 3) is that the front office server forwards the user's application (game) request to the unified manager. In the process of Figure 4, the client is configured into a traditional client-server structure or a peer-to-peer structure. The unified manager assigns users to game servers suitable for the requested game. The game server informs the unified manager of their status through continuous periodic heartbeat reports in a manner similar to the front office server. In this way, the unified manager knows the system status, and can manage and respond to requests from the front office server and the application server. After the first processing operation shown in FIG. 4 (block 414), the distributed application server distributes a server specific key to the user (block 415). This key provides additional security measures to prevent unauthorized access. The authentication server asks the unified manager or the assigned application server for the key, and forwards the key to the user and the front office server through the unified manager.

In the next block 416, the user connects to the assigned application server and provides it with the server-related key received from block 415. If the server-related key does not match the record on the application server, the user will be disconnected from the application server. If it matches, the user is allowed to stay connected to the application server. It should be noted that the user remains connected to the front office server during the entire period of using the application, such as during a game playing session. At block 417, the periodic user report is sent from the application participating user back to the user's lobby server. In addition, an application server (such as a game host) hosting an application for all participants sends periodic reports on the status of the application to the application host. The front office server and the application server do not communicate directly, thereby better managing the processing load on the front office server.

At the end of the application session (block 418), the user disconnects from the application server and returns to normal activities, including all available lobby functions through the lobby server. As mentioned above, these functions can include chat, group or community management, message transmission, and so on. It should be noted that these functions are always available to the user when the user connects to the front office server, including during application use (for example, during game play).

If the user performs a logout process, or if the user times out from the active connection due to inactivity, the user session is cleared from the activity record of the unified manager. This is indicated in the next block 419. If the user wishes to participate in another application, the user must pass the authentication process again, including the login process.

Unlike working in a network structure where applications are provided by a dedicated application server, the network can also work in a structure where multi-user applications are provided by a comprehensive server. The integrated server refers to the user (client) machine that adopts the integrated server application configuration that provides the application server function to the user's machine. The system that implements this method of operation has the applicants C. Guy, G. Van Datta and J. Fernandes, and the name is "Application Development Interface for Multi-User Applications Executable Over Communication Networks (for multi-user applications that can be executed on communication networks). Application Development Interface)", the co-pending U.S. Patent Application No. 09/704,514 with an application date of November 1, 2000 is described in. The full text of this application is hereby incorporated by reference. As described above, when the user wants to join the game, the system operation moves from the description of FIG. 3 to the description of FIG. 4 (dedicated application server) or FIG. 5 (integrated server).

Referring now to FIG. 5, the first operation under the integrated server structure is that a user who wants to host an application (such as an online game) initializes an integrated server application that has been installed on the user's computer. The integrated server application connects with appropriate domain names such as game portals. Then, the integrated server performs an authentication process to the authentication server in a process similar to the initial login process described in conjunction with FIG. 3. These operations are represented by the first block 514 in FIG. 5.

When the authentication server is successfully authenticated, the integrated server application of the hosting user causes periodic server reports to be transmitted to the proxy application server. As described above, the proxy application server is included in the authentication server cloud 112 in FIG. 1. The proxy application server may include applications in addition to or integrated with the integrated server application of the application resident user, or the proxy application server may include a separate server that serves as another node of the network of FIG. 1 and communicates with the computer of the application resident user . In any case, the user's integrated server application provides periodic and regular "heartbeat" reports to the proxy application server to confirm the operation of the resident application and provide status information to the proxy application server. The proxy application server communicates with the unified manager, so as to provide the unified manager with application status information received from the user's machine where the application resides. Just like similar reports from dedicated application servers and any other integrated server, the unified manager includes these reports in its data collection. These reporting operations are represented by the second block 515 in FIG. 5.

In the next operation, block 516, the user notifies the assigned lobby server of its status as an active application server. The newly executed application will now be available on the network. Then, the front office server registers the new application with the unified manager, and the unified manager adds appropriate application information to its data collection. The unified manager performs this operation in a manner similar to that performed in response to any other server becoming available through a web application.

After registering the new application with the unified manager, the network node will know the application through the respective front office server. Therefore, the application becomes available to network users, where network users can join the program environment established by the integrated server. For example, if the application is a multi-user game, other network users can join the current game managed by the integrated server of the user where the application resides. The process of joining the current game involves the same operations described above in conjunction with blocks 414, 415, 416, and 417 of FIG. 4. These operations involve communicating with the appropriate application server, receiving the server-related key, providing the key to the server, obtaining authorization, and providing a regular "heartbeat" report to the front hall server. These integrated server operations are represented by the "join" box 517 in FIG. 5.

At the end of the application session (block 518), the participating user can disconnect from the integrated server and return to normal activities, including all available lobby functions through the lobby server. As mentioned above, these functions can include chat, group or community management, message transmission, and so on. It should be noted that these functions are always available to the user when the user connects to the front office server, including during application use (for example, during game play). If the application resident user (integrated server) wants to exit the resident application, the network system (Figure 1) can ensure the orderly closing of the application or the orderly transfer to a different integrated server that takes over the application environment of the resident application. process.

If the user performs the logout process, or if the user times out from the active connection due to inactivity, the user session is cleared from the activity record of the unified manager. This is indicated in the next block 519. If the user wishes to participate in another application, the user must pass the authentication process again, including the login process.

The tiered ranking is common to all the components shown in Figure 1 and the shared application program interface also includes support for a tiered ranking engine. Tiered ranking is a list of users organized or ranked according to predetermined variables or metrics. Ladder ranking is the easiest to understand in the context of game applications, where the predetermined variables may refer to the number of wins, the number of losses, the number of points earned, and so on. When a user improves his or her performance, the user's ranking will increase, which means that the user will move up the "ladder" of ranking users. Therefore, the stepped ranking information can be used for various competitive purposes, such as competitions and competitions. The stepped ranking information is collected by functions in each multi-user application that periodically report the application status to the corresponding application server. The status may include information such as the player's game progress. Then, the application server stores this information in the system database indexed according to the user account and the currently used application. This information is managed by a ladder engine that can run anywhere on the network, such as on the unified manager, and the data can be stored in the data storage or database server of the unified manager (Figure 1).

The system interface preferably supports any registered user requesting a stepped ranking, and the stepped ranking will be provided through a stepped ranking engine. The request may come from the user via the application in which the user is currently participating. This ensures that non-participants cannot fraudulently obtain stepped ranking information. The stepped ranking request can be received by the front office server or the application server from the user, and the request can be forwarded to the stepped ranking engine on the unified manager or any other network entity that manages the stepped ranking. When a stepped ranking list is requested, all user accounts of the specified application are sorted according to the stored user performance data. The application status information preferably includes multiple statistical data that can be stored in the database at the same time. For example, the game application can record the number of wins, the number of losses, the number of points earned, the number of points allowed (points allowed), and other performance statistics of interest. Each metric can be sorted to generate a tiered ranking based on the metric selected by the user requesting the tiered ranking. Moreover, the stepped ranking engine provides sorting and retrieval of the stepped ranking in ascending or descending order. For example, a stepped ranking may be provided in the order from the largest number of points to the smallest number of points or from the smallest number of points to the largest number of points.

The various servers and databases of the system do not know the nature of the statistical data. That is, the server does not analyze the underlying data to understand the difference between the number of wins and the number of losses, or the number of points and the goal. Instead, each application defines the data set to be collected for that application, and the server and database simply store the collected data in the database. Therefore, each application will define its own data collection format, which will be supported by the database server.

The data can be included in a 256-byte data field, which is assigned to each user's account for each application connected to the system through the interface. For example, the application code can perform a stepped ranking function by specifying the sort order, start byte, and end byte data parameters. When a stepwise ranking message with these parameters is received, the server or database of the system will retrieve all data fields of all accounts associated with the calling application. The data in each data record between the start byte position and the end byte position will be treated as an integer value. Then, the retrieval data will be sorted in ascending or descending order depending on the sort order parameter value provided by the user. Then, the sorted integer value can be displayed to the user according to the known heading of the integer data. For example, a specific application may store performance data in the order of the number of wins, the number of losses, the number of points earned, and the number of allowable points. When retrieving performance data, the data can be parsed to extract the requested data for proper display. Other applications can store different performance parameters in different orders, which are known to the corresponding application server. In this way, the stepped ranking engine provides a powerful general cross-application stepped ranking system.

The tribe engine Another feature of the system described here is the tribe engine, which allows designated users of any trusted application to name and create a tribe. Then, the leader can send invitations to other users to join the tribe. The system will put any invitations sent to registered users who were not online when the invitation was sent into the queue for delivery when the invitee logs in next time. The user who received the clan invitation can reply in affirmative or negative, and can become a member of the clan if necessary.

The system supports various tribal characteristics. Tribe members can send private electronic messages to tribe members. Clan messages can be stored on the system's server until delivery occurs when each member completes the next login process. The system allows tribes to elect new leaders and set up various organizational structures for their tribes. Examples of organizational structures include dictatorships, in which a leader is responsible for all decisions of the tribe, or democracy, in which all members and leaders have the same voting rights in tribal decisions. The leader of the initiating tribe can choose which of these or other configurations will be used.

All tribal data, including all tribal member lists, tribal activity tracking, tribal electronic messages, etc., are saved by the system's database server. The tribe function is accessed through the program interface of the present invention in a manner similar to that described above for the stepped ranking data. This allows many discrete functions to be provided and designated or deleted for each tribe, thereby making the composition rules and work of each tribe potentially unique. Moreover, the program interface allows the tribal function to be used in a general manner for multiple applications. For example, in the context of a game, the same team or clan function can be applied regardless of whether the application is a flight simulator, a racing game, or an action shooting game.

In addition, multiple applications can share the same tribe and all member servers and databases without interfering with each other. The user account can be associated with multiple tribes in the same application or multiple tribes spanning multiple applications without affecting the user account or tribal functions.

The tribe engine of the present invention uses server-side processing instead of offline, Web-based tribe management technology or client arbitration to manage tribe data, without building anything into the actual application itself. Therefore, any application developed for the program interface described here can utilize the tribal processing in the interface specification, server and database built into the system of FIG. 1.

Network device structure The network computer devices (client and server) shown in the block diagram of FIG. 1 constitute each node of the computer network system 100. FIG. 6 is a block diagram of a computer in the system 100 of FIG. 1, in which various hardware components included in one of the computers that provide the functions of a server and a client are shown. Those skilled in the art should understand that both the server and the client shown in FIG. 1 may have similar computer structures, or may have alternative structures consistent with the capabilities and corresponding functions described herein.

Fig. 6 shows an exemplary computer 600, which may include any network computer, for example. Each computer 600 operates under the control of a central processing unit (CPU) 602 such as a "Pentium" microprocessor and related integrated circuit chips produced by Intel Corporation, Santa Clara, California, the United States. A computer user can input commands and data from the keyboard and computer mouse 604, and can observe the input and computer output on the display 606. The display is typically 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. The memory 610 typically includes a volatile semiconductor random access memory (RAM). Each computer preferably includes a program product reader 612 that receives a program product storage device 614, from which the program product reader can read data (and it can optionally write data to it). 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, a CD-R disk, a CD-RW disk, or a DVD disk.

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

The CPU 602 operates under the control of programming steps temporarily stored in the memory 610 of the computer 600. When the programming steps are executed, the computer performs its functions. Therefore, the programming steps implement the functions of each client or server. The programming steps may be received from the DASD 608 through the program product storage device 614 or through the network connection 622. The program product storage drive 612 can accommodate the program product 614, read the programming steps recorded thereon, and transfer the programming steps to the memory 610 to be executed by the CPU 602. As described above, the program product storage device may include any of a variety of removable media on which computer-readable instructions are recorded, including magnetic floppy disks and CD-ROM storage disks. Other suitable program product storage devices may include magnetic tapes and semiconductor memory chips. In this way, the processing steps required for the operation of the present invention can be implemented on the program product.

Optionally, the program steps can be received into the working memory 610 on the network 620. In the network method, after the network communication is established on the network connection 622 by a well-known method that should be understood by those skilled in the art and will not be described further, the computer receives the data including program steps into the memory 610 through the network interface 618. Then, the program steps are executed by the CPU 602, thereby including computer processes.

It should be understood that all network computers of the network system 100 shown in FIG. 1 may have a structure similar to that shown in FIG. 6, so it should be understood that the details described with reference to the computer 600 of FIG. 6 are applicable to all computers of the system 100. It should be understood that any network computer can have other alternative structures, as long as the computer can communicate with other computers shown in FIG. 4 and can 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. FIG. 7 is a block diagram of an exemplary hardware structure of the video game console system 700.

The video game console system 700 includes a central processing unit (CPU) 701 associated with a main memory 705. The CPU 701 operates under the control of programming steps stored in the OS-ROM 760 or transferred from a 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 through a dedicated bus 725. The IOP 720 couples the CPU 701 to the OS ROM 760, where the OS ROM 760 is constituted by a non-volatile memory storing program instructions such as an operating system. These instructions are preferably transmitted to the CPU through the IOP 720 when the main unit 700 is started.

The CPU 701 is communicatively coupled to a graphics processing unit (GPU) 710 through a dedicated bus 715. The GPU 710 is a graphics processor configured to perform graphics processing and formulate images in accordance with instructions received from the CPU 701. For example, the GPU 710 may express a graphic image according to a display list generated by and received from the CPU 701. The GPU may include a buffer for storing graphics data. The GPU 710 outputs the 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. The peripheral components may include one or more input controllers 722, a memory card 740, a USB 745, and an IEEE 1394 serial bus 750. In addition, the bus 755 is communicatively coupled to the IOP 720. The bus 755 is linked to several additional components, including an OS ROM 760, a sound processor unit (SPU) 765, an optical disc control 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 commands received from the CPU 701 and IOP 720. The SPU 765 may include a sound buffer in which waveform data is stored. The SPU 765 generates a sound signal and transmits the signal to the speaker.

The disk control unit 775 is configured to control a program reader, and the program reader may include, for example, an optical disk drive that receives removable storage media such as magnetic floppy disks, CD-ROM disks, CD-R disks, CD-RW disks, DVD disks, and the like.

The memory card 740 may include a storage medium to which the CPU 701 can write and store data. Preferably, the memory card 740 can be inserted into and removed from the IOP 720. The user can use the memory card 740 to store or save data. In addition, the video game system 700 is preferably equipped with at least one hard disk drive (HDD) 780 to which data can be written and stored.

A data I/O interface such as an IEEE 1394 serial bus 750 or a universal serial bus (USB) 745 interface is preferably communicatively coupled to the IOP 720, thereby allowing data to be transferred to and from the video game system 700 To, for example, the network shown in Figure 1.

The present invention is described above in accordance with the preferred embodiment, so that the understanding of the present invention can be conveyed. However, there are many structures of systems and applications to which the present invention is not specifically described here. Therefore, the present invention should not be seen as limited to the specific embodiments described herein, but it should be understood that the present invention has broad applicability for general multi-user applications. Therefore, all modifications, variations or equivalent solutions and implementations within the scope of the appended claims should be considered to fall within the scope of the present invention.