KR102089779B1 - Method for brokering item trade and server thereof - Google Patents

Abstract

The present invention relates to a transaction intermediary method and a server thereof which provide a transaction of a betting history between users in a betting game for predicting an actual sports match result in advance. To this end, according to an embodiment of the present invention, the transaction intermediary method comprises the steps of: receiving, from a first user terminal, a request for sale of a betting ticket including betting information made by allowing a first user to bet on one or more matches; determining a start time of the last match among the one or more matches included in the betting ticket; setting a transaction closing time based on the start time of the last match; and when the transaction closing time arrives, determining that the betting ticket cannot be traded.

Description

METHOD FOR BROKERING ITEM TRADE AND SERVER THEREOF}

The present invention relates to a transaction intermediary method and server, and more particularly, to a transaction intermediary method and server that provides a transaction of betting history between users in a betting game that predicts actual sports results in advance.

A betting game such as Toto or Proto is a game that predicts the results before a game is held for an athletic event and receives dividends by ranking according to the result of the game (winning result). The types of betting games include athletics wins, draws, defeats, wins, scores, and scores, mixed games, mixed winners, specials, etc. There are record games that match the scores of various games such as scores, scorers, and winners.

Betting games are being activated both offline and online. Online betting games allow users to bet on the results of real matches using virtual goods, and receive dividends as virtual goods according to the match results. Since online betting games are made of virtual goods rather than real goods, they have the advantage of being less burdensome and easier to access than offline methods.

Online or offline betting games are based on the outcome of the actual match, so the user can determine the overall status of the match and league, such as the results of the bets that the user bet on, the condition and performance of the players who participated in the match, and the match between the teams. It is important. However, it is difficult for a general user to grasp all the information that can be considered when placing a bet, and even if a lot of information is provided to a general user, it is very difficult to bet by analyzing the information. In some cases, betting game companies provide information about the odds of each team to users participating in the game. However, the odds alone have limitations in increasing the hit ratio for the average user to the betting game, and as a result, the newly introduced user cannot enjoy the betting game for a long time, and the number of users gradually decreases. In addition, since the content provided in the betting game is limited, there is also a problem that users with a high level of knowledge in addition to general users quickly lose interest.

Therefore, a new method is required to increase the interest of users who play a betting game and increase the sustainability of the betting game.

Korean Patent Publication No. 10-2010-0001466

An object of the present invention is to provide a transaction intermediary method and a server capable of increasing the interest of a user playing a betting game in an online-type betting game and increasing the sustainability of the betting game.

In order to solve the above problems, a method of brokering a transaction of a betting ticket between a first user and a second user of the present invention is a betting that includes betting information that a first user bets on one or more matches from a first user terminal. Receiving a request to sell the ticket; Determining a start time of the last match among one or more matches included in the betting ticket; Setting a transaction closing time based on the start time of the last game or the transaction end request time transmitted from the first user terminal; And when the transaction deadline arrives, the betting ticket includes determining that the transaction is impossible.

In addition, the transaction intermediary method according to an embodiment of the present invention further includes determining a betting ticket that satisfies a first determination condition from a group of betting tickets held by the first user, and receiving a request to sell the betting ticket. A bet ticket is a bet ticket that satisfies the first judgment condition, and the first judgment condition is that there is an unstarted match among one or more matches included in the betting information, and the difference between the current time and the start time of the unstarted match is 1 Can be satisfied when the judgment period is exceeded.

In addition, the step of determining a betting ticket that satisfies the first determination condition is determining a non-starting match among the games included in the betting ticket based on the start time and the current time of the game included in each betting ticket in the betting ticket group ; And it may include the step of setting the time before the first judgment period from the start time of the unstarted game as a sellable time of the betting ticket.

In addition, the transaction intermediary method according to an embodiment of the present invention further includes providing a sales registration screen to a first user terminal before receiving a request to sell a bet ticket, and the sales registration screen is a first user It may include a reserved ticket information area in which bet tickets satisfying the first determination condition among bet tickets held by the company are listed.

In addition, the transaction intermediary method according to an embodiment of the present invention, when approving a sale request, assigning an identification code to the betting ticket; And registering the bet ticket on the exchange bulletin board based on the identification code.

In addition, the transaction intermediary method according to an embodiment of the present invention includes the step of updating bet information according to the result of the finished game, when any one of the at least one game included in the bet ticket ends The information may include the number of betting games betted by the first user and the number of bet hits by the first user.

In addition, the transaction brokering method according to an embodiment of the present invention further includes providing an exchange bulletin board screen to the second user terminal when receiving an inquiry request for the exchange bulletin board from the second user terminal, wherein the exchange bulletin board screen is A ticket information exposure area may be included, and the bet ticket may be displayed together with the number of betting games and the number of betting hits in the ticket information exposure area.

In addition, the bet information further includes at least one of a betting history, a bet amount, a sale amount, a dividend rate, a total odds ratio, an expected winning amount, and a hit record of the first user of the bet ticket, and at least some of the bet information is the ticket information exposure area Can be included in

In addition, the transaction intermediary method according to an embodiment of the present invention determines whether or not the first user's bet is hit with respect to the finished game after any one of the at least one games included in the betting ticket ends. step; And if the first user's bet for the match ended fails, the betting ticket may further include determining that the transaction is impossible.

In addition, in the transaction intermediary method according to an embodiment of the present invention, when a purchase request for a betting ticket is received from a second user terminal of a second user before a transaction closing time, the betting ticket is delivered to the account of the second user step; And subtracting the sale amount of the bet ticket from the second user's holding amount.

The transaction intermediary server for solving the above problems may be configured by including the control unit for the above-described transaction intermediary method.

The transaction intermediary method and server according to an embodiment of the present invention may induce users' interest by providing new content to a betting game. In addition, the transaction intermediary method and the server of the present invention are capable of trading a betting ticket including a part of a betting result for a game that has already ended.

1 is a conceptual diagram of an online betting system according to an embodiment of the present invention.
2 is a flowchart of a method for providing a betting game according to an embodiment of the present invention.
3 is a flowchart of a transaction brokering method according to an embodiment of the present invention.
4 is a flowchart of determining a betting ticket that satisfies a preset first determination condition according to an embodiment of the present invention.
5 to 10 are conceptual views for explaining a process of registering a bet ticket on an exchange bulletin board in a transaction intermediary method according to an embodiment of the present invention.
11 is a flowchart of steps for managing a betting ticket according to an embodiment of the present invention.
12 is a flowchart of the steps of brokering a transaction of a betting ticket between users according to an embodiment of the present invention.
13 to 15 show examples of screens displayed through a user terminal when a user purchases a betting ticket registered on an exchange bulletin board.
16 is a block diagram of a transaction intermediary server according to an embodiment of the present invention.

If described in detail with reference to the accompanying drawings the present invention. Here, repeated descriptions, well-known functions that may unnecessarily obscure the subject matter of the present invention, and detailed description of the configuration will be omitted. Embodiments of the present invention are provided to more fully describe the present invention to those skilled in the art. Accordingly, the shape and size of elements in the drawings may be exaggerated for a more clear description.

1 is a conceptual diagram of an online betting system 1000 according to an embodiment of the present invention. The online betting system 1000 according to an embodiment of the present invention includes a plurality of user terminals 10 and 20, a betting game server 30 and a transaction intermediary server 100. Here, the betting game server 30 and the transaction intermediary server 100 are configured by function to help understand the present invention, and these configurations may be implemented as one configuration. In addition, although the user terminals 10 and 20 in FIG. 1 are illustrated as a laptop computer, this is only an example and may be implemented as a personal computer (PC) or a portable terminal such as a smart phone or tablet PC.

The betting game server 30 functions to provide a betting game to a plurality of users. For example, the betting game server 30 may transmit game information on games to be opened in the future based on the current time to the plurality of user terminals 10 and 20. Here, the match information for the matches may be classified according to the event and the league to which the match belongs, and the match information may include a match start time, betting game information for each match, and odds for each betting game. In general, a betting game (or online betting game) is a match-type game that scores points or runs, as well as a match-type game that matches wins, draws, and loses of matches, wins, draws, and matches. There are various games such as games, special games to beat the winners, rankings, and scorers, and scores of specific matches, recorders to score the records of various matches, such as winners. The betting game server 30 calls the match information for matches for a plurality of events or leagues according to the administrator's input or through communication with an external server, and this is called at the request of the users 1 and 2 It can be transmitted to the user terminal (10, 20).

Users 1 and 2 can check game information provided by the betting game server 30 through their user terminals 10 and 20, and enjoy a betting game according to the game information.

As described above, online betting games have a problem in that users have a low hit ratio and content is limited, so that users can quickly lose interest in betting games. Online betting games are less burdensome than offline betting games, making it easier for new users to enter, but due to the reasons described above, it is difficult for newly introduced users to enjoy betting games for a long time, so there is a problem that the number of users gradually decreases. To solve this problem, the online betting system 1000 according to an embodiment of the present invention further includes a transaction intermediary server 100 capable of providing new content to a betting game.

The transaction mediation server 100 functions to mediate a transaction of betting tickets between users 1 and 2. Here, the betting ticket is predetermined information that can be paid through the betting game server 30 according to whether the users 1 and 2 match at least one game information with the actual game result, and the user If all of the included at least one game information matches the actual game result, the dividend amount according to the betting result may be deposited into the user's account through the betting game server 30. For example, among the users participating in the online betting game, the first user 1 is a seller who wants to sell a betting ticket including the betting history of his betting, and the second user 2 wants to purchase a betting ticket. Assume the situation of being a buyer. Here, the betting history is information indicating what betting games are included in the betting ticket. When the transaction brokerage server 100 receives a request from the second user terminal 20, the first user 1 sends the information of the bet ticket requested by the first user terminal 10 to the second user terminal 20 for sale. Send. When the second user confirms the information of the betting ticket and requests the purchase of the betting ticket, the transaction brokerage server 100 checks the holding amount in the account of the second user, and bets when the holding amount is higher than the selling amount of the betting ticket The ticket can be delivered to the account of the second user, the corresponding bet ticket is deleted from the account of the first user, and transaction information can be transmitted to the betting game server 30.

In addition, the transaction brokerage server 100 may provide an exchange bulletin board for brokering a transaction of betting tickets between users. At least one user's betting ticket may be registered on the exchange bulletin board. Here, the trading period of the betting ticket may be set based on the start time of the last game included in the betting ticket. Users can check the exchange bulletin board through a user terminal (for example, a laptop computer, personal computer (PC), portable terminal, etc.), view the betting tickets registered on the exchange bulletin board, and purchase the bet tickets have.

In addition, the transaction brokerage server 100 may provide the seller's hit information to other users. Users who want to purchase a bet ticket can check the hit information of the seller who registered the bet ticket when searching the bet ticket. Here, the seller's hit information may be cumulative information about the result obtained by the seller betting, and users who want to purchase a betting ticket use the seller's hit information as an objective judgment measure for the prediction accuracy of the betting ticket sold by the seller Can be utilized in. Therefore, even users who lack knowledge of games or bets can increase the winning rate by considering the seller's hit information and the objective information about the game.

When the betting ticket trading function through the transaction brokerage server 100 is added to the online betting game as described above, there are advantages as follows.

First, even a general user with little knowledge in the games can predict the actual result of the game with a higher probability by checking the betting history that is traded between users or sold by a user. In addition, when trading a betting ticket, the seller's hit information is provided to the users, so buyers can place a bet with a higher chance of winning using the seller's hit information.

Second, the seller will purchase the bet ticket that he / she has purchased if it is before the closing time (for example, 10 minutes before the last match), which is set based on the start time of the "last match" among the matches included in the bet ticket. You can sell anytime. For example, a user may place a bet on a plurality of matches, and there may be a situation in which the results of some of the plurality of matches are matched. At this time, the user may challenge the hit until the result of the last match according to his betting history, but may want to sell a winning bet ticket. Accordingly, the transaction brokerage server 100 according to an embodiment of the present invention sets the transaction closing time using the start time of the “last match” included in the match ticket. The user may sell his betting tickets to other users at various times, such as before the start of the first game, after the start of the first game, or after the results of at least some of the games included in the bet ticket have been hit.

Generally, a betting game may be played for at least one of a plurality of games, and for at least one of a plurality of games in each game. For example, when there are first to fourth games, various betting games, such as game-type games, score games, mixed games, special games, and record games, may exist for each game. The user can place a single bet on a single betting game and a multi bet on a plurality of betting games in a betting game proportional to the number of games. When a user bets on multiple matches, the user can consider the starting time and the selling point of the betting game that has not yet started during the multi betting, and set a different selling amount according to the number of bets already hit during the multi betting. And sell it to other users. In this case, the sales amount may be automatically determined based on the odds of each game.

Of course, the transaction intermediary server 100 according to an embodiment of the present invention may set a transaction closing time based on a start time of a “first match” among a plurality of matches included in a betting ticket, but the second advantage described above Therefore, it is more desirable to set the closing time of the transaction based on the start time of the "last match".

Third, it is possible to further secure the purchase time of the betting ticket. In a typical betting game, the participation time of the betting game (for example, the purchase time of the betting ticket) is set before the start time of the game (for example, 10 minutes, 20 minutes, 30 minutes, etc.). For example, if a first user tries to participate in a betting game for a certain game, but the corresponding game has already started, in a general betting game, it is not possible to participate in a betting game whose game time has passed. On the other hand, since the online betting system 1000 according to an embodiment of the present invention provides a trading function between users, and the transaction is based on the start time of the last game included in the betting ticket, a person who wants to purchase a betting ticket Can secure more time to purchase betting tickets.

As such, the transaction intermediary server 100 according to an embodiment of the present invention can provide content that users, as well as general users, have high knowledge in betting games or users with high hit ratios can feel interesting. Now, a method for providing a betting game through an online betting system or a transaction intermediary server and a transaction intermediary method according to an embodiment of the present invention will be further described with reference to FIGS. 2 to 15. The online betting system or transaction intermediary server according to an embodiment of the present invention provides a process of providing a betting game to a user (for example, a process of selling a betting ticket), a process of assisting the registration of a betting ticket from users, and It is possible to provide a process of brokering a transaction of betting tickets between users.

2 is a flowchart of a method for providing a betting game according to an embodiment of the present invention.

First, the betting game server 30 may transmit game information to the first user terminal 10, and information on odds, total odds, and expected winning amount according to a user's bet input through the first user terminal 10 To the user terminal 10. Here, the total odds is a value determined according to the odds and the number of bets selected by the user, and may be defined as a product of odds of a betting game betted by the user. For example, if the first user places bets on two betting games, and the odds of the betting games betted by the user are 1.5 respectively, the total odds are 1.5 * 1.5 = 2.25.

The first user places a bet through the first user terminal 10, and accordingly, the first user terminal 10 generates ticket purchase information (S11). Ticket purchase information may include bet information including at least one of a user's identifier (eg, account ID, unique identification code, etc.), bet amount, bet history, odds, total odds and expected winning amount.

In step S12, the ticket purchase information requested from the first user is transmitted to the betting game server 30.

In step S21, the betting game server determines whether one of the plurality of user terminals has received ticket purchase information. As a result of the determination, if ticket purchase information is received from any one user terminal, step S22 is performed, otherwise, step S25 is performed.

Step S22 is a step of generating a bet ticket according to the bet information received through step S21, step S23 is a step of allocating a bet ticket to the account of the first user, step S24 is the amount of bets from the amount held by the first user It is a step to deduct as much. In addition, when adding a betting ticket in step S22, the number of betting games that the user bet on may be added to the number of betting games betted by the user and betting games included in the betting information included in the betting ticket.

Step S25 is a step of determining whether all the games included in the betting ticket have ended. As a result of determination, when all the games are over, step S26 is performed. Otherwise, step S21 is performed.

The step S26 is a step of determining whether the bet history included in the bet ticket matches the actual result of the matches. If all of the betting details included in the betting ticket are the same as the actual match result (that is, the user hits all the match results), step S27 is performed, otherwise, step S28 is performed.

Step S27 is a step of adding at least a portion of the winning amount to the holding amount of the first user (eg, the account of the first user). For example, step S27 may be performed by adding the entire amount of the winning amount or the remaining amount of the winning amount excluding the fee to the amount held by the first user.

Step S28 is a step of destroying the bet ticket for which the determination of whether or not the hit has been completed.

In the above description, step S26 was described as being performed after the end of all the games. However, this is only an example, and step S25 may be made by determining whether a game is finished in one game unit, and step S26 is a single game unit judged to have ended the game through step S25, to determine whether or not the actual match result is hit. It can be done by In this case, after step S26, the step of determining whether the game of all the games included in the bet ticket has ended may be further included, and steps S27 and S28 after the step of determining whether the game of all the games included in the bet ticket has ended. , May be performed according to whether or not the betting games included in the betting ticket are hit.

3 is a flowchart of a transaction brokering method according to an embodiment of the present invention. The transaction intermediary method according to an embodiment of the present invention may be achieved by the transaction intermediary server 100. In the following description, it is assumed that a first user among a plurality of users requests to sell a betting ticket.

Step S31 is a step of requesting, by the first user terminal 10, the saleable bet ticket information to the transaction brokerage server 100 according to the request from the first user. According to an embodiment, the sellable bet ticket information may include information indicating which betting tickets are available to make a sales request to the transaction brokerage server 100 in consideration of the start time of a game included in the betting ticket.

Step S110 is a step in which the transaction intermediary server determines whether one of the plurality of user terminals has received a request for sellable bet ticket information. As a result of the determination, step S120 is performed when a request for saleable bet ticket information is received from any one user terminal, and step S130 is performed otherwise.

Step S120 is a step of determining a betting ticket that satisfies the first determination condition from the group of betting tickets held by the first user. The first judgment condition may be satisfied when there is an unstarted match among one or more matches, and the difference between the current time and the start time of the unstarted match exceeds the first judgment period. To this end, step S120 is a step of classifying an unstarted match among all games included in the betting ticket based on the start time and the current time of the match included in the betting ticket and using the start time of the match of the unstarted match. It may include the step of setting the time available for sale. The sellable time may be set as a time before the first judgment period (for example, 10 minutes, 20 minutes, 30 minutes, etc.) from the start time of the unstarted game. For example, the selling time of a betting ticket is before the first judgment period (for example, 10 minutes, 20 minutes, 30 minutes, etc.) based on the start time of the earliest unstarted game among all games included in the betting ticket. ). However, the sale time can be variously determined based on the start time of any one of the plurality of unstarted games when there are multiple unstarted games and should not be interpreted as the start time of the earliest unstarted game. Therefore, in another embodiment, the sellable time of the bet ticket is before the match start time (for example, 10 minutes, 20 minutes, 30 minutes, etc.) of the last unstarted match among the total matches included in the bet ticket. ).

In one embodiment, step S120 may include filtering bet tickets including a betting history (for example, a failed hit) of a prediction in a group of betting tickets held by the first user. As described with reference to FIG. 2, the determination of whether to hit each game in the betting information included in the betting ticket may be made in one game unit. The winning of a betting ticket is only possible if the prediction of all the games included in the betting ticket is hit, so if any prediction included in the betting ticket is missed, the betting ticket can be regarded as a failure to hit. Therefore, step S120 may include filtering a bet ticket for which any match has failed to hit. As a result of determining whether a bet is hit, the bet game server 30 may receive the result as described with reference to FIG. 2.

Step S125 is a step of transmitting information on a bet ticket (for example, a sellable bet ticket) determined through step S120. In one embodiment, step S125 may include generating a sales registration screen and transmitting the generated sales registration screen to the first user terminal 10 of the first user. The sales registration screen may include a reserved ticket information area in which a bet ticket (for example, a sellable bet ticket) that satisfies a first determination condition among bet tickets held by the first user is listed, and the first user sells Through the reserved ticket information area included in the registration screen, a bet ticket that he or she wants to sell can be selected and a sales amount can be set. In addition, the sales registration screen may further include a first search area, and a search function provided in the first search area may be used to search for a bet ticket that meets a user's desired condition.

Step S32 is a step of requesting, by the first user terminal 10, to sell a bet ticket and to send a sale amount.

In step S130, the transaction intermediary server determines whether a sale of a bet ticket is requested from one of the plurality of user terminals. As a result of the determination, if the sale of the bet ticket is requested from any one user terminal, step S140 is performed, otherwise, step S170 is performed. In the case of this example, since it is assumed that the first user terminal 10 requests the sale of the betting ticket, step S140 may be performed.

Steps S140 and S150 are steps for setting a trading period of a betting ticket. Step S140 is a step of determining the start time of the last match of the one or more matches included in the bet ticket requested to be sold, and step S150 is a closing time of the transaction based on the start time of the last match determined in step S140. This is the setting step. The closing time set through step S150 may be set as a time before the second judgment period from the last game start time. For example, the second determination period may be 10 minutes, 20 minutes, 30 minutes, etc., and the second determination period is not limited to the above period. In other words, the second judgment period may be set before the start time of the last game (eg, 10 minutes, 20 minutes, 30 minutes, etc.). According to an embodiment, the second determination period may be the same time as the first determination period considered in order to determine whether to be available for sale in step S120, but is not limited thereto.

In the above description, step S150 was described as using the start time of the last match among unstarted matches when setting the trade close time, but the method of setting the trade close time may be variously changed in addition to the above method. In another embodiment, step S150 may set a transaction closing time according to a period or time point requested by the first user. In this case, step S32 may further include, by the first user terminal 10, sending a request for the end of the transaction entered by the first user, in addition to the request to sell the bet ticket and the amount of the sale, step S150. May set a transaction closing time according to a transaction end request time transmitted from the first user terminal 10. For example, the first user starts a match after a predetermined time (for example, 1 hour to 48 hours) based on a time point at which the step S32 is performed, or one of a plurality of matches included in a betting ticket, or The end time may be set as the transaction end request time, and step S150 may be performed according to the transaction end request time transmitted from the first user terminal 10. In this case, step S150 determines whether the transaction end request time requested by the first user is earlier than the time before the second determination period from the start time of the last game, and the transaction end request time requested by the first user is of the last game. When the time from the start time is earlier than the time before the second determination period, the step of setting the transaction end request time as the transaction closing time may be further included. Otherwise, step S150 may further include transmitting an error message to the first user terminal.

Step S160 is a step of registering a betting ticket of the first user on the exchange bulletin board. Specifically, step S160 may include the step of assigning an identification code to the betting ticket and registering the betting ticket including the identification code and betting information and the sales amount for the betting ticket on the exchange bulletin board. In addition, when registering a betting ticket on the exchange bulletin board through step S160, a hit record of a user who wants to sell a betting ticket can also be registered.

Step S170 is a step of managing a bet ticket registered on the exchange bulletin board. The step of managing the bet ticket includes the step of determining whether or not the user's bet is hit after the end of each game included in the bet ticket, updating the bet information included in the bet ticket, brokering the transaction of the bet ticket, and It may include determining and processing whether the bet ticket cannot be traded based on the transaction closing time of the bet ticket.

Specifically, step S170 includes determining whether the first user correctly predicted the result of the finished game when the game end information is received from the betting game server. As described with reference to step S120, the winning of the betting ticket is possible only if the prediction of all the games included in the betting ticket is hit, so if any prediction included in the betting ticket misses, the betting ticket can be sold. Should be treated as such.

In addition, step S170 may include updating the betting information according to the result of the finished game when receiving game ending information from the betting game server. Here, the betting information may include the total number of betting games included in the betting ticket and the number of betting hits by the first user's bet among the betting games. For example, it is assumed that a first user places a bet on a winning game that matches a winning game of three games. In this case, the number of betting games in the first user's betting information is 3, and the number of betting hits is 0 because the matches have not yet been played. In addition, it is assumed that a match result is transmitted from the betting game server to the transaction intermediary server 100, whether the result of the first match or the first match is hit, among the three games betted by the first user. After confirming the match result information transmitted from the betting game server, the transaction brokerage server 100 updates the first user's betting information (eg, the number of betting hits). The number of betting hits is either kept at 0 or increased to 1 depending on whether the first match was hit or not.

In addition, step S170 is performed based on whether the closing time of the transaction has arrived, or a transaction of betting tickets cannot be processed or brokering trading of a betting ticket between a first user and another user according to a request to purchase a betting ticket from another user. can do.

4 is a flow chart for determining a betting ticket (S120) that satisfies a preset first determination condition according to an embodiment of the present invention. As described with reference to FIG. 3, the first judgment condition is satisfied when there is an unstarted match among one or more matches, and the difference between the time at which the sales request is received and the start time of the unstarted match exceeds the first judgment period Can be. In order to determine whether the first determination condition is satisfied, step S120 may include the following steps.

Step S121 is a step of checking betting information included in the betting ticket and checking the start time of each game included in the betting information.

Step S122 is a step of classifying an unstarted match among all games included in the betting ticket based on the start time of the match included in the betting ticket and the time when the sales request is received. As described above, betting games are for at least one of a plurality of matches, and in each match a plurality of types of games (e.g., win-win games, score games, mixed games, special games, Recorded games, etc.). In the betting game, there can be multiple types of bets per game, and the user can bet on multiple types of games in a single match, or single bets where only one type of bet is selected by the user. Multi bets are available for betting on one type of game in multiple matches or for multiple types of game in multiple matches. Therefore, the betting information included in the betting ticket may include betting history for one match or a plurality of types of matches.

For example, when the betting information includes only one betting history, step S122 may be performed by checking whether one game included in the betting information has started. In addition, when the bet information includes a bet history for a plurality of matches, step S122 checks the start time of each match included in the bet information, and determines the start time of each match and the time when a sales request is received. Unstarted matches can be classified on the basis.

Step S123 is a step of setting a sellable time of the betting ticket using the start time of the unstarted match. If there are multiple unsuccessful matches among the bets played by the user, before the match start time (for example, before the first judgment period from the start time of the match) or during a start match A sale time may be set before the game start time of the game with the latest time (eg, before the first judgment period from the game start time).

Step S124 is a step of determining whether the current time is before the sale time. As a result of the determination, when the sale time is before, a process of classifying a bet ticket into a saleable bet ticket is performed through step S125. Conversely, when the current time is after the sale time, a process of classifying the bet ticket into the non-saleable bet ticket is performed through step S126.

As described with reference to FIGS. 3 and 4, the transaction intermediary method according to an embodiment of the present invention may provide a transaction of a betting ticket between a plurality of users, and the transaction of the betting ticket is the last included in the betting information It is possible until the transaction closing time is set based on the start time of the game (or the first user's transaction end request time). Also, a request to sell a betting ticket may be set based on a start time of an unstarted match included in betting information. Now, a process of registering a betting ticket according to an embodiment of the present invention on an exchange bulletin board will be further described with reference to FIGS. 5 to 11.

5 to 10 are conceptual views for explaining a process of registering a bet ticket on an exchange bulletin board among the transaction intermediary methods according to an embodiment of the present invention. Specifically, FIGS. 5 to 10 show an example of screens displayed through a user terminal in the process of a user registering a betting ticket on an exchange bulletin board. The screens described below may be generated by a betting game server or a transaction intermediary server, and transmitted to a user terminal.

5 shows an example of a ticket purchase information screen displayed through a user terminal. The ticket purchase information screen may include at least a portion of the menu area mr, the first information area ir ₁ , the second information area ir ₂ , the purchase history area pr, and the chat area cr. The menu area mr is an area used for switching between various contents provided by a betting game server according to an embodiment of the present invention, and the first information area ir ₁ is an item selected through the menu area mr It is an area that displays information about. The second information area ir ₂ is an area indicating information (for example, a game ID, a holding amount, etc.) of a user logged into the betting game, and the chat area cr is an area for chatting between users.

The purchase history area pr includes a history of betting tickets purchased by a user. In this example, it is assumed that a user places a bet on a win / loss game among a plurality of betting games, and bets on two of the entire games. In addition, it is assumed that the user places a bet on wins, draws, or loses in the first game, and wins, draws, or loses on the second game. As described above, the betting game server 30 provides information on the total odds and expected sales amount through the user terminal 10 according to the user's betting, and the user uses the information displayed through the user terminal 10 To place a bet.

6 to 10 show an example of a sales registration screen displayed through a user terminal. The sales registration screen may be generated by the transaction intermediary server after determination of bet tickets satisfying the first judgment condition. The sales registration screen includes a menu area (mr), a first information area (ir ₁ ), a second information area (ir ₂ ), a reserved ticket information area (rr), a first search area (sr ₁ ), and a chat area (cr). It may include at least some of. The description of the menu area mr, the first information area ir ₁ , the second information area ir ₂ , and the chat area cr is made with reference to FIG. 5, and thus duplicate descriptions are omitted below.

The reserved ticket information area rr is an area in which betting tickets that can be sold by the user (eg, satisfied with a first judgment criterion) are listed. For example, unlike the purchase history area pr described with reference to FIG. 5 indicating the history of a bet ticket with a history purchased by the user, the reserved ticket information area rr is bet tickets with a purchased history Among them, it only shows betting tickets that can be traded with other users based on the current time. The method for determining bettable tickets that can be sold among all the betting tickets using the first determination condition has been described in detail with reference to FIGS. 3 and 4, and thus duplicate description is omitted. And, in this example, the number of betting tickets (for example, sellable betting tickets) determined by the transaction brokerage server is shown as three, but this is only an example, and according to the judgment result, 0, 1, 2 The number of bet tickets held by the user, such as four, four, or more, may be variously changed according to the determination method through the transaction brokerage server.

The first search area sr ₁ includes search conditions that can be input by the user to check some of the betting tickets that can be traded with other users. The user can check a bet ticket that satisfies a condition from among bet tickets that can be traded by inputting various search conditions. In FIG. 6, the first search area sr ₁ is illustrated as being only changeable in duration, but this is only an example and may be searchable by various attributes such as game type, date of purchase, bet amount, odds, and expected winning amount.

The user can check the betting tickets displayed in the reserved ticket information area rr, and input information through the detailed information spread area dr ₁ to dr ₃ for detailed information (eg, betting history, betting) Amount, odds, total odds, expected winning amount, etc.) can be checked. Thereafter, the user may select a betting ticket to be sold through the input unit. At this time, the user terminal may display an item for requesting the sale of the bet ticket selected by the user and whether the user has selected the correct bet ticket as shown in FIG.

8 shows a sales registration screen including a sales amount setting area nr displayed to a user. The user may input the sale amount of the bet ticket through the sale amount setting area nr, and when the input is completed by the user, a confirmation message may be displayed to the user as shown in FIG. 9. When the user inputs the confirmation button in the confirmation message shown in FIG. 9, the user terminal may transmit a sale request of the bet ticket selected by the user to the transaction brokerage server. Upon receiving a sales request from the user terminal, the transaction brokerage server may determine the start time of the last match included in the betting ticket, set the closing time of the transaction, and register the betting ticket on the exchange bulletin board. In addition, before registering a betting ticket on an exchange bulletin board, the transaction brokerage server may assign an identification code to the betting ticket and register the assigned identification code on the exchange bulletin board.

10 shows an example of an exchange bulletin board screen generated by a transaction brokerage server. The exchange bulletin board screen includes a menu area (mr), a first information area (ir ₁ ), a second information area (ir ₂ ), a chat area (cr), a ticket information exposure area (tr), and a second search area (sr ₂ ). It may include at least some of. Since the menu area mr, the first information area ir ₁ , the second information area ir ₂ , and the chat area cr have been described in detail above, redundant description is omitted.

The ticket information exposure area tr is an area that lists bet tickets requested by at least one user for sale. In the example illustrated in FIG. 10, it is assumed that a single user requests to sell one bet ticket according to the examples illustrated in FIGS. 6 to 9. Ticket information exposure area (tr) may be displayed by distinguishing each betting ticket for each identification code, at least one of identification code, number of folders (for example, number of betting games), betting information, sales amount, remaining time and registration time One item can be exposed. Here, the betting information may include at least one of a betting history, a betting amount, a dividend rate, a total odds rate, an expected winning amount, and a user's hit history. In FIG. 10, the folder indicates the number of betting games and the number of betting hits made by the user who requested to sell the above-mentioned betting ticket.

As described above, the user bets on multiple games with one type of betting game, with multiple types of betting games in one game, or multiple types of betting games in multiple games (e.g. multi betting) )can do. For example, if a user bets only on a losing game but bets on 8 games, the number of betting games is 8. Likewise, if a user bets on two betting games in one match, the number of betting games is 2.

Also, the contents of the folder item may be provided in a format such as "X / Y". In X / Y, Y means the number of betting games, and X means the number of betting hits. The transaction intermediary server according to an embodiment of the present invention sets the transaction closing time based on the last match among the games included in the betting ticket. Accordingly, the bet ticket may be exposed on the exchange bulletin board until the transaction closing time set based on the last match among at least one match included in the bet ticket.

For example, the buyers can classify and purchase bet tickets having a high number of bet hits among a plurality of bet tickets registered on the exchange bulletin board, based on the information on the folder item. Betting tickets with a high number of betting hits are required to be hit only for a relatively small number of betting games, which means that there is a higher chance of winning than betting tickets in which no match is played. In addition, the odds of a single betting game are important, but since the odds are proportional to the number of betting games, when purchasing a betting ticket with a high number of betting hits, it is possible to try to win a high amount of money with a relatively low risk. In addition, the seller can sell his bet ticket on the exchange bulletin board at any time, unless the bet ticket hits any betting game before the trading deadline and some of the multiple betting games are hit on the bet ticket, Not only is it easy to sell compared to other betting tickets that haven't played at all, but it can also be sold at a relatively high price.

As such, the exchange bulletin board provided by the transaction intermediary server according to an embodiment of the present invention can be used in various ways for both buyers and sellers, and further can provide interest to both general users and knowledgeable users.

The second search area sr ₂ provides a search or sort function for each item exposed in the ticket information exposure area tr.

The transaction brokerage server may repeatedly determine whether to request to purchase a bet ticket from another user, and whether the closing time of the transaction has arrived, according to a preset period. When receiving a purchase request for a betting ticket from another user, the transaction brokerage of the betting ticket is performed as described below. In addition, the transaction brokerage server may process the bet ticket as non-tradeable if it cannot receive a request to purchase a bet ticket from another user until the transaction deadline is reached.

11 is a flowchart of steps for managing a betting ticket according to an embodiment of the present invention.

Step S210 is a step of determining whether the game end information is received from the betting game server. Here, the match end information includes information indicating the end of the match of the match included in the betting ticket. When the game end information is received in step S210, step S220 is performed. Otherwise, step S240 is performed.

Step S220 is a step of determining whether a bet on the result of the match ended in the bet ticket was hit based on the match end information. As described above, betting tickets can only be won if the predictions of all matches included in the betting ticket are hit, so if any prediction in the betting ticket is missed, the betting ticket should not be sold to other users. Therefore, as a result of the determination through step S220, step S230 is performed only when the bet is hit, otherwise, step S260 is performed so that the betting ticket is not sold to other users.

Step S230 is a step of updating the betting information. Specifically, step S230 is a step of updating the number of betting hits included in the betting information. The number of betting hits updated through step S230 may be exposed to other users through the exchange bulletin board as described with reference to FIG. 10.

Step S240 is a step of determining whether the current time has arrived at the closing time of the transaction. As a result of the determination, when the current time arrives at the closing time of the transaction, step S260 is performed. As a result of the determination, if the current time has not reached the transaction closing time, step S250 is performed.

Step S250 is a step of brokering the transaction of the betting ticket. Step S250 includes determining whether a request to purchase a bet ticket registered on the exchange bulletin board is received from another user terminal. As a result of the determination, when a purchase request for a bet ticket is received, step S250 may include a step of brokering a transaction of the bet ticket between the first user and the user who made the purchase request. If the purchase request has not yet been received, the bet information may be updated according to the bet history still remaining, so that the updated bet information and the like can be displayed on the exchange bulletin board.

Step S260 is a step in which a transaction cannot be processed so that a bet ticket that has failed to hit or has passed the closing time is not sold to other users.

12 is a flowchart of the steps of brokering a transaction of a betting ticket between users according to an embodiment of the present invention. In the following description, it is assumed that a second user wants to purchase a betting ticket requested by the first user for sale. The second user can check the exchange bulletin board screen described with reference to FIG. 10 through the second user terminal 20 and select a betting ticket to be purchased on the exchange bulletin board screen.

Step S41 is a step in which the second user terminal 20 receives a purchase request generated by the second user selecting any one bet ticket, and step S42 is a step in which the bet ticket purchase request is transmitted to the transaction brokerage server 100 It is a step.

Step S310 is a step in which the transaction intermediary server 100 determines whether a request to purchase a bet ticket registered on an exchange bulletin board is received from at least one user terminal among a plurality of user terminals. As a result of the determination through step S310, when a request to purchase a bet ticket is received, step S320 is performed. Otherwise, step S110 described with reference to FIG. 3 is performed. In this example, since it is assumed that the second user terminal 20 has requested the purchase of the bet ticket, step S320 may be performed.

Step S320 is a step in which the transaction intermediary server delivers (or transfers) the betting ticket of the first user to the account of the second user. That is, in step S320, the betting ticket is transferred from the first user's account to the second user's account.

In step S330, the transaction intermediary server 100 transmits transaction information on the transaction between the first user and the second user to the betting game server 30. The betting game server 30 may receive transaction information and determine to what amount the first user and the second user have purchased and sold a betting ticket, and the first user's holding amount through steps S51 and S52 In addition, a process of adding at least a portion (for example, at least a portion of the sale amount excluding a fee) to the sale amount of the bet ticket and a process of subtracting the sale amount of the bet ticket from the amount held by the second user may be performed.

In step S340, the transaction brokering server 100 completes the transaction of the bet ticket requested to be purchased from the second user terminal 20. Step S340 may be performed, for example, by deleting the betting ticket from being exposed on the exchange bulletin board or by adding an object indicating that the sale is completed.

13 to 15 are conceptual views for explaining a situation when a betting ticket is purchased from an exchange bulletin board among trading methods according to an embodiment of the present invention. Specifically, FIGS. 13 to 15 show examples of screens displayed through a user terminal when a user (eg, a second user) purchases a betting ticket registered on an exchange bulletin board. The screens described below may be generated by the transaction brokerage server and transmitted to the user terminal.

13 shows an example of an exchange bulletin board screen displayed through a user terminal. The exchange bulletin board screen includes a menu area (mr), a first information area (ir ₁ ), a second information area (ir ₂ ), a chat area (cr), a ticket information exposure area (tr), and a second search area (sr ₂ ). It may include at least some of. Description of each area constituting the exchange bulletin board screen was made with reference to FIG. 10, and thus, redundant description is omitted. In the following description, it is assumed that the second user checks the exchange bulletin board screen through the second user terminal and requests the purchase of the bet ticket using the information displayed on the exchange bulletin board screen.

As described with reference to FIG. 10, at least one betting ticket requested by a plurality of users is registered in the ticket information exposure area tr. In this example, the number of bet tickets is shown as three registered, but this is only an example, and various numbers of bet tickets such as 0, 1, 2, 4, or more are ticket information according to the number requested for sale. It may be exposed through the exposed area tr.

As described above, in the ticket information exposure area tr, each bet ticket can be classified and sorted by identification code, identification code, number of folders (for example, the number of betting games and the number of betting hits), total odds, and expected winning At least one item of amount, sale amount, time remaining, registration time, and hit information may be exposed. The second user checks information of various betting tickets displayed in the ticket information exposure area tr, and determines his / her criteria (for example, the number of betting hits, the number of betting games, the expected winning amount, the selling amount, the hitting total, etc.). Therefore, you can try to buy a betting ticket. Of course, the user can check the detailed betting history of each betting ticket through the input of the detailed information spread area (dr ₁ to dr ₃ ).

14 and 15 illustrate an example of an exchange bulletin board screen displayed on a user terminal when a user inputs a detailed information spread area dr ₁ of a first bet ticket among a plurality of bet tickets.

14 and 15, when a user requests to check detailed information about a betting ticket through the detail information spread area dr ₁ , detailed information of the betting ticket may appear below the information on the betting ticket selected by the user. have. For example, detailed information of the betting ticket may include information on the number of selected games, betting history, and odds of each betting game according to a user's bet for each betting game.

The user can check detailed information of the betting ticket and decide whether to purchase. When the user selects an object for purchasing a betting ticket, the user terminal may transmit information informing the transaction to the transaction brokerage server, and the transaction brokerage server transmits a message for confirming whether to purchase to the user terminal as shown in FIG. 15. can do. Thereafter, a process according to a request for purchasing a betting ticket may be performed according to a user's input.

As described with reference to FIGS. 3 to 15, the transaction intermediary server 100 according to an embodiment of the present invention may provide new content providing transactions between users to a betting game. As described above, betting games are highly likely to win only if they have a lot of knowledge about games, teams, and players due to their characteristics, and general users with low knowledge can lose interest immediately because of low probability of winning. In addition, even with a lot of knowledge, the general betting game alone can quickly lose interest due to the limitations of the content provided by the betting game.

On the other hand, the transaction intermediary server 100 according to an embodiment of the present invention provides an exchange bulletin board. The transaction intermediary server 100 according to an embodiment of the present invention checks the result information of the finished match when one match ends, and processes the bet tickets that cannot be won according to the result information, or cannot be processed on the exchange board or Information on the number of bet hits can be updated. Therefore, users can check the information on the number of betting tickets that are likely to win by comprehensively checking the number of betting hits, the total number of hits, etc. even if they do not know the detailed information about the game, team, etc. that are the target of the betting game through the exchange bulletin board. You can enjoy betting games. In addition, the bet ticket that is registered to be sold through the transaction intermediary server 100 according to an embodiment of the present invention can be traded between users up to the transaction closing time set based on the start time of the last game included in the bet ticket, so the seller And both buyers can trade with each other in various strategies. Therefore, it is possible to increase the interest of all users using the betting game due to the features and advantages described above.

In the above description, it was explained that the transaction is made with a fixed sales amount registered by the seller. However, this is only an example, and in another embodiment, the selling price of the betting ticket may be changed according to the number of betting games and the number of betting hits at the end of one of the plurality of games included in the betting ticket. As described above, the betting ticket may include betting results for a plurality of matches, and the value of the betting ticket varies greatly at the end of one match. This is because the value of the betting ticket increases or becomes 0, depending on whether the match is successful or not. Of course, if the user who registered the betting ticket can continuously manage the direct selling amount of the betting ticket during the betting transaction period, it is not a big deal, but this is not easy in reality. Therefore, in another embodiment, the transaction intermediary server 100 checks whether or not the matched bet is hit each time one match ends, and if the bet for the finished match fails, the corresponding bet ticket cannot be processed However, if the bet for the finished game is successful, the selling amount of the betting ticket may be increased based on the odds of the successful betting game or various other factors. As another method, various sales amounts may be input in advance according to the success or failure of the betting games included in the betting ticket from the user, and the selling amount of the betting ticket may be updated at the end of the betting game.

In addition, in the above description, it was explained that transactions between users are conducted through an exchange bulletin board. However, this is only an example, and the transaction intermediary server 100 according to an embodiment of the present invention may provide a direct transaction between two users according to a request between the first user and the second user. In the case of providing a direct transaction between the first user and the second user, the transaction brokerage server 100 may provide the transaction through the processes described above except for the registration process of the exchange bulletin board.

In addition, in another embodiment, the transaction intermediary server 100 may sell a betting ticket through an auction, in addition to a one-way selling method through an exchange bulletin board, and when receiving a discount request for a betting ticket from another user, You can also inform the seller of the discount by sending a note, a notification message, etc. Here, the discount request may be made through, for example, an object (eg, a discount request object) included in the ticket information exposure area tr in the exchange bulletin board.

According to an embodiment, an upper limit of a sales amount that a seller can input may be determined based on a seller's hit ratio. For example, the seller can basically enter the sales amount in consideration of the expected winning amount and the odds of the betting game that has not yet begun, but the upper limit of the amount that the seller can enter can be set to be larger as the seller with a higher hit rate. . Through this, a seller with a high hit rate can be provided with an incentive for the sales amount when selling a betting ticket.

16 is a block diagram of a transaction intermediary server 100 according to an embodiment of the present invention. The transaction intermediary server 100 according to an embodiment of the present invention may perform a function of providing a transaction of a betting ticket between a first user and a second user. To this end, the transaction intermediary server 100 according to an embodiment of the present invention may include a communication unit 110 and a control unit 120. In addition, the parts overlapping with those mentioned above will be omitted and described below.

The communication unit 110 functions to provide wired or wireless communication with the betting game server 30 and a plurality of user terminals. As described with reference to FIG. 1, the transaction intermediary server 100 according to an embodiment of the present invention may be implemented in one configuration with the betting game server 30. In this case, the communication unit 110 may provide communication between the plurality of user terminals and the transaction intermediary server 100.

The controller 120 functions to provide a transaction of betting tickets between the first user and the second user. Specifically, the controller 120 determines a betting ticket that can be sold by the first user according to the request for saleable ticket information received from the first user terminal 10, and transmits the determined information to the first user terminal 10 It can function. Here, the betting ticket determination may be made by classifying betting tickets based on whether the first judgment condition is satisfied among all the betting tickets held by the user. The process of determining the betting ticket has been described in detail with reference to FIGS. 3 and 4, and thus duplicate descriptions are omitted.

In addition, when receiving a request to sell any one bet ticket from the first user terminal 10, the control unit 120 sets a transaction closing time using the start time of the last match among the games included in the bet ticket, You can register betting tickets on the exchange board. As described above, the closing time of the transaction may be set according to the closing time of the transaction requested by the user, not the starting time of the last game.

In addition, the controller 120 may perform a management function of a betting ticket. For example, the controller 120 may update betting information or discard a betting ticket according to the result of the hit of a game that has ended, when one game ends. In addition, the control unit 120 may process the bet ticket as non-tradeable depending on whether or not the transaction closing time of the bet ticket has arrived, and when a request to purchase a bet ticket is received from another user (for example, the second user), the It is possible to broker a betting ticket transaction between the first user and the second user.

Since each function performed through the control unit 120 has been described in detail with reference to FIGS. 3 to 15, redundant description will be omitted.

The exemplary methods according to the present invention include program instructions executed by a processor, software modules, microcode, a computer program product recorded on a computer-readable recording medium (including all devices having an information processing function), Applications, logic circuits, custom semiconductors, or firmware can be implemented in a variety of ways. Examples of the computer-readable recording medium include, but are not limited to, ROM, RAM, CD, DVD, magnetic tape, hard disk, floppy disk, hard disk, and optical data storage device. In addition, the computer-readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The above description is merely illustrative of the present invention, and various modifications may be made without departing from the technical spirit of the present invention by those skilled in the art to which the present invention pertains.

100: transaction brokerage server 110: communication department
120: control unit

Claims (11)

As a method of brokering the transaction of the betting ticket between the first user and the second user,
Determining a betting ticket that satisfies a first determination condition from a group of betting tickets held by the first user at the control unit of the transaction brokering server;
The communication unit of the transaction brokerage server receives a request for sale of a betting ticket including betting information that the first user bets on one or more matches from a first user terminal, wherein the betting ticket satisfies the first judgment condition. Betting tickets;
Determining a start time of the last match among the one or more matches included in the betting ticket by the control unit;
Setting a transaction closing time based on a start time of the last game or a transaction end request time transmitted from the first user terminal in the control unit; And
When the transaction close time arrives, the control unit includes the step of determining that the betting ticket is impossible to trade,
The first judgment condition is satisfied when there is an unstarted match among one or more matches included in the betting information, and a difference between the current time and the start time of the unstarted match exceeds the first judgment period. How to broker a transaction. delete According to claim 1,
Determining a betting ticket that satisfies the first determination condition,
Determining an unstarted match among the games included in the bet ticket based on the start time and the current time of the match included in each bet ticket in the bet ticket group; And
And setting a time before the first judgment period as a sellable time of the bet ticket from the start time of the unstarted match. According to claim 1,
Before the step of receiving a request to sell the bet ticket, further comprising providing a sales registration screen to the first user terminal,
The sales registration screen is a transaction brokering method characterized in that it includes a reserved ticket information area in which bet tickets satisfying the first judgment condition are listed among bet tickets held by the first user. According to claim 1,
Granting an identification code to the bet ticket when the sale request is approved; And
And registering the bet ticket on an exchange bulletin board based on the identification code. The method of claim 5,
When one of the at least one match included in the betting ticket is over, further comprising updating the betting information according to the result of the finished match,
The betting information is a transaction brokering method characterized in that it includes the number of betting games hit by the first user and the number of hitting bets hit by the first user. The method of claim 6,
When receiving an inquiry request for the exchange bulletin board from a second user terminal, further comprising providing an exchange bulletin board screen to the second user terminal,
The exchange bulletin board screen includes a ticket information exposure area, and the betting ticket is displayed together with the number of betting games and the number of betting hits in the ticket information exposure area. The method of claim 7,
The betting information further includes at least one of a betting history of a betting ticket, a betting amount, a selling amount, a dividend rate, a total odds ratio, a predicted winning amount, and a hit record of the first user, and at least some of the betting information is the ticket information Transaction brokering method characterized in that included in the exposed area. According to claim 1,
Determining whether or not the first user's bet is hit with respect to the finished match after any one of the at least one matches included in the betting ticket ends; And
And if the first user's bet on the finished game fails to hit, the betting ticket further comprises determining that the transaction is impossible. According to claim 1,
When receiving a purchase request for the bet ticket before the transaction closing time from the second user terminal of the second user,
Transferring the betting ticket to the account of the second user; And
And subtracting the sale amount of the bet ticket from the amount held by the second user. A transaction intermediary server including a control unit for performing a transaction intermediary method according to any one of claims 1 and 3 to 10.

Images