JP2024098921A - Gift giving system - Google Patents

Abstract

[Problem] While considering that the giver selects the gift, the present invention aims to enable gift giving that is entertaining like a game, and to reduce the time and effort required for preparation. [Solution] The giver displays a game execution page with a game application 31 on the giver terminal 3, and each participant displays a game execution page with a game application 41 on each participant terminal 4. When the giver presses a standby button 75, a challenger is nominated and their nickname is displayed in a challenging participant display field 74. Each selection button 78, which is iconized with the gift name and image of the gift presented, is placed on a circular orbit. When the giver presses a start button 76, each selection button 78 rotates along the circular orbit, and when it stops, each participant presses an arbitrary selection button 78. The participant ID of the participant who pressed the selection button 78 first is associated with the gift ID of the presented gift displayed by that selection button 78. [Selected Figure] Figure 1

Description

The invention of this application relates to a system used when a giver gives gifts to multiple recipients.

It is said that Japanese people are a race that loves giving gifts. Giving gifts is almost essential for smoothing interpersonal relationships, and gifts are widely given to friends, acquaintances, business associates, and others. Among these, gift catalogs, which allow the recipient to choose a gift from a catalog, are very popular because they allow the recipient to receive a gift that reflects their preferences.
In addition, there are also many situations where gifts are given to multiple recipients at once. Typical examples are wedding favors at wedding receptions and gifts in return for funeral attendees. In these cases, gifts are often given from a gift catalog.
IT is also being used for such catalog gifts, and services have been introduced that allow the recipient to select items from the catalog on a website. Patent Document 1 also introduces a technology in which the giver selects items from the catalog to create a custom-made catalog gift and present it to the recipient.

JP 2007-11524 A

The gift catalog as described above is advantageous in that the recipient can select a gift and can easily choose a gift that matches the recipient's tastes and the gift that the recipient has wanted. However, when presenting gifts to multiple recipients at one time, such as at an event, it may be desirable to present the gifts with entertainment value, such as a game. Such entertainment value cannot be obtained by distributing conventional gift catalogs. However, there is a problem in that it takes time and effort to prepare the game when actually playing a game and presenting gifts as prizes.
The present invention has been made in consideration of the above points, and aims to make it possible to give gifts in a game-like, entertaining way while still allowing the giver to select the gift, and to reduce the time and effort required for preparation.

In order to solve the above problems, this specification discloses a gift presentation system. The disclosed gift presentation system is a gift presentation system used when a giver presents gifts to multiple recipients. This system includes a server that can be accessed via a network by a giver terminal operated by the giver, and a memory unit.
The storage unit stores a gift information master file and a presented gift information file.
The gift information master file is a file that records information about each gift that can be given.
The presented gift information file is a file that records information on gifts that the giver has selected as gifts to be presented from among the gifts recorded in the gift information master file.
The server is capable of providing a gift selection page to the gift giver terminal, and also has a gift registration program installed in the server.
The gift presentation selection page is a page where the user can input whether or not to select each gift recorded in the gift information master file as a gift to be presented, and is a page where the gift presentation registration program can be executed.
The gift presentation registration program is a program for recording each gift selected on the gift presentation selection page in a gift presentation information file.
A game means is provided for playing a game when presenting each gift recorded in the presented gift information file to a recipient, and the game means is a means for determining which gift is to be presented to which participant among participants in the game.
The server constitutes game means and can be accessed via the network by each participant terminal operated by each participant in the game.
The server provides the game execution page to each participant's terminal.
The game means includes a simulated musical chairs game program that operates on a game execution page.
The simulated musical chairs game program includes a button arrangement module for arranging a plurality of selection buttons, which are command buttons, along a circular track, and a button rotation module for displaying the selection buttons arranged on the circular track revolving around the track on each participant terminal.
The multiple selection buttons arranged on the circular orbit have a one-to-one correspondence with the gifts recorded in the gift presentation information file, and are buttons that execute a matching module that performs a process of recording the participant ID of the participant associated with the participant terminal on which the selection button is pressed in correspondence with one gift recorded in the gift presentation information file.
Each selection button is a command button that becomes active when the button rotation module rotates each selection button for a predetermined period of time and stops, and becomes inactive after the first pressing operation is performed at any of the participant terminals.
The simulated musical chairs game program is a program that has fewer selection buttons than the number of participant terminals that can press selection buttons to cause the server to execute a corresponding module.
After any one of the selection buttons has been pressed once after the rotation of the selection buttons has stopped, each participant terminal is unable to execute the association module even if another active selection button is pressed.
In addition, in the gift presentation system of the disclosed invention, the selection button may be a button on which an image of a corresponding gift is displayed.
In addition, in the gift presentation system of the disclosed invention, the button placement module may include code for updating the placement of each selection button to correspond to gifts that have not been matched, except for gifts that have been matched by the matching module.
In addition, the gift-giving system according to the disclosed invention comprises:
The storage unit stores a participant information file, the participant information file being a file in which each participant ID that identifies each participant is recorded;
The simulated musical chairs game program includes a challenger nomination module that extracts participant IDs that are greater than the number of selection buttons from among participant IDs whose participant IDs are not recorded in the presentation gift information file, and the challenger nomination module can be configured to enable a matching module to be executed by pressing a selection button for a participant terminal associated with each extracted participant ID.

As described below, the gift presentation system of the disclosed invention takes into consideration the gift giver's selection of gifts, but also plays a simulated game of musical chairs to determine which gifts will be presented to which participants, making gift presentation an entertaining attraction.
In this case, the giver only needs to purchase the gift in advance and execute the gift presentation registration program; there is no need to carry the purchased gift to the venue, so preparation is extremely simple and does not require much time or effort.
Furthermore, if the selection button is a button that displays an image of the corresponding gift, the player will press the selection button because he or she wants that gift, which increases the fun of the game.
Furthermore, if the button placement module includes code for updating the placement of each selection button in correspondence with gifts that have not been matched, excluding gifts that have been matched by the matching module, the simulated musical chairs game can be played multiple times with gifts that have not been acquired, so there is no need to place a large number of selection buttons at one time, which is particularly suitable when a large number of gifts are to be presented.
In addition, the simulated musical chairs game program includes a challenger nomination module that extracts participant IDs that are greater than the number of selection buttons from among participant IDs whose participant IDs are not recorded in the presentation gift information file, and the challenger nomination module is a module that enables the matching module to be executed by pressing the selection button for the participant terminal related to each extracted participant ID.According to this configuration, challengers are selected from a large number of participants to challenge the simulated musical chairs game, which is particularly suitable when there are a large number of participants.

1 is a schematic diagram of a gift presentation system according to an embodiment; FIG. 2 is a schematic diagram showing the structure of a gift sales information file. 1 is a schematic diagram showing the structure of a gift information master file. FIG. 2 is a schematic diagram showing the structure of a gift presentation information file. FIG. 13 is a schematic diagram showing an example of each page for selling simulated game gifts. 1 is a flow chart outlining a gift presentation registration program. 13 is a flowchart showing an outline of a game preparation program. FIG. 11 is a schematic diagram showing an example of the structure of a participant information file. FIG. 13 is a schematic diagram showing an example of a giver contact email executed by a giver contact module. 3A to 3C are schematic diagrams showing examples of pages for participant registration. 13 is a flowchart showing an outline of a participant registration program. FIG. 13 is a schematic diagram showing an example of a gift giver game playing page. FIG. 13 is a schematic diagram showing an example of a gift giver game playing page. 11 is a flowchart showing an outline of a button arrangement module. 13 is a flow chart outlining the challenger nomination module. 13 is a flow chart outlining the association module; FIG. 13 is a schematic diagram of a participant game execution page. FIG. 13 is a schematic diagram illustrating an example of a gift receipt page. 13 is a diagram showing an example of a gift receipt page when a special bonus is won in a lottery.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A preferred embodiment of the present invention will now be described with reference to the accompanying drawings. FIG 1 is a schematic diagram of a gift presentation system according to an embodiment of the present invention.
The gift presentation system of the embodiment is a system used when a giver presents gifts to multiple recipients. As described below, the gift presentation system of the embodiment plays a game simulating musical chairs (hereinafter referred to as a simulated musical chairs game) to determine gifts to be presented to each recipient. It is assumed that the simulated musical chairs game is played at an event such as a party or a banquet. Hereinafter, an event where the simulated musical chairs game is played is referred to as a simulated game event. Moreover, gifts presented to each recipient in this manner through the simulated musical chairs game are referred to as simulated game gifts.

As shown in Figure 1, the gift presentation system of the embodiment includes a server 1 that can be accessed via a network by a gift giver terminal 3, which is a terminal operated by the gift giver, and participant terminals 4, which are terminals operated by each participant in the simulated musical chairs game, and a memory unit 2.
In this embodiment, the network is the Internet 100, and therefore the server 1 is a web server. Gifts are sold to gift givers by gift businesses and presented to gift recipients. The server 1 is operated and managed by the gift business, and will be referred to as the gift server 1 below. The gift server 1 does not need to be a single server, and the gift server 1 may be made up of multiple server computers.

The memory unit 2 is a storage such as a hard disk provided in the gift server 1, but may be provided in a server other than the gift server 1, such as a storage server. The memory unit 2 does not need to be only one, and multiple storages may be used as the memory unit 2, and may be provided in different locations.
In this embodiment, each participant terminal 4 is a smartphone. The giver terminal 3 may be a smartphone or a PC, but in the following example, it is a smartphone.

In the gift presentation system of the embodiment, the gift to be presented to each recipient is determined in the simulated game event, so the giver is asked to select the gift to be presented (presentation gift) in advance before the simulated game event. The selected present gift is then sold to the giver by the gift business. As files for these purposes, as shown in FIG. 1, the memory unit 2 stores a gift sales information file 21, a gift information master file 22, and a presented gift information file 23.

Figure 2 is a schematic diagram showing the structure of the gift sales information file 21. The gift sales information file 21 is a database file that records information on gift sales that are conducted in advance for each simulated game event. As shown in Figure 2, the gift sales information file 21 records many records consisting of fields such as "sales ID", "membership ID", "gifter name", "number of participants", "number of gifts", "participant registration ID", "participant registration password", "sales date", and "event name".

"Sales ID" is a field in which information identifying each sale is input. The sales ID also serves as an ID identifying each simulated game event.
In this embodiment, gifts are sold to givers after they have registered as members, and a member information file (not shown) is stored in the memory unit 2. The member information file is a database file that records the personal information of each member, and is uniquely identified by a member ID. "Member ID" in the gift sales information file 21 is a field that records the member ID of the giver to whom the gift is sold. "Giver name" is a field into which the name of the member recorded in the member information file (or the name in the case of an organization or corporation) is transcribed.

The "Number of participants" is a field in which the number of participants participating in the simulated game event is entered. Participants are recipients of gifts, but there may be cases where the number of gifts is less than the number of participants, in which case there will be participants who are not recipients (participants who cannot receive gifts).
The "number of gifts" is a field in which the number of gifts to be given in the simulated game event is entered. This number is equal to or less than the number of participants.
"Sale Date" is a field in which the date on which a gift was sold at one simulated game event is entered.
"Event name" is a field in which the name of the simulated game event is recorded. For example, a name such as "XX wedding reception after-party" is recorded.

Figure 3 is a schematic diagram showing the structure of the gift information master file 22. The gift information master file 22 is a database file that records information on products or services that can be selected as gifts to be presented, and is a file that records information on various products or services that gift businesses can purchase and sell. In the case of services, it is often the case that something like a voucher for the service is provided to the recipient.

As shown in Figure 3, the gift information master file 22 contains many records consisting of fields such as "gift ID", "gift name", "sales price", "genre ID", "genre name", "supplier ID", and "image file name". The gift ID is information that identifies each gift, and the sales price is the price at which the gift is sold to the giver. The genre ID is information that identifies the genre of the gift. The supplier ID is information that identifies the business that supplies the gift. The image file name is the file name of an image file that shows the contents of the gift in an image, and is recorded including the path name if necessary.

4 is a schematic diagram showing the structure of the gift presentation information file 23. One gift presentation information file 23 is created for one sales ID and stored in the storage unit 2. For example, the file can be identified by the sales ID by using the sales ID as the file name.
As shown in FIG. 4, the gift presentation information file 23 is a database file that records records each of which has fields such as "registration ID", "gift ID", "gift name", "image file name", and "recipient ID". The number of records in the gift presentation information file 23 is the same as the value of "number of gifts" in the gift sales information file 21. The "registration ID" is an ID that uniquely identifies each record in one gift presentation information file 23. The gift ID is not unique identification information because the same gift may be selected multiple times as a gift presentation. Therefore, a registration ID is generated and recorded. The registration ID is, for example, identification information obtained by adding a subnumber to the sales ID. The "recipient ID" is a field in which the participant ID of the recipient determined by the pseudo musical chairs game is recorded.

On the other hand, the gift server 1 hosts a page for selecting a gift to be presented (hereinafter referred to as the selection page) on the gift giver terminal 3. That is, the storage unit 2 stores an HTML file for the selection page, and each script for the selection page is implemented for the selection page.
In this embodiment, a gift business sells several different types of gifts on a site (gift site) provided by the gift server 1, one of which is the simulated game gift in this embodiment.

Figure 5 is a schematic diagram showing an example of each page for selling simulated game gifts. A gift business provides a gift site on gift server 1, and Figure 5 (1) shows an example of the top page. The gift site is a site that requires member registration to be used, and the giver registers as a member in advance. Once registered as a member, a member ID and password are issued. Pressing the login button on the top page displays the login page, and the giver can log in by entering their member ID and password.

As shown in FIG. 5(1), the top page introduces several different types of gifts provided by a gift provider, one of which is a simulated game gift.
The top page has a button labeled "Simulated Musical Chairs Game Gift" (hereinafter, "Game Gift Button") 51. The game gift button 51 is linked to a sales page for the simulated game gift (hereinafter, "Game Gift Sales Page"). Figure 5 (2) shows an example of the game gift sales page.

As shown in Figure 5 (2), the game gift sales page has a participant number input field 52, a gift number input field 53, an event name input field 54, a price range selection field 55, a genre selection field 56, and a gift selection page display button 57.
The number of participants input field 52 is a field for inputting the number of participants in the simulated game event. The number of gifts input field 53 is a field for inputting the number of gifts to be presented, and is a field for inputting a number equal to or less than the number of participants. An error occurs if a number greater than the number of participants is input.

The event name input field 54 is a field for inputting the name of the simulated game event. For example, a name such as "XX wedding reception after-party" is input.
The price range selection field 55 is a field for selecting the price range of the gift to be presented. In this example, the price range selection field 55 is a check box that allows multiple selections, for example, 500 yen or less, 500 to 1000 yen, 1000 to 3000 yen, 3000 to 5000 yen, 5000 to 7000 yen, 7000 to 10000 yen, and 10000 yen or more. In addition, no designation can be selected.
The category selection field 56 is a field for inputting the category of the gift to be presented. In this example, the category selection field 56 is in the form of check boxes, and it is possible to select multiple categories or all categories.

The gift presentation selection page is linked to the gift presentation selection page display button 57. A script is embedded in the gift presentation selection page to display the gift presentation selection page according to the inputs in the price range selection field 55 and the category selection field 56. An example of the gift presentation selection page display is shown in Fig. 5 (3).
As shown in Fig. 5 (3), the gift selection page is a page that displays a list of gifts that can be selected as gifts to be presented. Each frame that displays a gift displays the name of the gift, an image showing the contents of the gift, and the sales price. The script embedded in the gift selection page searches the gift information master file 22 according to the price range selected in the price range selection field 55 and the genre selected in the genre selection field 56, and the sales price is entered into the price range selected in the price range selection field 55, and the gift name, image file, and sales price of the gift that corresponds to the genre selected in the genre selection field 56 are obtained. Then, the script is coded to incorporate the image and display it in each frame as shown in Fig. 5 (3).

As shown in Fig. 5(3), each frame displaying a gift has a quantity input field 58. Also, at the bottom of the gift selection page, a gift registration button is provided (not shown in Fig. 5(3)). When the gift selection page is displayed down to the bottom, the gift registration button is displayed.
The gift presentation registration program 11 is implemented in the gift server 1, and the gift presentation registration button is an execution button for the gift presentation registration program 11. FIG.

The gift presentation registration program 11 sums up the numbers in the quantity input fields 58 in each frame that displays a gift, and judges whether the total number matches the number in the gift number input field. If they do not match, an error message is displayed on the gift giver terminal 3 and the program ends.
If the total of the numerical input fields matches the numerical value in the gift quantity input field, the presentation gift registration program 11 stores the gift IDs and the quantities of the gifts for which a numerical value of 1 or more has been input in the quantity input field 58 in an array variable (2 columns). Then, the gift information master file 22 is searched for each gift ID to obtain the value of "sales amount". Next, the total sales amount is calculated by multiplying the sales amount for each gift ID by the quantity of the gift and totaling the value for all gift IDs. The presentation gift registration program 11 includes a payment module, and executes the payment module using the calculated total sales amount as an argument. The payment module is the same as that used in normal online shopping, but in this example, only credit cards or prepaid payments can be used.

When a return value indicating successful payment completion is returned from the payment module, the gift presentation registration program 11 generates a new sales ID and adds a new record to the gift sales information file 21. It then records the generated sales ID, the member ID held at the time of login, and the sales amount, which is the payment amount. It also records the number of gifts, which is the total of the numbers entered in the quantity input field 58, in "number of gifts," and records the number entered in the number of participants input field 52 in "number of participants." It also records the event name entered in the event name input field in "event name."

Next, the gift presentation registration program 11 creates a new gift presentation information file 23 by using the sales ID as the file name, and adds as many records as there are gifts. It then automatically generates a registration ID and records it in each record. It then records each gift ID in each record, searches the gift information master file 22 for each gift ID, and records the gift name and image file name.

As shown in FIG. 1, the gift server 11 is equipped with a game preparation program 12. After creating the gift presentation information file 23 and recording each piece of information as described above, the gift presentation registration program 11 executes the game preparation program 12 as a subroutine and then terminates. FIG. 7 is a flow chart showing an outline of the game preparation program 12.

The game preparation program 12 is a program that performs processing for preparing for playing the simulated musical chairs game, such as providing necessary information to the gift giver. As shown in Fig. 7, the game preparation program 12 first generates a participant registration ID and a participant registration password. The gift sales information file 21 is searched for the sales ID, and these are recorded in the "participant registration ID" and "participant registration password" of the corresponding record, respectively.
Next, the game preparation program 12 creates a new participant information file 24 and stores it in the storage unit 2. Fig. 8 is a schematic diagram showing an example of the structure of the participant information file 24. The participant information file 24 is a database file created for implementing a lottery, and as shown in Fig. 8, is a file in which records each of which is made up of fields such as "participant ID", "name", "nickname", "email address", "acquired gift", etc., are recorded for the number of participants. The participant information file 24 is created for each sales ID, and the file name is made identifiable by the sales ID, for example, by using the sales ID.

"Participant ID" is a field in which information that uniquely identifies each record in the participant information file 24 is recorded, and is, for example, information in which a sub-number for the participant is added to the sales ID. The participant name and email address are fields in which values are recorded when a participant uses the participant terminal 4 to register as a participant or to request the delivery of an acquired gift.
"Acquired gift" is a field in which the gift ID of a gift is recorded when the right to receive the gift is acquired through the pseudo musical chairs game.
The game preparation program 12 next includes a gift giver contact module for the gift giver to send a report of the completion of the gift purchase and information for playing the game. After creating the participant information file 24, the game preparation program 12 executes the gift giver contact module and ends.

The gift sender may be contacted by email from the gift server 1 or by mailing a printed copy of the message, but the following explanation will use email transmission as an example.
9 is a schematic diagram showing an example of a sender contact email executed by the sender contact module. As shown in FIG. 9, the sender contact email includes a report that the purchase of the simulated game gift has been successfully completed and a text explaining the simulated musical chairs game.

The explanation of the simulated musical chairs game includes the fact that the giver and each participant need to download an app (hereinafter referred to as the musical chairs game app) in advance, and that each participant needs to register as a participant. The giver contact email includes a download URL (hyperlink, hereinafter referred to as the giver app download link) 61 for the musical chairs game app for the giver, and a URL (hyperlink, hereinafter referred to as the participant registration link) 62 for participant registration. The email also includes an explanation that the participant registration link 62 should be forwarded to each participant via email, SNS, or the like. Although not shown in FIG. 9, the email also includes the URL of the gift site, a participant registration ID, and a participant registration password in consideration of the case where each participant manually logs in. The participant registration ID and participant registration password are recorded in the gift sales information file 21.

Next, the installation of the musical chairs game app and participant registration, which are carried out as part of the game preparation, will be described. FIG. 10 is a schematic diagram showing an example of each page for participant registration. FIG. 10(1) shows the participant registration top page. The participant registration top page is displayed by logging in to the participant terminal 4 with the participant registration ID and participant registration password. The giver contact email shown in FIG. 7 is forwarded to the participant terminal 4, and the participant can log in by tapping the participant registration link 62 on the participant terminal 4, or by accessing the URL of the gift site and entering the ID and password, and the participant registration top page of FIG. 10(1) will be displayed.

The name of the simulated game event is displayed on the participant registration top page for confirmation. A script is embedded in this section which searches the gift sales information file 21 using the participant registration ID, and reads and displays the value of the "Event Name" field of the corresponding record. The participant top page also states that participant registration and the download of a musical chairs game app are required to participate in the simulated musical chairs game held at the simulated game event, and provides an input page display button 63 that reads "Register participant."

The input page display program embedded in the input page display button 63 determines whether the musical chairs game app is installed on the accessed participant terminal 4, and if it is not installed, displays a message on the participant terminal 4 requesting the participant to download and install the musical chairs game app. Then, a button is displayed to allow the participant to select whether or not to download the app. If download is not selected, the process ends, and if it is selected, the download module is executed.

When the musical chairs game app is installed and a return value indicating normal completion is returned from the download module, the input page display program displays the participant registration input page shown in FIG. 10 (2) on the participant terminal 4. As shown in FIG. 10 (2), the participant registration input page has a name input field 64, a nickname input field 65, and a registration button 66. The gift server 1 has the participant registration program 13 implemented, and the send button on the confirmation page linked to the registration button 66 is an execution button for the participant registration program 13.

Figure 11 is a flowchart showing an overview of the participant registration program 13. The participant registration program 13 searches the gift sales information file 21 with the participant registration ID retained at the time of login, and obtains the sales ID and number of participants from the corresponding record. It then opens the participant information file 24 created corresponding to that sales ID, and determines whether a number of records matching the number of participants have already been recorded. If they have already been recorded, it outputs an error message indicating that participant registration has ended and terminates. If the number of records is less than the number of participants, the participant registration program 13 searches the participant information file 24 with the nickname entered in the nickname input field 65, and determines whether the same nickname exists. If it does, it displays a message requesting the user to choose a different nickname and terminates.

If the number of records is less than the number of participants and there is no identical nickname, the participant registration program 13 adds a new record to the participant information file 24. Then, a participant ID is generated and recorded in "Participant ID", the name entered in the name input field 63 of the participant registration input page is recorded in "Name", and the nickname entered in the nickname input field 64 is recorded in "Nickname". The sales ID, event name, registered participant ID and nickname are then sent to the participant and stored in the participant terminal 4 as internal variables of the musical chairs game app 41. Then, as shown in FIG. 10 (3), a message indicating that participant registration has been completed is displayed on the participant terminal 4 and the program is terminated. Note that, as shown in FIG. 10 (3), a message is displayed along with the completion message requesting that the participant launch the app on the day of the event and tap the participation button if they wish to participate in the game.

Next, the configuration for playing the simulated musical chairs game thus prepared will be described below. The simulated musical chairs game is played to determine which participant each gift recorded in the gift presentation information file 23 should be presented to. That is, the gift presentation system of the embodiment includes a game means for determining which participant each gift recorded in the gift presentation information file 23 should be presented to by playing the simulated musical chairs game. In this embodiment, the game means is composed of the gift server 1, the simulated musical chairs game program 14 implemented in the gift server 1, the gift giver terminal 3 and each participant terminal 4 on which musical chairs game apps 31 and 41 are installed, etc.

The game means is a means for displaying a game playing page on the gift giver terminal 3 and each participant terminal 4. The game means includes a simulated musical chairs game program 14 executed on the game playing page. The simulated musical chairs game program 14 includes a program for displaying the game playing page, and scripts and program modules implemented on the game playing page.
The game play page is called up and displayed from the gift giver terminal 3 and each participant terminal 4. In either case, the sales ID is acquired and stored in a session variable. The instance of the game play page displayed on each participant terminal 4 is slightly different from the instance displayed on the gift giver terminal 3. Hereinafter, the game play page displayed on the gift giver terminal 3 will be referred to as the gift giver game play page, and the game play page displayed on each participant terminal 4 will be referred to as the participant game play page.

12 and 13 are schematic diagrams showing an example of a gift giver game page. As the game progresses, the display state changes as shown in FIG. 12(1)→(2)→(3)→FIG. 13(1)→(2).
The gift sender app download link 61 shown in Fig. 9 includes a member ID and a seller ID, and when the gift sender taps the link to download and install the musical chairs game app 31, the member ID and the seller ID are stored as internal variables of the musical chairs game app. A start-up icon for the musical chairs game app 31, which is automatically created on the gift sender terminal 3, is embedded with a code for executing a game play page display program on the gift server 1 using the member ID and the seller ID as arguments. Therefore, with the member ID and the seller ID stored in the session variables, the gift sender game play page shown in Fig. 12 is displayed on the gift sender terminal 3.

As shown in Fig. 12, the giver's game page displays the name of the event for confirmation. This information is obtained by searching the gift sales information file 21 using the sales ID and obtaining the corresponding record.
The giver game execution page is provided with a total participant number display field 71, a remaining gift number display field 72, a number of players who have not yet received a gift display field 73, a challenger display field 74, etc. Also, a standby button 75, a start button 76, and a reset button 77 are provided as command buttons.

The total number of participants display field 71 is a field that displays the total number of participants participating in the pseudo musical chairs game. In this field, the gift sales information file 21 is searched for using the sales ID and the value of the "number of participants" of the record is displayed. The remaining number of gifts display field 72 is a field that displays the number of records (number of gifts) that are not associated with a participant ID in the presented gift information file 23, and displays the number of records that do not have a value recorded in the "recipient ID".
The number of non-acquirers display field 73 is a field in which the number of participants who have not acquired the right to receive a gift is displayed. When the game application is launched, the number in the number of non-acquirers display field 73 matches the number in the total number of participants display field 71. The challenger display field 74 is a field in which participants who will challenge the game in each musical chairs game are displayed.

The standby button 75 is an execution button for the button placement module and the challenger nomination module. FIG. 14 is a flowchart showing an outline of the button placement module. The button placement module is a module for implementing a state simulating a musical chairs game on the game implementation page, and for arranging a number of selection buttons 78, which are command buttons, in a circumferential arrangement. The selection buttons 78 are buttons that are pressed by challengers (participants nominated as challengers) to acquire gifts. In this embodiment, the selection buttons 78 are iconized buttons that display the names and images of the gifts that can be acquired. FIG. 12 (2) shows an example of the selection buttons 78 arranged by the button placement module.

In the musical chairs game app 31 for the giver, an initial value for the number of selection buttons 78 to be placed is set (hereinafter, the placement number setting value). If the number displayed in the non-acquirer number display field 73 is equal to or less than the placement number setting value, the button placement module updates the placement number to one less than the number of non-acquirers. Note that if the number in the non-acquirer number display field 73 is 1, the pseudo musical chairs game is over, and the button placement module ends without making any placement.

The button placement module opens the gift presentation information file 23 corresponding to the sales ID, and determines whether a value for "gift recipient ID" is recorded for the first record. If not, it obtains the value of "gift ID" for that record and stores it in an array variable. Hereinafter, this variable will be called the placement gift storage variable. The button placement module repeats this process in the order of record number until the number of variables in the placement gift storage variable reaches the placement number. Then, when the placement number is reached, it adds 1 to the record number of that record and stores the value in the variable. Hereinafter, this variable will be called the gift extraction start position. The initial value of the gift extraction start position is 1 (first record).

Then, the gift information master file 22 is searched for each extracted gift ID, and the gift name and gift image file name are obtained from the corresponding record.The gift name and gift image are then iconized to generate each selection button 78.At this time, the button arrangement module embeds code that executes the association module using the gift ID of the displayed gift as an argument in each selection button 78.At this time, each selection button 78 is set to an invalid state as an initial state.
The button arrangement module arranges the selection buttons 78 generated as described above in a circumferential manner as shown in Fig. 12 (2). The "circumferential" means a circle or an ellipse, and the buttons are arranged along a circumferential track that is set in advance on the page. When the number of unattained users display columns 73 is two, there is only one selection button 78, but it is arranged on the set circumferential track.

After arranging the selection buttons 78, the button arrangement module executes the challenger nomination module and ends. Fig. 15 is a flow chart showing an outline of the challenger nomination module. The challenger nomination module checks the number in the non-acquirer number display field 73, and if that number is greater than the arrangement number setting value, it adds 1 to the arrangement number setting value and stores the result as a variable as the number of challengers. If the number of non-acquirers is the arrangement number setting value, it subtracts 1 from the number of non-acquirers and sets it as the number of challengers. If the number of non-acquirers is less than the arrangement number setting value, it sets the number of non-acquirers as the number of challengers.
The challenger nomination module then opens the participant information file 24 corresponding to the sales ID, and starting from the first record, determines whether the "Acquired Gift" field is a null value. If it is a null value, it reads the "participant ID" of that record and stores it in an array variable. Then, it extracts participant IDs in order equal to the number of challengers, and stores each extracted participant ID in another array variable. Hereinafter, this variable will be referred to as the "challenging participant storage variable." The challenger nomination module adds 1 to the record number from which the last participant ID was extracted and stores the value in the variable. Hereinafter, this variable will be referred to as the challenger extraction start position. The default value of the challenger extraction start position is 1 (the first record).

Next, the challenger nomination module retrieves the nicknames of the participants associated with each extracted participant ID from the participant information file 24, and displays them in the challenger display area 74, as shown in Figure 12 (2) (7 people in this example). This completes the challenger nomination module. Note that the number of challenging participants storage variable is a global variable, and the extracted participant IDs of each challenger are retained in the currently challenging participant storage variable even after completion. Also, in the example of Figure 12 (2), the same humanoid image is drawn, but it is also possible to have each participant select an avatar in advance, which is then recorded in the participant information file 24, and the avatar is displayed together with the nickname.

The start button 76 is an execution button for the rotation module. The rotation module rotates each selection button 78 arranged in a circular shape by the button arrangement module along that circumference (along a set circular orbit). The rotation is indicated by arrows in FIG. 12 (3). The rotation is performed, for example, by setting a function to sequentially change the display position of each selection button 78 along the circular orbit at predetermined short time intervals, so that it appears to rotate to the human eye.

The musical chairs game program also includes a music playback module, and the rotation module is coded to execute the music playback module during the rotation operation. The music playback module plays a set music file from among the multiple music files stored in the storage unit 2, and allows the music file to be heard on the gift giver terminal 3 and each participant terminal 4.
The rotation module is coded to continue the rotation for a predetermined time (e.g., 5 to 15 seconds), at which point the rotation module stops playing music, switches each selection button 78 from an inactive state to an active state, and terminates the module.

16 is a flow chart showing an outline of the association module. The association module is a module that performs a process to make the gift displayed by the selection button 78 appear as if it has been acquired by the participant who pressed the selection button 78.
Specifically, each selection button 78 is embedded with a code that acquires a participant ID from a variable in the game application displaying the game execution page, and uses the participant ID and the gift ID as arguments to launch the association module. As shown in Fig. 16, the association module first determines whether the argument participant ID is in the challenging participant storage variable, and if not, ends the module. If it is, the participant ID is deleted from the challenging participant storage variable, and the challenging participant storage variable is updated.

Next, it is determined whether the argument gift ID is in the placed gift storage variable, and if not, the module is terminated. If it is, the gift presentation information file 23 is searched for that gift ID, and the participant ID is recorded in the "gift recipient ID" of the corresponding record. Then, that gift ID is deleted from the placed gift storage variable, and the placed gift storage variable is updated. Furthermore, a gift acquisition display module is executed as a subroutine.

The gift acquisition display module is a module that allows the challenger to see which gifts he or she has acquired. FIG. 13 (1) shows an example of the display result by the gift acquisition display module. As shown in FIG. 13 (1), the gift acquisition display module is a module that displays the gift name and image of the acquired gift in the challenger display column 74. In this example, the selection button 78 for the gift is hidden and the gift is displayed in the challenger display column 74, giving the impression that the gift has been moved to the challenger display column 74.

As can be seen from the above explanation, when multiple participants (challengers) press the same selection button 78 on their respective participant terminals 4, the participant who pressed it first will be in the state of having acquired the gift, and the participant ID of that participant will be recorded in the "recipient ID" of the presented gift information file 23. In addition, the gift name and image of the gift will be displayed in the challenger display column 74 displaying that participant. For participants who pressed it later, the gift ID has been deleted from the placed gift storage variable, so the module simply ends. For these participants, the gift acquisition display module is coded to display something like "Too bad" in the part of the challenger display column 74 displaying that participant, as shown in FIG. 13 (1).

Furthermore, when the selection button 78 is pressed once, the participant ID of all participants is deleted from the challenging participant storage variable, so even if the selection button 78 is pressed again, the module ends and nothing happens. This is the same when a different selection button 78 is pressed. If a certain selection button 78 is not pressed on any of the participant terminals 4, that selection button 78 remains on the orbit and indicates that it is not selected (not acquired); however, even if a participant who has pressed the selection button 78 once presses it again, the gift cannot be acquired because it has been deleted from the challenging participant storage variable.

The reset button 77 on the gift giver game page is a button in which a reset module that returns the game page to its initial state is embedded. FIG. 13 (2) shows the state in which the reset module has been executed. The reset module erases the selection buttons 78 for gifts that have not been acquired, if any remain. It also erases all display in the challenging participant display column. The reset module then updates the display values in the remaining gift number display column 72 and the number of unacquired gift recipients display column 73. For the remaining gift number, the number of records in the gift presentation information file 23 where the "gift recipient ID" is a null value is counted, and the display is updated. For the number of unacquired gift recipients, the number of records in the participant information file 24 where the "acquired gift" value is a null value is counted, and the display is updated. In addition, the extracted gift storage variable and the challenger participant storage variable are released and become null values, but the gift extraction start position and the challenger extraction start position are maintained.

Figure 17 is a schematic diagram of the participant game execution page. The participant game execution page is almost the same as the giver game execution page, but does not have a standby button, a start button, or a reset button. In addition, the participant game execution page has a gift reception button 80. The gift reception button 80 is a button for the participant to receive the gift that he or she has acquired, and is linked to the gift reception page.

Figure 18 is a schematic diagram showing an example of a gift receipt page. As shown in Figure 18, the gift receipt page displays the event name, the participant's nickname, and the gift name of the gift acquired. The module that displays the gift receipt page searches the gift sales information file 21 using the sales ID to acquire this information, searches the participant information file 24 using the participant ID to acquire the gift ID listed in the "acquired gift" field of the relevant record, and acquires the gift name from the gift information master file 22 and displays it as shown in Figure 17.

As shown in FIG. 18, the gift receiving page has a name input field 81, an address input field 82, a phone number input field 83, an email address input field 84, and an OK button 85. The OK button 85 is linked to a confirmation page, and the send button on the confirmation page is an execution button for the gift sending program (not shown) on the gift server 1. The gift sending program searches the participant information file 24 by the participant ID and checks the value of "gift sent or not" for the corresponding record. If this value is true, the gift has been sent, so the program displays a message to that effect on the participant terminal 4 and terminates. If it is false, the gift sending program records the gift ID and each piece of information entered on the gift receiving page in the gift sending information file (not shown) stored in the memory unit 2, so that the gift is sent to the recipient. The gift sending program then records a true value in "gift sent or not" for the record of the participant ID in the participant information file 24.

The operation of the gift presentation system of such an embodiment is generally described below.
For example, suppose that the giver is a bride and groom who are the hosts of the after-party of the wedding reception. The bride and groom find a simulated musical chairs game gift on a gift site they are browsing to present gifts, and decide to purchase it, thinking that it would be a good attraction for the after-party of the wedding reception. The giver operates the giver terminal 3 and presses (clicks or taps) the game gift button 51 on the top page of the gift site, displaying the game gift sales page of FIG. 5(2).

The giver inputs the number of participants in the participant number field 52, and the number of gifts in the gift number input field 53. The giver also inputs the event name in text in the event name input field 56, selects a price range in the price range selection field 56, and selects a gift genre in the genre selection field 55. Then, the giver presses a gift selection page display button 57.
As a result, a gift presentation selection page as shown in Fig. 5 (3) is displayed on the gift giver terminal 3. The gift giver inputs a number equal to or greater than 1 into the quantity input field 58 in the frame displaying the gift he or she wishes to give, so that the total of the numbers input into each quantity input field 58 equals the number input into the gift number input field 53. Then, the gift presentation registration button (not shown) is pressed. As a result, the gift presentation registration program 11 is executed.

The gift presentation registration program 11 calculates the total sales amount by adding up the sales amounts of gifts for which a number equal to or greater than 1 has been entered in the quantity input field 58, and executes the payment module using the total sales amount as an argument. The giver then makes payment by following the page displayed by the payment module. When payment is successfully completed, the gift presentation registration program 11 generates a new sales ID and adds and records a new record in the gift sales information file 21. It then records the member ID, sales amount, number of gifts, number of participants, and event name.

Next, the presented gift registration program 11 creates a new presented gift information file 23, adds records for the number of gifts, and records the registration ID, gift ID, gift name, and image file name in each record.
Next, the gift presentation registration program 11 executes the game preparation program 12 as a subroutine. The game preparation program 12 generates a participant registration ID and a participant registration password, and records them in the record of the sales ID. Then, a new participant information file 24 is created, and records are added for the number of participants. Then, participant IDs for the number of participants are generated, and are recorded in each record.
Furthermore, the game preparation program 12 executes a sender contact module, creates a sender contact email as shown in FIG.

The giver who has received the giver contact email clicks on the giver app download link 61 included therein, downloads the musical chairs game app, and installs it on the giver terminal 3. The giver also sends the participant registration link 62 included in the giver contact email to each participant of the after-party via email, SNS, etc. Each participant receives this on their participant terminal 4 and clicks the participant registration link 62 included therein. If the musical chairs game app is not installed, they download and install it. Then, on the displayed participant registration input page, they enter their name and nickname, press the registration button 66, and press the send button on the confirmation page. This executes the participant registration program 13, which adds a new record to the participant information file 24 and records the name and nickname. This operation is performed by each participant, and participant information is recorded in the participant information file 24 in records equal to the number of participants.

In this way, after the purchase of the gift, preparation for playing the game, and participant registration are completed, the day of the simulated game event arrives. The giver brings the giver terminal 3 to the after-party venue, and when it is time for the attraction, launches the musical chairs game app 31 on the giver terminal 3. This causes a file for the giver game play page to be sent from the gift server 1, and the giver game play page is displayed on the giver terminal 3. Each participant has also brought a participant terminal 4 with them, and the giver (or the facilitator of the after-party) requests each participant to start the musical chairs game app 41 to begin the simulated musical chairs game. In response, each participant launches the musical chairs game app 41 on their participant terminal 4. This causes the participant game play page to be displayed on each participant terminal 4.

After declaring the start of the game, the giver presses the standby button 75. This causes a specified number of selection buttons 78 (for example, six) to be displayed in the center of the game execution page. At the same time, the challengers are determined and their nicknames are displayed in the challenging participant display field 74. In this case, since this is the first round of the game, the participants recorded in the first through seventh records in the participant information file 24 are extracted and displayed in the challenging participant display field 74.
In this state, the giver presses the start button 76. This causes each selection button 78 to start rotating, and the set music file is played, playing music on the giver terminal 3 and each participant terminal 4. After a predetermined time, each selection button 78 stops, and the music playback also stops. At the same time, each selection button 78 is changed to active.

The participant in the middle of the challenge immediately presses the desired selection button 78 (the selection button 78 of the gift that the participant is aiming for). This executes the matching module. At this time, if the participant is the only participant to press that selection button 78, or is the participant who pressed it first, the matching module records the participant ID of that participant in the "recipient ID" of the gift presentation information file 23, and records the gift ID of that gift in the participant's record in the participant information file 24. The result display module then displays the gift that was acquired in the challenging participant display field 74. If another participant has pressed the same selection button 78 and the participant presses it later than the other participant, no recording is made in the gift presentation information file 23 or the participant information file 24. In this case, "Too bad" is displayed in the part of the challenging participant display field 74 that displays that participant.

Thereafter, the giver presses the reset button 77 on the giver terminal 3. This erases any selection buttons 78 that remain unused because no one pressed them. In addition, the display in the challenging participant display field 74 is also erased.
The giver then declares that he or she wishes to start the second round of the game, and presses the reset button 77 again. This causes the button arrangement module to be executed again. The button arrangement module determines whether the "gift recipient ID" is a null value from the record at the gift extraction start position, and if it is a null value, stores it in the arranged gift storage variable, and repeats this process until the arrangement number is reached. If the last record number is reached before the arrangement number is reached, the process returns to the first record (record number 1) and repeats. When the record number at the gift extraction start position is reached, the module ends even if the arrangement number has not been reached.

The challenger nomination module also operates, determining whether the "acquired gift" is a null value from the record at the start position of challenger extraction in the participant information file 24, and if it is a null value, storing it in the challenging participant storage variable, and repeating this process until the number of challengers (number of placements + 1) is reached. If the last record number is reached before the number of challengers is reached, it returns to the first record (record number 1) and repeats. When the record number at the start position of challenger extraction is reached, the module ends even if the number of challengers has not been reached.

After that, the start button 76 is pressed, the rotation module and the music playback module are operated, and after a predetermined time, they are stopped. At that timing, each challenger presses an arbitrary selection button 78, and the first challenger wins a gift.
This process is repeated, and when the number of gifts displayed in the remaining gift number display field 72 reaches zero, the pseudo musical chairs game ends. After that, each participant who has received a gift presses the gift reception button 80 to display the gift reception page on the participant terminal 4, and enters each piece of information to have the gift shipped.

According to the gift presentation system of this embodiment, while taking into consideration the gift giver's selection, a simulated game of musical chairs is played to determine which gift will be presented to which participant, making gift presentation an entertaining attraction.
In this case, the giver only needs to purchase the gift in advance and execute the gift presentation registration program; there is no need to carry the purchased gift to the venue, so preparation is extremely simple and does not require much time or effort.

In addition, since the selection button 78 is a button that displays an image of the corresponding gift, participants who want that gift will concentrate on the selection button 78 and try to press it the moment the rotation stops, which increases the fun of the game.
Furthermore, since the button arrangement module updates the arrangement of each selection button 78 in accordance with gifts that have not been associated with each other except for gifts that have been associated with each other by the association module, the simulated musical chairs game can be played multiple times for gifts that have not been acquired. This eliminates the need to arrange a large number of selection buttons 78 at one time, which is particularly suitable when a large number of gifts are to be presented.

The simulated musical chairs game program 14 also includes a challenger nomination module that extracts a greater number of participant IDs than the number of selection buttons 78 from among the participant IDs whose participant IDs are not recorded in the gift presentation information file 23, and the challenger nomination module enables the selection button 78 to be pressed for the participant terminal 4 associated with each extracted participant ID to execute the matching module, so that challengers are selected from among many participants to challenge the simulated musical chairs game. Therefore, even when there are many participants, there is no need to increase the number of selection buttons 78, which is particularly advantageous in this respect. If the challenger nomination module is not implemented, all participants will be challenged at once, but in this case, as the number of participants increases, the number of selection buttons 78 must be increased accordingly, which can cause problems such as difficulty in page layout or the selection buttons 78 becoming small and difficult to press. The configuration in which the challenger nomination module is implemented is advantageous in that such problems do not occur.

In the above embodiment, a configuration may be adopted in which a special bonus is awarded by lottery for gifts won through the pseudo musical chairs game. This bonus is awarded by the gift seller (gift business operator) rather than the giver, and may be some kind of product or service, or points (discounts) that can be used on a gift site or for other shopping.

For example, the lottery for the special privilege involves determining that one of the gifts (one or several) recorded in the gift information master file 22 is the winning gift, and a field is provided in the gift information master file 22 for recording information on whether the gift is the winning gift. The winning gift is changed periodically, such as once a day or once a week. To do this, a management terminal capable of rewriting the contents of the gift information master file 22 is connected to the gift server 1. The gift that is the winning gift is not known to the giver, let alone to each participant, but is recorded in the gift information file 22.
In this case, if the giver happens to select that gift as the presented gift, any participant who wins that gift in the simulated musical chairs game will be awarded a special privilege.

In terms of the software configuration, when the gift receipt page display program 16 displays the gift receipt page on the participant terminal 4, it refers to the gift information master file 22 to determine whether the selected gift ID is a winning gift ID, and if so, displays a message to that effect to inform the participant. An example of this is shown in FIG.
19 is a diagram showing an example of a gift receipt page when a special gift is won in a lottery. In this example, in addition to a display indicating that a special gift has been won, a button 86 for viewing details is provided. The button 86 for viewing details is linked to an explanatory page that displays the contents of the special gift and how to receive it. If the special gift is a voucher for some product or service, it will be sent together with the gift in the pseudo musical chairs game.

1 Gift Server 1
11 Gift presentation registration program 12 Game preparation program 13 Participant registration program 14 Simulated musical chairs game program 2 Storage unit 21 Gift sales information file 22 Gift information master file 23 Gift presentation information file 24 Participant information file 3 Gifter terminal 31 Musical chairs game application 4 Participant terminal 41 Musical chairs game application 78 Selection button

Claims (4)

A gift-giving system used when a giver gives gifts to multiple recipients, comprising:
a server that can be accessed via a network by a sender terminal that is a terminal operated by the sender;
A memory unit,
The storage unit stores a gift information master file and a gift presentation information file.
The gift information master file is a file that records information on each gift that can be given.
The gift information file is a file that records information on gifts selected by the giver as gifts to be given from among the gifts recorded in the gift information master file;
The server is capable of providing a gift selection page to the gift sender terminal, and a gift registration program is implemented in the server;
The gift selection page is a page where the user can input whether or not to select each gift recorded in the gift information master file as a gift to be presented, and is a page where the gift registration program can be executed;
The gift registration program is a program that records each gift selected on the gift selection page in the gift information file.
A game means is provided for playing a game when presenting each gift recorded in the presented gift information file to a recipient, the game means being a means for determining which gift is to be presented to which participant among participants in the game;
the server is accessible via the network from each participant terminal operated by each participant in the game, and constitutes a game means;
The server provides the game execution page to each participant's terminal.
the game means includes a simulated musical chairs game program that runs on a game execution page;
The simulated musical chairs game program includes a button arrangement module that arranges a plurality of selection buttons, which are command buttons, along a circular track, and a button rotation module that rotates the selection buttons arranged on the circular track on each participant terminal, the selection buttons being rotated along the circular track;
The multiple selection buttons arranged on the circular track correspond one-to-one to the gifts recorded in the gift presentation information file, and are buttons that execute a correspondence module that performs a process of recording the participant ID of the participant related to the participant terminal on which the selection button is pressed in correspondence with one gift recorded in the gift presentation information file,
Each selection button is a command button that becomes active when the button rotation module rotates each selection button for a predetermined period of time and stops rotating the selection button, and becomes inactive after the button rotation module has been pressed for the first time on any of the participant terminals;
The simulated musical chairs game program is a program that has a smaller number of selection buttons than the number of participant terminals that can execute a module associated with the server by pressing a selection button;
In the gift-presenting system, each participant terminal is characterized in that after pressing any one of the selection buttons once after the rotation of each selection button has stopped, the association module cannot be executed even if another active selection button is pressed. The gift presentation system according to claim 1, characterized in that the selection button is a button that displays an image of the corresponding gift. The gift presentation system of claim 1, characterized in that the button placement module includes code that updates the placement of each selection button to correspond to gifts that have not been matched, except for gifts that have been matched by the matching module. The storage unit stores a participant information file, the participant information file being a file in which each participant ID that identifies each participant is recorded;
The gift presentation system of claim 1, characterized in that the simulated musical chairs game program includes a challenger nomination module that extracts participant IDs that are greater than the number of selection buttons from among participant IDs whose participant IDs are not recorded in the presentation gift information file, and the challenger nomination module is a module that enables a correspondence module to be executed by pressing a selection button for each extracted participant ID associated with a participant terminal.

Images