Bidding support methods

Abstract

We provide a bidding support method that allows the number of items to be sold to be determined based on the bidding status of the product sale. [Solution] A method for supporting bidding for the sale of goods, wherein the control unit of a server terminal receives input data such as the bid amount and the number of items to be purchased from the bidder terminals of multiple bidders for a bidding project by the organizer, and determines the number of items to be sold for the bidding project after the start of the bidding project.

Description

Technical Field

[0005] , ,

[0001] The present invention relates to a method for assisting bidding.

Background Art

[0002] Conventionally, as an auction for multiple homogeneous assets, the auction of national bonds can be cited.

[0003] In the auction of national bonds, as disclosed in Non-Patent Document 1, for the amounts bid by bidders, winning bids are determined in descending order from the highest price. The number of national bonds to be sold is determined in advance by the organizer.

Prior Art Documents

Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] The technology disclosed in Non-Patent Document 1 concerns the auction of government bonds. Goods that are typically sold in multiple quantities, such as government bonds, are called homogeneous multiple goods. For example, in the case of government bonds, this would involve selling 10,000 identical bonds with a face value of 100 million yen each. Besides government bonds, homogeneous multiple goods include financial products such as newly listed stocks sold in IPOs and security tokens, as well as electronic assets such as crypto assets, NFTs (non-fungible tokens), and digital cards. It is expected that the demand for services that support the online auction sale of homogeneous multiple goods will increase in the future. Furthermore, organizers (operators) who plan auction projects for the sale of goods will find that, among the various goods they sell, products issued only in electronic form differ significantly from physical goods in that they can be copied countless times almost free of charge, allowing for flexible setting of the number of units to be sold. For products where the number of units to be sold can be flexibly set, it is expected that there will be many situations where they want to decide the number of units to be sold after the auction has started. Furthermore, such situations are not limited to products issued only in electronic form; they can also occur with physical products in order to create rare and limited-edition items.

[0006] Therefore, in view of the above problems and needs, the present invention provides a bidding support method that can determine the number of units to be sold according to the bidding status after the start of bidding for the sale of goods. [Means for solving the problem]

[0007] A method for supporting bidding for the sale of goods according to one aspect of the present invention, wherein the control unit of a server terminal receives input data from the bidder terminals of multiple bidders for a bidding project by the organizer, such as who entered how much they bid and how many units they wish to purchase, and after the start of bidding for the bidding project, determines the number of units to be sold for the bidding project. [Effects of the Invention]

[0008] According to the present invention, a bidding support method is provided that can determine the number of items to be sold according to the bidding status after the start of bidding for the sale of goods. Here, the bidding status refers to all or part of the data acquired by the organizer after the start of bidding, such as the input data and the time when that input data was entered or updated. At some point after the start of bidding, the sales quantity determination rule determines the number of items to be sold according to the bidding status. The details or outline of the sales quantity determination rule are usually made public to the bidders in advance by the organizer. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram showing a system for supporting bidding in the sale of goods according to the first embodiment of the present invention. [Figure 2] Figure 1 is a functional block diagram showing the server terminal 100. [Figure 3] Figure 1 is a functional block diagram showing the organizer terminal 200 for the bidding project. [Figure 4] This figure shows an example of bidding data stored on server terminal 100. [Figure 5] This flowchart shows an example of a bidding support method according to the first embodiment of the present invention. [Figure 6] This figure shows an example of bid data received from bidders and stored on server terminal 100. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described below with reference to the drawings. The embodiments described below are not intended to unduly limit the scope of the present invention as described in the claims. Furthermore, not all components shown in the embodiments are necessarily essential components of the present invention.

[0011] <Structure> Figure 1 is a block diagram showing a system for implementing a method for supporting bidding in the sale of goods according to the first embodiment of the present invention. This system 1 consists of, for example, a server terminal 100 that manages one or more bidding cases and supports the bidding process for each bidding case, an organizer terminal 200 for the organizer of the bidding case that plans the bidding case, and bidder terminals 300 for bidders who submit bids for the bidding case. For the sake of explanation, each terminal is described as a single or specific number, but there is no limit to the number of each.

[0012] The server terminal 100, the organizer terminal 200, and the bidder terminal 300 are each connected via network NW1. Network NW consists of the Internet, intranet, wireless LAN (Local Area Network), WAN (Wide Area Network), etc.

[0013] The server terminal 100 may be a general-purpose computer such as a workstation or personal computer, or it may be logically implemented through cloud computing.

[0014] The organizer's terminal 200 and the bidder's terminal 300 are, for example, information processing devices such as personal computers and tablet terminals, but may also be composed of smartphones, mobile phones, PDAs, etc.

[0015] In this embodiment, System 1 is described as comprising a server terminal 100, an organizer 200, and a bidder terminal 300, with each terminal's user performing operations on the server terminal 100 using their respective terminal. However, the server terminal 100 may be configured as a standalone unit, and the server terminal itself may be equipped with a function that allows each organizer to perform direct operations.

[0016] Figure 2 is a functional block diagram of the server terminal 100 shown in Figure 1. The server terminal 100 comprises a communication unit 110, a storage unit 120, and a control unit 130.

[0017] The communication unit 110 is a communication interface for communicating with the organizer terminal 200 and the bidder terminal 300 via the network NW1, and communication is performed according to a communication protocol such as TCP / IP (Transmission Control Protocol / Internet Protocol).

[0018] The storage unit 120 stores programs for executing various control processes and each function in the control unit 130, input data, etc., and is composed of a RAM (Random Access Memory), a ROM (Read Only Memory), etc. Further, the storage unit 120 has a bid data storage unit 121 for storing various data related to the bidding item. Note that a database (not shown) storing various data may be constructed outside the storage unit 120 or the server terminal 100.

[0019] The control unit 130 controls the overall operation of the server terminal 100 by executing the programs stored in the storage unit 120, and is composed of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), etc. As functions of the control unit 130, it has an information reception unit 131 for receiving instructions and information from each terminal, and an information processing unit 132 for referring to and processing various data related to the bidding item. The information reception unit 131 and the information processing unit 132 are activated by the programs stored in the storage unit 120 and executed by the server terminal 100 which is a computer (electronic computer).

[0020] The information reception unit 131 receives information from the organizer terminal 200, the bidder terminal 300, etc. via the communication unit 110. For example, it receives information regarding the conditions of the bidding item input by the organizer from the organizer terminal 200.

[0021] The information processing unit 132 refers to various data related to the bidding item (for example, the bid data 1000 described later) and performs predetermined processing.

[0022] Furthermore, the control unit 130 may also have a screen generation unit, which generates screen information to be displayed via the user interface of the organizer terminal 200 or the bidder terminal 300 as needed. For example, using image and text data (not shown) stored in the storage unit 120 as material, the user interface is generated by arranging various images and text in predetermined areas of the user interface according to predetermined layout rules. Processing related to the image generation unit can also be performed by a GPU (Graphics Processing Unit).

[0023] Figure 3 is a functional block diagram showing the organizer terminal 200 in Figure 1. The organizer terminal 200 comprises a communication unit 210, a display and operation unit 220, a storage unit 230, and a control unit 240.

[0024] The communication unit 210 is a communication interface for communicating with the server terminal 100 via the network NW, and communication is performed using a communication protocol such as TCP / IP.

[0025] The display operation unit 220 is a user interface used to display text, images, etc., in response to user input and input data from the control unit 240. If the organizer terminal 200 is a personal computer, it consists of a display and a keyboard or mouse; if the organizer terminal 200 is a smartphone or tablet, it consists of a touch panel, etc. This display operation unit 220 is activated by a control program stored in the storage unit 230 and executed by the organizer terminal 200, which is a computer (electronic calculator).

[0026] The memory unit 230 stores programs for executing various control processes and functions within the control unit 240, input data, etc., and is composed of RAM, ROM, etc. The memory unit 230 also temporarily or continuously stores the contents of communication with the server terminal 100.

[0027] The control unit 240 controls the overall operation of the organizer terminal 200 by executing programs stored in the memory unit 230, and is composed of a CPU, GPU, etc.

[0028] Furthermore, the bidder terminal 300 can have essentially the same configuration as the organizer terminal 200, so we will omit the explanation.

[0029] Figure 4 shows an example of bidding data stored in the server terminal 100.

[0030] The bidding data 1000 shown in Figure 4 stores various data related to bidding. In Figure 4, for the sake of explanation, an example of one bidding project (for example, a bidding project identified by bidding ID "10001" corresponding to a financial product sold by Company X) is shown, but information for multiple projects can be stored. Various data related to bidding may include, but are not limited to, basic data about the bidding project (for example, project name, organizer data such as organizer ID and industry, product data such as product name and product description), bidding period rules, price determination rules (each successful bidder's payment per unit shall be the bid amount, each successful bidder's payment per unit shall be the minimum successful bid price, etc.), sales quantity determination rules, payment upper limit, payment lower limit, target revenue amount, etc.), and bidding transaction data (bidder, bid amount, quantity, bidding date and time, successful bidder's bid amount, successful bidder, payment amount, etc.). Furthermore, the bidding data 1000 may also include analytical data (organizer data, highest successful bid price, lowest successful bid price, highest unsuccessful bid price, nature of successful bid amount, nature of successful bidder's bidding timing, nature of all bids, target revenue achievement rate, etc.) that is analyzed based on bidding data for each project, organizer, industry, product category, etc.

[0031] <Processing flow> Referring to Figure 5, the processing flow of the bidding support method executed by System 1 of this embodiment will be described. Figure 6 is a flowchart showing an example of a bidding support method according to the first embodiment of the present invention.

[0032] First, the organizer planning the bidding project accesses the server terminal 100 via a browser or application installed on the organizer terminal 200. When using the service for the first time, the organizer registers their name (corporate, organization name), address, attributes (company, individual, general incorporated association, government / local government, etc.), industry, number of employees, contact person's name, etc., and obtains a user ID (organizer ID) and password. For subsequent uses, the organizer logs into the service by entering the obtained user ID and password. The organizer then enters basic information (product name (e.g., financial product name), product description, etc.) via a designated screen displayed on the organizer terminal 200 to create the bidding project. The information receiving unit 131 of the control unit 130 of the server terminal 100 receives the entered basic information for the bidding project. The information processing unit 132 of the control unit 130 of the server terminal 100 stores the received basic information as bidding data 1000 in the bidding data storage unit 121 of the storage unit 120, thereby registering the project.

[0033] Here, the organizer selects the price determination rules and bidding period rules or parameters defining both rules for the bid project via the organizer terminal 200. The information processing unit 132 of the control unit 130 of the server terminal 100 then stores the input data related to the price determination rules and bidding period rules as data 1000 in the bidding data storage unit 121 of the storage unit 120 and performs registration. The price determination rules determine how much each bidder will ultimately pay. The bidding period rules define the settings for the bidding period, such as the period during which each bidder can place a bid, how much information each bidder can see about other bidders' bids and desired purchase quantities during the bidding period, and whether each bidder can change the bid amount or desired purchase quantity they entered during the bidding period.

[0034] Furthermore, when the organizer selects the sales quantity determination rule or the parameters defining it for a bid project via the organizer terminal 200, the information processing unit 132 of the control unit 130 of the server terminal 100 stores the input data related to the sales quantity determination rule as data 1000 in the bid data storage unit 121 of the storage unit 120 and performs registration. The rules for determining the number of units to be sold are as follows: The number of units to be sold will be determined according to the bidding situation.

[0035] As an example, consider the following rules for bidding period, price determination, and quantity to be sold. The bidding period rules stipulate that the bidding period is one week, and each bidder can see information on the total number of desired purchases at each price at any point during the bidding period. Each bidder can also update their bid amount and desired purchase quantity at any time during the bidding period. The price determination rule is that the price per unit of goods is set as the lowest bid amount at the end of the bidding period. The rule for determining the number of items to be sold is that it will be half of the total number of purchase requests 48 hours after the start of bidding, and the final number of items to be sold will be made public to bidders from that point onward. Let's assume there are currently four bidders, and 48 hours after the start of bidding, the bidding situation is as follows, as shown in Figure 6(a). 1) Bidder A has placed a bid of "1 item for 20 yen" (b_A=20, q_A=1). 2) Bidder B has placed a bid of "2 items for 13 yen" (b_B=13, q_B=2). *13 yen is the bid amount per item. The same applies below. 3) Bidder C has placed a bid of "2 items for 10 yen" (b_C=10, q_C=2). 4) Bidder D has placed a bid of "1 item for 10 yen" (b_D=10, q_D=1). Currently, there are 1 item requested for purchase at 20 yen, 2 items requested for purchase at 13 yen, and 3 items requested for purchase at 10 yen. According to the bidding rules, each bidder can see this information. Each bidder can update their bid amount and desired quantity as many times as they like during the bidding period. Currently, the total number of people wishing to purchase is 6 (1+2+2+1=6). According to the rules for determining the number of items to be sold, the number of items to be sold will be half of that, or 3. This number will be promptly announced to the bidders. Typically, once the number of units for sale is announced, it is expected that many bidders will update their bids or desired purchase quantities accordingly. Case 1) For simplicity, consider the case where no bidder updates their bid amount or desired quantity, and the bidding situation remains the same until the end of the bidding period. In this case, bidder A wins one item and bidder B wins two items, corresponding to the top three bids. The price determination rule is to set the price per item at the lowest bid amount, which is b_B = 13, the third highest bid amount. Bidder A will pay 13 yen x 1 item = 13 yen, and bidder B will pay 13 yen x 2 items = 26 yen. Case 2) Suppose that more than 48 hours after the start of bidding, bidder C updates their bid to "2 units for 14 yen," and then bidder B, seeing this, updates their bid to "1 unit for 16 yen," and then bidder C, seeing this, updates their bid to "2 units for 17 yen." And then, suppose no one updates their bids after that until the end of bidding. Then, as shown in Figure 6(a), the bidding situation at the end of bidding will be as follows. 1) Bidder A has placed a bid of "1 item for 20 yen" (b_A=20, q_A=1). 2) Bidder B has placed a bid of "1 unit for 16 yen" (b_B=16, q_B=1). 3) Bidder C has placed a bid of "2 items for 17 yen" (b_C=17, q_C=2). 4) Bidder D has placed a bid of "1 item for 10 yen" (b_D=10, q_D=1). As of 48 hours after the start of bidding, the number of items for sale has already been determined to be 3 according to the sales quantity determination rules. Of those 3 items, bidder A will win 1 and bidder C will win 2. According to the price determination rules, the minimum bid amount of 17 yen will be the price per item, so bidder A will pay 17 yen x 1 item = 17 yen, and bidder C will pay 17 yen x 2 items = 34 yen.

[0036] As another example, consider the following rules for determining the bidding period, price, and quantity sold. The bidding period rules stipulate that the bidding period is one week, and that each bidder cannot access any information regarding other bidders' bids at any point during the bidding period, nor can each bidder update their bid amount or desired quantity during the bidding period. The price determination rule is that the price per item is determined by the bid amount submitted by the winning bidder. The rules for determining the number of items to be sold are as follows: if the total number of desired purchases at the end of bidding is 8 or more, 3 items will be sold; if the total number of desired purchases is between 4 and 7, 2 items will be sold; and if the total number of desired purchases is between 1 and 3, 1 item will be sold. After the bidding period ends, the bidding status is as follows: 1) Bidder A has placed a bid of "1 item for 20 yen" (b_A=20, q_A=1). 2) Bidder B has placed a bid of "2 items for 13 yen" (b_B=13, q_B=2). 3) Bidder C has placed a bid of "2 items for 10 yen" (b_C=10, q_c=2). 4) Bidder D has placed a bid of "1 item for 10 yen" (b_D=10, q_D=1). Due to the bidding period rules, each bidder makes these bids within the bidding period without knowing the bid amounts or desired purchase quantities of other bidders. After the bidding period ends, the total number of desired purchases is 6 (1+2+2+1=6), which is in the range of 4 to 7. According to the rules for determining the number of items sold, 2 items will be sold. Bidder A wins 1 item, and bidder B also wins 1 item. According to the price determination rules, bidder A will pay 20 yen and bidder B will pay 13 yen.

[0037] The information processing unit 132 of the control unit 130 of the server terminal 100 transmits the data related to the registered bidding project, including the bidding period rules, sales quantity determination rules, and price determination rules, to multiple bidder terminals 300, thereby making the details of the bidding project public.

[0038] Then, as part of the processing in step S101, the information receiving unit 131 of the control unit 130 of the server terminal 100 receives data regarding the bid amount and desired purchase quantity entered by bidders from multiple bidder terminals 300 via the communication unit 110. The information processing unit 132 of the control unit 130 of the server terminal 100 stores the received input data regarding the bid amount and desired purchase quantity as bid data 1000 in the bid data storage unit 121 of the storage unit 120. Depending on the setting of the bidding period rules, bidders can update their bid amount and desired purchase quantity within the bidding period. Paragraph 0035 above is an example of this.

[0039] In this embodiment, the number of units to be sold is usually undetermined until a certain point after the start of the bidding period. Then, at an arbitrary time, the number of units to be sold is determined. This arbitrary time can be a certain point in the bidding period, the end of the bidding period, or it can be a point when various variables such as the number of bidders or the total number of units desired for purchase exceed a certain number.

[0040] In other words, as part of step S102, the information processing unit 132 determines whether or not to set the number of units to be sold within the bidding period. Here, as described above, the information processing unit 132 can determine the number of units to be sold based on the sales quantity determination rules. Alternatively, the organizer can send input data to set the number of units to be sold to the server terminal 100 via the organizer's terminal.

[0041] Next, as part of step S103, the information processing unit 132 determines the number of units to be sold based on the sales quantity determination rule described above, and stores the determined number of units in the bidding data storage unit 121 of the storage unit 120. Alternatively, the information processing unit 132 may also store the data regarding the determined number of units to be sold, received from the organizer terminal 200, in the bidding data storage unit 121 of the storage unit 120. As a result, at the end of the bidding, the output value of the number of units to be sold will be the determined number of units to be sold, and the organizer will sell the goods to one or more bidders based on the determined number of units to be sold.

[0042] In this embodiment, the organizer can determine the number of items to be sold according to the bidding situation. For physical goods such as books and clothing, increasing the sales volume incurs additional production costs. On the other hand, for electronic goods such as digital cards, ebooks, and branded clothing for avatars in cyberspace, increasing the sales volume incurs virtually no additional production costs. Therefore, those who sell electronic goods have a high degree of freedom in deciding how many of their goods to sell, and this decision is also highly important. This decision presents a dilemma: if the quantity sold is too low, sales will be low and profits will be low, but if the quantity sold is too high, the scarcity will decrease and profits will also be low. Furthermore, it is very difficult for sellers to decide how many to sell before the bidding begins, because they do not know the demand situation for the product. However, once the bidding is conducted, the demand situation can be understood from the bidding results. Being able to decide on the quantity to sell based on this understanding has high economic value.

[0043] Although embodiments of the invention have been described above, these can be implemented in various other forms, and can be carried out by various omissions, substitutions, and modifications. These embodiments and variations, as well as those with omissions, substitutions, and modifications, are included within the technical scope of the claims and their equivalents. [Explanation of Symbols]

[0044] 1 System: 100 Server terminal, 110 Communication unit, 120 Storage unit, 130 Control unit, 200 Organizer terminal, 300 Bidder terminal, NW1 Network

Claims

1. A method to support bidding for the sale of goods, The control unit of the server terminal is: The organizer's terminal, which is responsible for planning the bidding project, receives input data related to the bidding project and input data related to the rules for determining the number of units to be sold according to the bidding status. The received data relating to the bidding project and the data relating to the sales quantity determination rules are stored in the storage unit of the server terminal. For the aforementioned bidding project, the system receives bidding data, including the bid amount and the desired purchase quantity, from the bidder terminals of multiple bidders, and stores the received bidding data in the storage unit. A method for determining the number of units to be sold for a bid project after the start of bidding for the bid project, based on the bidding status based on the bidding data stored in the memory unit and the sales quantity determination rule.

2. The method according to claim 1, The control unit receives input data from the organizer's terminal regarding the bidding period rules and price determination rules for the bidding project. A method for storing the received data relating to the bidding period rules and the price determination rules in the storage unit, in association with the data relating to the bidding project.

3. The method according to claim 2, A method in which the control unit discloses the bidding item, the bidding period rules, the price determination rules, and the sales quantity determination rules, or a part thereof, to the bidder terminals of the multiple bidders.

4. The method according to claim 1, The aforementioned product is a digital content, method.

5. The method according to claim 1, The aforementioned product is an NFT (Non-Fungible Token), according to this method.

6. The method according to claim 1, The aforementioned product is a financial product, or a method.

7. The method according to claim 1, The aforementioned product is a cryptocurrency, or a method.

Images