U.S. Pat. No. 8,821,279

DETAILED DESCRIPTION OF EMBODIMENTS

Further features of the disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings.

An embodiment for implementing the present disclosure (hereinafter referred to as the present embodiment) will now be described with reference to specific examples. The present embodiment relates to a game system that provides a game to a terminal connected to a game server via a communication network. Specifically, as shown inFIG. 1, a game system G of the present embodiment includes a game server1that provides a game to a user who is operating a terminal, and terminals3a,3b,3c, . . . ,3n(hereinafter, collectively referred to as a terminal3) connected to the game server1via a communication network such as the Internet2.

In the following description, prior to describing the embodiment, the definitions of terms used in the present embodiment will be clarified. Then, a general outline of a social game concerning the present embodiment will be described, and thereafter, a configuration of the game system G and a process performed by the game system G will be described in detail.

(1) Definitions Of Terms

The definitions of terms used in the present embodiment are as follows.

“Virtual space” means a virtual world that is created during a game based on content of the game and refers to a space different from a physical space. The “virtual space” shown on a display (a display section) of the terminal3is two-dimensional. However, a conceptual space created by executing a program in the server1via a communication network with connections to another terminal3is not limited to a two-dimensional space.

“Physical user” means an entity operating a terminal, i.e., a person. “Virtual user” means a virtual entity representing the physical user in the virtual space in accordance with a button operation or a touch operation on the terminal of the physical user, or a virtual entity which is created based on a taste or preference of the physical user. The “virtual user” includes, for example, a virtual entity like a player in conventional shogi games or mahjong games that is not visible in the game and operates pieces or tiles in the virtual space as an existence representing the “physical user”. The “virtual user” also includes a particular visible character that is displayed in the game such as a role playing game or a player-versus-opponent game and that moves or performs an action. Further, the “virtual user” includes a virtual entity displayed as an avatar in a SNS. Accordingly, the “virtual user” in the present embodiment is used as a term that broadly represents the virtual entity in the virtual space, regardless of whether it is a virtual entity which is embodied in a game or a virtual entity which is not embodied.

“Two-dimensional map” means a map that is presented on a plane shown on a display (a display section) of the terminal3, and expresses a plurality of positions located on a plane in the virtual space and a route connecting the positions under a certain rule. “Virtual position” means a position, in the virtual space, on a plane located in such a manner that the virtual user is reachable.

“Point” means a point granted to the virtual user in the virtual space and allows a target game part to progress when the virtual user consumes the point in the virtual space. “Operation data that requests progress of a game part related to a virtual user” means operation data that requests that the point granted to the virtual user be used and that a target game part progress depending on the point consumed by being used. “Received content of operation data” means, for example, the number of times operation data is received, an instruction represented by the operation data, and a decision represented by the operation data.

(2) General Outline Of Social Game

Next, a general outline of a social game provided from the game server1to the terminal3connected via the Internet2will be described with reference toFIG. 2.

Generally, a social game is a game played in a virtual space by a virtual user performing an action in response to an operation of the terminal3by the physical user. A type of the social game is a game in which a set of a predetermined number of cards (hereinafter, referred to as a card deck) is created from among various kinds of, e.g., several hundreds of kinds of, virtual cards (hereinafter, simply referred to as cards) each having a character displayed thereon. More specifically, the user collects and strengthens the cards by battling against enemies appearing in the virtual space using the cards or by trading the cards with another virtual user, while upgrading a level and selecting an attribute of the card in the card deck. In a battle using the cards, a damage to an enemy or a result of the battle is determined based on the level of offensive and defensive powers of each card constituting the card deck, a skill (corresponding to a “meld” as used in a card game or mahjong) with which a certain effect can be obtained by a predetermined combination of cards, and so on.

This type of social game is established as a single game and as a whole with a plurality of parts being combined organically to complete a single story or a character. For example, as shown inFIG. 2, a social game20includes a quest part21, a combination part22, a battle part23, a gacha-part24and a trade part25, and each part serves as a game element.

As represented by the term “quest”, which means “to search, to explore and to have an adventure” or the like, the quest part21is a part constituting a game in which a virtual user travels throughout in a virtual space, battles against enemies that appear during the travel, obtains a new card, and improves the level of the virtual user. In the quest part21, the virtual user is given a predetermined number of quest points, and actions such as a movement of the virtual user, an obtainment of an item, an improvement of the level, and so on, are accomplished by consuming the quest point. In the quest part21, the virtual user battles against an enemy that has appeared by using the possessed cards and consuming a battle point.

The combination part22is a part in which cards possessed by the virtual user are combined to increase the card level representing the strength of the cards, so as to increase an offensive power for damaging enemies and/or a defensive power for defending from enemies during a battle.

The battle part23is a part in which the cards possessed by the virtual user are used to battle against another virtual user. A win or a loss is determined based on the offensive power and the defensive power of each of the cards described above.

The gacha part24is a part named after “gacha-gacha,” which is an imitative word expressing the sound and manner in which a capsule toy, which is a toy enclosed in a capsule, is ejected from a toy vending machine after a coin is inserted into the machine. In the gacha part24, the virtual user obtains a card randomly based on an occurrence rate of each card by using, for example, a gacha point or gacha authorization that is virtually provided instead of a coin.

The trade part25is a part via which the virtual user exchanges the cards in possession with another virtual user. Each virtual user adds advantageous cards obtained via the trade part25into a card deck to strengthen the card deck as a whole by increasing the level of offensive power for damaging an enemy and/or the defensive power for defending against attack from an enemy.

The social game20consisting of the plurality of parts described above has been meaningful as an entire game because none of the game parts is independent from the other, in other words, each of the game parts is related and combined with the other. Therefore, with the social game20, an entire game can be progressed by making progress in each of the game parts.

(3) Basic Hardware Configuration

(3-1) Configuration of Terminal

Hereinafter, a hardware configuration for obtaining a game system G of the present embodiment will be described based on the definition of the social game20described above.

As shown inFIG. 1, the terminal3may be a portable wireless communication terminal such as a smartphone, and may include, for example, a wireless communication section31, a display section32that may be of a liquid crystal display type, and an operation input section33for operating the terminal with a touch input or a key input. The terminal3is connected to the Internet2by a wireless communication section31through a mobile telephone line or a wireless LAN circuit and performs data communication with the game server1by using a web browser. Further, the terminal3displays a web browser screen on the operation input section32, which is usually a touch screen, and inputs a user operation such as a selection operation by touching the screen.

With the terminal3having such a hardware configuration, for example, an individual authentication process of the terminal is performed using a combination of a pre-registered user ID and a predetermined password. When the authentication between the terminal3and the game server1is completed, the terminal3receives data necessary for progression of a game from the game server1and transmits operation data inputted though the operation input section32to the game server1as described below.

The terminal3can be a mobile telephone, a PDA or a personal computer as long as it is a communication device capable of communicating with the game server1via a communication network such as the Internet2. The operation input section32has been described using a touch panel as an example, but may be of a configuration in which information is inputted through performing a selection operation by moving a cursor with a physical key operation.

(3-2) Schematic Configuration of Game Server

The game server1to be connected to the terminal3is embodied as a computer having a general-purpose hardware configuration as shown inFIG. 3, for example. That is to say, as shown inFIG. 3, the game server1includes a communication interface section11that establishes communications with the terminal3via the Internet2, and an operation input unit12such as a keyboard or a mouse that allows an operation input from a physical user. Further, the game server1is provided with an arithmetic processing section13such as a CPU that executes various arithmetic processing, a main memory14such as an SRAM or a DRAM that temporarily stores arithmetic processing data, a storage unit15such as a hard disk in which application programs and various data are stored, and a display16that displays an outcome of the arithmetic process.

In the game server1, by installing a program in the storage unit15for offering such social game20to a physical user, function blocks as shown inFIG. 4are obtained.

That is to say, the game server1comprises, for example, as shown inFIG. 4, a game data processing section100that is comprised of a quest part processing section101, a combination part processing section102, a battle part processing section103and a gacha part processing section104as well as a game data storing section200that manages game data thus realizing the functions of the abovementioned sections.

Here, the quest part processing section101executes data processing for the quest part21. The combination part processing section102executes data processing for the combination part22. The battle part processing section103executes data processing for the battle part23. The gacha part processing section104executes data processing for the gacha part24. The trade part processing section105executes data processing for the trade part25.

(3-3) Specific Configuration of Game Server

Now, among the parts processed by this type of game server1, a specific configuration and process details for achieving the quest part21will be described with reference toFIG. 5.

(3-3-1) Configuration of Game Data Storing Section

Data to be used in the quest part21is stored in the game data storing section200. As shown inFIG. 5, in the game data storing section200, a virtual space information storing section201, a map data storing section202, a virtual position data table203, an attribute data table204and a quest display image table205are stored.

The virtual space information storing section201obtains information regarding a virtual position where the virtual user can exist, i.e., a node arranged on a plane, as coordinate position information on the plane and stores this as virtual space information.

An image of the virtual space constituting the entire quest part is shown inFIGS. 6A and 6B. The virtual space information is information for specifying a virtual position where the virtual user exists or a virtual position reachable by the virtual user by consuming a quest point as shown inFIGS. 6A and 6B.

More specifically, as shown inFIG. 6A, the quest part21is constituted by two-dimensional planes configured as a plurality of layers (F(1)-F(n)), and the virtual space is formed by the entirety of the layers. In the present embodiment, a single closed region in one of the layers forming the virtual space is referred to as a “field”. That is to say, the virtual space is constituted by fields F(0), F(1), . . . F(n) as shown inFIG. 6A.

Field F(i), where “i” is any number in the range of 0 to n, and has an entire region that is divided into a matrix of a plurality of blocks (here, divided into squares where each side has a virtual length of “1” unit). For example, as shown inFIG. 6B, Field F(i) is constituted by 16 rectangular blocks that are arranged into a matrix, 4 blocks vertically (x) by 4 blocks horizontally (y). Further, Field F(i) is each provided with a stage St (a, b) at each of the center of blocks specified by the coordinates (a, b) in a two-dimensional Cartesian coordinate system.

This Field F(i) is connected by a map creating section40in such a manner that the respective stages are connected via a route (link) to be described below. That is to say, an end position Fend can be reached by starting from a start position Fstart and passing through a predetermined stage via a route. In this case, as shown inFIG. 6B, it is acceptable to have a block on which the stage St (a, b) is not located.

The virtual space information storing section201stores, for each Field F(i), position coordinate information regarding the stage St (a, b) which is node information constituting Field F(i), which serves as information for establishing such a virtual space.

The map data storing section202stores map data including node and link information. The nodes associated with each stage stored in the virtual space information storing section201are connected by a route (link) by the map creating section40described later. For example, in order to constitute Field F(1) of the first layer as shown inFIG. 7A, the map data storing section202stores map data350, as shown in a table ofFIG. 7B, which includes node information representing a stage number, node information to be connected by a link represented by a reachable stage information, and event data generated in the stages.

More specifically, as shown inFIG. 7B, the map data350contains node information related to a total of fourteen stage positions which are arranged two-dimensionally in Field F(1) as virtual positions and link information indicating a connection relationship between the stages. In the map data350represented by the table inFIG. 7B, Reachable Stage “St (2, 1) (15)” for Stage Number “St (1, 1)” indicates that a stage St (2, 1) can be reached from the stage St (1, 1) by consuming “15” quest points, which will be described below. Similarly, Reachable Stage “St (2, 3) (20)” for Stage Number “St (2, 2)” indicates that the stage St (2, 3) can be reached from the stage St (2, 2) by consuming “20” quest points, and Reachable Stage St “St (3, 2) (15)” indicates that the stage St (3, 2) can be reached from the stage St (2, 2) by consuming “15”quest points. The map data storing section201stores the map data350containing such information in each and every field.

In the above description, “stage” is an example of a virtual position. When the virtual user reaches a stage, the virtual user obtains either an item or a card or battles with an enemy that has appeared. “Field” is a planar virtual space having a plurality of such “stages” arranged therein. The entire quest part is constituted by a plurality of such fields, each having a plurality of stages arranged therein, provided in a layered structure. The terms “stage” and “field” used herein are merely distinguished for the sake of convenience. For example, depending on a story in a game, the term “field” may be used for a position where the virtual user can exist in the virtual space and the term “stage” may be used for a single closed virtual space where the “field” is located, which is opposite to the definition of the present embodiment.

The virtual position data table203(seeFIG. 5) stores identification data of a virtual user existing at each stage in each field F(i), as shown inFIG. 8, for example. The virtual position data table202is, for example, used for understanding the quantity of the virtual users and identity of each virtual user existing at each stage. Specifically, as identification data, the virtual position data table203stores an ID number which identifies a virtual user that exists at each stage such as information indicating that virtual users with an ID number of “11134” and “14375” exist at stage St (2, 2) in Field F(1).

The attribute data table204(seeFIG. 5) contains attribute information on virtual users existing in the virtual space for each virtual user. For example, as shown inFIG. 9, the attribute data table204contains position information, level information, quest point information, battle point information, gacha point information and obtained card list information as attribute information for each virtual user.

In the attribute data table204, “Position Information” indicates coordinates of a virtual position where a virtual user exists. For example, Position Information “F(1) St (2, 2)” indicates that a virtual user exists at stage St (2, 2) in Field F(1) shown inFIG. 7A. “Level Information” is a numerical value representing a level of strength of a virtual user in the game. When the game starts from level 1, this numerical value increases with the progress of the game to, for example, Level 2 and Level 3. For example, Level Information “L6”indicates that the level of the virtual user is at a sixth level. In the present embodiment, as a specific example of upper and lower limits of the level, the lowest level is Level 1 and the highest level is Level 90.

Concerning this level, a single level is given in the entire game, rather than giving a unique level for the quest part, which is only one part of the game. Also, depending on the game, it may not be necessary to have a concept of a level for the virtual user.

“Quest Point” information indicates the number of points consumed as a cost in the quest part21when the virtual user moves between the stages while traveling throughout in the virtual space. “Battle Point” information indicates the number of points consumed as a cost when a virtual user battles against another virtual user in the battle part23, or when attacking an enemy that has appeared when traveling throughout in the virtual space in the quest part21. “Gacha Point” information indicates a point consumed as a cost when the virtual user obtains an item via gacha lot in the gacha part24. “Obtained Card List” information indicates a list of cards obtained by the virtual user.

The quest display image table205(seeFIG. 5) contains data for displaying an image of the map on the terminal3connected via the Internet2. Specifically, as has been described with reference toFIG. 7, when the virtual user exists at the stage St (2, 2) in Field F(1), to present an image400of a displayable area shown in the display section32of the terminal3as shown inFIG. 10, the quest display image table205contains display image data described below.

That is to say, the quest display image table205contains data for displaying a stage display image411(a black dot inFIG. 10) that indicates a stage where the virtual user actually exists, e.g., the stage St (2, 2), and data for displaying a stage display image412(a white dot inFIG. 10) that indicates a stage around the stage St (2, 2). The quest display image table205also contains data for displaying an already-passed-through-route display image421that indicates a route (shown by a solid line inFIG. 10) between the already-reached stages and data for displaying a not-passed-through-route display image422that indicates a route (shown by a broken line inFIG. 10) between the unreached stages and between the unreached stage and the reached stage.

Further, the quest display image table205contains data for displaying a virtual user display image431(a white square inFIGS. 10) and 432(a white triangle inFIG. 10) that allows determination of whether or not another virtual user in each stage is an ally.

(3-3-2) Configuration of Quest Part Processing Section

The specific configuration of the quest part processing section101will now be described. As shown inFIG. 5explained above, the quest part processing section101includes the map creating section40, a quest image transmitting section41, an operation data receiving section42, a virtual position changing section43, a data table updating section44, a destination selection data transmitting section45and an event generating section46.

The map creating section40generates two-dimensional map information from the virtual space information stored in the virtual space information storing section201and creates a two-dimensional map by connecting a route between the stages located on Field F(1). Specifically, the map creating section40is provided with a piece storing section40ain which a plurality of kinds of pieces are stored.

Pieces stored in the piece storing section40aare of the same shape as the blocks obtained by dividing Field F(1) and serve as connecting pieces that connect the route from one edge of the block to at least one of the other edges of the block. For example, as shown inFIG. 11, six types of pieces are used.

In other words, connecting pieces401,402are pieces that connect a route from one edge of the block to at least one of the other edges of the block via the center part of the block. A connecting piece403is a connecting piece that connects a route from one edge of the block to two of other edges of the block, respectively, via the center part of the block. A connecting piece404is a piece that connects a route from one edge of the block to three other edges of the block, respectively, via the center part of the block.

The piece storing section40acontains a connecting piece405that connects a route from the center part of the block to an edge of the block to create a route to a stage terminated, and a connecting piece406that does not have a route in order to represent a block on which a stage does not exist.

By rotating the plurality of kinds of connecting pieces described above 90 degrees, 180 degrees or 270 degrees, and combining them, the map creating section40creates a two-dimensional map having a configuration of Field F(1) shown inFIG. 7A.

It is particularly preferable that the connecting piece has the same shape as the rectangular block that divides the field equally in a matrix form, since the stages can be easily divided and connected when creating a two-dimensional map. However, the shape of the connecting piece is not limited thereto. That is to say, the connecting piece may be any polygon such as a triangle or a hexagon that divides the field and that connects a route from one edge of the polygon to at least one of the other edges of the polygon.

The quest image transmitting section41transmits data for displaying an image of a map to at least one terminal3connected via the Internet2based on data stored in the game data storing section200.

Specifically, the quest image transmitting section41sets a displayable region that is a region that can be displayed on the terminal3. Thereafter, the quest image transmitting section41retrieves, from the quest display image table204, the image display data for constituting an image of the displayable region thus set. Then, the quest image transmitting section41combines the retrieved display image data and transmits, to the terminal3, the aforementioned display processing data for displaying an image shown inFIG. 10. Also, the display process data transmitted by the quest image transmitting section41is not limited to image data, but may also be display control data for controlling the display of the image data stored on the terminal3side.

The operation data receiving section42receives operation data from at least one terminal3. The operation data representing, for example, an operation that requires progress in the quest part. Specifically, the operation data receiving section42receives operation data indicating that a quest point is used for moving between the stages and operation data indicating that a battle point is used for battling against an enemy that has appeared.

The virtual position changing section43has a consumption point calculating section43aand a reached state determination section43bfor changing the stage where each virtual user exists based on the received operation data indicating that a quest point that is consumed by the operation data receiving section42is used.

The consumption point calculating section43acalculates accumulated quest points consumed depending on the content of the received operation data. Specifically, the consumption point calculating section43acalculates accumulated quest points consumed depending on the number of times the operation data is received. The reached state determining section43bdetermines whether the virtual user to be operated or processed (hereinafter also referred to as a target virtual user) has reached a destination virtual position based on the accumulated quest points. Although in the present embodiment, the number of times the operation data is received is used as a specific example of the content of the operation data received, an instruction represented by the operation data or a decision indicated by the operation data may be used instead.

The data table updating section44updates identification data in the virtual position data table202when the stage where each virtual user exists is changed by the virtual position changing section43.

The destination selection data transmitting section45transmits, to the terminal3, data related to options for selecting a destination stage.

The event generating section50generates an event to lead the virtual user to a certain route. The event generating section50has a stage selecting section51and a generation processing section52for generating an event for a stage.

The stage selecting section51arbitrarily selects a stage, from the stages arranged on the map, where a virtual event, which is an opportunity for obtaining a card or an item, is generated and notifies the event generating section52of the selected stage.

The stage selecting section51, for example, is configured in such a manner that a stage that contains a so-called detour route containing more numbers of virtual positions on the route is selected on a map in which a plurality of (e.g., two) stages are reachable from the stage where the virtual user currently exists and in which one of the stages is on a “short cut” that has no other stages between the current stage and the reachable target stage, whereas the other stage is on a “detour” that has at least one more stage before the target stage.

The stage selecting section51may also be configured in such a manner that an unreached stage described later that a virtual user has not reached is selected preferentially. For example, when Stages St (1, 4) and St (2, 4) are unreached stages, these two Stages St (1, 4) and St (2, 4) are selected as stages where an event is generated preferentially as compared to other stages.

The generation processing section52is a section that causes an event that leads the virtual user to a certain route to be generated at a stage selected by the stage selecting section51. For example, when Stages St (1, 1) and St (3, 1) are selected by the stage selecting section51, events are generated as follows: when a virtual user has reached the stage St (1, 1), the generation processing section52generates an event that provides a “quest point recovery item” with which the quest points can be recovered; when a virtual user reaches the stage St (3, 1), the generation processing section52generates an event that provides a “battle point recovery item” with which the battle points can be recovered. Data indicating the content of the event generated in each stage by the generation processing section52is, for example, stored in the map data350shown inFIG. 7Bexplained above as event data associated with the stage number. Based on the event data stored in the map data350, the quest image transmitting section41transmits, to the terminal3, display process data to cause an announcement of an event to be displayed.

(4) Process In Game Server

(4-1) Process of Quest Part Processing Section of First Embodiment

A process related to a first embodiment of the quest part processing section101having the aforementioned configuration will be described with reference toFIG. 12.

In step S1201, the quest part processing section101creates a two-dimensional map with the map creating section40by combining a total of six types of the connecting pieces401-406shown inFIG. 11for a field on which a virtual user to be a target of the process (hereinafter also referred to as a target virtual user) exists (hereinafter also referred to as a target field), and the process of the game server proceeds to step S1202.

In step S1202, the quest part processing section101generates an event for a stage constituting a target field with the event generating section50, which will be described in detail below, and the process of the game server proceeds to step S1203.

In step S1203, the quest part processing section101changes the existing position of the target virtual user in the target field, which will be described in detail below, and the process of the game server proceeds to step S1204.

In step S1204, the quest part processing section101determines whether the target virtual user has moved between the fields or not, or whether a predetermined period of time, such as 24 hours, has elapsed or not. When one of the conditions is satisfied (S1204: YES), the process of the game server proceeds to step S1205, and when neither condition is satisfied (S1204: NO), the process of the game server returns to step S1203.

In step S1205, the quest part processing section101confirms whether or not a termination of the process has been accepted. For example, when there is an operation wherein an administrator managing the game server1changes the configuration of the field as in maintenance work, a termination instruction of the process from the administrator is accepted. When termination of the process is accepted (S1205: YES), the present process is terminated. When there is no instruction for termination of the process (S1205: NO), the process of the game server returns to step S1201.

(4-1-1) Process of Creating a Two-Dimensional Map (Step S1201)

As a specific process of step S1201, a process of creating a two-dimensional map with the map creating section40in accordance with a flowchart shown inFIG. 13will be described.

The present process is based on the assumption that the map creating section40creates a two-dimensional map by combining the connecting pieces401-406of a total of six types shown inFIG. 11described above. Also, in the present process, each field is constituted by blocks that are arranged into a matrix, 4 blocks vertically (x) by 4 blocks horizontally (y). The position where each stage is located is specified with coordinates (a, b) of a two-dimensional orthogonal coordinate system.

In step S1301, the map creating section40determines whether a target virtual user has moved between the fields, and if it has moved (S1301: YES), the process of the game server proceeds to step S1302, and if it has not moved (S1301: NO), the process of the game server proceeds to step S1304.

In step S1302, the map creating section40determines whether or not a difference in the number of virtual users between the stages constituting the target field is greater than or equal to a predetermined number. Specifically, it is determined whether or not there is any stage in which the difference in the number of virtual users with respect to the stage having the smallest number of virtual users is greater than or equal to a predetermined number (hereinafter referred to as a congested stage). When the difference in the number of virtual users is greater than or equal to the predetermined number (S1302: YES), the process of the game server proceeds to step S1303, and when the difference in the number of virtual users is less than the predetermined number (S1302: NO), the process of the game server proceeds to step S1304.

In step S1302, the difference in the number of virtual users between the stages is used as an example of an evaluating index for evaluating unevenness of distribution of the virtual users between the stages. For example, unevenness of distribution of the virtual users between the stages may be evaluated using other evaluation indices such as a standard deviation or a variance. In such a case, for example, a stage having a deviation greater than or equal to a predetermined value may be determined as a “congested stage”, and the program proceed to step S1303.

In step S1303, in order to mitigate further concentration of virtual users in the congested stage, a stage other than the congested stage is set as a candidate for the shortest route from the start position Fstart to the end position Fend, and the process of the game server proceeds to step S1304.

In step S1304, the map creating section40sets the total number of stages to “the shortest route” depending on the level of the target virtual user, and the process of the game server proceeds to step S1305. Specifically, the map creating section40sets the total number of stages on “the shortest route” to increase as the level of the target user becomes higher. In this manner, by adjusting the difficulty of completing the target field depending on the level, the map creating section40can provide an environment in which a wide range of players from beginners to advanced level players can enjoy the game depending on the game progression status.

The level of the target virtual user is merely an example of attribute data of the target virtual user and other parameters may be used. For example, a target virtual user that prefers the quest part21may be estimated based on a consumption trend of points possessed by the target virtual user for each part and an operation history, and, for a virtual user preferring the quest part21, the total number of stages on the “shortest route” may set to be greater as compared to that of a different virtual user who prefers other game parts.

In step S1305, the map creating section40sets the coordinates (a, b) of a target block in the target field to (1, 1), which is an initial value, and the process of the game server proceeds to step S1306.

In step S1306, the map creating section40selects a connecting piece corresponding to the target block from the piece storing section40aand the process of the game server proceeds to step S1307. Specifically, the map creating section40selects a connecting piece corresponding to each target block based on the settings in step S1303and S1304described above.

In step S1307, the map creating section40updates the coordinates of the target block from (a, b) to (a+1, b), and the process of the game server proceeds to step S1308.

In step S1308, the map creating section40determines whether the variable “a” takes a value “x+1” or not. That is to say, it is determined whether or not the target block is beyond a laterally defined edge of an outer boundary of the field. In cases in which the variable “a” does not take a value “x+1”(S1308: NO), the program returns to step S1306, and in cases in which the variable “a” takes a value “x+1” (S1308: YES), the process of the game server proceeds to step S1309.

In step S1309, the map creating section40determines whether or not a variable “b” takes a value “y+1”. That is to say, it is determined whether or not the target block is beyond a longitudinally defined edge of the outer boundary of the field. In cases in which the variable “b” does not take a value “y+1” (S1309: NO), the process of the game server proceeds to step S1310, and in cases in which the variable “b” takes a value “y+1” (S1309: YES), the process of the game server proceeds to step S1311.

In step S1310, the map creating section40resets the value of the variable “a” to 1, and returns to step S1306. By resetting the value of the variable “a” in this manner, the position of the target block in the lateral direction is returned to the initial position.

By repeatedly performing the processes of the aforementioned steps S1306-S1310, the map creating section40creates, for example, a two-dimensional map as shown inFIG. 14A, which is different from the two-dimensional map shown inFIG. 7Adescribed above for the same Field (1). Here, as shown inFIGS. 7A and 14A, the map creating section40creates maps having stages located at the same position in the field F(1), and the route connecting the stages that is being changed.

In step S1311, the map creating section40causes the map data corresponding to the created two-dimensional map to be stored in the map data storing section202, and this process step is terminated. For example, the two-dimensional map as shown inFIG. 7Ais stored in the map data storing section202as the map data as shown inFIG. 7B, and this process step is terminated. Also, the two-dimensional map as shown inFIG. 14Ais stored in the map data storing section202as the map data as shown inFIG. 14B, and step S1201, which is the present process step, is terminated and the process of the game server proceeds to step S1202.

(4-1-2) Event Generating Process (Step S1202)

Next, for example, as a specific process content of step S1202, in the quest part processing101, a process of the flowchart shown inFIG. 15is performed by the event generating section50to produce an event for leading the virtual user to a certain route.

In step S1501, the event generating section50sets a total number of event generation N, and the process of the game server proceeds to step S1502. Here, the total number of event generation N may be determined based on the number of stages arranged in the field or the like.

In step S1502, the event generating section50sets a number of event generation E to zero. The number of event generation E indicates a number of times a virtual event, which is a chance of obtaining cards and items, is generated and the process of the game server proceeds to step S1503.

In step S1503, the stage selecting section51selects, from the stages located on the map, a target stage for which an event is to be generated, and the process of the game server proceeds to step S1504. The stage selecting section51notifies the generation processing section52of the selected stage.

In step S1504, the generation processing section52generates an event for leading the virtual user to a certain route at the stage selected by the stage selecting section51, and the process of the game server proceeds to step S1505. Data indicating the content of the event generated by the generation processing section52is, for example, stored in the map data storing section202as event data that is associated with the map data as shown inFIG. 14Bdescribed above. Also, based on the event data stored in the map data storing section202, the quest image transmitting section41transmits, to the terminal3, display process data for causing an announcement of an event to be displayed.

In step S1505, the event generating section50updates the number of event generation E to E+1, and the process of the game server proceeds to step S1506.

In step S1506, the event generating section50determines whether or not the number of event generation E is a total number of event generation N. When the number of event generation E is the total number of event generation N (S1506: YES), step S1202, which is the present process step, is terminated (S1506: YES), and the process of the game server proceeds to step S1203. When the number of event generation E is not the total number of event generation N (S1506: NO), the program returns to step S1503.

In accordance with the aforementioned steps S1501-S1506, the event generating section50generates an event for each stage, and, as described above, the following method may be applied as a specific example of the selecting of the stages.

In other words, referring toFIG. 14, it is assumed that a virtual user exists at St (1, 2) and that there are two stages St (1, 1) and St (2, 2) that are reachable from St (1, 2). Here, assuming that St (3, 2) is a stage that is reachable by the virtual user or a target stage that the virtual user wishes to reach, there are two routes for reaching St (3, 2), i.e., Route R1 which is a shortcut for reaching St (3, 2) and Route R2 which is a “detour” for reaching St (3, 2). In such a case, the stage selecting section51selects the stage St (1, 1), St (2, 1) or St (3, 1) in a so-called detour route R2 that includes other stages on the route.

In this manner, when the stage St (1, 1), St (2, 1) or St (3, 1) is selected by the stage selecting section51, the generation processing section52generates, for example, an event described below in step S1504.

In other words, the generation processing section52generates an event that provides a “quest point recovery item” with which a quest point is recoverable when the target virtual user has reached the stage St (2, 1). For the virtual user who has reached the stage St (3, 1) in field F(1), the generation processing section52generates an event for providing a rare card, which has a low appearance ratio and is difficult to obtain. Here, the card to be given to the virtual user is not necessarily limited to a rare card having a low appearance ratio, but by producing a particularly rare card, there is an advantage whereby the virtual user can be lead to the stage St (3, 1).

In selecting the stage to be a target for event generation, the process performed by the event generating section50is not limited to the process described above. For example, even if the stage is on a “detour” route, in a case in which it was determined to be a “congested stage” in step S1302described above, it may be excluded from the event generation target stages. Also, the process of selecting the stage to be a target for event generation performed by the event generating section50can be performed with other selecting processes, such as randomly selecting the stages and generating an event. As an example of other selecting processes, for example, it is possible to preferentially select a stage that is not on the shortest route from the starting position Fstart to the end position Fend shown inFIG. 14Aor the stages St (1, 4), St (4, 3) and St (4, 4) that serve as terminating stages, and to generate an event.

In this manner, by generating an event at an arbitrary stage by the event generating section50, the present system can prevent a route along which the virtual user progresses from being selected in a fixed manner due to a connection relationship between the stages created by the map creating section40.

(4-1-3) Process of Changing Stage where Virtual User Exists

As a specific process in step S1203, the quest part processing section101executes a process of changing a stage on which the virtual user exists in accordance with the flowchart shown inFIG. 16. As a prerequisite of this process, it is assumed that the destination stage of the target virtual user that is a target of the process has been determined. Also, it is assumed that each time the operation data that performs a usage request of the quest points is received from the terminal3, the quest points of the target virtual user will decrease by “3” points. For example, the quest points to be consumed at one time may be set by the level of the target virtual user rather than being determined by the physical user operating the terminal3.

As shown inFIG. 16, at first, in step S1601, the operation data receiving part42determines whether or not operation data that uses the quest point has been received. When the operation data that uses the quest point has not been received (S1601: NO), the program returns to step S1601, and when the operation data that uses the quest point has been received (S1601: YES), the process of the game server proceeds to step S1602.

In step S1602, the consumption point calculating section43acalculates accumulated quest points consumed depending on the number of times the operation data is received, and then the process of the game server proceeds to step S1603. For example, when the operation data is received 8 times, as has been described above, since the quest points are consumed by “3 points” each time the operation data is received, the accumulated consumed quest points become “24”. Also, the consumption point calculating section43anotifies the data table update section44of the quest points consumed for each time the operation data is received. The data table updating section44updates the quest points of the target virtual user in the attribute data table203based on the information notified by the consumption point calculating section43a. For example, when the target virtual user possesses “70” quest points and the operation data is received once, the data table update section44updates the quest points possessed by the target virtual user to “67 points”, which is a reduction of “3 points” from “70 points”.

In step S1603, the reach determining section43bdetermines whether or not the accumulated quest points calculated by the consumption point calculating section43aare greater than or equal to the points required for the target virtual user to reach the destination stage. For example, when the target virtual user moves from Stage St (2, 1) to Stage St (3, 1) (S1603: YES), the reached state determining section43bdetermines that “24 points”, which is the accumulated quest points, are greater than or equal to “23 points”, which is the number of points required for reaching the destination stage as shown in the table ofFIG. 14B. When the accumulated quest points are fewer than the points required for reaching (S1603: NO), the reached state determining section43breturns to step S1601. When the accumulated quest points are greater than or equal to the number of points required for reaching (S1603: YES), the process of the game server proceeds to step S1604. Also, as has been described above, when the accumulated quest points are “24 points” and the required number of points is “23 points”, the difference “1 point” can be assumed to have not been consumed, and the quest points of the target virtual user in the attribute data table203may be changed by the data table update section44.

In step S1604, the reached state determining section43bchanges the stage where the target virtual user exists to the destination stage. Then, the data table updating section44is notified of the fact that the stage has changed.

In step S1605, the data table updating section44updates the identification data in the virtual position data table202, and the process of the game server proceeds to step S1606. Specifically, the data table updating section44deletes the identification data of the target virtual user from the stage at which the target virtual user existed before the change, and adds the identification data of the target virtual user to the stage where the target virtual user exists after the modification.

In step S1606, the destination selection data transmitting section45determines whether or not the position where the target virtual user exists that is changed by the virtual position changing section43is the end position Fend of the target field. When it is the end position Fend (S1606: YES), the process of the game server proceeds to step S1607, and when it is not the end position Fend (S1606: NO), the process of the game server proceeds to step S1608.

In step S1607, the data table updating section44updates the identification data in the virtual position data table202, terminates step S1203, which is the present process step, and the process of the game server proceeds to step S1204. Specifically, when the current target field is F(i), the data table updating section44updates the identification data of the target virtual user stored in the virtual position data table203in such a manner that the target field becomes F(i+1).

In step S1608, the destination selection data transmitting section45determines whether there is a plurality of stages that the target virtual user can reach from the current stage of the target virtual user, which has been changed by the virtual position changing section43. For example, when the target virtual user exists at Stage St (2, 2) of the field F(i) shown inFIG. 14A, it is determined that there exists a plurality of reachable stages (S1608: YES), and the process of the game server proceeds to step S1609. When the target virtual user exists at a stage for which a plurality of reachable stages does not exist (S1608: NO), the process of the game server proceeds to step S1610.

In step S1609, the destination selection data transmitting section45transmits destination selection data for selecting the stage of the destination to the terminal3that operates the target virtual user, and step S1203, which is the present process step, is terminated and the process of the game server proceeds to step S1204.

For example, when the target virtual user exists at Stage St (2, 2) as shown inFIG. 17(see black dot inFIG. 17), the destination selection data transmitting section45transmits selection image data510and520respectively representing stages St (3, 2) and St (2, 3), one of which is being selected as image data representing a stage to be selected as a destination. This selection image data510,520may be incorporated in a map image400to be displayed on the terminal3.

The terminal3which has received such selection image data510,520displays these selection images on the display section32. When one of the selection images is selected by the physical user operating the operation input section33, the terminal3notifies the game server1of the fact that the destination stage has been determined via the wireless communication section31.

In step S1610, the destination selection data transmitting section45determines the destination stage of the target virtual user, terminates step S1203which is the present process step, and the process of the game server proceeds to step S1204. For example, when the target virtual user exists at Stage St (1, 1) in the field shown inFIG. 14A, the destination selection data transmitting section45determines Stage St (2, 1) as a destination stage.

(4-2) Process in Quest Part Processing Section of the Second Embodiment

Next, a process of the second embodiment of the quest part processing section101will be described with reference toFIG. 18.

In step S1801, the quest part processing section101determines whether or not the target field where the target virtual user exists is a “field already arrived at” which is a field at which the target virtual user has already arrived in the past. When the target field is the “field already arrived at” (S1801: YES), the process of the game server proceeds to step S1803, and when the target field is not the “field already arrived at” (S1801: NO), the process of the game server proceeds to step S1802.

In step S1802, the quest part processing section101creates a two-dimensional map for the target field with a process similar to that of step S1201of the first embodiment described above, and the process of the game server proceeds to step S1804.

In step S1803, the quest part processing section101re-creates a two-dimensional map for the field already arrived at for which a two-dimensional map has already been created, specifically in a manner described below, and the process of the game server proceeds to step S1804.

In step S1804, the quest part processing section101generates an event for a stage constituting a target field by the event generating section50, specifically in a manner described below, and the process of the game server proceeds to step S1805.

In step S1805, the quest part processing section101performs a process of changing the position at which the virtual user exists in the target field with a process similar to that of S1203of the first embodiment described above, and the process of the game server proceeds to step S1806.

In step S1806, the quest part processing section101determines whether or not the target virtual user has moved between the fields or whether or not a predetermined amount of time such as 24 hours has elapsed. When one of the conditions is satisfied (S1806: YES), the process of the game server proceeds to step S1807, and when neither condition is satisfied (S1806: NO), the program returns to step S1805.

In step S1807, the quest part processing section101determines whether or not termination of the process has been accepted. For example, as in maintenance activities, when the administrator who is managing the game server1changes the configuration of the field, a termination instruction for the process from the administrator is accepted. When the termination of the process is accepted, the present process step is terminated (S1807: YES). When there is no termination instruction for the process (S1807: NO), the program returns to step S1801.

(4-2-1) Process of Re-creating a Two-Dimensional Map (S1803)

As a specific process of step S1803, the process of re-creating a two-dimensional map will be described in accordance with a flowchart shown inFIG. 19.

In step S1803, similarly to S1201of the first embodiment described above, the map creating section40creates a two-dimensional map by combining a total of six kinds of connecting pieces401-406. Also, in this process, each field is constituted by blocks that are arranged into a matrix, 4 blocks vertically by 4 blocks horizontally. The position where each stage is located is specified with coordinates (a, b) of a two-dimensional orthogonal coordinate system.

In step S1901, the map creating section40sets the coordinates (a, b) of the target block in the target field to (1, 1), which is an initial value, and the process of the game server proceeds to step S1902.

In step S1902, the map creating section40determines whether the virtual user has not yet reached the target block at coordinates (a, b). When it is determined that it has not been reached (S1902: YES), the process of the game server proceeds to step S1903, and when it is determined that it has been reached (S1902: NO), the process of the game server proceeds to step S1904.

In step S1903, the map creating section40selects a connecting piece which is the same as the connecting piece previously selected for the target block and the process of the game server proceeds to step S1905. With this process, the map creating section40can maintain the connecting relationship between the target block and surrounding blocks for the cases in which the virtual user has previously arrived at the target field.

In step S1904, the map creating section40selects a new connecting piece corresponding to the target block from the piece storing section40a, and the process of the game server proceeds to step S1905. Here, a new connecting piece may be any connecting piece, and preferably, it is a piece different from the piece that was selected when the virtual user previously arrived at the target field. In this manner, by selecting a piece different from the piece that was selected when the virtual user previously arrived at the target field, the connection relationship between the target block and the surrounding block can be changed efficiently.

In step S1905, the map creating section40updates the coordinates of the target block from (a, b) to (a+1, b), and the process of the game server proceeds to step S1906.

In step S1906, the map creating section40determines whether or not the variable “a” takes a value x+1. In other words, it is determined whether or not the target block is beyond a laterally defined edge of an outer boundary of the field. When the variable “a” does not take a value x+1 (S1906: NO), the program returns to step S1902, and when the variable “a” takes a value x+1 (S1906: YES), the process of the game server proceeds to step S1907.

In step S1907, the map creating section40determines whether or not the variable “b” takes a value y+1. In other words, it is determined whether or not the target block is beyond a longitudinally defined edge of an outer boundary of the field. When the variable “b” does not take a value y+1 (S1907: NO), the process of the game server proceeds to step S1908, and when the variable “b” takes a value y+1 (S1907: YES), the process of the game server proceeds to step S1909.

In step S1908, the map creating section40resets the value of the variable “a” to 1, and returns to step S1902. By resetting the value of variable “a” in this manner, the position of the target block defined in the lateral direction is reset to an initial position.

In step S1909, the map creating section40writes the map data corresponding to the created two-dimensional map into the map data storing section202, and terminates S1803, which is the present process step.

By repeatedly performing the processes of steps S1902to S1908, the map creating section40connects the already reached stages by combining new pieces while maintaining the connection between the stages where the virtual user has not reached.

For example, in an instance in which the virtual user has not yet reached the stages St (1, 4), St (2, 4), St (3, 3), St (3, 4), St (4, 3) and St (4, 4) in a two-dimensional map of field F(1) as shown inFIG. 7A, the map creating section40creates, for example, the following two-dimensional map in accordance with the process of step S1803. In other words, while maintaining the connection of the route between unreached stages which is indicated with a thick line inFIG. 20A, the map creating section40can change routes between other stages.

As a variant of the process of step S1803, when the connection of the route between unreached stages is maintained, the map creating section40may select a piece different from the piece used when the virtual user arrived at a previous target field, and, for example, the two-dimensional map as shown inFIG. 20Bmay be created. In the two-dimensional map ofFIG. 20B, for example, for the stages St (2, 4) and St (3, 4) among the six unreached stages, by selecting pieces that are different from the previous pieces as indicated for Route 1 and Route 2, further different stages may be connected while maintaining the route between the unreached stages.

(4-2-2) Event Generating Process (S1804)

Next, as a specific process content of step S1804, in the quest part processing section101, the event generating section40generates an event which leads the virtual user, for example, in accordance with the process shown inFIG. 21, in order to prevent the virtual users from congregating on some of the stages in a newly created two-dimensional map.

In step S2101, the event generating section50sets the coordinates (a, b) of the target block of the target field to (1, 1), which is an initial value, and the process of the game server proceeds to step S2102.

In step S2102, the event generating section50determines whether or not the target block of the coordinates (a, b) has been reached. When it has not been reached (S2102: YES), the process of the game server proceeds to step S2103, and when it has been reached (S2102: NO), the process of the game server proceeds to step S2104.

In step S2103, the event generating section50sets the target block to an event target stage, and the process of the game server proceeds to step S2104.

In step S2104, the event generating section50updates the coordinates of the target block from (a, b) to (a+1, b), and the process of the game server proceeds to step S2105.

In step S2105, the event generating section50determines whether or not the variable “a” takes a value x+1. In other words, it determines whether or not the target block is beyond a laterally defined edge of an outer boundary of the field. When the variable “a” does not take a value x+1 (S2105: NO), the program returns to step S2102, and when the variable “a” takes a value x+1 (S2105: YES), the process of the game server proceeds to step S2106.

In step S2106, the event generating section50determines whether or not the variable “b” takes a value y+1. In other words, it determines whether or not the target block is beyond a longitudinally defined edge of an outer boundary of the field. When the variable “b” does not take a value y+1 (S2106: NO), the process of the game server proceeds to step S2107, and when the variable “b” takes a value y+1 (S2106: YES), the process of the game server proceeds to step S2108.

In step S2107, the event generating section50resets the value of variable “a” to 1, and returns to step S2102. By resetting the value of the variable “a” in this manner, the position of the target block defined in the lateral direction is reset to an initial position.

In step S2108, the event generating section50sets the total number of event generation N, and the process of the game server proceeds to step S2109. Here, the total number of event generation N may be determined based on the number of stages located in the field.

In step S2109, the event generating section50sets a number of event generation E to zero. The number of event generation E indicates a number of times a virtual event is generated, which is a chance of obtaining cards and items, and the process of the game server proceeds to step S2110.

In step S2110, the stage selecting section51selects a stage for which an event is to be generated from the event target stages set in step S2103. Also, the stage selecting section51notifies the generation processing section52of the selected stage. The generation processing section52causes an event for leading the virtual user to a certain route which will be generated in the selected stage by the stage selecting section51, and the process of the game server proceeds to step S2111. The data indicating the content of the event that was generated by the generation processing section52is stored in the map data storing section202as event data associated with the map data. Also, based on the event data stored in the map data storing section202, the quest image transmitting section41transmits, to the terminal3, display process data for displaying an announcement of an event.

In step S2111, the event generating section50updates the number of event generation E to E+1, and the process of the game server proceeds to step S2112.

In step S2112, the event generating section50determines whether or not the number of event generation E is equal to the total number of event generation N. When the number of event generation E is equal to the total number of event generation N (S2112: YES), the present process step is terminated, and when the number of event generation E is not equal to the total number of event generation N (S2112: NO), the program returns to step S2110.

In accordance with the aforementioned steps S2110to S2112, the event generating section50generates an event for each stage.

In other words, in accordance with the aforementioned process, the generation processing section52preferentially produces events at stages the virtual user has not reached, i.e., stages St (1, 4), St (2, 4), St (3, 3), St (3, 4), St (4, 3) and St (4, 4). In this manner, the event generating section50can efficiently leading the virtual user to an unreached stage in which the connection relationship is maintained at the time the map is re-created.

When selecting the stage to be a target of event generation, the event generating section50is not limited to the method described above, and may also be performed with other selecting processes such as generating events by randomly selecting the stages. As an example of other selecting processes, for example, the stages that are not on the shortest route from a start position Fstart to an end positions Fend in field400, or stages St (1, 1), St (2, 3), St (1, 4) that terminate in Field F (1) (seeFIG. 20) may be preferentially selected and events may be generated. That is, as long as the virtual users can be prevented from being concentrated on a single stage and can be dispersed, the event generating section50may be a section that generates events at any virtual position for said purpose.

(5) Advantageous Effect

With the game server of the present embodiments described above, the virtual position where a virtual user can exist is located two dimensionally and stored as map data in the map data storing section201and by transmitting this data to the terminal3, an image of the two-dimensional map can be displayed on the display section32of the terminal3.

Thereby, when executing an action assigned to the virtual user at each virtual position, a plurality of virtual destination positions reachable by the virtual user can be provided.

Particularly, since the physical user can recognize this plurality of destinations by looking at the two-dimensional map on the terminal3, a virtual region provided by the game part can be broadened visually as compared to the related art in which merely linear advancement was possible.

Also, in the present embodiment, since the map creating section40connects a route between the stages by combining the pieces to create a two-dimensional map by providing a change in a route connecting the stages that are reachable by the virtual user, various impressions can be provided to a physical user concerning the virtual space at which the virtual user exists, even though the virtual user is in the same virtual space.

In the present embodiment, since the map creating section40creates a two-dimensional map by connecting a route between the stages placed in the destination field, a field with a different route as compared to the field before the movement can be visually recognized by the physical user for every movement between the fields. Also, if the virtual user has returned to the field previously arrived at, the virtual user can move in the virtual space in which a route different from the route in the past is created. Thereby, a variety of impressions can be provided to a physical user regarding the stage where the virtual user exists.

In the present embodiment, when the virtual user has come back to the field previously arrived at, the map creating section40can maintain the connection relationship between the stages that have not been reached by the virtual user, and such a need can be satisfied even when the physical user wishes to move within the virtual space in the past state.

In the present embodiment, the map creating section40can easily divide the stages when creating a two-dimensional map and easily connect a route between the stages by using a matrix that equally divides the field into rectangular connecting pieces.

It is to be understood that the object of the present disclosure may also be accomplished by supplying a system or apparatus with a non-transitory storage medium in which a software program, which executes the functions of the above described embodiment, is stored and causing a computer (or CPU or MPU) of the system or apparatus to read out and execute the software program stored in the non-transitory storage medium.

In the above case, the software program read from the non-transitory storage medium executes the functions of the above described embodiment, and therefore the software program and the non-transitory storage medium in which the software program is stored are also an embodiment of the present disclosure.

Examples of the non-transitory storage medium for supplying the software program include a flexible disk, a hard disk, a magneto-optical disk, an optical disk such as a CD-ROM, a CD-R, a CD-RW, a DVD-ROM, a DVD-RAM, a DVD-RW and a DVD+RW, a magnetic tape, a nonvolatile memory card, and a ROM. Alternatively, the program may be downloaded via a network.

Further, it is to be understood that the functions of the above described embodiment may be accomplished not only by executing the software program read out by a computer, but also by causing an OS (operating system) or the like which operates on the computer to perform a part or all of the actual operations based on instructions of the software program.

Further, it is to be understood that functions of the above described embodiment may be accomplished by writing a software program read out from the non-transitory storage medium into a memory provided on an expansion board inserted into a computer or a memory provided in an expansion unit connected to the computer and then causing a CPU or the like provided in the expansion board or the expansion unit to perform a part or all of the actual operations based on instructions of the software program.

While the present disclosure has been described with reference to exemplary embodiments, it is to be understood that the present disclosure is not limited to the disclosed exemplary embodiments. The scope of the following claims is to be afforded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.