Systems and methods

Abstract

To provide a platform that enables automatic transactions depending on situations.SOLUTION: A controller includes: a state information acquisition unit that acquires information on a consumption state of a product from a target that consumes the product; and a request generation unit that generates a purchase request for purchasing the product to transmit it to the outside when it is determined that a predetermined condition is met based on the acquired information. The purchase request includes information that identifies a product for which purchase is desired.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a controller, a commodity trading system, and an automatic ordering program that can realize 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, 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 sale and purchase of goods between buyers and sellers, but such conventional electronic trading systems merely electronically carry out communication between buyers and sellers, and the start of the transaction itself is determined 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 regarding a consumption status of a product from a target consuming 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 determines that a predetermined condition is satisfied based on the acquired information. The purchase request includes information specifying 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 the target that consumes the product.

[0010] The request generating unit may attach a digital signature to the purchase request and transmit it to an external party. The request generating unit may include the location information of the controller in the purchase request and transmit it to an external device.

[0011] The controller may further include a communication unit that performs data communication with the 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] An automatic ordering program executed on a computer according to yet another aspect of the present disclosure causes the computer to execute the steps of acquiring information regarding the consumption status of a product from a subject who consumes the product, determining whether predetermined conditions are met based on the acquired information, and, if it is determined that the predetermined conditions are met, generating a purchase request to purchase the product and transmitting the purchase request to an external party. The purchase request includes information specifying the product desired to be purchased. [Effects of the Invention]

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

[0015] [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 schematic diagram showing an example of a configuration of a consuming entity that constitutes the commodity trading system according to the present embodiment. [Figure 3] FIG. 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. [Figure 4] 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 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] FIG. 2 is a schematic diagram showing an example of a configuration for acquiring a state value by a controller of the commodity trading system according to the present embodiment. [Figure 7] FIG. 10 is a schematic diagram showing another example of a configuration for acquiring a state value by a controller of the commodity trading system according to the present embodiment. [Figure 8] FIG. 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. [Figure 9] FIG. 10 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. [Figure 10] FIG. 2 is a diagram illustrating an example of user management by the operation server of the commodity trading system according to the present embodiment. [Figure 11] 10 is a flowchart showing a processing procedure for matching processing in the management server of the commodity trading system according to the present embodiment. [Figure 12]It is a flowchart showing the processing procedure of matching processing in an operation server of a product trading system according to the present embodiment. [Figure 13] It is a diagram showing an example of a shipping fee definition used in the product trading system according to the present embodiment. [Figure 14] It is a diagram showing another example of a shipping fee definition used in the product trading system according to the present embodiment. [Figure 15] It is a diagram for explaining an outline of processing in another product trading system according to the present embodiment. [Figure 16] It is a diagram for explaining an outline of processing in yet another product trading system according to the present embodiment.

Mode 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 the description thereof 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 an outline of 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 products for which repeated purchases such as daily necessities and consumables are assumed are suitable.

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

[0021] In this specification, "supplier 20" encompasses any entity that provides any product, and is typically assumed to be a producer 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 encompasses any entity that is capable of making decisions regarding product transactions.

[0022] In the following explanation, 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 an example in which detergent, fabric softener, etc. are automatically ordered from a washing machine depending on the situation without any user operation.

[0023] When predetermined conditions (including both objective and subjective conditions) are met, each consuming entity 10 transmits a purchase request 12 to the operation server 300, the purchase request 12 including information specifying the desired product and the number of products it wishes to purchase. The purchase request 12 may also include the desired price.

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

[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 requirements of the purchase request 12 match the requirements 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 requirements 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 delivers the goods that are the subject of the transaction to the consumer entity 10 Note that the supplier 20 itself may perform the delivery of the goods, but typically, any delivery provider 30 may perform it.

[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 circuitry. Control unit 110 is a computing entity for providing functions and executing processes according to this embodiment.

[0032] The control unit 110 may be configured to use a processor and memory as shown in Figure 2, and to have the processor execute computer-readable instructions stored in the memory. Alternatively, the control unit 110 may be configured using a hardwired circuit such as an ASIC (Application Specific Integrated Circuit) that incorporates 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 an FPGA (Field-Programmable Gate Array). Alternatively, the control unit 110 may be realized by appropriately combining a processor, a memory, an ASIC, an FPGA, and the like.

[0033] In the 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 configured, for example, with 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 this embodiment are realized.

[0036] The storage 106 is 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 realizing an automatic ordering function as described below. It stores 08.

[0037] In a configuration such as that shown in FIG. 2 in which processor 102 executes computer-readable instructions stored in memory, the memory corresponds to 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 unit 140 , and an output unit 150 .

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

[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. If 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 USB (Universal Serial Bus) port, a serial port such as IEEE1394, or a legacy parallel port. If the network interface 120 is configured as a wireless interface, it may include a processing circuit and an antenna for wireless communication with devices, routers, mobile base stations, etc. Wireless communication supported by the network interface 120 includes, for example, 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 the target 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 product consumption, such as the number or amount of product remaining in the target, the total amount or consumption rate of the product in the target, the history of product addition or consumption in the target, and changes over time in product addition or consumption in the target.

[0042] The internal interface 130 performs data communication with a device 50 such as a washing machine. The internal interface 130 can acquire necessary state values ​​from control logic implemented in the device 50. Typically, the internal interface 130 acquires information (e.g., inventory information, operation history information, etc.) managed by the device that consumes the product.

[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] Output unit 150 is a component for externally presenting the processing results of control unit 110. Output unit 150 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display. Output unit 150 may also be any indicator, speaker, or the like.

[0045] The controller 100 may further include a secure storage 152. The secure storage 152 is a storage unit that stores information necessary to realize secure processing. Like the storage 106, the secure storage 152 may be configured with a nonvolatile 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 processes such as adding a digital signature to information output from the controller 100 to prevent information tampering and spoofing. The identification information 158 includes information for uniquely identifying the controller 100 (for example, a serial number or a manufacturing number).

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

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

[0049] (b2:Supplier 20) 3 is a schematic diagram showing an example of the configuration of supplier terminal 200 used by 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 its 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 employed.

[0052] The main memory 202 is composed of a volatile storage device such as a DRAM or SRAM. The storage 210 is composed of a non-volatile storage device such as a hard disk or SSD, and holds various programs and data executed by the processor 201. Of the programs stored in the storage 210, designated program code is loaded onto the main memory 202, and the processor 201 sequentially executes computer-readable instructions included in the program code loaded onto the main memory 202, thereby realizing various functions as described below.

[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 that is the subject of 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, It may also include an Ethernet port to allow communication over the Internet.

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

[0056] All or part of the supplier terminal 200 may be implemented using a hardwired circuit such as an ASIC incorporating circuitry corresponding to computer-readable instructions, or may be implemented using circuitry corresponding to computer-readable instructions on an FPGA, or may be implemented by appropriately combining the processor 201, main memory, ASIC, FPGA, etc.

[0057] The supplier terminal 200 may further include a component for reading an inventory management program 212, which is comprised of computer-readable instructions, from a non-transitory medium storing the program. The medium may be, for example, an optical medium such as a DVD (Digital Versatile Disc) 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: Administration Server 300) 4 is a schematic diagram showing an example of the configuration of operation server 300 that constitutes commodity trading system 1 according to the present embodiment. Typically, 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 by, for example, 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 made up of non-volatile storage devices such as hard disks and SSDs (Solid State Drives), and The storage 310 stores various programs and data to be executed by the processor 301. Of the programs stored in the storage 310, designated program code is loaded onto the main memory 302, and the processor 301 sequentially executes computer-readable instructions included in the program code loaded onto the main memory 302, thereby realizing various functions as will be described later.

[0062] Typically, 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 about consuming entities 10 and suppliers 20. 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 execute the consumption engine in the computer. 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 exchanging data with terminals of the consuming entity 10 and the supplier 20, etc. The network interface 303 may include, for example, an Ethernet port to allow communication over the Internet.

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

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

[0067] The operation server 300 may further have a component for reading out the stored program and the like from a non-transitory medium storing 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, a semiconductor medium such as a USB memory, etc.

[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 ordering 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 (that is, generates and transmits a purchase request 12) a commodity corresponding to the condition.

[0071] In the following explanation, a washing machine is shown as a typical example of device 50, but the invention is not limited to this and can apply to any device. Examples of home appliances include copiers, multifunction devices, and 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 fixtures (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 for the automatic ordering function of commodity trading system 1 according to the present embodiment. Each step shown in FIG. 5 is realized by processor 102 of controller 100 executing automatic ordering program 108.

[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 may be, for example, values ​​such as the remaining amounts of detergent, fabric softener, and bleach.

[0075] The controller 100 determines whether the acquired state value of the device 50 satisfies a predetermined condition (step S102). That is, the controller 100 determines whether 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 processing is 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 processing 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 status of any target. That is, the controller 100 has a request generation function that, when it determines that a predetermined condition is met based on the acquired information (status value of the target device 50), generates a purchase request 12 for purchasing the commodity and transmits it to an external party (operation server 300).

[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 the required amount of detergent is supplied to the washing tub each time a wash is performed in 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 in accordance with 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 in accordance with 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 a predetermined condition is satisfied based on the calculated remaining amount of detergent 54.

[0082] 7 is a schematic diagram showing another example of a configuration for acquiring a state value by controller 100 of commodity trading system 1 according to the present embodiment. In FIG. 7, an example is shown in which internal interface 130 of controller 100 is connected to 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 the laundry execution history of device 50. Controller 100 then calculates the amount of detergent consumed and the remaining amount, etc., based on the acquired laundry execution history.

[0084] 7(B) shows an example of an estimation result 160 of the remaining amount of detergent calculated by the controller 100. The controller 100 determines whether 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 remaining amount of detergent falls below the threshold value 162 or by predicting the time when the remaining amount of detergent will fall below the threshold value 162.

[0085] 6 and 7, any method for acquiring the status value may be adopted depending on the target device 50 and the target product. Furthermore, the user may be responsible for some or all of the processing and configuration for acquiring the status value. For example, a configuration may be adopted in which the user visually checks the remaining amount and inputs the visually determined remaining amount 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 acquire the remaining amount of detergent 54 in the target device 50, and can therefore set, for example, a condition for generating the purchase request 12 such that the acquired 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 purchase request 12 generated by controller 100 of commodity trading system 1 according to the present embodiment.

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

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

[0091] The quantity information 122 is optional information, and is arbitrarily set as information for specifying the number of items to be purchased. For example, if the number of items 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 desired purchase price. In this case, a transaction will be concluded with the supplier 20 that presents the lowest price on the operation server 300 described below.

[0093] In this way, purchase request 12 includes product information 121, which is an example of information specifying the product desired to be purchased. 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 for purchasing 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 what 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] Thus, 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 performed 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 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 that generates a sales request 22 for selling products and transmits it to the outside (operation server 300).

[0101] 9 is a schematic diagram showing an example of a user interface screen provided by supplier terminal 200 of commodity trading system 1 according to the present embodiment. Referring to FIG. 9, user interface screen 250 accepts instructions from supplier 20 for generating 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, and a partial transaction field 264 for setting whether, when the requested details are met for only a portion of the desired number of units, the transaction is to be concluded for only the number of units that meets the requested details.

[0103] The supplier 20 registers the products available for sale in the list 252 and inputs the desired selling price (selling price column 258) and the desired 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 available products and register them in the list 2502. Alternatively, the supplier 20 can select the code reading button 268 and register the available products in the list 2502 by reading the 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 desired selling price (selling price column 258) and the desired selling price (sales 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] The supplier terminal 200 generates a sales request 22 via a user interface screen 250 as shown in FIG.

[0107] Products handled in the product trading system 1 may be identified using identification information attached to packages or the like. Such identification information may be, for example, a product identification number such as a JAN (Japanese Article Number) code, an EAN (European Article Number) code, a GTIN-13, or a GTIN-8. Using such product identification numbers can facilitate the handling of products distributed between multiple countries.

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

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

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

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

[0112] (e1: User Management) The operation server 300 of the product 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 product trading system 1 according to this 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 and 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 unique points used in the product trading system 1.

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

[0117] The management information 350 includes a purchase history 356 that indicates 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 balance information 354 every time the consuming entity 10 generates a purchase request 12, in addition to when a transaction is completed.

[0118] 10(B), the management information 360 for managing each supplier 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 a 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 relating to transactions between the consuming entity 10 and the supplier 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 this embodiment. Figures 11 and 12 show a commodity trading method in which a computer executes a commodity trade between a consuming entity 10 and a supplier 20.

[0122] The steps shown in FIGS. 11 and 12 are typically implemented by the processor 301 of the management server 300 executing the matching program 312 and the settlement program 314 (corresponding to a commodity trading program).

[0123] 11 and 12, the management server 300 determines whether it has received a purchase request 12 from the controller 100 of the consuming entity 10 or a sales 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 sales request 22 from the supplier terminal 200 (YES in step S300), the management server 300 stores the received purchase request 12 or sales request 22 in the request queue 316 (step S302).

[0124] Next, the operation server 300 determines whether 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 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 onwards. 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 of 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 determines 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 from the controller 100 of the consuming entity 10 nor a change in the sales request 22 from the supplier terminal 200 of the supplier 20 has been received (NO in step S300), the processing 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 processing 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).The management server 300 then compares the matching target purchase request 12 with the matching candidate sales request 22 to determine whether their request contents match (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 purchase request 12 to be matched and the sales request 22 of the matching candidate do not match (NO in step S316), the management server 300 The management server 300 determines whether the matching process has been completed for all sales requests 22 stored in the request queue 316 (step S322). If there are sales requests 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 process 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 the sales request 22 to be matched (step S332), and selects one of the purchase requests 12 stored in the request queue 316 as a matching candidate (step S334).The management server 300 then compares the sales request 22 to be matched with the purchase request 12 of the matching candidate to determine whether their request contents match (step S336).

[0137] If the matching target sales request 22 and the matching candidate purchase request 12 match each other (YES in step S336), the management server 300 determines that the transaction is concluded, notifies the supplier 20 and the consumer 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 determines whether the matching process has been completed for all purchase requests 12 stored in the request queue 316 (step S342). If there are purchase requests 12 stored in the request queue 316 for which the matching process has not yet been performed (NO in step S342), the management server 300 selects one purchase request 12 for which the matching process has not yet been performed as a matching candidate (step S344), and repeats the processes from step S336 onwards.

[0139] On the other 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 various modified examples as follows 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 legitimacy 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 forged.

[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 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 sent the public key based on the public key obtained from another device, and to authenticate its authenticity.

[0144] For example, the controller 100 uses an authenticated IP address to communicate data 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 communicate data with the operation server 300, which is the destination of the generated sale request 22. By using an authenticated IP address, the device that sent the purchase request 12 or sale request 22 can be authenticated, preventing fraudulent buying and selling through impersonation or the like.

[0145] (f2: Simplifying the 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, but 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 transaction may be concluded in accordance with the contents of the received purchase request 12.

[0147] In this case, a price previously agreed upon 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, delivery costs may be taken into consideration. That is, the operation server 300 determines whether the purchase request 12 and the sales request 22 match after taking into account the delivery costs for delivering a specific product from the supplier 20 to the consuming entity 10. When taking this delivery cost into consideration, the distance between the consuming entity 10 and the supplier 20 may also 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 a delivery fee for each product ("product A" in the example of FIG. 13). In the delivery fee definition 326, the consuming entity 10 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 calculation of a delivery cost is required for a purchase request 12 or a sales request 22, the delivery cost is determined by referring to the delivery destination information 352 and the delivery cost definition 326 of the consuming entity 10.

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

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

[0152] If a shipping fee needs to be calculated for any product, the weight of each product is determined by referring to weight table 328, which shows the weight of each product, and the shipping fee is determined by applying the determined weight to shipping fee 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 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.

[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-described delivery cost definition. The matching process may be performed taking into account the delivery costs calculated in this manner.

[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, each time the consuming entity 10 purchases a commodity, a usage fee calculated by multiplying the commodity price by a predetermined rate (e.g., 1.0%) may be automatically deducted from the account.

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

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

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

[0159] For example, various products are offered for "detergent," but some consumer entities 10 simply want 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 consumer 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 clear out 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 the operation server 300 manages meta products, it may store a table that associates a product identification number that identifies a meta product with a product identification number that identifies 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 at will until the transaction is completed. Furthermore, depending on the characteristics of the product, the purchase or sale may be required by a specific deadline.

[0165] Taking such needs into consideration, expiration dates may be set for purchase requests 12 and sales requests 22. More specifically, when the consuming entity 10 and the 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.

[0166] For purchase requests 12 and sales requests 22 with specified expiration dates, 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 the 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 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 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 conclude the transaction only if the supplier 20 has the product in stock, or whether to conclude 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 product in stock, the transaction will be concluded only if the specified product is in stock at the supplier 20.

[0171] On the other hand, when it is specified that a 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 a 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 (for example, within 6 hours after the transaction is concluded), or the deadline for delivering the product (for example, 3:00 PM on October 1st).

[0173] When a 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 business scale of the supplier 20, the range within which the product can be delivered may be limited. Considering such limitations on the delivery range, when the supplier 20 generates a 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 (for example, only within Japan, within 500 km, etc.).

[0175] When a 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 product trading system 1> In the above description, 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 also be employed. In other words, a configuration similar to a kind of peer-to-peer system may also be employed.

[0177] (g1: supplier-driven system) Figure 15 is a diagram illustrating an overview of processing in another commodity trading system 1A according to the present embodiment. Referring to Figure 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 Figure 15, there is no operating 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, only a single supplier 20 generates a sales request 22, so the process content is simplified.

[0179] In this way, without deploying 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 of the operating server 300 (for example, the matching program 312, the settlement program 314, the request queue 316, and User information 318 may also be included.

[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 yet 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 may have delivery fee definitions 326, 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 personnel.

[0184] Thus, 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 personnel 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 according to 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 controller 100 to a hotel reservation system or by incorporating 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, based on the acquired information such as the total number of guests, automatically order the required number of necessary supplies.

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

[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 number of sales of each juice.

[0189] In this way, 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 dollars), or the user may select a specific currency from multiple currencies. When a transaction is made between accounts in different currencies, the exchange rate at the time of the transaction may be taken into consideration when transferring payment 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 can be omitted.

[0192] (h3: Distributed Deployment) In the above description, an example where the operation server 300 executes matching processing and settlement processing is shown. However, each processing may be implemented on different servers, 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 trading 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, commodity trading is executed via the operation server 300. Thus, according to the commodity trading system 1 according to the present embodiment, a platform that enables automatic trading according to the situation can be provided.

[0194] The disclosed embodiments should be considered illustrative in all respects and not restrictive. The scope of the present invention is indicated by the claims rather than the above description, and is intended to include all modifications within the meaning and scope equivalent to the claims.

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 operation 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 status information acquisition unit that acquires information about a consumption status of a product from a target that consumes the product; a request generation unit that, when it is determined that a predetermined condition is satisfied based on the acquired information, automatically generates a purchase request for purchasing the product and transmits the purchase request to an external device; The purchase request includes identification information, which is a product identification number commonly used for products distributed among multiple countries, for identifying the product being requested to be purchased, and accepting means for accepting one or more sales requests for selling goods from one or more suppliers; A system comprising: a matching processing unit that determines whether the request content of the purchase request matches the request content of any of the one or more sales requests, and determines the sales requests that match the request content of the purchase request.

2. 2. The system according to claim 1, wherein the identification information includes identification information according to at least one of a JAN (Japanese Article Number) code, an EAN (European Article Number) code, GTIN-13, GTIN-8, and GTIN-14.

3. 3. The system according to claim 1, wherein the identification information can include information indicating a comprehensive product type in addition to a product identification number commonly used for products distributed among the plurality of countries.

4. The purchase request further includes a number of items requested for purchase and a desired price for purchasing the items; The system according to any one of claims 1 to 3, wherein the desired price can be designated as either a desired price value or a lowest price.

5. The system according to any one of claims 1 to 4, wherein the purchase request further includes a delivery deadline determined based on the acquired information.

6. a position information acquisition unit that acquires position information of the controller including the state information acquisition unit; The system according to any one of claims 1 to 5, wherein the purchase request further includes location information of the controller.

7. a communication unit that uses the authenticated IP address to perform data communication with a destination of the purchase request; 7. The system according to claim 1, wherein the request generation unit attaches a digital signature to the purchase request and transmits the purchase request to an external party.

8. acquiring information about a consumption state of the product from a subject who consumes the product; and when it is determined that a predetermined condition is satisfied based on the acquired information, automatically generating a purchase request for purchasing the product and transmitting the purchase request to an external party; The purchase request includes identification information, which is a product identification number commonly used for products distributed among multiple countries, for identifying the product being requested to be purchased, and receiving one or more sales requests to sell goods from one or more suppliers; determining whether the request content of the purchase request matches the request content of any of the one or more sales requests, and determining the sales requests that match the request content of the purchase request.

9. 9. The method of claim 8, wherein the identification information includes identification information according to at least one of the following: JAN (Japanese Article Number) code, EAN (European Article Number) code, GTIN-13, GTIN-8, and GTIN-14.

10. The method according to claim 8 or 9, wherein the identification information can include information indicating a comprehensive product type in addition to a product identification number commonly used for products distributed among the plurality of countries.

Images