Information processing method

An information processing method is an information processing method executable by a server device. The information processing method includes obtaining first position information from a first portable terminal that has received a beacon signal from a first beacon device, the first position information being information indicating a current position of the first portable terminal, calculating a probability of abnormal condition of the first beacon device by comparing the obtained first position information with second position information indicating an installation position of the first beacon device, the second position information being managed in advance by the server device, and performing a process corresponding to the calculated probability of abnormal condition.

BACKGROUND

1. Technical Field

The present disclosure relates to an information processing method for suppressing or reducing unauthorized use of a beacon device.

2. Description of the Related Art

Japanese Unexamined Patent Application Publication No. 2006-279854 discloses an anti-theft system which determines that an equipment device has been stolen when it is detected that the equipment device is located at a position different from a predetermined position.

Japanese Unexamined Patent Application Publication No. 10-226315 discloses an anti-theft apparatus that senses the movement of an anti-theft object.

Japanese Unexamined Patent Application Publication No. 2013-247417 discloses a communication monitoring apparatus that senses the suspected theft of a relay device in accordance with the number of communication devices that use the relay device.

SUMMARY

In one general aspect, the techniques disclosed here feature an information processing method executable by a server device. The information processing method includes obtaining first position information from a first portable terminal that has received a beacon signal from a first beacon device, the first position information being information indicating a current position of the first portable terminal, calculating a probability of abnormal condition of the first beacon device by comparing the obtained first position information with second position information indicating an installation position of the first beacon device, the second position information being managed in advance by the server device, and performing a process corresponding to the calculated probability of abnormal condition.

An information processing method according to an aspect of the present disclosure may provide processing for suppressing or reducing unauthorized use of a beacon device in accordance with the probability of abnormal condition of the beacon device.

DETAILED DESCRIPTION

There are cases where a beacon device is installed in a building such as a store. The beacon device transmits information to a portable terminal such as a smartphone. In this case, if the installed beacon device were stolen, it would not be desirable for the beacon device to be used without authorization. The present disclosure provides an information processing method for suppressing or reducing unauthorized use of a beacon device.

An information processing method according to an aspect of the present disclosure is an information processing method executable by a server device. The information processing method includes obtaining first position information from a first portable terminal that has received a beacon signal from a first beacon device, the first position information being information indicating a current position of the first portable terminal, calculating a probability of abnormal condition of the first beacon device by comparing the obtained first position information with second position information indicating an installation position of the first beacon device, the second position information being managed in advance by the server device, and performing a process corresponding to the calculated probability of abnormal condition.

According to the information processing method described above, it may be possible to calculate the probability of abnormal condition of a beacon device on the basis of a deviation from the installation position of the beacon device. According to the information processing method described above, furthermore, it may be possible to perform a process to suppress or reduce unauthorized use of the beacon device in accordance with the calculated probability of abnormal condition.

The calculating may include calculating the probability of abnormal condition so that the larger a difference between the current position indicated by the first position information and the installation position indicated by the second position information, the higher the probability of abnormal condition.

In the way described above, in the information processing method described above, specifically, the probability of abnormal condition may be calculated so that the larger the deviation from the installation position of the beacon device, the higher the probability of abnormal condition.

In addition, the information processing method may further include managing, as a first check-in history, a date and time of reception of a first ID transmitted from each of the plurality of second portable terminals. The first ID may be included in a beacon signal that each of the plurality of second portable terminals receives from the first beacon device. The calculating may include calculating the probability of abnormal condition by further using the first check-in history.

According to the information processing method described above, for example, even if current position information on a portable terminal has been tampered with, it may be possible to accurately calculate a probability of abnormal condition.

For example, the calculating may include calculating the probability of abnormal condition by comparing a first check-in history obtained when the first position information is obtained with a first check-in history obtained before the first position information is obtained.

According to the information processing method described above, it may be possible to calculate a probability of abnormal condition on the basis of the comparison between current and previous check-in histories.

In addition, the managing may include managing the date and time of reception of the first ID transmitted from each of the plurality of second portable terminals, as the first check-in history, in association with a user ID of a user of the corresponding one of the second portable terminals which has transmitted the first ID. The user ID of the user may be transmitted from the one of the second portable terminals. The calculating may include calculating the probability of abnormal condition in accordance with the number of identical user IDs included in the first check-in history.

According to the information processing method described above, it may be possible to calculate a probability of abnormal condition on the basis of the imbalanced number of users who use beacon devices.

In addition, the information processing method may further include managing, as a second check-in history, a date and time of reception of a second ID transmitted from each of a plurality of third portable terminals. The second ID may be included in a beacon signal that each of the plurality of third portable terminals received from a second beacon device different from the first beacon device. The calculating may include calculating the probability of abnormal condition by comparing the first check-in history with the second check-in history.

According to the information processing method described above, it may be possible to calculate a probability of abnormal condition on the basis of the comparison between a condition of usage of a certain beacon device and a condition of usage of another beacon device.

In addition, the performing of a process may include performing, as the process, a process for instructing the first portable terminal to obtain a beacon signal from a third beacon device different from the first beacon device, in a case where the calculated probability of abnormal condition is greater than or equal to a predetermined value.

According to the information processing method described above, if the occurrence of an abnormal event in a certain beacon device is suspected, it may be possible to determine whether or not an abnormal event has occurred by using another beacon device.

In addition, the performing of a process may include performing a predetermined process for the first portable terminal in a case where the calculated probability of abnormal condition is lower than a predetermined value, and suspending the predetermined process in a case where the calculated probability of abnormal condition is greater than or equal to the predetermined value.

According to the information processing method described above, it may be possible to suspend the predetermined process in accordance with the probability of abnormal condition.

In addition, the first portable terminal may have installed thereon an application for a game for which data is managed by the server device, and the predetermined process may be a process for allocating a game reward used in the game over the data.

In the way described above, the information processing method described above may be usable for the allocation of a game reward based on, for example, communication with a beacon device.

In addition, the performing of a process may include performing, as the process, a process for transmitting information to the first beacon device via the first portable terminal, the information being information for stopping a function of the first beacon device, in a case where the calculated probability of abnormal condition is greater than or equal to a predetermined value.

According to the information processing method described above, if the probability of abnormal condition is high, it may be possible to stop the operation of a beacon device.

In addition, the first beacon device may hold key information, and the information for stopping the function of the first beacon device may be encrypted information decodable by using the key information that the first beacon device holds.

According to the information processing method described above, it may be possible to prevent communication between a beacon device and a server device from being intercepted by any other device.

In addition, the information for stopping the function of the first beacon device may include information for deleting the key information held in the first beacon device.

According to the information processing method described above, if the probability of abnormal condition is high, it may be possible to completely stop the operation of a beacon device and to delete key information to enhance safety.

In addition, the second position information may be stored in a storage unit included in the server device.

In addition, at least one of the obtaining, the calculating, and the performing of a process may be executed by a processor included in the server device.

It should be noted that these general or specific aspects may be implemented as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable recording medium such as a compact disc read-only memory (CD-ROM). Alternatively, these general or specific aspects may be implemented as any combination of a system, an apparatus, an integrated circuit, a computer program, and a recording medium.

In the following, embodiments will be specifically described with reference to the drawings.

The following embodiments illustrate general or specific examples. Numerical values, shapes, materials, constituent elements, arranged positions and connection forms of the constituent elements, steps, the order of the steps, and others illustrated in the following embodiments are examples, and are not intended to limit the present disclosure. Among constituent elements described in the following embodiments, a constituent element that is not included in the independent claim which represents the most generic concept of the present disclosure is described as an optional constituent element.

The drawings are schematic and not necessarily drawn to scale. In the drawings, elements having substantially the same configuration are denoted by the same reference numerals, and a redundant description may be omitted or simplified.

First Embodiment

Underlying Knowledge Forming Basis of Information Providing Method According to First Embodiment

In a first embodiment, a description will be given of an information providing method for an information device having a game application.

A user (player) is able to download a game application by using an information device such as a smartphone. Downloadable games include a game of a type in which a player can earn a game reward (game item) in accordance with the level of progress in the game.

For example, there is available a game having a rule that a user sells goods in the game and is allocated a stamp once the sales have reached the initial target. In this game, when the user's sales have reached the next target, another stamp is further allocated to the user. When the user obtains a predetermined number of stamps (for example, five stamps), the user is able to earn a game item effective for the game to proceed.

There is also available a game with a mechanism in which, for example, the time period during which a user is able to play the game is restricted and the user is not allowed to resume the same game unless a certain time period has elapsed. In this case, an effective game item has a function of reducing the certain time period described above. The effective game item allows the user to resume the same game as the game without waiting for the lapse of the certain time period described above.

The present inventor has found a method for establishing a tie-up between an application for a game of the type described above and an actual store such as a pharmacy, a grocery store, or a clothing store so that the earning of stamps or game items in the game application is linked to sales promotion for the store.

Accordingly, in the first embodiment, a description will be given of an information providing method (a game reward allocation system) for giving incentives to a player of a game to visit an actual store by utilizing the game.

Configuration

In the following, a game reward allocation system according to the first embodiment will be described.FIG. 1illustrates a schematic configuration of a game reward allocation system100.

As illustrated inFIG. 1, the game reward allocation system100includes a server10and a mobile terminal20. The server10and the mobile terminal20are connected to each other via a network40(for example, the Internet).FIG. 1also illustrates a store30that is a target for collaboration with a game executable on the mobile terminal20.

In the game reward allocation system100, a user downloads a game application (hereinafter also referred to simply as a “game app”) from the server10by using the mobile terminal20. Information on the user, such as the state of progress of the game, is stored in the server10.

In the first embodiment, furthermore, it is assumed that a game executable on the mobile terminal20is a game having a rule that a user sells goods in the game and is allocated a stamp once the sales have reached the initial target. In this game, when the user's sales have reached the next target, another stamp is further allocated to the user. When the user obtains a predetermined number of stamps (for example, five stamps), the user is able to earn a game item effective for the game to proceed.

The game reward allocation system100has a feature in that a user is not only given a stamp in the way described above in accordance with the progress of the game but also is given a stamp by bringing the mobile terminal20with them to the actual store30.

A specific configuration of the game reward allocation system100will now be described.FIG. 2is a block diagram illustrating a functional configuration of the game reward allocation system100. First, the server10will be described.

As illustrated inFIG. 2, the server10includes a server control unit11, a store information database (DB)13, a game app information DB14, and a user information DB15.

The server control unit11receives each request from the mobile terminal20, refers to the corresponding DB (the corresponding one of the store information DB13, the game app information DB14, and the user information DB15) in accordance with the request, and updates the information stored in the DB, if necessary. Further, the server control unit11transmits game-related information (such as screen information) to the mobile terminal20in accordance with the request.

Specifically, the server control unit11is a processor. The server control unit11may be of any type, such as a microcomputer or a dedicated circuit.

Next, the mobile terminal20will be described. The mobile terminal20includes a control unit21, a storage unit22, and an operating system (OS)26. The storage unit22stores a game app, and the game app includes a game unit23, a software development kit (SDK) unit24, and a server information DB25. Specifically, the mobile terminal20is a terminal having a display unit, such as a smartphone, a tablet terminal, or a laptop personal computer (PC). The display unit is not illustrated inFIG. 2.

The control unit21boots the OS26and executes the game app stored in the storage unit22. The control unit21is a processor. The control unit21may be of any type, such as a microcomputer or a dedicated circuit. In the following embodiments, a process performed by the control unit21executing a game app is expressed simply as a verb and a corresponding subject “the game unit23” or “the SDK unit24”.

Next, information stored in each of the DBs described above will be briefly described.FIG. 3illustrates information stored in the store information DB13.FIG. 4illustrates information stored in the game app information DB14.FIG. 5illustrates information stored in the user information DB15.

As illustrated inFIG. 3, the store information DB13stores store attribute information131, advertisement information132, and purchaser privilege information133.

As illustrated inFIG. 4, the game app information DB14stores stamp information141, game attribute information142, reward allocation condition information143, reward list information144, reward incidence information145, and purchaser privilege reward information146.

As illustrated inFIG. 5, the user information DB15stores user login information151, user achievement level information152, a user check-in log153, a user achievement level log154, and user reward allocation information155.

Initialization Process

Next, an initialization process for a game app executed on the mobile terminal20will be described. First, the overall flow of the initialization process will be described.FIG. 6is a sequence diagram of the initialization process.

In a game initialization process (S10), the game unit23transmits a login request to the SDK unit24(S11), and the SDK unit24performs a login request process (S12). Specifically, the SDK unit24transmits the login request to the server control unit11(S13).

The server control unit11performs a login process (S14) in accordance with the received login request. After the completion of the login process, the server control unit11transmits a user ID to the SDK unit24(S15). The SDK unit24transmits a login completion notification to the game unit23(S16).

When the login is completed, the game unit23transmits a store collaboration information obtaining request to the SDK unit24(S17), and the SDK unit24performs a store collaboration information obtaining process (S18). Specifically, the SDK unit24transmits a store collaboration information generation request to the server control unit11(S19).

The server control unit11performs a store collaboration information generation process in accordance with the received store collaboration information generation request (S20) to generate store collaboration information, and transmits the store collaboration information to the SDK unit24(S21). Then, the SDK unit24transmits a store collaboration information obtaining completion notification to the game unit23(S22).

Through the operations described above, the game initialization process (S10) is completed. Then, the game unit23performs a game screen rendering and display process (S23). Specifically, the game unit23transmits a store collaboration image rendering and display request to the SDK unit24(S24), and the SDK unit24performs a store collaboration image rendering and display process (S25). After the completion of the store collaboration image rendering and display process, the SDK unit24transmits a store collaboration image rendering and display completion notification to the game unit23.

At the time of the login process, a login screen27aillustrated inFIG. 7Ais displayed on the display unit of the mobile terminal20. At the completion of the game screen rendering and display process, a game screen27billustrated inFIG. 7Bis displayed. The game screen27bincludes a game-specific image28aand a store collaboration image28b.

Next, the details of the operations of the game unit23, the SDK unit24, and the server10(the server control unit11) in the initialization process will be described. First, the operation of the game unit23in the initialization process will be described.FIG. 8is a flowchart of the operation of the game unit23in the initialization process.

As illustrated inFIG. 8, after performing the game initialization process (S31), the game unit23transmits a login request to the SDK unit24(S32), and transmits a store collaboration information obtaining request to the SDK unit24(S33). If the game unit23has succeeded in obtaining store collaboration information (YES in S34), a store collaboration flag is turned on (S35). If the game unit23has failed to obtain store collaboration information (NO in S34), a retry is performed (YES in S36). After the retry, the store collaboration flag is turned off (S37). The retry is performed a predetermined number of times, for example.

The subsequent various process requests from the game unit23to the SDK unit24(for example, the store collaboration image rendering and display request inFIG. 6) are made only while the store collaboration flag is ON.

Subsequently, the operation of the SDK unit24in the initialization process will be described.FIG. 9is a flowchart of the operation of the SDK unit24in the initialization process.

First, the SDK unit24determines whether or not an app user ID has been generated (S41). If an app user ID has not been generated (NO in S41), the SDK unit24obtains a universally unique identifier (UUID) from the OS26, and uses the obtained UUID as an app user ID (S42).

Then, the SDK unit24creates a WebView, and transmits to the server10a login page display component request that takes the app user ID and an app ID as arguments (S43). The WebView is a function (way) for an app in the mobile terminal20(here, a game app) to display a webpage on the app.

Then, the SDK unit24receives components for displaying a login page from the server10, and displays the login screen27aon the WebView (S44). Here, the user enters a user name and a password through the mobile terminal20. That is, the SDK unit24obtains the user name and password entered by the user.

Subsequently, the SDK unit24transmits to the server10a login request that takes the user name and password entered by the user, the app user ID, and the app ID as arguments (S45). If no response is received from the server10(NO in S46), the login request is retransmitted. If a response is obtained from the server10(YES in S46), the process ends.

Next, a specific example of the component request, the login request, and responses to these requests will be described.FIGS. 10A to 10DandFIG. 11illustrate an example of Hypertext Markup Language (HTML) documents of a component request, a login request, and responses to these requests.

As illustrated inFIG. 10A, a component request29includes an app user ID29a, an app ID29b, and an action29c.

As illustrated inFIG. 10B, a login request31includes an app user ID31a, an app ID31b, an action31c, a user name31d, and a password31e.

In response to the login request31, the server10transmits a response32b(a response indicating no error) illustrated inFIG. 100(step YES in S46). If the login is not accepted with the use of a combination of the user name and password specified in the login request31, a response32cillustrated inFIG. 10Dis transmitted (NO is obtained in step S46and the process of step S45is performed again).

For the display of a login screen, a response written in HTML and JavaScript (registered trademark), such as a response32aillustrated inFIG. 11, is transmitted in response to the component request29. That is, “components” for displaying a WebView are transmitted in HTML and JavaScript (registered trademark). The first half (the portion surrounded by the upper frame inFIG. 11) of the response32adescribes a login request transmission process and a retry process when the “transmit” button is pressed on the mobile terminal20. The second half (the portion surrounded by the lower frame inFIG. 11) of the response32adescribes components for displaying the login screen27aon the display unit of the mobile terminal20.

Subsequently, the operation of the server10(the server control unit11) will be described.FIG. 12is a flowchart of the operation of the server10in the initialization process.FIG. 13illustrates the user login information151and the user achievement level information152in the user information DB15. In the user login information151, as illustrated in part (a) ofFIG. 13, a user ID151ais associated with a user name and a password. As illustrated in part (b) ofFIG. 13, in each piece of user achievement level information152fincluded in the user achievement level information152, a user ID152ais associated with an app user ID, an app ID, a game score, a level152d, a stamp sheet152b, and the number of stamps152c.

The server control unit11obtains the app user ID29a(31a), the app ID29b(31b), and the action29c(31c) from the component request29or the login request31transmitted from the mobile terminal20(S51). If the action indicates “login”, that is, if the login request31has been transmitted from the mobile terminal20(YES in S52), the server control unit11obtains the user name31dand the password31efrom the login request31(S53). Then, the server control unit11searches the user login information151to obtain the user ID151a(S54).

If the user ID151ahas been successfully obtained (YES in S55) and if a combination of the user ID151a, the app user ID31a, and the app ID31bis not found in the user achievement level information152, the server control unit11registers the combination of the user ID151a, the app user ID31a, and the app ID31bin the user achievement level information152(S56). The values other than the user ID, the app user ID, and the app ID are set to default values (for example, score=0, level=1, stamp sheet=1, and number of stamps=0). Then, the server control unit11transmits the response32bindicating a successful login to the mobile terminal20regardless of whether or not the user achievement level information152has been registered (S58).

If the server control unit11has failed to obtain a user ID (NO in S55), the server control unit11transmits the response32cindicating a login failure to the mobile terminal20(S57).

On the other hand, if, in step S52, the action indicates “View”, that is, if the component request29has been transmitted from the mobile terminal20(NO in S52), the server control unit11generates the response32abased on the app user ID29aand the app ID29b, and transmits the response32ato the mobile terminal20(S59).

Store Collaboration Information Generation Process

Next, a store collaboration information generation process in the game screen rendering and display process will be described. First, a method for obtaining store collaboration information using the SDK unit24will be described.FIG. 14is a flowchart of a method for obtaining store collaboration information.FIGS. 15A and 15Brespectively illustrate an example of a store collaboration information request and an example of store collaboration information.FIG. 16illustrates an example of server information in the server information DB25.FIG. 17illustrates an example of a stamp sheet screen.

The SDK unit24transmits a store collaboration information request33that takes an app user ID33aand an app ID33bas arguments (S61). Then, the SDK unit24receives store collaboration information34from the server control unit11, and stores the store collaboration information34in the server information DB25as server information35(S62). Then, the SDK unit24notifies the game unit23of the completion of obtainment of the store collaboration information34(S63).

The store collaboration information34is information for generating a store collaboration image. The store collaboration information34includes a response34a, the number of stamps34b, and a message34c, and the server information35also includes the pieces of information described above.

The response34ais information indicating whether or not the server control unit11has succeeded in generating the store collaboration information34(whether or not the store collaboration information34has been generated without errors). The response34adescribes “NONE” if the store collaboration information34has been successfully generated, “connection_error” if network access to the server control unit11has failed, and “bad_app_id” If no app ID is registered in the server10.

The number of stamps34bis information indicating how many stamps an app user specified (or identified) by an app user ID has obtained in a game specified by an app ID. In the first embodiment, the number of stamps34bis expressed by the number of earned stamps/the number of goal stamps. The number of goal stamps is the number of stamps with which a stamp sheet is filled, and is “5” in the first embodiment. Accordingly, if, as illustrated inFIG. 17, no stamp is placed on a stamp sheet screen27c, the number of stamps34bis expressed as 0/5.

The message34cis a message for inspiring the user with a visit to the store30. The message34cis generated by the server control unit11.

Next, a process for generating the store collaboration information34using the server10(the server control unit11) will be described.FIG. 18is a flowchart of a method for generating the store collaboration information34.FIG. 19illustrates an example of the store attribute information131in the store information DB13.FIG. 20illustrates an example of the stamp information141in the game app information DB14.

The server control unit11extracts the app user ID33aand the app ID33bfrom the store collaboration information request33received from the control unit21(the SDK unit24) (S71). Then, the server control unit11obtains the corresponding user achievement level information152ffrom the user information DB15on the basis of the extracted app user ID33aand app ID33b(S72).

Subsequently, the server control unit11obtains a certain number of pieces of store attribute information131(FIG. 19) from the store information DB13(S73), and randomly selects one of the obtained pieces of store attribute information131(S74). The details of the process of step S73will be described below.

Then, the server control unit11obtains the number of goal stamps in the number of stamp sheets of the app corresponding to the app ID33bfrom the stamp information141in the game app information DB14(S75). The number of stamp sheets is specified by the stamp sheet152bincluded in the user achievement level information152f, and is “2” here. In addition, as indicated in stamp information141aillustrated inFIG. 20, the number of goal stamps is “5”.

Finally, the server control unit11generates store collaboration information34, and transmits the generated store collaboration information34to the mobile terminal20(S76). The store collaboration information34includes the number of earned stamps specified by the number of stamps152cincluded in the user achievement level information152f, the number of goal stamps, and a message included in the store attribute information selected in step S74(for example, a message36fif the store attribute information selected in step S74is store attribute information131d).

Next, an example of a process for obtaining a certain number of pieces of store attribute information131from the store information DB13(the process of step S73described above) will be described.FIG. 21AandFIG. 21Billustrate a flowchart of a process for obtaining a certain number of pieces of store attribute information131from the store information DB13.FIGS. 22A and 22Brespectively illustrate an example of the user check-in log153and an example of the game attribute information142.

In the following description, an example is provided in which the server control unit11extracts a certain number of pieces of store attribute information131by using a check-in list CL, store lists SL1and SL2, and a score SC.

The server control unit11obtains check-in information on check-ins (a history of check-ins) made over a certain period (for example, if the certain period is one month and the current time is 12:00 on Feb. 7, 2014, pieces of check-in information153aand153billustrated inFIG. 22Ain which the times are within a period from 12:00 on Jan. 7, 2014 to 12:00 on Feb. 7, 2014) from the user check-in log153in the user information DB15, and adds the obtained check-in information to the check-in list CL (S81). Then, the server control unit11empties the store list SL1(S82), and determines whether or not the check-in list CL is empty (S83).

If the check-in list CL is not empty (NO in S83), the server control unit11extracts a piece of check-in information from the check-in list CL (S84). Further, the server control unit11refers to the store attribute information131to obtain the store attribute information131having a store ID that matches the store ID indicated by the extracted check-in information, and adds the obtained store attribute information131to the store list SL1(S85). For example, the check-in information153aillustrated inFIG. 22Ais extracted. In this case, a store ID153crepresents str00005, and thus store attribute information131eamong the pieces of store attribute information131illustrated inFIG. 19is obtained.

Further, the server control unit11refers to the store attribute information131to obtain store attribute information131on a store located nearby the store indicated by the store ID153cin the check-in information153a, and adds the obtained store attribute information131to the store list SL1(S86). The presence or absence of a nearby store is determined by calculating the distance between the stores by using the latitude and longitude included in the store attribute information131. Specifically, if the distance between the stores is less than or equal to a certain value (for example, within 500 m), it is determined that the stores are nearby. When store attribute information131on a nearby store within 500 m is searched for using Structured Query Language (SQL), a description illustrated inFIG. 23is used. For example, store attribute information131band store attribute information131dare pieces of store attribute information having latitude and longitude within 500 m from the store attribute information131e(with a latitude of 34.72101 and a longitude of 135.3122). In this case, the store attribute information131band the store attribute information131dare added to the store list SL1.

The processes of steps S84to S86are performed until the check-in list CL becomes empty (YES in S83).

Then, the server control unit11obtains, from the game attribute information142in the game app information DB14, game attribute information (here, game attribute information142a) having an app ID that matches the app ID33bincluded in the store collaboration information request33(S87).

If the store list SL1is not empty (NO in S88), the server control unit11sets the score SC=0, and extracts a piece of store attribute information131from the store list SL1(S89). If the genre tendency in the extracted store attribute information131(hereinafter also referred to as “the target store attribute information131”) is identical to a genre142bin the game attribute information142a, the server control unit11adds a predetermined value (the value in parentheses in the genre tendency in the store attribute information131, for example, 0.5 for the store attribute information131d) to the score SC of the target store attribute information131(S90).

If the app tendency in the target store attribute information131is identical to the app ID33bincluded in the store collaboration information request33, the server control unit11adds a predetermined value (the value in parentheses in the app tendency in the store attribute information131, for example, 0.2 for store attribute information131a) to the score SC of the target store attribute information131(S91).

If the developer tendency in the target store attribute information131is identical to a developer142cin the game attribute information142a, the server control unit11adds a predetermined value (the value in parentheses in the developer tendency in the store attribute information131, for example, 0.3 for the store attribute information131b) to the score SC of the target store attribute information131(S92).

Finally, the server control unit11adds to the store list SL2the target store attribute information131in which the score SC calculated in steps S90to S92is included, and rearranges the pieces of store attribute information131in the store list SL2in descending order from the highest score SC (S93).

The processes of steps S89to S93are performed on each piece of store attribute information131in the store list SL1until the store list SL1becomes empty (YES in S88).

Through the process described above, a certain number of top-ranked pieces of store attribute information131in the store list SL2, that is, a certain number of nearby stores that the player has visited over a past certain period and that have high relevance to the game app currently being played by the player, are extracted (S94).

Game Screen Rendering and Display Process

A game screen rendering and display process that uses the store collaboration information34described above will be described.FIG. 24is a flowchart of the game screen rendering and display process.FIG. 25is a flowchart of a process for generating the store collaboration image28b.FIG. 26illustrates an example of the store collaboration image28b.

As illustrated inFIG. 24, first, the game unit23renders and displays the game-specific image28a(S101). If the store collaboration flag is ON (YES in S102), the game unit23transmits a request for rendering and displaying the store collaboration image28bto the SDK unit24(S103).

As illustrated inFIG. 25, upon receipt of the request for rendering and displaying the store collaboration image28b, the SDK unit24first renders a background portion of the store collaboration image28b(FIG. 26) (S111). Subsequently, the SDK unit24obtains the number of stamps34b(the number of earned stamps and the number of goal stamps) from the store collaboration information34(S112), and renders a number-of-stamps display portion28cof the store collaboration image28b(S113).

The SDK unit24further obtains the message34cfrom the store collaboration information34(S114), and renders a message display portion28dof the store collaboration image28b(S115). In the message display portion28d, the message34cis displayed as scrolling text.

Game Process and Reward Allocation Process

Next, a game process and a reward allocation process will be described.FIG. 27is a sequence diagram of the game process and the reward allocation process.

In the game process of S121, the game unit23transmits an achievement level transmission request to the SDK unit24(S122). Upon receipt of the achievement level transmission request, the SDK unit24performs an achievement level transmission process (S123). Specifically, the SDK unit24transmits a reward allocation determination request to the server control unit11(S124). The reward allocation determination request includes an achievement level.

The server control unit11performs a reward allocation determination process in accordance with the transmitted reward allocation determination request (S125). If it is determined that reward allocation is not necessary, the server control unit11transmits a response (reward allocation information) indicating the absence of reward allocation to the SDK unit24(S126). Then, the SDK unit24transmits the response indicating the absence of reward allocation (reward allocation information) to the game unit23(S127).

If a reward is to be allocated, the game unit23also transmits an achievement level transmission request to the SDK unit24(S128), and the SDK unit24performs an achievement level transmission process (S129and S130). The server control unit11performs a reward allocation determination process in accordance with the transmitted reward allocation determination request (S131). If it is determined that reward allocation is necessary, the server control unit11transmits a response (reward allocation information) indicating the presence of reward allocation to the SDK unit24(S132). Then, the SDK unit24transmits the response indicating the presence of reward allocation to the game unit23(S133).

Upon receipt of the response indicating the presence of reward allocation, the game unit23transmits a reward screen display request to the SDK unit24(S134). Upon receipt of the reward screen display request, the SDK unit24performs a reward screen display process (S135). Specifically, the SDK unit24transmits a reward screen information request to the server control unit11(S136). Upon receipt of the reward screen information request, the server control unit11generates reward screen information (S137), and transmits the generated reward screen information to the SDK unit24(S138). The SDK unit24displays an indication of obtaining of a reward on the display unit of the mobile terminal20by using the received reward screen information.

After displaying the reward screen information, the SDK unit24performs a reward allocation process (S139). Specifically, the SDK unit24transmits a reward information request to the server control unit11(S140). Upon receipt of the reward information request, the server control unit11generates reward information (S141), and transmits the generated reward information to the SDK unit24(S142).

The SDK unit24transmits the received reward information to the game unit23(S143), and the game unit23performs a reward process (S144).

As described above, in a game according to the first embodiment, a user sells goods in the game and is allocated a stamp once the sales have reached a predetermined amount.FIG. 28illustrates the game screen27bwhen goods are sold in a game.

As illustrated in part (a) ofFIG. 28, the sales figures are shown in the upper left portion of the game screen27b. As illustrated in part (b) ofFIG. 28, if goods in the game are sold with sales of “190 G” (G is the unit of currency in the game), as illustrated in part (c) ofFIG. 28, sales increase. In the illustrated example, the amount of “80 G” is added, resulting in the total sales amounting to “270 G”. The increase in sales is included in the achievement level transmission request described above as an “achievement level”, and the achievement level is transmitted from the game unit23to the SDK unit24. The achievement level is also included in the reward allocation determination request described above, and is transmitted from the SDK unit24to the server control unit11.

The process for the allocation of stamps in accordance with the achievement level, that is, the process for the addition of stamps on the stamp sheet screen27cdescribed above, is included in the reward allocation determination process described above. Note that the process for displaying a stamp sheet is included in the reward screen display process described above.FIG. 29illustrates how stamps are issued in the stamp sheet screen27c.

As illustrated in parts (a) to (e) ofFIG. 29, in the reward allocation determination process, stamps are given one by one as rewards each time a certain achievement is made in the game. Further, screens on which stamps are issued one by one in the stamp sheet screen27care generated through a reward screen information generation process. Stamps are reward information managed by the server10. The game unit23does not need to have awareness of the number of earned stamps or the number of goal stamps. If the number of earned stamps has reached the number of goal stamps (here, five), as illustrated in part (f) ofFIG. 29, the user is allocated an item of value in the game.

The item allocated to the user is information to be subjected to an allocation process by the game unit23, unlike a stamp. While the display regarding the allocation of items is performed by using the reward screen information generation process, a process for reflecting an allocated item in the game is performed by the game unit23in a reward process upon receipt of reward information transmitted from the SDK unit24.

Next, the game process and the reward process will be described in detail with reference to a flowchart.FIG. 30is a flowchart of the game process and the reward process.

If reward information has been received from the SDK unit24, that is, if reward information is present (YES in S151), the game unit23updates a game control variable/DB in accordance with the reward information (S158).

If no reward information is found (NO in S151) or after the process of step S158, a game-specific logic process is performed (S152). Then, the game unit23transmits an achievement level transmission request to the SDK unit24(S153).

If a response indicating the presence of reward allocation has been received (YES in S154), the game unit23transmits a reward screen display request to the SDK unit24, and waits for the display of a reward screen to be completed (S157).

If the game unit23has received a response indicating the absence of reward allocation (NO in S154) or after the display of a reward screen has been completed, the game unit23performs a game-specific image rendering and display process (S155), and the SDK unit24performs a store collaboration image rendering and display process (S156). Then, the presence or absence of reward information is determined again (S151).

Next, the achievement level transmission process performed by the SDK unit24will be described in detail with reference to a flowchart.FIG. 31is a flowchart of the achievement level transmission process.FIGS. 32A and 32Brespectively illustrate an example of a reward allocation determination request and an example of reward allocation information.

As illustrated inFIG. 31, the SDK unit24transmits to the server10(the server control unit11) a reward allocation determination request38that takes an app user ID38a, an app ID38b, and an achievement level38cas arguments (S161). Then, the SDK unit24receives reward allocation information39from the server10(S162). The reward allocation information39includes a response39aindicating whether an error is present or not, and a response39bindicating whether reward allocation is present or not.

If the response39bincluded in the reward allocation information39indicates the presence of reward allocation (YES in S163), the SDK unit24transmits a response indicating the presence of reward allocation to the game unit23(S164). On the other hand, if the response39bincluded in the reward allocation information39indicates the absence of reward allocation (NO in S163), the SDK unit24transmits a response indicating the absence of reward allocation to the game unit23(S165).

Next, the reward allocation determination process performed by the server control unit11will be described in detail with reference to a flowchart.FIG. 33is a flowchart of the reward allocation determination process.FIG. 34illustrates an example of the reward allocation condition information143.FIG. 35illustrates an example of the user achievement level log154(parts (a) and (b) ofFIG. 35) and an example of the user reward allocation information155(part (c) ofFIG. 35).

The server control unit11obtains the app user ID38a, the app ID38b, and the achievement level38cfrom the reward allocation determination request38received from the SDK unit24(S171). The server control unit11refers to the user achievement level information152in the user information DB15, and obtains the user achievement level information152fcorresponding to the combination of the app user ID38aand the app ID38b(S172).

Then, the server control unit11adds the current time to the app user ID38a, the app ID38b, and the achievement level38cto generate user achievement level log information154a, and adds the user achievement level log information154ato the user achievement level log154(S173). Further, the server control unit11refers to the reward allocation condition information143, and obtains reward allocation condition information143acorresponding to the app ID38band the user's level (S174). As illustrated inFIG. 34, the reward allocation condition information143aincludes a reward ID143b.

If the reward allocation condition information143ais satisfied as a result of totaling items in the user achievement level log154(YES in S175), the server control unit11generates the user reward allocation information155(S177). As illustrated in part (c) ofFIG. 35, specific user reward allocation information155aincludes an app user ID corresponding to the app user ID38a, an app ID corresponding to the app ID38b, a reward ID corresponding to the reward ID143b, a gift ID, a screen display completion flag, and a reward allocation completion flag. The gift ID is set to any unique value (for example, an integer that monotonically increases from 1 and that is not redundantly used for other user reward allocation information). Both the screen display completion flag and the reward allocation completion flag are set to “FALSE” at this time.

Then, the server control unit11transmits the reward allocation information39in which the response39bindicates the presence of reward allocation to the SDK unit24(S178).

If the reward allocation condition information143ais not satisfied as a result of totaling items in the user achievement level log154in step S175(NO in S175), the server control unit11transmits the reward allocation information39in which the response39bindicates the absence of reward allocation to the SDK unit24(S176).

Next, the reward screen display process will be described in detail with reference to a flowchart.FIG. 36is a flowchart of the reward screen display process.FIG. 37illustrates an example of a reward screen information request.FIG. 38illustrates an example of reward screen information in a case where the stamp sheet screen27cis displayed.FIG. 39illustrates an example of reward screen information in a case where an item allocation screen is displayed.

The SDK unit24creates a WebView, and transmits to the server10(the server control unit11) a reward screen information request41that takes an app user ID41aand an app ID41bas arguments (S181).

Then, the SDK unit24receives reward screen information42a(or reward screen information42b) from the server control unit11, and displays the stamp sheet screen27c(or an item allocation screen27d) on the WebView as a reward screen (S182).

For example, four stamps have been issued in the stamp sheet screen27cand the fifth stamp is to be issued. In this case, the reward screen information42ais written as in the thick-line frame inFIG. 38. Further, for example, the item allocation screen27dis displayed on which the image of an item, the name of the item, and the number of items are specified. In this case, the reward screen information42bis written as illustrated inFIG. 39. That is, the screen display process showScreen( ) which is written in JavaScript (registered trademark), dynamically shows a stamp allocation screen or a reward screen in accordance with the argument. The details of the process showScreen( ) are not described herein.

If the reward screen information42a(or the reward screen information42b) includes game-side reward allocation information42d(YES in S183), a reward allocation process is performed (S184). The game-side reward allocation information42dis specifically “location.href=”appcmd:gift=“+GIFT_ID” shown in the 14th row of the reward screen information42b. This is a typical method for invoking the reward allocation process for the SDK unit24from a process written in JavaScript (registered trademark).

While location.href=URL is used for the switching of the Web page currently displayed in the WebView to a uniform resource locator (URL), the WebView asks the SDK unit24, which has generated the WebView, about the possibility of the switching. If the URL and appcmd: match at the beginning, the SDK unit24does not determine that the switching to a URL is performed but determines that a process request has been made to the SDK unit24from JavaScript (registered trademark). In the case of the reward screen information42b, the reward allocation process is performed by passing “gift=1” as an argument.

The process shown in the 14th row of the reward screen information42bis an internal process of the function screen_show_completed( ) The function screen_show_completed( ) is designated as an argument of showScreen( ) and showScreen( ) invokes screen_show_completed( ) after the display of a reward screen.

Next, the reward screen information generation method will be described with reference to a flowchart.FIG. 40is a flowchart of the reward screen information generation method.FIG. 41illustrates an example of the reward list information144.

The server control unit11obtains the app user ID41aand the app ID41bfrom the reward screen information request41(S191). Then, the server control unit11obtains from the user reward allocation information155the user reward allocation information155acorresponding to the obtained app user ID41aand app ID41b(S192). In this case, the search conditions include a condition that the screen display completion flag is “FALSE”, that is, a condition that the search is limited to only the user reward allocation information155a, which has not been displayed.

Then, the server control unit11obtains from the reward list information144reward list information144acorresponding to the app ID41band the obtained user reward allocation information155(S193).

If the reward type in the reward list information144ais stamp (YES in S194), the server control unit11generates the reward screen information42a(S195). Specifically, the server control unit11generates the reward screen information42aby using the stamp sheet152band the number of stamps152c, which are included in the user achievement level information152f, and also by using the number of stamps after reward allocation, which is obtained by adding “the number of rewards” in the reward list information144ato the number of stamps152c(or the number of goal stamps if the number of stamps obtained as a result of addition exceeds the number of goal stamps).

If the reward type in the reward list information144ais item (NO in S194), the server control unit11generates the reward screen information42bby using the gift ID included in the user reward allocation information155aand also by using the reward image and reward name included in the reward list information144a(S196).

Finally, the server control unit11sets the screen display completion flag in the user reward allocation information155to “TRUE” (ON), and transmits the reward screen information42a(or the reward screen information42b) to the SDK unit24(S197). The server control unit11may transmit the reward screen information42a(or the reward screen information42b) to the SDK unit24and then set the screen display completion flag in the user reward allocation information155to “TRUE”.

Next, the reward allocation process (S184inFIG. 36) will be described in detail with reference to a flowchart.FIG. 42is a flowchart of the reward allocation process.FIGS. 43A and 43Brespectively illustrate an example of a reward information request and an example of reward information.

The SDK unit24obtains the gift ID from the reward screen information42a(or the reward screen information42b) transmitted from the server control unit11(S201). Then, the SDK unit24generates a reward information request43that takes an app user ID43a, an app ID43b, and a gift ID43cas arguments, and transmits the reward information request43to the server control unit11(S202).

Then, the SDK unit24receives reward information44from the server control unit11(S203). If the reward information44includes a response indicating no error (“ERROR”:“NONE”) (YES in S204), the SDK unit24transmits reward information for the game unit23to the game unit23(S205). The reward information for the game unit23at least includes the reward ID and the number of rewards of the reward information44.

Next, a reward information generation process will be described in detail with reference to a flowchart.FIG. 44is a flowchart of the reward information generation process.

The server control unit11obtains the app user ID43a, the app ID43b, and the gift ID43cfrom the reward information request43obtained from the SDK unit24(S211). Then, the server control unit11obtains from the user reward allocation information155the user reward allocation information155acorresponding to the app user ID43a, the app ID43b, and the gift ID43c(S212). In this case, the search conditions also include a condition that the reward allocation completion flag is “FALSE”.

If the corresponding user reward allocation information155ahas been successfully obtained (YES in S213), the server control unit11obtains from the reward list information144the reward list information144acorresponding to the app ID43band the reward ID included in the user reward allocation information155a(S214).

If the reward type in the reward list information144ais stamp (YES in S215), the server control unit11obtains from the user achievement level information152the user achievement level information152fcorresponding to the app user ID43aand the app ID43b(S216). Then, the server control unit11adds the number of rewards (the number of stamps) specified by the reward list information144ato the number of stamps in the user achievement level information152f, and further generates and transmits the reward information44(S217). Accordingly, as illustrated in part (c) ofFIG. 13described above, the number of stamps in the user achievement level information152fis increased.

If the reward type in the reward list information144ais item (NO in S215), the server control unit11generates and transmits the reward information44(S218). In this case, the reward information44includes the reward ID included in the user reward allocation information155aand the number of rewards included in the reward list information144a.

After step S217or step S218, the server control unit11sets the reward allocation completion flag in the user reward allocation information155ato “TRUE” (S219).

If the corresponding user reward allocation information155ahas not been successfully obtained in step S213(NO in S213), the server control unit11generates and transmits reward information44which includes a response (“ERROR”:“NO_REWARD_FOUND”) indicating the occurrence of an error (S220).

Although not illustrated in the drawings, in the stamp adding process described above, if the number of stamps exceeds the number of goal stamps, the server control unit11obtains the reward ID of the current stamp sheet152bfrom the stamp information141, and generates user reward allocation information155a. The procedure of the generation of user reward allocation information is similar to that of step S177, and is not described in detail herein. In addition, the server control unit11updates the user achievement level information152f(that is, the number of stamp sheets is incremented by 1 and the number of stamps is reset).

Reward Allocation Based on Check-in

Next, reward allocation based on a check-in (or a purchase at the store30), which is a characteristic process of the game reward allocation system100, will be described.FIG. 45is a sequence diagram of reward allocation based on a check-in. In the first embodiment, the term “check-in” refers to a process in which the mobile terminal20obtains identification information (in the first embodiment, information including a store ID or a buying ID) for allocating a stamp by, for example, reading a two-dimensional code provided in the store30by using an imaging unit of the mobile terminal20.

First, the SDK unit24performs a behavior-preliminary-to-visit detection process (S221), and transmits a nearby store determination request to the server control unit11(S222). The server control unit11performs a nearby store determination process (S223), and transmits nearby store information to the SDK unit24(S224).

The SDK unit24transmits a display switching request to the game unit23in accordance with the result of the nearby store determination process (S225). At this time, the game unit23is in the game process (S226). Thus, after receiving the display switching request, the game unit23makes the game process proceed to continuously have the player enjoy the game experience. Then, the game unit23transmits a visit information obtaining request to the SDK unit24(S227). The game unit23may display a button indicating “the switching to a check-in screen” upon receipt of the display switching request, and transmit a visit information obtaining request to the SDK unit24at the timing when the user presses the button.

Then, the SDK unit24performs a visit information obtaining process (S228). Specifically, the SDK unit24transmits a check-in request (or a purchase request) to the server control unit11(S229), and the server control unit11performs a check-in process (or a purchase process) (S230). If reward allocation is necessary, the server control unit11transmits a response (reward allocation information) indicating the presence of reward allocation to the SDK unit24(S231). Subsequently, a series of processes from the reward screen display process (S232) through the reward process (S241) is performed. These processes are similar to those described above, and are not described in detail herein.

Next, the behavior-preliminary-to-visit detection process will be described in detail with reference to a flowchart.FIG. 46is a flowchart of the behavior-preliminary-to-visit detection process.FIGS. 47A and 47Brespectively illustrate an example of a nearby store determination request and an example of nearby store information.

First, the SDK unit24activates a position information obtaining unit included in the mobile terminal20, and obtains position information (S251). Specifically, the position information obtaining unit is a global positioning system (GPS) module. The position information obtaining unit may be of any type that is capable of obtaining the position of the mobile terminal20.

Then, the SDK unit24generates a nearby store determination request45, and transmits the nearby store determination request45to the server control unit11(S252). As illustrated inFIG. 47A, the nearby store determination request45includes an app user ID45a, an app ID45b, and position information45c.

Then, the SDK unit24receives nearby store information46from the server control unit11(S253). As illustrated inFIG. 47B, the nearby store information46includes a response46aindicating whether or not there is a nearby store.

If there is a nearby store, that is, if the response46aincluded in the nearby store information46indicates the presence of a nearby store (YES in S254), the SDK unit24transmits a display switching request to the game unit23(S255).

The nearby store determination process will now be described in detail with reference to a flowchart.FIG. 48is a flowchart of the nearby store determination process.

The server control unit11obtains the app user ID45a, the app ID45b, and the position information45cfrom the received nearby store determination request45(S261). Then, the server control unit11refers to the store attribute information131, and obtains store attribute information on a store located within a predetermined range (S262). The server control unit11obtains store attribute information on a store located within a range of, for example, 500 m from the position indicated by the position information45c.

If one or more pieces of store attribute information have been successfully obtained (YES in S263), the server control unit11generates nearby store information46in which the response46aindicates the presence of a nearby store, and transmits the nearby store information46to the SDK unit24(S264). If no store attribute information has been successfully obtained (NO in S263), the server control unit11generates nearby store information46in which the response46aindicates the absence of a nearby store, and transmits the nearby store information46to the SDK unit24(S265).

Next, the visit information obtaining process will be described in detail with reference to a flowchart.FIG. 49is a flowchart of the visit information obtaining process.FIGS. 50A and 50Brespectively illustrate an example of a check-in request and an example of reward allocation information.FIG. 51illustrates an example of a two-dimensional code available for check-ins.

First, the SDK unit24activates the imaging unit included in the mobile terminal20, and causes the imaging unit to read a two-dimensional code to obtain a store ID (identification information including a store ID) from the two-dimensional code (S271). As illustrated inFIG. 51, a panel on which a two-dimensional code is printed is installed in the store30. The two-dimensional code includes a store ID as information. A user visits the store30and reads the two-dimensional code by using the mobile terminal20. The two-dimensional code may be, for example, a QR code (registered trademark), or may be any other two-dimensional code. As an alternative to a two-dimensional code, other identification information such as a barcode may be used. The ID obtained in step S271may be a purchase ID described below.

Then, the SDK unit24activates the position information obtaining unit included in the mobile terminal20, and obtains position information (S272).

Then, the SDK unit24generates a check-in request47, and transmits the check-in request47to the server control unit11(S273). As illustrated inFIG. 50A, the check-in request47includes an app user ID47a, an app ID47b, position information47c, and a store or purchase ID47d.

Then, the SDK unit24receives reward allocation information48from the server control unit11(S274). As illustrated inFIG. 50B, the reward allocation information48includes a response48aindicating the presence or absence of reward allocation.

If reward allocation is present (YES in S275), the SDK unit24notifies the game unit23that a reward screen is displayed (S276). Then, the reward screen display process described above is performed. Note that the reward screen display process actually performed here is different from the reward screen display process described above in that, for example, a banner advertisement is displayed.

Then, the check-in process (or purchase process) will be described in detail with reference to a flowchart.FIG. 52is a flowchart of the check-in process (or purchase process).FIG. 53illustrates an example of the reward incidence information145.FIG. 54illustrates an example of the advertisement information132.FIG. 55illustrates an example of the purchaser privilege information133.

The server control unit11receives the check-in request47from the SDK unit24, and obtains the app user ID47a, the app ID47b, the position information47c, and the store or purchase ID47dfrom the received check-in request47(S281).

In order to determine whether the store or purchase ID47dis a store ID or a purchase ID, the server control unit11refers to the purchaser privilege information133, and obtains purchaser privilege information133ahaving a purchase ID that matches the store or purchase ID47d(S282). If the purchaser privilege information133ahas not been successfully obtained (NO in S283), the server control unit11determines that the store or purchase ID47dis a purchase ID. Then, the server control unit11refers to the store attribute information131, and obtains store attribute information (by way of example, the store attribute information131a) having a store ID that matches the store or purchase ID47d(S284). If the purchaser privilege information133ahas been successfully obtained (YES in S283), a purchaser privilege granting process described below is performed (S296).

The store attribute information131ato be obtained in step S284is store attribute information131ahaving a store ID47d(hereinafter referred to as “the store ID47d” instead of the store or purchase ID47d) and position information (latitude and longitude) indicating a position close to the position indicated by the obtained position information47c. If store attribute information131asatisfying the conditions described above has not been successfully obtained (NO in S285), the server control unit11transmits reward allocation information which includes a response indicating the absence of reward allocation to the SDK unit24(S286).

The processes of steps S284to S286mean that it is not sufficient to read a two-dimensional code in order for a user to receive a reward allocated based on a check-in and that it is necessary to read a two-dimensional code at or near the store30. The configuration described above may reliably draw users to the store30.

If store attribute information131asatisfying the conditions has been successfully obtained in step S285(YES in S285), the server control unit11refers to the user achievement level information152, and obtains the user achievement level information152fhaving an app user ID and an app ID respectively corresponding to the app user ID47aand the app ID47b. The server control unit11extracts the user ID152afrom the obtained user achievement level information152f(S287). Then, the server control unit11refers to the user check-in log153, and obtains check-in information (by way of example, the check-in information153a) having a user ID corresponding to the extracted user ID152aand having a time that is a time of the day (S288).

If the check-in information153ahas been successfully obtained (YES in S289), the server control unit11transmits reward allocation information which includes a response indicating the absence of reward allocation to the SDK unit24(S286).

The processes of steps S287to S289are performed in order to allow a user to receive a reward allocated based on a check-in once a day. The period necessary to again receive a reward allocated based on a check-in is not limited to one day described above, and may be set as desired. In a case where a reward is allocated once regardless of the period, there is no need for the determination of a time in steps S287to S289.

If the check-in information153ahas not been successfully obtained in step S289(NO in S289), the server control unit11adds (or registers) to the user check-in log153check-in information including a user ID, a store ID, and an app ID respectively corresponding to the user ID152a, the store ID47d, and the app ID47b, and also including the current time (S290).

Then, the server control unit11extracts the level152dfrom the user achievement level information152fobtained in step S287, and refers to the reward incidence information145to obtain one or more pieces of reward incidence information145ahaving an app ID and a level respectively corresponding to the app ID47band the level152d(S291).

The level152dis a level of progress indicating the state of progress of the game. The level152dis used to change the content of a reward in accordance with the level of progress.

For example, the number of stamps or items to be allocated as rewards is set to increase in accordance with an increase in the level of progress in the game. In games, the difficulty level generally increases with the level of progress in the games. In order to maintain game balance, the settings described above are made.

Then, the server control unit11randomly selects one of the obtained one or more pieces of reward incidence information145a(S292). The random selection is based on the reward incidence included in the reward incidence information145. Further, the server control unit11extracts the reward ID included in the randomly selected reward incidence information145(S293). In addition, the server control unit11extracts advertisement information132aassociated with the store ID47dfrom the advertisement information132(S294). Since the advertisement information132is information used in combination with the store attribute information131, the advertisement information132includes no store ID, for example.

Finally, the server control unit11performs the reward screen information generation process (in steps S193to S197inFIG. 40) in accordance with the reward ID extracted in step S293(S295).

When the advertisement information132ahas been successfully extracted in step S294, a reward screen information having added thereto a banner image (banner information) included in the extracted advertisement information132ais generated.FIG. 56illustrates an example of reward screen information42chaving added thereto a banner image. The reward screen information42cillustrated inFIG. 56is used for the display of the item allocation screen27d. The same applies to reward screen information used for the display of the stamp sheet screen27c.

According to the reward screen information42cillustrated inFIG. 56, the item allocation screen27dincluding a banner image is displayed on the display unit of the mobile terminal20. As in the item allocation screen27d, the banner image may have an indication that, for example, a purchase at a store where a two-dimensional code for check-ins is provided enables the purchaser to have an additional stamp allocated. Such a banner image may encourage the user to purchase goods in the store30.

Next, the purchaser privilege granting process will be described.FIGS. 57A and 57Billustrate examples of tickets with printed two-dimensional codes to be used for the purchaser privilege granting process.

The tickets illustrated inFIGS. 57A and 57Bmay be each a sheet of paper having approximately a business card size and containing a two-dimensional code including a purchase ID. The tickets are distributed when goods are purchased in the store30. In the first embodiment, different tickets are distributed in accordance with the amount of purchased goods. For example, the ticket illustrated inFIG. 57Ais distributed to a user who has purchased goods amounting to less than a predetermined amount (here, 1000 yen), and the ticket illustrated inFIG. 57Bis distributed to a user who has purchased goods amounting to the predetermined amount or more. That is, different types of tickets are distributed in accordance with the purchase amount of the user. The tickets illustrated inFIGS. 57A and 57Bare distributed in exchange for the purchase of goods. Unlike the two-dimensional code for check-ins (FIG. 51) which is provided in the store30, the tickets illustrated inFIGS. 57A and 57Bare not necessarily read at or near the store30.

In the following, the purchaser privilege granting process (the process when YES is obtained in step S283inFIG. 52) will be described in detail with reference to a flowchart.FIG. 58is a flowchart of the purchaser privilege granting process.FIG. 59illustrates an example of the purchaser privilege reward information146.

If a used flag in the purchaser privilege information133aobtained in step S283inFIG. 52is “TRUE” (YES in S301), the server control unit11transmits reward allocation information which includes a response indicating the absence of reward allocation to the SDK unit24(S302).

If the used flag in the purchaser privilege information133aobtained in step S283inFIG. 52is “FALSE” (NO in S301), the server control unit11refers to the purchaser privilege reward information146, and obtains purchaser privilege reward information146a(S303). The purchaser privilege reward information146ato be obtained here is purchaser privilege reward information having a purchaser privilege ID that matches the purchaser privilege ID included in the purchaser privilege information133a.

Then, the used flag in the purchaser privilege information133ais updated to “TRUE” (S304). Then, the server control unit11performs the reward screen information generation process (in steps S193to S197inFIG. 40) in accordance with the reward ID included in the obtained purchaser privilege reward information146a(S305).

As described above, the game reward allocation system100according to the first embodiment allows a user to obtain a reward similar to a reward obtained during the progress of the game on the basis of a check-in.

In the game reward allocation system100, a gaming technique in which an accumulation of small achievements is expressed with effective visual effects such as printed stamps, and makes the user feel like a major achievement and gain rewards can be applied to the actual activity of the user (the visit to a store). This technique is called gamification and such a technique has been demonstrated to be effective. Gamification is a methodology of applying game mechanics to activities in other fields, such as health activities and educational activities, to improve engagement in such activities.

In order to implement the game reward allocation system100, it may be sufficient that the SDK described above (the SDK unit24) be incorporated in an existing game application (the game unit23). In other words, it is easy to add the reward allocation function based on a check-in described above to an existing game application. That is, the game reward allocation system100can have high versatility.

Conclusion

An information providing method using the game reward allocation system100according to the first embodiment has been described. The game reward allocation system100is connected to the mobile terminal20via the network40. The mobile terminal20has installed thereon an application for a game of a type in which game rewards are earned in accordance with the level of progress in the game, and also has a display.

The game reward allocation system100is an example of an information management system, and the mobile terminal20is an example of an information device. Further, a game reward is specifically a stamp or an item obtainable in a game.

In the information providing method according to the first embodiment, the mobile terminal20obtains identification information (information included in a two-dimensional code) which includes a store ID indicating a given store, and, from the mobile terminal20, an app ID indicating a game application that is running on the mobile terminal20and a user ID (app user ID) indicating a user of the game application, as well as the store ID, are received via the network40.

In the information providing method according to the first embodiment, furthermore, a first database (the user information DB15) and a second database (the game app information DB14) are referred to in accordance with the app ID and the app user ID, and first instruction data (reward screen information) indicating that a first game reward corresponding to the level of progress in the game be allocated is transmitted to the mobile terminal20via the network40.

In the user achievement level information152in the user information DB15, the user's level of progress in the game is managed in association with the app ID and the user ID. In the reward incidence information145in the game app information DB14, a first game reward ID (reward ID) indicating a first game reward allocated in accordance with the app ID and the level of progress is managed.

In the information providing method, furthermore, specifically, a third database (the store attribute information131in the store information DB13) that manages registered stores which have been registered is referred to, and it is determined whether or not the registered stores include the store indicated by the received store ID (S285inFIG. 52). If the registered stores include the store indicated by the received store ID, the first instruction data is transmitted to the mobile terminal20via the network40(S295inFIG. 52).

The identification information described above includes first position information indicating the position of the given store (a store ID included in the identification information is associated with the position information (latitude and longitude) in the store attribute information131).

In the information providing method, accordingly, second position information indicating the position of the mobile terminal20is obtained from the mobile terminal20by using a GPS system (S281inFIG. 52). If the position indicated by the second position information is within a predetermined distance range from the position indicated by the first position information (YES in S285inFIG. 52), the first instruction data is transmitted to the mobile terminal20via the network40(S295inFIG. 52).

In the information providing method, furthermore, state information (with the reward allocation completion flag “TRUE”) indicating that the first game reward has been allocated to the user who is indicated by the user ID and who has started the application indicated by the app ID after the first instruction data has been transmitted to the mobile terminal20is managed.

The first instruction data includes advertisement information (the banner image illustrated inFIG. 56) indicating that a purchase at the store indicated by the store ID allows the purchaser to be further allocated an additional game reward. In the information providing method, accordingly, the mobile terminal20reads a buying ID (the purchase ID included in the two-dimensional code illustrated inFIG. 57A or 57B) indicating that goods or services have been purchased at the store30, and, from the mobile terminal20, an app ID as well as the buying ID is received via the network40(S281inFIG. 52).

Then, a third database (the purchaser privilege reward information146in the game app information DB14) that manages an app ID and a second game reward ID (reward ID) indicating a second game reward allocated in association with the app ID is referred to in accordance with the app ID (S303inFIG. 58), and second instruction data (reward screen information) indicating that the second game reward be additionally allocated is transmitted to the mobile terminal20via the network40(S305inFIG. 58).

The third database manages, in association with an app ID and a second game reward ID, a privilege ID (purchaser privilege ID) indicating in which price range the user has purchased goods or services.

In the information providing method, accordingly, the mobile terminal20reads a buying ID and a privilege ID, and, from the mobile terminal20, an app ID as well as the buying ID and the privilege ID is received via the network40(S281inFIG. 52). Then, the third database is referred to in accordance with the privilege ID and the app ID (S303inFIG. 58), and second instruction data indicating that the second game reward be additionally allocated is transmitted to the mobile terminal20via the network40.

The information providing method described above may give incentives to a player of a game to visit the actual store30.

Modifications to First Embodiment

The plurality of databases (the store information DB13, the game app information DB14, and the user information DB15) described above in the first embodiment may be formed into a single database. In addition, the content of the information stored in the databases described above in the first embodiment and the distribution of information to the databases are examples, and are not limited to any specific form. Furthermore, while, in the first embodiment, the server10includes the plurality of databases, the plurality of databases may be located outside the server10.

In the first embodiment, an advertisement (a banner advertisement) indicating that an event for reward allocation based on a check-in takes place may be displayed on the game screen27b, the stamp sheet screen27c, or the item allocation screen27d. The advertisement may be displayed when the user is located within a predetermined range from the position of the store30on the basis of the position information obtained by the position information obtaining unit included in the mobile terminal20. This advertisement may further attract customers to the store30. The display of such an advertisement is feasible by using a process similar to the determination process described above in the first embodiment as to whether or not the user of the mobile terminal20(or the mobile terminal20) is located close to the store30.

Second Embodiment

Underlying Knowledge Forming Basis of Information Providing Method According to Second Embodiment

In the first embodiment, the imaging unit of the mobile terminal20reads a two-dimensional code at the time of a check-in. Alternatively, a check-in may be performed through any operation other than reading a two-dimensional code if the mobile terminal20is successful in obtaining a store ID. For example, a check-in may be performed by distributing a store ID (in a second embodiment, a device ID of a beacon device described below) within the store30via wireless communication.

In a conceivable configuration, for example, a beacon device may be installed in the store30and the mobile terminal20may receive a beacon signal that is a radio signal transmitted from the beacon device to perform a check-in.

This configuration will cause a difficulty in giving incentives to a player of a game to visit the actual store30if the beacon signal transmitted from the beacon device is tapped by an eavesdropper or the beacon device is stolen. Accordingly, it is desirable to address unauthorized use of the beacon device.

In the second embodiment, an information processing method (game reward allocation system) configured to address unauthorized use of a beacon device will be described. The following description will focus on the differences between the second embodiment and the first embodiment, and substantially identical portions may not be described.

Configuration

First, a configuration of a game reward allocation system according to the second embodiment will be described.FIG. 60illustrates a functional configuration of a game reward allocation system100aaccording to the second embodiment.

As illustrated inFIG. 60, the game reward allocation system100aaccording to the second embodiment includes a server10a(an example of a server device) and a mobile terminal20a(an example of a portable terminal). The server10aand the mobile terminal20aare connected to each other via a network40(for example, the Internet).FIG. 60also illustrates a store30athat is a target for collaboration with a game executable on the mobile terminal20a.

The difference between the mobile terminal20aand the mobile terminal20is the process of an SDK unit24a. Another difference is that the mobile terminal20afurther includes a GPS unit21a(corresponding to the position information obtaining unit in the first embodiment) (not illustrated in the first embodiment) and a wireless communication unit21b.

The GPS unit21ais a GPS module that obtains current position information indicating the current position of the mobile terminal20a. The current position information is obtained by controlling the GPS unit21ausing the control unit21.

The wireless communication unit21bis a wireless communication module that performs wireless communication between the mobile terminal20aand a plurality of beacon devices50ato50ninstalled in the store30a. The transmission and reception of signals between the mobile terminal20aand the plurality of beacon devices50ato50nare performed by controlling the wireless communication unit21busing the control unit21. The communication standard of the wireless communication performed by the wireless communication unit21bis, for example, Bluetooth (registered trademark). Alternatively, any other communication standard such as wireless local area network (LAN) may be used.

The difference between the server10and the server10ais the process of a server control unit11a. Another difference is that the server10afurther includes a server storage unit16. In the second embodiment, furthermore, unlike the first embodiment, the plurality of beacon devices50ato50nand a PC60are installed in the store30a.

In the following, a detailed functional configuration of the game reward allocation system100awill be described.FIG. 61is a block diagram illustrating the detailed functional configuration of the game reward allocation system100a. InFIG. 61, constituent elements mainly described in the following second embodiment are illustrated, and some of the constituent elements illustrated inFIG. 60are not illustrated.

In the following second embodiment, as in the first embodiment, a process performed by the control unit21executing a game app is expressed simply as a verb and a corresponding subject “the game unit23” or “the SDK unit24a”. In addition, a process performed by a constituent element of the SDK unit24ais also expressed with the constituent element as the subject.

Furthermore, it is assumed that communication between the mobile terminal20a(the SDK unit24a) and the server10a(the server control unit11a) (for example, communication between a beacon communication unit73and a beacon control unit83) is performed via the control unit21(communication unit) and the network40.

It is also assumed that communication between the mobile terminal20a(the SDK unit24a) and the plurality of beacon devices50ato50nis performed via the wireless communication unit21b. That is, communication between the mobile terminal20a(the SDK unit24a) and the plurality of beacon devices50ato50nis performed by using the wireless communication function of the mobile terminal20a.

First, the SDK unit24aof the mobile terminal20awill be described in detail. The SDK unit24aincludes an information collection unit71, an advertisement display unit72, the beacon communication unit73, and a reward allocation unit74.

The information collection unit71obtains information on a user, such as the gender, age, and address (residence) of the user. The information collection unit71transmits the information on the user to an information obtaining unit81of the server10a. The information on the user is obtained by the information collection unit71through, for example, an input acceptance screen displayed on a display unit of the mobile terminal20a, or may be stored in advance in the mobile terminal20a.

The advertisement display unit72performs a process similar to the store collaboration information obtaining process illustrated inFIG. 14, and a process similar to the store collaboration image rendering process illustrated inFIG. 25.

The beacon communication unit73receives a beacon signal from a beacon device (for example, the beacon device50a) installed in the store30a, and transmits a device ID included in the received beacon signal to the beacon control unit83. Further, the beacon communication unit73transmits an app ID, an app user ID, and current position information on the mobile terminal20ato the beacon control unit83. The app ID and the app user ID are included in the game unit23. The current position information is obtained from the GPS unit21aincluded in the mobile terminal20a.

The reward allocation unit74performs a process similar to the reward screen display process illustrated inFIG. 36, and a process similar to the reward allocation process illustrated inFIG. 42.

Next, the server control unit11aof the server10awill be described. The server control unit11aincludes the information obtaining unit81, an advertisement distribution unit82, the beacon control unit83, a reward control unit84, and an advertisement designation acceptance unit85.

The information obtaining unit81obtains information on the user from the information collection unit71, and stores the obtained information in the server storage unit16as app user information.

The advertisement distribution unit82performs a process similar to the store collaboration information generation process illustrated inFIG. 18, and a process similar to the store collaboration information transmission process illustrated inFIG. 18.

In the second embodiment, unlike the first embodiment, the content of the store collaboration information generated by the advertisement distribution unit82can be specified through the PC60installed in the store30a. Specifically, the advertisement designation acceptance unit85accepts the designation of a store that is a target for collaboration or the designation of the content of game rewards. Such designation is input by a person in charge of advertising for the store30athrough the PC60.

The person in charge of advertising for the store30ais also able to specify the mobile terminal20afrom which the store collaboration information is transmitted, by using the app user information. That is, the person in charge of advertising for the store30ais able to specify the destination to which the advertisement is distributed, through the PC60. Specifically, the person in charge of advertising for the store30ais able to transmit the store collaboration information only to mobile terminals of users who are, for example, 30 years old or over.

The content of the designation accepted by the advertisement designation acceptance unit85is stored in, for example, the server storage unit16.

The beacon control unit83provides beacon device information on a beacon device located around the mobile terminal20a, calculates the probability of abnormal condition of the beacon device, and performs a process corresponding to the calculated probability of abnormal condition. Specifically, the beacon control unit83obtains current position information (an example of first position information) indicating the current position of the mobile terminal20afrom the beacon communication unit73of the mobile terminal20a. Further, the beacon control unit83compares the obtained current position information with installation position information (beacon ID information described below) indicating the installation position of the beacon device50ato provide information concerning a beacon device located around the mobile terminal20a. Further, the beacon control unit83compares the obtained current position information with the installation position information indicating the installation position of the beacon device50ato calculate the probability of abnormal condition of the beacon device50a, and performs a process corresponding to the calculated probability of abnormal condition. The operations of the beacon control unit83described above are characteristic operations of the server10a, and will be described in detail below.

The beacon control unit83holds (or stores) pieces of key information86ato86n. The pieces of key information86ato86nare key information for performing encryption communication with the beacon devices50ato50n, respectively. A signal encrypted by using the key information86ais decodable by using key information51aheld in the beacon device50a, and a signal encrypted by using the key information51ais decodable by using the key information86a. Similarly, a signal encrypted by using the key information86nis decodable by using key information51nheld in the beacon device50n, and a signal encrypted by using the key information51nis decodable by using the key information86n. The key information51nand the key information86nmay be identical (common key encryption).

The reward control unit84performs a process similar to the reward screen information generation process illustrated inFIG. 40, and a process similar to the reward information generation process illustrated inFIG. 44.

Next, the constituent elements (the beacon devices50ato50nand the PC60) installed in the store30awill be described.

The beacon devices50ato50nare installed in the store30a, and are each a device that periodically repeatedly transmits a beacon signal which is a radio signal for wireless communication. The beacon signal includes, for example, the device ID (identification information) of a beacon device that has transmitted the beacon signal. The beacon device50ais an example of a first beacon device, and the beacon device50nis an example of a second beacon device.

Each of the beacon devices50ato50nis not limited to any specific form but, in the second embodiment, may be a small module having a substrate of approximately 3 cm×3 cm on which circuit components are mounted. In the second embodiment, furthermore, the beacon devices50ato50nare each driven by a button cell battery. In terms of maintenance, it is desirable to reduce the frequency of replacement of the batteries. Accordingly, each of the beacon devices50ato50ndoes not include a constituent element for obtaining position information thereon, such as a GPS module, in order to reduce power consumption.

As described above, the beacon devices50ato50nrespectively hold the pieces of key information51ato51nto perform encryption communication with the beacon control unit83. Since each of the beacon devices50ato50ndoes not include a constituent element for directly communicating with the server10a, communication between the beacon devices50ato50nand the server10ainvolves the transmission and reception of information via the mobile terminal20a. However, the mobile terminal20aholds no key information corresponding to the pieces of key information51ato51n, which makes it difficult for the mobile terminal20ato alter information, for example.

In the second embodiment, a plurality of beacon devices are installed in a single store30a, or a single building (space). It is sufficient that at least one beacon device be installed in the store30a, and a plurality of beacon devices may not necessarily be installed.

The PC60is a personal computer installed in the store30a, and is usable by a person in charge of advertising for the store30ato specify the content of store collaboration information, for example. The PC60may not necessarily be installed in the store30a. Instead of the PC60, any other information communication terminal such as a smartphone may be used.

Finally, the server storage unit16will be described.FIG. 62illustrates information stored in the server storage unit16.

As illustrated inFIG. 62, the server storage unit16stores beacon ID information161and a check-in history162. Although not illustrated inFIG. 62, the server storage unit16also stores the app user information described above and the content of the designation accepted by the advertisement designation acceptance unit85.

The beacon ID information161is information managed in advance by the server10a, and is an example of second position information. Specifically, the beacon ID information161is information illustrated inFIG. 63.FIG. 63illustrates an example of the beacon ID information161.

As illustrated inFIG. 63, the beacon ID information161is information in which the device IDs of a plurality of beacon devices are associated with the installation positions of the beacon devices. The beacon ID information161also includes other information such as the respective device names of the plurality of beacon devices, the store IDs of stores in which the beacon devices are installed, the locations where the beacon devices are installed (“installation locations”), radio field intensity (received signal strength intensity (RSSI)), and a false flag.

The check-in history162is a log of check-ins.FIG. 64illustrates an example of the check-in history162. As described below, upon receipt of a beacon signal from each of the beacon devices50ato50n, the mobile terminal20atransmits a device ID included in the beacon signal to the server10a. In this case, the server10astores the device ID transmitted from the mobile terminal20ain the server storage unit16as a check-in history in association with the date and time of reception of the device ID. Similarly, the server10aalso stores the date and time of reception of a device ID transmitted from any other mobile terminal in the server storage unit16as the check-in history162.

That is, each of a plurality of mobile terminals (an example of second portable terminals) transmits to the server10aa beacon ID (an example of a first ID) included in a beacon signal received from the beacon device50a. The server10amanages, as the check-in history162, the dates and times of reception of the beacon IDs transmitted from the plurality of mobile terminals. Also, each of a plurality of mobile terminals (an example of third portable terminals) transmits to the server10aa beacon ID (an example of a second ID) included in a beacon signal received from a beacon device (for example, the beacon device50n) different from the beacon device50a. The server10afurther manages, as the check-in history162, the dates and times of reception of the beacon IDs transmitted from the plurality of mobile terminals.

As illustrated inFIG. 64, the check-in history162also includes other information such as a check-in position, an app user ID, and an app ID (not illustrated). The check-in position is the position of a mobile terminal at the time of check-in.

In the following second embodiment, a check-in history constituted by a date and time of reception of the device ID of the beacon device50ais also referred to as a first check-in history. A check-in history constituted by a date and time of reception of the device ID of a beacon device other than the beacon device50aamong the plurality of beacon devices50ato50nis also referred to as a second check-in history.

Operation

Next, the operation of the game reward allocation system100awill be described.FIG. 65Ais a sequence diagram of the operation of the game reward allocation system100a. The operation illustrated inFIG. 65Ais performed when a user who has visited the store30astarts a game app stored in the mobile terminal20a. Specifically, the operation illustrated inFIG. 65Ais started, for example, when the user presses a trigger button through a screen on which the app is being started.

First, the beacon communication unit73of the mobile terminal20atransmits a request for obtaining the device ID of a device near the current position of the mobile terminal20ato the beacon control unit83of the server10a(S311). In this case, the beacon communication unit73starts the GPS unit21a, causes the device ID obtaining request to include the current position information on the mobile terminal20aobtained from the GPS unit21a, and transmits the device ID obtaining request.

Then, the beacon control unit83transmits a list of device IDs of beacon devices located near the current position of the mobile terminal20a(S312). For example, the beacon control unit83refers to the beacon ID information161in the server storage unit16to select beacon devices installed within a predetermined range (for example, within a distance of 1 km) from the current position of the mobile terminal20a, and transmits a list of the device IDs of the selected beacon devices to the beacon communication unit73. Note that, in the beacon ID information161, a beacon device whose value of the false flag indicates “pending”, “temporary suspension”, or “complete stop” can possibly be used without authorization. Thus, the beacon control unit83does not cause the list to include the device ID of such a beacon device.

Each of the plurality of beacon devices50ato50n(for example, the beacon device50a) installed in the store30aperiodically repeatedly transmits a beacon signal (S313). Upon receipt of a beacon signal from the beacon device50a, the beacon communication unit73accesses the beacon device50a(S314) and transmits a device ID obtaining request to the beacon device50a(S315).

Upon receipt of the device ID obtaining request, the beacon device50atransmits a beacon signal including the device ID of the beacon device50ato the beacon communication unit73(S316).

The beacon device50amay transmit the device ID to the mobile terminal20avia two-way communication between the beacon device50aand the mobile terminal20a, as in steps S313to S316. Alternatively, the beacon device50amay transmit (or broadcast) a beacon signal including the device ID to the mobile terminal20ain step S313.FIG. 65Bis a sequence diagram of this operation of the game reward allocation system100a.

In the operation of the game reward allocation system100aillustrated inFIG. 65B, the processes of steps S314to S316are omitted, and a beacon signal including the device ID of the beacon device50ais broadcasted in step S313. That is, there is no need for two-way communication for the transmission of a device ID, enabling an increase in communication speed and a reduction in power consumption for communication. On the contrary, there is a limitation on the amount of information that can be included in a beacon signal, resulting in the data length of a device ID being limited.

Upon receipt of the beacon signal, the beacon communication unit73transmits to the beacon control unit83a request for reward allocation including both the device ID included in the received beacon signal and the current position information on the mobile terminal20obtained from the GPS unit21aat the current time (S317). The request for reward allocation also includes an app ID and an app user ID.

The beacon control unit83receives the request for reward allocation from the beacon communication unit73(S318). In other words, the beacon control unit83obtains the device ID and the current position information indicating the current position of the mobile terminal20a. Then, the beacon control unit83saves check-in information (S319). That is, the beacon control unit83manages (or stores), as the check-in history162(first check-in history), the date and time of reception of the device ID and current position information transmitted from the mobile terminal20a. Then, the beacon control unit83calculates the probability of abnormal condition of the beacon device50a(S320). For example, the beacon control unit83refers to the beacon ID information161stored in the server storage unit16to read the installation position of the mobile terminal20a, and compares the read installation position with the obtained current position information to calculate the probability of abnormal condition of the beacon device50a. Then, the beacon control unit83performs a process corresponding to the probability of abnormal condition calculated in step S320(S321).

Method for Calculating Probability of Abnormal Condition

Next, the method for calculating a probability of abnormal condition in step S320inFIG. 65Awill be described in detail. In the following description, by way of example, the probability of abnormal condition=1 is set when the probability of abnormal condition is the highest, and the probability of abnormal condition=0 is set when the probability of abnormal condition is the lowest, that is, when normal conditions exist.

As described above, the server storage unit16stores the beacon ID information161. That is, the beacon control unit83manages in advance the beacon ID information161indicating the installation position of the beacon device50a.

If the position indicated by the current position information on the mobile terminal20aobtained in step S318is largely different from the installation position of the beacon device50aindicated by the beacon ID information161, it is suspected that the beacon device50amay be placed at a position different from the installation position indicated by the beacon ID information161due to its theft or any other reason.

Accordingly, for example, if the difference between the installation position indicated by the beacon ID information161and the current position of the mobile terminal20ais within a predetermined value, the beacon control unit83determines that the beacon device50ais under normal conditions (probability of abnormal condition=0). If the difference is larger than the predetermined value, the beacon control unit83determines that an abnormal event has occurred (probability of abnormal condition=1).

The determination described above is the simplest example. In the second embodiment, the beacon control unit83calculates a probability of abnormal condition, using the current position information on the mobile terminal20aobtained in step S318, so that the larger the difference between the installation position indicated by the beacon ID information161and the current position indicated by the obtained current position information, the higher the probability of abnormal condition.

The calculation of the probability of abnormal condition may be based on information other than the current position information described above. As described above, the beacon control unit83manages (or stores in the server storage unit16), as a first check-in history, the dates and times when the beacon ID of the beacon device50awas received from a plurality of mobile terminals. The first check-in history may be used for the calculation of the probability of abnormal condition.

In a case where the beacon device50ais installed in the store30a, there is a tendency for the number of check-ins to vary from store to store and from time slot to time slot (for example, in Store1, the number of check-ins is comparatively large during the time slot of 12:00 to 13:00, but is comparatively small during the time slot of 20:00 to 21:00, etc.).

However, while the beacon device50ais being used without authorization, the tendency for the number of check-ins to vary may be different from usual or the number of check-ins may markedly decrease. That is, in this case, the current first check-in history is considered to be largely different from the previous first check-in history.

Accordingly, the beacon control unit83may compare the first check-in history obtained when the current position information is obtained in step S318with the previous first check-in history to calculate a probability of abnormal condition. For example, the beacon control unit83calculates the degree of similarity between the current distribution of the number of check-ins and the previous distribution of the number of check-ins, and calculates a probability of abnormal condition so that the lower the degree of similarity calculated, the higher the probability of abnormal condition. The degree of similarity is calculated by using a known technique.

For example, in a case where the user of the mobile terminal20aalters data of the GPS unit21a, it is probable that a probability of abnormal condition may not be able to be correctly calculated through the comparison between the installation position indicated by the beacon device50aand the current position of the mobile terminal20a. In this case, it is effective to calculate a probability of abnormal condition by using a check-in history.

Alternatively, the calculation of a probability of abnormal condition may be based on a second check-in history constituted by a date and time of reception of the device ID of a beacon device (for example, the beacon device50n) other than the beacon device50aamong the beacon devices50ato50ninstalled in the store30a. Specifically, the beacon control unit83may calculate a probability of abnormal condition by comparing the first check-in history with the second check-in history.

As described above, the beacon control unit83manages (or stores in the server storage unit16), as a second check-in history, the dates and time when the beacon ID of a beacon device other than the beacon device50awas received from the plurality of mobile terminals. If the distribution of the number of check-ins included in the second check-in history is largely different from the distribution of the number of check-ins included in the first check-in history, the beacon device50ais presumably used in a way different from that of the other beacon devices. That is, it can be determined that the beacon device50awill be installed in a location other than the store30aand used without authorization.

For example, the beacon control unit83calculates the degree of similarity between the distribution of the number of check-ins included in the first check-in history and the distribution of the number of check-ins included in the second check-in history, and calculates a probability of abnormal condition so that the lower the degree of similarity calculated, the higher the probability of abnormal condition. The degree of similarity is calculated by using a known technique.

As described above, the first check-in history includes an app user ID. A probability of abnormal condition may be calculated on the basis of the number of identical app user IDs. For example, the beacon control unit83may calculate a probability of abnormal condition in accordance with the number of identical app user IDs included in the first check-in history.

As illustrated inFIG. 66, a predetermined number of or more check-ins made using an identical app user ID may be consecutive, or the proportion (frequency) of check-ins made using an identical app user ID may be higher than a predetermined value.FIG. 66illustrates an example of a check-in history162awhen an abnormal event has occurred. In the case illustrated inFIG. 66, it is suspected that a specific user may be using the beacon device50awithout authorization. In this case, the beacon control unit83may determine that the probability of abnormal condition is high. In addition, the beacon control unit83may determine that the probability of abnormal condition is high if, for example, the number of identical app user IDs included in a certain period is large. Indeed, the following case is conceivable. Although the beacon device50ais being used with authorization, only a specific user happens to visit the store. In order to mitigate the potential consequences of the situation, the number of identical app user IDs included in a certain period is used as an auxiliary condition in combination with the comparison of the degree of similarity to the previous history described above.

As described above, a probability of abnormal condition is calculated by using the discrepancy between the installation position of the beacon device50aand the current position of the mobile terminal20aor by using the check-in history162. Note that a probability of abnormal condition may be calculated by using the discrepancy between the installation position of the beacon device50aand the current position of the mobile terminal20aand by also using the check-in history162. In this case, probabilities of abnormal condition are calculated by using the respective techniques, and then a weighted sum of the calculated probabilities of abnormal condition is calculated, for example, to determine one probability of abnormal condition.

Process Corresponding to Probability of Abnormal Condition

Next, the process corresponding to the probability of abnormal condition in step S321inFIG. 65Awill be described. The beacon control unit83performs a process corresponding to the probability of abnormal condition calculated in the way described above. In the second embodiment, the beacon control unit83performs any of five processes in accordance with the probability of abnormal condition.FIG. 67is a flowchart of a method for determining a process corresponding to the probability of abnormal condition by using the beacon control unit83. In the flowchart inFIG. 67, threshold values for determination of the probability of abnormal condition and the number of threshold values are examples.

First, the beacon control unit83determines whether or not the calculated probability of abnormal condition is smaller than a first threshold value, namely, 0.2 (S331). If the calculated probability of abnormal condition is smaller than 0.2 (YES in S331), the beacon control unit83performs a reward allocation authentication process using the beacon device50a(Action1) (S332).

If the calculated probability of abnormal condition is greater than or equal to 0.2 (NO in S331), the beacon control unit83determines whether or not the calculated probability of abnormal condition is smaller than a second threshold value, namely, 0.4 (S333). If the calculated probability of abnormal condition is smaller than 0.4 (YES in S333), the beacon control unit83performs a reward allocation authentication process using another beacon device (for example, the beacon device50n) different from the beacon device50a(Action2) for the beacon communication unit73(S334).

If the calculated probability of abnormal condition is greater than or equal to 0.4 (NO in S333), the beacon control unit83determines whether or not the calculated probability of abnormal condition is smaller than a third threshold value, namely, 0.6 (S335). If the calculated probability of abnormal condition is smaller than 0.6 (YES in S335), the beacon control unit83performs a process for holding reward allocation pending (Action3) (S336).

If the calculated probability of abnormal condition is greater than or equal to 0.6 (NO in S335), the beacon control unit83determines whether or not the calculated probability of abnormal condition is smaller than a fourth threshold value, namely, 0.8 (S337). If the calculated probability of abnormal condition is smaller than 0.8 (YES in S337), the beacon control unit83performs a process for temporarily suspending the functions of the beacon device50a(Action4) (S338).

If the calculated probability of abnormal condition is greater than or equal to 0.8 (NO in S337), the beacon control unit83performs a process for completely stopping the functions of the beacon device50a(Action5) (S339).

The details of the processes corresponding to the probability of abnormal condition will be described hereinafter.

Reward Allocation Authentication Process (Action1)

First, the reward allocation authentication process (Action1) will be described in detail.FIG. 68is a sequence diagram of the reward allocation authentication process. The reward allocation authentication process is a predetermined process performed when the probability of abnormal condition is low (or when normal conditions exist). When the reward allocation authentication process is completed, a game reward (for example, a stamp or an item) used in a game app is allocated over data.

First, the beacon control unit83of the server10agenerates a control signal for instructing the beacon device50aand the mobile terminal20ato perform Action1, and a random number (one-time password). The random number is used as measures against the interception (tapping) of communication.

The beacon control unit83transmits to the beacon communication unit73an encrypted signal obtained by encrypting the generated control signal and random number by using the key information86acorresponding to the key information51astored in the beacon device50a(S341).

The beacon communication unit73of the mobile terminal20areceives the encrypted signal from the beacon control unit83. However, the mobile terminal20adoes not store the key information51a. That is, the beacon communication unit73is not able to decode the encrypted signal. Accordingly, the beacon communication unit73transmits the received encrypted signal to the beacon device50aas is (S342).

The beacon device50adecodes the received encrypted signal by using the key information51a(S343), and obtains a control signal and a random number. Then, in accordance with the instructions for Action1indicated by the control signal, the beacon device50atransmits a response signal including the instructions to the beacon communication unit73(S344). In this case, the beacon device50are-encrypts the random number, which is obtained by decoding the encrypted signal by using the key information51a, by using the key information51a, and causes the response signal to include the re-encrypted random number before transmitting the response signal.

Upon receipt of the response signal, the beacon communication unit73transmits a reward allocation request including the encrypted random number to the beacon control unit83in accordance with the instructions for Action1included in the response signal (S345).

The beacon control unit83receives the reward allocation request, checks the random number, and performs a process for allocating a reward (S346). More specifically, the beacon control unit83first decodes the encrypted random number by using the key information86ato obtain a random number, and checks whether the obtained random number matches the random number transmitted from the beacon control unit83in step S341. If both match, a process for allocating a reward is started.

The process for allocating a reward is similar to the reward screen generation process described with reference toFIG. 40or a process similar to the reward information generation process described with reference toFIG. 44, and is performed by the reward control unit84. As a result, a game reward (for example, a stamp or an item) used in the game app is allocated over data.

In the way described above, if the calculated probability of abnormal condition is lower than a predetermined value (here, 0.2), the beacon control unit83performs a predetermined process for allocating a reward to the mobile terminal20a.

Reward Allocation Authentication Process Using Other Beacon Device (Action2)

Next, the reward allocation authentication process using another beacon device (Action2) will be described in detail.FIG. 69is a sequence diagram of the reward allocation authentication process using another beacon device. InFIG. 69, steps substantially identical to those inFIG. 68are denoted by numerals similar to those inFIG. 68, and the description thereof is simplified.

As described above, a plurality of beacon devices are installed in the store30a. Thus, if unauthorized use of the beacon device50ais suspected, a reward allocation authentication process is performed using a beacon device (here, the beacon device50n) other than the beacon device50a. This makes the reward allocation authentication process infeasible when, for example, the beacon device50ahas been stolen, suppressing the unauthorized obtaining of game rewards.

First, the beacon control unit83of the server10atransmits to the beacon communication unit73an encrypted signal including a control signal for providing instructions for Action2and a random number (S341). The beacon communication unit73transmits the received encrypted signal to the beacon device50aas is (S342).

The beacon device50adecodes the received encrypted signal by using the key information51a(S343), and obtains a control signal and a random number. Then, in accordance with the instructions for Action2indicated by the control signal, the beacon device50atransmits a response signal including the instructions and the re-encrypted random number to the beacon communication unit73(S344).

Upon receipt of the response signal, the beacon communication unit73transmits a re-authentication request including the encrypted random number to the beacon control unit83in accordance with the instructions for Action2included in the response signal (instructions for communicating with the beacon device50n) (S351).

The beacon control unit83receives the re-authentication request, checks the random number, and re-transmits the encrypted signal (S352). Specifically, the beacon control unit83generates a control signal for instructing the beacon device50nand the mobile terminal20ato perform an action, and a random number, and transmits to the beacon communication unit73an encrypted signal encrypted by using the key information86n, the encrypted signal including the generated control signal and random number (S352). The beacon communication unit73transmits the received encrypted signal to the beacon device50nas is (S353).

The beacon device50ndecodes the received encrypted signal by using the key information51n(S354), and obtains a control signal and a random number. Then, in accordance with the instructions for the action indicated by the control signal, the beacon device50ntransmits a response signal including the instructions and the re-encrypted random number to the beacon communication unit73(S355).

Upon receipt of the response signal, the beacon communication unit73transmits a reward allocation request including the encrypted random number to the beacon control unit83in accordance with the instructions for the action included in the response signal (S356).

The beacon control unit83receives the reward allocation request, checks the random number, and performs a process for allocating a reward (S357). More specifically, the beacon control unit83first decodes the encrypted random number by using the key information86nto obtain a random number, and checks whether the obtained random number matches the random number transmitted from the beacon control unit83in step S352. If both match, a process for allocating a reward is started.

In the way described above, if the calculated probability of abnormal condition is greater than or equal to a predetermined value (here, 0.2), the beacon control unit83performs a process for instructing the mobile terminal20ato obtain a beacon signal (response signal) from the beacon device50ndifferent from the beacon device50a.

This can prevent the mobile terminal20afrom receiving a beacon signal from the beacon device50aif the beacon device50ahas been stolen, suppressing or reducing unauthorized use of the beacon device50a.

A method for selecting a beacon device different from the beacon device50ais not limited to any specific method. For example, the beacon control unit83may refer to installation position information on beacon devices and select a beacon device located closest to the beacon device50a. Alternatively, the beacon control unit83may refer to installation position information on beacon devices and randomly select a beacon device from among beacon devices located near the beacon device50a.

Process for Holding Reward Allocation Pending (Action3)

Next, the process for holding reward allocation pending (Action3) will be described in detail.FIG. 70is a sequence diagram of the process for holding reward allocation pending. InFIG. 70, steps substantially identical to those inFIG. 68are denoted by numerals similar to those inFIG. 68, and the description thereof is simplified.

In the process for holding reward allocation pending, if unauthorized use of the beacon device50ais suspected, the start of the process for allocating a reward is brought into a pending state. During the period of the pending state, the staff actually checks the state of the beacon device50ain the store30a, and, when it is confirmed that the beacon device50ais in the normal state, a process for allocating a reward is started.

First, the beacon control unit83of the server10asets the false flag, corresponding to the device ID of the beacon device50a, in the beacon ID information161to “pending” (S360), and then transmits to the beacon communication unit73an encrypted signal including a control signal for providing instructions for Action3and a random number (S341). The beacon communication unit73transmits the received encrypted signal to the beacon device50aas is (S342).

The beacon device50adecodes the received encrypted signal by using the key information51a(S343), and obtains a control signal and a random number. Then, in accordance with the instructions for Action3indicated by the control signal, the beacon device50atransmits a response signal including the instructions and the re-encrypted random number to the beacon communication unit73(S344).

Upon receipt of the response signal, the beacon communication unit73displays Message1on the display unit in accordance with the instructions for Action3included in the response signal (S361).FIG. 71is a schematic diagram of the mobile terminal20aon which Message1is displayed.

As illustrated inFIG. 71, in Message1, a message indicating that reward allocation is pending is displayed.

Further, in accordance with the instructions for Action3, the beacon communication unit73transmits a reward allocation request including the encrypted random number to the beacon control unit83(S362).

The beacon control unit83receives the reward allocation request, checks the random number, and holds the process for allocating a reward pending (S363). The pending reward allocation is released (the process for allocating a reward is started), for example, when the staff who has confirmed that the beacon device50ais in the normal state notifies the beacon control unit83of the normal operation of the beacon device50athrough the PC60. When the normal operation is confirmed, the beacon control unit83resets the false flag, corresponding to the device ID of the beacon device50a, in the beacon ID information161to “NO”.

In the way described above, if the calculated probability of abnormal condition is greater than or equal to a predetermined value (here, 0.4), the beacon control unit83performs a process for putting a predetermined process for allocating a reward on hold. This may suppress the start of a predetermined process for allocating a reward after checking the state of the beacon device50a.

Process for Temporarily Suspending Functions of Beacon Device (Action4)

Next, the process for temporarily suspending the functions of the beacon device50a(Action4) will be described in detail.FIG. 72is a sequence diagram of the process for temporarily suspending the functions of the beacon device50a. InFIG. 72, steps substantially identical to those inFIG. 68are denoted by numerals similar to those inFIG. 68, and the description thereof is simplified.

The process for temporarily suspending the functions of the beacon device50ais a process performed when the probability of abnormal condition is comparatively high.

First, the beacon control unit83of the server10asets the false flag, corresponding to the device ID of the beacon device50a, in the beacon ID information161to “temporary suspension” (S370), and then transmits to the beacon communication unit73an encrypted signal including a control signal for providing instructions for Action4(S341). The beacon communication unit73transmits the received encrypted signal to the beacon device50aas is (S342).

The beacon device50adecodes the received encrypted signal by using the key information51a(S343), and obtains a control signal. Then, in accordance with the instructions for Action4indicated by the control signal, the beacon device50atransmits a response signal including the instructions to the beacon communication unit73(S344).

Upon receipt of the response signal, the beacon communication unit73displays Message2on the display unit in accordance with the instructions for Action4included in the response signal (S371).FIG. 73is a schematic diagram of the mobile terminal20aon which Message2is displayed.

As illustrated inFIG. 73, in Message2, a message indicating that the functions of a device are temporarily suspended.

Meanwhile, after transmitting the response signal in step S344, the beacon device50atemporarily suspends the functions in accordance with the instructions for Action4(S372). Specifically, the beacon device50astops the transmission of the beacon signal. In this case, the beacon device50acan be reactivated by the manager or the like of the beacon device50aperforming a predetermined recovery procedure. After the manager has performed the recovery procedure, the beacon control unit83resets the false flag, corresponding to the device ID of the beacon device50a, in the beacon ID information161to “NO”.

In the way described above, if the calculated probability of abnormal condition is greater than or equal to a predetermined value (here, 0.6), the beacon control unit83performs a process for transmitting information for temporarily suspending the functions of the beacon device50ato the beacon device50avia the mobile terminal20a. This may suppress unauthorized use of the beacon device50a.

Process for Completely Stopping Functions of Beacon Device (Action5)

Next, the process for completely stopping the functions of the beacon device50a(Action5) will be described in detail.FIG. 74is a sequence diagram of the process for completely stopping the functions of the beacon device50a. InFIG. 74, steps substantially identical to those inFIG. 68are denoted by numerals similar to those inFIG. 68, and the description thereof is simplified.

The process for completely stopping the functions of the beacon device50ais performed when the probability of abnormal condition is significantly high.

First, the beacon control unit83of the server10asets the false flag, corresponding to the device ID of the beacon device50a, in the beacon ID information161to “complete stop” (S380), and then transmits to the beacon communication unit73an encrypted signal including a control signal for providing instructions for Action5(S341). The beacon communication unit73transmits the received encrypted signal to the beacon device50aas is (S342).

The beacon device50adecodes the received encrypted signal by using the key information51a(S343), and obtains a control signal. Then, in accordance with the instructions for Action5indicated by the control signal, the beacon device50adeletes the key information51aheld (or stored) in the beacon device50ato completely stop the functions (S381). In this case, reactivation of the beacon device50ais not possible.

If the beacon communication unit73is not allowed to receive a response signal for a certain period or more after the encrypted signal is transmitted in step S342, the beacon communication unit73displays Message3on the display unit (S382).FIG. 75is a schematic diagram of the mobile terminal20aon which Message3is displayed.

As illustrated inFIG. 75, in Message3, a message indicating that the process has failed is displayed.

In the way described above, if the calculated probability of abnormal condition is greater than or equal to a predetermined value (here, 0.8), the beacon control unit83performs a process for transmitting information for completely stopping the functions of the beacon device50ato the beacon device50avia the mobile terminal20a. The information for stopping the functions of the beacon device50ais encrypted information which is decodable by using the key information51aheld in the beacon device50a. The information for stopping the functions of the beacon device50aincludes information for deleting the key information51aheld in the beacon device50a.

This may reduce the probability of the outflow of the key information51a, and may suppress unauthorized use of the game reward allocation system100a.

Conclusion

An information processing method that uses the game reward allocation system100aaccording to the second embodiment has been described. In the information processing method according to the second embodiment, the server10aobtains current position information indicating the current position of the mobile terminal20afrom the mobile terminal20athat has received a beacon signal from the beacon device50a. Further, the server10acompares the obtained current position information with installation position information (beacon ID information) indicating the installation position of the beacon device50a, which is managed in advance by the server10a, to calculate the probability of abnormal condition of the beacon device50a. Then, the server10aperforms a process corresponding to the calculated probability of abnormal condition.

In the information processing method described above, the probability of abnormal condition of the beacon device50ais calculated using the GPS unit21aincluded in the mobile terminal20a. The beacon device50afor which the probability of abnormal condition is to be calculated is not necessarily provided with a GPS module, which may make the beacon device50asimplified (reduced in power consumption).

In the information processing method described above, furthermore, it may be possible to perform a process for suppressing or reducing unauthorized use of a beacon device in accordance with the probability of abnormal condition of the beacon device.

Modifications to Second Embodiment

In the second embodiment, the beacon ID information161(installation position information) is stored in the server storage unit16included in the server10a. However, the beacon ID information161may be obtained from a storage device located outside the server10a. The beacon ID information161is not information transmitted from the beacon devices50ato50nbut is information registered in advance in the server storage unit16by the manager of the server10aor by the managers of the beacon devices50ato50n.

The technique of the second embodiment may be implemented as the game reward allocation system100aor the server10a. Alternatively, the technique of the second embodiment may be implemented as an application applicable to the mobile terminal20aor an SDK (the SDK unit24a) applicable to a game app (the game unit23).

The information processing method according to the second embodiment is also applicable to a system other than the game reward allocation system100a(for example, any other non-game-related system).

Other Embodiments

As described above, the first and the second embodiments have been described as illustrative examples of the technique disclosed herein. However, the technique of the present disclosure is not limited to these embodiments, and is also applicable to other embodiments including modifications, replacements, additions, omissions, and others as desired. In addition, the constituent elements described in the first and second embodiments described above may be used in combination to construct different embodiments.

For example, in the foregoing embodiments, each constituent element may be constituted by dedicated hardware, or may be implemented by executing a software program suitable for the corresponding constituent element. Each constituent element may be implemented by a program execution unit such as a central processing unit (CPU) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.

In the foregoing embodiments, furthermore, a process performed by a specific processing unit may be performed by another processing unit. In addition, the order of a plurality of processes may be changed, or a plurality of processes may be performed in parallel.

While an information providing method and an information processing method according to one or more aspects of the present disclosure have been described with reference to embodiments, the present disclosure is not limited to these embodiments. Various modifications conceivable by a person skilled in the art to the embodiments described above and embodiments constituted by a combination of constituent elements in different embodiments, which are made without departing from the gist of the present disclosure, may also fall within the scope of one or more aspects of the present disclosure.

The technique of the present disclosure is applicable to an information processing method for suppressing or reducing unauthorized use of a beacon device. The technique of the present disclosure is further applicable to a game reward allocation system and others configured to perform a process for suppressing or reducing unauthorized use of a beacon device in accordance with the probability of abnormal condition of the beacon device and configured to allocate a game reward used in a game app through communication with a beacon device.