U.S. Pat. No. 7,711,847

DETAILED DESCRIPTION

System Construction

FIG. 1is a block diagram of a computer network system100comprised of one or more network devices including one or more client computers102who communicate with an authorization server104to gain access to the system, including participation with multi-user online applications. As described further below, the client computers can comprise computers102(a) configured in a classic client-server configuration, or in a peer-to-peer configuration, or can comprise computers102(b) configured in an integrated server configuration that combine the functionality of other computers with the client computer functions. References to client computers102will be understood to be a collective reference to either configuration, or references to one configuration subgroup102(a),102(b) or the other will be to the specific subgroup specified. An authentication server determines whether authorization is warranted by consulting a database server106for user records. The authentication server also communicates with a universe manager computer108that maintains records about online users and helps manage the online application environment, or universe.

After an authentication server104authorizes a user102to continue, the user can participate in an online multi-user application by first communicating with lobby servers110to obtain application-level information. The application-level information can include information about an application and its participating users. In the context of an online game application, for example, the lobby server110can provide information about the game and about currently participating users. After selection of an online multi-user application, the user is redirected to an appropriate application server112, from which the user receives information sufficient to permit the user to join the online environment of the multi-user application. Thus, application level information is maintained at a lobby server110, rather than at each individual application server or host machine112. Users can therefore learn about and select a desired application, such as an aircraft online game, through communication with the lobby server, leaving the application servers free to host their particular applications.

InFIG. 1, the lobby servers108and application servers112are depicted as cloud shapes to indicate that the functionality of these servers can be distributed across multiple computers who collectively provide the functionality or can be provided by one or more independent network computers. For example, the application servers112can comprise dedicated application server computers114that function as a distributed memory engine (DME). As an alternative, as described further below, the application servers can comprise a combination of integrated servers102(b) and application servers112acting in a proxy capacity to provide an interface to the universe manager108. Similarly, the function of the lobby servers110can be provided by dedicated lobby servers that communicate directly with the clients102, or the lobby server functions can be provided by other computers that communicate with the clients, such as the authentication server or universe manager108.

Thus, the functionality of the game server is split between the lobby server and the application server. The lobby server can therefore reduce the bandwidth requirements and other operating demands on the application server. The application can comprise, for example, a multi-user interactive gaming application. This improves efficiency of operation.

In accordance with the invention, cross-user communications as well as cross-application communications in real-time are facilitated through the lobby server concept. A user who is participating with one application can communicate with a user who is participating with a different application. Thus, a first user can be logged in to lobby server and can be participating in an aircraft online game environment through an application server, while a second user can be logged in to the same lobby server, but can be participating with a different application in a different programming environment, such as a financial package or a different online game. The first user and the second user can communicate with each other, if they wish, or they can choose to participate in their respective environments, isolated from each other in terms of communications.

The universe manager108acts in an overall supervisory role, maintaining information about the users (clients)102who are registered with the system and logged on, communicating with the users via the authorization servers104, lobby servers110, and application servers112. The lobby servers110provide application level information to the users, thereby acting as an application portal and source of application information to the clients102. For example, unlike typical game portal servers that merely provide links to game sites, the lobby servers provide information about games in progress and can provide game-level information, such as information about the players who are actively participating in a game. The application servers112provide the actual application environment. For example, in the situation where the online application is a game, the application servers provide the actual game play environment comprising player participants, audio and graphics information, and other data necessary for a client102to fully participate in the online gaming experience for the game administered by the particular application server112. In this way, many tasks that must be performed to support system operation can be performed according to the most appropriate machine to perform the task.

As noted above, the authentication servers104communicate with database servers106for authentication, application information, and the like.FIG. 2illustrates details of the database servers and shows that the database servers can comprise multiple servers and associated database storage. For example,FIG. 2shows a database server106that includes an authentication data server202and an associated authentication database204, a transaction data server206and associated transaction database208, and an application data server210and associated application database212. The operation and configuration of these components will be better understood with reference to the following description.

System Operation

FIGS. 3,4, and5are flow diagrams that illustrate the functioning of the system constructed in accordance with the invention to provide improved operation of online multi-user applications.

In the first operation, represented by the flow diagram block301, a user connects to a network domain name, such as a game portal or other Internet site to attempt access and login 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 (represented by block302) can include operation through a load balancer or similar configuration for server workload management. At the next block303, the user is assigned a session key by an authentication server. The session key will remain active during the current online session by the user and will be associated with a privilege level, thereby providing a means for the various system components (illustrated inFIG. 1) to determine the level of access to be granted to the user. The user then supplies account login information to the authentication server, at block304, and then the authentication server forwards an authentication request to the authentication data server (of the database servers), as indicated at the block305. The account login involves a user's registered account number or other identifier against which a user's right to access can be determined. At the next operation (block306), the authentication request is processed with appropriate load balancing and is directed to a particular one of the authentication servers.

At the next block307, the authentication data server communicates directly with the authentication database to determine whether the user's login should be accepted. This operation can involve, for example, checking the user's account history to ensure all appropriate fees have been paid and to ensure the user has all authorizations or qualifications to proceed. To maintain the user's history, this operation307also involves sending the transaction record (login attempt) to the transaction data server for non-volatile storage. This recording operation also can involve a load balancing operation.

The success or failure of the login attempt is reported back to the authentication server, at the next block308. The login result is forwarded back to the user and also to the transaction data server. At the next block309, similar processing operations are repeated for the user name login procedure. Yet another similar login sequence occurs for the user's screen name, along with an application identification, as indicated at the block310. If the screen name login is successful, then the authentication server will assign the user to a lobby server and will also promote the session privilege level to the Universe Manager, so that the user will be granted all appropriate access during the session. It should be noted that the authentication server is aware of the lobby servers that are available corresponding to the application ID provided by the user, by requesting an appropriate application server from the Universe Manager. The Universe Manager keeps track of the available lobby servers via “heartbeat” reports that are sent by lobby servers to the Universe Manager continuously while the lobby servers are operational. This processing is represented by the next block310.

Next, at the block311, the user disconnects from the authentication server and establishes communication with the assigned lobby server. At the block312, the user verifies the session key that was obtained from the authentication server at block303and also verifies the application ID with the assigned lobby server. The lobby server verifies the data, as well as the privilege level, with the Universe Manager. The user's privilege is upgraded upon successful verification.

In the next phase of system operation, at block313, the user has successfully completed login with a lobby server and therefore is entitled to participate in system-wide functions. These functions can include, for example, chat, group or community management, player-matching activities such as team or clan tasks, and outcome or competitive standings and ladder progress. Any requests from the user for information regarding available chat channels, available games, location of other users, messaging functions, and the like, the request is forwarded from the lobby server to the Universe Manager. If a request for information involves the non-volatile storage, then the request is forwarded to the appropriate database server (FIG. 2).

One of the system-wide functions that a user might want to participate in following successful connection with a lobby server can comprise using an application. In the context of an online gaming environment, that application is a game. Those skilled in the art will appreciate that other online multi-user applications can be involved. As noted above, the clients can participate in online gaming as either part of a client-server configuration or peer-to-peer configuration, or as part of an integrated application server and client configuration.FIG. 4relates to users who are operating in a client-server or peer-to-peer configuration, andFIG. 5relates to users who are operating in an integrated application server configuration.

InFIG. 4, the first operation (which occurs upon the user wanting to join a game after completion of the last block inFIG. 3), is for the lobby server to forward the user's application (game) request to the Universe Manager. In theFIG. 4processing, the client is configured as a classic client-server configuration or as a peer-to-peer configuration. The Universe Manager assigns the user to a game server that is appropriate for the requested game. The game servers keep the Universe Manager appraised of their status via continuous, periodic heartbeat reports, in a fashion similar to that of the lobby servers. In this way, the Universe Manager is aware of system status and can manage and respond to requests from the lobby servers and application servers. After the first processing operation shown inFIG. 4(block414), the assigned application server assigns a server specific key to the user (block415). The key provides an extra measure of security to prevent unauthorized access. The authentication server asks either the Universe Manager or the assigned application server for the key, and forwards the key to the user through the Universe Manager and to the lobby server.

In the next block416, the user is connected with the assigned application server, providing it with the server-specific key it received from block415. The user will be disconnected from the application server if the server-specific key does not match the records at the application server. If there is a match, the user is allowed to remain connected with the application server. It should be noted that the user remains connected to a lobby server throughout use of the application, such as during a game playing session. At block417, periodic user reports are sent from an application-participating user back to the user's lobby server. In addition, the application server who is hosting the application for all participants (such as the game host) sends periodic reports on the status of the application to the application host. The lobby server and application server do not directly communicate, thereby better managing the processing load on the lobby server.

At the conclusion of the application session (block418), the user disconnects from the application server and returns to normal activities, including all available lobby functions through the lobby server. As noted, these functions can include chat, group or community management, messaging, and the like. It should be noted that these functions are available to the user at all times when the user is connected to the lobby server, including during application use (e.g., during game play).

If the user performs a logout procedure, or if the user is timed out from an active connection because of inactivity, the user's session is cleared from the active records of the Universe Manager. This is indicated at the next block,419. If the user wishes to participate in another application, the user must go through the authentication process once again, including the login process.

Rather than operate in a network configuration in which applications are provided by dedicated application servers, the network can also operate in a configuration in which the multi-user application is provided by integrated servers. An integrated server refers to a user (client) machine that has been configured with an integrated server application that provides the user machine with application server functionality. A system that implements this method of operation is described in co-pending U.S. patent application Ser. No. 09/704,514 by C. Guy, G. Van Datta, and J. Fernandes entitled “Application Development Interface for Multi-User Applications Executable Over Communication Networks” filed Nov. 1, 2000. The disclosure of this application is hereby incorporated by reference. As noted above, when a user wants to join a game, the system operation moves from the description ofFIG. 3to the description of eitherFIG. 4(dedicated application server) orFIG. 5(integrated server).

Turning now toFIG. 5, the first operation under the integrated server configuration is for a user who wants to host an application (such as an online game) to initialize an integrated server application that has been installed on the user's computer. The integrated server application makes a connection to an appropriate domain name, such as a game portal Web site. The integrated server then executes an authentication process with an authentication server, in a process similar to the initial login process described in conjunction withFIG. 3. These operations are represented by the first block514ofFIG. 5.

Upon successful authentication with the authentication server, the hosting user's integrated server application causes periodic server reports to be transmitted to a proxy application server. As noted above, the proxy application server is included within the application server cloud112ofFIG. 1. The proxy application server can comprise an application in addition to or integrated with the integrated server application at the hosting user, or the proxy application server can comprise a separate server that is another node of theFIG. 1network and that communicates with the hosting user's computer. In any case, the user's integrated server application provides periodic, regular “heartbeat” reports to the proxy application server to confirm the operation of the hosted application and to provide status information to the proxy application server. The proxy application server communicates with the Universe Manager, providing the Universe Manager with the application status information received from the hosting user machine. The Universe Manager includes these reports in its data collection, just as it would with similar reports from dedicated application servers and from any other integrated servers. These reporting operations are represented by the second block515ofFIG. 5.

In the next operation, block516, the user notifies its assigned lobby server of its status as an active application server. This new executing application will now be available over the network. The lobby server then registers this new application with the Universe Manager, which adds the appropriate application information to its data collection. This operation is performed by the Universe Manager in a manner similar to what it would perform in response to any other server becoming available with a network application.

After the new application has been registered with the Universe Manager, the network nodes will become aware of the application through respective lobby servers. Therefore, the application becomes available for network users, who can join the program environment established by the integrated server. For example, if the application is a multi-user game, then other network users can join the on-going game, as managed by the hosting user's integrated server. The process of joining a game in progress involves the same operations as described above in conjunction with blocks414,415,416, and417ofFIG. 4. These operations involve communicating with an appropriate application server, receiving a server-specific key, providing the server with that key, becoming authorized and providing regular “heartbeat” reports to the lobby server. These integrated server operations are represented by the “join” block517ofFIG. 5.

At the conclusion of the application session (block518), a participating user can disconnect from the integrated server and return to normal activities, including all available lobby functions through the lobby server. As noted, these functions can include chat, group or community management, messaging, and the like. As noted above, these functions are available to the user at all times when the user is connected to the lobby server, including during application use (e.g., during game play). If a hosting user (the integrated server) wishes to withdraw from hosting the application, the network system (FIG. 1) can implement procedures as desired to ensure an orderly shut down of the application or an orderly transition to a different integrated server that continues on with the program environment of the hosted application.

If the user performs a logout procedure, or if the user is timed out from an active connection because of inactivity, the user's session is cleared from the active records of the Universe Manager. This is indicated at the next block,519. If the user wishes to participate in another application, the user must go through the authentication process once again, including the login process.

Ladder Ranking

The application program interface that is shared in common with all the components illustrated inFIG. 1also includes provision for a ladder ranking engine. A ladder ranking is a list of users that is organized or sorted according to a predetermined variable or metric. The ladder ranking is most easily understood in the context of a gaming application, where the predetermined variable likely refers to wins, losses, points scored, and the like. As a user improves his or her performance, the user's ranking will improve, meaning that the user will move up a “ladder” of ranked users. Thus, the ladder ranking information can be used for various competitive purposes, such as contests and tournaments.

The ladder ranking information is collected via functionality in each multi-user application that periodically reports the application status to the corresponding application server. The status can include information such as progress of players in the game. The application servers then store the information to a system database that is indexed according to a user's account information and application currently being used. This information is managed by a ladder engine that can operate at any location of the network, for example, at the Universe Manager, and the data can be stored at data storage of the Universe Manager or in the database servers (FIG. 1).

The system interface preferably provides for any registered user to request a ladder ranking, which will be provided through the ladder ranking engine. The request can come from a user via an application with which the user is currently participating. This ensures that non-participants cannot falsely obtain the ladder ranking information. The ladder ranking requests can be received by a lobby server or application server from a user, and the request can be forwarded to the ladder ranking engine at the Universe Manager or whatever other network entity that manages the ladder rankings. When a ladder ranking list is requested, all of the user accounts for the specified application are sorted based on the stored user performance data. The application status information preferably includes multiple statistics, which can be stored simultaneously in the database. For example, a gaming application can track wins, losses, points scored, points allowed, and other performance statistics of interest. Each metric can be sorted on, thus generating a ladder ranking according to the metric chosen by the user who requests the ladder ranking. Moreover, the ladder ranking engine provides sorting and retrieving of a ladder ranking in ascending or descending order. For example, a ladder ranking can be provided in order from most points to least points, or from least points to most points.

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

The data can be included in a 256-byte data field that is assigned to each user's account for each application with which the system interfaces. For example, the application code can execute the ladder ranking function by specifying data parameters of sort order, start byte, end byte. Upon receiving a ladder ranking message with these parameters, a server or database of the system will retrieve all data fields for all accounts associated with the calling application. The data in each data record between the start byte location and the end byte location will be treated as an integer value. The sort operation will then be performed on the retrieved data, in ascending or descending order depending on the value of a user-supplied sort order parameter. The sorted integer numbers can then be displayed to a user in accordance with known headings for the integer data. For example, a particular application might store performance data as number of wins, followed by number of losses, followed by points scored, followed by points allowed. When the performance data is retrieved, the data can be parsed to extract the requested data for proper display. Other applications can store different performance parameters in a different order, which will be known to the corresponding application server. In this way, the ladder ranking engine provides a powerful generic, cross-application ladder rankings system.

Clans Engine

Another feature of the system described herein is a clans engine that allows a designated user of any trusted application, a user referred to as a “leader”, to name and create a clan. The leader can then issue invitations to other users for joining the clan. The system will queue up any invitations sent to registered users who are not online at the time the invitation is sent, for delivery at the invitee's next login. A user who receives a clan invitation can respond affirmatively or negatively and, if desired, can become a member of the clan.

The system supports a variety of clan features. Members of a clan can send private electronic messages to the members of the clan. The clan messages can be stored on the servers of the system until delivery, which occurs as each member completes the next login process. The system permits clans to elect new leaders and set up various organizational structures for their clan. Examples of organizational structures include dictatorships, where one leader is in charge of all decisions of the clan, or a democracy, where all members and the leader have equal votes in the clan decision making. The leader who initiates the clan can select which of these, or other, configurations will be utilized.

All of the various clan data, including the clan membership list, clan activity tracking, clan electronic messaging, and the like are saved by database servers of the system. The clan functionality is accessed through the program interface in accordance with the present invention, in a manner similar to that described above for the ladder ranking data. This permits many discrete functions to be provided and specified or deleted for each clan, making the composition rules and operation of each clan potentially exclusive. Moreover, the program interface permits the clan functionality to be used in a generic way for multiple applications. For example, in a gaming context, the same team or clan functionality can be applied whether the application is a flight simulator, car racing game, or action-shooter game.

In addition, multiple applications can share the same clans and membership servers and databases at the same time, without interfering with each other. User accounts can be associated with more than one clan in the same application or in clans that extend across multiple applications, without any impact to the user account or to the clan functionality.

The clan engine in accordance with the present invention manages the clan data using server-side processing, rather than relying on offline, Web-based clan management techniques or client-side arbitration, with nothing built into the actual application itself. Thus, any application developed for the program interface described herein can utilize the clan processing that is built into the interface specification, servers, and databases of theFIG. 1system.

Network Device Construction

The network computer devices (clients and servers) shown in the block diagram ofFIG. 1comprise nodes of a computer network system100.FIG. 6is a block diagram of a computer in the system100ofFIG. 1, illustrating the hardware components included in one of the computers that provide the functionality of the servers and clients. Those skilled in the art will appreciate that the servers and clients illustrated inFIG. 1can all have a similar computer construction, or can have alternative constructions consistent with the capabilities and respective functions described herein.

FIG. 6shows an exemplary computer600such as might comprise any of the network computers. Each computer600operates under control of a central processor unit (CPU)602, such as a “Pentium” microprocessor and associated integrated circuit chips, available from Intel Corporation of Santa Clara, Calif., USA. A computer user can input commands and data from a keyboard and computer mouse604, and can view inputs and computer output at a display606. The display is typically a video monitor or flat panel display. The computer600also includes a direct access storage device (DASD)608, such as a hard disk drive. The memory610typically comprises volatile semiconductor random access memory (RAM). Each computer preferably includes a program product reader612that accepts a program product storage device614, from which the program product reader can read data (and to which it can optionally write data). The program product reader can comprise, for example, a disk drive, and the program product storage device can comprise removable storage media such as a magnetic floppy disk, a CD-R disc, a CD-RW disc, or DVD disc.

Each computer600can communicate with the others over a computer network620(such as the Internet or an intranet) through a network interface618that enables communication over a connection622between the network620and the computer. The network interface618typically comprises, for example, a Network Interface Card (NIC) or a modem that permits communications over a variety of networks.

The CPU602operates under control of programming steps that are temporarily stored in the memory610of the computer600. When the programming steps are executed, the computer performs its functions. Thus, the programming steps implement the functionality of the respective client or server. The programming steps can be received from the DASD608, through the program product storage device614, or through the network connection622. The program product storage drive612can receive a program product614, read programming steps recorded thereon, and transfer the programming steps into the memory610for execution by the CPU602. As noted above, the program product storage device can comprise any one of multiple removable media having recorded computer-readable instructions, including magnetic floppy disks and CD-ROM storage discs. Other suitable program product storage devices can include magnetic tape and semiconductor memory chips. In this way, the processing steps necessary for operation in accordance with the invention can be embodied on a program product.

Alternatively, the program steps can be received into the operating memory610over the network620. In the network method, the computer receives data including program steps into the memory610through the network interface618after network communication has been established over the network connection622by well-known methods that will be understood by those skilled in the art without further explanation. The program steps are then executed by the CPU602thereby comprising a computer process.

It should be understood that all of the network computers of the network system100illustrated inFIG. 1can have a construction similar to that shown inFIG. 6, so that details described with respect to theFIG. 6computer600will be understood to apply to all computers of the system100. It should be appreciated that any of the network computers can have an alternative construction, so long as the computer can communicate with the other computers illustrated inFIG. 4and can support the functionality described herein.

For example, with reference toFIG. 7, the client computers102can comprise a computer entertainment system, such as a video game console system700.FIG. 7is a block diagram of an exemplary hardware configuration of the video game console system700.

The video game console system700includes a central processing unit (CPU)701that is associated with a main memory705. The CPU701operates under control of programming steps that are stored in the OS-ROM760or transferred from a game program storage medium to the main memory705. The CPU701is configured to process information and execute instructions in accordance with the programming steps.

The CPU701is communicatively coupled to an input/output processor (IOP)720via a dedicated bus725. The IOP720couples the CPU701to an OS ROM760comprised of a non-volatile memory that stores program instructions, such as an operating system. The instructions are preferably transferred to the CPU via the IOP720at start-up of the main unit700.

The CPU701is communicatively coupled to a graphics processing unit (GPU)710via a dedicated bus715. The GPU710is a drawing processor that is configured to perform drawing processes and formulate images in accordance with instructions received from the CPU701. For example, the GPU710can render a graphics image based on display lists that are generated by and received from the CPU701. The GPU can include a buffer for storing graphics data. The GPU710outputs images to an AV output device790that is connected to the console system700.

The IOP720controls the exchange of data among the CPU700and a plurality of peripheral components in accordance with instructions that are stored in an IOP memory730. The peripheral components can include one or more input controllers722, a memory card740, a USB745, and an IEEE1394serial bus750. Additionally, a bus755is communicatively coupled to the IOP720. The bus755is linked to several additional components, including the OS ROM760, a sound processor unit (SPU)765, an optical disc control unit775, and a hard disk drive (HDD)780.

The SPU765is configured to generate sounds, such as music, sound effects, and voices, in accordance with commands received from the CPU701and the IOP720. The SPU765can include a sound buffer in which waveform data is stored. The SPU765generates sound signals and transmits the signals to speakers.

The disc control unit775is configured to control a program reader, which can comprise, for example, an optical disk drive that accepts removable storage media such as a magnetic floppy disk, an optical CD-ROM disc, a CD-R disc, a CD-RW disc, a DVD disk, or the like.

The memory card740can comprise a storage medium to which the CPU701can write and store data. Preferably, the memory card740can be inserted and removed from the IOP720. A user can store or save data using the memory card740. In addition, the video game system700is preferably provided with at least one hard disk drive (HDD)780to which data can be written and stored.

A data I/O interface, such as an IEEE1394serial bus750or a universal serial bus (USB)745interface, is preferably communicatively coupled to the IOP720in order to allow data to be transferred into and out of the video game system700, such as to the network illustrated inFIG. 1.

The present invention has been described above in terms of a presently preferred embodiment so that an understanding of the present invention can be conveyed. There are, however, many configurations for the system and application not specifically described herein but with which the present invention is applicable. The present invention should therefore not be seen as limited to the particular embodiment described herein, but rather, it should be understood that the present invention has wide applicability with respect to multi-user applications generally. All modifications, variations, or equivalent arrangements and implementations that are within the scope of the attached claims should therefore be considered within the scope of the invention.