System and Method

Abstract

To provide a controller, a commodity transaction system, and an automatic ordering program capable of achieving electronic commodity transaction.SOLUTION: A product transaction system includes: one or a plurality of consumption entities; one or a plurality of suppliers that provide at least part of one or a plurality of products; and an operation server that is accessible from any of the one or a plurality of consumption entities and the one or a plurality of suppliers. A controller 100 as a main configuration of the consumer entity includes a state information acquisition unit (an internal interface 130 and a sensing unit 140) for acquiring information on a consumption state of the commodity from an object (an apparatus 50) for consuming the commodity. When it is determined that predetermined conditions are satisfied based on the acquired information, the controller generates a purchase request for purchasing the commodity and transmits it to the outside. The purchase request includes information for specifying the product desired to be purchased.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to a controller, a commodity trading system, and an automatic ordering program capable of realizing electronic commodity trading. [Background technology]

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

[0003] [Patent Document 1] JP 2019-128814 A 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 such conventional electronic trading systems merely carry out communication between buyers and sellers electronically, and the start of the transaction itself is decided by human judgment.

[0005] The present disclosure aims to provide a platform that enables automated trading depending on the situation. [Means for solving the problem]

[0006] A controller according to an embodiment of the present disclosure includes a status information acquisition unit that acquires information on a consumption status of a product from a target that consumes the product, and a request generation unit that generates a purchase request for purchasing the product and transmits the purchase request to an external device when it is determined that a predetermined condition is satisfied based on the acquired information. The purchase request includes information that identifies the product desired to be purchased.

[0007] The request generator may include at least one of the number of products desired to be purchased and the desired price for purchasing the products.

[0008] The request generator may include a delivery deadline determined based on the obtained information. The status information acquisition unit may include a sensing unit that senses the remaining amount of the product.

[0009] The state information acquisition unit may include an interface for acquiring information managed by a subject that consumes a product.

[0010] The request generating unit may attach a digital signature to the purchase request before transmitting it to the outside. The request generating unit may include the position information of the controller in the purchase request and transmit the request to the outside.

[0011] The controller may further include a communication unit that performs data communication with a destination of the purchase request using the authenticated IP address.

[0012] A commodity trading system according to another aspect of the present disclosure includes the above-mentioned controller, a second request generation unit that generates a sales request for selling a commodity and transmits it to the outside, and a matching processing unit that determines a pair of the purchase request and the sales request whose request contents match each other.

[0013] According to yet another aspect of the present disclosure, an automatic ordering program executed on a computer causes the computer to execute the steps of acquiring information on a consumption state of a product from a subject consuming the product, determining whether or not a predetermined condition is satisfied based on the acquired information, and generating and transmitting a purchase request for purchasing the product to an external device when it is determined that the predetermined condition is satisfied. The purchase request includes information identifying the product desired to be purchased. Effect of the Invention

[0014] According to the present disclosure, a platform can be realized that enables automatic trading according to the situation. [Brief description of the drawings]

[0015] [Figure 1] 1 is a diagram for illustrating an overview of processing in a commodity trading system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a schematic diagram showing an example of a configuration of a consuming entity that constitutes a commodity trading system according to the present embodiment. [Diagram 3] 2 is a schematic diagram showing an example of the configuration of a supplier terminal used in a supplier that constitutes the commodity trading system according to the present embodiment. FIG. [Figure 4] FIG. 2 is a schematic diagram showing an example of a configuration of an administration server that constitutes the commodity trading system according to the present embodiment. [Diagram 5] 10 is a flowchart showing a processing procedure of an automatic ordering function of the commodity trading system according to the present embodiment. [Figure 6] 2 is a schematic diagram showing a configuration example for acquiring a state value by a controller of the commodity trading system according to the present embodiment. FIG. [Figure 7] 13 is a schematic diagram showing another example configuration for acquiring a state value by a controller of the commodity trading system according to the present embodiment. FIG. [Figure 8] 2 is a schematic diagram showing an example of a purchase request generated by a controller of the commodity trading system according to the present embodiment. FIG. [Figure 9] 13 is a schematic diagram showing an example of a user interface screen provided by a supplier terminal of the commodity trading system according to the present embodiment. FIG. [Figure 10] 2 is a diagram for illustrating an example of user management by a management server of the commodity trading system according to the present embodiment. FIG. [Figure 11] 13 is a flowchart showing a processing procedure for matching processing in a management server of the commodity trading system according to the present embodiment. [Figure 12]This is a flowchart showing the processing procedure of the matching process in the operation server of the product trading system according to the present embodiment. [Figure 13] This is a diagram showing an example of the delivery fee definition used in the product trading system according to the present embodiment. [Figure 14] This is a diagram showing another example of the delivery fee definition used in the product trading system according to the present embodiment. [Figure 15] This is a diagram for explaining the outline of the processing in another product trading system according to the present embodiment. [Figure 16] This is a diagram for explaining the outline of the processing in yet another product trading system according to the present embodiment.

Embodiments for Carrying Out the Invention

[0016] 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 will not be repeated.

[0017] <A. Product Trading System 1> First, the product trading system 1 according to the present embodiment will be described. The product trading system 1 provides a platform that enables transactions in response to purchase requests for products from arbitrary consumer entities.

[0018] FIG. 1 is a diagram for explaining the outline of the processing in the product trading system 1 according to the present embodiment. Referring to FIG. 1, the product trading system 1 includes one or more consumer entities 10 that consume one or more products, one or more suppliers 20 that provide at least a part of the one or more products, and an operation server 300 that is accessible from any of the one or more consumer entities 10 and the one or more suppliers 20.

[0019] The products handled in the product trading system 1 are not particularly limited, but those for which repeated purchases such as daily necessities and consumables are assumed are preferred.

[0020] In this specification, the "consumer entity 10" includes any entity (subject) that consumes any commodity, and typically includes natural persons such as individuals, non-natural persons (including organizations and corporations) such as stores and business establishments, computers, devices with computing capabilities, etc., that are expected to consume the commodity. The "consumer entity 10" is a concept that includes any entity (subject) that can make some kind of decision regarding the transaction of a commodity.

[0021] In this specification, "supplier 20" includes any entity that provides any product, and is typically assumed to be a manufacturer or importer of the product. "Supplier 20" may be a logistics company that stores or manages any product, or may be a computer or a device with computing capabilities. "Supplier 20", like "consumer entity 10", is a concept that includes any entity that is capable of making some kind of decision regarding the transaction of products.

[0022] In the following description, we will mainly explain an example in which the consuming entity 10 is a computer or a device with a computing function. Figure 1 shows, as an example, a configuration in which detergent, fabric softener, etc. are automatically ordered from a washing machine depending on the situation without user operation, etc.

[0023] Each consuming entity 10 transmits a purchase request 12 including information for identifying any and the number of products it wishes to purchase to the operating server 300 when predetermined conditions (including both objective and subjective) are met. The purchase request 12 may also include the price at which the purchase is desired.

[0024] Meanwhile, each of the suppliers 20 transmits a sales request 22 including information for identifying any product that the supplier 20 wishes to sell and the number of the product that the supplier 20 can provide to the operation server 300. The sales request 22 may also include the price at which the supplier 20 wishes to sell the product.

[0025] The operation server 300 compares a purchase request 12 from one or more consumer entities 10 with a sales request 22 from one or more suppliers 20 to determine whether the content of the purchase request 12 matches the content of the sales request 22 (hereinafter, also referred to as "matching process"). That is, the operation server 300 has a matching process function for determining a pair of a purchase request 12 and a sales request 22 whose request contents match each other. When the purchase request 12 and the sales request 22 match, it is determined that the transaction is established.

[0026] The operation server 300 notifies the supplier 20 corresponding to the sales request 22 for which the transaction is determined to be established of the fact that the transaction is established, and supplies the commodity that has become the subject of the transaction to the consumer entity 10 for delivery. Regarding the delivery of the commodity, the supplier 20 itself may perform the delivery, but typically, any delivery provider 30 may perform the delivery.

[0027] As will be described later, the operation server 300 is also responsible for the settlement process between the consumer entity 10 and the supplier 20.

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

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

[0030] (b1: Consumer Entity 10) FIG. 2 is a schematic diagram showing a configuration example of the consumer entity 10 constituting the commodity trading system 1 according to the present embodiment. The consumer entity 10 may be realized mainly with a controller 100 which is a kind of computer.

[0031] 2, controller 100 includes, as a main component, a control unit 110 which is a processing circuit. Control unit 110 is a computing entity for realizing the provision of functions and the execution of processes according to the present embodiment.

[0032] The control unit 110 may be configured to use a processor and memory as shown in Fig. 2 to cause the processor to execute computer readable instructions stored in the memory. Alternatively, the control unit 110 may be configured to execute a hardwired circuit such as an Application Specific Integrated Circuit (ASIC) incorporating circuits corresponding to computer readable instructions. Alternatively, the control unit 110 may be implemented by implementing a circuit corresponding to a computer-readable instruction on a field programmable gate array (FPGA). 0. The control unit 110 may also be realized by appropriately combining a processor, a memory, an ASIC, an FPGA, and the like.

[0033] In a configuration using a processor and memory as shown in FIG. 2, the control unit 110 includes a processor 102, a main memory 104, and a storage 106.

[0034] The processor 102 is an arithmetic circuit that sequentially reads and executes computer-readable instructions. The processor 102 is composed of, for example, a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), etc. The control unit 110 may be realized using a plurality of processors 102 (multiprocessor configuration), or may be realized using a processor having a plurality of cores (multicore configuration).

[0035] The main memory 104 is a volatile storage device such as a dynamic random access memory (DRAM) or a static random access memory (SRAM). Of the various programs stored in 106, a specified program is loaded onto the main memory 104, and by cooperating with the main memory 104, various processes according to the present embodiment are realized.

[0036] The storage 106 is, for example, a non-volatile storage device such as a hard disk drive (HDD), a solid state drive (SSD), or a flash memory. The storage 106 stores various programs and data executed by the processor 102. Typically, the storage 106 stores an automatic ordering program 104 for implementing an automatic ordering function as described below. It stores 08.

[0037] In a configuration such as that shown in FIG. 2 in which the processor 102 executes computer-readable instructions stored in a memory, the memory corresponds to the storage 106 .

[0038] The controller 100 further includes a GPS (Global Positioning System) 112 and a network. The device includes a network interface 120 , an internal interface 130 , a sensing section 140 , and an output section 150 .

[0039] The GPS 112 acquires position information of the controller 100. Note that as the GPS 112, any GNSS (Global Navigation Satellite System) can be used.

[0040] The network interface 120 performs data communication with the operation server 300 via a network. The network interface 120 may be configured as either a wired or wireless interface. When the network interface 120 is configured as a wired interface, it may include a wired connection terminal such as an Ethernet (registered trademark) port, a Universal Serial Bus (USB) port, a serial port such as IEEE1394, or a legacy parallel port. When the network interface 120 is configured as a wireless interface, it may include a processing circuit and an antenna for wireless communication with a device, a router, a mobile base station, and the like. Examples of wireless communication supported by the network interface 120 include Wi-Fi (registered trademark), Bluetooth (registered trademark), ZigBee (registered trademark), LPWA (Low Power Wide Area), GSM (registered trademark), W-CDMA, CD-ROM, and the like. MA2000, LTE (Long Term Evolution), 5th generation mobile communication system (5G) Either is acceptable.

[0041] The internal interface 130 and the sensing unit 140 correspond to a status information acquisition unit that acquires information about the consumption status of a product from an object that consumes the product (in this case, the device 50). Here, "information about the consumption status of a product" is a concept that encompasses information necessary to determine whether or not an order for the target product is necessary. Typically, "information about the consumption status of a product" includes any information related to the consumption of a product, such as the number or amount of the product remaining in the object, the total amount or consumption rate of the product in the object, the history of the addition or consumption of the product in the object, and the change over time in the addition or consumption of the product in the object.

[0042] The internal interface 130 performs data communication with an appliance 50 such as a washing machine. The internal interface 130 can acquire a required state value from a control logic implemented in the appliance 50. Typically, the internal interface 130 acquires information (e.g., inventory information, operation history information, etc.) managed by an object that consumes a commodity.

[0043] The sensing unit 140 senses necessary information from the appliance 50 such as a washing machine or a part related to the appliance 50. Any sensor can be used as the sensing unit 140. Typically, the sensing unit 140 may be configured to sense the remaining amount of a product.

[0044] The output unit 150 is a component for externally presenting the processing results of the control unit 110. The output unit 150 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display. The output unit 150 may also be any indicator or speaker.

[0045] The controller 100 may further include a secure storage 152. The secure storage 152 is a storage unit that holds information necessary to realize secure processing. Like the storage 106, the secure storage 152 may be configured with a non-volatile storage device such as a hard disk, SSD, or flash memory. In this case, a known access restriction function may be added to prevent the stored data from being altered. In addition, a security chip such as a TPM (Trusted Platform Module) may be used. Furthermore, necessary information may be stored using an RFID (Radio Frequency Identifier) ​​tag or the like.

[0046] The secure storage 152 stores, for example, a digital certificate 154, a key pair 156 consisting of a private key and a public key, and identification information 158. The digital certificate 154 is issued by an arbitrary issuer (typically, a certificate authority). The key pair 156 is used in a process of adding a digital signature to information output from the controller 100 in order to prevent information tampering, spoofing, and the like. The identification information 158 includes information for uniquely identifying the controller 100 (for example, a serial number, a manufacturing number, and the like).

[0047] For example, the controller 100 can add a digital signature generated using its own private key to the purchase request 12 to be sent to the operation server 300, allowing the operation server 300 and the supplier terminal 200 to authenticate that the purchase request 12 is genuine. In this way, the controller 100 may add a digital signature to the generated purchase request 12 and send it to the outside.

[0048] Furthermore, the legitimacy of the requester of purchase request 12 can be more reliably authenticated by adding an electronic signature generated using the private key of controller 100 to a data set including controller identification information 158 in purchase request 12.

[0049] (b2:Supplier 20) 3 is a schematic diagram showing an example of the configuration of supplier terminal 200 used in supplier 20 constituting commodity trading system 1 according to the present embodiment. Typically, supplier terminal 200 is realized using a general-purpose computer.

[0050] 3, the supplier terminal 200 includes, as main components, one or more processors 201, a main memory 202, a network interface 203, an input unit 204, a display 205, and a storage 210. These components are connected via an internal bus 206.

[0051] The processor 201 is configured by, for example, a CPU, a GPU, etc. A plurality of processors 201 may be arranged, or a processor 201 having a plurality of cores may be adopted.

[0052] The main memory 202 is composed of a volatile storage device such as a DRAM or an SRAM. The storage 210 is composed of a non-volatile storage device such as a hard disk or an SSD, and holds various programs and various data executed by the processor 201. Of the programs stored in the storage 210, designated program code is expanded on the main memory 202, and the processor 201 realizes various functions, which will be described later, by sequentially executing computer-readable instructions included in the program code expanded on the main memory 202.

[0053] Typically, the storage 210 stores an inventory management program 212 for managing the inventory of available products, and inventory information 218 indicating the status of each product subject to inventory management.

[0054] The network interface 203 performs data communication with the operation server 300 via a network. The network interface 203 is, for example, The device may also include an Ethernet port to allow communication over a network.

[0055] The input unit 204 accepts any input instruction. The display 205 displays the results of processing by the processor 201, and the like.

[0056] The supplier terminal 200 may be realized in whole or in part using a hardwired circuit such as an ASIC incorporating a circuit corresponding to a computer-readable instruction, or may be realized using a circuit corresponding to a computer-readable instruction on an FPGA, or may be realized by appropriately combining the processor 201, a main memory, an ASIC, an FPGA, or the like.

[0057] The supplier terminal 200 may further include a component for reading out an inventory management program 212, which is made up of computer-readable instructions, from a non-transitory medium storing the stored program. The medium may be, for example, an optical medium such as a digital versatile disc (DVD) or a semiconductor medium such as a USB memory. The inventory management program 212 may not only be installed in the supplier terminal 200 via the medium, but may also be provided from a distribution server on a network.

[0058] (b3: Management server 300) 4 is a schematic diagram showing an example of the configuration of the operation server 300 constituting the commodity trading system 1 according to the present embodiment. Typically, the operation server 300 is realized using one or more general-purpose computers.

[0059] 4, the operation server 300 includes, as main components, one or more processors 301, a main memory 302, a network interface 303, an input unit 304, a display 305, and a storage 310. These components are connected via an internal bus 306.

[0060] The processor 301 is configured, for example, with a CPU, a GPU (Graphics Processing Unit), etc. A plurality of processors 301 may be arranged, or a processor 301 having a plurality of cores may be employed.

[0061] The main memory 302 is configured with a volatile storage device such as a dynamic random access memory (DRAM) or a static random access memory (SRAM). It is composed of non-volatile storage devices such as hard disks and SSDs (Solid State Drives), and The storage 310 holds various programs and various data executed by the processor 301. Of the programs stored in the storage 310, designated program code is expanded onto the main memory 302, and the processor 301 realizes various functions as described below by sequentially executing computer-readable instructions included in the program code expanded onto the main memory 302.

[0062] Typically, the storage 310 stores a matching program 312 for implementing the matching process, a payment program 314 for implementing the payment process, a request queue 316, and user information 318 including various information regarding the consuming entities 10 and the suppliers 20. The request queue 316 temporarily holds one or more purchase requests 12 from one or more consuming entities 10 and one or more sale requests 22 from one or more suppliers 20.

[0063] The matching program 312 and the settlement program 314 are configured to The program corresponds to a commodity trading program for executing a commodity trading between the entity 10 and the supplier 20.

[0064] The network interface 303 is responsible for data exchange with terminals of the consuming entity 10 and the supplier 20, etc. The network interface 303 may, for example, include an Ethernet port to allow communication over the Internet.

[0065] The input unit 304 accepts any input instruction. The display 305 displays the results of processing by the processor 301, and the like.

[0066] All or part of the operation server 300 may be implemented using a hardwired circuit such as an ASIC in which a circuit corresponding to a computer-readable instruction is incorporated. Alternatively, it may be implemented using a circuit corresponding to a computer-readable instruction on an FPGA. Further, it may be implemented by appropriately combining the processor 301, the main memory, the ASIC, the FPGA, and the like.

[0067] The operation server 300 may further include a component for reading out the stored program and the like from a non-transitory medium that stores a matching program 312 and a settlement program 314 composed of computer-readable instructions. The medium may be, for example, an optical medium such as a DVD or a semiconductor medium such as a USB memory.

[0068] The matching program 312 and the settlement program 314 may not only be installed in the operation server 300 via the medium but also be provided from a distribution server on the network.

[0069] <C. Consumption Entity 10 and Controller 100> In the commodity trading system 1 according to the present embodiment, the consumption entity 10 has a function (hereinafter, also referred to as "automatic order function") of automatically ordering necessary commodities as needed.

[0070] The consumption entity 10 monitors the state of the device 50 such as a washing machine, and when the state of the device 50 satisfies a predetermined condition, automatically orders a commodity corresponding to the condition (that is, generates and transmits a purchase request 12).

[0071] In the following description, a washing machine is shown as a typical example of the device 50, but the present invention is not limited to this and may be applied to any device. Examples of home appliances include copiers, multifunction machines, printers (products: toner, ink, paper, etc.), vacuum cleaners (products: paper packs), shavers with cleaning functions (products: cleaning fluid), coffee makers (products: coffee), refrigerators (products: beverages, food, etc.), air conditioners (products: filters), and lighting equipment (products: fluorescent lamps, LED bulbs, etc.).

[0072] (c1: Processing procedure) First, a processing procedure of the automatic ordering function of commodity trading system 1 according to the present embodiment will be described.

[0073] 5 is a flowchart showing a processing procedure of the automatic ordering function of commodity trading system 1 according to the present embodiment. Each step shown in FIG.

[0074] 5, the controller 100 acquires a status value of the target device 50 (step S100). That is, the controller 100 acquires information on the consumption status of the product from the target that consumes the product. If the device 50 is a washing machine, the status value of the device 50 is assumed to be, for example, the remaining amount of detergent, fabric softener, and bleach.

[0075] The controller 100 determines whether or not the acquired state value of the device 50 satisfies a predetermined condition (step S102). That is, the controller 100 determines whether or not the predetermined condition is satisfied based on the acquired information.

[0076] If the acquired state value of the device 50 does not satisfy the predetermined condition (NO in step S102), the subsequent processes are skipped.

[0077] If the acquired status value of the device 50 satisfies the predetermined condition (YES in step S102), the controller 100 generates a purchase request 12 according to the acquired status value of the device 50 (step S104), and transmits the generated purchase request 12 to the operation server 300 (step S106). That is, when the controller 100 determines that the predetermined condition is satisfied, it generates a purchase request 12 for purchasing the product and transmits it to the outside. Then, the process ends.

[0078] In this way, the automatic ordering function of the commodity trading system 1 according to the present embodiment can automatically generate and transmit a purchase request 12 for purchasing a necessary commodity according to the state of any target. That is, the controller 100 has a request generating function that generates a purchase request 12 for purchasing the commodity and transmits it to the outside (operation server 300) when it determines that a predetermined condition is satisfied based on the acquired information (state value of the target device 50).

[0079] (c2: Get status value) Next, an example of a method for acquiring the state value will be described.

[0080] Fig. 6 is a schematic diagram showing an example of a configuration for acquiring a status value by controller 100 of commodity trading system 1 according to the present embodiment. Fig. 6 shows detergent tray 52 attached to a washing machine. Detergent 54 is loaded inside detergent tray 52, and a required amount of detergent is supplied to the washing tub every time a wash is performed by the washing machine.

[0081] The sensing unit 140 of the controller 100 is disposed in association with the detergent tray 52, and the rotation angle of the sensing unit 140 changes according to the amount of detergent 54 in the detergent tray 52. ​​The sensing unit 140 outputs a signal indicating the remaining amount of detergent 54 in the detergent tray 52 according to the rotation angle. The remaining amount of detergent 54 in the detergent tray 52 is calculated based on this output signal. The controller 100 determines whether or not a predetermined condition is satisfied based on the calculated remaining amount of detergent 54.

[0082] Fig. 7 is a schematic diagram showing another example of a configuration for acquiring a state value by the controller 100 of the commodity trading system 1 according to the present embodiment. Fig. 7 shows an example in which the internal interface 130 of the controller 100 is connected to a device 50.

[0083] 7(A) shows an example of history information 56 held by device 50, which is a washing machine. Controller 100 accesses history information 56 held by device 50 via internal interface 130, and acquires a laundry execution history of device 50. Then, controller 100 calculates the amount of detergent consumed and the remaining amount, etc., based on the acquired laundry execution history.

[0084] Fig. 7(B) shows an example of an estimation result 160 of the remaining amount of detergent calculated by the controller 100. The controller 100 judges whether or not a predetermined condition is satisfied based on the estimation result 160 as shown in Fig. 7(B). For example, a predetermined threshold value 162 may be set for the estimation result 160, and the purchase request 12 may be generated when the amount falls below the threshold value 162, or by predicting the time when the amount will fall below the threshold value 162.

[0085] The method of acquiring the status value is not limited to the configuration shown in Fig. 6 and Fig. 7, and any acquisition method can be adopted according to the target device 50 and the target product. Furthermore, a user may be in charge of a part or all of the process and configuration for acquiring the status value. For example, a mode may be adopted in which the user visually checks the remaining amount and inputs the remaining amount obtained by the visual check into the controller 100.

[0086] (C3: Conditions and Purchase Requirements) Next, an example of conditions related to the automatic ordering function and the purchase request 12 to be generated will be described.

[0087] 6 and 7, the controller 100 can obtain the remaining amount of detergent 54 in the target device 50, and can therefore set, for example, a condition for generating a purchase request 12 such that the obtained remaining amount of detergent 54 is equal to or less than a predetermined lower limit. When such a condition is met, the controller 100 generates the purchase request 12.

[0088] FIG. 8 is a schematic diagram showing an example of a purchase request 12 generated by controller 100 of product trading system 1 according to the present embodiment.

[0089] 8(A), the purchase request 12 generated by the controller 100 (the consuming entity 10) includes product information 121, quantity information 122, and a desired price 123.

[0090] The product information 121 stores specific information (such as a product code, as described below) for identifying the product to be purchased.

[0091] The quantity information 122 is optional information, and information for specifying the number of products to be purchased is set arbitrarily. For example, if the number of products purchased is always one, the quantity information 122 may be omitted.

[0092] The desired price 123 is optional information and is set arbitrarily depending on the characteristics of the product, the characteristics of the market, etc. For example, the desired price 123 can be set to "lowest price" instead of a specific purchase price. In this case, a transaction is concluded with the supplier 20 who offers the lowest price on the operation server 300 described later.

[0093] In this way, the purchase request 12 includes product information 121, which is an example of information that identifies a product desired to be purchased. The purchase request 12 may also include at least one of the number of products desired to be purchased (quantity information 122) and the desired price at which to purchase the product (desired price 123).

[0094] Furthermore, when the estimated result 160 of the remaining amount of the detergent as shown in FIG. 7(B) above can be used, it is possible to predict at which timing the detergent will be completely consumed. In such a case, it is possible to generally determine the deadline by which the product to be purchased will be delivered to the target device 50.

[0095] Therefore, as shown in FIG. 8(B), the purchase request 12 generated by the controller 100 (consumption entity 10) may further include a delivery deadline 124. When the delivery deadline 124 is included in the purchase request 12, the operation server 300 executes a matching process with the supplier 20 so as to meet the specified delivery deadline 124.

[0096] In this way, the purchase request 12 may include a delivery deadline (delivery deadline 124) determined based on the acquired information.

[0097] FIG. 8 shows an example of the purchase request 12, but it is not limited thereto and any data structure may be adopted.

[0098] Also, the purchase request 12 shown in FIG. 8 may include information for specifying the source consumption entity 10 (controller 100). On the other hand, when secure data exchange is executed between the controller 100 and the operation server 300, information for uniquely identifying the controller 100 may be provided to the operation server 300 in advance in the procedure of that data exchange. By adopting such a method, it is not necessary to include information that is preferably concealed in the purchase request 12, and the security risk can be reduced.

[0099] <D. Supplier 20 and Supplier Terminal 200> Next, an example of the processing in the supplier 20 (supplier terminal 200) of the product trading system 1 according to the present embodiment will be described.

[0100] The supplier 20 operates the supplier terminal 200 to manage the inventory of products that can be provided to the consuming entity 10, and also generates a sales request 22 and transmits it to the operation server 300. In other words, the supplier terminal 200 has a request generation function to generate a sales request 22 for selling products and transmit it to the outside (operation server 300).

[0101] 9 is a schematic diagram showing an example of a user interface screen provided by the supplier terminal 200 of the commodity trading system 1 according to the present embodiment. Referring to FIG. 9, the user interface screen 250 accepts an instruction from the supplier 20 for generating a sales request 22.

[0102] More specifically, the user interface screen 250 includes a list 252 showing a list of products that the supplier 20 can sell. The list 252 includes a product code field 254 showing a product code for identifying each product that the supplier 20 can sell, a product name field 256 showing the product name of each product, a selling price field 258 showing the desired selling price of each product, a sales quantity field 260 showing the desired number of units of each product, a remaining number field 262 showing the number of units of each product that have not yet been traded among the desired number of units, and a partial transaction field 264 for setting whether or not to process the transaction as concluded only for the number of units that meets the requested content when the requested content is met only for a portion of the requested number of units.

[0103] The supplier 20 registers the products available for sale in the list 252 and inputs the suggested selling price (selling price column 258) and the suggested selling price (selling quantity column 260) for each product.

[0104] The supplier 20 can select the search button 266 and enter the product name or a code that identifies the product to search for products that are available for sale and register them in the list 2502. Alternatively, the supplier 20 can select the code reading button 268 and register the products that are available for sale in the list 252 by reading a barcode or QR code (registered trademark) attached to the product that the supplier wishes to purchase using a camera or the like installed in the terminal.

[0105] The supplier 20 can select the change content button 270 to arbitrarily change the suggested selling price (selling price column 258) and the suggested selling price (selling quantity column 260) registered in the list 252. The changes made by the supplier 20 are reflected when the update button 272 is selected.

[0106] Via a user interface screen 250 as shown in FIG. 6, the supplier terminal 200 generates a sales request 22 and transmits it to the operation server 300 .

[0107] Products handled in the product trading system 1 may be specified using identification information attached to packages or the like. Examples of such identification information include product identification numbers such as JAN (Japanese Article Number) codes, EAN (European Article Number) codes, GTIN-13, and GTIN-8. Using such product identification numbers can facilitate the handling of products distributed among multiple countries.

[0108] Furthermore, identification information for collective packaging may be used. Identification information for collective packaging includes a product identification number set for collective packaging (case, bowl, pallet, etc.) which is a trading unit between companies. As such identification information for collective packaging, collective package product codes such as GTIN-14 are known. Since collective package product codes include product identification numbers for each collectively packaged product, the product trading system 1 can handle individual products as well as handle them in a collected state.

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

[0110] By using the above-mentioned identification information for 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.

[0111] <E. Operation Server 300> Next, an example of the processing in the operation server 300 of the merchandise trading system 1 according to the present embodiment will be described.

[0112] (e1: User Management) The operation server 300 of the merchandise trading system 1 manages user information necessary for the matching process.

[0113] FIG. 10 is a diagram for explaining an example of user management by the operation server 300 of the merchandise trading system 1 according to the present embodiment. FIG. 10(A) shows an example of management information 350 for managing each of the consumer entities 10, and FIG. 10(B) shows an example of management information 360 for managing each of the suppliers 20.

[0114] Referring to FIG. 10(A), the management information 350 for managing each of the consumer entities 10 includes delivery destination information 352 indicating the delivery destination (address or latitude / longitude) of the consumer entity 10. The delivery destination information 352 included in the management information 350 may be used as the delivery destination information of the purchase request 12 received from the consumer entity 10. However, when the GPS 112 is installed in the controller 100 of the consumer entity 10, the delivery destination information 352 may be omitted if the position information of the controller 100 from the GPS 112 is included in the purchase request 12.

[0115] The management information 350 includes balance information 354 indicating the balance of the account of the consumer entity 10. The balance information 354 embodies an account for managing the economic value held by each of the consumer entity 10 and the supplier 20. As the economic value, an amount in a specific currency is assumed, but it may be something like a virtual currency or a unique point used in the merchandise trading system 1.

[0116] When a consuming entity 10 generates a purchase request 12, the management server 300 reserves the planned purchase amount determined based on the purchase request 12 from the corresponding balance information 354. In other words, the management server 300 reserves the value determined according to the purchase request 12 from the account of the corresponding consuming entity 10.

[0117] The management information 350 includes a purchase history 356 indicating transaction information of the consuming entity 10. The operation server 300 updates the contents of the purchase history 356 every time a transaction is completed. Note that the operation server 300 may update the contents of a purchase request 12 generated by the consuming entity 10 in the balance information 354, not only when a transaction is completed but also whenever the consuming entity 10 generates a purchase request 12.

[0118] 10(B), the management information 360 for managing each of the suppliers 20 includes balance information 364 indicating the balance of the account of the supplier 20. When a transaction is concluded between any of the consuming entities 10 and the supplier 20, the operation server 300 adds the amount exchanged in the transaction to the corresponding balance information 364.

[0119] The management information 360 includes a sales history 366 that indicates transaction information of the supplier 20. The operation server 300 updates the contents of the sales history 366 every time a transaction is concluded.

[0120] As described above, the operation server 300 manages information regarding transactions between the consuming entities 10 and the suppliers 20 using the management information 350 and management information 360 shown in FIG.

[0121] (e2: Matching process) Next, an example of matching processing in the operation server 300 of the commodity trading system 1 will be described. Figures 11 and 12 are flowcharts showing the processing steps of matching processing in the operation server 300 of the commodity trading system 1 according to the present embodiment. Figures 11 and 12 show a commodity trading method in which a computer executes a commodity trading between a consuming entity 10 and a supplier 20.

[0122] Each step shown in FIG. 11 and FIG. 12 is typically realized by the processor 301 of the operation server 300 executing a matching program 312 and a settlement program 314 (corresponding to a commodity trading program).

[0123] 11 and 12, the management server 300 determines whether or not it has received a purchase request 12 from the controller 100 of the consuming entity 10 or a sale request 22 from the supplier terminal 200 of the supplier 20 (step S300). If it has received a purchase request 12 from the controller 100 or a sale request 22 from the supplier terminal 200 (YES in step S300), the management server 300 stores the received purchase request 12 or sale request 22 in the request queue 316 (step S302).

[0124] Next, the operation server 300 determines whether or not the received request is a purchase request 12 (step S304). If the received request is a purchase request 12 (YES in step S304), the operation server 300 determines whether or not the planned purchase amount determined based on the contents of the received purchase request 12 exists in the account of the consuming entity 10 that sent the purchase request 12 (step S306).

[0125] If the planned purchase amount exists in the account of the consuming entity 10 (YES in step S306), the operation server 300 reserves the planned purchase amount from the account of the consuming entity 10 (step S308). Then, the matching process from step S310 onwards is executed.

[0126] If the planned purchase amount does not exist in the account of the consuming entity 10 (NO in step S306), the operation server 300 does not execute the matching process from step S310 onward. At this time, the operation server 300 may notify the controller 100 of the consuming entity 10 that the purchase request 12 cannot be generated.

[0127] If the received request is a sales request 22 (NO in step S304), the processes in steps S306 and S108 are skipped.

[0128] If the operation server 300 has not received the purchase request 12 from the controller 100 of the consuming entity 10 or the sales request 22 from the supplier terminal 200 of the supplier 20 (NO in step S300), the operation server 300 judges whether or not a change in the purchase request 12 has been received from the controller 100 of the consuming entity 10 or a change in the sales request 22 has been received from the supplier terminal 200 of the supplier 20 (step S309). If a change in the purchase request 12 has been received from the controller 100 of the consuming entity 10 or a change in the sales request 22 has been received from the supplier terminal 200 of the supplier 20 (YES in step S300), the matching process from step S310 onwards is executed.

[0129] If neither a change in the purchase request 12 has been received from the controller 100 of the consuming entity 10 nor a change in the sales request 22 has been received from the supplier terminal 200 of the supplier 20 (NO in step S300), the process from step S300 onwards is repeated.

[0130] If no change in the purchase request 12 has been received from the controller 100 of the consuming entity 10 and no change in the sales request 22 has been received from the supplier terminal 200 of the supplier 20 (NO in step S300), the process from step S300 onwards is repeated.

[0131] The operation server 300 determines whether the newly received or updated request is a purchase request 12 or a sale request 22 (step S310).

[0132] If the newly received or updated request is a purchase request 12 ("purchase request" in step S310), the management server 300 sets the newly received or updated purchase request 12 as a purchase request 12 to be matched (step S312), and selects one of the sales requests 22 stored in the request queue 316 as a matching candidate (step S314).Then, the management server 300 compares the matching target purchase request 12 with the matching candidate sales request 22 to determine whether the request contents match each other (step S316).

[0133] If the contents of the matching purchase request 12 and the matching candidate sales request 22 match (YES in step S316), the management server 300 determines that the transaction is concluded, notifies the consuming entity 10 and the supplier 20 corresponding to the target purchase request 12 and sales request 22, respectively (step S318), and changes the status of the target purchase request 12 and sales request 22 to awaiting delivery completion of the target product (step S320). Then, the matching process ends.

[0134] If the contents of the matching target purchase request 12 and the matching candidate sales request 22 do not match each other (NO in step S316), the management server 300 The management server 300 judges whether the matching process has been completed for all the sales requests 22 stored in the request queue 316 (step S322). If there is any sales request 22 stored in the request queue 316 for which the matching process has not yet been performed (NO in step S322), the management server 300 selects one sales request 22 for which the matching process has not yet been performed as a matching candidate (step S324), and repeats the processes from step S316 onwards.

[0135] On the other hand, if the matching process has been completed for all sales requests 22 stored in the request queue 316 (YES in step S322), the management server 300 determines that no purchase requests 12 and sales requests 22 whose request contents match each other have been found, and terminates the matching process.

[0136] If the newly received or updated request is a sales request 22 ("sales request" in step S310), the management server 300 sets the newly received or updated sales request 22 as a matching target sales request 22 (step S332), and selects one of the purchase requests 12 stored in the request queue 316 as a matching candidate (step S334).Then, the management server 300 compares the matching target sales request 22 with the matching candidate purchase request 12 to determine whether the request contents match each other (step S336).

[0137] If the contents of the matching sales request 22 and the matching candidate purchase request 12 match (YES in step S336), the management server 300 determines that the transaction is concluded, notifies the supplier 20 and the consuming entity 10 corresponding to the target sales request 22 and purchase request 12, respectively (step S338), and changes the status of the target sales request 22 and purchase request 12 to awaiting delivery completion of the target product (step S340). Then, the matching process ends.

[0138] If the request contents of the sales request 22 to be matched and the purchase request 12 of the matching candidate do not match (NO in step S336), the management server 300 judges whether the matching process has been completed for all the purchase requests 12 stored in the request queue 316 (step S342). If the matching process has not been performed on any of the purchase requests 12 stored in the request queue 316 (NO in step S342), the management server 300 selects one purchase request 12 that has not yet been matched as a matching candidate (step S344), and repeats the processes from step S336 onwards.

[0139] On one hand, if the matching process has been completed for all purchase requests 12 stored in the request queue 316 (YES in step S342), the operation server 300 determines that no sales request 22 and purchase request 12 whose request contents match each other have been found, and ends the matching process.

[0140] <F. Modified Example> In the above description, a typical example of the commodity trading system 1 according to the present embodiment has been described, but the following various modified examples can be applied. Note that the modified examples described below can be arbitrarily combined and appropriately applied.

[0141] (f1:EVER / IP (registered trademark)) As the communication protocol of each device constituting the commodity trading system 1 according to the present embodiment, EVER / IP (registered trademark) provided by Connect Free Co., Ltd. may be adopted. When EVER / IP is adopted, each device of the controller 100, the supplier terminal 200, and the operation server 300 will have an authenticated IP address. That is, each device of the controller 100, the supplier terminal 200, and the operation server 300 will have a network interface (communication unit) that performs data communication with a destination using the authenticated IP address.

[0142] Here, the "authenticated IP address" means a state in which the validity of the IP address held by each device is guaranteed to the communication destination or a third party. In EVER / IP, the "authenticated IP address" means an IP address that is generated by an irreversible cryptographic hash function and is directly or indirectly authenticated by a certification authority. By using such an authenticated IP address, it can be guaranteed that the IP address used by each device for data communication is not spoofed.

[0143] More specifically, the authenticated IP address is generated using a key pair consisting of a private key and a public key held by each device, and a predetermined hash function. A hash value is calculated by inputting the public key into the predetermined hash function, and all or a part of the calculated hash value becomes the authenticated IP address of each device. By sharing the predetermined hash function between devices, it is possible to determine the IP address of the device that is the sender of the public key obtained from another device based on the public key, and to authenticate the authenticity of the public key.

[0144] For example, the controller 100 uses an authenticated IP address to perform data communication with the operation server 300, which is the destination of the generated purchase request 12. The supplier terminal 200 also uses an authenticated IP address to perform data communication with the operation server 300, which is the destination of the generated sale request 22. By using an authenticated IP address, the device itself that sent the purchase request 12 and sale request 22 can be authenticated, and fraudulent buying and selling due to spoofing or the like can be prevented.

[0145] (f2: Simplification of matching process) In the above explanation, an example of a matching process was given assuming that the same product is provided by multiple suppliers 20. However, if there is only one supplier 20 providing a specific product, the matching process may be simplified.

[0146] In this case, when the operation server 300 receives the purchase request 12 from the consuming entity 10 (controller 100), the operation server 300 may complete the transaction according to the contents of the received purchase request 12.

[0147] In this case, a price pre-agreed between the consuming entity 10 and the supplier 20 may be used.

[0148] (f3:Shipping cost) In the matching process between the purchase request 12 and the sales request 22, a delivery cost may be taken into consideration. That is, the operation server 300 determines whether the purchase request 12 and the sales request 22 match after reflecting the delivery cost for delivering a specific product from the supplier 20 to the consuming entity 10. When taking the delivery cost into consideration, the distance between the consuming entity 10 and the supplier 20 may be taken into consideration. An example of a method for calculating the delivery cost will be described below.

[0149] FIG. 13 is a diagram showing an example of a delivery fee definition 326 used in the product trading system 1 according to the present embodiment. The delivery fee definition 326 shown in FIG. 13 defines the delivery fee for each product ("Product A" in the example of FIG. 13). In the delivery fee definition 326, The distance between the consuming entity 10 and the supplier 20 is divided into sections (sections 1 to 5), and a delivery cost is defined for each section. When a delivery cost needs to be calculated in a purchase request 12 or a sales request 22, the delivery cost is determined by referring to the delivery destination information 352 of the consuming entity 10 and the delivery cost definition 326.

[0150] The shipping cost definition 326 shown in FIG. 13 may be utilized as the shipping cost definition for the sales request 22 .

[0151] Fig. 14 is a diagram showing another example of the delivery cost definition 327 used in the product trading system 1 according to the present embodiment. The delivery cost definition 327 shown in Fig. 14 basically defines the delivery cost for all products. In the delivery cost definition 327, the distance between the consuming entity 10 and the supplier 20 is divided into categories (categories 1 to 5), and the delivery cost is defined for each category.

[0152] If a calculation of shipping costs is required for any of the products, the weight of each product is determined by referring to weight table 328, which shows the weight of each product, and the shipping costs are determined by applying the determined weight to shipping cost definition 327.

[0153] 13 and 14 show an example in which the distance between the consuming entity 10 and the supplier 20 is divided into sections and the delivery cost is defined for each section, but the present invention is not limited to this, and the delivery cost may be defined per unit distance (e.g., 1 km). Furthermore, domestic and overseas delivery cost definitions may be defined separately.

[0154] As described above, in the product trading system 1 according to the present embodiment, the necessary delivery costs can be calculated by using the above-mentioned definition of delivery costs. The matching process may be performed taking into account the delivery costs calculated in this way.

[0155] (f4: usage fee) The cost of using the commodity trading system 1 according to this embodiment may be borne by either the consuming entity 10 or the supplier 20. For example, every time the consuming entity 10 purchases a commodity, an amount calculated by multiplying the commodity price by a predetermined rate (e.g., 1.0%) may be automatically debited from the consuming entity 10's account as a usage fee.

[0156] Alternatively, the supplier 20 who supplies the product may bear the usage fee according to the number of products sold or the sales amount. Furthermore, the supplier 20 who supplies the product may bear a fixed amount as the usage fee that is determined according to the number of products supplied, etc. Such usage fee burden can be designed arbitrarily.

[0157] However, it is preferred to implement a process linked to the accounts of the consuming entity 10 and the supplier 20 so that usage fees can be calculated and collected automatically.

[0158] (f5: meta-product) In the 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."

[0159] For example, various "detergent" products are offered, but some consumer entities 10 simply wish to purchase "detergent" without identifying a specific producer or product.

[0160] Therefore, for example, a meta-product that specifies a comprehensive product type may be defined without specifying a product such as "AAA detergent made by company A."

[0161] By storing in the operation server 300 association information indicating which products are included in such a meta-product, the consuming entity 10 can order "detergent" (regardless of which product).

[0162] On the other hand, the supplier 20 can provide any product as long as it matches the product type required by the meta-product, which makes it easier to dispose of inventory.

[0163] The type of products to be included in each meta product may be managed by the operation server 300, or conditions that can be included in each meta product may be specified, and the supplier 20 may sell the meta product according to those conditions. When managing meta products on the operation server 300 side, a table may be stored that associates a product identification number indicating a meta product with a product identification number indicating one or more specific products included in the meta product.

[0164] In this way, making meta-products available allows for more flexible product trading. (f6:Expiration date options) The consumer entity 10 and the supplier 20 may be able to cancel or withdraw their purchase request 12 and sale request 22, respectively, at any time until the transaction is completed. Furthermore, depending on the characteristics of the goods, purchases or sales may be required by a certain deadline.

[0165] Considering such needs, a validity period may be set for the purchase request 12 and the sale request 22. More specifically, when the consuming entity 10 and the supplier 20 generate any purchase request 12 and sale request 22, they may be able to add a validity period (validity period condition) for canceling or withdrawing the request if the transaction is not concluded.

[0166] For purchase requests 12 and sales requests 22 with a specified expiration date, if the transaction has not been concluded by the arrival of the specified expiration date, the management server 300 forcibly cancels the corresponding purchase request 12 or sales request 22. By adding such an expiration date condition to the purchase request 12 or sales request 22, it is possible to avoid a situation in which a transaction is concluded too late.

[0167] 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.

[0168] (f7: Stock availability option) Although the supplier 20 is scheduled to supply a particular product at all times, it may be possible that the supplier is temporarily unable to supply the product due to some circumstances. In such a case, the product will be delivered to the consumer entity 10 as soon as it arrives, but the consumer entity 10 will have to wait until the product arrives.

[0169] Therefore, when the consuming entity 10 generates the purchase request 12, the availability of the specified product in stock may be added as a condition. More specifically, the consuming entity 10 may be allowed to select whether to complete the transaction only if the supplier 20 has the product in stock, or whether to complete the transaction even if the supplier 20 does not have the product in stock.

[0170] If the condition is that the transaction will be concluded only if the supplier 20 has the item in stock, the transaction will be concluded only if the specified item is in the supplier's 20 inventory.

[0171] On the other hand, when it is specified that the transaction can be concluded even if the supplier 20 has no inventory, the consumption entity 10 may be presented with the time until the target product arrives at the supplier 20, etc.

[0172] (f8: Delivery start deadline option) There may be cases where the consumption entity 10 wants to obtain some product as soon as possible. Therefore, when the consumption entity 10 generates the purchase request 12, a deadline until the specified product is delivered from the supplier 20 may be added as a condition. More specifically, the consumption entity 10 may be able to specify the time from when the transaction is concluded until the product is delivered (e.g., within 6 hours after the conclusion of the transaction), or the deadline for delivering the product (e.g., 3:00 p.m. on October 1st).

[0173] When the purchase request 12 with such a condition added is generated, the operation server 300 receives information such as the deliverable time from the supplier 20, and determines whether the requirements of the purchase request 12 and the sales request 22 match.

[0174] (f9: Deliverable range option) Depending on the scale of the business of the supplier 20, the range within which the product can be delivered may be limited. Considering such a limitation on the delivery range, when the supplier 20 generates the sales request 22, the range within which the product can be delivered may be specified in advance. More specifically, the supplier 20 may be able to specify the range within which the product can be delivered (e.g., only within Japan, within 500 km, etc.).

[0175] When the sales request 22 with such a condition added is generated, the operation server 300 refers to the delivery destination information of the consumption entity 10 (information indicating the location of the consumption entity 10) and determines whether the requirements of the purchase request 12 and the sales request 22 match.

[0176] <G. Another form of the commodity trading system 1> In the above explanation, a commodity trading system 1 centered around the operation server 300 is exemplified, but a configuration that does not use such an operation server 300 may be adopted. In other words, a configuration similar to a kind of peer-to-peer may be adopted.

[0177] (g1: Supplier-led system) Fig. 15 is a diagram for explaining an overview of processing in another commodity trading system 1A according to the present embodiment. Referring to Fig. 15, the commodity trading system 1A includes one or more consuming entities 10 and a supplier 20. In the commodity trading system 1A shown in Fig. 15, there is no operation server 300, and instead the supplier 20 (supplier terminal 200) processes a purchase request 12 from the consuming entity 10 (controller 100).

[0178] That is, the supplier terminal 200 installed at the supplier 20 executes the matching process. However, in the matching process executed by the supplier terminal 200, since only a single supplier 20 generates a sales request 22, the process content is simplified.

[0179] In this way, without an operating server 300, communication may be carried out between the supplier 20 (supplier terminal 200) and one or more consuming entities 10 (controller 100) to process purchase requests 12 as needed.

[0180] In the commodity trading system 1A shown in FIG. 15, the supplier terminal 200 disposed at the supplier 20 has, in addition to the configuration shown in FIG. 3, the functions possessed by the operating server 300 (for example, the matching program 312, the settlement program 314, the request queue 316, and User information 318, etc.

[0181] (g2: System with delivery management server 400 added) In the merchandise trading system 1A shown in FIG. 15, a configuration example is shown in which a supplier 20 (supplier terminal 200) having the same functions as the operation server 300 of the merchandise trading system 1 shown in FIG. 1 is used. However, for the processing related to delivery, another server may be arranged.

[0182] FIG. 16 is a diagram for explaining an outline of processing in still another merchandise trading system 1B according to the present embodiment. Referring to FIG. 16, the merchandise trading system 1B corresponds to a configuration in which a delivery management server 400 is further added to the merchandise trading system 1A shown in FIG. 15.

[0183] The delivery management server 400 communicates with the supplier 20 (supplier terminal 200) and executes processing for managing delivery fees and delivery personnel. That is, the delivery management server 400 has delivery fee definitions 326 and 327 as shown in FIGS. 13 and 14, and may execute processing for determining delivery fees and processing for determining an appropriate delivery person from a plurality of delivery persons.

[0184] In this way, by arranging the delivery management server 400 in charge of processing related to delivery, requests from a plurality of suppliers 20 (supplier terminals 200) can be integrated to determine an appropriate delivery person 30, so that efficient delivery can be realized. Further, even if the available delivery persons are updated, only the information held by the delivery management server 400 needs to be updated, so that a flexible system can be realized.

[0185] <H. Other Forms> (h1: Application Example of Automatic Ordering Function) The automatic ordering function according to the merchandise trading system 1 of the present embodiment can be applied to various facilities and industries.

[0186] For example, it can be applied to a system that automatically orders hotel supplies (toothbrushes, towels, slippers, shampoo, toilet paper, etc.) In this case, by connecting the controller 100 to a hotel reservation system or by incorporating an automatic ordering program 108 (FIG. 2) into a part of the hotel reservation system, it is possible to acquire the total number of guests and the like, and to automatically order the required number of necessary supplies based on the acquired information such as the total number of guests.

[0187] Also, for example, the present invention can be applied to a system that automatically orders the necessary raw materials (milk, fruit, cups, straws, etc.) in a fresh juice shop. In this case, by connecting the controller 100 to a cash register or by incorporating an automatic ordering program 108 (FIG. 2) into a part of the cash register, the number and type of juices sold can be obtained, and the necessary raw materials can be automatically ordered in the required quantities based on the obtained number and type of juice.

[0188] In this case, since the amount of raw materials consumed varies for each type of juice, ingredient information such as the type and amount of raw materials consumed for each type of juice is specified in advance, and the type and amount of raw materials required can be determined by multiplying the specified ingredient information by the sales volume of each juice.

[0189] In this manner, the commodity trading system 1 according to the present embodiment can be applied to businesses in various fields.

[0190] (h2:account) Commodity trading system 1 also allows international commodity trading, in which case user accounts may be unified in a specific currency (e.g., Japanese yen or US dollar), or the user may select a specific currency from multiple currencies. When trading is carried out between accounts in different currencies, the exchange rate at the time of the transaction may be taken into consideration when transferring money between the accounts.

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

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

[0193] <I. Advantages> According to the commodity trading system 1 according to the present embodiment, when the controller 100 acquires information regarding the consumption state of the commodity from the target that consumes the commodity and determines that a predetermined condition is satisfied based on the acquired information, a purchase request 12 for purchasing the commodity is automatically generated and transmitted to the operation server 300 or the like. Then, a commodity transaction is executed via the operation server 300. As described above, according to the commodity trading system 1 according to the present embodiment, a platform that enables an automatic transaction according to the situation can be provided.

[0194] 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 claims are included.

Explanation of reference numerals

[0195] 1, 1A, 1B Commodity trading system, 10 Consumption entity, 12 Purchase request, 20 Supplier, 22 Sales request, 30 Delivery person, 50 Equipment, 52 Detergent tray, 54 Detergent, 56 History information, 100 Controller, 102, 201, 301 Processor, 104 Main memory, 106, 210, 310 Storage, 108 Automatic ordering program, 110 Control unit, 120, 203, 303 Network interface, 121 Product information, 122 Quantity information, 123 Desired price, 124 Delivery deadline, 130 Internal interface, 140 Sensing unit, 150 Output unit, 160 Estimation result, 162 Threshold value, 200 Supplier terminal, 202, 302 Main memory, 204, 304 Input unit, 205, 305 Display, 206, 306 Internal bus, 212 Inventory management program, 218 Inventory information, 250 User interface screen, 252, 2502 list, 254 product code field, 256 product name field, 258 sales price field, 260 sales quantity field, 262 remaining quantity field, 264 partial transaction field, 266 search button, 268 code reading button, 270 content change button, 272 update button, 300 management server, 312 matching program, 314 settlement program, 316 request queue, 318 user information, 326, 327 delivery cost definition, 328 weight table, 350, 360 management information, 352 delivery destination information, 354, 364 balance information, 356 purchase history, 366 sales history, 400 delivery management server.

Claims

1. A means for obtaining information regarding the consumption status of a product from the person who consumes the product, A means for predicting when the remaining quantity of the aforementioned product falls below a threshold and generating a purchase request, The system includes means for determining whether the content of the purchase request matches the content of one or more sales requests for goods received from one or more suppliers. A system in which, when the contents of a purchase request match the contents of any sales request, the purchase procedure for the goods in accordance with the purchase request is automatically executed based on that match.

2. The purchase request includes a delivery deadline determined based on the forecast, The system according to claim 1, wherein the means for determining whether a match is made is conditional on meeting the delivery deadline included in the purchase request.

3. The system according to claim 1, wherein the purchase request may include either a request to specify a particular product, or a request to accept any product of the same type as the aforementioned product.

4. The system according to claim 1, wherein the purchase request may include either a specific desired purchase price or the lowest selling price of the product offered by the one or more suppliers.

5. The system according to claim 1, wherein the purchase request includes identifying information for identifying the product and the desired quantity of the product.

6. The aforementioned purchase request includes delivery address information, The system according to claim 1, wherein the means for determining whether a match exists is the means for determining whether a match exists, based on the delivery address information included in the purchase request, and taking into account the delivery costs for delivering the goods.

7. The system according to claim 6, further comprising a calculation means for calculating a delivery fee for delivering the goods based on a delivery fee definition associated with the supplier or goods and the distance based on the delivery destination information.

8. The system according to any one of claims 1 to 6, wherein the purchase request is affixed with an electronic signature.

9. A method performed by one or more computers, A step of obtaining information about the consumption status of the product from the person who consumes the product, The steps include: predicting when the remaining quantity of the aforementioned product will fall below a threshold and generating a purchase request; The steps include determining whether the content of the purchase request matches the content of one or more sales requests for goods received from one or more suppliers, A method comprising the step of automatically executing a purchase procedure for goods in accordance with the purchase request if the contents of the purchase request match the contents of any sales request.

Images