Systems, methods, and programs suitable for conducting user-experience-based events.

Abstract

We provide a system suitable for conducting user-experience-based events that can create memorable experiences for users. [Solution] A system 100 suitable for conducting user experience type events, The system comprises a server 10, a transmitting device 20 that transmits identification information, and a user terminal 30 that receives identification information and transmits the received identification information back to the server 10. A quest completion determination unit 17 determines the end of a quest using identification information received by the user terminal 30, The acquisition unit 14 acquires user behavior information during quests, Based on the acquired behavioral information, the behavioral history playback unit 19 creates user behavioral history data during the quest and makes the behavioral history data playable after the quest is completed. It is equipped with.

Description

Technical Field

[0001] The present invention relates to a system, a method, and a program suitable for implementing a user experience type event.

Background Art

[0002] Conventionally, as a user experience type event, an event has been proposed in which each user is divided into teams, finds a treasure placed in the real world, and brings it back to a hideout. In this type of event, for example, a server, a transmission device that transmits identification information, and a user terminal that receives the identification information and transmits the received identification information to the server are utilized (see Patent Document 1 above).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] While experience type events such as those described in Patent Document 1 have been beginning to spread in recent years, not just providing them, for example, how to enhance the sense of immersion and interest, and as a result, make it an experience that remains in the user's memory has been the key to differentiation.

[0005] Therefore, an object of the present invention is to provide a system, a method, and a program suitable for implementing a user experience type event that can be an experience remaining in the user's memory.

Means for Solving the Problems

[0006] One aspect of the present invention is exemplified as follows. [1] A system suitable for implementing a user experience type event, The system comprises a server, a transmitting device that transmits identification information, and a user terminal that receives the identification information and transmits the received identification information to the server, and further, A quest completion determination unit determines the end of a quest using the identification information received by the user terminal, The acquisition unit obtains user behavior information during quests, An action history playback unit creates user action history data during a quest based on the acquired action information, and makes the action history data playable after the quest is completed. An event execution system equipped with the necessary features. [2] The aforementioned behavioral history data includes image data and / or video data that reflects user behavior during quests, as described in item 1. [3] The aforementioned behavioral history data includes augmented reality (AR) data that reflects user behavior during a quest, which is reproduced with or without predetermined markers, as described in item 1 or 2. [4] The acquisition unit includes a camera that captures images of the user. A system according to any one of items 1 to 3, which starts and / or terminates the acquisition of user behavior information depending on the reception status of the identification information transmitted from the transmitting device. [5] The aforementioned behavioral history playback unit, A system according to any one of items 1 to 4, which calculates the user's contribution to a quest based on at least one of the acquired behavioral information and the reception status of the identification information from the transmitting device. [6] The aforementioned behavioral history playback unit, A system described in any five of items 1 to 4, which calculates the degree to which user behavior history data is utilized, and then calculates the user's contribution to a quest based on the degree to which the behavior history data is utilized. [7] The system according to item 5 or 6, further comprising a reward provision unit that provides rewards to users for quests in proportion to the user contributions mentioned above. [8] It also includes a fake information provider section capable of providing fake information related to quests. For users who have progressed significantly in the event, compared to users who have progressed less, It is possible to provide specific fakes, and / or Fakes can be provided frequently. A system described in any one of items 1 through 7. [9] A system described in any one of items 1 to 8, which can distinguish and display areas that have not been visited by the user or user team members on a map displayed on the user's terminal.

[10] A suitable method for conducting user-experience-based events through quests, A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. An event implementation method that includes [specific characteristics / features].

[11] This program is suitable for conducting user-experience-based events through quests. A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. A program designed to be executed by a computer system.

[0007] A further aspect of the present invention may be exemplified as follows.

[12] The transmission device transmits identification information based on at least one standard selected from the group consisting of BLE (Bluetooth Low Energy), LoRa, Wi-Fi, and UWB (Ultra Wide Band), and the system according to any one of items 1 to 8.

[13] The reception state of the identification information received by the user terminal includes at least one selected from the group consisting of reception intensity (RSSI), reception period, and reception count, and the system according to any one of items 1 to 8.

[14] The user terminal can transmit a user ID for identifying the user terminal by short-range wireless communication, and the system according to any one of items 1 to 8.

[15] The system further includes a hint providing unit capable of providing hints regarding quests, For users with a low progress degree of an event, compared with users with a high progress degree, It is possible to provide specific hints and / or It is possible to provide hints more frequently, The system according to any one of items 1 to 8.

Advantages of the Invention

[0008] According to the present invention, it is possible to provide a system, a method, and a program suitable for implementing a user experience type event that can be an experience remaining in the user's memory.

Brief Description of the Drawings

[0009] [Figure 1] A diagram showing an outline of an event implementation system according to Embodiment 1. [Figure 2] A diagram showing an example of an event realized by Embodiment 1. [Figure 3]A schematic diagram showing one of the event execution devices (user terminal) in Embodiment 1. [Figure 4] A schematic diagram showing one of the event execution devices (server) in Embodiment 1. [Figure 5] A diagram illustrating an example of how the fake product is provided in Embodiment 1. [Figure 6] A flowchart illustrating an example of the event implementation method in Embodiment 1. [Figure 7] A schematic diagram showing one of the event execution devices (server) in another embodiment. [Modes for carrying out the invention]

[0010] Hereinafter, one aspect (embodiment) of the present invention will be described with reference to the drawings. The embodiments of the present invention are not limited to those described below, and can be implemented with various modifications within the scope of the technical idea of ​​the present invention.

[0011] In this specification, the term "process" is not limited to independent processes; therefore, even if it cannot be clearly distinguished from other processes, it is included in the term "process" if the function of that process is achieved in that manner. The same applies to the term "step." Furthermore, in the contents shown in the drawings, the scale, shape, and length may be exaggerated for the sake of clarity.

[0012] The user experience event configured according to this embodiment offers high flexibility in terms of participation and engagement. Such an event may be conducted individually by a single user, or it may be conducted in a format in which multiple users cooperate with each other, or compete and challenge each other.

[0013] The quests in such events and the worldviews they create may be realistic, fictional, or have a strong narrative, tailored to the region, scale, season, and purpose. While events that appeal to gameplay are naturally included, a broader range of events are also possible, such as those aimed at fostering cooperation and initiative in education and training.

[0014] [Embodiment 1] <Event Implementation System> ≪Overview≫ The system suitable for conducting user-experience type events according to this embodiment (hereinafter sometimes simply referred to as "this system"; the same applies hereinafter, including other embodiments) is: The system comprises a server, a transmitting device that transmits identification information, and a user terminal that receives the identification information and transmits the received identification information to the server, and further, A quest completion determination unit determines the end of a quest using the identification information received by the user terminal, The acquisition unit obtains user behavior information during quests, The system includes an action history playback unit that creates user action history data during a quest based on the acquired action information, and makes the action history data playable after the quest is completed.

[0015] According to this, based on the premise that users will replay their action history data after completing a quest (to review their own actions), a moderate sense of excitement and tension will be evoked, thereby improving immersion and interest in the event and creating a memorable experience for the user.

[0016] In particular, behavioral history data may be provided to the user's device in a downloadable format. This makes it easy for users to reflect on their actions during quests, share this information with others (friends, family, colleagues, followers, etc.), and post it on social media, further enhancing a sense of excitement and tension.

[0017] Figure 1 is a diagram illustrating the schematic of this system 100. This system 100 comprises a server 10, a transmitting device 20 that transmits identification information, and a user terminal 30 that receives identification information and transmits the received identification information to the server.

[0018] Communication between the server 10 and the user terminal 30 may be possible via network wireless communication L1, such as a LAN (Local Area Network) or the Internet, and communication between the transmitting device 20 and the user terminal 30 may be possible via short-range wireless communication L2, for example. There may be multiple transmitting devices 20 and user terminals 30, in which case communication between each user terminal 30 may also be possible via short-range wireless communication L2, for example.

[0019] This system 100 is suitable for conducting user-experience type events. In this type of event, the objective is presented as a quest, which serves as an element in building the world view. Here, the quest may include, for example, victory conditions or achievement conditions in the event, and may also include defeat conditions or failure conditions. Quests allow the system to show users "what to do" and "what not to do" in the event.

[0020] Therefore, in this system, it is determined whether the predetermined victory or achievement conditions have been met, and whether the predetermined defeat or failure conditions have been met, and then the completion of the quest is determined.

[0021] Examples of quests include, for example, "discovering the target object" if the event is exploration / discovery-based, "reaching the correct answer" if the event is puzzle-solving / thinking-based, and "virtually avoiding capture" if the event is avoidance-based. In any case, a quest can be the main quest, which is the ultimate goal, or it can be individual subquests that make up the main quest or branch off from the main quest.

[0022] (Transmitter) The transmitting device 20 transmits identification information. An example of the transmitting device 20 is a beacon.

[0023] A beacon, for example, continuously transmits a beacon ID as one of its identification pieces of information at intervals of tens to hundreds of milliseconds via short-range wireless communication L2 within a predetermined area from its own device. Since the beacon ID is unique to that beacon, in the case of multiple beacons, one beacon can be identified based on a single beacon ID.

[0024] Examples of short-range wireless communication L2 methods include, but are not limited to, the Bluetooth (trademark) method. Identification information transmitted by the beacon is received by the user terminal 30.

[0025] In this system 100, beacons are placed, for example, within a designated area of ​​an event venue in the real world. Conceptually, for example, multiple beacons each emit a unique beacon ID, which is a string that distinguishes them from one another, such as "Bx_id" (where "x" is a unique integer).

[0026] Multiple transmitters 20 may be used; for example, this system 100 includes multiple transmitters 20, such as the first transmitter 20A, the second transmitter 20B, the third transmitter 20C, and so on.

[0027] (User terminal) The user terminal 30 receives identification information transmitted from the transmitting device 20 and transmits the received identification information to the server 10. The user terminal 30 may be, for example, a portable device that the user can carry. The portable device may be a smartphone, tablet, portable game console, etc., and may be a general-purpose device or a dedicated device provided for this system 100. It may be the user's own device or a device borrowed from someone else.

[0028] The user terminal 30 may be associated with a unique user ID. In this case, when the user terminal 30 transmits identification information received from a beacon to the server 10, for example, it may also transmit the user ID as one of the user identification pieces of information that identifies the user terminal 30.

[0029] Multiple user terminals 30 may be used. For example, this system 100 includes multiple user terminals 30, such as user terminal 30A used by user A, user terminal 30B used by another user B, and so on.

[0030] The user terminal 30, like the beacon 20, may, for example, continuously transmit a user ID via short-range wireless communication L2 within a predetermined area from its own device. In this case, the user terminal 30 can also function as a transmitting device. The ability of user terminals 30 to transmit and receive information from each other facilitates information sharing, cooperation, and updates among users.

[0031] (server) Server 10 is configured, for example, using a computer. It can execute various programs in an event and transmit information to the user terminal 30. Server 10 may have its components distributed across multiple computers, or at least a portion of its components may be located on the cloud.

[0032] In this system 100, the server 10, for example, receives data from a specific user terminal 30A. User ID (a user ID unique to user terminal 30A), and Beacon ID Upon receiving the beacon, the system can execute processing corresponding to the beacon ID. The processing results are sent, for example, to user terminal 30A and to other user terminals 30 within the team that includes user terminal 30A.

[0033] ≪User Experience Event≫ Figures 2(a) and 2(b) show examples of user experience events realized by this system 100.

[0034] This event's main quest involves being the first to find a total of seven "stone tablet fragments" (beacons) placed in the real world. While it may include various related subquests, we will omit their explanation here.

[0035] The event venue is divided into Exploration Area As and Free Area Af. The search for "stone tablet fragments" mainly takes place in Exploration Area As, and users who have finished their exploration there can move to Free Area Af to review their exploration as needed.

[0036] There are more than eight beacons placed within the exploration area, and users will search for these beacons in sequence. The reason there are more beacons than the "seven" required to complete the main quest is that some of them may be fakes.

[0037] During exploration, users can utilize radar. The radar is displayed, for example, on an application installed on the user terminal 30 for participation in this event. It is depicted as a roughly circular shape within the application's interface, and various information is displayed there.

[0038] On the radar, the approximate locations of the beacons B1, B2, etc., are visualized as light points, centered on the user's own position P, which is displayed as the origin. Zooming in and out is possible; zooming in allows for precise identification of the beacon's location, while zooming out provides an overview of each beacon's position.

[0039] When user terminal 30 enters the beacon's transmission area, it receives the beacon ID from the beacon. Then, for example, it sends the received beacon ID along with its own user ID to server 10.

[0040] To make it easier for users to find the beacon when they get close enough, markers 5 may be placed within the exploration area. Examples of markers 5 include upright flags, signposts, and signs. Relatively large and conspicuous containers (treasure chests, boxes, containers, tents, etc.) may also be used, and placing a beacon inside one of these can further enhance user immersion and interest through the experience of finding, opening, and obtaining items from such a box.

[0041] Throughout the quest, users may be offered fake items from time to time. These fake items may be items other than the "Stone Slab Fragment" obtained when finding a beacon, or they may be false information regarding the beacon's location. The way fake items are offered varies depending on the user's quest progress, and the presence of fake items in the quest stimulates the user's sense of gambling and makes it easier to feel satisfied when they obtain a "Stone Slab Fragment."

[0042] Incidentally, cameras 6 may be placed within the exploration area. Cameras 6 capture images of user behavior, and this information is transmitted to server 10, where information about the user's actions throughout the quest is acquired and stored.

[0043] Camera 6 can be positioned, for example, so that its imaging area includes a beacon, the user who is searching for the beacon, and / or the marker 5. It can also be positioned inside the marker 5. This makes it easier to effectively acquire information about the user's actions when they are searching for the beacon.

[0044] For example, camera 6 is placed on a designated tree. In this case, the camera can easily capture various actions of the user as they diligently search for the beacon among the dense foliage, which would serve as behavioral information. Alternatively, camera 6 is placed inside the marker 5 that contains the beacon (for example, the inside of the lid of the treasure chest containing the beacon or the inside of the tent, which would serve as marker 5). In this case, the camera can easily capture the user's facial expression as behavioral information at the very moment they discover the beacon by opening the treasure chest or entering the tent.

[0045] The user's actions, captured in this way, are provided as activity history data after the quest is completed, for example, on the user's device or in a downloadable format. Based on the premise that users will reflect on their own actions, it is easier to evoke a moderate sense of excitement and tension, and it is easier to improve immersion and interest in the event.

[0046] The user progresses through the exploration, and the quest is completed when the achievement condition is met by being the first to find all seven "stone tablet fragments". The user moves from the exploration area As to the free area Af, where, for example, an AR marker M is placed on a set diorama that mimics the location of a beacon. AR The AR marker M is placed there. The user can access the AR marker M. AR The user terminal 30 reads the data, which allows the AR data provided as behavioral history data to be played back on the set diorama. This makes it easier for the user to remember the experience, and also encourages word-of-mouth and social media posts, which is commercially advantageous.

[0047] Furthermore, if the above quest is one of several subquests, the action history data for that subquest, even if the main quest is still in progress, may be made playable. This provides an opportunity to reflect on one's actions and makes it easier to increase motivation for completing the next subquest or main quest.

[0048] ≪Event execution device (user terminal)≫ Figure 3 is a schematic diagram of a user terminal 30, which is one of the event execution devices that make up the system 100. The user terminal 30 can be configured to include, for example, a communication unit 31, a storage unit 32, a display / input unit 33, a position sensor 34, and a control unit 35. If multiple user terminals 30 are used, they may have similar configurations.

[0049] The communication unit 31 is comprised of, for example, a short-range wireless communication unit and a network communication unit. This communication unit 31 facilitates suitable communication with other devices.

[0050] The short-range wireless communication unit consists of, for example, an adapter for receiving short-range wireless communication, and is composed of, for example, a Bluetooth adapter. According to the short-range wireless communication unit, short-range wireless communication L2 makes it easier to receive, for example, a beacon ID transmitted from a beacon, and also makes it easier to transmit, for example, a user ID that identifies the user terminal within a predetermined area.

[0051] The network communication unit consists of, for example, a network adapter. The network communication unit facilitates communication with, for example, the server 10 via wireless communication L1, and also facilitates the transmission of, for example, the user ID and the beacon ID to the server 10 when the short-range wireless communication unit receives a beacon ID. Furthermore, it can also suitably receive, for example, information indicating the processing content executed by the server 10 from the server 10.

[0052] The storage unit 32 is composed of, for example, ROM (Read Only Memory) and RAM (Random Access Memory). The storage unit 32 can store, for example, a program (client program) to be executed in this system 100. By executing this program, the computer can perform processes such as displaying various information about events transmitted from the server 10, inputting various instructions from the user, receiving and transmitting beacon IDs and user IDs.

[0053] Furthermore, the memory unit 32 can store, for example, its own user ID. Such user ID may be stored in the memory unit 32 at the time the program is installed on the user terminal 30 for participation in this event. In addition, it can also store, for example, information about items owned by the user. Information stored in this type of memory unit 32 may be read out as needed and used for computer processing.

[0054] The display / input unit 33 is composed of, for example, a liquid crystal touch panel display. The display / input unit 33 makes it easy to display various information about an event to the user, and also makes it easy to input predetermined information about an event into the user terminal 30. The content displayed on the display / input unit 33 may correspond to the information transmitted from the server 10. The input information may be transmitted to the server 10 and also stored in the storage unit 32.

[0055] The display and input sections may be provided separately. In this case, the input section may consist of a predetermined push-button device or an external keyboard, rather than a touch panel.

[0056] The position sensor 34 consists of a GPS (Global Positioning System) sensor, etc. The position sensor 34 makes it easy to measure, for example, the position of the user terminal 30. Based on the acquired position information and the time when that position information was measured, the movement speed of the user terminal 30 can also be easily calculated.

[0057] The control unit 35 is composed of, for example, a CPU (Central Processing Unit) and a microcontroller. The control unit 35 can, for example, store and retrieve various types of information in the storage unit 32, and operate various parts of the user terminal 30 according to the program stored in the storage unit 32.

[0058] In one embodiment, the control unit 35 may include a reception detection unit 36. The reception detection unit 36 ​​can, for example, detect the reception status of a beacon ID transmitted from a beacon in the communication unit 31 (short-range wireless communication unit). At this time, the control unit 35 may transmit its own user ID stored in the storage unit 32 and the received beacon ID to the server 10 via the communication unit 31 (network communication unit).

[0059] The "beacon ID reception status" includes at least one selected from the group consisting of the reception strength of the beacon ID received by the short-range radio communication unit, the reception period which is the period during which the same beacon ID was received consecutively, and the reception count which is the number of times the same beacon ID was received consecutively. The reception period is calculated based on the time each beacon ID was received, after obtaining the time at which each beacon ID was received.

[0060] The radio waves carrying identification information transmitted by a beacon become stronger the closer you get to the beacon. Therefore, the closer the distance between the beacon and the user terminal 30, the stronger the received signal strength in the short-range wireless communication unit. In other words, the received signal strength serves as an indicator of how close (or far) the user terminal 30 is to the beacon.

[0061] Once the distance of the user terminal 30 to the beacon is derived, it is possible to derive the speed and acceleration of the user terminal 30 as it approached (or escaped) the beacon by combining it with time elements such as reception time and timing.

[0062] As described above, the beacon continuously transmits its beacon ID at predetermined intervals. Therefore, the longer the user stays within the beacon's transmission area, the greater the reception period and the number of receptions on the user terminal 30. In other words, the reception period and the number of receptions can also be used as indicators to determine how long the user stayed within the beacon's transmission area (i.e., near the beacon).

[0063] The reception status of the beacon ID, as well as various information derived from it, are stored in the memory unit 32 and read out as appropriate.

[0064] ≪Event execution device (server)≫ Figure 4 shows a schematic diagram of a server 10, which is one of the event execution devices that make up the system 100. The server 10 can be configured to include, for example, a communication unit 11, a storage unit 12, an acquisition unit 14, and a control unit 15.

[0065] The communication unit 11 is configured to include, for example, a network communication unit. This communication unit 11 facilitates suitable communication with other devices.

[0066] The communication unit 11 (network communication unit) is composed of, for example, a network adapter. The network communication unit facilitates communication with, for example, the user terminal 30 via wireless communication L1, and also facilitates the reception of, for example, user IDs and beacon IDs from the user terminal 30. Furthermore, the communication unit 11 facilitates the transmission of, for example, information indicating the processing content of an event to the user terminal 30.

[0067] The memory unit 12 is composed of, for example, a hard disk, ROM, and RAM. The memory unit 12 can store, for example, a program (main program) to be executed in the system 100. By executing this program, the computer can be made to perform the progression and branching of events executed in the system 100, as well as determine the completion of quests.

[0068] The memory unit 12 can store information acquired by the acquisition unit 14 and action history data generated by the control unit 15. It can also store various conditions for completing various quests (main quests and sub-quests) (e.g., victory conditions, achievement conditions, defeat conditions, and failure conditions), as well as the completion status of various quests (e.g., whether completed or not). The memory unit 12 can also store thresholds and reference values ​​used for various judgments and decisions.

[0069] Furthermore, the memory unit 12 can store various databases (DBs) that are referenced as appropriate in event processing. Examples of such DBs include the user DB 12y and the item DB 12i.

[0070] In user DB12y, for example, each user ID of user terminal 30 (all user terminals participating in the event) is associated with item information, meaning that information about which user owns which items is stored. User IDs in user DB12y may be stored, for example, when a client program installed on user terminal 30 receives information transmitted from that user terminal 30.

[0071] In Item DB12i, for example, a beacon ID is associated with an item ID that identifies the item. Items here are divided into essential items that are necessary to complete a quest and general items (fake items) that are not essential. General items can be broadly treated as "fake items," but among such general items, items with lower usefulness or rarity compared to others, or items that have disadvantages, etc., may be treated as "fake items" in a narrower sense.

[0072] The acquisition unit 14 acquires information about the user's actions during the quest. The actions to be acquired broadly include those involving movement. This includes actions related to physical movement such as walking, running, searching, looking around, pushing, opening, nodding, and tilting the head, as well as actions related to facial expressions such as being surprised, laughing, and frowning. For example, image information of these actions is acquired. Audio information may also be acquired simultaneously or independently. This information is acquired, for example, by cameras 6 placed within the exploration area. In this case, the acquisition unit 14 may include the cameras 6.

[0073] The acquisition unit 14 preferably starts and / or stops acquiring user behavior information according to the reception status of the beacon ID transmitted from the beacon. This makes it easier to efficiently acquire behavior information by targeting the user's actions.

[0074] For example, it is preferable that the acquisition unit 14 determines that the received strength of the beacon ID is equal to or greater than a predetermined threshold T1 (the user is approaching the beacon) and then starts acquiring behavioral information. Alternatively, it is preferable that the acquisition unit 14 determines that the received strength of the beacon ID is equal to or less than a predetermined threshold T2 (the user is moving away from the beacon) and then ends acquiring behavioral information. These thresholds T1 and T2 may be stored in the storage unit 12 and may be read out as appropriate when making determinations.

[0075] In addition, the acquisition unit 14 may determine if the user terminal's stay time within the beacon's transmission area is above a predetermined threshold, and then start or stop acquiring behavioral information. This also makes it easier to efficiently acquire behavioral information by targeting the user's actions.

[0076] The control unit 15 is composed of, for example, a CPU and a microcontroller. The control unit 15 can, for example, store and retrieve various types of information in the storage unit 12, and operate each part of the server 10 according to the program stored in the storage unit 12.

[0077] In one embodiment, the control unit 15 can be configured to include, for example, a processing execution unit 16, a quest completion determination unit 17, a fake provision unit 18, and an action history playback unit 19.

[0078] The processing execution unit 16 can, for example, execute event-based processing corresponding to the reception of a user ID or beacon ID from a user terminal 30. Events in this system 100 basically proceed through processing by this processing execution unit 16.

[0079] Furthermore, the processing execution unit 16 can also determine, for example, the progress of an event. For example, it is easier to determine the progress of an event by appropriately reading information stored in the storage unit 12.

[0080] Currently, the "progress of the event" may be determined based on at least one element selected from a group consisting of, for example, the number of required items acquired, the number of subquests completed, and whether or not a specific required item has been acquired. For example, if the number of acquired items is judged to be higher than the baseline number (pre-stored in memory unit 12), if the number of completed items is judged to be higher than the baseline number (pre-stored in memory unit 12), or if a specific flag item is possessed, the progress of the event may be judged to be high.

[0081] The quest completion determination unit 17 determines the completion of a quest using identification information received by the user terminal 30. For example, it reads the quest completion conditions stored in the memory unit 12, and compares this with the beacon ID, preferably the user ID, received from the user terminal 30 to determine that the completion conditions have been met (that the corresponding quest has been completed). At this time, the control unit 15 may process the display of the next quest on the user terminal 30.

[0082] In one embodiment, when the control unit 15 receives a user ID and a beacon ID, it triggers a process to associate the item information (item ID) previously associated with the beacon ID with the user ID, based on the user ID being above a predetermined signal strength (indicating the user has approached the beacon). As a result, the item, as a virtual object, is assigned to the user. The acquired item may, for example, be displayed on the application of the user terminal 30.

[0083] Furthermore, the control unit 12 may include a fake item provider unit 18. The fake item provider unit 18 can, for example, provide fake items related to quests. The fake item provider unit 18 can also, for example, execute event processing in response to receiving a user ID or beacon ID from a user terminal 30. Currently, in this system 100, a part of the control unit 15, together with the item DB 12i, constitutes this fake item provider unit 18.

[0084] Figure 5 is a diagram illustrating an example of how fake items are provided, showing an example of the configuration of the item DB12i. In the item DB12i, the beacon ID and item information (item ID) are associated with each other, organized into a table, and stored in the storage unit 12.

[0085] Conceptually, here, information indicating essential items required to complete a quest is represented by strings such as "item_id01", "item_id02", etc., while information indicating fake items is represented by strings such as "fake_id01", "fake_id02", etc.

[0086] Currently, the first beacon ID "B1_id" is associated with the required item ID "item_id01_A". At this time, if the user finds the first beacon, they can obtain the first required item as a virtual object, triggered by the reception of identification information from this first beacon and the reception strength being above a predetermined threshold.

[0087] On the other hand, the second beacon ID "B2_id" is associated with two types of item IDs: the required item ID "item_id02" and the fake item ID "fake_id02". At this time, a lottery (a lottery from the two types of item IDs) is held, triggered by the reception of identification information from this second beacon and the reception strength being above a predetermined threshold. A user who finds the second beacon cannot obtain the second required item unless they win the lottery.

[0088] Furthermore, the third beacon ID "B3_id" is associated only with the fake item ID "fake_id03". In this case, even if the user finds this third beacon, they will only be able to obtain the fake item.

[0089] Preferably, the fake content provider 18 can provide fake content more frequently to users whose event progress is high, as determined by the processing execution unit 16, compared to users whose progress is low. This makes it easier to increase the element of chance for users who are gaining an advantage in the event, and to create the possibility of a comeback for users who are following suit. In any case, it makes it easier to further improve immersion and entertainment value.

[0090] In one embodiment, if a beacon ID is associated with both a required item ID and a fake item ID, the probability of winning a required item ID may be lower for users who have progressed further in the event compared to users who have progressed less. This also makes it easier to further enhance immersion and interest.

[0091] Furthermore, it is preferable that the fake information provider 18 can provide specific fake information to users who are at a higher stage of the event compared to users at a lower stage. By providing advantageous users with specific, strong fake information, it is easier to create the possibility of a comeback for users who are following along, as described above. Advantageous users are presumably more relaxed, and in this case, even strong fake information can contribute to increased interest due to its rarity.

[0092] In one embodiment, if a fake item ID is associated with a predetermined beacon ID, the fake item given to users who have progressed further in the event may be an unattractive item, such as one with low usefulness, low rarity value, or one that comes with a disadvantage. This also makes it easier to further enhance immersion and interest.

[0093] The contents of the table in Item DB12i, which associates beacon IDs and item IDs, may change dynamically, for example, according to the progress of the event. By changing the table so that certain fakes can be provided to users who are at a higher stage of event progress, and / or so that fakes are provided more frequently, it becomes easier to further improve immersion and interest for all users.

[0094] The activity history playback unit 19 creates user activity history data during a quest based on the activity information acquired by the acquisition unit 14, and makes the activity history data playable after the quest is completed.

[0095] The behavioral history data preferably includes image data and / or video data that review user behavior during quests. If the behavioral information includes, for example, the above-mentioned imaging information acquired by a camera, image data and video data can be created based on or appropriately edited from this information. Multiple behavioral history data sets may be created, for example, in chronological order.

[0096] Methods for making the activity history data replayable after the quest is completed include, for example, running a program on the user terminal 30's application to play the data, or providing the activity history data to the user terminal 30 in a downloadable format. In any case, the premise that the activity history data will be played back (to reflect on one's own actions) after the quest is completed makes it easier to evoke a moderate sense of excitement and tension.

[0097] Currently, it is preferable that the behavioral history data includes Augmented Reality (AR) data that allows users to review their actions during quests, either by replaying it with or without predetermined markers. This allows for the recreation of experiences linked to reality through data playback, creating a sense of the extraordinary and making it easier to retain the experience in the user's memory.

[0098] AR data may be created in the control unit 15 using known techniques, and may be stored in the storage unit 12 and read out as needed. The AR data may also be provided to the user terminal 30 in a downloadable format.

[0099] AR data-based effects can be implemented, for example, during the processing stage where logs stored in the memory unit 12 are formatted to extract key points and miraculous moments of user behavior, then smoothed in space and time, and finally rendered according to themes.

[0100] Here, it is preferable for the behavior history playback unit 19 to calculate the user's contribution to the quest based on at least one of the behavior information acquired by the acquisition unit 14 and the reception status of the beacon ID from the beacon, and it is even more preferable to display the calculated user contribution to the user. This makes it easier to calculate a contribution that appropriately reflects the user's contribution to the quest, and it is also easier to evoke a moderate sense of excitement and tension based on the premise that one's own user contribution is calculated (one's own actions are evaluated).

[0101] As described above, based on user behavior information, it is possible to derive the user's behavior and facial expressions near the beacon, and based on the reception status of the beacon ID, it is possible to derive the user's distance to the beacon, speed and acceleration, time spent near the beacon, etc.

[0102] Therefore, for example, the behavior history playback unit 19, The system can determine if the user terminal 30's time spent near the beacon is less than a predetermined standard value (pre-stored in the memory unit 12), and this can be treated as a high-scoring criterion. This is because it can be inferred that the user found the beacon without getting lost.

[0103] Furthermore, for example, the behavioral history playback unit 19, The system can determine that the user terminal 30 has left the beacon's transmission range and use this as a low-scoring criterion. This is because it can be inferred that the user lost track of the beacon during the search process.

[0104] Furthermore, for example, the behavioral history playback unit 19, The system can determine if the acceleration of the user terminal 30 relative to the beacon is greater than a predetermined standard value (pre-stored in the memory unit 12), and this can be set as a high-scoring criterion. This is because it can be inferred that the user ran directly towards the beacon.

[0105] Furthermore, for example, the behavioral history playback unit 19, The system can determine if a user has waved their hand vigorously near a beacon and use this as a criterion for a high rating. This is because it can be inferred that the user is a cooperative player who has called for help from teammates.

[0106] Based on these high and low evaluation criteria, the user contribution score may be calculated using a predetermined function, or it may be calculated using an additive or subtractive scoring system, but is not limited to these methods, with appropriate weighting applied.

[0107] The behavior history playback unit 19 preferably calculates the user's contribution to the quest based on the degree to which the user utilizes the behavior history data. For example, if the utilization of behavior history data is highly rated and positively impacts the user's contribution, it becomes easier to encourage the user to utilize the behavior history data. This makes it easier for users to actively reflect on their own actions, and as a result, it becomes easier to further improve immersion and interest during events.

[0108] The degree to which users utilize behavioral history data can be measured by, for example, the number of times the behavioral history data provided to the user is played back, the duration of playback, and the number of times it is shared with the team. The behavioral history playback unit 19 can determine if these counts and / or durations are higher than predetermined baseline values ​​(pre-stored in the memory unit 12), and can then treat this as a high evaluation requirement when calculating user contribution.

[0109] Furthermore, it is preferable that the behavior history playback unit 19 provides rewards for quests to the user in proportion to the user's contribution. Under a system where users with higher user contributions receive more rewards, this can serve as an incentive for users to increase their user contribution.

[0110] User contributions may be displayed to the user as scores, ranks, and / or images. Scoring allows users to easily understand their level of contribution as a score, while ranking allows users to easily understand their level of contribution as a rank. Visualization allows users to easily grasp their contribution visually as it is represented by shapes, characters, etc.

[0111] Preferably, the control unit 15 described above is capable of distinguishing and displaying unexplored areas of the user or user team members on the map displayed on the user terminal 30. This allows the user to efficiently explore unexplored areas, thus making it easier to avoid stress caused by unintentionally exploring already explored areas repeatedly. The map on the user terminal may be displayed on the user terminal's application, and information from the position sensor 34 of the user terminal 30 may be appropriately utilized to identify areas of activity.

[0112] <Event Implementation Method and Program> A further embodiment of this embodiment is: A suitable method for conducting user-experience-based events through quests (hereinafter sometimes simply referred to as "this method," including other embodiments, the same applies hereinafter), A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. This is an event implementation method that includes [specific features / features].

[0113] In this method, the steps comprising it are not limited to the order described above, and multiple steps may be performed simultaneously, or some steps may be repeated.

[0114] Figure 6 is a flowchart showing an example of the flow of this method. In step S1, information about the user's actions during the quest is obtained.

[0115] Then, in step S2, the user terminal that receives the identification information transmitted from the transmitting device determines the end of the quest using the identification information received by the user terminal. Steps S1 to S2 are repeated until the end of the quest is determined, but only step S2 may also be repeated.

[0116] Once the completion of the quest is determined, the process proceeds to step S3, where, based on the acquired action information, user action history data for the quest is created. Then, the process proceeds to step S4, where the action history data is made playable after the completion of the quest. In step S4, for example, the server 10 receives a playback request from the user (a playback request signal transmitted from the terminal device 30) input to the user device 30 (step S5), and then executes a process to make such data playable on the user terminal 30 (step S6).

[0117] A further embodiment of this embodiment is: This program is suitable for conducting user-experience-based events through quests. A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. It is a program designed to be executed by a computer system.

[0118] Regarding the above methods and programs, various details may be referenced from the various details described in the above-mentioned system. Some of these may be combined as appropriate, and preferred embodiments may be provided.

[0119] As described above, this system 100 can enhance immersion and interest, resulting in a memorable experience for the user. On the other hand, the configuration of this system can be modified in various ways within the scope of the technical concept of the present invention.

[0120] [Other embodiments] Unlike the first embodiment described above, the user terminal 30 may be equipped with and capable of executing the DB and processing execution unit 16 on the server 10 side. In this case, for example, event processing is executed within the user terminal 30, and result information indicating the result of that processing is sent to the server 10. The server 10 can proceed with the event based on the result information sent from the user terminal 30.

[0121] The configuration of the control unit is not limited to that of the control unit 15 described in Embodiment 1 above. For example, the fake provisioning unit may provide fakes to the user in a manner different from that of the fake provisioning unit 18.

[0122] Figure 7 shows a schematic diagram of the control unit 15A according to another embodiment. In this embodiment, the control unit 15A, in particular the fake provisioning unit 18A, includes, for example, a user distribution measurement unit.

[0123] The user distribution measurement unit can measure the distribution of users in the search area of ​​the event venue. For example, the user distribution measurement unit measures the distribution of users based on at least one piece of information selected from the group consisting of information about the position sensor 34 from the user terminal 30, information about the reception status of the transmitting device received by the user terminal 30, and user behavior information acquired by the acquisition unit 14.

[0124] The memory unit 12 stores the map sections of the search area (for example, a map section that can be identified by numerical values ​​along the X-axis in the east-west direction and the Y-axis in the north-south direction). At this time, the user distribution measurement unit estimates the congestion status in each section using, for example, the section information read from the memory unit and the measured user distribution.

[0125] Here, the fake information provider 18A can provide the user with fake information based on the estimated congestion status. The fake information here may be, for example, a false location of a beacon displayed on the application of the user terminal 30.

[0126] For example, the fake information provider 18A can display false beacon locations more frequently or in greater numbers in areas with less congestion compared to areas with more congestion. This helps to level out the user distribution, contribute to congestion reduction, improve event satisfaction, and ultimately create a more memorable experience for users. Note that the fake information is not limited to the above and may include false hints provided during the event.

[0127] Various wireless communication standards such as Bluetooth, BLE (Bluetooth Low Energy), LoRa (LoRa), UWB (Ultra Wide Band), and Wi-Fi (Wi-Fi) can be suitably used.

[0128] The control unit 15A may be able to provide hints about the quest in the same manner as providing fake hints. A hint ID may be associated with the beacon ID, and the hints given to users who have made little progress in the event may be attractive, such as being highly useful, having high rarity value, or providing benefits.

[0129] Such hints may include information that suggests the beacon's location to the user (direction, landmarks, specific map names, etc.). By adjusting the hint information and / or its frequency of provision to equalize the congestion levels in the exploration area, it becomes easier to guide the user effectively. This also contributes to improving the performance of lower-performing players and makes it easier to effectively achieve events.

[0130] Fakes and hints may be dynamically generated depending on the progress of the event and / or the congestion level of the exploration area. Of course, information pre-stored in memory may also be read and provided as needed.

[0131] In Embodiment 1 described above, an example of an event was explained that aimed at quickly searching for a beacon (quickly receiving a strong signal from a beacon). However, the applicable events are not limited to the above, and may also include cases where a virtual threat is threatening the beacon, and the goal is to avoid such a virtual threat (avoiding a strong signal from the beacon).

[0132] The system described above utilizes various wireless technologies and can provide new experiential entertainment and value. For example, regarding application scenarios of this system, Adding a treasure hunt element to orienteering at a ski resort during the off-season. In real-world competitive games such as survival games, lending beacons to participants adds new entertainment elements such as organized combat, treasure hunts, and avoidance of virtual threats. At a renovated abandoned school facility, staff members dress up as ghosts, adding a ghost-hunting element to the experience. Such proposals have been considered, and of course, they are not limited to these, demonstrating their significant innovativeness.

[0133] (Examples of application) The following are examples of applications of this system.

[0134] • System overview and quest determination In one embodiment, the determination of quest completion may be triggered by the detection of a "nearby stay event" based on basic statistics of the reception history of identification information. For example, an adaptive threshold Tt = μt + k·σt (where k is set according to the state vector) can be applied to the moving average μt and variance σt of the reception intensity. When the number of receptions exceeding the adaptive threshold Tt reaches a predetermined number M, the beacon can be treated as a candidate for discovery and used to determine whether the main quest or sub-quest has been completed.

[0135] Here, "reception history of identification information" may refer to time-series data such as the reception strength (RSSI, etc.), reception time, reception interval, and / or channel number of the identification information received by the user terminal from the transmitting device. The "state vector" may refer to a list of multiple operational parameters referenced in the operation of the quest, such as event progress, congestion index, search stagnation index, and user team composition, and this may be used for the dynamic updating of thresholds and coefficients for each process.

[0136] • Camera placement and action acquisition The acquisition of behavioral information may be started and stopped in synchronization with the adaptive threshold determination of the reception history. For example, the camera 6 can start imaging when the adaptive threshold Tt is exceeded (nearby stay event) is detected, and imaging can stop when the adaptive threshold Tt is not exceeded for a predetermined period of time. This makes it easier to improve the efficiency of acquiring highly interesting moments such as the user's facial expressions and movements.

[0137] AR playback and special effects In one embodiment, AR playback data of behavioral history data may be generated by a stepwise process including log formatting, trajectory simplification, smoothing, event tagging, and theme-based rendering. Here, "trajectory simplification" may use, for example, a general piecewise linear simplification method (e.g., simplification based on tolerance ε), and "smoothing" may use, for example, a general time-series smoothing method (e.g., moving average). Multiple themes may be provided, such as radar-style or diorama-style, and may be switchable by the user or operator (administrator).

[0138] • Server configuration and database The memory unit may be provided with a short-term log area that stores basic statistics of the reception history (e.g., moving average and variance), and a management area that stores state vectors such as event progress and congestion index. Parameters such as window width W, predetermined number of times M, coefficient k, and weight w_i can be changed via a settings screen or operator settings file.

[0139] • Acquisition section, start and end conditions More specifically, the acquisition unit may update the adaptive threshold Tt = μt + k·σt based on the moving average μt and variance σt calculated from the reception history. When the adaptive threshold Tt is exceeded for a predetermined number of consecutive receptions, an imaging start flag may be set, and if the state of not exceeding the threshold continues for a predetermined time, an imaging end flag may be set. This makes it easier to obtain resistance to environmental fluctuations and the effects of multiple paths compared to simply fixing the threshold.

[0140] • Processing execution unit and termination determination unit The quest completion determination unit may extract events that exceed the adaptive threshold Tt as "discovery completion candidates," compare them with the item acquisition history associated with the user ID, and determine that the main quest has been completed if a predetermined number of required items have been obtained. For subquests, completion may be determined by at least one of multiple conditions, such as obtaining a specific flag item, achieving a predetermined exploration procedure, and / or exploring a certain percentage of unexplored areas.

[0141] Fake Provider The fake location provider may represent the search area as a grid of sections G(x,y) and update the probability field P_fake(x,y) for false location presentation based on operational indicators such as the congestion level ρ(x,y) and dwell time τ(x,y) of each section. As an operational safety valve, the maximum number of people to guide and the congestion level upper limit may be set in advance for each section, and the frequency of false location presentation may be suppressed as long as these do not exceed. Note that updating P_fake may also be done by simple rules based on an evaluation function aimed at reducing the variance (ρ) and the average dwell time (for example, suppressing presentation to higher congestion sections and promoting presentation to lower congestion sections). As an operational safety valve, the maximum number of people to guide and / or the congestion level upper threshold may be set and stored for each section, and the manner of fake location presentation (for example, frequency of presentation and content of fakes) may be controlled as long as these do not exceed these limits.

[0142] • Playback of activity history and AR generation The generation of behavioral history data may be carried out through a step-by-step process including formatting of time series data (missing data imputation and format standardization), trajectory extraction (sequencing of time, location, and reception intensity), simplification (simplification of line data based on tolerance error ε), smoothing (suppression of fluctuations by moving average), event tagging (discovery, merging, departure, re-exploration, etc.), and theme-based rendering.

[0143] • Calculation of contribution User contribution is calculated as a weighted composite score of basic metrics. For example, it may be calculated as Score_u = w1·"N_detect" + w2·"(D / D1)" + w3·"Q_hint" + w4·"A_team" - w5·"E_escape". Here, N_detect is the number of discovery events, D / D1 is the normalization of movement amount, Q_hint is an index of the usefulness of the hints provided, A_team is the team contribution action, and E_escape is the exploration exit event. The weight w1 may be a fixed value, or it may be updateable from the operator's settings screen according to the state vector.

[0144] • Utilization of behavioral history The degree of utilization of behavioral history data can be measured by the number of plays, playback time, or the number of team shares, or / or all of these. If the utilization level exceeds a predetermined threshold, a mechanism may be adopted to incentivize post-activity reflection, such as by adding points to the user's contribution.

[0145] • Display of uninvolved areas Unexplored areas can be displayed by combining user terminal location sensor information (such as simple GPS coordinates) and potential discovery results from the reception history, coloring each section G(x,y) as explored / unexplored. The coloring criteria can be fixed, or they can be changed from a state vector depending on the event difficulty.

[0146] • Methods and Programs The above program may be executed in the following order: input (received history, location sensor), preprocessing (moving average, variance calculation), adaptive threshold update (Tt update), discovery success candidate extraction, quest determination, UI reflection, action history generation, and AR playback data output. Each stage may be executed on the server side, or some of them (for example, at least one of preprocessing, UI reflection, or AR playback) may be executed on the terminal side.

[0147] • Crowd conditions and fake / hints The congestion level may be estimated by combining several basic indicators (all of which are generally obtainable indicators), such as the approximate number of terminals in use in section G(x,y), the average dwell time, and the distance between neighboring terminals. The presentation of fakes may be carried out based on simple rules using these indicators, with an upper limit set on the frequency of presentation.

[0148] Hint information may be provided using simple information such as directions, landmarks, and section names, with the aim of leveling out congestion and encouraging lower-performing users to improve their performance. The frequency of hint provision may be adjusted according to the state vector, while respecting safety valves (maximum number of guides, upper limit of congestion).

[0149] • Parameter example An example of each parameter in this application is as follows: Window width W: 5 seconds Prescribed number of times M: 3 times Coefficient k: 1.5 Tolerance ε: 1.0 Weights w_i: {1.0, 0.3, 0.5, 0.7, 0.4} Maximum number of people: 20 Maximum congestion level: 0.8 (utilization rate per section)

[0150] (summary) At least one of the contents of the other embodiments described above may be appropriately combined with the contents of Embodiment 1. In other embodiments, a mode may be adopted in which preprocessing and provisional calculation of contribution are performed on the terminal side, and the server side receives the result information and performs only aggregation and consistency. From the viewpoint of privacy protection, operational rules may be added to clearly indicate the start and end conditions of camera imaging, the storage period, and the purpose of use on the terminal UI. [Industrial applicability]

[0151] According to the present invention, it is possible to provide a system, method, and program suitable for conducting user-experience type events that can create a memorable experience for users. [Explanation of symbols]

[0152] 100: Event Implementation System 5: Landmark 6: Camera 10: Server 11: Communications Department 12: Storage section 12y: User Database 12i: Item Database 14: Acquisition part 15,15A: Control Unit 16: Processing Execution Unit 17: Quest Completion Determination Section 18,18A: Fake content provider 19: Action History Playback Department 20: Transmitter 30: User terminal 31: Communications Department 32: Storage section 33: Display / Input Section 34: Position sensor 35: Control Unit L1: Network Wireless Communication L2: Near field communication As: Exploration Area Af: Free Area

Claims

1. A system suitable for conducting user-experience type events, The system comprises a server, a transmitting device that transmits identification information, and a user terminal that receives the identification information and transmits the received identification information to the server, and further, A quest completion determination unit determines the end of a quest using the identification information received by the user terminal, The acquisition unit obtains user behavior information during quests, The system includes: an action history playback unit that creates user action history data during a quest based on the acquired action information and makes the action history data playable after the quest is completed; and a fake provision unit that can provide fake information related to the quest. The event implementation system is capable of providing specific fake content to users who are further along in the event's progress, and / or providing fake content more frequently, compared to users who are less advanced.

2. The system according to claim 1, wherein the behavior history data includes image data and / or video data that review user behavior during a quest.

3. The system according to claim 1, wherein the behavior history data includes Augmented Reality (AR) data that allows users to review their actions during a quest, which is reproduced with or without predetermined markers.

4. The acquisition unit includes a camera that captures images of the user. The system according to claim 1, wherein the acquisition of user behavior information is started and / or terminated in accordance with the reception status of the identification information transmitted from the transmitting device.

5. The aforementioned behavioral history playback unit, The system according to claim 1, which calculates the user's contribution to a quest based on at least one of the acquired behavioral information and the reception status of the identification information from the transmitting device.

6. The aforementioned behavioral history playback unit, The system according to claim 1, which calculates the degree to which user behavior history data is utilized, and then calculates the user's contribution to a quest based on the degree to which the behavior history data is utilized.

7. The system according to claim 5 or 6, further comprising a reward provision unit that provides the user with a reward for a quest in a proportion obtained using the user contribution.

8. The system according to claim 1, which can distinguish and display areas that have not yet been visited by a user or a user team member on a map displayed on the user terminal.

9. A system suitable for conducting user experience type events, The system comprises a server, a transmitting device that transmits identification information, and a user terminal that receives the identification information and transmits the received identification information to the server, and further, A quest completion determination unit determines the end of a quest using the identification information received by the user terminal, The acquisition unit obtains user behavior information during quests, An action history playback unit creates user action history data during a quest based on the acquired action information, and makes the action history data playable after the quest is completed. It includes a fake information provider section capable of providing fake information related to quests, An event implementation system that measures user distribution, estimates congestion levels using the measured user distribution, and provides users with fake quests so that the estimated congestion levels are leveled out.

10. A suitable method for conducting user-experience-based events through quests, A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. It has, An event implementation method comprising measuring the user distribution, estimating the congestion level using the measured user distribution, and providing users with fake quests so that the estimated congestion level is leveled out.

11. This program is suitable for conducting user-experience-based events through quests. A user terminal that receives identification information transmitted from a transmitting device determines the end of the quest using the identification information received by the user terminal, Steps to obtain user behavior information through quests, Based on the acquired behavioral information, the user's behavioral history data during the quest is created, and the behavioral history data is made playable after the completion of the quest. The steps include measuring the user distribution, estimating the congestion level using the measured user distribution, and providing users with fake quests so that the estimated congestion level is leveled out. A program designed to be executed by a computer system.

Images