Server, control method, and program

Abstract

Provide a server or the like that can prove on SNS that a user has purchased a voting ticket. 【Solution means】When the posting unit 102 of the server 100 receives an instruction to select and post any purchase history from the list of purchase histories of voting tickets from the first terminal 200-1 used by the first user, it determines a proof URL associated with the selected purchase history, and posts a proof message including the proof URL to the SNS that has been pre-linked and set by the first user. When there is an access to the proof URL included in the proof message from the second terminal 200-2 used by the second user, the generation unit 103 generates a proof page including the account name of the first user's SNS related to the purchase history associated with the accessed proof URL, and the purchase date and quantity of the voting ticket related to the purchase history associated with the accessed proof URL. The proof page providing unit 104 provides the proof page to the second terminal 200-2.

Description

Technical Field

[0001] The present invention relates to a server, a control method, and a program.

Background Art

[0002] Conventionally, for competitions related to public competitions and sports promotion lottery tickets, a technique for managing information on lottery tickets for predicting the results of competitions purchased by users has been known. For example, Patent Document 1 discloses a purchase information management system that provides purchase information and payment information of lottery tickets purchased by a user by inserting cash into a voting terminal at a stadium to a mobile terminal used by the user.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] On the other hand, a user may post on SNS (Social Networking Service) that they have purchased a lottery ticket. Generally, when a user purchases a lottery ticket at a stadium, the user takes a picture of the physical lottery ticket with a camera and posts the taken image, and when purchasing a lottery ticket online, the user obtains a screenshot of the purchase screen of the lottery ticket and posts the obtained screenshot. However, just the screenshot of the purchase screen may be perceived as weak proof that the user has purchased a lottery ticket by other users using SNS in some cases.

[0005] The present invention solves the above problems, and an object thereof is to provide a server, a control method, and a program capable of proving on SNS that a user has purchased a lottery ticket.

Means for Solving the Problems

[0006] The server according to the first aspect of the present invention A list providing unit that provides a list of purchase histories of lottery tickets for predicting the results of competitions purchased by a first user to a first terminal used by the first user; When receiving an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal, a proof URL associated with the purchase history related to the selection is determined, and a proof message including the proof URL is posted to an SNS that has been linked and set in advance by the first user. A posting unit; When there is an access to the proof URL included in the proof message from a second terminal used by a second user different from the first user, the account name of the first user in the SNS related to the purchase history associated with the accessed proof URL, and the purchase date and quantity of the lottery tickets related to the purchase history associated with the accessed proof URL. A generation unit that generates a proof page including at least; A proof page providing unit that provides the generated proof page to the second terminal; It is characterized by comprising.

[0007] Also, in the server according to the above aspect, When the access is within the purchasable period of the lottery ticket related to the purchase history associated with the accessed proof URL, the generation unit generates the proof page further including a link for purchasing the lottery ticket. It is characterized by this.

[0008] Also, in the server according to the above aspect, When the access is after it is determined whether or not the lottery ticket related to the purchase history associated with the accessed proof URL has won, the generation unit includes information indicating whether or not the lottery ticket has won, and when the lottery ticket has won, the refund amount or the recovery rate associated with the first user. A proof page is generated that further includes; It is characterized by this.

[0009] Also, in the server according to the above aspect, when the posting unit detects that a voting ticket related to a purchase history associated with the proof URL with the access has won, it quotes the proof message related to the proof page from the account in the SNS used by the operator of the server, and includes information indicating that the voting ticket related to the purchase history associated with the proof URL with the access has won, and the refund amount or the recovery rate associated with the first user, and posts a winning message including the above to the SNS It is characterized by the above.

[0010] Also, in the server according to the above aspect, the generation unit includes, as an image, the account name of the first user in the SNS related to the purchase history associated with the proof URL with the access, and the purchase item and quantity of the voting ticket related to the purchase history associated with the proof URL with the access, in the proof page It is characterized by the above.

[0011] Also, in the server according to the above aspect, when the proof message is posted to the SNS, the list providing unit includes, in the list, a thumbnail image including at least the purchase item and quantity of the voting ticket related to the purchase history associated with the proof URL included in the posted proof message It is characterized by the above.

[0012] Also, in the server according to the above aspect, when the list providing unit detects that a voting ticket related to the purchase history associated with the proof URL included in the proof message has won, it displays information indicating that the voting ticket has won, overlaid on the thumbnail image It is characterized by the above.

[0013] The control method according to the second aspect of the present invention is a control method executed by a server, wherein the server Provide a list of purchase histories of lottery tickets for predicting the results of competitions purchased by the first user to the first terminal used by the first user, When receiving an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal, determine a proof URL associated with the purchase history related to the selection, and post a proof message including the proof URL to a SNS that has been pre-linked and set by the first user, When there is an access to the proof URL included in the proof message from a second terminal used by a second user different from the first user, generate a proof page including at least the account name of the first user on the SNS related to the purchase history associated with the proof URL to which the access has been made, and the purchase date and quantity of the lottery tickets related to the purchase history associated with the proof URL to which the access has been made, Provide the generated proof page to the second terminal Characterized by.

[0014] The program according to the third aspect of the present invention is A computer A list providing unit that provides a list of purchase histories of lottery tickets for predicting the results of competitions purchased by the first user to the first terminal used by the first user, When receiving an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal, determine a proof URL associated with the purchase history related to the selection, and post a proof message including the proof URL to a SNS that has been pre-linked and set by the first user. A posting unit, When there is an access to the proof URL included in the proof message from a second terminal used by a second user different from the first user, generate a proof page including at least the account name of the first user on the SNS related to the purchase history associated with the proof URL to which the access has been made, and the purchase date and quantity of the lottery tickets related to the purchase history associated with the proof URL to which the access has been made. A generation unit, A proof page providing unit that provides the generated proof page to the second terminal, characterized by causing it to function as

[0015] The above program may be recorded on a non - transitory recording medium. The non - transitory recording medium can be distributed and sold independently of the computer. Here, the non - transitory recording medium refers to a tangible recording medium. The non - transitory recording medium is, for example, a compact disk, a flexible disk, a hard disk, a magneto - optical disk, a digital video disk, a magnetic tape, a semiconductor memory, etc. Also, the transitory recording medium refers to the transmission medium (propagating signal) itself. The transitory recording medium is, for example, an electrical signal, an optical signal, an electromagnetic wave, etc. Note that the temporary memory area is an area for temporarily storing data and programs, and is, for example, a volatile memory such as RAM (Random Access Memory).

Advantages of the Invention

[0016] According to the present invention, it is possible to provide a server, a control method, and a program capable of proving in an SNS that a user has purchased a voting ticket.

Brief Description of the Drawings

[0017]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Embodiments for Carrying Out the Invention

[0018] (1. Overall Configuration) As shown in FIG. 1, a server 100 according to an embodiment of the present invention is communicably connected via a computer communication network 400 such as the Internet to a plurality of terminals 200 and a database 300.

[0019] The server 100 is a device that manages the purchase history of lottery tickets for predicting the results of competitions purchased by users. For example, the server 100 provides a sales site (hereinafter referred to as "Sales Site X") that sells lottery tickets online, and in response to a request from a user of the terminal 200, refers to the information stored in the database 300 and provides information for predicting the results of competitions or executes a process of selling lottery tickets. Then, the server 100 manages the purchase history of users on "Sales Site X". In addition, the server 100 refers to the information stored in the database 300 at a predetermined cycle and detects whether the lottery tickets purchased by the user are winning.

[0020] Here, the competition is a public competition or a competition targeted by sports promotion lottery tickets, such as motorcycle racing, horse racing, boat racing, auto racing, soccer, basketball, etc. Also, lottery tickets for predicting the results of competitions are, for example, car tickets, horse tickets, boat tickets, and sports promotion lottery tickets.

[0021] The terminal 200 is a device used by users who view information for predicting the results of a competition or purchase a voting ticket online. The terminal 200 is, for example, a smartphone, a tablet computer, or the like.

[0022] The database 300 is a device that stores information for predicting the results of a competition and information related to the results of the competition, and records, for example, a starting list, a match list, information about competitors, videos of past races or matches, results of races or matches, and the like.

[0023] (2. Hardware Configuration of the Server) FIG. 2 is a block diagram showing the hardware configuration of the server 100.

[0024] As shown in FIG. 2, the server 100 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM 13, a recording medium 14, an output device 15, a communication device 16, and an input device 17. Each component is connected by a bus 18.

[0025] The CPU 11 controls the operation of the entire server 100, is connected to each component, and exchanges control signals and data.

[0026] In the ROM 12, an operating program necessary for controlling the operation of the entire server 100 and various data are recorded.

[0027] The RAM 13 is for temporarily recording data and programs, and holds programs and data read from the recording medium 14, as well as other data necessary for communication.

[0028] The recording medium 14 is composed of a hard disk, a flash memory, or the like, and records data processed by the server 100.

[0029] The output device 15 includes a display device such as an LCD (Liquid Crystal Display), and an audio output device such as a speaker. The output device 15 outputs, for example, data output from the CPU 11 under the control of the CPU 11.

[0030] The communication device 16 includes a communication interface for connecting the server 100 to a computer communication network such as the Internet, and communicates with other information processing devices and the like via the communication device 16.

[0031] The input device 17 includes input devices such as buttons, keyboards, touch panels, and microphones. The input device 17 receives an operation input from a user of the server 100 and outputs a signal corresponding to the received operation input to the CPU 11.

[0032] (3. Functional Configuration of the Server in the Embodiment) The functional configuration of the server 100 will be described with reference to FIG. 3.

[0033] Functionally, the server 100 includes a list providing unit 101, a posting unit 102, a generation unit 103, and a proof page providing unit 104. In the present embodiment, the CPU 11 and the communication device 16 function as the list providing unit 101, the posting unit 102, the generation unit 103, and the proof page providing unit 104.

[0034] The list providing unit 101 provides a list of purchase histories of lottery tickets for predicting the results of competitions purchased by the first user to the first terminal 200-1 used by the first user.

[0035] The first user is a user who uses the first terminal 200-1 among the plurality of terminals 200, and is, for example, a user who has purchased a lottery ticket on "Sales Site X".

[0036] Fig. 4 shows an example of a list of purchase histories provided to the first terminal 200-1. The list 500-1 of purchase histories in Fig. 4 allows the first user to confirm the items and quantities of the voting tickets purchased at the "Sales Site X". The items are represented by, for example, frame numbers, car numbers, horse numbers, numbers indicating the results of matches, etc. The list 500-1 includes the purchase history 501 of the voting ticket T1 during the purchasable period, the purchase history 502 of the voting ticket T2 for which it has been determined whether or not it has won, and a button 503 for posting the selected purchase history in the list to the SNS. When the purchase histories 501 and 502 are selected by the user, they are highlighted. The list 500-1 in Fig. 4 shows that the purchase history 501 has been selected by the first user.

[0037] For example, when the list providing unit 101 receives a request for presenting the purchase history of the first user from the first terminal 200-1 used by the first user, it transmits the list 500-1 in Fig. 4 to the first terminal 200-1 and causes the list 500-1 to be displayed on the first terminal 200-1.

[0038] When the posting unit 102 receives an instruction for selecting and posting any one of the purchase histories in the list by the first user from the first terminal 200-1, it determines a proof URL (Uniform Resource Locator) associated with the selected purchase history, and posts a proof message including the proof URL to the SNS that has been pre-linked and set by the first user.

[0039] The linked setting is a setting that associates the user information of the first user managed by the server 100 with the account information used by the first user on the SNS, and enables, for example, the first user to post from the "Sales Site X" to the SNS.

[0040] The proof URL is a URL for the server 100 to prove that the voting ticket related to the purchase history has been purchased by the first user.

[0041] For example, when the posting unit 102 receives information indicating that the purchase history 501 and the button 503 in the list 500-1 of FIG. 4 have been selected from the first terminal 200-1, it determines the proof URL 601 associated with the purchase history 501. Then, the posting unit 102 posts a proof message including the proof URL 601 to the SNS using the account name (e.g., @first_user) that the first user uses on the SNS.

[0042] FIG. 5 shows an example of a proof message. The proof message 600 in FIG. 5 includes the proof URL 601 and information 602 regarding the lottery ticket T1 of the purchase history 501 selected by the first user.

[0043] When the generation unit 103 receives an access to the proof URL included in the proof message from the second terminal 200-2 used by a second user different from the first user, it generates a proof page including at least the account name of the first user on the SNS related to the purchase history associated with the accessed proof URL, and the purchase item and quantity of the lottery ticket related to the purchase history associated with the accessed proof URL.

[0044] For example, when the generation unit 103 detects an access to the proof URL 601 of the proof message 600 in FIG. 5 from the second terminal 200-2, it generates a proof page including information on the account name "@first_user" of the first user of the purchase history 501, and information on the purchase item "2-4-6" and quantity "10 tickets" of the lottery ticket T1 purchased by the first user.

[0045] Here, the generation unit 103 includes, as an image, in the proof page the account name of the first user on the SNS related to the purchase history associated with the accessed proof URL, and the purchase item and quantity of the lottery ticket related to the purchase history associated with the accessed proof URL.

[0046] Fig. 6 shows an example of a proof page. The proof page 700-1 in Fig. 6 includes an image 703 that contains a ballot 701 imitating an actual ballot and the account name 702 of the first user. The ballot 701 includes information on the purchase point 704 and quantity 705 of the ballot T1 related to the purchase history 501.

[0047] Here, when the access is within the purchasable period of the ballot related to the purchase history associated with the proof URL where the access occurred, the generation unit 103 generates a proof page that further includes a link for purchasing the ballot.

[0048] For example, when the access to the proof URL 601 is within the purchasable period of the ballot T1 related to the purchase history 501, the generation unit 103 generates a link for transitioning to the purchase page of the ballot T1 in association with the image 703. When the image 703 associated with the link is selected, the user is redirected to the purchase page of the ballot T1.

[0049] Fig. 7 shows an example of a purchase page. The purchase page 800 in Fig. 7 is a page for purchasing the ballot T1. The purchase page 800 includes a departure form 801, a column 802 for specifying the purchase point, a column 803 for specifying the quantity of the ballot, and a button 804 for proceeding to the procedure of purchasing the ballot with the specified purchase point and quantity. When the image 703 is selected on the proof page 700-1, the user is redirected to the purchase page 800 in Fig. 7 where the same purchase point as in the purchase history 501 is specified in the column 802. The second user who selects the image 703 can easily purchase a ballot with the same purchase point as the ballot T1 purchased by the first user by specifying the quantity in the column 803 and selecting the button 804.

[0050] In addition, when the access occurs after it is determined whether the ballot related to the purchase history associated with the proof URL where the access occurred has won, the generation unit 103 generates a proof page that further includes information indicating whether the ballot has won and, if the ballot has won, the refund amount or the recovery rate associated with the first user.

[0051] The recovery rate is the ratio of the refund amount to the purchase amount of the lottery ticket, and is a value calculated for each user. The recovery rate can be regarded as indicating the performance of the user. For example, a user with a higher recovery rate can be regarded as a user who is better at selecting the items and quantities to buy. The recovery rate for each user is calculated when the refund amount is determined, and the information on the calculated recovery rate is stored in the recording medium 14 of the server 100 or the database 300. The lottery tickets subject to the calculation of the recovery rate are arbitrarily set by the operator of the server or the first user. For example, the operator of the server can set the lottery tickets subject to the calculation of the recovery rate to the lottery tickets purchased by the first user in the past year, or only the lottery tickets purchased by the first user most recently, that is, only lottery ticket T1.

[0052] For example, when the access to the proof URL 601 occurs after it is determined whether the lottery ticket T1 related to the purchase history 501 has won, the generation unit 103 generates a proof page further including information indicating whether the lottery ticket T1 has won, and the refund amount or the recovery rate associated with the first user if the lottery ticket T1 has won. When the information indicating the refund amount is included in the proof page, the second user who views the proof page can confirm the result of the lottery ticket T1 in detail. Also, when the information indicating the recovery rate associated with the first user is included in the proof page, the second user who views the proof page can easily confirm the past and current performance of the first user.

[0053] FIG. 8 shows an example of a proof page when there is an access after it is determined whether the lottery ticket has won. The proof page 700-2 in FIG. 8 is assumed to be generated when the lottery ticket T1 has won. The proof page 700-2 in FIG. 8 includes an image 707 including a lottery ticket 701 imitating the actual lottery ticket, the account name 702 of the first user, and information 706 indicating the winning and the refund amount.

[0054] The proof page providing unit 104 provides the generated proof page to the second terminal 200-2.

[0055] For example, when the access to the proof URL 601 by the second user occurs, the proof page providing unit 104 provides the proof page generated according to the time of the access to the second terminal 200-2. Specifically, when the access to the proof URL 601 occurs during the purchasable period of the voting ticket T1, the proof page providing unit 104 provides the proof page 700-1 in which the link to the purchase page 800 of the voting ticket T1 is associated with the image 703. When the access to the proof URL 601 occurs after the purchasable period of the voting ticket T1 and before it is determined whether the ticket has won, the proof page providing unit 104 provides the proof page 700-1 in which the link to the purchase page 800 of the voting ticket T1 is not associated with the image 703. When the access to the proof URL 601 occurs after it is determined whether the ticket has won, the proof page providing unit 104 provides the proof page 700-2 including the image 707 including the information 706 indicating the winning and the refund amount.

[0056] In addition, when the posting unit 102 detects that the voting ticket related to the purchase history associated with the accessed proof URL has won, the posting unit 102 quotes the proof message related to the proof page from the account on the SNS used by the operator of the server 100, and posts to the SNS a winning message including the information indicating that the voting ticket related to the purchase history associated with the accessed proof URL has won, the refund amount or the recovery rate associated with the first user.

[0057] For example, when the posting unit 102 refers to the information stored in the database 300 and detects that the voting ticket T1 related to the purchase history 501 associated with the accessed proof URL 601 has won, the posting unit 102 quotes the proof message 600 related to the proof page 700-2 from the official account on the SNS of the operator of the "Sales Site X", and posts to the SNS a winning message including the information indicating that the voting ticket T1 has won, the refund amount of the voting ticket T1 or the recovery rate of the first user.

[0058] Fig. 9 shows an example of a winning message. The winning message 900 in Fig. 9 includes text 901 indicating that the ticket T1 has won and the refund amount of the ticket T1, and content 902 that quotes the certification message 600. The content 902 includes the certification URL 601, and an image 707 included in the certification page 700-2 of the certification URL 601 is displayed as a thumbnail image.

[0059] In addition, when the certification message is posted to the SNS, the list providing unit 101 includes in the list at least a thumbnail image including the purchase date and quantity of the ticket related to the purchase history associated with the certification URL included in the posted certification message.

[0060] For example, after the certification message 600 in Fig. 5 is posted to the SNS by the posting unit 102, when the list providing unit 101 receives a request for presenting the purchase history from the first terminal 200-1 of the first user, it provides the list 500-2 of the purchase history shown in Fig. 10 to the first terminal 200-1. The list 500-2 in Fig. 10 includes a thumbnail image 504 in the purchase history 501. The thumbnail image 504 is a reduced image of the ticket 701 including information on the purchase date 704 and quantity 705 of the ticket T1 related to the purchase history 501.

[0061] Furthermore, when the list providing unit 101 detects that the ticket related to the purchase history associated with the certification URL included in the certification message has won, it displays information indicating that the ticket has won overlaid on the thumbnail image.

[0062] For example, when the list providing unit 101 refers to the information stored in the database 300 and detects that the ticket T1 related to the purchase history 501 associated with the certification URL 601 has won, as shown in Fig. 11, it displays information 505 indicating that the ticket T1 has won overlaid on the thumbnail image 504.

[0063] (4. Operations of the Server in the Embodiment) The operation of the server 100 according to this embodiment will be described with reference to FIG. 12. For example, when the server 100 receives a request to present a purchase history from the first terminal 200-1 used by the first user, it starts the control process shown in FIG. 12.

[0064] The list providing unit 101 provides a list of purchase histories of lottery tickets for predicting the results of competitions purchased by the first user to the first terminal 200-1 used by the first user (step S101).

[0065] For example, the list providing unit 101 transmits the list 500-1 in FIG. 4 to the first terminal 200-1 and causes the first terminal 200-1 to display the list 500-1.

[0066] The posting unit 102 determines whether or not it has received an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal 200-1 (step S102). When the posting unit 102 determines that it has received an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal 200-1 (step S102; YES), it determines a proof URL associated with the selected purchase history, and posts a proof message including the proof URL to the SNS that has been pre-linked and set by the first user (step S103). On the other hand, when the posting unit 102 determines that it has not received an instruction to select and post any one of the purchase histories in the list by the first user from the first terminal 200-1 (step S102; NO), it waits as it is.

[0067] For example, when the posting unit 102 receives information indicating that the purchase history 501 and the button 503 in the list 500-1 in FIG. 4 have been selected from the first terminal 200-1, it determines the proof URL 601 associated with the purchase history 501, and posts a proof message 600 including the proof URL 601 to the SNS using the account name of the first user. On the other hand, when the posting unit 102 does not receive information indicating that the purchase history and the button 503 in the list 500-1 in FIG. 4 have been selected from the first terminal 200-1, it waits as it is.

[0068] The generation unit 103 determines whether there has been an access to the proof URL included in the proof message from the second terminal 200-2 used by the second user (step S104). When the generation unit 103 determines that there has been an access to the proof URL included in the proof message from the second terminal 200-2 (step S104; YES), it determines whether the access is within the purchasable period of the ballot ticket related to the purchase history associated with the proof URL to which the access was made (step S105). On the other hand, when the generation unit 103 determines that there has been no access to the proof URL included in the proof message from the second terminal 200-2 (step S104; NO), it waits as it is.

[0069] For example, when the generation unit 103 detects that there has been an access to the proof URL 601 of the proof message 600 in FIG. 5 from the second terminal 200-2, it determines whether the access to the proof URL 601 is within the purchasable period of the ballot ticket T1 related to the purchase history 501. On the other hand, when the generation unit 103 does not detect that there has been an access to the proof URL 601 of the proof message 600 in FIG. 5 from the second terminal 200-2, it waits as it is.

[0070] In step S105, when the generation unit 103 determines that the access is within the purchasable period of the ballot ticket related to the purchase history associated with the proof URL to which the access was made (step S105; YES), it generates a proof page including the account name in the SNS of the first user related to the purchase history associated with the proof URL to which the access was made, the purchase item and quantity of the ballot ticket related to the purchase history associated with the proof URL to which the access was made, and a link for purchasing the ballot ticket (step S106). On the other hand, when the generation unit 103 determines that the access is not within the purchasable period of the ballot ticket related to the purchase history associated with the proof URL to which the access was made (step S105; NO), it determines whether the access was after it was determined whether the ballot ticket related to the purchase history associated with the proof URL to which the access was made was a winning ticket (step S107).

[0071] For example, when the access to the proof URL 601 is within the purchasable period of the voting ticket T1 related to the purchase history 501, the generation unit 103 generates a proof page 700-1 including an image 703 that imitates a physical voting ticket, an account name 702 of the first user, and a link for transitioning to the purchase page 800 of the voting ticket T1 is associated with the image 703. On the other hand, when the access to the proof URL 601 is not within the purchasable period of the voting ticket T1 related to the purchase history 501, the generation unit 103 determines whether the access to the proof URL 601 is after it is determined whether the voting ticket T1 has won or not.

[0072] In step S107, when the generation unit 103 determines that the access is after it is determined whether the voting ticket related to the purchase history associated with the proof URL to which the access was made has won or not (step S107; YES), the account name in the SNS of the first user related to the purchase history associated with the proof URL to which the access was made, the purchase item and quantity of the voting ticket related to the purchase history associated with the proof URL to which the access was made, information indicating whether the voting ticket has won or not, and when the voting ticket has won, the refund amount or the recovery rate associated with the first user, are included to generate a proof page (step S108). On the other hand, when the generation unit 103 determines that the access is before it is determined whether the voting ticket related to the purchase history associated with the proof URL to which the access was made has won or not (step S107; NO), the account name in the SNS of the first user related to the purchase history associated with the proof URL to which the access was made, the purchase item and quantity of the voting ticket related to the purchase history associated with the proof URL to which the access was made, are included to generate a proof page (step S109).

[0073] For example, after it is determined whether the access to the proof URL 601 hits the voting ticket T1 related to the purchase history 501, and if the voting ticket T1 hits, the generation unit 103 generates a proof page 700-2 including an image 707 including a voting ticket 701 imitating a physical voting ticket, the account name 702 of the first user, and information 706 indicating the hit and the refund amount. On the other hand, when the access to the proof URL 601 is before it is determined whether the voting ticket T1 related to the purchase history 501 hits, the generation unit 103 generates a proof page 700-1 including an image 703 including a voting ticket 701 imitating a physical voting ticket and the account name 702 of the first user.

[0074] The proof page providing unit 104 provides the generated proof page to the second terminal 200-2 (step S110).

[0075] For example, when the access to the proof URL 601 is made during the purchasable period of the voting ticket T1, the proof page providing unit 104 provides a proof page 700-1 in which a link to the purchase page 800 of the voting ticket T1 is associated with the image 703. When the access to the proof URL 601 is made after the purchasable period of the voting ticket T1 and before it is determined whether it hits, the proof page providing unit 104 provides a proof page 700-1 in which a link to the purchase page 800 of the voting ticket T1 is not associated with the image 703. When the access to the proof URL 601 is made after it is determined whether it hits, the proof page providing unit 104 provides a proof page 700-2 including the information 706 indicating the hit and the refund amount.

[0076] According to this embodiment, for the purchase history selected by the user from the list of purchase histories, a proof message is posted on the SNS. When there is an access from another user to the proof URL included in the proof message, the server that provides the list of purchase histories to the user generates a proof page for proving the purchase of the lottery ticket related to the purchase history included in the proof message, and provides the proof page to the other user who accessed the proof URL. Thereby, other users can confirm that the purchase of the lottery ticket by the user has been proved by the server that provides the list of purchase histories to the user, and the user can prove the purchase of the lottery ticket on the SNS by posting it on the SNS.

[0077] Also, according to this embodiment, when the access to the proof URL is within the purchasable period of the lottery ticket, a proof page including a link for purchasing the lottery ticket related to the purchase history is generated. Thereby, other users who viewed the proof page can easily purchase the same lottery ticket as the user.

[0078] Also, according to this embodiment, when the access to the proof URL is after it is determined whether the lottery ticket has won or not, a proof page including information indicating whether the lottery ticket has won and, if the lottery ticket has won, the refund amount or the recovery rate associated with the user is generated. Thereby, other users who viewed the proof page can easily confirm the detailed results of the lottery ticket purchased by the user and the user's performance.

[0079] Also, according to this embodiment, when the user posts a message about the purchase history and it is detected that the lottery ticket for which there has been an access to the proof URL by another user has won, a message indicating that it has won is posted by the server operator. Thereby, the user can prove to more other users on the SNS that the user has purchased the lottery ticket, and can further notify that the user has won.

[0080] Further, according to the present embodiment, the proof page includes, as an image, the user's account name on the SNS, the purchase item and quantity of the voting ticket related to the purchase history associated with the proof URL for which access has been made. Thereby, an image related to the purchase history posted by the user can be made to flow on the timeline of the SNS.

[0081] Also, according to the present embodiment, after a proof message is posted for the selected purchase history, the user can view, in the list of purchase histories, information on the voting ticket related to the selected purchase history as a thumbnail image. Further, when it is detected that the voting ticket has hit, information indicating that the ticket has hit is superimposed and displayed on the thumbnail image. Thereby, the user can easily confirm the posted information and the result of the voting ticket in the list of purchase histories.

[0082] (5. Modification example) As described above, the embodiments of the present invention have been described. However, when implementing the present invention, various forms of modification and application are possible.

[0083] In the above embodiment, when the voting ticket has hit, the generation unit 103 generates a proof page further including information indicating whether or not the voting ticket has hit, the refund amount, or the recovery rate of the first user. However, the present invention is not limited to this, and a proof page including both the refund amount and the recovery rate of the first user may be generated.

[0084] Also, in the above embodiment, after it is determined whether or not the access hits a voting ticket related to a purchase history associated with the authenticated URL where the access occurred, if the voting ticket did not hit and the way of missing is regrettable, the generation unit 103 may generate a proof page further including information indicating that the voting ticket did not hit and information on the voting ticket that hit. The criterion for whether the way of missing is regrettable is arbitrarily set by the server operator or the first user. For example, after it is determined that the access to the authenticated URL 601 did not hit the voting ticket T1 related to the purchase history 501, if only one part of the purchase points of the voting ticket T1 is different from the voting ticket that hit, the generation unit 103 generates a proof page further including information indicating that the voting ticket T1 did not hit and information on the purchase points of the voting ticket that hit. For example, instead of the information 706 of the proof page 700-2 in FIG. 8, the generation unit 103 includes information on the purchase points of the voting ticket that did not hit and the voting ticket that hit in the image 707.

[0085] Also, in the above embodiment, when the posting unit 102 detects that a voting ticket related to a purchase history associated with the authenticated URL where the access occurred hits, the posting unit 102 quotes a proof message related to the proof page from an account on the SNS used by the operator of the server 100, and posts a hit message including information indicating that the voting ticket related to the purchase history associated with the authenticated URL where the access occurred hits, and the refund amount or the recovery rate of the first user, to the SNS. However, the present invention is not limited to this, and a hit message including both the refund amount and the recovery rate associated with the first user may be posted to the SNS.

[0086] Also, in the above embodiment, although the winning message 900 includes the proof URL 601 determined when receiving the selection and submission instruction of the purchase history from the first terminal 200-1, it is not limited to this. For example, when the proof URL 601 is reposted, in the case of an SNS where the thumbnail image displayed in the content 902 of the winning message 900 is not updated and the previous image, that is, the image 703 included in the proof page 700-1 is used as the thumbnail image, the posting unit 102 may determine a proof URL different from the proof URL 601 and include the proof URL different from the proof URL 601 in the winning message 900. Then, when the generation unit 103 detects that there has been an access to a proof URL different from the proof URL 601 of the winning message 900 from the terminal 200, the generation unit 103 generates a proof page including information indicating that the voting ticket T1 has won, the proof URL 601, and the proof page providing unit 104 provides the generated proof page to the terminal 200.

[0087] Also, by applying the operation program that defines the operation of the server 100 according to the above embodiment to an existing personal computer or information terminal device, it is also possible to make the personal computer or information terminal device function as the server 100 according to the embodiment.

[0088] The present invention can be implemented in various embodiments and variations without departing from the broad spirit and scope of the present invention. Also, the above-described embodiments are for explaining the present invention and do not limit the scope of the present invention. That is, the scope of the present invention is indicated by the claims rather than the embodiments. And various modifications made within the scope of the claims and within the scope of the meaning of the invention equivalent thereto are considered to be within the scope of the present invention.

Industrial Applicability

[0089] According to the present invention, it is possible to provide a server, a control method, and a program capable of proving in an SNS that a user has purchased a voting ticket.

Explanation of Signs

[0090] 11 CPU 12 ROM 13 RAM 14 Recording medium 15 Output device 16 Communication device 17 Input device 18 Bus 100 Server 101 List providing unit 102 Submission unit 103 Generation unit 104 Proof page providing unit 200 Terminal 200-1 First terminal 200-2 Second terminal 300 Database 400 Computer communication network 500-1,500-2,500-3 List 501,502 Purchase history 503,804 Button 504 Thumbnail image 505,602,706 Information 600 Proof message 601 Proof URL 700-1,700-2 Proof page 701 Voting ticket 702 Account name 703,707 Image 704 Purchase item 705 Quantity 800 Purchase page 801 Departure list 802,803 Column 900 Winning message 901 Text 902 Content

Claims

1. a list providing unit that provides a list of purchase history of betting tickets for predicting the outcome of a competition purchased by a first user to a first terminal used by the first user; a posting unit that, when receiving an instruction from the first terminal by the first user to select and post any one of the purchase histories from the list, determines a certification URL associated with the selected purchase history, and posts a certification message including the certification URL to an SNS that has been previously linked with the first user; a generation unit that, when a certification URL included in the certification message is accessed from a second terminal used by a second user different from the first user, generates a certification page that includes at least an account name in the SNS of the first user related to the purchase history associated with the accessed certification URL and a selection and number of betting tickets related to the purchase history associated with the accessed certification URL; a certification page providing unit that provides the generated certification page to the second terminal; A server comprising:

2. The generation unit generates the certification page further including a link for purchasing the betting ticket when the access occurs during a period during which the betting ticket related to the purchase history associated with the accessed certification URL is available for purchase. The server according to claim 1 .

3. When the access occurs after it has been determined whether or not the betting ticket related to the purchase history associated with the accessed certification URL has been a winning ticket, the generation unit generates the certification page further including information indicating whether or not the betting ticket has been a winning ticket, and, when the betting ticket has been a winning ticket, a refund amount or a recovery rate associated with the first user. The server according to claim 1 .

4. When the posting unit detects that the betting ticket related to the purchase history associated with the accessed certification URL has been a winning ticket, the posting unit posts a winning message to the SNS from an account on the SNS used by an operator of the server, citing a certification message related to the certification page, the winning message including information indicating that the betting ticket related to the purchase history associated with the accessed certification URL has been a winning ticket and a refund amount or a recovery rate associated with the first user.

4. The server according to claim 1, wherein the first and second storage units are connected to the first and second storage units.

5. The generation unit includes, in the certification page, as an image, an account name in the SNS of the first user related to the purchase history associated with the accessed certification URL and a selection and a quantity of a betting ticket related to the purchase history associated with the accessed certification URL.

4. The server according to claim 1, wherein the first and second storage units are connected to the first and second storage units.

6. When the certification message is posted to the SNS, the list providing unit includes, in the list, a thumbnail image including at least the selection and quantity of the betting ticket related to the purchase history associated with the certification URL included in the posted certification message.

4. The server according to claim 1, wherein the first and second storage units are connected to the first and second storage units.

7. When the list providing unit detects that the betting ticket related to the purchase history associated with the certification URL included in the certification message is a winning ticket, the list providing unit displays information indicating that the betting ticket is a winning ticket by superimposing the information on the thumbnail image.

7. The server according to claim 6.

8. A control method executed by a server, comprising: The server, providing a list of purchase history of betting tickets for predicting the outcome of a competition purchased by a first user to a first terminal used by the first user; When an instruction to select and post any one of the purchase histories from the list by the first user is received from the first terminal, a certification URL associated with the selected purchase history is determined, and a certification message including the certification URL is posted to an SNS with which a link setting has been made in advance by the first user; When a certification URL included in the certification message is accessed from a second terminal used by a second user different from the first user, a certification page is generated that includes at least an account name in the SNS of the first user related to the purchase history associated with the accessed certification URL and a selection and quantity of betting tickets related to the purchase history associated with the accessed certification URL; providing the generated verification page to the second terminal; A control method comprising:

9. Computer, a list providing unit that provides a list of purchase history of betting tickets for predicting the outcome of a race purchased by a first user to a first terminal used by the first user; a posting unit that, when receiving an instruction from the first terminal by the first user to select and post any one of the purchase histories from the list, determines a certification URL associated with the selected purchase history and posts a certification message including the certification URL to an SNS that has been previously linked with the first user; a generation unit which, when a certification URL included in the certification message is accessed from a second terminal used by a second user different from the first user, generates a certification page including at least an account name in the SNS of the first user related to a purchase history associated with the accessed certification URL and a selection and quantity of betting tickets related to the purchase history associated with the accessed certification URL; a certification page providing unit that provides the generated certification page to the second terminal; A program characterized by causing the program to function as a

Images