Point rally management program and point rally management system

Abstract

To provide a point rally management program and a point rally management system capable of continuously holding a point rally.SOLUTION: The rally management server 10 includes an account management unit 11AC, a rally environment management unit 11EV, a version management unit 11VR, a rally provision unit 11EX, a check-in determination unit 11CH that determines whether or not a player has performed a valid check-in in a predetermined spot, a check-in history management unit 11HS that manages a check-in history, an achievement condition determination unit 11GJ that determines whether or not a predetermined achievement condition is satisfied in a game or the like in which a player participates, a privilege provision unit 11RW that provides a predetermined privilege to a player who has satisfied the achievement condition, and a ranking management unit 11RK that manages a ranking related to a point rally. A control unit 11CR that controls each device, wherein SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a point rally management program and a point rally management system. [Background technology]

[0002] A point rally is known in which participants (players) are provided with information on places to visit (spots) and are given predetermined content or benefits depending on the participants' current location, the progress of the event, etc.

[0003] As a system for managing point rallies, guide map display panels are installed at various tourist spots (spots), and infrared communication units are attached to the display panels.When participants visit each tourist spot, the infrared communication function of the participants' mobile phones is used to display coupon images, point images, etc. on the guide map display panels installed at each tourist spot, and coupon and point information is provided to the participants' mobile phones via infrared communication (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2011-100430 Summary of the Invention [Problem to be solved by the invention]

[0005] By the way, point rallies are often used not only to promote specific products or services, but also to revitalize towns and brand local businesses. When point rallies are used for such purposes, it is desirable that they be held on an ongoing basis.

[0006] If a point rally is held continuously, it is possible that spots may move or disappear during the event. New spots may also appear during the event. If a spot moves, disappears, or appears during the point rally, the content of the point rally must also be updated accordingly.

[0007] However, conventional point rally management systems require the installation of guide map display panels and infrared communication units at each spot. Therefore, if a spot is relocated, disappeared, or created during a point rally, the guide map display panels and infrared communication units must be relocated, removed, or newly installed each time, making it virtually impossible to continue the point rally.

[0008] In view of the above circumstances, the present invention aims to provide a point rally management program and a point rally management system that enable point rallies to be held continuously. [Means for solving the problem]

[0009] The point rally management program of the present invention is characterized in that, when defining the identification information of a player as a player ID, the identification information of a spot as a spot ID, the history of the player's check-ins at the spot as a check-in history, the identification information of a game consisting of multiple spots as a game ID, and the identification information of a series consisting of multiple games as a series ID, the program has a computer execute the following steps: a check-in determination step for determining whether the check-in determination information associated with the player ID and the spot ID satisfies the check-in conditions of the spot ID; a check-in history storage step for storing the check-in history associated with the player ID and the spot ID in a storage device when the check-in determination step is performed; a game achievement determination step for determining whether the check-in history stored in the storage device satisfies specified game achievement conditions; and a series achievement determination step for reading the achievement determination result of the game obtained by the game achievement determination step from the storage device and determining whether the check-in history associated with the series ID associated with the game ID satisfies specified series achievement conditions.

[0010] It is preferable that the game ID is associated with a creator ID indicating the creator of the game, and that the computer executes the following steps: a calculation step of reading the check-in history information from the storage device and calculating the number of check-ins at the spot, the number of checked-in players, the number of times the game has been played, or the number of players of the game; and a ranking display step of assigning the calculation results to the spot ID or the game ID and storing them in the storage device, and displaying a ranking of the creator IDs related to the calculation results. Also, it is preferable that the player ID in the check-in determination step is not associated with the game ID, and that the game achievement determination step is performed based on the check-in history before the player ID was associated with the game ID, as well as the check-in history after the player ID was associated with the game ID. Furthermore, when the version of the game is defined as a game version, the computer is caused to execute a version application step of associating the updated game version with the player ID in the storage device, and when the game version of the game is updated, in the version application step, the game version associated with the player ID of a player not participating in the game is overwritten with the updated game version, while the game version associated with the player ID of a player participating in the game is preferably associated with at least one of the game versions before and after the update to the player ID based on the request of the player.

[0011] The point rally management program of the present invention causes a computer to execute the following steps when defining a player's identification information as a player ID, a spot's identification information as a spot ID, a history of the player's check-ins at the spots as a check-in history, and a game ID as identification information for a game consisting of a plurality of the spots: a check-in determination step for determining whether the check-in determination information associated with the player ID and the spot ID satisfies the check-in conditions of the spot ID; a check-in history storage step for storing the check-in history associated with the player ID and the spot ID in a storage device when the check-in determination step is performed; and a game achievement determination step for determining whether the check-in history stored in the storage device and associated with the game ID satisfies a predetermined game achievement condition; wherein the player ID in the check-in determination step is not associated with the game ID, and the game achievement determination step makes a determination based on the check-in history before the player ID was associated with the game ID, as well as the check-in history after the player ID was associated with the game ID.

[0012] When registering the game in the storage device, the computer is caused to execute a past check-in history application determination step of accepting whether or not the check-in history for the player ID before it was associated with the game ID and registered should be used as a determination target for the game achievement determination step for the game ID, wherein the check-in history includes a check-in time, and the player ID is associated with a game participation time representing the time at which the player ID joined the game, and if the check-in time is before the game participation time, the check-in history is before it was associated with the game ID and registered, and if the check-in time is after the game participation time, the check-in history is after it was associated with the game ID and registered.Furthermore, when guiding the game to the player who is not participating in the game, the computer is caused to execute a guidance step of displaying a progress rate for the game based on the check-in history and game achievement conditions of the game, and preferably the progress rate for the game is generated based on the check-in history of the player stored in the storage device before the game was registered.

[0013] Furthermore, the point rally management program of the present invention, when defining the identification information of a player as a player ID, the identification information of a spot as a spot ID, the history of the player's check-ins to the spot as a check-in history, the identification information of a game consisting of a plurality of the spots as a game ID, and the version of the game as a game version, causes a computer to execute a version application step of associating the updated game version with the player ID in a storage device, and when the game version of the game is updated, in the version application step, the game version associated with the player ID of a player not participating in the game is overwritten with the updated game version, while the game version associated with the player ID of a player participating in the game is associated with at least one of the game versions before or after the update based on the request of the player.

[0014] In the version application step, it is preferable that the updated game version is added as the game version associated with the player ID of the player participating in the game. Furthermore, in the version application step, it is preferable that the game version associated with the player ID of the player participating in the game is updated to at least one of the pre-update and post-update game versions according to a request from the player. Furthermore, when the game version of the game is updated, it is preferable that an applied version determination step be executed in which the player is determined whether or not they are participating in the game. Additionally, when the game version of the game is updated, it is preferable that the version application step output an instruction to the player who participated in the game before the game version of the game was updated to select either the updated game version or the pre-update game version.

[0015] The method causes a computer to execute a version associating step of associating the updated game version in the storage device with the game ID. When the game version of the game is updated and the game version associated with the game ID is added, the version associating step preferably adds a game achievement condition associated with the game ID in accordance with the added game version. Furthermore, when the version associating step performs any one of deleting, changing, and adding a spot belonging to the game, the updated game version is preferably added to the spot ID of the spot belonging to the game. Furthermore, when deleting or changing the spot, the check-in determination condition for the spot related to the game version before the update is preferably set to the location information of the deleted spot ID or the location information of the spot ID before the change.

[0016] The point rally management system of the present invention is characterized by comprising: a storage device that stores a player ID as identification information of a player, a spot ID as identification information of a spot, a check-in history as a history of the player's check-ins to the spot, a game ID as identification information of a game consisting of a plurality of the spots, and a series ID as identification information of a series consisting of a plurality of the games; a check-in determination unit that determines whether the check-in determination information associated with the player ID and the spot ID satisfies the check-in conditions of the spot ID; a check-in history memory unit that stores the check-in history associated with the player ID and the spot ID in the storage device; a game achievement determination step that determines whether the check-in history stored in the storage device satisfies specified game achievement conditions; and a series achievement determination unit that reads the achievement determination result of the game by the game achievement determination unit from the storage device and determines whether the check-in history associated with the series ID associated with the game ID satisfies the specified series achievement conditions.

[0017] The point rally management system of the present invention comprises a storage device that stores a player ID as identification information of a player, a spot ID as identification information of a spot, a check-in history as a history of the player's check-ins to the spot, and a game ID as identification information of a game consisting of a plurality of the spots; a check-in determination unit that determines whether the check-in determination information associated with the player ID and the spot ID satisfies the check-in conditions of the spot ID; a check-in history storage unit that stores the check-in history associated with the player ID and the spot ID in the storage device; and a game achievement determination unit that determines whether the check-in history stored in the storage device and associated with the game ID and player ID satisfies predetermined game achievement conditions, wherein the player IDs that are the subject of determination by the check-in determination unit include those that are not associated with the game ID, and the game achievement determination unit makes a determination based on the check-in history before the player ID was associated with the game ID, as well as the check-in history after the player ID was associated with the game ID.

[0018] The point rally management system of the present invention comprises a storage device that stores a player ID, which is identification information for a player, a spot ID, which is identification information for a spot, a check-in history, which is a history of the player's check-ins to the spot, a game ID, which is identification information for a game consisting of a plurality of the spots, and a game version, which is the version of the game; and a version application unit that associates the updated game version with the player ID in the storage device, wherein when the game version of the game is updated, the version application unit overwrites the game version associated with a player ID that is not participating in the game with the updated game version, while for the game version associated with a player ID that is participating in the game, the version application unit associates at least one of the game versions before or after the update with the player ID based on the request of the player. [Effects of the Invention]

[0019] According to the present invention, it is possible to provide a point rally management program and a point rally management system that enable the operation of a point rally over a long period of time. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of a point rally management system. [Figure 2] (A) is a hardware configuration diagram of a rally management server, and (B) is a hardware configuration diagram of a rally player terminal. [Figure 3] FIG. 2 is a functional block diagram of a rally management server. [Figure 4] 1A is an explanatory diagram showing an overview of the creator DB, and FIG. 1B is an explanatory diagram showing an overview of the player DB. [Figure 5] 1A is an explanatory diagram showing an overview of the spot DB, FIG. 1B is an explanatory diagram showing an overview of the game DB, and FIG. 1C is an explanatory diagram showing an overview of the series DB. [Figure 6] FIG. 1A is an explanatory diagram showing the relationship between spots, games, and series before the upgrade, and FIG. 1B is an explanatory diagram showing the relationship between spots, games, and series after the upgrade. [Figure 7] FIG. 2 is an explanatory diagram showing an overview of a check-in history DB. [Figure 8] FIG. 10 is a flow chart showing an overview of a point rally management method (game play edition). [Figure 9] FIG. 10 is a flow chart showing an overview of a point rally management method (version upgrade edition). [Figure 10] (A) is a functional block diagram of a rally management server, and (B) is a functional block diagram of a rally player terminal. [Figure 11] FIG. 1 is a flow chart showing an overview of a point rally management method. [Figure 12] FIG. 1 is a flow chart showing an overview of a point rally management method. [Figure 13] FIG. 1 is a flow chart showing an overview of a point rally management method. [Figure 14] FIG. 10 is an explanatory diagram showing an overview of the progress rate of the game. DETAILED DESCRIPTION OF THE INVENTION

[0021] As shown in Figure 1, the point rally management system 2 includes a rally management server 10, a rally administrator terminal 20, a rally creator terminal 30, a rally player terminal 40, and a communication line 50 that enables mutual communication between the rally management server 10 and each terminal 20 to 40.

[0022] The rally management server 10 processes information necessary for running and managing a point rally consisting of multiple spots, receives requests from each of the terminals 20-40, performs predetermined calculations, and transmits the results of the calculations to each of the terminals 20-40. The rally manager terminal 20 is used to register and change point rallies and manage the operation of point rallies, and is operated by the manager. The rally creator terminal 30 is used to register and change point rallies and is operated by the creator of the point rally. The rally player terminal 40 is used to participate in and play point rallies and is operated by point rally players.

[0023] A desktop computer or a mobile terminal (such as a notebook computer, mobile phone, tablet PC, or smartphone) is used as the rally manager terminal 20. Mobile terminals are used as the rally creator terminal 30 and the rally player terminal 40.

[0024] As shown in FIG. 2(A), the rally management server 10 includes a CPU 11, a RAM 12, a ROM 13, an external storage device 14, an input device 15, an output device 16, an input / output interface 18, and a bus 19.

[0025] The CPU 11 is a so-called central processing unit that executes various programs to provide various services for the rally management server 10. The RAM 12 is a so-called RAM (random access memory) that is used as a working area for the CPU 11. The ROM 13 is a so-called ROM (read only memory) that stores the basic OS and various programs (for example, a point rally management program) that are executed by the CPU 11.

[0026] The external storage device 14 stores the results of calculations of various programs, and may be a built-in storage device (for example, a hard disk drive) or a removable storage device (for example, a memory card). The external storage device 14 may be a NAS (Network Attached Storage). It may also be connected via a communication line, such as a storage device.

[0027] The input device 15 is an input key, keyboard, or mouse, and is used to input various information. The output device 16 is a display, and displays various operating states.

[0028] The input / output interface 18 enables communication over a communication line. The bus 19 is a wiring that integrally connects the CPU 11, RAM 12, ROM 13, input device 15, output device 16, input / output interface 18, etc., for communication.

[0029] Next, the rally player terminal 40 and the rally creator terminal 30 will be explained. Common parts will be given the same names, and only the differences will be explained in detail.

[0030] 2(B), the rally player terminal 40 includes a CPU 41, RAM 42, ROM 43, an external storage device 44, an input device 45, an output device 46, an input / output interface 48, and a bus 49. The input device 45 includes input keys, a touch panel, a camera, a GPS sensor unit, an acceleration sensor, etc. Although not shown, the rally creator terminal 30 also includes a CPU, RAM, ROM, an external storage device, an input device, an output device, an input / output interface, and a bus, and each of the components is the same as that of the rally player terminal 40.

[0031] When the basic OS and various programs stored in ROM 13 are executed by CPU 11, as shown in Figure 3, rally management server 10 functions as an external storage device 14 in which various information is stored and various DBs (databases) are constructed, an input device 15, an output device 16, an input / output interface 18, an account management unit 11AC, a rally environment management unit 11EV, a version management unit 11VR, a rally provision unit 11EX that provides each player with a point rally, a check-in determination unit 11CH that determines whether a player has performed a valid check-in at a specified spot, a check-in history management unit 11HS that manages the check-in history, an achievement condition determination unit 11GJ that determines whether a player has met specified achievement conditions in a game or the like in which they participate, a benefit provision unit 11RW that provides specified benefits to players who meet the achievement conditions, a ranking management unit 11RK that manages rankings related to the point rally, and a control unit 11CR that controls each device.

[0032] Each part of the CPU 11 will be described in detail below.

[0033] The account management unit 11AC manages the accounts of the administrator, creator, player, etc., and operates in response to a request from each of the terminals 20 to 40. The account management unit 11AC includes an administrator registration processing unit, a game creator registration processing unit, and a player registration processing unit. The administrator registration processing unit records predetermined information in an administrator DB (not shown) constructed in the external storage device 14.

[0034] The game creator registration processing unit records predetermined information in a game creator DB (FIG. 4(A)) constructed in the external storage device 14. The game creator DB associates the creator ID, which is an identifier for the creator, the creator name, the creator address, login information for the creator to log in to the point rally management system 2 (e.g., ID and password required for login), contact information (SNS, email address, etc.), the creator display name displayed on the point rally management system, the number of creator votes, and the creator ranking.

[0035] When a request for game creator registration is sent from rally creator terminal 30, the game creator registration processing unit requests the rally creator terminal 30 to send the information required for game creator registration (creator name, creator address, login information, etc.). Upon receiving the information required for game creator registration from rally creator terminal 30, the game creator registration processing unit associates the information required for game creator registration with a new creator ID and registers it in the game creator DB.

[0036] The player registration processing unit records predetermined information in a player DB (FIG. 4(B)) constructed in the external storage device 14. The player DB associates the following with each other: a player ID, which is an identifier for the player; a player name; a player address; login information for the player to log in to the point rally management system 2 (e.g., an ID and password required for login); contact information (SNS, email address, etc.); a player display name displayed on the point rally management system; participating game information (game ID and version of the game); game participation time; game achievement information; participating series information; series achievement information; earned points; number of player votes; and player ranking. Note that earned points may be omitted. Game participation time is stored for each version of the game.

[0037] When a request for player registration is sent from the rally player terminal 40, the player registration processing unit requests the rally player terminal 40 to send information required for player registration (player name, player address, login information, etc.). When the information required for player registration is received from the rally player terminal 40, the player registration processing unit associates the information required for player registration with a new player ID and registers it in the player DB.

[0038] The rally environment management unit 11EV manages the environment of the point rally, and operates in response to a request from the rally administrator terminal 20 or the rally creator terminal 30. The rally environment management unit 11EV includes a spot registration change unit, a game registration change unit, and a series registration change unit.

[0039] The spot registration and change unit reads the spot DB (FIG. 5(A)) in which various information about spots (places visited), which are components of a rally point, is recorded, and performs necessary processing such as addition, change, or deletion as appropriate.

[0040] The spot DB associates the spot ID, which is the spot's identifier, the spot name, the creator ID representing the creator who set up the spot, the spot location (e.g., city / town name or street address), the spot location information (e.g., GPS coordinates), the spot check-in conditions, the spot status indicating whether the spot is currently valid or not, the game ID, which is the identifier of the game to which the spot belongs, the version of the game that applies to the spot, the number of spot votes, and the spot ranking.

[0041] A given spot may belong to different games at the same time, or the same spot may be prohibited from belonging to multiple games at the same time.

[0042] The game registration change unit reads the game DB (FIG. 5(B)) in which various information about a game (FIG. 6) consisting of multiple spots is recorded, and performs necessary processing such as addition, change, or deletion as appropriate.

[0043] The game DB associates the following with each other: a game ID which is an identifier of the game, a game name, a creator ID which indicates the creator of the game, the number of constituent spots which indicates the number of spots which make up the game, a game difficulty which indicates the difficulty of the game, a game version which indicates the version of the game, game achievement conditions which indicate the conditions for achieving the game, a game achievement bonus which is given to players who meet the game achievement conditions, game participant information which indicates the IDs of players participating in the game, a game start time which indicates the start time of the game, a game end time which indicates the end time of the game, a series ID which indicates the identifier of the series to which the game belongs, the number of game votes, and a game ranking.

[0044] When a new game registration request is received from the rally creator terminal 30, the game registration change unit requests the rally creator terminal 30 to send information required for game registration (game name, number of constituent spots, detailed information about the constituent spots, game achievement conditions, game achievement bonuses, game start time, game end time, etc.). When the information required for game registration is received from the rally creator terminal 30, the game registration change unit associates the game ID, creator ID, etc. with the information required for game registration and registers it in the game DB. The game registration change unit also associates "01" as the game version with the newly registered game ID.

[0045] The information required for game registration may include a series ID. In this case, upon receiving the information required for game registration from the rally creator terminal 30, the series registration change unit determines whether the series ID in the information required for game registration is a series that has already been registered in the series DB. If it is determined that the series ID is already registered in the series DB, the game registration change unit associates the series ID with the game ID in the game DB. On the other hand, if it is determined that the series ID is not registered in the series DB, the series registration change unit associates the series ID, creator ID, etc. with the information required for series registration (described below), and then associates the series ID with the game ID in the game DB.

[0046] Here, the version of the game may be "GAME001_01", which is the game ID of the game (for example, "GAME001") combined with the version number (for example, "01") separated by an "_", or it may be just the version number "01". The spot registration change unit associates the spots (spot IDs "SPOT001" to "SPOT007") belonging to the game with the game ID "GAME001" in the spot DB. Then, upon associating the spots (spot IDs "SPOT001" to "SPOT007") with the game ID "GAME001", the spot registration change unit sets "GAME001_01", which indicates the version "01" of "GAME001", as the game version for the existing spots (spot IDs "SPOT001" to "SPOT007").

[0047] The game registration change unit also reads spot IDs associated with a specific game ID from the spot DB and calculates the distance between spots based on the location information of each spot. The distance between spots may be the sum of the shortest distances between spots on a specific route. The game registration change unit associates the calculated distance between spots as the game difficulty level with the game ID in the game DB.

[0048] The series registration change unit reads the series DB (FIG. 5(C)) in which various information about a series (FIG. 6) consisting of multiple games is recorded, and performs necessary processing such as addition, change, or deletion as appropriate.

[0049] The series DB associates a series ID, which is an identifier for the series, the series name, a creator ID, which indicates the creator of the series, series achievement conditions, which indicate the conditions for achieving the series, series achievement rewards given to players who meet the series achievement conditions, series participant information, which indicates the player IDs of players participating in the series, a series start time, which indicates the start time of the series, a series end time, which indicates the end time of the series, the number of votes for the series, and a series ranking.

[0050] When a new series registration request is sent from the rally producer terminal 30, the series registration change unit requests the rally producer terminal 30 to send information required for series registration (series name, series achievement conditions, series achievement bonus, series start time, series end time, etc.). When the series registration change unit receives the information required for series registration from the rally producer terminal 30, it associates the series ID, producer ID, etc. with the information required for series registration and registers it in the game DB.

[0051] The version management unit 11VR manages the version updates of the game. When a spot, which is a component of the game, is added, changed, or deleted, the version management unit 11VR reads the version of the game from the game DB and adds the new version as the game version associated with the game ID.

[0052] The rally providing unit 11EX provides the rally player terminal 40 with information about the point rally and information necessary for playing the point rally. The rally providing unit 11EX references the player DB and transmits information about the game or series to the rally player terminal 40. At this time, the information transmitted to the rally player terminal 40 includes each ID related to the game or series, the number of spots, the game difficulty level, the creator display name, achievement conditions, achievement benefits, etc.

[0053] When a rally player terminal 40 applies to participate in a game, the player registration processing unit associates participating game information related to the game with the player ID. Also, when a rally player terminal 40 applies to participate in a series, the player registration processing unit associates the series ID of the series and participating game information related to the game belonging to the series with the player ID.

[0054] When a player wishes to participate in a game, the rally providing unit 11EX provides the player with game information related to the latest game version. Here, when a predetermined game is updated, the rally providing unit 11EX inquires of players who are already participating in the game about the desired version to be applied. In the inquiry about the desired version to be applied, the rally management server 10 transmits information about the existing version and the new version of the game to the rally player terminal 40, and inquires whether the player wishes to play the existing version or the new version of the game. When the rally management server 10 receives a request for the desired version of the game from the rally player terminal 40, the player registration processing unit refers to the player DB and associates the player ID related to the request with the game version related to the request. The rally providing unit 11EX provides the requested version of the game to the rally player terminal 40.

[0055] Here, if the game version related to the request is a new version, the new game version may be added in addition to the old game version as a game version associated with the player ID related to the request, or the new game version may be overwritten as a game version associated with the player ID related to the request. Also, if the game version related to the request is an old version, the old game version may remain as the game version associated with the player ID related to the request, or the new game version may be added in addition to the old game version as a game version associated with the player ID related to the request, and play may continue with the old game version.

[0056] The check-in history management unit 11HS records the check-in history of the player, and performs reading, adding, changing, deleting, etc., to the check-in history DB (FIG. 7).

[0057] The check-in history DB stores check-in history. The check-in history associates a player ID, which is an identifier of the player who requested check-in determination, a spot ID, which is an identifier of the spot that was the target of check-in determination, a check-in time, which indicates the time when the check-in determination was requested, check-in determination information, a check-in determination result, and a check-in determination time. Note that the check-in time may be the time when check-in was performed or the time when check-in determination was made.

[0058] The check-in determination unit 11CH determines whether the player has performed a valid check-in at the spot, and upon receiving a check-in determination request including the player ID of the player and the spot ID of the spot, reads the spot check-in conditions associated with the spot ID.

[0059] Thereafter, the check-in determination unit 11CH requests the rally player terminal 40 to transmit check-in determination information, and after receiving the check-in determination information from the rally player terminal 40, determines whether or not the check-in determination information satisfies the spot check-in conditions. After the determination by the check-in determination unit 11CH, the check-in history management unit 11HS writes the check-in determination request, the check-in determination information, and the check-in determination result in the check-in history DB.

[0060] Here, if the spot check-in condition is "the location information transmitted from the rally player terminal 40 is within a radius of r meters from the spot location information," the check-in determination information will be "the location information of the rally player terminal 40." Also, if the spot check-in condition is "a predetermined two-dimensional code associated with the spot has been acquired," the check-in determination information will be the two-dimensional code associated with the spot. Note that the spot check-in condition is not limited to a two-dimensional code, and may be a barcode, keyword, photo, etc.

[0061] The achievement condition determination unit 11GJ includes a game achievement determination unit and a series achievement determination unit.

[0062] The game achievement determination unit determines whether the player has met the achievement conditions for the game in which the player is participating. This determination is made when a predetermined condition (e.g., a valid check-in is determined by the check-in determination unit 11CH) is met. When the check-in determination unit 11CH determines a valid check-in, the game achievement determination unit reads the player ID, spot ID, etc. from information related to the check-in, and then reads the game achievement conditions (e.g., that valid check-ins have been made at all spots belonging to the game) from the game ID and game version associated with the player ID and spot ID. Furthermore, the game achievement determination unit extracts various information associated with the player ID from the check-in history DB and determines whether the extracted information meets the game achievement conditions. If the extracted information meets the game achievement conditions, the player registration processing unit rewrites the game achievement information associated with the player ID in the player DB from "none (default value)" to "yes." Note that if there are multiple game versions of the game, it is preferable that game achievement information be associated with each game version.

[0063] It should be noted that the game achievement determination unit reads the player ID, spot ID, etc. from the information related to the check-in, and then reads the game achievement condition (for example, that valid check-ins have been made at all spots belonging to the game) from the game ID and game version associated with the player ID and spot ID, but the present invention is not limited to this. If the game achievement determination unit reads the player ID, spot ID, etc. from the information related to the check-in and then does not find a game ID associated with the player ID and spot ID, it may not determine whether the game achievement condition has been met.

[0064] When the game achievement determination unit determines that the game achievement condition has been met, the series achievement determination unit reads the series ID and series achievement condition (e.g., that the achievement conditions for all games belonging to the series have been met) from the series DB based on information regarding the game achievement condition (such as the player ID and game ID), and reads the game achievement information associated with the player ID from the player DB. Next, the series achievement determination unit determines whether the game achievement information meets the series achievement condition. If it is determined that the game achievement information meets the series achievement condition, the player registration processing unit rewrites the series achievement information associated with the player ID in the player DB from "none (default value)" to "yes."

[0065] When it is determined that a game achievement condition or a series achievement condition has been achieved (for example, when game achievement information or series achievement information, etc., is written to a predetermined DB), the bonus provider 11RW associates the achievement bonus associated with the achievement condition with the player ID in the player DB, and transmits a message to the rally player terminal 40 associated with the player ID that the achievement bonus has been awarded to the player. The achievement bonus may be points acquired exclusively by the point rally management system. The points may also be associated with the source of acquisition (such as the game ID or series ID).

[0066] The ranking management unit 11RK reads the player DB and extracts information about the players with the highest number of points under predetermined conditions. The ranking management unit 11RK also transmits information about the IDs of the players with the highest number of points under predetermined conditions at a predetermined timing to the rally player terminal 40.

[0067] Next, a method for managing a point rally using the point rally management system 2 will be described with reference to FIGS.

[0068] (Rally guide step) The rally providing unit 11EX refers to the game DB and the series DB and transmits a predetermined game or series to the rally player terminal 40 (S110). At this time, for a player who has already participated in several games, etc., it may transmit only information about games, etc. that the player has not yet participated in. Note that the rally providing unit 11EX refers to the game DB and the series DB and transmits a predetermined game or series to a player ID registered in the player DB, and the information transmitted to the predetermined player ID may be viewed via the rally player terminal 40 (S110).

[0069] (Rally registration step) When the rally management server 10 receives a game participation application request from a rally player terminal 40, the game registration change unit associates the information included in the participation application request (e.g., a game ID related to the game) with the player ID in the game DB, and the player registration processing unit associates the player ID with participating game information and game achievement information in the player DB (S112). Similarly, when the rally management server 10 receives a series participation application request from a rally player terminal 40, the series registration change unit associates the information included in the participation application request (e.g., a series ID related to the series) with the player ID in the series DB, and the player registration processing unit associates the series ID with the player ID in the player DB (S112).

[0070] (Rally start step) After the rally reception step, the rally provider 11EX, based on a request from the rally player terminal 40, refers to the game DB, series DB, and check-in history DB, and transmits various information about the game or series related to the participation application request, as well as the progress status of each rally, to the rally player terminal 40 (S120). The rally player makes an action plan for the next spot while referring to information about the game etc. in which he / she has participated (the remaining number of spots that have not been reached, location information of the spots, etc.) through the rally player terminal 40.

[0071] (Wait step) After the rally start step, the rally provider 11EX enters a state of waiting for a check-in determination request (S130).

[0072] (Check-in decision step) When the rally player reaches the destination spot, the rally player transmits a check-in determination request from the rally player terminal 40 through the rally player terminal 40. When the check-in determination unit 11CH receives the check-in determination request from the rally player terminal 40 (S140), it refers to the spot DB based on the spot ID of the spot included in the check-in determination request, and reads the spot check-in conditions associated with the spot ID. Thereafter, the check-in determination unit 11CH requests the rally player terminal 40 to transmit check-in determination information. After receiving the check-in determination information from the rally player terminal 40, the check-in determination unit 11CH determines whether the check-in determination information satisfies the spot check-in conditions (S140).

[0073] (Check-in history update step) After the check-in determination unit 11CH makes the determination, the check-in history management unit 11HS writes the check-in determination request, the check-in determination information, and the check-in determination result in the check-in history DB (S142).

[0074] (Game completion determination step) If the check-in determination unit 11CH determines that the check-in is valid, the game achievement determination unit reads the game achievement conditions from the game ID and game version associated with the player ID. Furthermore, the game achievement determination unit extracts various information associated with the player ID from the check-in history DB and determines whether the extracted information satisfies the game achievement conditions (S144). If it is determined that the extracted information satisfies the game achievement conditions, the player registration processing unit writes the game achievement information in the player DB. If the check-in is not determined to be valid or if it is determined that the extracted information does not satisfy the game achievement conditions, the process proceeds to a standby step (S130) in which a check-in determination request is awaited from the rally player terminal 40.

[0075] (Game achievement bonus grant step) If it is determined that the game achievement condition has been achieved, the reward providing unit 11RW associates the game achievement reward associated with the game achievement condition with the player ID in the player DB, and sends a message to the rally player terminal 40 associated with the player ID that the game achievement reward has been granted to the player (S146).

[0076] (Series completion determination step) When the game achievement determination unit determines that the game achievement condition has been met, the series achievement determination unit reads the series achievement condition from the series DB based on the series ID associated with the game ID, and reads the game achievement information associated with the player ID from the player DB. Next, the series achievement determination unit determines whether the game achievement information meets the series achievement condition (S150). If it is determined that the game achievement information meets the series achievement condition, the player registration processing unit writes the series achievement information in the player DB. If it is determined that the game achievement information does not meet the series achievement condition, the rally management server 10 transitions to a standby step (S130) in which it waits for a check-in determination request from the rally player terminal 40.

[0077] (Series achievement bonus grant step) When it is determined that the series achievement condition has been achieved, the benefit provider 11RW associates the series achievement benefit associated with the series achievement condition with the player ID in the player DB, and transmits a message to the rally player terminal 40 associated with the player ID that the series achievement benefit has been given to the player (S152).The rally management server 10 then transitions to a standby step (S130) in which it waits for a check-in determination request from the rally player terminal 40.

[0078] Next, a case where a new spot is installed will be described with reference to FIG.

[0079] (Game registration change request step) The rally manager terminal 20 or the rally creator terminal 30 transmits a request to add a new spot (spot ID "SPOT008") in a predetermined game (game ID: GAME001) via operation of the terminal (S210).

[0080] Upon receiving a request to add a new spot (spot ID "SPOT008"), the spot registration change unit adds the spot ID "SPOT008" to the spot DB (Figure 5(A)) and associates the spot ID "SPOT008" with the game ID "GAME001" (S212).

[0081] Furthermore, upon associating the spot ID "SPOT008" with the game ID "GAME001", the version management unit 11VR adds the updated game version "GAME001_02" along with the previous game version "GAME001_01" as the game version of the game ID "GAME001" (Figure 5(B)) (S214).

[0082] Thereafter, the spot registration change unit associates "GAME001_02," which indicates version "02" of "GAME001," with the spot ID "SPOT008" as the game version for the spot ID "SPOT008" (FIG. 5(A)). The spot registration change unit also adds "GAME001_02," which indicates version "02" of "GAME001," as the game version for the existing spots (spot IDs "SPOT001" to "SPOT007"). As a result, the spot ID of the newly established spot is associated with the updated game version due to the new establishment, and the spot IDs of the existing spots are associated with the updated game version in addition to the existing game version (S216).

[0083] In this way, the version management unit 11VR can manage the content of the game to which the spot has been added by version.

[0084] (Version application determination step) When a predetermined game is updated, the rally providing unit 11EX determines whether or not a player ID registered in the player DB is a player participating in the game (S220).

[0085] The rally providing unit 11EX inquires of the rally player terminal 40 of the player determined to be participating in the game about the desired version to be applied. In inquiring about the desired version to be applied, the rally management server 10 transmits information about the version of the game just before the update and the version just after the update to the rally player terminal 40, and inquires about which version the player wants to play (S230).

[0086] When the rally management server 10 receives a request for a desired version of the game from a rally player terminal 40 (S240), the player registration processing unit performs a version application step of referring to the player DB and associating the player ID related to the request with the game version related to the request (S250). The rally providing unit 11EX provides the requested version of the game to the rally player terminal 40 (S260).

[0087] Meanwhile, in the rally providing unit 11EX, for the rally player terminal 40 of a player determined in S230 not to be participating in the game, the player registration processing unit performs a version application determination step in which the player DB is referenced and the participating game information of the game associated with the player ID is overwritten with the latest game version (S280). As a result, players who are not participating in the game when a version upgrade occurs will be provided with the latest version of the game at the time of participation registration, but will no longer be provided with older versions of the game at the time of participation registration. In other words, when a version upgrade occurs, only those who were participating in the game at the time of the version upgrade can play the previous game version.

[0088] In this way, the point rally management system 2 has a game (point rally) consisting of multiple spots and a series consisting of multiple games, and each game and each series has its own achievement conditions and achievement rewards according to each achievement condition, so compared to holding one large-scale point rally consisting of many spots, the hurdle for achieving the conditions is lowered and participants' motivation is increased. Therefore, players can continue to hold point rallies more than if they held one large-scale point rally.

[0089] Furthermore, the point rally management system 2 can reflect changes in the game even if a spot is relocated, disappears, or newly established, so that point rallies can be held continuously for a longer period of time than before.

[0090] Furthermore, whenever a spot is relocated, destroyed, or newly established, the version of the game to which that spot belongs can be managed. This means that not only players who joined before the game was updated, but also players who joined after the game was updated can play the game. As a result, the point rally can be held continuously for a longer period of time than before.

[0091] Furthermore, when a game is updated, only those who are registered to play the existing version of the game at the time of the update can play it. This creates a certain premium for players who can play the older version, which encourages them to register to play the game.

[0092] The game creator registration processing unit can also solicit game creators from players registered in the player DB. When a game creator application is received from a rally player terminal 40, the game creator registration processing unit requests the rally player terminal 40 to transmit the information necessary for game creator registration, and updates the game creator DB (FIG. 4(A)) based on the information transmitted from the rally player terminal 40.

[0093] Similarly, the player registration processing unit can also solicit game players from creators registered in the creator DB. When a player application is received from a rally creator terminal 30, the player registration processing unit requests the rally creator terminal 30 to transmit the information necessary for player registration, and updates the player DB (FIG. 4(A)) based on the information transmitted from the rally creator terminal 30.

[0094] In this way, a rally player can also become a rally creator, and a rally creator can also become a rally player, making it easier for players who have played or created for a long period of time to continue their activities in the point rally management system.

[0095] The ranking management unit 11RK can also ask the rally player terminals 40 to vote for their favorite games or series, or for their favorite creators. The ranking management unit 11RK tally the voting results and ranks the items in order of the number of votes. The number of votes and rankings for each piece of information are stored in the creator DB, player DB, spot DB, game DB, or series DB in association with a corresponding identifier such as a creator ID, player ID, or spot ID, and are transmitted to the rally player terminals 40 and the rally creator terminals 30.

[0096] The ranking management unit 11RK may refer to the check-in history DB to calculate the number of visits to each spot (the number of valid check-in judgments, the number of players who received valid check-in judgments, etc.), and may tally up the rankings of the most visited spots under predetermined conditions. The ranking information obtained in this way is transmitted to the rally player terminal 40. The ranking information may include not only the most visited spots but also the creator IDs of the spots.

[0097] The ranking management unit 11RK may also refer to the game DB and series DB to calculate the number of participants in a game, the number of times a game has been played, and the number of participants in a series and the number of times a game has been played, and tally up rankings related to the number of participants and the number of times a game has been played under predetermined conditions. The ranking information obtained in this way is transmitted to the rally player terminal 40.

[0098] In the above embodiment, the steps from check-in determination step S140 to series achievement award step S152 were performed by the rally management server 10 (see FIG. 8), but the present invention is not limited to this. The steps from check-in determination step S140 to series achievement award step S152 may also be performed by the rally player terminal 40. A server program may be installed in the rally management server 10, and a terminal program may be installed in the rally player terminal 40.

[0099] Hereinafter, the same parts as those in the above embodiment will be denoted by the same reference numerals, and only the different parts will be described in detail, with the same parts omitted.

[0100] In the rally management server 10, when the basic OS and various programs (server programs for the point rally management program) stored in ROM 13 are executed by the CPU 11, as shown in Figure 10 (A), the rally management server 10 functions as an external storage device 14, an input device 15, an output device 16, an input / output interface 18, an account management unit 11AC, a rally environment management unit 11EV, a version management unit 11VR, a check-in history management unit 11HS that manages check-in history, a ranking management unit 11RK, and a control unit 11CR that controls each device.

[0101] When the basic OS and various programs (terminal program for the point rally management program) stored in ROM 43 are executed by the CPU 41 in the rally player terminal 40, as shown in Figure 10 (B), the rally player terminal 40 functions as an external storage device 44, an input device 45, an output device 46, an input / output interface 48, a rally providing unit 41EX (game providing unit) that provides point rallies to each player, a check-in determination unit 41CH that determines whether a player has performed a valid check-in at a specified spot, a check-in history management unit 41HS that manages the check-in history, an achievement condition determination unit 41GJ that determines whether a player has met specified achievement conditions in a game in which they participate, a benefit providing unit 41RW that provides specified benefits to players who have met the achievement conditions, a ranking management unit 41RK that manages rankings related to the point rally, and a control unit 41CR that controls each device.

[0102] Hereinafter, among the various parts of the rally player terminal 40 (Figure 10(B)), those which are the same as the various parts of the rally management server 10 (Figure 10(A)) will be given the same names, and detailed explanations will be given only of the parts which are different.

[0103] The check-in history management unit 41HS transmits the updated data to the rally management server 10. When the rally management server 10 receives the updated data, the check-in history management unit 11HS adds the updated data received from the rally player terminal 40 to the check-in history DB (FIG. 7).

[0104] Next, a method for managing a point rally using the point rally management system 2 will be described with reference to FIGS.

[0105] (Rally guide step) In the rally management server 10, the rally providing unit 11EX refers to the game DB and the series DB, and transmits a predetermined game or series to the rally player terminal 40 (S510).

[0106] (Rally registration step) When the rally management server 10 receives a game participation application request from a rally player terminal 40, the game registration change unit associates the information included in the participation application request (e.g., a game ID related to the game) with the player ID in the game DB, and the player registration processing unit associates the player ID with participating game information and game achievement information in the player DB (S512). Similarly, when the rally management server 10 receives a series participation application request from a rally player terminal 40, the series registration change unit associates the information included in the participation application request (e.g., a series ID related to the series) with the player ID in the series DB, and the player registration processing unit associates the series ID with the player ID in the player DB (S512).

[0107] (Rally start step) After the rally reception step, the rally provider 11EX, based on a request from the rally player terminal 40, refers to the player ID, game DB, series DB, and check-in history DB, and transmits various information related to the game or series related to the participation application request and various information necessary for playing the rally to the rally player terminal 40 (S520). The rally player plays rally points while making an action plan for the next spot, referring to information related to the game etc. in which he / she has participated (the remaining number of spots that have not been reached, location information of the spots, etc.) through the rally player terminal 40 (S600).

[0108] The control unit 41CR records various information acquired by the rally player terminal 40 (check-in history, game achievement information, series achievement information, acquired points, etc.) in the external storage device 44. The control unit 41CR transmits the various information stored in the external storage device 44 to the rally management server 10 at a predetermined timing. The control unit 11CR updates the various information received from the rally player terminal 40 in the various DBs of the external storage device 14. In this way, the various information acquired by the rally player terminal 40 is synchronized with the information stored in the rally management server 10 (S525).

[0109] Next, the procedure for playing a rally point at the rally player terminal 40 will be described (FIG. 11(B)).

[0110] (standby state) The rally player terminal 40 in the standby state waits for input of a check-in determination request (S610).

[0111] (Check-in decision request step) When the player reaches the destination spot, the player operates the rally player terminal 40 to request check-in determination (S620).

[0112] (Check-in decision step) The check-in determination unit 41CH reads the spot check-in conditions associated with the spot ID based on the spot ID of the spot related to the check-in determination request. Furthermore, the check-in determination unit 41CH requests input of check-in determination information via the output device of the rally player terminal 40. When the check-in determination information is input by operating the rally player terminal 40 (for example, by reading a two-dimensional code), the check-in determination unit 41CH determines whether the check-in determination information satisfies the spot check-in conditions (S630).

[0113] (Check-in history update step) After the check-in determination unit 41CH makes a determination, the check-in history management unit 41HS writes the check-in determination request, the check-in determined information, and the check-in determination result to the external storage device 44 (S640). Here, the check-in determination result is a determination result that the check-in determined information satisfies the spot check-in condition (check-in valid) or a determination result that the spot check-in condition is not satisfied (check-in invalid).

[0114] (Game completion determination step) If the check-in determination unit 41CH determines that the check-in is valid, the game achievement determination unit in the rally player terminal 40 reads the game achievement conditions from the game ID and game version associated with the player ID. Furthermore, the game achievement determination unit in the rally player terminal 40 extracts various information associated with the player ID from the check-in history DB and determines whether the extracted information satisfies the game achievement conditions (S650). If it is determined that the extracted information satisfies the game achievement conditions, the control unit 41CR writes the game achievement information to the external storage device 44. If the check-in is not determined to be valid or if it is determined that the extracted information does not satisfy the game achievement conditions, the rally player terminal 40 transitions to a standby state in which it waits for a check-in determination request.

[0115] (Game achievement bonus grant step) If it is determined that the game achievement condition has been achieved, the reward providing unit 11RW associates the game achievement reward associated with the game achievement condition with the player ID in the external storage device 44, and the output device 46 displays that the game achievement reward has been granted to the player (S660).

[0116] (Series completion determination step) When the game achievement determination unit determines that the game achievement condition has been met, the series achievement determination unit reads the series achievement condition from the external storage device 44 based on the series ID associated with the game ID, and also reads the game achievement information associated with the player ID from the external storage device 44. Next, the series achievement determination unit determines whether the game achievement information meets the series achievement condition (S670). If it is determined that the game achievement information meets the series achievement condition, the control unit 41CR writes the series achievement information in the external storage device 44. If it is determined that the game achievement information does not meet the series achievement condition, the rally player terminal 40 transitions to a standby state in which it waits for input of a check-in determination request.

[0117] (Series achievement bonus grant step) When it is determined that the series achievement condition has been achieved, the benefit provider 41RW associates the series achievement benefit associated with the series achievement condition with the player ID in the external storage device 44, and the output device 46 displays that the series achievement benefit has been given to the player (S680). Thereafter, the rally player terminal 40 transitions to a standby state in which it waits for input of a check-in determination request.

[0118] Next, a case where a version upgrade of a game is performed will be described with reference to FIG.

[0119] (Game registration change request step) The rally manager terminal 20 or the rally creator terminal 30 transmits a request to add a new spot (spot ID "SPOT008") in a predetermined game (game ID: GAME001) via operation of the terminal (S210).

[0120] Upon receiving a request to add a new spot (spot ID "SPOT008"), the spot registration change unit adds the spot ID "SPOT008" to the spot DB (Figure 5(A)) and associates the spot ID "SPOT008" with the game ID "GAME001" (S212).

[0121] Furthermore, upon associating the spot ID "SPOT008" with the game ID "GAME001", the version management unit 11VR adds the updated game version "GAME001_02" along with the previous game version "GAME001_01" as the game version of the game ID "GAME001" (Figure 5(B)) (S214).

[0122] Thereafter, the spot registration change unit associates "GAME001_02," which indicates version "02" of "GAME001," with the spot ID "SPOT008" as the game version for the spot ID "SPOT008" (FIG. 5(A)). The spot registration change unit also adds "GAME001_02," which indicates version "02" of "GAME001," as the game version for the existing spots (spot IDs "SPOT001" to "SPOT007"). As a result, the spot ID of the newly established spot is associated with the updated game version due to the new establishment, and the spot IDs of the existing spots are associated with the updated game version in addition to the existing game version (S216).

[0123] Thereafter, the version management unit 11VR notifies the rally play terminal 40 of the player ID registered in the player DB that a predetermined game has been upgraded (S710).

[0124] When the rally play terminal 40 receives a version upgrade notification from the rally management server 10 (S720), the rally providing unit 41EX performs a version application determination step (S730) in which the game ID included in the version upgrade notification is compared with the game ID associated with the player ID stored in the external storage device 44 to determine whether the player is participating in the upgraded game.

[0125] If it is determined that the player is not participating in an upgraded game, the control unit 41CR overwrites the game version of the game ID stored in the external storage device 44 with the updated game version (S735). Thereafter, the control unit 41CR requests various information necessary for playing a rally in the updated game version from the rally management server 10, and stores the various information received from the rally management server 10 in the external storage device 44. On the other hand, if it is determined that the player is participating in an upgraded game, a selection request screen for selecting the version of the game immediately before the update and the version immediately after the update is displayed on the output device 46 (S740). This allows the player to be asked whether they would like to play the existing version of the game or the new version.

[0126] When the input of the desired version of the game is accepted by operating the input device 45 (S750), the control unit 41CR refers to the external storage device 44 and performs a version application step of associating the player ID with the desired game version (S760). Thereafter, the control unit 41CR requests various information necessary for playing a rally with the updated game version from the rally management server 10, and stores the various information received from the rally management server 10 in the external storage device 44. The rally providing unit 41EX provides the requested version of the game to the rally player (S770).

[0127] In the above embodiment, the version application step associates the player ID with the game version desired by the player. However, the present invention is not limited to this. The updated game version may be added as a game version associated with the player ID regardless of the player's preference. Furthermore, a version application reselection step may be performed after the version application step, in which the player requests selection of an applicable version. The version application reselection step is preferably performed at the player's request. When the version application reselection step upgrades the game to the second version, even a player who selected the first version can play the second version of the game by performing the version application reselection step at the player's request after completing the first version of the game.

[0128] In the above embodiment, the rally management server 10 performs a rally notification step (S510), a rally application is made by the rally player terminal 40, and the rally management server 10 performs a rally acceptance step (S512) and a rally start step (S520), but the present invention is not limited to this. A request may be made to a predetermined server (such as the rally management server 10) to download a terminal program for the point rally management program, and the rally acceptance step (S512) and rally start step (S520) may be performed during the process of installing the terminal program.

[0129] In the above embodiment, the content of the game to which a spot has been added is managed by version, but the present invention is not limited to this, and the content of the game to which a spot has been deleted or changed may also be managed by version.

[0130] When a request to delete an existing spot in a specific game is received from the rally administrator terminal 20 or the rally creator terminal 30, the version management unit 11VR adds the updated game version (for example, "GAME00X_01" becomes "GAME00X_02") as the game version of the game ID with which the spot is associated. At this time, the spot registration change unit adds the updated version as the game version to all spot IDs belonging to the deleted game.

[0131] When a request to change an existing spot in a specific game is received from the rally manager terminal 20 or the rally creator terminal 30, the version management unit 11VR adds the updated game version as the game version of the game ID associated with the spot. At this time, the spot registration change unit adds the updated version as the game version to all spot IDs belonging to the game.

[0132] In this way, the version management unit 11VR can manage the content of the game in which spots have been added, changed, or deleted by version.

[0133] It should be noted that the rally player terminal 40 may transmit information that "due to the disappearance or relocation of the spot, it is no longer possible to satisfy the check-in conditions for the spot." In this case, when receiving information that "due to the disappearance or relocation of the spot, it is no longer possible to satisfy the check-in conditions for the spot" from the rally player terminal 40, the rally providing unit 11EX may request the rally administrator terminal 20 to perform an on-site check of the spot. Then, if the on-site check results in the information that "due to the disappearance or relocation of the spot, it is no longer possible to satisfy the spot check-in conditions," a predetermined version upgrade process may be performed, and predetermined points may be awarded to the player ID linked to the rally player terminal 40 that provided the information.

[0134] Furthermore, if a spot belonging to the game disappears or moves, and the spot check-in condition for that spot is "obtaining a specific two-dimensional code," the spot check-in condition can no longer be met even if the game version before the update is used. In such a case, it is preferable for the spot registration change unit to change the spot check-in condition for that spot in the game version before the update to a condition that can be determined based on the spot position information of that spot (for example, "the position information sent from the rally player terminal 40 must be within a radius of r meters from the spot position information").

[0135] In the above embodiment, the version of the game is updated when a spot, which is a component of the game, is added, changed, or deleted, but the present invention is not limited to this, and the game version may also be updated when the game achievement conditions or game achievement rewards are changed. In this case, the game achievement conditions and game achievement rewards are associated with the game version in the game DB, and when the game version is updated, the updated game version may be added to the game version before the update as a game version associated with the game achievement conditions and game achievement rewards, or the game version before the update may be updated to the updated game version.

[0136] For example, if the game achievement condition of the game is "check in to all spots belonging to the game," the game achievement condition may remain the same before and after a game version upgrade. On the other hand, the game achievement condition of the game may be individually changed before and after a game version upgrade, such as changing the game achievement condition from "check in to all spots belonging to the game" to "check in to all spots belonging to the game during a specified period" or "answer a specified quiz after checking in to all spots belonging to the game." In such cases, the game registration change unit associates each game achievement condition with each game version for the game ID and stores them in the game DB at the time of the version upgrade.

[0137] In the above embodiment, when a spot is moved, deleted, or added, the version of the game belonging to that spot is updated, but the present invention is not limited to this, and the version of the series belonging to that game may be updated along with the version of the game belonging to that spot.

[0138] Also, a major series may be set up to include multiple series, and the major series may be playable along with the games and series.

[0139] In the above embodiment, when a player who participated in a predetermined game reached a predetermined spot, a check-in determination step (S140 in FIG. 8) was triggered to perform a check-in history update step (S142) and a game achievement determination step (S144). However, the present invention is not limited to this, and the check-in determination step (S140 in FIG. 8) and the check-in history update step (S142) may also be performed when a player who is not participating in the game (a player ID not associated with a game ID) checks in to a predetermined spot. A method for managing a point rally using the point rally management system 2 in this case will be described with reference to FIG. 13.

[0140] (Spot guide step) The rally provider 11EX transmits various information (spot name, spot location, spot position information, etc.) related to the spot ID registered in the spot DB (Figure 10(A)) to the player registered in the player DB (for example, "players with player IDs PL_0106 and PL_0107" in Figure 4(B)) (S410).

[0141] (Wait step) After the spot guidance step, the rally provider 11EX enters a state of waiting for a check-in determination request (S420).

[0142] (Check-in decision step) When the player reaches the destination spot, the rally player terminal 40 transmits a check-in determination request through the rally player terminal 40. When the check-in determination unit 11CH receives the check-in determination request from the rally player terminal 40 (S140), it refers to the spot DB based on the spot ID of the spot included in the check-in determination request, and reads the spot check-in conditions associated with the spot ID. Thereafter, the check-in determination unit 11CH requests the rally player terminal 40 to transmit check-in determination information. After receiving the check-in determination information from the rally player terminal 40, the check-in determination unit 11CH determines whether the check-in determination information satisfies the spot check-in conditions (S140).

[0143] (Check-in history update step) After the check-in determination unit 11CH makes the determination, the check-in history management unit 11HS writes the check-in determination request, the check-in determination information, and the check-in determination result in the check-in history DB (S142).

[0144] (Rally guide step) The rally providing unit 11EX refers to the game DB and the series DB, and transmits information about games and series in which the player has not participated to the rally player terminal 40 (S450). The information about games and series in which the player has not participated includes the game ID of the game in which the player has not participated that is not associated with the player ID, the spot ID associated with the game ID in which the player has not participated, and the series ID associated with the game ID in which the player has not participated. Furthermore, the information about the game in which the player has not participated may include the check-in determination result associated with the player ID and the spot ID, and the progress rate of the game (FIG. 14).

[0145] The game progress rate may be displayed as "M / N" or "M / N x 100" where N is the number of spot IDs associated with the game ID and M is the number of spot IDs associated with the game ID that have valid check-in determination results. Also, the check-in determination results for the spot IDs associated with the game ID may be displayed as a list.

[0146] (Rally registration step) When the rally management server 10 receives a game participation application request from a rally player terminal 40, the game registration change unit associates the information included in the participation application request (e.g., a game ID related to the game) with the player ID in the game DB, and the player registration processing unit associates the player ID with participating game information and game achievement information in the player DB (S452). Similarly, when the rally management server 10 receives a series participation application request from a rally player terminal 40, the series registration change unit associates the information included in the participation application request (e.g., a series ID related to the series) with the player ID in the series DB, and the player registration processing unit associates the series ID with the player ID in the player DB.

[0147] After the rally start step, the steps from rally start step S120 to series achievement award step S152 shown in Fig. 8 may be performed as appropriate. Then, in game achievement determination step S144 and series achievement determination step S150, not only check-in determination results generated after association with the game ID but also check-in determination results generated before association with the game ID can be used.

[0148] That is, in the game achievement determination step S144, the game achievement determination unit reads the player ID and spot ID, etc. from the information related to the check-in, and then determines whether the achievement conditions for the game have been met using not only the check-in history generated after the game participation time associated with the player ID, but also the check-in history generated before the game participation time associated with the player ID.

[0149] In addition, in the series achievement determination step S150, the series achievement determination unit reads the player ID and spot ID, etc. from the information related to the check-in, and then determines whether the achievement conditions for the series have been met using not only the check-in history generated after the game participation time associated with the player ID, but also the check-in history generated before the game participation time associated with the player ID.

[0150] In this way, even when a player who is not participating in a game checks in at a predetermined spot, by performing the spot introduction step S410, the waiting step S420, the check-in determination step S140, and the check-in history update step S142, when the player participates in a game in the future, the check-in determination result obtained before participating in the game can be used in the achievement conditions of the game. Furthermore, considering the benefits that players who have not participated in the game will receive if they participate in a future game, an incentive is created for players who have not participated in the game to at least check in even if they are not participating in the game.

[0151] The rally provider 11EX also references the game DB and series DB and transmits information about games and series in which the player has not yet participated to the rally player terminal 40. The information about games and series in which the player has not yet participated includes the game ID of the game not associated with the player ID, the spot ID associated with the game ID in which the player has not yet participated, and the progress rate of the game. This allows the player to know the progress rate of the game before participating in the game. As a result, this information becomes a basis for the player to decide whether or not to participate in the game. This also creates an incentive for the player to participate in the game.

[0152] In this embodiment, the check-in history includes the check-in time (FIG. 7). Furthermore, a game participation time indicating the time at which the player joined the game is associated with each game ID (FIG. 4(B)). Therefore, the game achievement determination unit compares the two and determines that if the check-in time is before the game participation time, it is the check-in history before it was associated with the game ID and registered, and if the check-in time is after the game participation time, it is the check-in history after it was associated with the game ID and registered.

[0153] For this reason, the game achievement determination unit can be set to one of two modes for each game: one that uses only the check-in determination results obtained by the player after participating in the game or series, and one that uses not only the check-in determination results obtained by the player after participating in the game or series but also the check-in determination results obtained by the player before participating in the game or series. This setting is performed by the game registration change unit of the rally environment management unit 11EV. The game achievement determination unit then makes its determination according to the set mode of the two modes.

[0154] The present invention is not limited to the above-described embodiment, and it goes without saying that various modifications can be made without departing from the spirit of the present invention. [Explanation of symbols]

[0155] 2. Point Rally Management System 10 Rally Management Server 11AC Account Management Department 11CH Check-in Judgment Section 11CR control unit 11EV Rally Environmental Management Department 11EX Rally Provided Department 11GJ achievement condition judgment part 11HS Check-in History Management Department 11RK Ranking Management Department 11RW Benefits Recommendation Department 11VR Version Control Department 14 External storage device 15 Input Devices 16 Output Devices 18 Input / Output Interface 20 Rally Manager Terminal 40 Rally Player Terminal 50 communication lines

Claims

1. When the identification information of a player is defined as a player ID, the identification information of a spot is defined as a spot ID, the history of the player checking in to the spot is defined as a check-in history, the identification information of a game consisting of a plurality of the spots is defined as a game ID, and the identification information of a series consisting of a plurality of the games is defined as a series ID, a check-in determination step of determining whether or not check-in determination information associated with the player ID and the spot ID satisfies a check-in condition of the spot ID; a check-in history storage step of storing, in a storage device, a check-in history in which the player ID and the spot ID are associated, when the check-in determination step is performed; a game achievement determination step of determining whether or not the check-in history stored in the storage device satisfies a predetermined game achievement condition; a series achievement determination step of reading from the storage device a result of the game achievement determination step, and determining whether or not the check-in history associated with the series ID associated with the game ID satisfies a predetermined series achievement condition; A point rally management program characterized by causing a computer to execute the above.

2. The game ID is associated with a creator ID indicating the creator of the game, a calculation step of reading the check-in history information from the storage device and calculating the number of check-ins at the spot, the number of players who checked in, the number of times the game has been played, or the number of players of the game; The point rally management program of claim 1, characterized in that the computer executes a ranking display step of assigning the result of the calculation to the spot ID or the game ID and storing it in the storage device, and displaying the ranking of the creator ID related to the result of the calculation.

3. the player ID in the check-in determination step is not associated with the game ID; In the game achievement determination step, the determination is made based on a check-in history after the player ID is associated with the game ID, as well as the check-in history before the player ID is associated with the game ID.

3. The point rally management program according to claim 1 or 2,

4. When the version of the game is defined as a game version, a version applying step of associating the updated game version with the player ID in the storage device; When the game version of the game is updated, in the version application step, the game version associated with the player ID of the player not participating in the game is overwritten with the updated game version, Associating at least one of the game versions before and after the update with the player ID of the player participating in the game based on a request from the player.

3. The point rally management program according to claim 1 or 2,

5. When the identification information of a player is defined as a player ID, the identification information of a spot is defined as a spot ID, the history of the player checking in to the spot is defined as a check-in history, and the identification information of a game consisting of multiple spots is defined as a game ID, a check-in determination step of determining whether or not check-in determination information associated with the player ID and the spot ID satisfies a check-in condition of the spot ID; a check-in history storage step of storing, in a storage device, a check-in history in which the player ID and the spot ID are associated, when the check-in determination step is performed; a game achievement determination step of determining whether or not the check-in history stored in the storage device and associated with the game ID and the player ID satisfies a predetermined game achievement condition, the player ID in the check-in determination step is not associated with the game ID; In the game achievement determination step, the determination is made based on a check-in history after the player ID is associated with the game ID, as well as the check-in history before the player ID is associated with the game ID. A points rally management program featuring:

6. When registering the game in the storage device, the computer is caused to execute a past check-in history application determination step of accepting whether or not the check-in history related to the player ID before being associated with the game ID and registered is to be used as a determination target for the game achievement determination step for the game ID, The check-in history includes check-in times; The player ID is associated with a game participation time indicating the time when the player participated in the game, and If the check-in time is before the game participation time, the check-in history is before being associated with the game ID and registered, A point rally management program as described in claim 3 or 5, characterized in that if the check-in time is later than the game participation time, the check-in history is the check-in history after being associated with the game ID and registered.

7. When introducing the game to the player who is not participating in the game, a guide step of displaying a progress of the game based on the check-in history and a game achievement condition of the game, 7. The point rally management program according to claim 6, wherein the game progress is generated based on the check-in history of the player stored in the storage device before registration for the game.

8. When the identification information of a player is defined as a player ID, the identification information of a spot is defined as a spot ID, the history of the player checking in to the spot is defined as a check-in history, the identification information of a game consisting of multiple spots is defined as a game ID, and the version of the game is defined as a game version, a version applying step of associating the updated game version with the player ID in a storage device; When the game version of the game is updated, in the version application step, the game version associated with the player ID of the player not participating in the game is overwritten with the updated game version, A point rally management program characterized in that the game version associated with the player ID of the player participating in the game is associated with at least one of the game versions before and after the update based on the request of the player.

9. 9. The point rally management program according to claim 8, wherein the version application step adds the updated game version as the game version associated with the player ID participating in the game.

10. The point rally management program according to claim 8, characterized in that in the version application step, the game version associated with the player ID participating in the game is updated to at least one of the game versions before and after the update, in accordance with the request of the player.

11. When an update to the game version of the game is made, 11. The point rally management program according to claim 8, wherein the program causes the player to execute an applicable version determination step of determining whether or not the player is participating in the game.

12. When an update to the game version of the game is made, The point rally management program according to claim 11, characterized in that in the version application step, an output is output to the player who participated in the game before the game version of the game was updated, informing him or her to select either the updated game version or the game version before the update.

13. a version associating step of associating the updated game version in the storage device with the game ID; When the game version of the game is updated and the game version associated with the game ID is added, A point rally management program according to any one of claims 8 to 10, characterized in that in the version association step, a game achievement condition associated with the game ID is added according to the added game version.

14. The point rally management program of claim 13, characterized in that in the version association step, when one of deleting, changing, and adding a spot belonging to the game is performed, the updated game version is added to the spot ID of the spot belonging to the game.

15. A point rally management program as described in claim 14, characterized in that when deleting or changing the spot, the check-in determination condition of the spot for the game version before the update is set to the location information of the deleted spot ID or the location information of the spot ID before the change.

16. a storage device that stores a player ID as identification information of a player, a spot ID as identification information of a spot, a check-in history as a history of check-ins by the player to the spot, a game ID as identification information of a game consisting of a plurality of the spots, and a series ID as identification information of a series consisting of a plurality of the games; a check-in determination unit that determines whether or not check-in determination information associated with the player ID and the spot ID satisfies the check-in condition of the spot ID; a check-in history storage unit that stores a check-in history in which the player ID and the spot ID are associated in a storage device; a game achievement determination step of determining whether or not the check-in history stored in the storage device satisfies a predetermined game achievement condition; A point rally management system characterized by comprising: a series achievement determination unit that reads the achievement determination result of the game by the game achievement determination unit from the storage device and determines whether the check-in history associated with the series ID associated with the game ID satisfies a specified series achievement condition.

17. a storage device that stores a player ID as identification information of a player, a spot ID as identification information of a spot, a check-in history as a history of check-ins by the player to the spot, and a game ID as identification information of a game consisting of a plurality of the spots; a check-in determination unit that determines whether or not check-in determination information associated with the player ID and the spot ID satisfies the check-in condition of the spot ID; a check-in history storage unit that stores a check-in history in which the player ID and the spot ID are associated in a storage device; a game achievement determination unit that determines whether the check-in history stored in the storage device and associated with the game ID and the player ID satisfies a predetermined game achievement condition, The player IDs to be determined by the check-in determination unit include those that are not associated with the game ID, A point rally management system characterized in that the game achievement determination unit makes a determination based on the check-in history before the player ID was associated with the game ID, as well as the check-in history after the player ID was associated with the game ID.

18. a storage device that stores a player ID, which is identification information of a player, a spot ID, which is identification information of a spot, a check-in history, which is a history of check-ins by the player to the spot, a game ID, which is identification information of a game consisting of a plurality of the spots, and a game version, which is a version of the game; a version application unit that associates the updated game version with the player ID in the storage device; A point rally management system characterized in that, when the game version of the game is updated, the version application unit overwrites the game version associated with the player ID of a player not participating in the game with the updated game version, while for the game version associated with the player ID of a player participating in the game, the version application unit associates at least one of the game versions before or after the update with the player ID based on the player's request.

Images