Method for ladder ranking in a game

Methods for creating an interactive gaming environment are provided. In various embodiments, methods of the present invention may include initializing an interactive game application at a game server which is then characterized as having an active status, notifying a lobby server concerning the active status of the game server, registering the application with a universe management server via the lobby server, and allowing users to join the interactive gaming environment. The users joining the interactive gaming environment may be identified by a server key obtained from the game server.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation and claims the priority benefit of U.S. patent application Ser. No. 12/218,581, filed Jul. 15, 2008, now U.S. Pat. No. 7,822,809 and entitled “Creating and Interactive Gaming Environment,” which is a divisional and claims the priority benefit of U.S. patent application Ser. No. 10/359,359, filed Feb. 4, 2003, now U.S. Pat. No. 7,711,847 and entitled “Managing Users in a Multi-User Network Game Environment.” U.S. patent application Ser. No. 10/359,359 claims the priority benefit of U.S. provisional patent application Ser. No. 60/376,115, filed Apr. 26, 2002 and entitled “Multi-User Application Program Interface.” The disclosure of each of the aforementioned applications is incorporated by reference. More than one reissue application has been filed for the reissue of U.S. Pat. No. 7,962,549. The reissue applications include application Ser. Nos. 13/918,809 (the parent reissue) and concurrently-filed continuation reissues 15/688,592 (the present continuation reissue) 15/688,610, and 15/688,565, all of which are reissues of U.S. Pat. No. 7,962,549;

The present application is a continuation reissue of U.S. patent application Ser. No. 13/918,809 filed Jun. 14, 2013, which is an application for reissue of U.S. Pat. No. 7,962,549 filed Jul. 19, 2010 as U.S. patent application Ser. No. 12/839,311 and issued on Jun. 14, 2011; the '549 patent is a continuation of U.S. patent application Ser. No. 12/218,581 filed Jul. 15, 2008, which is a divisional of U.S. patent application Ser. No. 10/359,359 filed Feb. 4, 2003, which claims the priority benefit of U.S. provisional patent application number 60/376,115 filed on Apr. 26, 2002, the disclosures of which are incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to computer networks and, more particularly, to creating an interactive gaming environment over a computer network.

2. Description of the Related Art

Computer networks, such as local area networks and the Internet, are increasingly being used as the backbone for various transactions and interactions between parties. From online banking, where bank customers can initiate financial transactions over a computer network, to online gaming, where garners can participate in real-time gaming over the Internet, service providers are increasingly supporting a variety of services over computer networks. There are currently a variety of different computer network configurations that facilitate the transactions and interactions that take place.

Many of the online applications involve multi-user applications, which are computer programs that are executed on a computer system and which allow multiple geographically separated participants to interact with the computer program and other participating users in an application environment. For example, gaming is a popular multi-user application that is increasing in popularity. An aircraft simulation game can enable multiple participants to pilot their respective virtual aircraft within an airspace, and can enable the participants to interact with other participants in their aircraft in the same airspace. Thus, the online gaming application provides a single application environment or universe in which multiple participants maneuver.

To support multi-user applications, such as online gaming, with geographically dispersed application users, such as game participants, and to support real-time interaction among the users in the application environment, it has been necessary to share information about every participant in the environment. For example, in an aircraft simulation application, it becomes necessary to share information about the airplanes for each of the participants, including aircraft size, speed, altitude in three-dimensional space, appearance details, virtual environment details (such as buildings and terrain), and the like. Such information permits the computer at each participant to properly keep track of game developments and determine the actions being performed by each of the participants. This permits each participant to obtain properly rendered visual images on the participant's viewing display.

The amount of information that must be shared among all of the participants can become daunting and can result in bandwidth difficulties. The amount of information that must be shared among participants is so great that it has inhibited the development of online gaming and other online multi-user applications. A technique for distributing the management of online applications is described in U.S. Pat. No. 5,841,980 to R. Waters et al. entitled Distributed System for Communication Networks in Multi-User Applications.

The '980 patent describes a system configuration in which the functionality of a monolithic server is distributed across multiple servers, each of which services a number of local users. Thus, whereas a single server previously served as the source of all application information, such as game state, the '980 patent describes a situation in which the game server functionality is distributed across multiple computers. Users (on-line participants) are free to login to their most convenient server. In this way, there is no single “choke point” that might inhibit game play, and the bandwidth requirements for the online game community are reduced. Even with the reduction in overall bandwidth demands, the sheer volume of data that must be transmitted between users to support the online environment can result in local pockets of strained bandwidth capacity.

Other multi-user applications provide a somewhat cumbersome user interface and can be inefficient for operation of the application server. For example, some online gaming portals provide links to game sites of interest. The server that provides the gaming portal Web site only provides links to game pages or game Web sites. Thus, the gaming portal will redirect a user to the appropriate game server or host for information about ongoing games. This places additional operational burdens on the game servers.

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

SUMMARY OF THE INVENTION

The present invention provides for creating an interactive gaming environment. In various embodiments, methods of the present invention may include initializing an interactive game application at a game server which is then characterized as having an active status, notifying a lobby server concerning the active status of the game server, registering the application with a universe management server via the lobby server, and allowing users to join the interactive gaming environment. The users joining the interactive gaming environment may be identified by a server key obtained from the game server.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a computer network system on which is run a multi-user application configured in accordance with the present invention.

FIG. 2 is a detail block of the system shown in FIG. 1.

FIG. 3 is a flow diagram of the operations performed by the system of FIG. 1.

FIG. 4 is a flow diagram that shows further system operations in addition to those shown in FIG. 3.

FIG. 5 is a flow diagram that shows further system operations in addition to those shown in FIG. 3.

FIG. 6 is a block diagram of a computer in the network illustrated in FIG. 4, illustrating the hardware components.

FIG. 7 is a block diagram of a computer entertainment system in the network illustrated in FIG. 1, illustrating the hardware components.

 DETAILED DESCRIPTION

System Construction

FIG. 1 is a block diagram of a computer network system 100 comprised of one or more network devices including one or more client computers 102 who communicate with an authorization server 104 to gain access to the system, including participation with multi-user online applications. As described further below, the client computers can comprise computers 102(a) configured in a classic client-server configuration, or in a peer-to-peer configuration, or can comprise computers 102(b) configured in an integrated server configuration that combine the functionality of other computers with the client computer functions. References to client computers 102 will be understood to be a collective reference to either configuration, or references to one configuration subgroup 102(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 server 106 for user records. The authentication server also communicates with a universe manager computer 108 that maintains records about online users and helps manage the online application environment, or universe.

After an authentication server 104 authorizes a user 102 to continue, the user can participate in an online multi-user application by first communicating with lobby servers 110 to 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 server 110 can 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 server 112, 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 server 110, rather than at each individual application server or host machine 112. 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.

In FIG. 1, the lobby servers 108 and application servers 112 are 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 servers 112 can comprise dedicated application server computers 114 that function as a distributed memory engine (DME). As an alternative, as described further below, the application servers can comprise a combination of integrated servers 102(b) and application servers 112 acting in a proxy capacity to provide an interface to the universe manager 108. Similarly, the function of the lobby servers 110 can be provided by dedicated lobby servers that communicate directly with the clients 102, or the lobby server functions can be provided by other computers that communicate with the clients, such as the authentication server or universe manager 108.

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 manager 108 acts in an overall supervisory role, maintaining information about the users (clients) 102 who are registered with the system and logged on, communicating with the users via the authorization servers 104, lobby servers 110, and application servers 112. The lobby servers 110 provide application level information to the users, thereby acting as an application portal and source of application information to the clients 102. 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 servers 112 provide 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 client 102 to fully participate in the online gaming experience for the game administered by the particular application server 112. 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 servers 104 communicate with database servers 106 for authentication, application information, and the like. FIG. 2 illustrates details of the database servers and shows that the database servers can comprise multiple servers and associated database storage. For example, FIG. 2 shows a database server 106 that includes an authentication data server 202 and an associated authentication database 204, a transaction data server 206 and associated transaction database 208, and an application data server 210 and associated application database 212. The operation and configuration of these components will be better understood with reference to the following description.

System Operation

FIGS. 3, 4, and 5 are 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 block 301, 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 block 302) can include operation through a load balancer or similar configuration for server workload management. At the next block 303, 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 in FIG. 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 block 304, and then the authentication server forwards an authentication request to the authentication data server (of the database servers), as indicated at the block 305. 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 (block 306), the authentication request is processed with appropriate load balancing and is directed to a particular one of the authentication servers.

At the next block 307, 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 operation 307 also 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 block 308. The login result is forwarded back to the user and also to the transaction data server. At the next block 309, 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 block 310. 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 block 310.

Next, at the block 311, the user disconnects from the authentication server and establishes communication with the assigned lobby server. At the block 312, the user verifies the session key that was obtained from the authentication server at block 303 and 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 block 313, 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. 4 relates to users who are operating in a client-server or peer-to-peer configuration, and FIG. 5 relates to users who are operating in an integrated application server configuration.

In FIG. 4, the first operation (which occurs upon the user wanting to join a game after completion of the last block in FIG. 3), is for the lobby server to forward the user's application (game) request to the Universe Manager. In the FIG. 4 processing, 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 apprised 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 in FIG. 4 (block 414), the assigned application server assigns a server specific key to the user (block 415). 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 block 416, the user is connected with the assigned application server, providing it with the server-specific key it received from block 415. 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 block 417, 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 (block 418), 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 of FIG. 3 to the description of either FIG. 4 (dedicated application server) or FIG. 5 (integrated server).

Turning now to FIG. 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 with 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 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 cloud 112 of FIG. 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 the FIG. 1 network 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 block 515 of FIG. 5.

In the next operation, block 516, 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 blocks 414, 415, 416, and 417 of FIG. 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” block 517 of FIG. 5.

At the conclusion of the application session (block 518), 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 in FIG. 1 also 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 gaining 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 the FIG. 1 system.

Network Device Construction

The network computer devices (clients and servers) shown in the block diagram of FIG. 1 comprise nodes of a computer network system 100. FIG. 6 is a block diagram of a computer in the system 100 of FIG. 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 in FIG. 1 can all have a similar computer construction, or can have alternative constructions consistent with the capabilities and respective functions described herein.

FIG. 6 shows an exemplary computer 600 such as might comprise any of the network computers. Each computer 600 operates 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 mouse 604, and can view inputs and computer output at a 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 comprises volatile semiconductor random access memory (RAM). Each computer preferably includes a program product reader 612 that accepts a program product storage device 614, 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 computer 600 can communicate with the others over a computer network 620 (such as the Internet or an intranet) through a network interface 618 that enables communication over a connection 622 between the network 620 and the computer. The network interface 618 typically comprises, for example, a Network Interface Card (NIC) or a modem that permits communications over a variety of networks.

The CPU 602 operates under control of programming steps that are temporarily stored in the memory 610 of the computer 600. 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 DASD 608, through the program product storage device 614, or through the network connection 622. The program product storage drive 612 can receive a program product 614, read programming steps recorded thereon, and transfer the programming steps into the memory 610 for execution by the CPU 602. 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 memory 610 over the network 620. In the network method, the computer receives data including program steps into the memory 610 through the network interface 618 after network communication has been established over the network connection 622 by well-known methods that will be understood by those skilled in the art without further explanation. The program steps are then executed by the CPU 602 thereby comprising a computer process.

It should be understood that all of the network computers of the network system 100 illustrated in FIG. 1 can have a construction similar to that shown in FIG. 6, so that details described with respect to the FIG. 6 computer 600 will be understood to apply to all computers of the system 100. 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 in FIG. 4 and can support the functionality described herein.

For example, with reference to FIG. 7, the client computers 102 can comprise a computer entertainment system, such as a video game console system 700. FIG. 7 is a block diagram of an exemplary hardware configuration of the video game console system 700.

The video game console system 700 includes a central processing unit (CPU) 701 that is associated with a main memory 705. The CPU 701 operates under control of programming steps that are 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 in accordance with the programming steps.

The CPU 701 is communicatively coupled to an input/output processor (IOP) 720 via a dedicated bus 725. The IOP 720 couples the CPU 701 to an OS ROM 760 comprised of a non-volatile memory that stores program instructions, such as an operating system. The instructions are preferably transferred to the CPU via the IOP 720 at start-up 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 that is configured to perform drawing processes and formulate images in accordance with instructions received from the CPU 701. For example, the GPU 710 can render a graphics image based on display lists that are generated by and received from the CPU 701. The GPU can include a buffer for storing graphics data. The GPU 710 outputs images to an AV output device 790 that is connected to the console system 700.

The IOP 720 controls the exchange of data among the CPU 700 and a plurality of peripheral components in accordance with instructions that are stored in an IOP memory 730. The peripheral components can include one or more input controllers 722, a memory card 740, a USB 745, and an IEEE 1394 serial bus 750. Additionally, a bus 755 is communicatively coupled to the IOP 720. The bus 755 is linked to several additional components, including the 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, in accordance with commands received from the CPU 701 and the IOP 720. The SPU 765 can include a sound buffer in which waveform data is stored. The SPU 765 generates sound signals and transmits the signals to speakers.

The disc control unit 775 is 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 card 740 can comprise a storage medium to which the CPU 701 can write and store data. Preferably, the memory card 740 can be inserted and removed from the IOP 720. A user can store or save data using the memory card 740. In addition, the video game system 700 is preferably provided 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 in order to allow data to be transferred into and out of the video game system 700, such as to the network illustrated in FIG. 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.

Claims

1. A method for ladder ranking in a game application, comprising:

receiving a request for a ladder ranking list from a player having a user account registered with the game application, wherein the game application is associated with a plurality of registered user accounts and the request for the ladder ranking list includes one or more game performance metrics identified by the player;
executing instructions stored in memory, wherein execution of the instructions by a processor: retrieves game performance data from all user accounts registered with the game application, the game performance data stored at an application server; sorts all user accounts registered with the game application based on the stored game performance data; and generates a ladder ranking list including all sorted registered user accounts based on the one or more game performance metrics.

2. The method of claim 1, wherein the game performance data stored at the application server is collected during periodic game application status reports.

3. The method of claim 1, wherein the game performance metric includes the number of wins.

4. The method of claim 1, wherein the game performance metric includes the number of losses.

5. The method of claim 1, wherein the game performance metric includes points scored.

6. The method of claim 1, wherein the game performance metric includes points allowed.

7. The method of claim 1, wherein the ladder ranking list is sorted in ascending order.

8. The method of claim 1, wherein the ladder ranking list is sorted in descending order.

9. A system for ladder ranking in a game application, comprising:

a lobby server for receiving a request for a ladder ranking list from a player having a user account registered with the game application, wherein the game application is associated with a plurality of registered user accounts and the request for the ladder ranking list includes one or more game performance metrics identified by the player; and
a ladder engine stored in memory and executable by a processor to: retrieve game performance data from all user accounts registered with the game application, the game performance data stored at an application server, sort all user accounts registered with the game application based on the stored game performance data, and generate a ladder ranking list including all sorted registered user accounts based on the one or more game performance metrics.

10. The system of claim 9, wherein the ladder engine executes further instructions to sort the ladder ranking list in ascending order.

11. The system of claim 9, wherein the ladder engine executes further instructions to sort the ladder ranking list in descending order.

12. A non-transitory computer readable storage medium having embodied thereon a program, the program being executable by a processor to perform a method for ladder ranking in a game application, the method comprising:

receiving a request for a ladder ranking list from a player having a user account registered with the game application, wherein the game application is associated with a plurality of registered user accounts and the request for the ladder ranking list includes one or more game performance metrics identified by the player;
retrieves game performance data from all user accounts registered with the game application;
sorts all user accounts registered with the game application based on the stored game performance data; and
generates a ladder ranking list including all sorted registered user accounts based on the one or more game performance metrics.

13. A lobby server apparatus for cross-application and real-time communication channels, the apparatus comprising:

a network interface that receives login information from a first client device; and
a processor that executes instructions stored in a memory, wherein execution of the instructions by the processor: authenticates the login information received from the first client device, establishes an online session with the first client device in accordance with a lobby server assignment based on the authenticated login information, assigns the first client device to a game server in accordance with a game server assignment, wherein the first client device connects to the assigned game server based on the game server assignment and obtains game-related information from the assigned game server, and performs a plurality of lobby server functionalities associated with the game-related information in accordance with a split distribution of functionalities that reduces one or more operating demands on the assigned game server, the lobby server functionalities including: providing status information regarding game play of a first game by the first client device in a game environment provided by the assigned game server, the status information provided to at least a second client device; establishing a channel for cross-application user communications in real-time between the first client device and the second client device during the game play of the first game by the first client device in the game environment provided by the assigned game server and during game play of a second game by the second client device, and updating the status information regarding the first client device when the online session of the first client device is terminated.

14. The apparatus of claim 13, wherein the status information is provided via an application portal that provides real-time information regarding one or more games currently in progress and regarding players currently playing each game.

15. The apparatus of claim 13, wherein the login information includes information regarding an account registered to the first client device.

16. The apparatus of claim 13, wherein the processor executes further instructions to create a clan based on a request from the first client device, wherein the clan comprises the first client device and one or more other client devices.

17. The apparatus of claim 16, wherein the network interface sends an invitation to each of the other client devices, and wherein the processor executes further instructions to add the respective client device upon acceptance of the invitation.

18. The apparatus of claim 17, wherein at least one of the other client devices is not online when the respective invitation is sent, and wherein the invitation is made available to the at least one other client device when the at least one other client device next logs in.

19. The apparatus of claim 16, wherein the first client device further specifies that the other client devices are able to make decisions regarding the clan.

20. The apparatus of claim 16, wherein the channel for cross-application user communications is specific to the clan.

21. The apparatus of claim 16, wherein information regarding the created clan is used in a plurality of different game applications.

22. The apparatus of claim 16, further comprising memory that stores information related to the clan, the stored information including at least one of a member list, tracked activity, and electronic messages.

23. The apparatus of claim 16, wherein the clan includes an organizational structure that includes at least one client device identified as a leader, wherein the leader makes one or more decisions for the clan.

24. The apparatus of claim 13, wherein the network interface further receives periodic status reports sent from an application server of the first client device.

25. The apparatus of claim 13, further comprising memory that maintains information regarding a plurality of client devices that are currently logged in.

26. The apparatus of claim 13, wherein the online session of the first client device is terminated when the first client device performs a logout procedure or when the first client device is detected as having been inactive for a predetermined period of time.

27. The apparatus of claim 13, wherein the processor executes further instructions to perform player-matching.

28. The apparatus of claim 13, wherein the processor executes further instructions to provide information to the first client device regarding available chat channels, available games, or locations of other users.

29. The apparatus of claim 13, wherein the processor executes further instructions to provide a list of a plurality of client devices, wherein the list is ranked according to a predetermined metric.

30. A lobby server method for cross-application and real-time communication, the method comprising:

receiving login information sent over a communication network from a first client device; and
executing instructions stored in memory, wherein execution of the instructions by a processor: authenticates the login information received from the first client device, establishes an online session with the first client device in accordance with a lobby server assignment based on the authenticated login information, assigns the first client device to a game server in accordance with a game server assignment, wherein the first client device connects to the assigned game server based on the game server assignment and obtains game-related information from the assigned game server, and performs a plurality of lobby server functionalities associated with the game-related information in accordance with a split distribution of functionalities reduces one or more operating demands on the assigned game server, the lobby server functionalities including: providing status information obtained from the assigned game server regarding game play of a first game by the first client device in a game environment provided by the assigned game server, the status information provided to at least a second client device, establishing a channel for cross-application user communications in real-time between the first client device and the second client device during the game play of the first game by the first client device in the game environment provided by the assigned game server and during game play of a second game by the second client device, and updating the status information regarding the first client device when the online session of the first client device is terminated.

31. The method of claim 30, wherein the status information is provided via an application portal that provides real-time information regarding one or more games currently in progress and regarding players currently playing each game.

32. The method of claim 30, wherein the login information includes information regarding an account registered to the first client device.

33. The method of claim 30, wherein execution of further instructions by the processor creates a clan based on a request from the first client device, wherein the clan comprises the first client device and one or more other client devices.

34. The method of claim 33, further comprising sending an invitation to each of the other client devices, and wherein execution of further instructions by the processor adds the respective client device upon acceptance of the invitation.

35. The method of claim 34, wherein at least one of the other client devices is not online when the respective invitation is sent, and wherein the invitation is made available to the at least one other client device when the at least one other client device next logs in.

36. The method of claim 33, wherein the first client device further specifies that the other client devices are able to make decisions regarding the clan.

37. The method of claim 33, wherein the channel for cross-application user communications is specific to the clan.

38. The method of claim 33, wherein information regarding the created clan is used in a plurality of different game applications.

39. The method of claim 33, further comprising storing information in memory related to the clan, the stored information including at least one of a member list, tracked activity, and electronic messages.

40. The method of claim 33, wherein the clan includes an organizational structure that includes at least one client device identified as a leader, wherein the leader makes one or more decisions for the clan.

41. The method of claim 30, further comprising receiving periodic status reports sent from an application server of the first client device.

42. The method of claim 30, further comprising maintaining information in memory regarding a plurality of client devices that are currently logged in.

43. The method of claim 30, wherein the online session of the first client device is terminated when the first client device performs a logout procedure or when the first client device is detected as having been inactive for a predetermined period of time.

44. The method of claim 30, wherein further execution of instructions by the processor performs player-matching.

45. The method of claim 30, wherein further execution of instructions by the processor provides information to the first client device regarding available chat channels, available games or locations of other users.

46. The method of claim 30, wherein further execution of instructions by the processor provides a list of a plurality of client devices, wherein the list is ranked according to a predetermined metric.

47. A non-transitory computer-readable storage medium, having embodied thereon a program executable by a processor to perform a lobby server method for cross-application channels in real-time communication, the method comprising:

receiving login information sent over a communication network from a first client device;
authenticating the login information received from the first client device;
establishing an online session with the first client device in accordance with a lobby server assignment based on the authenticated login information;
assigning the first client device to a game server in accordance with a game server assignment, wherein the first client device connects to the assigned game server based on the game server assignment and obtains game-related information from the assigned game server within the online session; and
performing a plurality of lobby server functionalities associated with the game-related information in accordance with a split distribution of functionalities reduces one or more operating demands on the assigned game server, the lobby server functionalities including: providing status information obtained from the assigned game server regarding game play of a first game by the first client device in a game environment provided by the assigned game server, the status information provided to at least a second client device; establishing a channel for cross-application communications in real-time between the first client device and the second client device during the game play of the first game by the first client device in the game environment provided by the assigned game server and during game play of a second game by the second client device; and updating the status information regarding the first client device when the online session of the first client device is terminated.

48. The apparatus of claim 13, wherein establishing the online session with the first client device in accordance with the lobby server assignment includes associating the online session with a privilege level of authorized access based on the authenticated login information.

49. The apparatus of claim 13, wherein the authorized access includes one or more game applications, and wherein the game server assignment is based on a game application requested by the first client device.

50. The apparatus of claim 13, wherein the online session is established further based on a session key, and wherein the connection between the first client device and the assigned game server is further based on a server-specific key.

51. The method of claim 30, wherein establishing the online session with the first client device in accordance with the lobby server assignment includes associating the online session with a privilege level of authorized access based on the authenticated login information.

52. The method of claim 30, wherein the authorized access includes one or more game applications, and wherein the game server assignment is based on a game application requested by the first client device.

53. The method of claim 30, wherein the online session is established further based on a session key, and wherein the connection between the first client device and the assigned game server is further based on a server-specific key.

Referenced Cited
U.S. Patent Documents
5630757 May 20, 1997 Gagin et al.
5634129 May 27, 1997 Dickinson
5682139 October 28, 1997 Pradeep
5704032 December 30, 1997 Badovinatz et al.
5823879 October 20, 1998 Goldberg
5826085 October 20, 1998 Bennet
5838909 November 17, 1998 Roy et al.
5841980 November 24, 1998 Waters
5862339 January 19, 1999 Bonnaure et al.
5893106 April 6, 1999 Brobst et al.
5941947 August 24, 1999 Brown
5956485 September 21, 1999 Perlman
5984787 November 16, 1999 Redpath
5987376 November 16, 1999 Olson et al.
6038599 March 14, 2000 Black et al.
6041312 March 21, 2000 Bickerton et al.
6050898 April 18, 2000 Vange
6098091 August 1, 2000 Kisor
6106569 August 22, 2000 Bohrer
6108569 August 22, 2000 Shen
6142472 November 7, 2000 Kliebisch
6151632 November 21, 2000 Chaddha et al.
6152824 November 28, 2000 Rothschild et al.
6154782 November 28, 2000 Kawaguchi et al.
6203433 March 20, 2001 Kume
6219045 April 17, 2001 Leahy et al.
6247017 June 12, 2001 Martin
6311209 October 30, 2001 Olson et al.
6345297 February 5, 2002 Grimm
6352479 March 5, 2002 Sparks
6363416 March 26, 2002 Naeimi
6446113 September 3, 2002 Ozzie et al.
6470022 October 22, 2002 Rochberger
6487583 November 26, 2002 Harvey
6487678 November 26, 2002 Briskey et al.
6519629 February 11, 2003 Harvey
6530840 March 11, 2003 Cuomo
6539494 March 25, 2003 Abramson et al.
6549946 April 15, 2003 Fisher
6560636 May 6, 2003 Cohen et al.
6561811 May 13, 2003 Rapoza et al.
6577628 June 10, 2003 Hejza
6587874 July 1, 2003 Golla
6607444 August 19, 2003 Takahashi et al.
6631412 October 7, 2003 Glasser et al.
6654831 November 25, 2003 Otterness et al.
6676521 January 13, 2004 La Mura et al.
6704885 March 9, 2004 Salas-Meza et al.
6748420 June 8, 2004 Quatrano et al.
6755743 June 29, 2004 Yamashita
6761636 July 13, 2004 Chung et al.
6763371 July 13, 2004 Jandel
6766364 July 20, 2004 Moyer et al.
6769990 August 3, 2004 Cohen
6799255 September 28, 2004 Blumenau
6839435 January 4, 2005 Lijima et al.
6844893 January 18, 2005 Miller et al.
6931446 August 16, 2005 Cox et al.
7003550 February 21, 2006 Cleasby et al.
7016942 March 21, 2006 Odom
7018295 March 28, 2006 Sakaguchi et al.
7025675 April 11, 2006 Fogel
7035919 April 25, 2006 Lee et al.
7056217 June 6, 2006 Pelkey
7089301 August 8, 2006 Labio et al.
7107312 September 12, 2006 Hackbarth et al.
7155515 December 26, 2006 Brown et al.
7165107 January 16, 2007 Pouyoul et al.
7177950 February 13, 2007 Narayan et al.
7188145 March 6, 2007 Lowery et al.
7203755 April 10, 2007 Zhu et al.
7290264 October 30, 2007 Powers et al.
7366185 April 29, 2008 Bush
7454458 November 18, 2008 Islam et al.
7523163 April 21, 2009 Zhu et al.
7539216 May 26, 2009 Johns et al.
7587465 September 8, 2009 Muchow
7613800 November 3, 2009 Dhupelia
7640298 December 29, 2009 Berg
7680908 March 16, 2010 Gates, III et al.
7711847 May 4, 2010 Dhupelia
7720908 May 18, 2010 Newson et al.
7730206 June 1, 2010 Newson et al.
7792902 September 7, 2010 Chatani
7822809 October 26, 2010 Dhupelia
7831666 November 9, 2010 Chatani et al.
7877509 January 25, 2011 Dhupelia
7899017 March 1, 2011 Yu et al.
7908393 March 15, 2011 Marr et al.
7930345 April 19, 2011 Dhupelia
7962549 June 14, 2011 Dhupelia
8032619 October 4, 2011 Kato et al.
8050272 November 1, 2011 Chaturvedi et al.
8051180 November 1, 2011 Mazzaferri et al.
8131802 March 6, 2012 Jacob
8214489 July 3, 2012 Ballette et al.
8335813 December 18, 2012 Sun et al.
8402124 March 19, 2013 Barillaud et al.
8549150 October 1, 2013 Roseman et al.
8554842 October 8, 2013 Maehiro
8560707 October 15, 2013 Jacob
8719143 May 6, 2014 Meijer et al.
8719375 May 6, 2014 Hildreth et al.
8725874 May 13, 2014 Keohane et al.
8856233 October 7, 2014 Lacapra et al.
8965978 February 24, 2015 Chandranmenon et al.
8972548 March 3, 2015 Jacob
8990305 March 24, 2015 Barkley et al.
9032248 May 12, 2015 Petty et al.
9318003 April 19, 2016 Nilsson et al.
9369540 June 14, 2016 Lowery et al.
9516068 December 6, 2016 Jacob
9729621 August 8, 2017 Jacob
9762631 September 12, 2017 Chatani
10063631 August 28, 2018 Jacob
10547670 January 28, 2020 Jacob
10659500 May 19, 2020 Chatani
20010009868 July 26, 2001 Sakaguchi et al.
20010024974 September 27, 2001 Cohen
20010037466 November 1, 2001 Fukutake et al.
20010044339 November 22, 2001 Cordero
20020023117 February 21, 2002 Bernardin et al.
20020035604 March 21, 2002 Cohen et al.
20020042830 April 11, 2002 Bose et al.
20020049086 April 25, 2002 Otsu
20020062348 May 23, 2002 Maehiro
20020075844 June 20, 2002 Hagen
20020075940 June 20, 2002 Haartsen
20020082077 June 27, 2002 Johnson
20020082086 June 27, 2002 Scallie
20020086732 July 4, 2002 Kirmse et al.
20020107934 August 8, 2002 Lowery et al.
20020107935 August 8, 2002 Lowery et al.
20020115488 August 22, 2002 Berry
20020133707 September 19, 2002 Newcombe
20020142842 October 3, 2002 Easley
20020156917 October 24, 2002 Nye
20020169889 November 14, 2002 C
20020178260 November 28, 2002 Chang
20020184070 December 5, 2002 Chen et al.
20030018719 January 23, 2003 Ruths
20030073494 April 17, 2003 Kalpakian et al.
20030093669 May 15, 2003 Morals et al.
20030126245 July 3, 2003 Feltin et al.
20030167343 September 4, 2003 Furuno
20030190960 October 9, 2003 Jokipii
20030204566 October 30, 2003 Dhupelia
20030204593 October 30, 2003 Brown et al.
20030214943 November 20, 2003 Engstrom et al.
20030216181 November 20, 2003 Daniell et al.
20030217135 November 20, 2003 Chatani
20030217158 November 20, 2003 van Datta
20030233537 December 18, 2003 Wohlgemuth et al.
20040001476 January 1, 2004 Islam et al.
20040002384 January 1, 2004 Multerer et al.
20040024879 February 5, 2004 Dingman
20040030787 February 12, 2004 Jandel
20040031052 February 12, 2004 Wannamaker et al.
20040053690 March 18, 2004 Fogel
20040059711 March 25, 2004 Jandel
20040117443 June 17, 2004 Barsness
20040139228 July 15, 2004 Takeda
20050038836 February 17, 2005 Wang
20050068894 March 31, 2005 Yu et al.
20050105526 May 19, 2005 Stiemerling
20050144521 June 30, 2005 Werner
20050181878 August 18, 2005 Danieli et al.
20050245317 November 3, 2005 Arthur et al.
20050251577 November 10, 2005 Guo
20050259637 November 24, 2005 Chu
20050262411 November 24, 2005 Vertes
20060015560 January 19, 2006 MacAuley et al.
20060047836 March 2, 2006 Rao et al.
20060075127 April 6, 2006 Juncker
20060085792 April 20, 2006 Traut
20060092942 May 4, 2006 Newson et al.
20060100020 May 11, 2006 Kasai
20060142085 June 29, 2006 Kim
20060168107 July 27, 2006 Balan et al.
20060164974 July 27, 2006 Ramalho et al.
20060190540 August 24, 2006 Chatani
20060200551 September 7, 2006 Bali et al.
20060218274 September 28, 2006 Labio et al.
20060218275 September 28, 2006 Labio et al.
20060221856 October 5, 2006 Quiroz
20060247011 November 2, 2006 Gagner
20060248144 November 2, 2006 Zhu et al.
20060253595 November 9, 2006 van Datta
20060258463 November 16, 2006 Cugno et al.
20060288103 December 21, 2006 Gobara
20070058792 March 15, 2007 Chaudhari
20070061460 March 15, 2007 Khan
20070076729 April 5, 2007 Takeda
20070094325 April 26, 2007 Ih et al.
20070099702 May 3, 2007 Tupper
20070165629 July 19, 2007 Chaturvedi
20070174399 July 26, 2007 Ogle et al.
20070191109 August 16, 2007 Crowder
20070208748 September 6, 2007 Li
20070217436 September 20, 2007 Markley
20070233865 October 4, 2007 Garbow et al.
20070288598 December 13, 2007 Edeker et al.
20070291706 December 20, 2007 Miller et al.
20080049755 February 28, 2008 Gannon et al.
20080189365 August 7, 2008 Narayanaswami et al.
20080243953 October 2, 2008 Wu et al.
20080280686 November 13, 2008 Dhupelia et al.
20080291839 November 27, 2008 Hooper et al.
20090006545 January 1, 2009 Dhupelia
20090006604 January 1, 2009 Dhupelia
20090077245 March 19, 2009 Smelyansky
20090089363 April 2, 2009 Keohane et al.
20090094370 April 9, 2009 Jacob
20090113060 April 30, 2009 Jacob
20090138610 May 28, 2009 Gobara
20090157882 June 18, 2009 Kashyap
20090240821 September 24, 2009 Juncker
20090287828 November 19, 2009 Wei et al.
20100153496 June 17, 2010 Heinla
20100279767 November 4, 2010 Dhupelia
20100285872 November 11, 2010 Dhupelia
20100287239 November 11, 2010 Chatani
20120166651 June 28, 2012 Jacob
20130304931 November 14, 2013 Jacob
20140256449 September 11, 2014 Chatani et al.
20150180958 June 25, 2015 Jacob
20180013802 January 11, 2018 Chatani
20180013820 January 11, 2018 Jacob
20200329094 October 15, 2020 Jacob
Foreign Patent Documents
104069637 October 2014 CN
1125617 August 2001 EP
1499987 January 2005 EP
2360874 August 2011 EP
2360875 August 2011 EP
2325543 November 1998 GB
269863 December 2015 IN
05-022346 January 1993 JP
63-32725 September 1998 JP
11-234326 August 1999 JP
2000-124939 April 2000 JP
2000-157724 June 2000 JP
2001-187273 July 2001 JP
2001-314657 November 2001 JP
2002-011251 January 2002 JP
2003-099337 April 2003 JP
201347493 November 2013 TW
I491229 July 2015 TW
WO 2000/05854 February 2000 WO
WO 2000/10099 February 2000 WO
WO 2000/68864 November 2000 WO
WO 2001/63423 August 2001 WO
WO 2001/82678 November 2001 WO
WO 2002/35769 May 2002 WO
WO 2003/091894 November 2003 WO
WO 2003/100643 December 2003 WO
WO 2004/063843 July 2004 WO
WO 2005/088466 September 2005 WO
WO 2006/023508 March 2006 WO
WO 2009/045475 April 2009 WO
Other references
  • U.S. Appl. No. 15/702,580 Office Action dated Jan. 24, 2019.
  • U.S. Appl. No. 15/672,113 Office Action dated Mar. 8, 2018.
  • “Brief for Appellee,” in re Masayuki Chatani et al., U.S. Court of Appeals for the Federal Circuit (2007-1150) (May 21, 2007).
  • “Brief of Appellants,” in re Masayuki Chatani et al., U.S. Court of Appeals for the Federal Circui (2007-1150) (Mar. 23, 2007).
  • “In Re Masayuki Chatani and Glen Van Datta,” United States Court of Appeals for the Federal Circuit, 2007-1150 (U.S. Appl. No. 11/211,128), Nov. 19, 2007.
  • “Petition for Panel Rehearing,” In Re Masayuki Chatani and Glen Van Datta, Appeal From the United States Patent and Trademark Office, Board of Patent Appeals and Interferences, In the United States Court of Appeals for the Federal Circuit, 2007-1150 (U.S. Appl. No. 10/211,128), Jan. 3, 2008.
  • “Reply Brief of Appellants,” In re Masayuki Chatani et al., U.S. Court of Appeals for the Federal Circuit (2007-1150) (Jun. 4, 2007).
  • “Technical Issues of establishing any-to-any 2-way real-time communications over the internet,” Apr. 24, 2005, URL http://web.archive.org/web/20050424081036/.
  • Aronson, Jesse. “Using Groupings for Networked Gaming,” Gamasutra.com, Jun. 21, 2000.
  • Audet, F. Nat Behavioral Requirements for Unicast UDP, Behave Internet-Draft, Jul. 15, 2005.
  • Boulic, Ronan etl al. “Integration of Motion Control Techniques for Virtual Human and Avatar Real-Time Animation,” Swiss Fedl Inst. Of Tech., Lausanne, Switzerland, Sep. 1997.
  • Chiueh, Tzi-cker, “Distributed Systems Support for Networked Games,” Computer Science Department, State University of New York at Stony Brook, Stony Brook, NY, May 1997.
  • Cisco Systems Inc., “Network Flow Management: Resource Reservation for Multimedia Flows,” Mar. 19, 1999.
  • Diot et al., “A Distributed Architecture for Multiplayer Interactive Applications on the Internet”, Aug. 1999, Network, IEEE, vol. 13, Issue 4, Jul.-Aug. 1999, pp. 6-15.
  • ECC Report 50. “Technical Issues of Establishing Any-to-Any-2-Way Real-Time Communications over the Internet.” Electronic Communications Committee (ECC). Gothenburg, Jul. 2004.
  • Festa and Borland, “Netscape alumni to launch P2P company”, Aug. 2, 2001, (avaiable at http://news.cnet.com/news/0/1005-202-6766377.html).
  • Hagsand O: Interactive Multiuser Ves in the Dive System: IEEE Multimedia, IEEE Service Center, New York, NY, US vol. 3, No. 1, 21 Mar. 21, 1996, pp. 30-39, XP000582951 ISSN: 1070-986X.
  • Hanada, S. “The Design of Network Game and DirectPlay,” Inside Windows, Softbank K.K., vol. 4, pp. 42-57, Apr. 1, 1998.
  • Rosenberg, J. Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols, Mmusic Internet-Draft, Jul. 19, 2004.
  • Rosenberg, J. Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, Mmusic Internet—Draft, Jul. 17, 2005.
  • Rosenberg, J. Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Off/Answer Protocols, Mmusic Internet—Draft, Jan. 16, 2007.
  • Rosenberg, J. “Simple Traversal of UDP Through Network Address Translators (NAT),” Behave Internet—Draft, Jul. 17, 2005.
  • Rosenberg, J. STUN—Simple Traversal of User Datagram Protocols (UDP) Throught Network Address Translators (NATs), Network Working Group, Mar. 2003.
  • Rosenberg, J. Traversal using Relay NAT (TURN), Midcom Internet—Draft, Oct. 20, 2003.
  • Takeda, Y. Symmetric NAT Traversal Using STUN, Internet Engineering Task Force, Jun. 2003.
  • PCT/US03/08682 International Search Report dated Oct. 14, 2003.
  • PCT/US03/12668 International Search Report dated Jul. 17, 2003.
  • PCT/US08/11415 Search Report and Written Opinion dated Dec. 5. 2008.
  • EP 037211413, European Search Report dated Jun. 30, 2005.
  • Chinese Application No. 03801033, Office Action dated Jun. 9, 2006.
  • Chinese Application No. 03801033, Office Action dated Jul. 5, 2011.
  • Chinese Application No. 03801033, Office Action dated Sep. 25, 2009.
  • Chinese Application No. 201410266012.9, Office Action dated Jul. 27, 2016.
  • European Application No. 03724201.3, Office Action dated Dec. 13, 2013.
  • European Application No. 03724201.3, Office Action dated Jul. 3, 2012.
  • Chinese Application No. 200810168739.8, Decision of Rejection dated Dec. 11, 2012.
  • Chinese Application No. 200810168739.8, Office Action dated May 11, 2012.
  • Chinese Application No. 200810168739.8, Office Action dated May 19, 2011.
  • Chinese Application No. 20088011547.1, Decision of Rejection dated Jul. 5, 2013.
  • Chinese Application No. 20088011547.1, Office Action dated Oct. 12, 2012.
  • Chinese Application No. 20088011547.1, Office Action dated Mar. 7, 2012.
  • Chinese Application No. 20088011547.1, Office Action dated Aug. 10, 2012.
  • EP 08014892.7 Office Action dated Jul. 20, 2011.
  • Taiwan Application No. 097138349, Office Action dated Mar. 26, 2014.
  • Taiwan Application No. 097138349, Office Action dated Feb. 8, 2013.
  • EP 08835745.4 Extended European Search Report dated Jul. 22, 2011.
  • EP 11004182.9 Extended European Search Report dated Jul. 14, 2011.
  • EP 11004181.1 Extended European Search Report dated Jul. 22, 2011.
  • U.S. Application No. 10/211,128 Final Office Action dated Feb. 2, 2004.
  • U.S. Appl. No. 10/211,128 Office Action dated Nov. 10, 2003.
  • U.S. Appl. No. 11/375,526 Office Action dated Apr. 8, 2008.
  • U.S. Appl. No. 11/375,526 Final Office Action dated Jul. 3, 2007.
  • U.S. Appl. No. 11/375,526 Final Office Action dated Mar. 2, 2007.
  • U.S. Appl. No. 11/375,526 Office Action dated Oct. 24, 2006.
  • U.S. Appl. No. 11/403,623 Office Action dated Jun. 25, 2009.
  • U.S. Appl. No. 11/403,623 Office Action dated Apr. 9, 2008.
  • U.S. Appl. No. 11/403,623 Final Office Action dated Jul. 3, 2007.
  • U.S. Appl. No. 11/403,623 Final Office Action dated Mar. 5, 2007.
  • U.S. Appl. No. 11/403,623 Office Action dated Oct. 24, 2006.
  • U.S. Appl. No. 12/840,977 Office Action dated Jul. 30, 2013.
  • U.S. Appl. No. 12/840,977 Final Office Action dated Jun. 18, 2012.
  • U.S. Appl. No. 12/840,977 Final Office Action dated Oct. 19, 2011.
  • U.S. Appl. No. 12/840,977 Office Action dated May 16, 2011.
  • U.S. Appl. No. 12/840,977 Final Office Action dated Dec. 3, 2010.
  • U.S. Appl. No. 14/283,959 Office Action dated Jan. 11, 2017.
  • U.S. Appl. No. 14/283,959 Final Office Action dated Jul. 19, 2016.
  • U.S. Appl. No. 14/283,959 Office Action dated Feb. 4, 2016.
  • U.S. Appl. No. 10/359,359 Final Office Action dated Nov. 27, 2009.
  • U.S. Appl. No. 10/359,359 Office Action dated Mar. 31, 2009.
  • U.S. Appl. No. 10/359,359 Office Action dated Aug. 27, 2007.
  • U.S. Appl. No. 10/359,359 Final Office Action dated Feb. 9, 2007.
  • U.S. Appl. No. 10/359,359 Office Action dated Aug. 8, 2006.
  • U.S. Appl. No. 12/839,306 Office Action dated Nov. 12, 2010.
  • U.S. Appl. No. 12/839,311 Office Action dated Nov. 12, 2010.
  • U.S. Appl. No. 12/218,581 Office Action dated Sep. 2, 2010.
  • U.S. Appl. No. 12/218,581 Office Action dated Feb. 1, 2010.
  • U.S. Appl. No. 12/218,581 Office Action dated Oct. 2, 2009.
  • U.S. Appl. No. 12/218,591 Office Action dated Feb. 25, 2009.
  • U.S. Appl. No. 13/918,809 Final Office Action dated May 10, 2017.
  • U.S. Appl. No. 13/918,809 Office Action dated Oct. 20, 2016.
  • U.S. Appl. No. 13/918,809 Final Office Action dated Nov. 18, 2015.
  • U.S. Appl. No. 13/918,809 Office Action dated Apr. 29, 2015.
  • U.S. Appl. No. 13/918,809 Office Action dated Jun. 10, 2014.
  • U.S. Appl. No. 12/049,954 Final Office Action dated Dec. 14, 2010.
  • U.S. Appl. No. 12/049,954 Office Action dated Jun. 24, 2010.
  • U.S. Appl. No. 12/235,438 Final Office Action dated Jan. 4, 2012.
  • U.S. Appl. No. 12/235,438 Office Action dated Aug. 8, 2011.
  • U.S. Appl. No. 12/235,438 Final Office Action dated Aug. 31, 2010.
  • U.S. Appl. No. 12/235,438 Office Action dated Apr. 15, 2010.
  • U.S. Appl. No. 13/412,361 Office Action dated Jun. 17, 2014.
  • U.S. Appl. No. 13/412,361 Final Office Action dated Nov. 28, 2012.
  • U.S. Appl. No. 13/412,361 Office Action dated Jul. 30, 2012.
  • U.S. Appl. No. 13/941,436 Final Office Action dated Oct. 7, 2015.
  • U.S. Appl. No. 13/941,436 Office Action dated Jun. 22, 2015.
  • U.S. Appl. No. 14/637,182 Office Action dated Sep. 9, 2016.
  • U.S. Appl. No. 15/702,580, filed Sep. 12, 2017, Masayuki Chatani, Managing Participants in an Online Session.
  • U.S. Appl. No. 13/918,809, filed Jun. 14, 2013, Shekar V. Dhupelia, Method for Ladder Ranking in a Game.
  • U.S. Appl. No. 15/672,113, filed Aug. 8, 2017, Mark L. Jacob, Systems and Methods for Seamless Host Migration.
  • U.S. Appl. No. 16/048,065, filed Jul. 27, 2018, Mark L. Jacob, Systems and Methods for Seamless Host Migration.
  • U.S. Appl. No. 13/918,809 Office Action dated Nov. 29, 2017.
  • U.S. Appl. No. 15/702,580 Final Office Action dated May 13, 2019.
  • U.S. Appl. No. 13/918,809 Office Action dated Jul. 12, 2019.
  • U.S. Appl. No. 16/048,065 Office Action dated Jun. 27, 2019.
  • U.S. Appl. No. 15/688,610, filed Aug. 28, 2017, Shekhar V. Dhupelia, Method for Ladder Ranking in a Game.
  • U.S. Appl. No. 15/688,656, filed Aug. 28, 2017, Shekhar V. Dhupelia, Method for Ladder Ranking in a Game.
  • U.S. Appl. No. 13/918,809 Office Action dated Apr. 3, 2020.
  • U.S. Appl. No. 15/688,610 Office Action dated Jan. 30, 2020.
  • PCT/US08/11415 International Preliminary Report on Patentability dated Apr. 7, 2010.
  • U.S. Appl. No. 15/688,610 Final Office Action dated Sep. 29, 2020.
  • U.S. Appl. No. 15/688,656 Final Office Action dated Oct. 14, 2020.
  • U.S. Appl. No. 16/773,589 Office Action dated Oct. 6, 2020.
  • U.S. Appl. No. 15/688,656 Office Action dated Apr. 27, 2021.
  • U.S. Appl. No. 16/773,589 Office Action dated May 4, 2021.
  • U.S. Appl. No. 15/702,580 Office Action dated Oct. 7, 2019.
  • U.S. Appl. No. 15/688,656 Office Action dated Apr. 20, 2020.
  • U.S. Appl. No. 13/918,809 Final Office Action dated Nov. 3, 2020.
  • U.S. Appl. No. 16/773,589, filed Jan. 27, 2020, Mark L. Jacob, Systems and Methods for Seamless Host Migration.
  • U.S. App. No. 16/878,437, filed May 19, 2020, Masayuki Chatani, Managing Participants in an Online Session.
  • Hanada, S. “The Design of Network Game and DirectPlay,” Inside Windows, Softbank K.K., vol. 4, No. 4, pp. 42-57, Apr. 1, 1998.
Patent History
Patent number: RE48700
Type: Grant
Filed: Aug 28, 2017
Date of Patent: Aug 24, 2021
Assignee: SONY INTERACTIVE ENTERTAINMENT AMERICA LLC (San Mateo, CA)
Inventors: Shekhar V. Dhupelia (San Diego, CA), Glen Van Datta (San Diego, CA), Brian Fernandes (San Diego, CA), Eiko Erika Kato (San Diego, CA), William McCarroll (San Diego, CA)
Primary Examiner: Cameron Saadat
Application Number: 15/688,592
Classifications
Current U.S. Class: Network Type (e.g., Computer Network, Etc.) (463/42)
International Classification: G06F 15/16 (20060101); A63F 13/352 (20140101); G06Q 40/00 (20120101); A63F 13/358 (20140101); A63F 13/71 (20140101); G06Q 10/02 (20120101); G06Q 20/10 (20120101); H04L 29/08 (20060101); H04L 29/06 (20060101); A63F 13/335 (20140101);