IoT Product Logistics Management System

Abstract

An Internet of Things (IoT) product logistics management system comprises at least one product, a reader / writer device, a cloud device, and multiple agent devices. The reader / writer device is a device with wireless communication capabilities and a specific media access control (MACC) address. The cloud device has the function of communicating with clients, verifying that the client device is one of the reader / writer devices in the IoT through the client's specific MACC address. The agent server devices have their own URLs and passwords and can communicate with the cloud device. Once the cloud device verifies that the reader / writer device is an IoT device, it ensures that the reader / writer device can only communicate with the agent server devices, which then communicate with the cloud device.

Description

Technical Field

[0001] This invention relates to a system for cloud service applications, and more particularly to a management system that uses an Internet of Things (IoT) connectivity architecture to transmit the logistics, warehousing, and sales status of products to cloud devices for processing using this IoT connectivity architecture. Background Technology

[0002] With the rapid development of technology and the dramatic changes in economic structure, the traditional "business-to-business" competition has evolved into a "supply chain-to-supply chain" competition. Enhancing supply chain information integration capabilities to improve logistics efficiency and reduce costs is a crucial issue for businesses to develop competitiveness. With advancements in Radio Frequency Identification (RFID) technology, RFID is increasingly being adopted in supply chain activities and process transformation.

[0003] Among the characteristics of logistics management, two key factors contributing to improved industrial competitiveness are efficiency and completeness. Firstly, efficiency involves more than just delivering goods to customers within a specific timeframe; it also includes integrated delivery methods that deliver different goods to different customers simultaneously. Secondly, completeness encompasses not only providing the physical integrity of the goods but also providing information about their contents. To enhance these two characteristics, manufacturers must obtain real-time information about the goods themselves. Integrating RFID technology with a cloud-based monitoring system can help businesses and their partners (distributors) control logistics in real time, enabling the generation of real-time goods information.

[0004] Real-time information provided by RFID and cloud monitoring systems can improve customer satisfaction with the integrity of goods. Goods integrity encompasses not only the physical integrity of the goods but also the provision of information about their contents. Furthermore, specifically regarding the process from production at the factory to delivery to the customer, RFID allows logistics centers to monitor goods and provide real-time information for further risk assessment.

[0005] Efficiency and security are the two most important aspects of logistics management. Therefore, for manufacturers and shippers, effectively tracking and managing goods is one of the most critical issues. If manufacturers want to improve these two aspects, they must obtain real-time information about the goods themselves. RFID and cloud monitoring systems can generate complete real-time cargo information.

[0006] Furthermore, through the establishment of RFID and cloud monitoring systems, inventory levels at the business end can be quickly transmitted back to the corporate headquarters, enabling the headquarters to grasp firsthand product sales and market demand in the shortest possible time. This effectively improves the previous ordering and procurement timelines, which were often measured in months. Inaccurate estimations could lead to inventory buildup (overestimation) or lost sales opportunities (underestimation). When the corporate headquarters can monitor sales and market demand in real time, the company can react quickly. Shorter ordering times mean the company can adjust supply according to actual market conditions, effectively reducing risk and increasing profits.

[0007] The ability to create these applications stems from the establishment of the Internet of Things (IoT) connectivity architecture. The IoT connects everyone and everything around them through a highly integrated cloud network. This includes manufacturers, consumers, machines, raw materials, product manufacturing processes, logistics management, product sales, and consumer habits. Everything from product production to sales, and even the big data analysis of sales data used to infer or predict consumer habits, can be connected to the IoT platform via product sensors (e.g., RFID, electronic tags) and software. Similarly, efficiency and security are the two most important key conditions for the IoT; however, efficiency and security are contradictory indicators. Therefore, balancing efficiency and security is crucial for the successful application of logistics management systems. Summary of the Invention

[0008] To practically apply the aforementioned needs to enterprise operations, the main objective of this invention is to provide an IoT connectivity architecture for a product logistics management system within the Internet of Things (IoT), comprising: a read / write device, which is a device with wireless communication capabilities, and whose identity as a read / write device in the IoT is confirmed via a specific Media Access Control (MAC) address; a cloud device, which has the capability to communicate with clients and can confirm that a client device is a read / write device in the IoT via a specific MAC address; and a proxy server device, which has a URL and password and can communicate with the cloud device. After the cloud device provides the URL and password of the proxy server device to the client device, the read / write device can only communicate with the proxy server device, and the proxy server device then communicates with the cloud device to transmit information from the client device to the cloud device. This approach can improve the security and efficiency of the IoT and reduce the cost of business operations.

[0009] Another major objective of this invention is to provide an goods logistics management system using the Internet of Things connectivity architecture of this invention, which can improve the efficiency of logistics management and reduce operating costs.

[0010] In accordance with the above objectives, the present invention first provides a connectivity architecture for the Internet of Things (IoT), comprising: a client device having wireless communication capabilities and a specific user identifier; a cloud device having the capability to communicate with the client device, and identifying the client device as one of the client devices in the IoT through the specific user identifier; and a proxy server device having a URL and password, and capable of communicating with the cloud device; wherein, after the cloud device provides the URL and password of the proxy server device to the client device in the IoT, the client device can only communicate with the proxy server device, and the proxy server device then communicates with the cloud device to transmit information from the client device to the cloud device.

[0011] The present invention further provides a connectivity architecture for the Internet of Things (IoT), comprising: multiple client devices, each of which is a device with wireless communication capabilities and each of which has a specific user identifier; a cloud device, which has the function of communicating with each client device and identifies each client device as one of the client devices in the IoT through each specific user identifier; and multiple proxy server devices, each of which has a URL and password and can communicate with the cloud device; wherein, after the cloud device provides the URL and password of each proxy server device to at least one client device in the IoT to form a pair, each client device can only communicate with the paired proxy server device, and the proxy server device then communicates with the cloud device to transmit information from each client device to the cloud device. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the IoT connectivity architecture of the present invention.

[0013] Figure 2 This is a schematic diagram of another embodiment of the IoT connectivity architecture of the present invention.

[0014] Figure 3 This is a flowchart of the IoT connection method of the present invention.

[0015] Figure 4 This is a schematic diagram of another embodiment of the IoT connectivity method of the invention.

[0016] Figure 5 This is a schematic diagram of the logistics management system architecture for the Internet of Things (IoT) product of the present invention.

[0017] Figure 6 This is a schematic diagram of the read / write device of the present invention.

[0018] Figure 7A This is a schematic diagram of the cloud device structure of the present invention.

[0019] Figure 7BThis is a schematic diagram of the security judgment data stored in the memory module of this invention.

[0020] Figure 7C This is a schematic diagram of the warehouse data stored in the memory module according to the present invention.

[0021] Figure 8 This is a schematic diagram of the first embodiment of the Internet of Things (IoT) product logistics management system of the present invention.

[0022] Figure 9 This is a schematic diagram of the second location area in the first embodiment of the IoT product logistics management system of the present invention.

[0023] Figure 10 This is a schematic diagram of product warehousing management in the second embodiment of the Internet of Things product logistics management system of this invention.

[0024] Figure 11 This is a schematic diagram of product sales management in a second embodiment of the Internet of Things (IoT) product logistics management system of the present invention.

[0025] Figure 12 This is a schematic diagram illustrating the display of manager information in this invention.

[0026] [Explanation of Key Component Symbols]

[0027] Communication directions S1~S10

[0028] Product 10

[0029] Electronic Tag 12

[0030] Read / write device 31 / 32 / 33 / 41 / 42 / 43 / 51 / 52 / 53 / 61 / 62 / 63 / 71

[0031] Client device (read / write device) 100

[0032] Controller 110 / 210 / 310 / 410

[0033] Antenna 120 / 220 / 320 / 420

[0034] 130 input / output interfaces

[0035] Wireless transmission module 140 / 240 / 340 / 440

[0036] Positioning device 150

[0037] Demagnetizing module 170

[0038] Cloud device 500

[0039] Receive / Transmit Interface Module 510

[0040] Data processing module 520

[0041] Memory module 530

[0042] Display module 600

[0043] Agent servo device 700 Detailed Implementation

[0044] To enable those skilled in the art to better understand and implement the objectives, technical features, and advantages of the present invention, the technical features and implementation methods of the present invention will be explained in the following description in conjunction with the accompanying drawings, and preferred embodiments will be further illustrated. However, the following description of the embodiments is not intended to limit the present invention, and the drawings used in the following text are schematic representations related to the features of the present invention.

[0045] First, please refer to Figure 1 This is a schematic diagram of the IoT connection architecture of the present invention. Figure 1 As shown, the IoT connectivity architecture consists of a client device 100, a cloud device 500, and at least one broker device 700. The client device 100 is a device with wireless communication capabilities and a specific user identifier. The cloud device 500 communicates with the client device 100, using the client device's specific user identifier to identify the client device 100 as one of the client devices in the IoT. The broker device 700 has its own URL and password and can communicate with the cloud device 500.

[0046] In the IoT connection architecture of this invention, the client device 100 is a device with a constantly changing floating IP (Internet Protocol) wireless communication function (e.g., personal computer, laptop computer, smartphone, smart portable device, smart reading device, etc.), and each client device 100 has a unique identifier (e.g., a code set by the manufacturer at the time of manufacture; or hardware data such as MAC address) to generate a universally unique identifier (uuid) for the client device 100, used for identification or to prevent hacker intrusion. Furthermore, in the IoT connection architecture of this invention, the cloud device 500 is a fixed Domain Name System (DNS), which has server functions and the ability to communicate with the client device 100. The cloud device 500 is composed of at least a receiving / transmitting interface module, a data processing module, and a memory module; therefore, the cloud device 500 has recorded the uuids of all clients belonging to the IoT of this invention and stored them in the memory module, forming a database. Furthermore, the proxy server device 700 is a constantly changing floating IP address. Its primary function is to receive encoded data strings confirmed to be transmitted by the client device 100 in the Internet of Things (IoT) and directly transmit them to the cloud device 500. It's important to note that after receiving the data string from the client device 100, the proxy server device 700 does not perform any processing; it directly transmits the received data string. Only after the cloud device 500 receives the data string from the proxy server device 700 and decodes it will it process the data string transmitted by the client device 100. Clearly, in the IoT connection architecture of this invention, during the entire process of the client device 100 delivering the data string to the cloud device 500, the cloud device 500 does not directly expose its address. Therefore, the probability of the cloud device 500 being attacked by hackers can be reduced, significantly improving the security of the IoT.

[0047] In a preferred embodiment of the IoT connectivity architecture of the present invention, multiple client devices 100 can be divided into multiple groups, with each group corresponding to or paired with a proxy server device 700. Therefore, in the IoT connectivity architecture of the present invention, there can be multiple proxy server devices 700, such as... Figure 2As shown. When the cloud device 500 determines that one of the proxy server devices 700 has been hacked, it can choose to shut down the attacked proxy server device 700 or re-establish the URL and password of a new proxy server device 700, which can further ensure the security of the Internet of Things of this invention. In addition, in the embodiments of this invention, the proxy server device 700 chooses to use the MQTT (Message Queuing Telemetry Transport) communication standard protocol to transmit data strings. Since MQTT is a protocol designed for the Internet of Things, especially a lightweight message transmission protocol based on the publish / subscribe model, it was invented in 1999 by Dr. Andy Stanford-Clark of IBM and Dr. Arlen Nipper of Arcom. It was originally designed for communication between a large number of remote sensors and control devices with limited computing power and operating on low-bandwidth, unreliable networks. Therefore, MQTT has the advantages of small and lightweight data transmission, and can have great advantages in bandwidth and speed. Because it requires very low network bandwidth, it also requires low hardware resources, which can improve the efficiency of IoT systems or various business operation systems using this IoT architecture (such as logistics management or product production traceability). As a result, it can effectively reduce the cost of business operations.

[0048] Next, the process and method by which the Internet of Things of the present invention actually completes the connection will be described in detail.

[0049] Please continue to refer to Figure 1 First, the client device 100 logs in to the cloud device 500 (e.g., ...). Figure 1 (The communication direction is indicated by S1 in the diagram). For example, client device 100 logs into cloud device 500 via HTTPS (Hypertext Transfer Protocol Secure) to start the IoT system. Then, when cloud device 500 receives a request from client device 100 (such as...), ... Figure 1In the communication direction indicated by S2, the cloud device 500 first verifies whether the MAC address used by the client device 100 is already stored in the cloud device 500's database. If it is confirmed that the MAC address used by the client device 100 is already stored in the cloud device 500's database, a client identification code (client UUID) is generated. Then, the cloud device 500 generates a pair of keys exclusively used by the client. In a preferred embodiment of the present invention, this key uses an RSM asymmetric key, thus generating a pair of client_pub_key and client_pub_key. The RSM asymmetric key has a long decoding time, so it has high security. In addition, in another preferred embodiment, the cloud device 500 can also selectively generate a symmetric key client_share_key exclusive to the client device 100. Therefore, in a preferred embodiment of the present invention, RSM asymmetric keys and symmetric keys can be selectively used together. Since symmetric keys have short decoding times but relatively low security, the client_share_key needs to be changed frequently to ensure security. To this end, the cloud device 500 further generates / sets a change time (share_key_expiry date time) to improve security by periodically changing the share_key_expiry date time. Therefore, when the cloud device 500 detects that the constantly changing client_share_key has exceeded the share_key_expiry date time setting, it automatically generates a new client_share_key to ensure security. When the cloud device 500 confirms that the MAC Address data of a client device 100 is the same as that stored in the database, it determines that this client device 100 is a client in this Internet of Things. Afterwards, the cloud device 500 will send the generated UUID and key information back to the client device 100 (e.g., ...). Figure 1 The S3 identifier in the table indicates the communication direction. The information returned to the client device 100 includes: client_uuid, server_pub_key (this server_pub_key is the same as client_pub_key; since all client devices 100 use the same pub_key, it can also be called server_pub_key) and client_pri_key.

[0050] Furthermore, if, upon receiving a request from client device 100, cloud device 500 determines that the MAC address used by client device 100 is not in its database, and therefore does not belong to a client device within this IoT network, it stores this MAC address information in another database for subsequent comparison. It's important to note that while the S3 communication feedback mechanism is generally error-free, errors can still occur. For example, if the connection fails due to an excessively long wait for server response, client device 100 will re-execute the request. However, this time, cloud device 500 will determine that the MAC address is already recorded in its database and will still send back the corresponding UUID. At this point, the key pair generated and sent back to client device 100 by cloud device 500 will be updated. Therefore, even if a fake device uses any method to spoof the MAC address of client device 100, it cannot obtain the same key. In other words, only one specific UUID can exist in the system.

[0051] Next, as Figure 1 The S4 identifier indicates the communication direction. When client device 100 requests client_share_key, share_key_expiry date / time, MQTT_Broker IP, and MQTT_Broker username and password (username / password) via HTTPS using an encoded client_uuid (i.e., the client_uuid is converted to garbled characters based on server_pub_key); when cloud device 500 receives the garbled client_uuid, it decodes it based on server_pub_key to verify the client_uuid's correctness; after cloud device 500 confirms the client_uuid's correctness, it sends the client_share_key, share_key_expiry date / time, MQTT_Broker IP, and MQTT_Broker username and password back to client device 100 after encoding them with client_pub_key (e.g., ...). Figure 1 (The communication direction indicated by S5 in the diagram).

[0052] Furthermore, in a preferred embodiment of the present invention, the IP address, username, and password of the MQTT_Broker can be obtained in two separate transactions; for example, the first transaction (e.g., ...) Figure 1In the communication direction indicated by S4, client device 100 uses an encoded client_uuid (i.e., the client_uuid is converted into garbled characters based on the server_pub_key) to request client_share_key, share_key_expiry date / time, and MQTT_Broker IP via HTTPS. When cloud device 500 receives the garbled client_uuid, it decodes it based on the server_pub_key to verify its correctness. After cloud device 500 confirms the client_uuid is correct, it sends the client_share_key, share_key_expiry date / time, and MQTT_Broker IP back to client device 100 after encoding them with the client_pub_key (e.g., ...). Figure 1 The communication direction indicated by S5 in the code). The second time (e.g.) Figure 1 (The communication direction is indicated by S6 in the code). The client device 100 then uses the encoded client_uuid (i.e., the client_uuid will be converted into garbled characters according to the server_pub_key) to "request" the MQTT_Broker account and password via HTTPS. When the cloud device 500 receives the garbled client_uuid, it will decode it according to the server_pub_key to confirm whether the client_uuid is correct. After the cloud device 500 confirms that the client_uuid is correct, the cloud device 500 will send the MQTT_Broker account and password, etc., back to the client device 100 after encoding them with the client_pub_key (e.g., ...). Figure 1 (The S7 indicator in the diagram represents the communication direction). It should be noted that for the first and second attempts, only the MQTT_Broker's IP address, username, and password need to be obtained separately; no other restrictions apply.

[0053] Clearly, during the identification and verification process between client device 100 and cloud device 500, the HTTPS protocol used is a hybrid cryptographic anti-hacking and secure communication protocol (Secure Sockets Layer; SSL) or Transport Layer Security (TLS). It is a recognized security protocol, and the recognized credentials required by cloud device 500 can be verified by client device 100 through the digital signature of the certification authority to confirm whether the information was directly transmitted from cloud device 500. Therefore, when hackers attempt to tamper with, steal, or deny information during transmission, these security authentications can be used to prevent password tampering or theft.

[0054] Next, as Figure 1 The S8 identifier indicates the communication direction. After the client device 100 obtains relevant data from the cloud device 500, the client device 100 will immediately connect to the proxy server device 700. However, before connecting to the proxy server device 700, it must be confirmed that the received information is complete. This complete information includes: 1. Server_pub_key; 2. Client_pub_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. Client_Share_key; 6. Share_key_expiry date and time. After confirming that it has received complete information, the client device 100 will use the client_share_key to encode the client_uuid and the data content (datainvolved) that the client device 100 wants to send to the cloud, and then upload it to the proxy server device 700 (i.e., MQTT Broker).

[0055] In a preferred embodiment of the present invention, the client device 100 further checks whether the Share_key_expiry datetime has expired (e.g., the expiration date is 2015 / 0501); if the Share_key_expiry datetime has expired (e.g., the result of the check date is 2015 / 0502), the client device 100 will re-encode the client_uuid (i.e., the client_uuid will be converted into garbled characters according to the server_pub_key) and request a new share_key via HTTPS. The cloud device 500 receives the client_uuid, which has been converted to garbled characters. It then decodes the client_uuid using the server_pub_key to verify its correctness. Once the cloud device 500 confirms the client_uuid is correct, it sends the new share_key_expiry datetime encoded in client_pub_key back to the client device 100. Furthermore, to enhance security, the share_key_expiry datetime can be periodic or random, depending on the cloud device 500's settings.

[0056] Once the client device 100 confirms that it has received the complete information, it now knows the MQTT_Broker IP address, MQTT_Broker username, and password of the proxy server device 700. Therefore, the client device 100 can upload the encoded client_uuid and data string to the proxy server device 700 (e.g., ...). Figure 1 (The S8 symbol indicates the communication direction); then, after receiving the encoded client_uuid and data string uploaded by the client device 100, the proxy server device 700 directly (that is, without any processing) transmits the information uploaded by the client device 100 to the cloud device 500. Clearly, during the entire IoT process where the client device 100 transmits its information string to the cloud device 500, the cloud device 500 does not directly expose its address, thus reducing the probability of the cloud device 500 being attacked by hackers. Since the proxy server device 700 simply transmits the data uploaded by the client device 100 directly to the cloud device 500, the probability of the MQTT_Broker IP, MQTT_Broker account, and password of the proxy server device 700 being cracked is reduced, further increasing the security of the IoT communication process.

[0057] Next, as Figure 1In the communication direction indicated by S9, after receiving the data (i.e., the encoded client_uuid and data string) directly transmitted by the proxy server device 700, the cloud device 500 immediately decodes it using the client_share_key and verifies whether the received client_uuid and data string are complete and correct. If correct, it stores the data in the memory module, waiting for the user to use these received data strings for specific applications. If the received client_uuid and data string are incomplete or incorrect, they are recorded. It should be noted that the purpose of verifying incorrect information is to prevent or reduce the probability of successful hacking by using deep learning through artificial intelligence or by adding, modifying, or correcting verification mechanisms by the Internet of Things system. In this embodiment, incorrect information includes, for example: (1) a web crawler discovers that counterfeit products of certain goods are rampant; or (2) the same client_uuid set at the beginning of the program appears in two completely different places at the same time. In this case, the IoT system will notify the company's inspectors or issue a warning. The inspectors can take actions such as observation or ignoring the issue to achieve the effect of early warning and anti-hacking; or (3) when the device 500 itself continuously receives suspicious information from a specific proxy server device 700, such as unknown client_uuid information; when incorrect information continues to appear, it is determined that the proxy server device 700 may be hacked, and the cloud device 500 can choose to shut down this proxy server device 700 (e.g., Figure 1 (The communication direction is indicated by S10 in the diagram).

[0058] In embodiments of the present invention, the client_share_key encoding method can be combined with a hash function to prevent tampering, wherein the hash function can be selected from MD5, SHA-1, or SHA-256, etc. Simultaneously, the client_share_key can also be combined with different decoding methods, such as block ciphers, streaming ciphers, ECB mode, or the aforementioned hybrid methods, which can not only more effectively increase the difficulty of cracking but also without sacrificing decoding time.

[0059] Please refer to Figure 2 This is a schematic diagram of another embodiment of the IoT connectivity architecture of the present invention. Figure 2As shown, the IoT connectivity architecture consists of multiple client devices 100, a cloud device 500, and at least one proxy device 700. Each client device 100 is a device with wireless communication capabilities and a specific user identifier. The cloud device 500 has the ability to communicate with each client device 100, using each client device's unique user identifier to identify it as one of the client devices 100 in the IoT. The proxy server device 700 has its own URL and password and can communicate with the cloud device 500. Because... Figure 2 Implementation examples and Figure 1 The implementations share the same basic connectivity architecture, with the only difference being that after the cloud device 500 provides each proxy server device's URL, account, and password to at least one client device 100 in the Internet of Things (IoT) and forms a pair, these paired client devices 100 can only communicate with their paired proxy server devices 700, which in turn communicate with the cloud device 500 to transmit data from each client device 100 to the cloud device 500. Figure 2 The actual process of completing a connection in the Internet of Things (IoT) is briefly described below.

[0060] Please continue to refer to Figure 2 First, each client device 100 logs in to the cloud device 500 via HTTPS. Next, upon receiving a request from each client device 100, the cloud device 500 verifies whether the MAC address used by each client device 100 is stored in its database. If the MAC address is indeed stored, a unique client UUID is generated for each client. Then, the cloud device 500 generates a unique key for each client based on its configuration. Once the cloud device 500 determines that each client device 100 is a client in this IoT application, it sends back the generated UUID and key information to each client device 100. This information includes the client_uuid, server_pub_key, and client_pri_key.

[0061] Next, each client device 100 can request client_share_key, share_key_expiry datetime, MQTT_Broker IP, and MQTT_Broker username and password (username / password) via HTTPS using its encoded client_uuid. When the cloud device 500 receives the client_uuid converted to garbled characters, it will decode it according to its respective server_pub_key to verify the correctness of each received client_uuid. After the cloud device 500 confirms that the client_uuid is correct, it will encode the client_share_key, share_key_expiry datetime, MQTT_Broker IP, and MQTT_Broker username and password using client_pub_key and send them back to the client device 100. For example: the IP address, account, and password of the agent device (Broker-1) are sent back to Client-1 to Client-5; the IP address, account, and password of the agent device (Broker-2) are sent back to Client-6 to Client-15; the IP address, account, and password of the agent device (Broker-3) are sent back to Client-16 to Client-50. Clearly, this Internet of Things has paired 50 individual client devices 100 with 3 agent server devices 700 to communicate with the cloud device 500. Next, after each client device 100 obtains relevant data through the cloud device 500, the client device 100 will connect to its paired proxy server device 700. Simultaneously, once each client device 100 confirms that the information received from the cloud device 500 includes: 1. Server_pub_key; 2. Client_pub_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. Client_Share_key; 6. Share_key_expiry datetime, it will use the client_share_key to encode the client_uuid and the data content to be transmitted from the client device 100 to the cloud before uploading it to the proxy server device 700 (i.e., the MQTT Broker).

[0062] Since each client device 100, after confirming receipt of complete information, already knows the MQTT_Broker IP, MQTT_Broker account, and password of its paired proxy server device 700, it can upload the encoded client_uuid and information string to the paired proxy server device 700. Then, upon receiving the encoded client_uuid and information string uploaded by the paired client device 100, each proxy server device 700 immediately transmits the uploaded information directly (i.e., without any processing) to the cloud device 500. Clearly, during the process of the client device 100 transmitting its information string to the cloud device 500, the cloud device 500 does not directly expose its address, thus reducing the probability of the cloud device 500 being attacked by hackers. Since each agent server device 700 simply transmits the data uploaded by the client device 100 directly to the cloud device 500, the probability of the MQTT_Broker IP and MQTT_Broker account and password of the agent server device 700 being cracked can be reduced, thus increasing the security of the IoT communication process. Next, after receiving the data (i.e., the encoded client_uuid and data string) directly transmitted by each proxy server device 700, the cloud device 500 decodes it using each client_share_key and verifies whether the received client_uuid and data string are complete and correct. If correct, it stores the data in the memory module, waiting for the user to use the received data string for specific applications. If the received client_uuid and data string are incomplete or incorrect, it is recorded. In this embodiment, the generation of incorrect information may include: each client publishing information at a certain regularity. If a client publishes information at an abnormal or excessive frequency, it is considered incorrect information; or the proxy server device 700 itself publishes information at a frequency other than MQTT and attempts to connect to the cloud device 500. When incorrect information continues to appear, it is determined that the proxy server device 700 may be under attack by hackers. The cloud device 500 can then choose to shut down this proxy server device 700.

[0063] In summary, the main technical means of the IoT connection architecture of the present invention is as follows: after the cloud device 500 confirms that each client device 100 is a user of this IoT, the cloud device 500 sends back the MQTT_Broker IP, MQTT_Broker account, and password of the proxy server device 700 to each client device 100. Then, each client device 100 connects to the proxy server device 700 according to the received MQTT_Broker IP, MQTT_Broker account, and password, and encodes the data string to be transmitted by each client device 100 and uploads it together to the proxy server device 700. Then, the proxy server device 700 directly transmits the data string transmitted by the client device 100 to the cloud device 500 for decoding and processing without processing the data string transmitted by the client device 100. Clearly, the IoT connection architecture of this invention is divided into two stages for connection. After the client device 100 is identified in the first stage, the client device 100 can only connect to the proxy server device 700 in the second stage. Since the first stage is completed before the client device 100 connects, when the client device 100 is transmitting data, it can only connect and communicate with the proxy server device 700. Therefore, the cloud device 500 does not directly expose its address, which reduces the probability of the cloud device 500 being attacked by hackers and effectively improves the security of the IoT connection architecture.

[0064] Next, the connection method and process of the IoT connection architecture of the present invention will be described in detail. Through the connection method and process of the IoT connection architecture, the innovation of the present invention using the agent server device 700 can be more clearly understood.

[0065] Please refer to Figure 3 This is a flowchart of the IoT connection method of the present invention. Figure 3 As shown, the IoT connection method of the present invention includes:

[0066] Step 1: The client device 100 logs in to the cloud device 500. For example, the client device 100 logs in to the cloud device 500 via HTTPS in order to start the IoT system.

[0067] Step 2: When the cloud device 500 receives the request from the client device 100, the cloud device 500 will first verify whether the MAC address used by the client device 100 has been stored in the database of the cloud device 500.

[0068] Step 3: When the cloud device 500 confirms that the MAC address used by the client device 100 has been stored in the database of the cloud device 500, it determines that the data of the client device 100 is correct and that it is the client device 100 in this Internet of Things. Then the cloud device 500 will generate a client identification code (client UUID) and a pair of keys used exclusively by the client. In this embodiment, the key uses a highly secure RSM asymmetric key; thus, a pair of client_pub_key and client_pri_key can be generated. The generated UUID and key information are then sent back to the client device 100. This information sent back to the client device 100 includes: client_uuid and server_pub_key (this server_pub_key is the same as client_pub_key). Furthermore, if, after receiving a request from the client device 100, the cloud device 500 determines that the MAC address used by the client device 100 is not in its database, and therefore determines that the MAC address used by the client device 100 is not a client device in this IoT, then this MAC address information is stored in another database for subsequent comparison.

[0069] Step 4: Client device 100 determines whether the UUID and key information generated by cloud device 500 have been correctly received; when client device 100 confirms that it has correctly received the UUID and key information, client device 100 will then use the encoded client_uuid (i.e., client_uuid will be converted into garbled characters according to server_pub_key) to request client_share_key, MQTT_Broker IP of proxy server device 700 and MQTT_Broker account and password (username / password) from cloud device 500 via HTTPS.

[0070] Step 5: When the cloud device 500 receives the client_uuid converted to garbled characters, it will decode it according to the server_pri_key to confirm whether the client_uuid is correct. After the cloud device 500 confirms that the client_uuid is correct, the cloud device 500 will encode the client_share_key, the MQTT_Broker IP of the proxy server device 700, and the MQTT_Broker account and password in the form of client_pub_key and send them back to the client device 100.

[0071] Step 6: After the client device 100 obtains relevant data from the cloud device 500, the client device 100 will immediately decode it using the client_pri_key and confirm that the received information is complete. This complete information includes: 1. Server_pub_key; 2. Client_pri_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. client_Share_key. Once the client device 100 confirms that it has received complete information, it will connect to the proxy server device 700. If the client device 100 determines that the received information is incomplete, it will return to step 4 and request again from the cloud device 500 to obtain the client_share_key, the MQTT_Broker IP of the proxy server device 700, and the MQTT_Broker username and password (username / password).

[0072] Step 7: Client device 100 connects to agent server device 700 using MQTT_Broker IP, MQTT_Broker account and password; at the same time, it also uses client_share_key to encode client_uuid and the data content (data involved) that client device 100 wants to transmit to cloud device 500, and then uploads it to agent server device 700.

[0073] Step 8: After receiving the encoded client_uuid and information string uploaded by the client device 100, the proxy server device 700 immediately transmits the information uploaded by the client device 100 directly (that is, without any processing) to the cloud device 500.

[0074] Step 9: After receiving the data directly transmitted by the proxy server device 700, the cloud device 500 immediately decodes it using the client_share_key and verifies whether the received client_uuid and data string are complete and correct.

[0075] Step 10: When the cloud device 500 determines that the received client_uuid and data string are complete and correct, it stores the decoded client data string in the memory module, waiting for the user to use these received data strings for specific applications; if the received client_uuid and data string are incomplete or incorrect, it records them; in this embodiment, incorrect information includes (1) the client_uuid corresponding to a certain IP is incorrect, which may be a problem of theft; (2) if a certain client_uuid is used in conjunction with Geo Location data upload, it can be verified by verifying the rationality of GeoLocation (whether a certain client_uuid is in Asia one minute and in North America the next minute); when incorrect information continues to appear, it is determined that the proxy server device 700 may be attacked by hackers; then the cloud device 500 can choose to shut down this proxy server device 700.

[0076] Clearly, in the entire IoT architecture's connection process, steps 1 through 6 involve establishing a connection between each client device 100 and the cloud device 500 before the device leaves the factory. This means that each client device 100 receives complete information from the cloud device 500 upon leaving the factory, including: 1. Server_pub_key; 2. Client_pri_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. client_Share_key. When the IoT system starts, the data string that each client device 100 needs to transmit to the cloud device 500 for processing is sent to the proxy server device 700 based on the MQTT_Broker IP. The proxy server device 700 then directly transmits the client device 100's data string to the cloud device 500. Therefore, during the information transmission process from steps 7 to 10, the cloud device 500 does not directly expose its address, thus reducing the probability of the cloud device 500 being attacked by hackers. Since the proxy server device 700 simply transmits the data uploaded by the client device 100 directly to the cloud device 500, the probability of the MQTT_Broker IP and MQTT_Broker account and password of the proxy server device 700 being cracked can be reduced, thus increasing the security of the IoT communication process.

[0077] Next, please refer to Figure 4 This is a flowchart of another embodiment of the IoT connection method of the present invention. Figure 4 As shown, the IoT connection method of the present invention includes:

[0078] Step 1: The client device 100 logs in to the cloud device 500. For example, the client device 100 logs in to the cloud device 500 via HTTPS in order to start the IoT system.

[0079] Step 2: When the cloud device 500 receives the request from the client device 100, the cloud device 500 will first verify whether the MAC address used by the client device 100 has been stored in the database of the cloud device 500.

[0080] Step 3: When the cloud device 500 confirms that the MAC address used by the client device 100 has been stored in the database of the cloud device 500, it determines that the data of the client device 100 is correct and that it is the client device 100 in this Internet of Things. Then the cloud device 500 will generate a client identification code (client UUID) and a pair of keys used exclusively by the client. In this embodiment, the key uses a highly secure RSM asymmetric key; thus, a pair of client_pub_key and client_pri_key can be generated. The generated UUID and key information are then sent back to the client device 100. This information sent back to the client device 100 includes: client_uuid and server_pub_key (this server_pub_key is the same as client_pub_key). Furthermore, if, after receiving a request from the client device 100, the cloud device 500 determines that the MAC address used by the client device 100 is not in its database, and therefore determines that the MAC address used by the client device 100 is not a client device in this IoT, then this MAC address information is stored in another database for subsequent comparison.

[0081] Step 4: Client device 100 determines whether it has correctly received the UUID and key information generated by cloud device 500. When client device 100 confirms that it has correctly received the UUID and key information, client device 100 will then use the encoded client_uuid (i.e., client_uuid will be converted into garbled characters according to server_pub_key) to request client_share_key, share_key_expiry date and time, MQTT_Broker IP of proxy server device 700, and MQTT_Broker account and password (username / password) from cloud device 500 via HTTPS.

[0082] In a preferred embodiment of the present invention, this key uses an RSM asymmetric key; thus, a pair of client_pub_key and client_pri_key can be generated. The RSM asymmetric key has a long decoding time, resulting in high security. Furthermore, in another preferred embodiment, the cloud device 500 can selectively generate a client device 100-specific symmetric key, client_share_key. Therefore, in a preferred embodiment of the present invention, the RSM asymmetric key and the symmetric key can be used selectively. Since the symmetric key has a short decoding time, its security is relatively low, therefore the client_share_key needs to be changed frequently to ensure security. For this purpose, the cloud device 500 further generates a constantly changing share_key_expiry date time, thereby improving security by periodically changing the client_share_key. Therefore, when the cloud device 500 detects that the constantly changing client_share_key has exceeded the set change time, it automatically generates a new client_share_key to ensure security.

[0083] Step 5: After receiving the client_uuid converted to garbled characters, the cloud device 500 will decode it according to the server_pri_key to confirm whether the client_uuid is correct. After the cloud device 500 confirms that the client_uuid is correct, the cloud device 500 will encode the client_share_key, share_key_expiry date and time, the MQTT_Broker IP of the proxy server device 700, and the MQTT_Broker account and password in client_pub_key and send them back to the client device 100.

[0084] Step 6: After the client device 100 obtains the relevant data from the cloud device 500, the client device 100 will immediately decode it using client_pri_key and confirm that the received information is complete. This complete information includes: 1. Server_pub_key; 2. Client_pri_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. client_Share_key; 6. share_key_expiry date and time. Once the client device 100 confirms that it has received complete information, it will connect to the proxy server device 700. If the client device 100 determines that the received information is incomplete, it will return to step 4 and request the information again from the cloud device 500.

[0085] Step 7: Client device 100 connects to agent server device 700 using MQTT_Broker IP, MQTT_Broker account and password; at the same time, it also uses client_share_key to encode client_uuid and the data content (data involved) that client device 100 wants to transmit to cloud device 500, and then uploads it to agent server device 700.

[0086] Step 8: Client device 100 checks whether the Share_key_expiry date time has expired; if the check result is not expired, the encoded client_uuid and data string content are uploaded to the proxy server device 700; if the check result is expired, it will return to step 4 and request a new Share_key_expiry date time from the cloud device 500. For example, if the expiration date is 2015 / 0501, and the check result has already exceeded the Share_key_expiry datetime (e.g., the check result is 2015 / 0502), then the client device 100 will re-obtain the new share_key_expiry datetime via HTTPS using an encoded client_uuid (i.e., the client_uuid will be converted to garbled characters based on the server_pub_key). When the cloud device 500 receives the garbled client_uuid, it will decode it according to the server_pub_key to verify the client_uuid's correctness. After the cloud device 500 confirms the client_uuid is correct, it will send the new share_key_expiry datetime back to the client device 100 after encoding it with the client_pub_key. Furthermore, to increase security, the shared_key_expiry datetime can be set periodically or as a random variable, which can be determined by the cloud device 500.

[0087] Step 9: After receiving the encoded client_uuid and information string uploaded by the client device 100, the proxy server device 700 immediately transmits the information uploaded by the client device 100 directly (that is, without any processing) to the cloud device 500.

[0088] Step 10: After receiving the data directly transmitted by the proxy server device 700, the cloud device 500 immediately decodes it using the client_share_key and verifies whether the received client_uuid and data string are complete and correct.

[0089] Step 11: When the cloud device 500 determines that the received client_uuid and data string are complete and correct, it stores the decoded client data string in the memory module, waiting for the user to use these received data strings for specific applications; if the received client_uuid and data string are incomplete or incorrect, it records them; in this embodiment, incorrect information includes (1) the client_uuid corresponding to a certain IP is incorrect, which may be a problem of theft; (2) if a certain client_uuid is used in conjunction with Geo Location data upload, it can be verified by verifying the rationality of GeoLocation (whether a certain client_uuid is in Asia one minute and in North America the next minute). When incorrect information continues to appear, it is determined that the proxy server device 700 may be attacked by hackers; then the cloud device 500 can choose to shut down this proxy server device 700.

[0090] Clearly, in the entire IoT architecture's connection process, steps 1 through 6 involve each client device 100 establishing a connection with the cloud device 500 before it leaves the factory. This means that each client device 100 receives complete information from the cloud device 500 upon leaving the factory, including: 1. Server_pub_key; 2. Client_pri_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / password; 5. client_Share_key; 6. share_key_expiry date and time. When the IoT system starts, the data string that each client device 100 needs to transmit to the cloud device 500 for processing is sent to the proxy server device 700 based on the MQTT_Broker IP. The proxy server device 700 then directly transmits the client device 100's data string to the cloud device 500. Therefore, during the information transmission process from steps 7 to 10, the cloud device 500 does not directly expose its address, thus reducing the probability of the cloud device 500 being attacked by hackers. Since the proxy server device 700 simply transmits the data uploaded by the client device 100 directly to the cloud device 500, the probability of the MQTT_Broker IP and MQTT_Broker account and password of the proxy server device 700 being cracked can be reduced, thus increasing the security of the IoT communication process.

[0091] Next, the present invention can also be used in Figure 3In step 4, the process of client device 100 obtaining the MQTT_Broker IP, MQTT_Broker account, and MQTT_Broker password from cloud device 500 is executed in two steps. For example, the first step involves client device 100 requesting client_share_key and MQTT_Broker IP via HTTPS using an encoded client_uuid (i.e., the client_uuid is converted to garbled characters based on server_pub_key). When cloud device 500 receives the garbled client_uuid, it decodes it based on server_pub_key to verify its correctness. After cloud device 500 confirms the client_uuid is correct, it then sends the client_share_key and MQTT_Broker IP to cloud device 500. The IP address and other information are encoded using the `client_pub_key` and sent back to client device 100. The second step involves client device 100 using the encoded `client_uuid` (which is converted to gibberish using the `server_pub_key`) to request the MQTT_Broker account and password via HTTPS. When cloud device 500 receives the gibberished `client_uuid`, it decodes it using the `server_pub_key` to verify its correctness. Once cloud device 500 confirms the `client_uuid` is correct, it sends the MQTT_Broker account and password, encoded using the `client_pub_key`, back to client device 100. It's important to note that of the information requested in the first and second steps, only the MQTT_Broker's IP address, account, and password are required to be obtained in two separate transactions; other information is not restricted.

[0092] Next, the implementation of the Internet of Things architecture of the present invention in the product logistics management system will be described in detail.

[0093] First, please refer to Figure 5 This is a schematic diagram of the IoT product logistics management system architecture of the present invention. Figure 5As shown, a product logistics management system of the present invention includes: multiple products 10, electronic tags 12 configured on each product, at least one client device 100 (e.g., personal computer, laptop computer, smartphone, smart portable device, smart reading device, etc.), and each client device 100 can read and transmit information inside the electronic tag 12 and transmit the information inside the electronic tag 12 to a cloud device 500 via a proxy server device 700, and a display device 600 connected to the cloud device 500. The logistics management system uses a wireless network to form a communication link between each other. Each client device 100 is a wireless communication device with a floating IP address, and each client device 100 has a specific user identifier. The cloud processing device 500 is a fixed domain name system (DNS), which has the function of a server and the function of communicating with each client device 100. The specific user identifier of each client device 100 confirms that each client device 100 is one of the client devices in the Internet of Things. The proxy server device 700 (i.e., MQTT) A broker is a dynamic, floating IP address with a URL and password. Its primary function is to receive encoded data strings from client devices 100 in the Internet of Things (IoT) and transmit them directly to the cloud device 500, enabling communication with the cloud device 100. The cloud device 500 provides each client device 100 in the IoT with the URL and password of a proxy server 700. These client devices 100 can only communicate with the proxy server 700, which in turn communicates with the cloud device 500 to transmit product information 10 from each client device 100 to the cloud device 100. After processing, the cloud device 100 displays the processed results on a display device 600.

[0094] Next, please refer to Figure 6 This is a schematic diagram of the structure of the client device (e.g., personal computer, laptop computer, smartphone, smart portable device, smart reading device, etc.) of the present invention; as shown Figure 6 As shown, the client device 100 comprises a controller 110, multiple antennas 120, multiple input / output interfaces 130, and a wireless transmission module 140; next, please refer to... Figure 7A This is a schematic diagram of the cloud device structure of the present invention; as shown below. Figure 7AAs shown, the cloud device 500 consists of a receive / transmit interface module 510, a data processing module 520, and a memory module 530. A security judgment database has been established in the memory module 530, including data such as the device number, user identifier (e.g., Media Access Control Address MAC Address), the name or number of the storage location, and the coordinates (including latitude and longitude) of its location. Therefore, the data processing module 520 performs comparisons and verifications, for example, comparing whether the user identifier (e.g., Media Access Control Address MAC Address) used by each client device 100 has been stored in the memory module 530 database of the cloud device 500. Furthermore, the cloud device 500 can also communicate with each client device 100, the proxy server device 700, and the display module 600 through the receive / transmit interface module 510.

[0095] When the logistics management system is operating, each client device 100 has logged into the cloud device 500 via HTTPS through the wireless transmission module 140, and has confirmed that each client device 100 is a client device in the Internet of Things. At the same time, each client device 100 has also confirmed that it has received complete information, including: 1. Server_pub_key; 2. Client_pri_key; 3. MQTT_Broker IP; 4. MQTT_Broker username / passward; 5. client_Share_key; 6. Share_key_expiry date time; its login and verification process is as described in the aforementioned embodiments. In this embodiment of the logistics management system, the client device 100 is a read / write device. It can send an electrical signal to the electronic tag 12 on the product 10 via the antenna 120, triggering the electronic tag 12 to transmit its internally stored information. The antenna 120 of the read / write device receives the information transmitted by the electronic tag 12, which is then transmitted to the controller 110 via the input / output interface 130 for processing. After encoding the client_uuid and electronic tag 12 information data using the client_share_key, the wireless transmission module 140 transmits the encoded information to the proxy server device 700. The proxy server device 700, upon receiving the data string from the client device, does not perform any processing but directly transmits the received data string. The cloud device 500's receive / transmit interface module 510 receives the data from the proxy server. After the data string from the service device 700 is processed, it will be decoded by the data processing module 520. At this time, the information inside the electronic tag 12 can be stored in the storage space set by the memory module 530, for example, stored in the storage space set by a specific company; or the information inside the electronic tag 12 can be simultaneously transmitted to the display module 600 for display; or the data processing module 520 can process the information inside multiple electronic tags 12 in a specific way before transmitting it to the display module 600 to display the set information status. Among them, when performing security identification processing, the data processing module 520 can also compare the data such as the number, user identifier, name or number of the warehouse, and coordinates (including latitude and longitude) of each reader / writer 100 received by the receiver / transmitter interface module 510 with the data stored in the memory module 530, such as... Figure 7B The diagram shows the security judgment data stored in the memory module 530 of this invention; if the received client_uuid and data string are incomplete or incorrect, they are recorded.

[0096] In this embodiment, the generation of incorrect information may include: each client device 100 publishing information at a certain regularity; if a client device 100 publishes information at an abnormal or excessive frequency; or the client_uuid corresponding to the IP of a client device 100 is incorrect, there may be a problem of identity theft; or, if a client_uuid is used in conjunction with GeoLocation data upload, the validity of GeoLocation can be verified (whether a client_uuid is in Asia one minute and North America the next); or the proxy server device 700 itself publishes information at frequencies other than via MQTT and attempts to connect to the cloud device 500, etc.; these are considered incorrect information. When incorrect information continues to appear, it is determined that the proxy server device 700 may be under hacker attack; then the cloud device 500 can choose to shut down this proxy server device 700. In addition, the method of transmitting the information processed by the cloud device 500 to the display module 600 can be wireless transmission (WiFi, Bluetooth) or wired transmission. Clearly, in the IoT connection architecture of this invention, during the process of the client device 100 transmitting the data string to the cloud device 500, the cloud device 500 does not directly expose its address, thus reducing the probability of the cloud device 500 being attacked by hackers and significantly improving the security of the Internet of Things.

[0097] It should be emphasized that, as described in the foregoing detailed description, in the subsequent description of the product logistics management system embodiments of the present invention, each client device 100 has logged into the cloud device 500 through the wireless transmission module 140, and it has been confirmed that each client device 100 is a client device in the Internet of Things. At the same time, each client device 100 has also confirmed that it has received complete information, including the MQTT_Broker IP and MQTT_Broker account and password of the agent server device 700, etc., which will not be described in detail here.

[0098] Next, please refer to Figure 8 A schematic diagram of the first embodiment of the IoT product logistics management system of the present invention. (See diagram below.) Figure 8As shown, the product logistics management system of the present invention includes a first location area (1), such as a warehouse where products are stored; and the product 10 can be any goods, such as sports shoes, leather bags, clothing and other consumer products. The first location area 1 stores multiple products 10, and each product 10 is equipped with an electronic tag 12. These electronic tags 12 can be affixed one by one after the products 10 are stored in the first location area 1. At the same time, the electronic tag 12 stores at least the product name and identification code (ID code) of the product 10. The first location area 1 has an entrance and exit, and at least one first reader / writer device 31 / 32 / 33 that can be used as a client device 100 is configured at the entrance and exit (for example, the security identification codes of the three first reader / writer devices are A001, A002 and A003 respectively). Each first reader / writer device 31 / 32 / 33 has a security identification code, the name or number of the warehouse it is located in, and the coordinates (including latitude and longitude) of its location. The purpose of configuring multiple first reader / writer devices at the entrance and exit is to effectively improve the speed and accuracy of product information reading and writing, and reduce the error rate of product information reading and writing, when the number of products passing through the entrance and exit per unit time increases.

[0099] When a product 10 stored in the first location area 1 needs to be transported to a sales point, each product 10 must pass through at least one first reader / writer device 31 / 32 / 33 configured at the entrance / exit. The first antenna 120 on each first reader / writer device 31 / 32 / 33 emits a signal, causing each electronic tag 12 passing through the first reader / writer device 31 / 32 / 33 to transmit its stored product information upon receiving the signal emitted by the first antenna 120. The first antenna 120 of the first reader / writer device 31 / 32 / 33 receives the information transmitted by the electronic tag 12, transmits it through the input / output interface 130 to the controller 110 for processing, and encodes the client_uuid and electronic tag 12 information using the client_share_key. The wireless transmission module 140 then transmits the encoded information to the proxy server device 700. The proxy server device... After receiving the data string from the client device, 700 does not perform any processing but directly transmits the received data string. After the receiving / transmitting interface module 510 of the cloud device 500 receives the data string from the proxy server device 700, it will be decoded by the data processing module 520. At this time, the information inside the electronic tag 12 can be stored in the storage space set by the memory module 530, for example, stored in the storage space set by a specific company; or the information inside the electronic tag 12 can be transmitted to the display module 600 to display the information simultaneously; or the data processing module 520 can process the information inside multiple electronic tags 12 in a specific way before transmitting it to the display module 600 to display the set information status, so that the cloud device 500 can know which products and quantities have been moved out of the first location area 1; therefore, it can be further compared with the warehouse data stored in the memory module 530 to confirm whether the two quantities are the same.

[0100] Next, when the aforementioned removed products 10 need to be transported to another area for sale, it may be necessary to transport these products to a designated area for warehousing via a transport device; for example, transporting 10,000 pairs of sports shoes from the Shanghai Free Trade Zone to a sales point warehouse on Wangfujing Street in Beijing. To ensure that the sports shoes to be transported arrive at the designated area for warehousing on schedule and in full, it is necessary to confirm which sports shoes are entering the transport device (e.g., a container) upon entering the transport device, and also to ensure that no products are missing from the transport device throughout the entire transportation process.

[0101] To address the aforementioned needs, the first embodiment of the product logistics management system of the present invention proceeds with the following procedure. A container (or second location area 2) on the transport device is configured with an entrance / exit. At least one second reader / writer 41 / 42 / 43, which can function as a client device 100, is configured at the entrance / exit (e.g., the security identification codes of the three second readers / writers are P004, P005, and P006, respectively). Each second reader / writer 41 / 42 / 43's second antenna 220 emits a signal, causing each electronic tag 12 passing through the second reader / writer 41 / 42 / 43 to receive the signal emitted by the second antenna 220, thereby triggering the electronic tag 12 to transmit the product information stored within it. The information transmitted from the electronic tag 12 is received by the second antenna 220 of the second read / write device 41 / 42 / 43, and then transmitted to the controller 210 for processing via the input / output interface 130. After encoding the client_uuid and electronic tag 12 information data using the client_share_key, the wireless transmission module 240 transmits the encoded information to the proxy server device 700. The proxy server device 700, upon receiving the data string from the client device, does not perform any processing but directly transmits the received data string. The cloud device 500 receives the data. After receiving the data string from the proxy server device 700, the transmitting interface module 510 decodes it through the data processing module 520. At this point, the information inside the electronic tag 12 can be stored in the storage space set by the memory module 530, for example, in the storage space set by a specific company; or the information inside the electronic tag 12 can be simultaneously transmitted to the display module 600 for display; or the data processing module 520 can process the information inside multiple electronic tags 12s in a specific way before transmitting them to the display module 600 to display the set information status; so that the cloud device 500 can know the data sent to the next data tag. The quantity of products in the second location area 2, as well as the name and identification code of each product, can be further compared with the storage data in the memory module 530, so that the cloud device 500 can know which products and quantities have been stored in the second location area 2. In addition, the security confirmation method for the information transmitted by the second read / write device 41 / 42 / 43 is the same as that described above, and will not be described again. The difference lies in the security identification code. In this embodiment, P in P004 represents a read / write device configured on the transport container, so it can choose to transmit or not transmit coordinate (including latitude / longitude) information.

[0102] Next, please refer to Figure 9This is a schematic diagram of the second location area in the first embodiment of the IoT product logistics management system of the present invention. In the second location area 2, at least one third read / write device 51 / 52 / 53, which can serve as a client device 100, is further configured (e.g., the security identification codes of the three third read / write devices are G007, G008, and G009, respectively). Each third read / write device 51 / 52 / 53 is composed of at least one third antenna 320, a third control module 310, a positioning device 150, and a third wireless transmission module 340. These third read / write devices 51 / 52 / 53 are used to scan or monitor the product 10 placed in the second location area 2 to ensure that the quantity of products stored in the second location area 2 is safely placed there. Clearly, in this embodiment, the second location area 2 is a transport container for the product. During the transport of the product 10, these third read / write devices 51 / 52 / 53 continuously transmit information to the electronic tag 12 on the product 10 via the third antenna 320. This triggers the electronic tag 12 to transmit the product information stored inside. The third antenna 320 of the third read / write devices 51 / 52 / 53 receives the information transmitted by the electronic tag 12, which is then transmitted to the controller 110 via the input / output interface 130 for processing. After encoding the client_uuid and electronic tag 12 information data using the client_share_key, the data is wirelessly transmitted... The input module 140 transmits the encoded information to the proxy server device 700. After receiving the data string from the client device, the proxy server device 700 does not perform any processing but directly transmits the received data string. After the receive / transmit interface module 510 of the cloud device 500 receives the data string from the proxy server device 700, it will be decoded by the data processing module 520. At this time, the information inside the electronic tag 12 can be stored in the storage space set by the memory module 530, for example, stored in the storage space set by a specific company; or the information inside the electronic tag 12 can be transmitted to the display module 600 to display the information simultaneously; or the data processing module 520 can process the information inside multiple electronic tags 12 in a specific way before transmitting it to the display module 600 to display the set information status; so that the cloud device 500 can determine the current location of the product by using GPS coordinate information.

[0103] Furthermore, it should be emphasized that the electronic tags described in the above embodiments may include one of the following: NFC (Near Field Communication), RFID (Radio Frequency Identification), ID stamp, or ID (Identity) sticker. Specifically, if the electronic tag 12 placed on the product 10 in the second location area (container) 2 is RFID, then the third reader / writer device 51 / 52 / 53 configured in the second location area (container) 2 can be fixed in one position. However, if the electronic tag 12 placed on the product 10 in the second location (container) 2 is NFC, an ID stamp, or an ID sticker, then the third reader / writer device 51 / 52 / 53 configured in the second location 2 must be able to move within the second location area (container) 2 to ensure that each product 10 can be scanned. Moreover, the frequencies of the electronic tag 12 in the system are matched with those of the first antenna 120, the second antenna 220, and the third antenna 320.

[0104] Furthermore, it should be emphasized that the cloud device 500 is a fixed Domain Name System (DNS), which functions as a server and communicates with the client device 100. It consists of a receive / transmit interface module 510, a data processing module 520, and a memory module 530, and can be connected to the display module 600 via the receive / transmit interface module 510. The data processing module 520 has already stored the security identification code of at least one first read / write device 31 / 32 / 33 (e.g., three first read / write devices) configured at the first entrance / exit of the first location area 1, the name or number of the warehouse it is located in, and the coordinates (including latitude and longitude) of its location. The information is recorded and stored in the memory of the memory module 530; similarly, the data processing module 520 has also recorded and stored in the memory of the memory module 530 the security identification codes (e.g., three second read / write devices) of at least one second read / write device 41 / 42 / 43 configured at the second entrance / exit of the second location area 2, the name or number of the warehouse, and the coordinates (including latitude and longitude) of its location; and the security identification codes, the name or number of the warehouse, and the coordinates (including latitude and longitude) of at least one third read / write device 51 / 52 / 53 configured in the second location area 2 are also recorded and stored in the memory of the memory module 530, such as... Figure 7B and Figure 7C As shown, where, Figure 7CThis invention illustrates the storage data within the memory module. When the data processing module 520 determines that the received client_uuid and data string are correct, it can store this information in the specific storage space set by the memory module 530. When the received client_uuid and data string are determined to be incorrect or erroneous, it indicates that the received read / write device is not transmitted by the logistics management system, and there may be hacker information attempting to intrude or abnormal client data. Therefore, the data processing module 520 of the cloud device 500 will decide, based on the determination result, whether to ignore this information, or to choose to shut down the proxy server device 700 or issue a warning notification without further processing.

[0105] Furthermore, the product 10 information in the first location area 1 can be recorded in the cloud device 500 in the data processing module 520 or memory module 530 before the product 10 enters the first location area 1; alternatively, after multiple products 10 have passed through the first read / write device 31 / 32 / 33 in the first location area 1, the number of products 10 passing through the first location area 1, as well as the name and identification code of each product, can be recorded, and then the data on the number of products in the first location area 1, as well as the name and identification code of each product, can also be established and recorded in the cloud device 500 in the data processing module 520 or memory module 530, such as... Figure 7C As shown; at this time, during the process of data processing module 520 storing data to memory module 530, cloud device 500 will also add a data storage time record as one of the data for subsequent comparison. The present invention does not limit the method chosen for recording the quantity of products in the first location area 1 and the name and identification code data of each product.

[0106] Clearly, once the product quantity, product name, and identification code of the first location area 1 have been established in the memory module 530 of the cloud device 500, they will be processed and compared by the data processing module 520 within the cloud device 500. After the data processing module 520 performs security checks and information processing, it will know that the product quantity, product name, and identification code of the first location area 1 can be further compared with the warehouse data (such as...) in the memory module 530. Figure 7CThe comparison (as shown) allows the cloud device 500 to determine which products and quantities have been moved out of the first location area 1. At this time, the cloud device 500 can connect to the display 600 via the receive / transmit interface module 510 to display the quantity of products originally stored in the first location area 1, the product names, and the recording time; or to display when which products and quantities have been moved out of the first location area 1, and how many products and quantities are still stored in the first location area 1. This allows the administrator to know the quantity and names of products in the first location area 1. Of course, the administrator can also query the cloud device 500 to find the product names and identification codes stored in the first location area 1.

[0107] Finally, after the product logistics management system of the present invention has been operated in the first embodiment, the manager can see information such as how many products are currently stored in the warehouse, how many products are currently en route, where they have been transported, and when they are scheduled to arrive at their destination (Wangfujing Street) on the display module 600 connected to the cloud device 500. Simultaneously, the manager can also query the product name and identification code of the products in the management system through the cloud device 500. Similarly, in another preferred embodiment of the present invention, the first read / write device 31 / 32 / 33 configured in the second location area 2, like the third read / write device 51 / 52 / 53, must be able to move within the first location area 1 to ensure that each product 10 can be scanned.

[0108] The item management system of the present invention can be further integrated with the item warehousing and sales management system into a complete system, and its detailed operation process is described below.

[0109] Please refer to Figure 10This is a schematic diagram of the item storage management of the second embodiment of the Internet of Things product logistics management system of the present invention. First, when multiple products 10 with electronic tags 12 have been placed in the first storage area 1, for example, in the first embodiment, the products (ten thousand pairs of sports shoes) have been transported to the first storage area 1 on Wangfujing Street for storage, and the quantity, product name and identification code of the products placed in the first storage area 1 have been stored in the memory device of the cloud device; obviously, the first storage area 1 has an entrance and exit, and at least one first reading and writing device is configured on this entrance and exit. Each first reading and writing device has a number 31 / 32 / 33 (for example: the security identification codes of the three first reading and writing devices are A001, A002 and A003 respectively), the name or number of the warehouse where it is located, and the coordinates (including latitude and longitude) of its location, and these information have also been recorded or stored in the memory device of the cloud device. Then, when the manager wants to send the products placed in the first storage area (1) to different sales outlets, this can be achieved by the item storage and sales management system of the present invention.

[0110] When the manager wants to deliver 10,000 pairs of athletic shoes from the first storage area 1 to the first sales point (5,000 pairs), the second sales point (3,000 pairs), and the third sales point (1,000 pairs), when athletic shoes numbered 1 to 5000 are to be delivered to the first sales point, these athletic shoes will pass through the entrance / exit of the first storage area 1. The entrance / exit is equipped with at least one first reader / writer (i.e., the fourth reader / writer). The first antenna 120 on each first reader / writer 31 / 32 / 33 will transmit a signal, causing... Each electronic tag 12 passing through the first reader / writer 31 / 32 / 33, upon receiving a signal emitted by the first antenna 120, will trigger the electronic tag 12 to transmit the product information stored internally. The first antenna 120 of the first reader / writer 31 / 32 / 33 will then receive the information transmitted by the electronic tag 12, transmit it through the input / output interface 130 to the controller 110 for processing, and encode the client_uuid and electronic tag 12 information data using the client_share_key. The encoded information will then be transmitted by the wireless transmission module 140. The data is sent to the proxy server device 700; after receiving the data string from the client device, the proxy server device 700 does not perform any processing but directly transmits the received data string; after the receiving / transmitting interface module 510 of the cloud device 500 receives the data string from the proxy server device 700, it will be decoded by the data processing module 520. At this time, the information inside the electronic tag 12 can be stored in the storage space set by the memory module 530, for example, stored in the storage space set by a specific company; wherein, the information transmitted by the first read / write device 31 / 32 / 33 includes its encoding The product name and identification code in the electronic tag are: number, name or number of the warehouse, coordinates of its location (including latitude and longitude), and product name and identification code. After the sports shoes numbered 1 to 5000 have passed through the first read / write device 31 / 32 / 33 of the first storage area 1, it is obvious that after the data processing module 520 of the cloud device 500 processes the data, it will know that the sports shoes numbered 1 to 5000 have been moved out of the first storage area 1. The data processing module 520 in the cloud device 500 will record the time when the sports shoes numbered 1 to 5000 were moved out of the first storage area 1, for example: 9:00 AM.During the processing of data by the data processing module 520 of the cloud device 500, the data processing module 520 first confirms whether the received information was sent by the first read / write device 31 / 32 / 33 of the management system. For example, the data processing module 520 will at least confirm whether the information such as the serial number of each incoming first read / write device, the name or serial number of the warehouse it belongs to, and its location coordinates (including latitude and longitude) are the same as the record information stored in the memory module 530. When it is determined that the received information is correct, the information transmitted by these first read / write devices 31 / 32 / 33 can be stored in the memory module 530. The memory module 530 can synchronously transmit information from the electronic tag 12 to the display module 600 for display, or the data processing module 520 can process the information from multiple electronic tags 12 and then transmit it to the display module 600 to display the set information status. When the cloud device 500 determines that the received information is incorrect, it indicates that there may be hacker information attempting to intrude. Therefore, the data processing module will ignore this information and not perform further processing. Alternatively, it can choose to shut down the proxy server device 700 or further issue a warning to the cloud device.

[0111] Similarly, when shoes numbered 5001 to 8000 pass through at least one first reader / writer 31 / 32 / 33 at the entrance / exit of the first storage area 1, the cloud device 500 will know that shoes numbered 5001 to 8000 have been removed from the first storage area 1 through the same system operation. The data processing module 520 within the cloud device 500 will then record the time when shoes numbered 5001 to 8000 were removed from the first storage area 1, for example, 10:00 AM. When shoes numbered 8001 to 9000 pass through at least one first reader / writer 31 / 32 / 33 at the entrance / exit of the first storage area 1, the cloud device 500 will know that shoes numbered 8001 to 9000 have been removed from the first storage area 1 through the same system operation. The data processing module 520 within the cloud device 500 will then record the time when shoes numbered 8001 to 9000 were removed from the first storage area 1, for example, 11:00 AM. When the second embodiment is in operation, the manager can see on the display module 600 connected to the cloud device 500 that the sports shoes numbered 9001 to 10000 are still stored in the warehouse; while the sports shoes numbered 1 to 5000, 5001 to 8000, and 8001 to 9000 are shown to have been moved out of the first storage area 1 at different times.

[0112] Next, once the athletic shoes numbered 1 to 5000 have been delivered to the first sales location (second storage area), they will be read and written by the reader / writer 61 (e.g., security identification code S010) located at the first sales location. Therefore, through the same operation described above, the manager can see on the display module 600 connected to the cloud device 500 that athletic shoes numbered 9001 to 10000 are currently stored in the warehouse. At 11:00 AM, athletic shoes numbered 1 to 5000 were already stored at the first sales location. The manager can also query product information through the cloud device 500, such as querying the size information of athletic shoes numbered 1 to 5000. Similarly, once the athletic shoes numbered 5001 to 8000 have been delivered to the second sales location, they will be read and written by the reader / writer 62 (e.g., security identification code S011) configured at the second sales location. Therefore, through the same operation described above, the manager can see on the display module 600 connected to the cloud device 500 that athletic shoes numbered 9001 to 10000 are currently stored in the warehouse, athletic shoes numbered 1 to 5000 were stored at the first sales location at 11:00 AM, and athletic shoes numbered 5001 to 8000 were stored at the second sales location at 11:30 AM. The manager can also query product information through the cloud device 500, such as querying the size information of athletic shoes numbered 5001 to 8000. Next, once the athletic shoes numbered 8001 to 9000 have been delivered to the third sales location, they will be read and written by the reader / writer 63 (e.g., security identification code S012) located at the third sales location. Therefore, through the same operation described above, the manager can see on the display module 600 connected to the cloud device 500 that athletic shoes numbered 9001 to 10000 are currently stored in the warehouse, athletic shoes numbered 1 to 5000 were stored at the first sales location at 11:00 AM, athletic shoes numbered 5001 to 8000 were stored at the second sales location at 11:30 AM, and athletic shoes numbered 8001 to 9000 were stored at the third sales location at 12:00 PM. The manager can also query product information through the cloud device 500, such as querying the size information of athletic shoes numbered 8001 to 9000.

[0113] Finally, for an explanation of the sales operation of this second embodiment, please refer to [link / reference]. Figure 11 This is a sales management diagram of the second embodiment of the Internet of Things product logistics management system of the present invention. Figure 11As shown, once the customer has confirmed the product they wish to purchase (e.g., sneakers, item number 999), the service staff will take product 10 to the counter for checkout. At this time, the salesperson will take the electronic tag 12 on product 10 to the reader / writer 71 (e.g., number CS0100) configured on the counter. The reader / writer 71 (the fifth reader / writer) configured on the counter has the same structure as a general reader / writer, but also has a demagnetization module 170. After confirming that the customer has completed payment, the counter notifies the reader / writer 71 to send the information that the 999th sports shoe has been sold. Since the number of the reader / writer 71 configured on the counter, the name or number of the sales point, and the coordinates (including latitude and longitude) of its location are stored in the cloud device, after the reader / writer 71 configured on the counter sends out the information that the product has been sold, after being processed by the data processing module 520 of the cloud device 500, the information that the 999th sports shoe originally stored at the first sales point has been sold will be displayed on the display module 600 through the receiving / transmitting interface module 510. Therefore, after the same operation described above, the administrator can see the information that the 999th shoe at the first sales point has been sold on the display module 600 connected to the cloud device 500. Similarly, when the read / write device at the second sales point (not shown in the figure) sends out the information that the 5999th shoe has been sold, and the read / write device at the third sales point (not shown in the figure) sends out the information that the 8999th shoe has been sold, after processing by the data processing module 520 of the cloud device 500, the information will be displayed on the display module 600 via the receive / transmit interface module 510. The final display result on the display module 600 shows the sales information as follows: Figure 12 The diagram shown is a schematic representation of the manager information display in this invention.

[0114] Furthermore, when the electronic tag configured on product 10 uses RFID, this RFID can be recycled and reused; of course, these electronic tags 12 configured on the product can also use other types, such as NFC, ID stamps, or ID stickers. In this second embodiment, the electronic tag 12 is frequency-matched to each antenna 120 / 220 / 320 in the system.

[0115] Based on the detailed description of the first and second embodiments above, the present invention can be further combined to form the complete goods warehousing, logistics and sales management system of the present invention, so it will not be described in detail again.

[0116] Although the present invention has been disclosed above with reference to the preferred embodiments described above, it is not intended to limit the present invention. Any person skilled in the art may make some modifications and refinements without departing from the spirit and scope of the present invention. Therefore, the scope of patent protection of the present invention shall be determined by the claims appended to this specification.

Claims

1. An Internet of Things (IoT) product logistics management system, characterized in that, include: At least one product, each product having an electronic tag, each product being placed in a first location area, and each electronic tag having product information; At least one first read / write device, each first read / write device being a device with wireless communication capabilities and each first read / write device having a first specific media access control address, is configured at a first entrance / exit of the first location area, and when each product passes through the first entrance / exit, each first read / write device receives the product information of each electronic tag; At least one second read / write device, each of the second read / write devices being a device with wireless communication capabilities and each of the second read / write devices having a second specific media access control address, is configured at a second entrance / exit in a second location area, and when multiple products pass through the second entrance / exit, each of the second read / write devices receives the product information of each of the electronic tags; as well as The proxy server device is a floating Internet Protocol address that changes at any time. It has a website address, account and password to pair with the first read and write device and the second read and write device. After being paired, the first read and write device and the second read and write device can only communicate with the paired proxy server device and can communicate with the cloud device through message queue telemetry transmission communication standard. The cloud device has the function of communicating with the first read / write device, the second read / write device and the proxy server device. The first read / write device and the second read / write device log in to the cloud device through the Hypertext Transfer Security Protocol in order to start the Internet of Things system. When the cloud device receives requests from the first and second reading / writing devices, it performs comparison and verification. If it confirms that the first specific media access control address of the first reading / writing device and the second specific media access control address of the second reading / writing device are stored in the cloud device, the cloud device generates an authentication code for the first and second reading / writing devices and a pair of keys exclusively used by the first and second reading / writing devices. The cloud device then sends the authentication code and the keys back to the first and second reading / writing devices. A first reading / writing device and a second reading / writing device request, via the Hypertext Transfer Security Protocol (HTTP) using the encoded authentication code, at least obtain the Internet Protocol address, the account, and the password of the proxy server from the cloud device. The first reading / writing device and the second reading / writing device connect to the proxy server based on the received Internet Protocol address, account, and password. The proxy server directly transmits information from the first reading / writing device and the second reading / writing device to the cloud device without any processing via the Message Queuing Telemetry Transmission Communication Standard (MQTS), so as to transmit the information on the first reading / writing device and the second reading / writing device to the cloud device.

2. An Internet of Things (IoT) product logistics management system, characterized in that, include: At least one product, each product having an electronic tag, each product being placed in a first location area, and each electronic tag having product information; At least one first read / write device, each of the first read / write devices being a device with wireless communication capabilities, and each of the first read / write devices having a first specific media access control address, is configured at a first entrance / exit of the first location area, and when multiple products pass through the first entrance / exit, each of the first read / write devices receives the product information of each of the electronic tags; At least one second read / write device, each of the second read / write devices being a device with wireless communication capabilities and each of the second read / write devices having a second specific media access control address, is configured at a second entrance / exit in a second location area, and when multiple products pass through the second entrance / exit, each of the second read / write devices receives the product information of each of the electronic tags; At least one third read / write device, each of the third read / write devices being a device with wireless communication capabilities, and each of the third read / write devices having a third specific media access control address and a positioning device, is configured in the second location area. After the plurality of products have been placed in the second location area, each of the third read / write devices receives the product information of each electronic tag and the coordinate information output by the positioning device. The proxy server device is a floating Internet Protocol address that changes at any time. It has a website address, account, and password to pair with the first, second, and third read / write devices. Once paired, the first, second, and third read / write devices can only communicate with the paired proxy server device and can communicate with cloud devices via message queue telemetry transmission communication standards. The cloud device has the function of communicating with the first read / write device, the second read / write device, the third read / write device and the proxy server device. The first read / write device, the second read / write device and the third read / write device log in to the cloud device through the Hypertext Transfer Security Protocol in order to start the Internet of Things system. When the cloud device receives requests from the first, second, and third read / write devices, it performs comparison and verification. If it confirms that the first specific media access control address of the first read / write device, the second specific media access control address of the second read / write device, and the third specific media access control address of the third read / write device are stored in the cloud device, the cloud device generates authentication codes for the first, second, and third read / write devices, as well as a pair of keys used exclusively by the first, second, and third read / write devices. The cloud device then sends the authentication codes and the keys used exclusively by the first, second, and third read / write devices back to the first, second, and third read / write devices. The writing device and the third reading and writing device, the first reading and writing device, the second reading and writing device and the third reading and writing device, request from the cloud device at least the Internet Protocol address of the proxy server, the account and the password through the Hypertext Transfer Security Protocol using the encoded dialectical code, the first reading and writing device, the second reading and writing device and the third reading and writing device connect to the proxy server based on the received Internet Protocol address, the account and the password, the proxy server directly transmits information from the first reading and writing device, the second reading and writing device and the third reading and writing device to the cloud device without any processing through the message queue telemetry transmission communication standard, so as to transmit the information on the first reading and writing device, the second reading and writing device and the third reading and writing device to the cloud device.

3. The IoT product logistics management system according to claim 2, characterized in that, The third read / write device moves within the second position area.

4. An Internet of Things (IoT) product logistics management system, characterized in that, include: At least one product, each product having an electronic tag, each product being placed in a first location area, and each electronic tag having product information; At least one first read / write device, each of the first read / write devices being a device with wireless communication capabilities, and each of the first read / write devices having a first specific media access control address, is configured at a first entrance / exit of the first location area, and when multiple products pass through the first entrance / exit, each of the first read / write devices receives the product information of each of the electronic tags; At least one fourth read / write device, each of which is a device with wireless communication function and each of which has a fourth specific media access control address, is configured at the entrance and exit of the storage area, and when multiple products pass through the entrance and exit, each of the fourth read / write devices receives the product information of each of the electronic tags; The fifth read / write device is a device with wireless communication function and has a fifth specific media access control address and a demagnetization module. After the demagnetization module in the fifth read / write device demagnetizes the electronic tag on the product, it is used to transmit the demagnetized electronic tag of the product. The proxy server device is a floating Internet Protocol address that changes constantly. It has a website address, account, and password to pair with the first, fourth, and fifth read / write devices. Once paired, the first, fourth, and fifth read / write devices can only communicate with the paired proxy server device and can communicate with cloud devices via message queue telemetry transmission communication standards. The cloud device has the function of communicating with the first read / write device, the fourth read / write device, the fifth read / write device and the proxy server device. The first read / write device, the fourth read / write device and the fifth read / write device log in to the cloud device through the Hypertext Transfer Security Protocol in order to start the Internet of Things system. When the cloud device receives requests from the first, fourth, and fifth read / write devices, it performs comparison and verification. If it confirms that the first specific media access control address of the first read / write device, the fourth specific media access control address of the fourth read / write device, and the fifth specific media access control address of the fifth read / write device are stored in the cloud device, the cloud device generates authentication codes for the first, fourth, and fifth read / write devices, as well as a pair of keys used exclusively by the first, fourth, and fifth read / write devices. The cloud device then sends the authentication codes and the keys used exclusively by the first, fourth, and fifth read / write devices back to the first, fourth, and fifth read / write devices. The writing device and the fifth reading and writing device, the first reading and writing device, the fourth reading and writing device and the fifth reading and writing device, request from the cloud device at least the Internet Protocol address, the account and the password of the proxy server device via the Hypertext Transfer Security Protocol using the encoded dialectical code, the first reading and writing device, the fourth reading and writing device and the fifth reading and writing device connect to the proxy server device according to the received Internet Protocol address, the account and the password, the proxy server device directly transmits the information from the first reading and writing device, the fourth reading and writing device and the fifth reading and writing device to the cloud device without any processing through the message queue telemetry transmission communication standard, so as to transmit the information on the first reading and writing device, the fourth reading and writing device and the fifth reading and writing device to the cloud device.

5. An Internet of Things (IoT) product logistics management system, characterized in that, include: At least one product, each product having an electronic tag, each product being placed in a first storage area, and each electronic tag having product information; At least one first read / write device, each of the first read / write devices being a device with wireless communication capabilities, and each of the first read / write devices having a first specific media access control address, is configured at a first entrance / exit of the first storage area, and when multiple products pass through the first entrance / exit, each of the first read / write devices receives the product information of each of the electronic tags; At least one second read / write device, each of the second read / write devices being a device with wireless communication capabilities and each of the second read / write devices having a second specific media access control address, is configured at a second entrance / exit of a second storage area, and when multiple products pass through the second entrance / exit, each of the first read / write devices receives the product information of each of the electronic tags; At least one third read / write device, each of the third read / write devices being a device with wireless communication capabilities, and each of the third read / write devices having a third specific media access control address and a positioning device, is configured in the second storage area. After multiple products have been placed in the second storage area, each of the third read / write devices receives the product information of each electronic tag and the coordinate information output by the positioning device. The fifth read / write device is a device with wireless communication function and has a fifth specific media access control address and a demagnetization module. After the demagnetization module in the fifth read / write device demagnetizes the electronic tag on the product, it is used to transmit the demagnetized electronic tag of the product. The proxy server device is a floating Internet Protocol address that changes constantly. It has a website address, account, and password to pair with the first, second, third, and fifth read / write devices. Once paired, the first, second, third, and fifth read / write devices can only communicate with the paired proxy server device and can communicate with cloud devices via message queue telemetry transmission communication standards. The cloud device has the function of communicating with the first read / write device, the second read / write device, the third read / write device, the fifth read / write device and the proxy server device. The first read / write device, the second read / write device, the third read / write device and the fifth read / write device log in to the cloud device through the Hypertext Transfer Security Protocol in order to start the Internet of Things system. When the cloud device receives requests from the first, second, third, and fifth read / write devices, it performs comparison and verification. If it confirms that the first specific media access control address of the first read / write device, the second specific media access control address of the second read / write device, the third specific media access control address of the third read / write device, and the fifth specific media access control address of the fifth read / write device are stored in the cloud device, then the cloud device generates authentication codes for the first, second, third, and fifth read / write devices, as well as a pair of keys used exclusively by the first, second, third, and fifth read / write devices. The cloud device then sends the authentication codes and the keys used exclusively by the first, second, third, and fifth read / write devices back to the first read / write device. The device comprises a second, a third, and a fifth read / write device. The first, second, third, and fifth read / write devices, using the encoded dialectical code, request at least the Internet Protocol address, account, and password of the proxy server from the cloud device via the Hypertext Transfer Security Protocol. The first, second, third, and fifth read / write devices connect to the proxy server based on the received Internet Protocol address, account, and password. The proxy server directly transmits information from the first, second, third, and fifth read / write devices to the cloud device without any processing via the message queue telemetry transmission communication standard, so as to transmit the information on the first, second, third, and fifth read / write devices to the cloud device.

6. The IoT product logistics management system according to claim 4 or 5, characterized in that, It further includes a display device that connects to the cloud device via a receive / transmit interface module to display some or all of the information stored in the memory module, in order to display the storage information, coordinate information and sales information of each product.

7. The IoT product logistics management system according to claim 1, 2, 4 or 5, characterized in that, The electronic tag is selected from one of the following: near field communication, radio frequency identification, identification stamp, or identification sticker.

8. The IoT product logistics management system according to claim 1, 2, 4 or 5, characterized in that, Each of the aforementioned read / write devices comprises at least one first antenna, a first control module, and a first wireless transmission module.

9. The Internet of Things (IoT) product logistics management system according to claim 1, 2, 4, or 5, characterized in that, When the cloud device provides the URL and password of the proxy server to the read / write devices in the Internet of Things, it chooses to obtain them in multiple steps.

10. The IoT product logistics management system according to claim 2 or 5, characterized in that, It further includes a display device that connects to the cloud device via a receive / transmit interface module to display some or all of the information stored in the memory module, so as to display the storage information and coordinate information of each product.

Images