U.S. Pat. No. 8,795,088

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Some embodiments of the present invention will be described hereinafter with reference to the drawings, if necessary.FIG. 1is a block diagram schematically illustrating the architecture of a game system according to an embodiment of the present invention. As illustrated inFIG. 1, in an embodiment of the present disclosure, an online gaming server device10(hereinafter also referred to simply as the “server device10”) is connected to a plurality of terminal devices30-1,30-2, . . . , and30-N (hereinafter also collectively referred to as the “terminal devices30” or each individually as the “terminal device30”), each having a communication function, via a communication network20such as the Internet so that the server device10can communicate with the terminal devices30.

As illustrated inFIG. 1, the server device10includes a central processing unit (CPU)11, a main memory12, a user interface (I/F)13, a communication I/F14, an external memory15, and a disk drive16, and these components are electrically connected to one another via a bus17. The CPU11loads an operating system and various programs for controlling the progress of an online game into the main memory12from the external memory15, and executes commands included in the loaded programs. The main memory12is used to store a program to be executed by the CPU11, and is formed of, for example, a dynamic random access memory (DRAM).

The user I/F13includes, for example, an information input device including a keyboard, a mouse, and the like through which an operator enters an input, and an information output device including a liquid crystal display and the like through which calculation results of the CPU11are output. The communication I/F14is implemented as hardware, firmware, or communication software such as a transmission control protocol/Internet protocol (TCP/IP) driver or a point-to-point protocol (PPP) driver, or a combination thereof, and is configured to be able to communicate with the terminal devices30via the communication network20.

The external memory15is formed of, for example, a magnetic disk drive, and stores various programs such as a game program for allowing the terminal device30to execute an online game and a control program for controlling the progress of the online game. The game program is created using, for example, Adobe Flash (registered trademark), which is a format developed by Adobe Systems Incorporated to handle moving images, games, and the like. The game program created using Adobe Flash (registered trademark) is stored in the external memory15as a small web format (SWF) file. The game program will be described below. The disk drive16reads data stored in a storage medium such as a compact disc read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM), or DVD Recordable (DVD-R) disc, or writes data to such a storage medium. For example, data of a game program or the like stored in a storage medium is read by the disk drive16, and is installed into the external memory15.

The terminal device30may be any information processing device capable of executing a game program in the server device10, such as a mobile phone, a smartphone, a game console, a personal computer, a tablet, or an electronic book reader. The terminal device30has, for example, browser software for interpreting a hypertext markup language (HTML) file and displaying a screen, and plug-in software (e.g., Flash Player distributed by Adobe Systems Incorporated) incorporated in the browser software. The terminal device30acquires an SWF file embedded in an HTML file from the server device10, and executes the SWF file using the browser software and plug-in software, and therefore the user of the terminal device30, or a game player, may be provided with a gaming function.

The game program is stored in the server device10in various forms. For example, the game program may be provided as a piece of application software executable on various application execution platforms. The player is able to execute or operate a game application using the terminal device30.

FIG. 2is a block diagram illustrating the functionality of the server device10. The functionality of the server device10illustrated inFIG. 2is implemented by components of the server device10illustrated inFIG. 1. As illustrated inFIG. 2, the server device10may include a game program storage unit51, a group information management unit52, a play history storage unit53, an authentication unit54, a charging processing unit55, and a group information update unit56.

The game program storage unit51stores game programs for executing or operating various games executable or operable on the terminal device30. The game programs may be created using, for example, script languages such as ActionScript and JavaScript, both of which are registered trademarks, or object-oriented programming languages such as Objective-C and Java, both of which are registered trademarks. The game programs are executed or operated on a platform installed on the terminal device30. A game program to be stored in the game program storage unit51may be produced by modifying a web page created in a markup language such as HTML5 by using a style sheet such as Cascading Style Sheet 3 (CSS3). Such a web page created in a markup language is executed or operated by the browser software installed on the terminal device30. The game program storage unit51may store a desired number of game programs, and a game program for executing or operating a game selected by the terminal device30is provided to a desired number of terminal devices30via the communication I/F14in accordance with control of the CPU11.

The terminal device30may execute or operate the game program to play various games such as action games, role-playing games, baseball interactive games, and card games. The games implemented by the game program are not limited to those explicitly disclosed herein. When a game is executed, for example, animation or an operation icon designated by the program is displayed on a screen of the terminal device30. The player may enter an instruction for causing the game to progress using an input interface (e.g., a touch screen or a button) of the terminal device30. The instruction entered by the player is transmitted to the server device10through the browser of the terminal device30or a platform function such as NgCore (registered trademark). The terminal device30sends information indicating various parameters (such as the number of game points earned and information concerning obtained items), which is used in the game, and information indicating the status of the game (such as information specifying which mission has been fulfilled) to the server device10, if necessary. The game program storage unit51manages the progress of the individual players in the game in accordance with information received from the plurality of terminal devices30, such as instructions, information indicating the parameters, and information indicating the statuses. Thus, each player is able to resume the interrupted game from the point where it was interrupted, on the basis of the information concerning the progress of the game held in the server device10.

The group information management unit52divides, for each game program stored in the game program storage unit51(namely, each game), players registered in the game into a plurality of groups, and manages the associations between the players and the groups in accordance with the grouping of players in each group. For example, when one of the games implemented by the game program in the game program storage unit51is executed on the terminal device30for the first time, the user of the terminal device30may be registered as a player of the game, and the registered player may be included in one or a plurality of groups. Specifically, the group information management unit52may assign player identification information to a player who is registered as a player of a specific game in accordance with a predetermined rule, and store the player identification information in association with group identification information identifying a group in which the player is included.

In a specific game, players in the same group may cooperate to progress in the game. For example, in a game (e.g., a role-playing game) designed such that players progress in the game by defeating enemy characters, players in the same group may cooperate to attempt to battle against an enemy character. In an interactive game, players in the same group may cooperate to compete against an opposing group. The algorithm for determining victory or defeat with an enemy character may be defined in such a manner that, for example, parameters indicating the attributes of each player in a group who attempts to battle against the enemy character (which may be represented in various ways such as attack, defense, life, and stamina levels) are compared with parameters of the same type for the enemy character and the winning percentage of the player is higher than that of the enemy character when the attributes of the player are superior to those of the enemy character. In a case where a plurality of players in a group cooperate to compete against an enemy character, the determination of victory or defeat may be performed by, for example, comparing the sum of parameters representing the attributes of all the players in the group with the parameter representing the corresponding attribute of the enemy character.

The play history storage unit53may manage a play history of a player specified by the player identification information stored in the group information management unit52on a game-by-game basis. The play history storage unit53may store the play history in a play history information table in the external memory15. Examples of the play history include the number of logins made by the player to play the game, the total number of game points the player has earned in the game, the amount of money the user has spent on purchasing game items (i.e., the amount charged to the user), and the number of messages the user has sent to other users.FIG. 3illustrates an example of the play history information table. The play history is not limited to that explicitly disclosed herein or illustrated inFIG. 3, and may include arbitrary information concerning the activity of a specific player in a specific game (the degree to which the player is active in the game). The play history may be managed every predetermined period. For example, the number of logins made by a specific user may be managed at predetermined intervals such as daily, weekly, or monthly. The play history will be described in more detail below.

Upon access from the terminal device30to the server device10to play a specific game on the terminal device30, the authentication unit54authenticates the player who has made the access request. The access request may be automatically sent to the server device10, for example, when application software for the game is started on the terminal device30. If the game program is embedded in an HTML file and is provided, authentication processing may be performed in response to a request for obtaining the HTML file. The access request includes, for example, identification information or a password for identifying the player. The authentication unit54checks the authentication information and/or password included in the access request against authentication information and/or password registered in advance to authenticate the player. If authentication succeeds, the player is authorized to log in the game to play the game. The play history storage unit53may manage the number of times access was granted by the authentication unit54, as the number of logins which is an item of the play history.

The charging processing unit55determines the amount charged to the player, and manages the determined charged amount. For example, the charging processing unit55may receive a purchase request for so-called virtual items, such as virtual weapons and armor, from a player, and determine the amount charged to the player in accordance with the purchase request. The charging processing unit55may also charge a user for any service request given by the user as well as for the purchase of virtual items. The play history storage unit53may manage the charged amount determined by the charging processing unit55as an item of the play history.

The group information update unit56may change the association between player identification information and group identification information in the group information management unit52at least partially in accordance with the play history managed by the play history storage unit53. The group information update unit56may change an association between player identification information and group identification information on a specific player by, for example, making the specific player withdraw from a specific group, making the specific player join a specific group, ceasing the membership of the specific player in the specific group for a predetermined period of time, or limiting the involvement of the specific player in the progress of the game.

In an exemplary embodiment, the group information update unit56may refer to the play history in the play history storage unit53, specify a non-active player having a low activity in a specific game, exclude the non-active player from the current group in which the non-active player is currently included, and associate the player identification information on the non-active player with group identification information on other groups. For example, group identification information on a group including only the non-active player as a constituent member is newly created, and player identification information on the non-active player is associated with the group identification information. In an embodiment, a non-active player is a player whose membership in the current group ceases for a predetermined period of time. For example, if the current group has a vacant position after the predetermined period of time has elapsed (or if the number of members included in the group has not reached the upper limit), the non-active player may be returned to the group.

The group information update unit56may determine that, for example, a player who logs in three times or less for a predetermined period of time (e.g., one week) is a non-active user. In another embodiment, the group information update unit56may determine that a player who is not charged for a predetermined period (e.g., one month) is a non-active player.

In another exemplary embodiment, the group information update unit56may specify an active player having a high activity and preferentially keep the active player in the current group while excluding a player having a relatively low activity from the current group. For example, players may be kept in the current group preferentially in order from the player who has logged in the largest number of times for the predetermined period, and a player who has logged in a relatively small number of times may be excluded. Further, a player who has logged in a larger number of times than the excluded player among players included in any other group or among players who are not included in any groups may be joined in the current group. Similarly, a player charged a large amount may be preferentially kept in the current group, and a player charged a relatively small amount may be excluded from the current group. Accordingly, a player who is more active in the play may be left in the current group. This may encourage individual players to be more active in the game.

In still another exemplary embodiment, for example, the group information update unit56may specify an active player having a high activity in a game on the basis of one or more criteria. Examples of the criteria include the amount of money the player has in the game, the number of battles fought by the player in the game (the number of wins, the number of losses), the number of times a mission in the game has been completed by the player, the number of friends of the player in the game, the number of items the player possesses in the game, the level of the player, attack and/or defense level, and the number of comments posted by the player in the game. The parameters given above may be stored in the play history storage unit53as items of the play history. In this manner, a player having a high activity in a game may be preferentially kept in the current group under control of the group information update unit56. Conversely, a player having a relatively low activity in the game may be excluded from the current group. Accordingly, the degree to which a player is active is evaluated in terms of the content of the play of the game rather than in terms of utilization of the game system, such as the number of logins and the charged amount. A player having a high activity in the game may be kept in the current group. Accordingly, a player who is more active in a game may be left in the current group. This may encourage individual players to be more active in the game even after the game is initiated, rather than to merely participate in the game.

The change of an association between player identification information and group identification information by the group information update unit56will be described with reference toFIGS. 4A to 4Cand5A to5C.FIGS. 4A to 4Care schematic diagrams illustrating the change of an association between player identification information and group identification information according to an embodiment of the present disclosure.FIGS. 5A to 5Cillustrate an example configuration of a group identification information management table that manages an association between player identification information and group identification information. The group identification information management table is stored in, for example, the external memory15. As illustrated inFIG. 4A, in an exemplary embodiment, players A, B, and C are initially included in groups1,2, and3, respectively, as the sole constituent members immediately after a predetermined game program has been downloaded for the first time. In this case, as illustrated inFIG. 5A, the group information management unit52stores player identification information “000001” identifying the player A in association with group identification information “100001” identifying the group1, player identification information “000002” identifying the player B in association with group identification information “100002” identifying the group2, and player identification information “000003” identifying the player C in association with group identification information “100003” identifying the group3.

Then, as illustrated inFIG. 4B, for example, the player A invites the player B and the player C to the group1. The player B and the player C accept the invitation, so that the player B and the player C in addition to the player A can be included in the group1as constituent members. In order to reflect the change in the grouping of the group, as illustrated inFIG. 5B, the group information management unit52stores the three pieces of player identification information respectively identifying the players A, B, and C in association with the group identification information “100001” identifying the group1. The re-grouping described above may be automatically performed using a matching module (not illustrated) in the server device10. The matching module may be configured to match players against each other in accordance with a predetermined algorithm based on, for example, various attributes of the players (e.g., level, sex, age, etc.).

The group information update unit56may periodically monitor the play history of players, and specify a non-active player. For example, if it is determined that the player C is a non-active player, as illustrated inFIG. 4C, the player C may be excluded from the group1. In this case, as illustrated inFIG. 5C, the group information update unit56stores the group identification information identifying the group1in association with the pieces of player identification information respectively identifying the player A and the player B, and stores the player identification information on the player C in association with group identification information “100004” identifying a group4different from the group1. Accordingly, the player C is excluded from the group1. Thereafter, the player A may invite another player (e.g., a player D (not illustrated)) to the group1.

As described above, according to an embodiment of the present disclosure, a non-active player who is not active in a game may be excluded from the group in which the non-active player is currently included, in accordance with the play history of each individual player stored in the play history storage unit53. In particular, a player with a small number of accesses to the game or with a low frequency of purchase of virtual items may be specified as a non-active player. If there is an upper limit set for the number of players included in a group, the position that is vacant because the non-active player has been excluded may be filled with a new player, and the new player may cooperate with the other players to progress in the game. An online gaming server device according to an embodiment of the present disclosure may change the grouping of players included in a group in accordance with the states of the play of the players, thereby dynamically changing the grouping of players in a cooperative relationship with each other in accordance with the progress of a game.

Next, an example in which a plurality of groups are combined to create a new group will be described with reference toFIGS. 6A,6B,7A, and7B. A more extensive set of players, which is created by combining a plurality of groups, is herein sometimes referred to as meta-group, and information identifying the meta-group is herein sometimes referred to as meta-group identification information.FIGS. 6A and 6Bare schematic diagrams of a combination of groups, andFIGS. 7A and 7Billustrate an example configuration of a meta-group identification information management table that manages player identification information, group identification information, and meta-group identification information. The meta-group identification information management table is stored in, for example, the external memory15. As illustrated inFIG. 6A, three players, namely, players A, B, and C, are included in a group1, and two players, namely, players D and E, are included in a group2. As illustrated inFIG. 7A, the group information management unit52stores group identification information on the groups1and2in association with player identification information on each of the players included in each group.

In an embodiment, the group1and the group2may be combined. For example, as illustrated inFIG. 6B, the group1and the group2may be combined to generate meta-group1including all the players included in the group1and all the players included in the group2. Thus, all the players included in the meta-group1may cooperate to progress in the game. For instance, all the players included in the meta-group may battle against an enemy character using the sum of parameters of all the players.

When the meta-group1is to be generated, as illustrated inFIG. 7B, the group information management unit52may store meta-group identification information “200001” identifying the meta-group1in association with player identification information on each of the players included in the meta-group1under control of, for example, a meta-group identification information generation unit (not illustrated). In this case, the players included in the meta-group1are included in the original groups in which the individual players are initially included, and are also included in a meta-group including the original groups. For example, after the group1and the group2are combined into the meta-group1, the player A is included in the group1and is also included in the meta-group1. The player identification information identifying the player A is stored in the group information management unit52in association with both the group identification information identifying the group1and the meta-group identification information identifying the meta-group1.

The meta-group identification information generation unit may periodically refer to the play history of members constituting each group to determine the total activity of the group in accordance with the play history of the members, and specify an active group and a non-active group. For example, it is determined whether each group is an active group or a non-active group, based on the sum of the numbers of logins made by the respective members constituting the group or the sum of the charged amounts determined by the charging processing unit55. For example, inFIG. 6A, it may be determined that the group1is an active group and the group2is a non-active group. In this case, as illustrated inFIG. 6B, the group1and the group2may be formed into the single meta-group1. In this way, in the progress of a game, an active group and a non-active group may be combined so that a group having a high activity leads a group having a low activity to progress in the game. In another embodiment, active groups may be combined to generate a meta-group or non-active groups may be combined to generate a meta-group.

Two groups may be combined automatically (without the operation of the player) when a predetermined condition is satisfied (such as when the game has proceeded to a predetermined stage or when a predetermined period of time has elapsed since the game was initiated). In addition, two groups may be combined by the following procedure: A player included in one group (e.g., the player A in the group1) asks at least one of players included in another group (e.g., the players D and E in the group2) if both groups are combined. If the asked player agrees, the two groups are combined. The number of groups to be combined is not limited to two, and, for example, more than two groups may be combined.

As described above, individual players included in the meta-group1are included in the original groups in which the individual players are initially included, and are also included in a meta-group including the original groups. Thus, as in the embodiment described with reference toFIG. 3, a non-active player who is not active in the game among the players included in the meta-group1may be excluded from the group in which the non-active player is included, in accordance with the play history of the individual players stored in the play history storage unit53. As described above, a player with a small number of accesses to the game or with a low frequency of purchase of virtual items may be specified as a non-active player. Thus, if there is an upper limit set for the number of players included in a group, the position that is vacant because the non-active player has been excluded may be filled with a new player, and the new player may cooperate with the other players to progress in the game.

In an embodiment, a group selected from one or a plurality of groups constituting a meta-group may be excluded from the meta-group. For example, in a meta-group including two active groups, a less active group having a larger number of players who are not active in the game may be excluded from this meta-group. The less active group including a larger number of players with a small number of accesses to the game or with a low frequency of purchase of virtual items may particularly be specified as a non-active group. Thus, if there is an upper limit set for the number of members of a meta-group, the position that is vacant because the non-active group has been excluded may be filled with a new group, and the new group may cooperate with the other groups to progress in the game.

Accordingly, in an embodiment of the present disclosure, groups may be combined to generate a meta-group, and thus the players included in the meta-group may cooperate to progress in a game. Therefore, in an embodiment of the present disclosure, groups may be combined to dynamically change the grouping of players in a cooperative relationship with each other in accordance with the progress of a game.

The processes and procedures described and illustrated herein are implemented by software, hardware, or any combination thereof, as well as that explicitly stated in the embodiments. More specifically, the processes and procedures described and illustrated herein are implemented by the installation of the logic corresponding to the processes into a medium such as an integrated circuit, a volatile memory, a non-volatile memory, a magnetic disk, or an optical storage. The processes and procedures described and illustrated herein may also be installed in the form of a computer program, and executed by various computers.

If the processes and procedures has been described and illustrated herein to be executed by a single device, software, component, or module, such processes or procedures may also be executed by a plurality of devices, a plurality of pieces of software, a plurality of components, and/or a plurality of modules. The data, table, or database described and illustrated herein to be stored in a single memory may also be distributed to and stored in a plurality of memories included in a single device or a plurality of memories which are located in a plurality of devices in a distributed manner. Furthermore, the software and hardware elements described and illustrated herein may also be integrated into a smaller number of constituent elements or separated into a larger number of constituent elements.