Commodity exchange system, commodity exchange method, and commodity exchange program

JP2025161939A5Pending Publication Date: 2026-04-06NERAI CO LTD +2
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-08-26
Publication Date
2026-04-06

AI Technical Summary

Technical Problem

Conventional electronic trading systems do not facilitate direct transactions between producers and buyers of industrial products.

Method used

A commodity trading system that includes a receiving means for purchase and sale requests, a determining means to match these requests considering shipping costs, and a management of accounts for buyers and suppliers, enabling direct trading with a platform that temporarily holds requests and collects usage fees.

Benefits of technology

Enables direct trading between producers and buyers, ensuring reliable delivery and efficient transaction management through matching and settlement processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

To provide a platform which also enables a direct commodity exchange between a producer and a purchaser.SOLUTION: Provided is a commodity exchange system for performing a commodity exchange between the purchaser and a supplier. The commodity exchange system includes: first receiving means which receives, from the purchaser, a purchase request including a desired purchase price of a specific commodity; second receiving means which receives a sales request including a desired sales price of the specific commodity from the supplier; and determination means which, after a delivery cost for delivering the specific commodity from the supplier to the purchaser is reflected, determines whether the purchase request matches the sales request.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to a commodity trading system, a commodity trading method, and a commodity trading program for conducting commodity trading between a buyer and a supplier. [Background technology]

[0002] In conventional distribution systems, products are delivered from producers to buyers via retailers. In contrast to such distribution systems, for example, Japanese Patent Laid-Open Publication No. 2019-128814 (Patent Document 1) discloses an electronic trading system that can revitalize the market. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-128814 Summary of the Invention [Problem to be solved by the invention]

[0004] The electronic trading system disclosed in the above-mentioned Patent Document 1 supports the buying and selling of goods between buyers and sellers, but does not realize direct transactions, for example, between producers of industrial products and buyers of those industrial products.

[0005] The present disclosure aims to provide a platform that also enables direct trading of goods between producers and buyers. [Means for solving the problem]

[0006] According to one aspect of the present disclosure, there is provided a commodity trading system for conducting commodity trading between a buyer and a supplier, the commodity trading system including a first receiving means for receiving a purchase request from a buyer including a desired purchase price of a specific commodity, a second receiving means for receiving a sale request from a supplier including a desired sale price of the specific commodity, and a determining means for determining whether the purchase request and the sale request match, taking into account a shipping cost for shipping the specific commodity from the supplier to the buyer.

[0007] The commodity trading system may further include a request queue for temporarily holding one or more purchase requests and one or more sale requests. The determining means may determine whether a purchase request and a sale request match when a purchase request or a sale request is added to the request queue or when a purchase request or a sale request held in the request queue is changed.

[0008] The commodity trading system may further include a calculation means for calculating a shipping cost for shipping a particular commodity based on a shipping cost definition associated with the supplier or the particular commodity and the distance between the buyer and the supplier.

[0009] The commodity trading system may further include accounts for managing economic value held by each of the buyer and the supplier. The first accepting means may reserve a value determined based on the desired purchase price included in the purchase request from the corresponding buyer's account.

[0010] The commodity trading system may further include means for collecting a usage fee from the account of the buyer corresponding to the purchase request when a commodity transaction based on the matched purchase request and sale request is completed.

[0011] According to another aspect of the present disclosure, there is provided a commodity trading method in which a computer executes a commodity trading between a buyer and a supplier, the commodity trading method including the steps of: receiving a purchase request from the buyer, the purchase request including a desired purchase price for a specific commodity; receiving a sale request from the supplier, the sale request including a desired sale price for the specific commodity; and determining whether the purchase request and the sale request match, taking into account a shipping cost for shipping the specific commodity from the supplier to the buyer.

[0012] According to yet another aspect of the present disclosure, there is provided a commodity trading program for causing a computer to execute a commodity trading between a buyer and a supplier, the commodity trading program causing the computer to execute the steps of: receiving a purchase request from a buyer, the purchase request including a desired purchase price for a specific commodity; receiving a sale request from a supplier, the sale request including a desired sale price for the specific commodity; and determining whether the purchase request and the sale request match, taking into account a shipping cost for shipping the specific commodity from the supplier to the buyer. [Effects of the Invention]

[0013] According to the present disclosure, a platform can be realized that also enables direct trading of goods between producers and buyers. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 2 is a diagram illustrating an overview of processing in the commodity trading system according to the present embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a processing procedure in the commodity trading system according to the present embodiment. [Figure 3] FIG. 2 is a schematic diagram showing an example of a configuration of an operating server that constitutes the commodity trading system according to the present embodiment. [Figure 4] FIG. 2 is a schematic diagram showing a main part of a matching process in the commodity trading system according to the present embodiment. [Figure 5]FIG. 2 is a schematic diagram showing an example of a user interface screen provided on a buyer's terminal that constitutes the commodity trading system according to the present embodiment. [Figure 6] FIG. 2 is a schematic diagram showing an example of a user interface screen provided on a terminal of a supplier that constitutes the commodity trading system according to the present embodiment. [Figure 7] FIG. 2 is a schematic diagram showing an example of a user interface screen provided on a buyer's terminal that constitutes the commodity trading system according to the present embodiment. [Figure 8] FIG. 2 is a diagram illustrating a method for managing information about buyers by the operation server of the commodity trading system according to the present embodiment. [Figure 9] 10 is a diagram illustrating a method for managing information about suppliers by the operation server of the commodity trading system according to the present embodiment. FIG. [Figure 10] FIG. 2 is a diagram showing an example of a delivery fee definition used in the commodity trading system according to the present embodiment. [Figure 11] FIG. 10 is a diagram showing another example of a delivery fee definition used in the commodity trading system according to the present embodiment. [Figure 12] 10 is a flowchart showing a processing procedure in a management server of the commodity trading system according to the present embodiment. [Figure 13] 10 is a flowchart showing a processing procedure in a management server of the commodity trading system according to the present embodiment. [Figure 14] FIG. 10 is a schematic diagram showing another example of a user interface screen provided on a buyer's terminal that constitutes the commodity trading system according to the present embodiment. [Figure 15] FIG. 10 is a schematic diagram showing another example of a user interface screen provided on a supplier terminal that constitutes the commodity trading system according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] Embodiments according to the present disclosure will be described in detail with reference to the drawings. For the same or corresponding parts in the drawings, the same reference numerals are given and their descriptions are not repeated.

[0016] <A. Product Trading System 1> First, the product trading system 1 according to this embodiment will be described. The product trading system 1 provides a platform that enables direct product trading between producers and buyers.

[0017] FIG. 1 is a diagram for explaining the outline of processing in the product trading system 1 according to this embodiment. Referring to FIG. 1, the product trading system 1 includes an operation server 100 that can be accessed by any one or more buyers 10 who wish to purchase any product and any one or more suppliers 20 who wish to offer any product. That is, the product trading system 1 electronically conducts product trading between the buyers 10 and the suppliers 20.

[0018] Each of the buyers 10 transmits a purchase request 12 including information for specifying any product and quantity desired to be purchased, as well as the desired purchase price, to the operation server 100. Also, each of the suppliers 20 transmits a sales request 22 including information for specifying any product and quantity desired to be sold, as well as the desired sales price, to the operation server 100.

[0019] The operation server 100 compares the purchase requests 12 from one or more buyers 10 with the sales requests 22 from one or more suppliers 20, and determines whether the purchase requests 12 and the sales requests 22 match (hereinafter, also referred to as "matching processing"). When the purchase request 12 and the sales request 22 match, it is determined that the transaction is established.

[0020] The operation server 100 notifies the supplier 20 corresponding to the sales request 22 for which the transaction is determined to be established that the transaction is established, and delivers the product that is the subject of the transaction to the buyer 10. Regarding the delivery of the product, the supplier 20 itself may perform it, but typically, any delivery person 30 may perform it.

[0021] The management server 100 is also responsible for the settlement process between the buyer 10 and the supplier 20, as will be described later.

[0022] There are no particular restrictions on the products that can be handled by the product trading system 1, but products that are expected to be purchased repeatedly, such as daily necessities and consumables, are suitable.

[0023] The buyer 10 is typically assumed to be an individual who will ultimately use the product in question, but is not limited to this and may also be, for example, a store or business that plans to use the product on an ongoing basis. Furthermore, the buyer 10 may also be a computer or a device with computing capabilities. In this way, the buyer 10 is a concept that encompasses any entity that is capable of making some kind of decision regarding the transaction of the product.

[0024] The supplier 20 may be any entity capable of providing any product, but is typically a producer or importer of any product. Alternatively, the supplier 20 may be a logistics company that stores or manages any product. Furthermore, the supplier 20 may be a computer or a device with computing capabilities. In this way, the supplier 20, like the buyer 10, is a concept that encompasses any entity that is capable of making decisions regarding the transaction of products.

[0025] In this way, the commodity trading system 1 according to the present embodiment provides a platform that enables direct commodity trading between producers and buyers, something that has not existed in conventional business models.

[0026] 2 is a diagram illustrating an example of a processing procedure in commodity trading system 1 according to the present embodiment. Fig. 2 shows an example of processing when buyer 10 orders a specific commodity, a transaction is concluded with any supplier 20, and the commodity is provided by that supplier 20.

[0027] 2, when a buyer 10 performs an operation to order a specific product, a purchase request 12 is sent to the operation server 100 (step S1). The operation server 100 receives the purchase request 12 from the buyer 10, which includes the desired purchase price for the specific product. The operation server 100 then reserves, from the balance of the buyer 10, an amount of money to be purchased that is determined based on the desired purchase price and the desired number of items to be purchased that are included in the purchase request 12 from the buyer 10 (step S2).

[0028] On the other hand, when the supplier 20 performs an operation to sell a specific product, a sales request is sent to the operation server 100 (step S3). The operation server 100 receives a sales request 22 from the supplier 20, which includes a desired selling price for the specific product.

[0029] The management server 100 executes a matching process between the purchase requests 12 from the buyers 10 and the sales requests 22 from the suppliers 20 (step S4). In this matching process, when a transaction is concluded between the purchase request 12 from any buyer 10 and the sales request 22 from any supplier 20, the management server 100 transmits a notification of the transaction conclusion to each of the buyers 10 and the supplier 20 (step S5).

[0030] Upon receiving the notification that the transaction has been concluded, the supplier 20 ships the merchandise that is the subject of the transaction (step S6). In addition, upon shipping the merchandise that is the subject of the transaction, the supplier 20 transmits tracking information for tracking the shipped merchandise to the buyer 10 via the operation server 100. By sharing the tracking information among the buyer 10, the supplier 20, and the operation server 100, it is possible to guarantee that the merchandise will be delivered reliably.

[0031] When the buyer 10 receives the goods from the supplier 20 (step S7), the buyer 10 transmits a goods receipt notification to the operation server 100 (step S8). When the operation server 100 receives the goods receipt notification from the buyer 10, it deposits the planned purchase amount that it had reserved in advance into the account of the supplier 20 (step S9).

[0032] Through the processing procedure as described above, the transaction of goods in the goods trading system 1 is completed.

[0033] Hereinafter, the configuration, functions, and details of the processing of the goods trading system 1 according to the present embodiment will be described.

[0034] <B. Hardware Configuration> Next, an example of the hardware configuration of the goods trading system 1 according to the present embodiment will be described.

[0035] (b1: Operation Server 100) FIG. 3 is a schematic diagram showing a configuration example of the operation server 100 that constitutes the goods trading system 1 according to the present embodiment. Typically, the operation server 100 is realized using one or more general-purpose computers.

[0036] Referring to FIG. 3, the operation server 100 includes, as main components, one or more processors 101, a main memory 102, a communication interface 103, an input unit 104, a display 105, and a storage 110. These components are connected via an internal bus 106.

[0037] The processor 101 is composed of, for example, a CPU or a GPU (Graphics Processing Unit). A plurality of processors 101 may be arranged, or a processor 101 having a plurality of cores may be employed.

[0038] The main memory 102 is composed of a volatile storage device such as a DRAM (Dynamic Random Access Memory) or an SRAM (Static Random Access Memory). The storage 110 is composed of a non-volatile storage device such as a hard disk or an SSD (Solid State Drive), and the The storage 110 stores various programs and data to be executed by the processor 101. Of the programs stored in the storage 110, designated program code is loaded onto the main memory 102, and the processor 101 sequentially executes computer-readable instructions included in the program code loaded onto the main memory 102, thereby realizing various functions as will be described later.

[0039] Typically, the storage 110 stores a matching program 112 for implementing the matching process, a payment program 114 for implementing the payment process, a request queue 116, and user information 118 including various information about buyers 10 and suppliers 20. The request queue 116 temporarily holds one or more purchase requests 12 from one or more buyers 10 and one or more sale requests 22 from one or more suppliers 20.

[0040] The matching program 112 and the settlement program 114 correspond to a commodity trading program that causes a computer to execute a commodity trading between the buyer 10 and the supplier 20 .

[0041] The communication interface 103 is responsible for exchanging data with the terminals of the buyer 10 and the supplier 20. The communication interface 103 may include, for example, an Ethernet port to enable communication via the Internet.

[0042] The input unit 104 accepts any input instruction. The display 105 displays the processing results of the processor 101, etc.

[0043] All or part of the management server 100 is a hardwired device such as an ASIC (Application Specific Integrated Circuit) that incorporates a circuit corresponding to a computer-readable instruction. Alternatively, the implementation may be implemented using circuits corresponding to computer-readable instructions on a field-programmable gate array (FPGA). It may be realized by appropriately combining the processor 101, a main memory, an ASIC, an FPGA, etc.

[0044] The operation server 100 may further include a component for reading the matching program 112 and the settlement program 114, which are comprised of computer-readable instructions, from non-transitory media that stores the programs. The media may be, for example, optical media such as a digital versatile disc (DVD) or semiconductor media such as a USB memory.

[0045] The matching program 112 and the settlement program 114 are not only installed on the management server 100 via media, but also provided from a distribution server on the network. It may be possible to do so.

[0046] (b2: Terminals of buyer 10 and supplier 20) Buyers 10 and suppliers 20 can use any terminal to use the commodity trading system 1. The terminals used by buyers 10 and suppliers 20 include any information processing devices such as personal computers, smartphones, tablets, and mobile phones.

[0047] The functions provided to the buyer 10 and supplier 20 as described below may be realized by an application pre-installed on the terminal, or the user interface provided by the management server 100 may be used via the terminal's browser.

[0048] The various functions, including the user interfaces provided to the buyer 10 and the supplier 20, may be realized using any hardware and software configuration.

[0049] <C. Matching Process> Next, the matching process in the merchandise trading system 1 according to the present embodiment will be described.

[0050] (c1: Purchase Request 12 and Sale Request 22) In the merchandise trading system 1 according to the present embodiment, the matching process may be performed in consideration of the delivery cost required to deliver the merchandise from the supplier 20 to the buyer 10. That is, the operation server 100 of the merchandise trading system 1 determines whether the purchase request 12 and the sale request 22 match after reflecting the delivery cost for delivering a specific merchandise from the supplier 20 to the buyer 10. In considering this delivery cost, the distance between the buyer 10 and the supplier 20 may be taken into account.

[0051] FIG. 4 is a schematic diagram showing a main part of the matching process in the merchandise trading system 1 according to the present embodiment.

[0052] Referring to FIG. 4, the purchase request 12 from the buyer 10 includes a total purchase desired amount 121 including a desired purchase price 122 and a delivery cost 123, a desired purchase quantity 124, and delivery destination information 125. The purchase request 12 may further include a system usage fee 126. The system usage fee 126 is a usage fee when the buyer 10 uses the merchandise trading system 1. Typically, an amount obtained by multiplying a predetermined rate (for example, 1.0%) by the desired purchase price 122 or the total purchase desired amount 121 may be automatically calculated.

[0053] That is, when the merchandise transaction based on the matched purchase request 12 and sale request 22 is completed, the operation server 100 may collect the system usage fee 126 from the account of the buyer 10 corresponding to the purchase request 12.

[0054] The delivery fee 123 may be calculated for each product or may be calculated for multiple products at once. Also, the delivery address information 125 does not necessarily need to be included in the purchase request 12, and may be obtained from the user information 118 pre-stored in the operation server 100.

[0055] When a buyer 10 wishes to purchase a specific product, the buyer 10 specifies the desired purchase price 122 in addition to the desired purchase quantity 124, or specifies the desired purchase price 122 and total purchase amount 121 including delivery fee 123. In response to this, the terminal of the buyer 10 generates a purchase request 12 and transmits it to the operation server 100.

[0056] On the other hand, a sales request 22 from a supplier 20 includes a desired sales total amount 221 including a desired sales price 222 and a shipping cost 223, a desired sales quantity 224, and a shipping cost definition 225. In the sales request 22, the shipping cost 223 may be calculated from the shipping cost definition 225 based on the shipping destination information 125 of the buyer 10.

[0057] When a supplier 20 wishes to sell a specific product, the supplier 20 specifies a desired selling price 222 and a desired number of units 224. This causes the supplier's 20 terminal to generate a sales request 22 and transmit it to the management server 100. The management server 100 calculates or evaluates a delivery fee 223 in the sales request 22 for each potential buyer 10.

[0058] The management server 100 compares the total desired purchase amount 121 of the purchase request 12 from one or more buyers 10 with the total desired sales amount 221 of the sales request 22 from one or more suppliers 20 to determine whether their conditions match (match). Alternatively, the management server 100 compares the desired purchase price 122 of the purchase request 12 from one or more buyers 10 with the desired sales price 222 of the sales request 22 from one or more suppliers 20 to determine whether their conditions match (match).

[0059] In the matching process, the transaction may be concluded under favorable conditions for one party, provided that the other party is not placed under unfavorable conditions. For example, suppose that the buyer 10 sets the desired purchase price 122 of a certain product to "100 yen," and the supplier 20 sets the desired selling price 222 of the product to "90 yen." In this case, the desired purchase price 122 desired by the buyer 10 may be changed to "90 yen," and the transaction may be concluded. In this case, the buyer 10 can purchase the product at "10 yen" cheaper than the desired purchase price 122, resulting in a transaction under favorable conditions.

[0060] Conversely, the supplier 20 may change the desired selling price 222 to "100 yen" and then decide to conclude the transaction. In this case, the supplier 20 can purchase the product at "10 yen" cheaper than the desired selling price 222, so the transaction will be on advantageous terms.

[0061] Furthermore, the buyer 10 may change the desired purchase price 122 to "95 yen" and the supplier 20 may change the desired selling price 222 to "95 yen" before deciding to conclude the transaction. In this case, the transaction will be on more favorable terms than initially agreed upon for both the buyer 10 and the supplier 20.

[0062] Furthermore, a transaction may be concluded even if only some of the conditions for the quantity are met, or if all of the conditions for the quantity are not met. For example, if the desired purchase quantity 124 in the purchase request 12 is less than the desired sale quantity 224 in the sale request 22, the buyer 10 can purchase only a portion of the number of items specified in the desired purchase quantity 124. If the buyer 10 allows it, a transaction may be concluded for only a portion of such a specified number.

[0063] (c2: User interface screen) Next, an example of a user interface screen provided in commodity trading system 1 according to the present embodiment will be described.

[0064] 5 is a schematic diagram showing an example of a user interface screen 300 provided on a terminal of a buyer 10 constituting the commodity trading system 1 according to the present embodiment. Referring to FIG. 5, the user interface screen 300 accepts instructions from the buyer 10 for generating a purchase request 12.

[0065] More specifically, the user interface screen 300 displays the items that the buyer 10 wishes to purchase. It includes a product display section 302 that displays an image of the product, a search button 304 for searching for the product desired to be purchased, and a code reading button 306 for reading identification information for specifying the product desired to be purchased.

[0066] The buyer 10 can search for the product they wish to purchase by selecting the search button 304 and entering the product name or a code that identifies the product. Alternatively, the buyer 10 can select the code reading button 306 and specify the product they wish to purchase by reading the barcode or QR code (registered trademark) attached to the product using a camera or the like installed in the terminal.

[0067] In this way, an image showing the searched or specified product is displayed in the product display section 302 .

[0068] A database for managing products may be provided inside or outside the operation server 100 in order to search for products based on product names or identification information, and to search for product images.

[0069] When the buyer 10 specifies the product he / she wishes to purchase, he / she inputs the desired purchase price and the desired purchase quantity. More specifically, the user interface screen 300 includes a quantity input box 310 and a price input box 314.

[0070] The buyer 10 inputs the number of items he / she wishes to purchase in the quantity input box 310 and the desired purchase price in the price input box 314 .

[0071] Depending on the selection state of the unit selection radio button 312 for selecting either individual units (1 unit) or case units, the desired purchase quantity entered in the quantity input box 310 is set to either individual units or case units.

[0072] Depending on the selection state of delivery cost selection radio button 316, which selects whether delivery cost is included or not, the desired purchase price entered in price input box 314 is set to either a price including delivery cost or a price not including delivery cost. If delivery cost selection radio button 316 is selected as including delivery cost, the price entered in price input box 314 means the desired total purchase amount 121, and if delivery cost selection radio button 316 is selected as not including delivery cost, the price entered in price input box 314 means the desired purchase price 122.

[0073] Furthermore, user interface screen 300 includes check button 318 for setting whether or not to process the transaction as concluded for only the number of items that meet the conditions when the conditions are met for only a portion of the desired purchase quantity. Selecting check button 318 allows the transaction to be concluded for only a portion of the desired purchase quantity.

[0074] A purchase request 12 is generated via a user interface screen 300 such as that shown in FIG.

[0075] 6 is a schematic diagram showing an example of a user interface screen provided on a terminal of a supplier 20 constituting the commodity trading system 1 according to the present embodiment. Referring to FIG. 6, a user interface screen 400 receives instructions from a supplier 20 for generating a sales request 22.

[0076] More specifically, user interface screen 400 displays the products available for sale by supplier 20. The list 402 includes a product code column 404 indicating a product code for identifying each product that the supplier 20 can sell, a product name column 406 indicating the product name of each product, a selling price column 408 indicating the desired selling price of each product, a sales quantity column 410 indicating the desired number of units of each product, a remaining number column 412 indicating the number of units of each product that have not yet been traded, and a partial transaction column 414 for setting whether, when conditions are met for only a portion of the desired number of units, a transaction is to be concluded for only the number of units that meet the conditions.

[0077] The supplier 20 registers the products available for sale in the list 402 and inputs the desired selling price (selling price column 408) and the desired selling price (selling quantity column 410) for each product.

[0078] The supplier 20 can select the search button 416 and enter the product name or a code that identifies the product to search for available products and register them in the list 402. Alternatively, the supplier 20 can select the code reading button 418 and register the available products in the list 402 by reading the barcode or QR code attached to the product that the supplier wishes to purchase using a camera or the like installed in the terminal.

[0079] The supplier 20 can select the change content button 420 to arbitrarily change the desired selling price (selling price column 408) and the desired selling price (sales quantity column 410) registered in the list 402. The changes made by the supplier 20 are reflected when the update button 422 is selected.

[0080] A sales request 22 is generated via a user interface screen 400 such as that shown in FIG.

[0081] 7 is a schematic diagram showing an example of a user interface screen 320 provided on the terminal of a buyer 10 constituting the commodity trading system 1 according to the present embodiment. Referring to FIG. 7, the user interface screen 320 shows the status of purchase requests 12 and sale requests 22 accepted by the operation server 100. More specifically, the user interface screen 320 includes a commodity display section 322 showing an image of the target commodity, and a status display section 330 showing the transaction status.

[0082] The status display section 330 includes a purchase request status display section 332 that displays the desired purchase price and desired purchase quantity according to the purchase requests 12 from one or more buyers 10, and a sales request status display section 334 that displays the desired sales price and desired sales quantity according to the sales requests 22 from one or more buyers 10. The status display section 330 displays the purchase requests 12 and sales requests 22 in a manner that allows them to be compared, and buyers 10 and suppliers 20 refer to the status display section 330 when generating new purchase requests 12 or sales requests 22 or when updating the contents of purchase requests 12 or sales requests 22 that have already been generated.

[0083] The status display portion 330 of the user interface screen 320 is typically generated based on the contents of the purchase requests 12 and sales requests 22 temporarily held in the request queue 116 (FIG. 3) of the operation server 100.

[0084] (c3: User management) Next, user management in the operation server 100 of the commodity trading system 1 will be described.

[0085] 8 is a diagram illustrating a method for managing information related to buyers 10 by operation server 100 of commodity trading system 1 according to the present embodiment. Referring to FIG. 8, operation server 100 has management information 150 for managing each of buyers 10.

[0086] The management information 150 includes delivery destination information 152 indicating the delivery destination (address or latitude and longitude) of the buyer 10. The delivery destination information 152 included in the management information 150 may be used as the delivery destination information 125 of the purchase request 12. However, the delivery destination information 125 of the purchase request 12 may be calculated using location information from a GPS (Global Positioning System) or the like installed in the terminal of the buyer 10. In this case, it is not necessary to include the delivery destination information 152 in the management information 150.

[0087] The management information 150 includes balance information 154 that indicates the balance of the account of the buyer 10. The balance information 154 embodies an account that manages the economic value held by each of the buyer 10 and the supplier 20. The economic value is assumed to be an amount in a specific currency, but it may also be something like virtual currency or unique points used in the commodity trading system 1.

[0088] When a buyer 10 generates a purchase request 12, the management server 100 reserves (reserves) the planned purchase amount determined based on the purchase request 12 from the corresponding balance information 154. In other words, the management server 100 reserves a value determined based on the desired purchase price included in the purchase request 12 from the account of the corresponding buyer 10.

[0089] The management information 150 includes a purchase history 156 that indicates transaction information of the buyer 10. The operation server 100 updates the contents of the purchase history 156 every time a transaction is concluded. Note that the operation server 100 may update the contents of a purchase request 12 in the balance information 154 every time the buyer 10 generates a purchase request 12.

[0090] 9 is a diagram illustrating a method for managing information related to suppliers 20 by operation server 100 of commodity trading system 1 according to the present embodiment. Referring to FIG. 9, operation server 100 has management information 250 for managing each of suppliers 20.

[0091] The management information 250 includes balance information 254 indicating the balance of the account of the supplier 20. When a transaction is concluded between any of the buyers 10 and the supplier 20, the operation server 100 adds the amount exchanged in the transaction to the corresponding balance information 254.

[0092] The management information 250 includes a sales history 256 that indicates transaction information of the supplier 20. The operation server 100 updates the contents of the sales history 256 every time a transaction is concluded.

[0093] The management server 100 uses management information 150 shown in FIG. 8 and management information 250 shown in FIG. 9 to manage information on the buyer 10 and the supplier 20 regarding the transaction.

[0094] (c4: Shipping cost calculation) Next, an example of a method for calculating delivery costs (delivery cost 123 included in purchase request 12 and delivery cost 223 included in sales request 22) will be described.

[0095] FIG. 10 is a diagram showing an example of delivery cost definition 226 used in product trading system 1 according to the present embodiment. Delivery cost definition 226 shown in FIG. 10 defines delivery costs for each product ("Product A" in the example of FIG. 10). In delivery cost definition 226, the distance between buyer 10 and supplier 20 is divided into categories (categories 1 to 5), and delivery costs are defined for each category. When calculation of delivery costs is required for purchase request 12 or sales request 22, the delivery costs are determined by referring to the delivery destination information of buyer 10 and delivery cost definition 226.

[0096] The shipping cost definition 226 shown in FIG. 10 is used as the shipping cost definition 225 of the sales request 22. This may also be done.

[0097] Figure 11 is a diagram showing another example of delivery cost definition 227 used in product trading system 1 according to the present embodiment. Delivery cost definition 227 shown in Figure 11 basically defines delivery costs for all products. In delivery cost definition 227, the distance between buyer 10 and supplier 20 is divided into categories (categories 1 to 5), and a delivery cost is defined for each category.

[0098] When a calculation of delivery costs is required for any product, the weight of each product is determined by referring to a weight table 228 showing the weight of each product, and the delivery costs are determined by applying the determined weight to a delivery cost definition 227.

[0099] 10 and 11 show an example in which the distance between the buyer 10 and the supplier 20 is divided into categories and the delivery cost is defined for each category, but this is not limiting and the delivery cost may be defined per unit distance (for example, 1 km). Furthermore, separate definitions of domestic and overseas delivery costs may be defined.

[0100] As described above, in the product trading system 1 according to this embodiment, the necessary shipping costs can be calculated by using the above-mentioned shipping cost definition. That is, the management server 100 may calculate the shipping cost for shipping a specific product based on the shipping cost definition associated with the supplier 20 or the specific product and the distance between the buyer 10 and the supplier 20.

[0101] (c5: Processing procedure) Next, an example of a processing procedure in the operation server 100 of the commodity trading system 1 will be described. Figures 12 and 13 are flowcharts showing the processing procedure in the operation server 100 of the commodity trading system 1 according to the present embodiment. Figures 12 and 13 show a commodity trading method in which a computer executes a commodity trade between a buyer 10 and a supplier 20.

[0102] The steps shown in FIGS. 12 and 13 are typically realized by the processor 101 of the management server 100 executing the matching program 112 and the settlement program 114 (corresponding to a commodity trading program).

[0103] 12 and 13, the management server 100 determines whether or not it has received a purchase request 12 from the terminal of the buyer 10 or a sale request 22 from the supplier 20 (step S100). If it has received a purchase request 12 from the terminal of the buyer 10 or a sale request 22 from the supplier 20 (YES in step S100), the management server 100 stores the received purchase request 12 or sale request 22 in the request queue 116 (step S102).

[0104] In this way, the management server 100 executes a process of receiving a purchase request 12 including a desired purchase price of a specific product from a buyer 10, and a process of receiving a sale request 22 including a desired selling price of a specific product from a supplier 20.

[0105] Next, the management server 100 determines whether the received request is a purchase request 12 (step S104). If the received request is a purchase request 12 (YES in step S104), the management server 100 determines whether the planned purchase amount, which is determined based on the desired purchase price and desired purchase quantity included in the received purchase request 12, exists in the account of the buyer 10 who sent the purchase request 12 (step S106).

[0106] If the planned purchase amount exists in the account of the buyer 10 (YES in step S106), the management server 100 reserves the planned purchase amount from the account of the buyer 10 (step S107). Then, the matching process from step S110 onwards is executed.

[0107] If the planned purchase amount does not exist in the account of the buyer 10 (NO in step S106), the operation server 100 does not execute the matching process from step S110 onwards. At this time, the operation server 100 may notify the terminal of the buyer 10 that the purchase request 12 cannot be generated.

[0108] If the received request is a sales request 22 (NO in step S104), the processes of steps S106 and S108 are skipped.

[0109] If the purchase request 12 from the terminal of the buyer 10 or the sales request 22 from the supplier 20 has not been received (NO in step S100), the management server 100 determines whether a change in the purchase request 12 from the terminal of the buyer 10 or a change in the sales request 22 from the supplier 20 has been received (step S109). If a change in the purchase request 12 from the terminal of the buyer 10 or a change in the sales request 22 from the supplier 20 has been received (YES in step S100), the matching process from step S110 onwards is executed.

[0110] If neither a change in purchase request 12 from the terminal of buyer 10 nor a change in sales request 22 from supplier 20 has been received (NO in step S100), the processing from step S100 onwards is repeated.

[0111] In this way, when a purchase request 12 or a sales request 22 is added to the request queue 116, or when a purchase request 12 or a sales request 22 held in the request queue 116 is changed, a process is performed to determine whether the purchase request 12 and the sales request 22 match.

[0112] If no change in purchase request 12 has been received from the terminal of buyer 10 and no change in sales request 22 has been received from supplier 20 (NO in step S100), the processing from step S100 onwards is repeated.

[0113] The operation server 100 determines whether the newly received or updated request is a purchase request 12 or a sale request 22 (step S110).

[0114] If the newly received or updated request is a purchase request 12 ("Purchase Request" in step S110), the management server 100 sets the newly received or updated purchase request 12 as a purchase request 12 to be matched (step S112), and selects one of the sales requests 22 stored in the request queue 116 as a matching candidate (step S114).

[0115] Next, the management server 100 determines whether or not it is necessary to calculate a delivery fee for the purchase request 12 to be matched or the sales request 22 to be matched (step S116). If it is necessary to calculate a delivery fee for the purchase request 12 to be matched or the sales request 22 to be matched (YES in step S116), the management server 100 determines the necessary delivery fee (delivery fee 123 or delivery fee 223) based on the information indicating the delivery destination of the buyer 10 (delivery destination information 125 or delivery destination information 152) and the information on the delivery fee (delivery fee definition 225 or delivery fee definition 226) (step S118).

[0116] In this way, the management server 100 determines whether the purchase request 12 and the sale request 22 match, taking into account the shipping costs for shipping a particular product from the supplier 20 to the buyer 10.

[0117] On the other hand, if it is not necessary to calculate the delivery cost for the matching target purchase request 12 or the matching candidate sales request 22 (NO in step S116), the process of step S118 is skipped.

[0118] The management server 100 then compares the matching target purchase request 12 with the matching candidate sales request 22 to determine whether or not their conditions match (step S120).

[0119] If the matching conditions of the purchase request 12 to be matched and the matching candidate sales request 22 are met (YES in step S120), the management server 100 determines that the transaction has been concluded, notifies the buyer 10 and supplier 20 corresponding to the purchase request 12 and sales request 22, respectively (step S122), and changes the status of the purchase request 12 and sales request 22 to awaiting delivery completion of the target product (step S124).Then, the matching process ends.

[0120] If the conditions of the purchase request 12 to be matched and the sales request 22 of the matching candidate do not match (NO in step S120), the management server 100 determines whether the matching process has been completed for all sales requests 22 stored in the request queue 116 (step S126). If there are sales requests 22 stored in the request queue 116 for which the matching process has not yet been performed (NO in step S126), the management server 100 selects one sales request 22 for which the matching process has not yet been performed as a matching candidate (step S128), and repeats the processes from step S116 onwards.

[0121] On the other hand, if the matching process has been completed for all sales requests 22 stored in the request queue 116 (YES in step S126), the management server 100 determines that no purchase requests 12 and sales requests 22 matching each other's conditions have been found, and terminates the matching process.

[0122] On the other hand, if the newly received or updated request is a sales request 22 ("Sales Request" in step S110), the management server 100 sets the newly received or updated sales request 22 as the sales request 22 to be matched (step S132), and selects one of the purchase requests 12 stored in the request queue 116 as a matching candidate (step S134).

[0123] Next, the management server 100 determines whether or not it is necessary to calculate delivery costs for the sales request 22 to be matched or the purchase request 12 of the matching candidate (step S136). If it is necessary to calculate delivery costs for the sales request 22 to be matched or the purchase request 12 of the matching candidate (YES in step S136), the management server 100 determines the necessary delivery costs (delivery costs 123 or delivery costs 223) based on the information indicating the delivery destination of the buyer 10 (delivery destination information 125 or delivery destination information 152) and the information on delivery costs (delivery cost definition 225 or delivery cost definition 226) (step S138).

[0124] In this way, the management server 100 determines whether the purchase request 12 and the sale request 22 match, taking into account the shipping costs for shipping a particular product from the supplier 20 to the buyer 10.

[0125] On the other hand, if it is not necessary to calculate the delivery cost for the sales request 22 to be matched or the purchase request 12 of the matching candidate (NO in step S136), the process of step S138 is skipped.

[0126] The management server 100 then compares the sales request 22 of the matching target with the purchase request 12 of the matching candidate to determine whether or not their conditions match (step S140).

[0127] If the conditions of the sales request 22 to be matched and the purchase request 12 of the matching candidate are met (YES in step S140), the management server 100 determines that the transaction is concluded, notifies the supplier 20 and the buyer 10 corresponding to the sales request 22 and the purchase request 12, respectively (step S142), and changes the status of the sales request 22 and the purchase request 12 to awaiting delivery completion of the target product (step S144). Then, the matching process ends.

[0128] If the conditions between the sales request 22 to be matched and the purchase request 12 of the matching candidate do not match (NO in step S140), the operation server 100 determines whether the matching process has been completed for all the purchase requests 12 stored in the request queue 116 (step S146). If there is a purchase request 12 stored in the request queue 116 for which the matching process has not been performed (NO in step S146), the operation server 100 selects one purchase request 12 for which the matching process has not been performed yet as a matching candidate (step S148), and repeats the processes below step S136.

[0129] On the other hand, if the matching process has been completed for all the purchase requests 12 stored in the request queue 116 (YES in step S146), the operation server 100 determines that no sales request 22 and purchase request 12 whose conditions match each other have been found, and ends the matching process.

[0130] <D. Product Management> An example of product management in the product trading system 1 according to the present embodiment will be described.

[0131] (d1: Identification Information) The products handled in the product trading system 1 may be specified using identification information attached to packages or the like. As such identification information, for example, product identification numbers such as JAN (Japanese Article Number) code, EAN (European Article Number) code, GTIN-13, GTIN-8, etc. may be used. By using such product identification numbers, it is possible to facilitate the handling of products distributed among multiple countries.

[0132] Furthermore, identification information for collective packaging may be used. The identification information for collective packaging includes a product identification number assigned to a collective package (such as a case, a bowl, or a pallet), which is a trading unit between companies. A known example of such identification information for collective packaging is a collective package product code such as GTIN-14. Since the collective package product code includes the product identification number for each product packaged, the commodity trading system 1 can handle individual products as well as handle them in a collective state.

[0133] The collective package product code can be embodied as a barcode symbol such as an ITF (Inter-Leaved two of five) symbol.

[0134] By using the above-mentioned identification information indicating individual products and the identification information for collective packaging in combination, more flexible transactions can be realized according to the characteristics of the products and the circumstances of the supplier 20.

[0135] (d2: Meta-products) In product trading system 1 according to the present embodiment, a plurality of products of the same type may be collectively handled as one product. Such a product is also called a "meta-product."

[0136] For example, various products are offered for "water," but some buyers 10 simply want to purchase "water" without identifying a specific producer or product.

[0137] Therefore, for example, instead of specifying a product such as "water in a 1-liter PET bottle," a meta-product that specifies a comprehensive product type may be defined.

[0138] By storing correspondence information indicating which products are included in such meta-products in the management server 100, the buyer 10 can order "water in a 1 liter PET bottle" (regardless of which product).

[0139] On the other hand, since the supplier 20 can provide any product as long as it corresponds to the product type required by the meta product, inventory disposal and the like can be carried out more easily.

[0140] Regarding which products to include in each meta product, it may be managed on the operation server 100 side, or the conditions that can be included in each meta product may be specified, and the supplier 20 side may sell it as a meta product according to the conditions. When the operation server 100 manages the meta product, a table associating the product identification number indicating the meta product with the product identification number indicating each of the specific one or more products included in the meta product may be held.

[0141] In this way, by making the meta product available, a more flexible product transaction can be realized.

[0142] <E. Variations of the purchase request 12 and the sales request 22> In the above description, the matching process of comparing the total purchase amount 121 (including the desired purchase price 122 and the delivery fee 123) included in the purchase request 12 with the total sales amount 221 (including the desired sales price 222 and the delivery fee 223) included in the sales request 22 was exemplified. However, this is not the only case, and additional conditions may be included for the purchase request 12 and the sales request 22. Some variations will be described below.

[0143] (e1: Price specification option) Figures 5 and 6 show an example where the user inputs a specific desired purchase price or desired sales price. However, this is not the only case, and a price corresponding to the transaction situation (see Figure 7 etc.) may be specified.

[0144] Figure 14 is a schematic diagram showing another example of the user interface screen 300 provided on the terminal of the buyer 10 constituting the product transaction system 1 according to the present embodiment. In the user interface screen 300 shown in Figure 14, an example where "current lowest price" is specified in the price input box 314 is shown.

[0145] The "current lowest price" of the purchase request 12 means the lowest of the total desired selling amount 221 or the desired selling price 222 included in the sales request 22 for which a transaction has not been concluded in the transaction status shown in Figure 7. When the "current lowest price" is specified as such a desired purchase price, if there is a quantity of desired selling items that is sufficient to satisfy the desired purchase quantity, the transaction will be concluded immediately.

[0146] Conversely, a "current highest price" may be specified when generating a sales request 22. In this case, it means the highest of the total desired purchase amount 121 or the desired purchase price 122 included in the purchase request 12 for which a transaction has not been concluded in the transaction status shown in Fig. 7. When the "current highest price" is specified as such a desired sales price, if there is a quantity of units desired to be purchased that is sufficient to satisfy the quantity desired to be sold, the transaction will be concluded immediately.

[0147] Furthermore, in addition to specifying "current lowest price" or "current highest price," it is also possible to specify "5 yen higher than the current lowest price" or "5 yen lower than the current highest price."

[0148] The desired purchase price and desired selling price are not limited to the above example, and may be specified in any format.

[0149] By expanding the price specification options for the desired purchase price and desired selling price as described above, the buyer 10 and the supplier 20 can enjoy flexible transactions according to the transaction situation.

[0150] (e2: Collective packaging option) As mentioned above, suppliers 20 often provide products to buyers 10 in the form of transaction-specific group packages (e.g., 12 products packaged in a single cardboard box). In such cases, the group package can be sold as a single unit, or the individual products contained in the group package can be sold.

[0151] To meet such needs, when generating a sales request 22, it may be possible to select whether to sell the collective package in units of one, or whether to allow the individual sale of the products included in the collective package.

[0152] Figure 15 is a schematic diagram showing another example of a user interface screen provided on a terminal of a supplier 20 constituting the commodity trading system 1 according to this embodiment. On the user interface screen 400 as shown in Figure 15, the supplier 20 may accept a selection as to whether, for commodities collectively packaged in a transaction unit, the collective package is to be sold in units of one, or whether the commodities included in the collective package are to be allowed to be sold individually (individual sales field 424).

[0153] The operation server 100 determines whether the conditions between the purchase request 12 and the sales request 22 match, taking into consideration the supplier's 20 requests for such collective packaging.

[0154] It is also possible to set different shipping costs for when the collective package is sold as a single unit and when the collective package is separated into individual products. Typically, shipping costs are set higher when the collective package is separated into individual products compared to when the collective package is sold as a single unit. Setting different shipping costs in this way can increase the incentive to sell the collective package as a single unit.

[0155] (e3: expiry date option) The buyer 10 and supplier 20 may be able to cancel or withdraw their purchase request 12 and sale request 22 at will until the transaction is completed. Furthermore, depending on the characteristics of the product, there may be a need to purchase or sell by a specific deadline.

[0156] Taking such needs into consideration, expiration dates may be set for purchase requests 12 and sales requests 22. More specifically, when the buyer 10 and supplier 20 generate any purchase request 12 or sales request 22, they may be able to add a deadline (expiration date condition) for canceling or withdrawing the request if the transaction is not concluded.

[0157] For purchase requests 12 and sales requests 22 with specified expiration dates, if the transaction has not been concluded by the time the specified expiration date arrives, the management server 100 forcibly cancels the corresponding purchase request 12 or sales request 22. By adding this to the sales request 22, it is possible to avoid a situation where the transaction is concluded too late.

[0158] The expiration date may be specified by any method, such as a specific date, a specific date and time, today, this week, or this month.

[0159] (e4: Stock availability option) Although the supplier 20 is scheduled to supply a specific product at all times, there may be a situation where the supplier is temporarily unable to supply the product for some reason. In such a case, the product will be delivered to the buyer 10 as soon as it arrives, but the buyer will have to wait until the product arrives.

[0160] Therefore, when the buyer 10 generates the purchase request 12, the buyer 10 may add a condition as to whether the specified product is in stock. More specifically, the buyer 10 may be allowed to select whether the transaction will be concluded only if the supplier 20 has the product in stock, or whether the transaction will be concluded even if the supplier 20 does not have the product in stock.

[0161] If the condition is that the transaction will be concluded only if the supplier 20 has the product in stock, the transaction will be concluded only if the specified product is in stock at the supplier 20.

[0162] On the other hand, if it is specified that the transaction can be concluded even if the supplier 20 does not have the product in stock, the buyer 10 may be informed of the time until the supplier 20 receives the product in stock.

[0163] (e5: Delivery start deadline option) There may be cases where the buyer 10 wishes to obtain a certain product as soon as possible. Therefore, when the buyer 10 generates the purchase request 12, the buyer 10 may add a condition specifying a deadline for the specified product to be delivered by the supplier 20. More specifically, the buyer 10 may be able to specify the time from the conclusion of the transaction until the product is delivered (e.g., within six hours after the conclusion of the transaction), or the deadline for the product to be delivered (e.g., 3:00 PM on October 1st).

[0164] When a purchase request 12 with such conditions attached is generated, the management server 100 receives information such as the available delivery time from the supplier 20 and determines whether the conditions match between the purchase request 12 and the sales request 22.

[0165] (e6: Delivery range options) Depending on the business scale of the supplier 20, the area within which the product can be delivered may be limited. Taking such limitations on the delivery area into consideration, the supplier 20 may specify in advance the area within which the product can be delivered when generating the sales request 22. More specifically, the supplier 20 may be able to specify the area within which the product can be delivered (for example, within Japan only, within 500 km, etc.).

[0166] When a sales request 22 with such conditions attached is generated, the management server 100 refers to the delivery destination information of the buyer 10 (information indicating the location of the buyer 10) and determines whether the conditions match between the purchase request 12 and the sales request 22.

[0167] In addition, when the buyer 10 generates the purchase request 12, if it is clear that the conditions of the deliverable range specified in advance by the supplier 20 are not met, the sales request 22 that does not meet the conditions may be hidden from the buyer 10.

[0168] (e7: Eligibility confirmation) Depending on the goods to be traded (e.g., alcohol, tobacco, medicine, etc.), it is necessary to confirm that the buyer 10 has the prescribed qualifications. Therefore, the operation server 100 may previously hold the attribute information (such as age) of the buyer 10, and also refer to the attribute information to determine whether the conditions match between the purchase request 12 and the sales request 22.

[0169] Regarding the attribute information of the buyer 10, the buyer 10 may previously send an image of a copy of the driver's license to the operation server 100, and based on the transmitted image, generate the attribute information of the buyer 10.

[0170] By confirming the qualifications of the buyer 10 in this way, a proper and legal transaction can be realized.

[0171] (e8: Volume discount) In the transaction of goods in the goods trading system 1, when a predetermined number of goods are purchased, the price of the goods may be reduced. In this case, when the supplier 20 generates the sales request 22, the sales volume of the goods and the discount rate may be added as conditions.

[0172] In the matching process, when a transaction of goods equal to or more than the specified sales volume is established, the operation server 100 may determine the price of the goods according to the specified discount rate.

[0173] <F. Other forms> (f1: Account) In the commodity trading system 1, international commodity trading is also possible. In such a case, the user's account may be unified in a specific currency (e.g., Japanese yen, US dollar, etc.), or the user may be allowed to select a specific currency from multiple currencies. When transactions are conducted between accounts in different currencies, the payment may be exchanged between the accounts considering the exchange rate at the time of the transaction.

[0174] Alternatively, the accounts of each user may be managed using any virtual currency. By using a common virtual currency, conversion processing based on the exchange rate can be omitted.

[0175] (f2: Distributed arrangement) In the above description, an example where the operation server 100 executes the matching process and the settlement process is shown. However, each process may be implemented on a different server, or may be implemented using a plurality of operation servers 100. For example, by preparing operation servers 100 for each country or region and coordinating the operation servers 100 with each other, international commodity trading can be realized.

[0176] <G. Advantages> According to the commodity trading system 1 according to the present embodiment, the buyer 10 and the supplier 20 each generate a purchase request 12 and a sales request 22, and the operation server 100 determines the matching between the purchase request 12 and the sales request 22. When it is determined that they match, the commodity is delivered from the supplier 20 to the buyer 10, and in response to the completion of the delivery of the commodity, the payment is transferred to the account of the supplier 20. By introducing such an electronic trading mechanism, direct commodity trading between the producer and the buyer 10 becomes possible.

[0177] The embodiments disclosed this time should be considered as illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the scope of the claims are included. are intended to include all modifications within the meaning and scope equivalent to the scope of the claims.

Explanation of reference numerals

[0178] 1 commodity trading system, 10 buyer, 12 purchase request, 20 supplier, 22 sales request, 30 deliverer, 100 operation server, 101 processor, 102 main memory, 103 communication interface, 104 input unit, 105 display, 106 internal bus, 110 storage, 112 matching program, 114 settlement program, 116 request queue, 118 user information, 121 desired purchase total amount, 122 desired purchase price, 123, 223 delivery cost, 124 desired purchase quantity, 125, 152 delivery destination information, 126 system usage fee, 150, 250 management information, 154, 254 balance information, 156 Purchase history, 221 Desired sales total, 222 Desired sales price, 224 Desired sales quantity, 225, 226, 227 Shipping cost definition, 228 Weight table, 256 Sales history, 300, 320, 400 User interface screen, 302, 322 Product display area, 304, 416 Search button, 306, 418 Button, 310 Quantity input box, 312 Unit selection radio button, 314 Price input box, 316 Shipping cost selection radio button, 318 Check button, 330 Status display area, 332 Purchase request status display area, 334 Sales request status display area, 402 List, 404 Product code field, 406 Product name field, 408 Sales price field, 410 Sales quantity field, 412 Remaining quantity field, 414 Partial transaction field, 420 Content change button, 422 Update button, 424 individual sales column.

Claims

1. A commodity trading system for conducting commodity transactions between buyers and suppliers, A first receiving means for receiving a purchase request from the aforementioned buyer, including the desired purchase price for a specific product, first identification information for identifying the specific product, and shipping address information, A second receiving means for receiving sales requests from the supplier, including the desired selling price of the specific product and second identification information for identifying the specific product, A determination means for determining whether a purchase request and a sales request match, based on the delivery destination information included in the purchase request, after reflecting the delivery costs for delivering the specific product from the supplier to the buyer, with respect to purchase requests and sales requests where the first and second identification information match, A commodity trading system comprising, when a purchase request and a sales request match, a notification means for notifying the buyer of the matched purchase request and the supplier of the sales request that the transaction has been completed without any action required from the buyer and the supplier.

2. A request queue for temporarily holding one or more of the aforementioned purchase requests and one or more of the aforementioned sales requests, The product trading system according to claim 1, further comprising means for providing data including the desired number of units to be purchased by desired purchase price based on purchase requests stored in the request queue, and the desired number of units to be sold by desired selling price based on sales requests stored in the request queue.

3. The commodity trading system according to claim 2, wherein the data provided is used for display on a terminal device.

4. The product trading system according to any one of claims 1 to 3, wherein the determination means includes means for determining the shipping cost based on the weight of the specific product and the distance based on the shipping destination information.

5. The product trading system according to claim 4, further comprising a delivery fee definition in which the delivery fee is determined according to the weight and distance of the product.

6. The first identification information and the second identification information are generated using a standardized product identification number. The commodity trading system according to any one of claims 1 to 5, wherein the commodity identification number uses at least one of the following: JAN (Japanese Article Number) code, EAN (European Article Number) code, GTIN-13, GTIN-8, and GTIN-14.

7. The product trading system according to any one of claims 1 to 6, wherein the desired purchase price included in the purchase request can be the lowest price among unmatched sales requests, or a price based on that lowest price.

8. The commodity trading system according to any one of claims 1 to 7, wherein the purchase request further includes an expiration date for the purchase request, and / or the sale request further includes an expiration date for the sale request.

9. A method of commodity trading performed by a computer for conducting commodity transactions between buyers and suppliers, The steps include receiving a purchase request from the aforementioned buyer, which includes the desired purchase price for a specific product, first identifying information for identifying the specific product, and shipping address information, A step of receiving a sales request from the supplier, including the desired selling price of the specific product and second identifying information for identifying the specific product; With respect to purchase requests and sales requests in which the first and second identification information matches, the step of determining whether the purchase request and the sales request match, based on the delivery address information included in the purchase request, after reflecting the delivery costs for delivering the specific goods from the supplier to the buyer. A method for trading goods, comprising the step of notifying the buyer of the matched purchase request and the supplier of the matched sales request that the transaction has been completed, without requiring any action from the buyer or supplier of the sales request.

10. A commodity trading program for conducting commodity transactions between buyers and suppliers, which is installed on a computer. The steps include receiving a purchase request from the aforementioned buyer, which includes the desired purchase price for a specific product, first identifying information for identifying the specific product, and shipping address information, A step of receiving a sales request from the supplier, including the desired selling price of the specific product and second identifying information for identifying the specific product; With respect to purchase requests and sales requests in which the first and second identification information matches, the step of determining whether the purchase request and the sales request match, based on the delivery address information included in the purchase request, after reflecting the delivery costs for delivering the specific goods from the supplier to the buyer. A commodity trading program that, when a purchase request and a sales request match, performs the step of notifying the buyer of the matched purchase request and the supplier of the sales request that the transaction has been completed, without requiring any action from the buyer or supplier.