An intensive document handover record system based on blockchain technology

Abstract

The present invention provides an intensive document handover record system based on blockchain technology, including a business device end module, a hub module, a business service end module, and a blockchain trusted module. The business device end module runs on the trusted IoT device end, and is responsible for the distribution collection, data signing and data synchronization of document information. The hub module is responsible for providing services and interfaces for the business device end module, receiving data synchronized by the business device end module, and providing users with face login verification, document information verification, signature confirmation and document information upload services. The business service end module receives and processes the data of the hub module, and sends the document operation node attributes to the blockchain trusted module. The blockchain trusted module is responsible for issuing trusted IoT devices and issuing identity tags, and verifies the source of the collected data, and provides data on-chain and on-chain query API interfaces for the business server. The present invention can quickly integrate the data of all trusted IoT devices.

Description

Technical Field

[0001] The present invention relates to the field of document management, and in particular to an intensive document handover record system based on blockchain technology. Background Art

[0002] The widespread application of Internet technology has become an effective means to promote the modernization of document management, but there are also some shortcomings, such as: insufficient data quality management, weak data security control, difficulty in data openness and sharing, etc., which cannot fully meet the new requirements of document management.

[0003] As the evolution and upgrade of the second-generation Internet's capabilities, blockchain technology uses its distributed, transparent, traceable, and tamper-proof features to improve the credibility and security of data. Summary of the invention

[0004] Purpose of the invention: An application of traceable and tamper-proof recording functions based on blockchain technology, using privacy protection technology of trusted hardware, privacy protection technology based on cryptographic zero-knowledge proof, and authorized flow based on trusted chains to solve the security problem of data information storage. The present invention issues a unique identity tag of a document through a smart contract to form a trusted ID (Identity document) of the document, and the device terminal registers and issues it to form a trusted iot (Internet of Things) device ID. When it is uploaded to the chain, the trusted iot device ID and the trusted ID are verified to ensure that the source of the data is authentic and reliable. The present invention implants blockchain technology into the document handover record system, and uploads each operation node of the document handover to the chain, realizing the trusted recording of information at each link, ensuring the traceability of the document handover process, and thus solving the problem of information asymmetry.

[0005] The system of the present invention includes a business device end module, a hub module, a business service end module and a blockchain trusted module.

[0006] The business device end module runs on the IoT device, registers and issues the IoT device, and the IoT device that is successfully registered and issued is called a trusted IoT device;

[0007] The central module receives and processes document data uploaded by multiple business device modules, and provides users with face login verification, document information verification, signature confirmation and document information upload functions;

[0008] The business service module provides an upload binding interface for the central module, and receives and processes the data uploaded synchronously by the central module;

[0009] The blockchain trusted module is used to issue trusted IoT devices and identity tags, verify the source of data, and provide data on-chain and on-chain query API interfaces for the business server module.

[0010] The business service module is used to receive and process data from the business device module, and provide the business device module with an equipment registration and issuance interface, an equipment verification interface, a document query interface, a scanning and loading interface, and a scanning and warehousing interface;

[0011] The device registration and issuance interface is responsible for registering and issuing the device_id and imei passed by the business device module on the chain, including the following steps:

[0012] Step a1, accept the device_id and imei passed in by the service device module, verify that the device_id and imei are not empty to ensure that the data is valid. If the data verification fails, a data exception is returned;

[0013] Step a2, query the device_id and imei on the chain service to confirm whether they have been registered. If they have been registered, return duplicate registration exception information;

[0014] Step a3: If the device is not registered, perform the device registration operation, call the on-chain registration according to device_id and imei, and return the on-chain ID of the currently registered device; the on-chain ID is a unique identifier that identifies a piece of on-chain data;

[0015] Step a4: After the device is successfully registered, it is issued on the chain according to the returned on-chain ID. The issued IoT device is a trusted IoT device.

[0016] The device authentication interface is responsible for checking the device to verify whether it is a trusted IoT device, specifically including the following steps:

[0017] Step b1, receiving the device_id passed in by the service device module, verifying that the device_id is not empty to ensure that the data is valid. If the data verification fails, a data exception is returned;

[0018] Step b2: query the service registration record according to device_id. If no result is found, registration is not performed and abnormal data is returned.

[0019] Step b3: Verify the status of the queried record. If the status is unissued or cancelled, return data exception. Otherwise, return device verification success and related business operations can be performed.

[0020] The document query interface is responsible for querying the node attribute information on the real chain based on the chain ID of the data that has been uploaded to the chain;

[0021] The scanning loading interface is responsible for scanning and checking the data that has been bound and is ready to be loaded. If the check passes, the flow status is changed to loaded. If the check fails, data abnormality information is returned;

[0022] The scanning and warehousing interface is responsible for scanning and checking the data that has been loaded and is ready to be put into the warehouse. If the check passes, the flow status is changed to "put into the warehouse". If the check fails, data abnormality information is returned.

[0023] The service device end module registers and issues the IoT device, including the following steps:

[0024] Step c1, generate device_id based on the IoT device information, where device_id refers to a unique identification code based on the IoT device information;

[0025] Step c2, carry device_id and imei, call the device registration interface of the business service module to register; imei (International Mobile Equipment Identity) refers to the international mobile equipment identity code, a unique code in network communication;

[0026] Step c3, after successful registration, obtain the on-chain device ID;

[0027] The iot (Internet of Things) device refers to an IoT device with networking function;

[0028] The IoT device information includes manufacturer, product model, production date, product batch, MAC address, device_id, and imei;

[0029] The IoT device includes the following states: unissued, issued, and deregistered, where the unissued state refers to a device that has not been used after registration, the issued state refers to the device being in use, and the deregistered state means that the current device has been abandoned and cannot perform business operations.

[0030] After the business device module is started, it performs a self-check and sends the device_id to the business server module for verification. If the business server returns true, the self-check passes, indicating that the IoT device is a trusted IoT device and can be operated. Otherwise, the self-check fails, indicating that the IoT device is untrustworthy, the output fails, and jumps to the device registration page.

[0031] The business device-side module can encrypt and sign the collected data through the Hash algorithm. The encryption refers to the business device-side module encrypting the transmitted data through the built-in public key and hash algorithm. The business service-side module receives the ciphertext information and decrypts it through the corresponding private key to obtain the correct transmission information; the signing refers to the business device-side module encrypting the device_id through the built-in private key and hash algorithm. The business service-side module receives the encrypted device_id and decrypts it through the corresponding public key to obtain the correct device_id, thereby ensuring that the source of information sending is credible.

[0032] The business device module is also used for distributed collection of document information, data signing and data synchronization, and specifically includes the following steps:

[0033] Step d1, scan and identify the unique code of the document;

[0034] Step d2, collecting document image data and generating document information;

[0035] Step d3, encrypting the current operation node attribute and the document information generated in step d2;

[0036] Step d4: if step d3 is successful, the encrypted document information and signature are synchronously uploaded to the central module, and the document status is updated to registered;

[0037] If step d3 fails, the failure reason is prompted and investigated, and steps d1 to d3 are executed again.

[0038] The business device module is also used to complete the scanning and loading operation, that is, the operation that needs to be completed before loading. The scanning and loading operation includes two modes, namely mode 1 and mode 2. Mode 1 is suitable for a small number of document operations, that is, when the number of documents is less than or equal to a threshold (generally 60), and specifically includes the following steps:

[0039] Step e1, physically isolate an area in the operation area as a scanning and loading verification area;

[0040] Step e2, scanning and identifying the unique code of the document;

[0041] Step e3, calling the query interface of the business service module, obtaining the document status according to the document unique code, judging whether it meets the current operation requirements according to the status, if the status is bound, continue to execute the following steps, otherwise, the process is terminated, an error message is output, and the document is placed in the waiting area for verification;

[0042] Step e4, encrypting the document unique code and the operation node attribute;

[0043] Step e5: After step c4 succeeds, the encrypted document information and signature are carried to call the scanning and loading interface of the business server to update the document status to loaded;

[0044] Step e6, loading the documents into the truck;

[0045] Step e7, repeating steps e2 to e6 until all document operations are completed;

[0046] Step e8, scan and check the documents in the to-be-checked area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps e3 to e6 after correcting the abnormal documents until all the documents have been loaded;

[0047] Step e9: After all documents are loaded onto the truck, a handover note is generated and printed. After the customer checks and signs for correctness, the truck is transported to the warehouse.

[0048] Mode 2 is applicable to operations involving a large number of documents, that is, when the number of documents is greater than the threshold (generally 60), and includes the following steps:

[0049] Step f1, physically isolate an area in the operation area as a scanning and loading verification area;

[0050] Step f2, batch scanning of document identity tags;

[0051] Step f3, calling the query interface of the business service module, obtaining the document status according to the document identity tag, judging whether it meets the current operation requirements according to the status, if the status is bound, continue to execute the following steps, otherwise, the process is terminated, an error message is output, and the document is placed in the waiting area for verification;

[0052] Step f4, encrypting the document identity tag and the operation node attribute;

[0053] Step f5: After step f4 succeeds, the encrypted document information and signature will be carried to call the scanning and loading interface of the business server to update the document status to loaded;

[0054] Step f6, loading the documents into the truck;

[0055] Step f7, scan and check the documents in the to-be-checked area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps f3 to f6 after correcting the abnormal documents until all the documents have been loaded;

[0056] Step f8: After all documents are loaded onto the truck, a handover note is generated and printed. After the customer checks and signs for correctness, the truck is transported to the warehouse.

[0057] The business device module is also used for scanning and warehousing operations, that is, operations that need to be performed after the truck arrives at the warehouse. The scanning and warehousing operations include two modes, namely mode 1 and mode 2. Mode 1 is suitable for operations with a small number of documents, that is, when the number of documents is less than or equal to a threshold (generally 60), and specifically includes the following steps:

[0058] Step g1, physically isolate an area in the operation area as a scanning and warehousing verification area;

[0059] Step g2, taking out the document from the truck, scanning and identifying the unique code of the document;

[0060] Step g3, call the query interface of the business service module, obtain the document status according to the document unique code, and judge whether it meets the current operation requirements according to the status. If the status is loaded, continue to execute the following steps, otherwise, terminate the process, output an error message, and put the document in the waiting area for verification;

[0061] Step g4, encrypting the document operation node attributes;

[0062] Step g5: After step g4 succeeds, the scanning and loading interface of the business server is called with the encrypted document information and signature to update the document status to "in storage";

[0063] Step g6, putting the document into the secure storage area;

[0064] Step g7, repeat steps g2 to g6 until all document operations in the truck are completed;

[0065] Step g8, scan and check the documents in the area to be checked one by one, analyze the abnormal reasons according to the status of the documents, and execute steps g3 to g6 after correcting the abnormal documents until all documents are put into the safe storage area.

[0066] Mode 2 is applicable to operations involving a large number of documents, that is, when the number of documents is greater than the threshold (generally 60), and includes the following steps:

[0067] Step h1, physically isolate an area in the operation area as a scanning and warehousing verification area;

[0068] Step h2, taking the documents from the truck and scanning the document identity tags in batches;

[0069] Step h3, call the query interface of the business service module, obtain the document status according to the document identity tag, and judge whether it meets the current operation requirements according to the status. If the status is loaded, continue to execute the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification;

[0070] Step h4, encrypting the document identity tag and the operation node attribute;

[0071] Step h5: After step h4 succeeds, the encrypted document information and signature are carried to call the scanning and loading interface of the business server to update the document status to stored;

[0072] Step h6, putting the document into the secure storage area;

[0073] Step h7, scan and check the documents in the area to be checked one by one, analyze the cause of the abnormality according to the status of the document, and execute steps h3 to h6 after correcting the abnormal document until all documents are placed in the safe storage area.

[0074] The central module is used for data interaction within the local area network and is not limited to the network environment of on-site operation, thereby ensuring more efficient work efficiency. The central module specifically performs the following steps:

[0075] Step i1, the user enters the account number and enters the central module after face login verification;

[0076] Step i2: Enter the central module to view the list of documents collected under the account, sign and confirm after verification, and generate an operation record;

[0077] In step i3, the custodian uploads the verified document to the business server, calls the upload binding interface, and updates the document status to bound.

[0078] The document has operation node attributes. The business service module is used to collect document operation node attributes and send the collected document operation node attributes to the blockchain trusted module. The operation node attributes include: operation node unique identifier node_uuid, document unique code, trusted ID, resource owner, status, process, behavior, operation hash, file hash, operator, device ID and operation time. The operation time is the current timestamp. The classification label is greater than or equal to 1 and is used for document retrieval and positioning. The snapshot information is file image data, and the trusted ID is the identity label content. Specifically, the following steps are included:

[0079] Step j1, receiving the collected data and making preparations before uploading to the chain, verifying whether the document identity tag status has been issued. If it is not issued, the document is returned as untrustworthy;

[0080] Step j2: If the document identity tag status has been issued, the document operation node attribute is verified to be non-empty to ensure the data is valid. If the data verification fails, a data exception is returned;

[0081] Step j3, after verification, obtain the requested req_uuid as a unique identifier to ensure that no duplicate requests occur, causing dirty data in the system, where: req_uuid = current timestamp (milliseconds) + 5-digit random number;

[0082] Step j4, in order to improve the efficiency of chaining, differentiate the number of chained data, obtain the number of data currently chained, chainSize, and perform corresponding processing for different data volumes, specifically including the following steps:

[0083] Step j4-1, if chainSize is less than or equal to the threshold (generally 200), synchronous chaining is used for operation. After executing the chaining, synchronous chaining can synchronously obtain the chain ID of the current data chaining and related request result information;

[0084] Step j4-2, based on the returned result information, verify whether the result information is correct and obtain the returned result status. If the status is OK, it is successful, and the current on-chain information ID is saved to the corresponding record of the business system for later related query;

[0085] Step j4-3, based on the returned result information, verify that the result information is incorrect, and provide feedback and reminder on the abnormal result information;

[0086] Step j4-4, if chainSize is greater than the threshold (usually 200), asynchronous batch chaining is used for operation. Asynchronous chaining needs to be processed according to the task ID of the execution feedback;

[0087] Step j4-5, verify whether the result information is correct according to the returned result information, obtain the returned result status, if the status is OK, it is successful, and save the current task ID information;

[0088] Step j4-6, based on the result information returned by the execution, verify that the result information is incorrect, and provide feedback and reminder on the abnormal result information;

[0089] Step j4-7, when asynchronously uploading to the chain, use the scheduled task to query the on-chain ID according to the returned task ID. After the ID is queried, the current on-chain information ID is saved to the corresponding record of the business system for later related queries. The scheduled task is to query the unsuccessful asynchronous uploading data according to the set time rules, and update the query results to the result record.

[0090] The trusted ID is the identity tag content;

[0091] The identity tag status includes: to be produced, to be issued, and issued;

[0092] The identity tag has an issuance operation, including the following steps:

[0093] Step k1, affixing the identity label to the document cover;

[0094] Step K2: The trusted IoT device identifies the unique code of the document and the identity tag content, and encrypts the content;

[0095] Step k3: After step k2 succeeds, the trusted IoT device carries the ciphertext and signature generated in step k2 and uploads them to the business server module synchronously, and the business server module performs the issuance operation;

[0096] Step k4: After step k3 succeeds, the identity tag is in an issued state, and the trusted ID is the content of the identity tag.

[0097] The identity tag content is generated and stored by the blockchain trusted module before production. The tag content is a unique value in the blockchain trusted module. At this time, the tag is in a "pending production" state.

[0098] The content of the identity tag is written during production. After writing, the EPC area of ​​the identity tag is converted to a permanent locked state. The identity tag in the permanent locked state of the EPC area cannot be modified a second time to prevent tampering. At this time, the tag is in a "pending release" state.

[0099] The identity tag is used to bind to the unique code of the document and can be remotely scanned and identified. When scanning and loading large quantities of documents or scanning and storing them in warehouses, a trusted IoT device can be used to remotely identify the identity tag to perform batch operations and improve work efficiency.

[0100] The document has an identity tag attribute, and the identity tag is an RFID electronic tag based on EPC 96 encoding, and is a unique value consisting of a tag prefix + n2 digits. The tag prefix can be defined according to the business scenario, such as: identification version number (8bit) + identification code (28bit) + business identification (24bit), where the identification code is used to identify the blockchain issuer, such as: F000001, and the business identification is used to identify the business scenario, such as: A01Q01, then the tag prefix is: 86F000001A01Q01.

[0101] The document unique code is a unique value consisting of the document prefix + n1 character strings. The document prefix can be defined according to the business scenario, such as: identification version number (Q01) + document specification (KYQ), then the document prefix is ​​Q01KYQ, n1 is greater than or equal to 1, the character string is composed of 26 uppercase letters and 0-9 numbers permutation and combination, in order to prevent character confusion, 0, O, 1, I, 2, Z characters are removed, a total of 30 valid characters, then the permutation and combination of n1 character strings is the maximum number of document codes supported n2, that is, n2 = 30 n1.

[0102] The document has a status attribute, and the status includes but is not limited to: to be registered, registered, verified, bound, loaded and stored, among which: the initial status of the document is to be registered, the status of the document registered in the cloud is registered, the status of the document signed and confirmed is verified, the status of the document uploaded and bound is bound, the status of the document scanned and loaded is loaded, and the status of the document scanned and stored is stored.

[0103] Beneficial effects: The present invention can handle a large number of requests from business device-end devices, quickly integrate the data of all trusted IoT devices, complete the intensive management of documents, and provide users with practical, safe and reliable document handover services. The blockchain technology is implanted into the document handover record system, and each operation node of the document handover is chained to achieve reliable recording of information at each link, thereby ensuring the traceability of the document handover process. The trusted ID of the device and document is issued through smart contracts to ensure that the source of the data is authentic and reliable, thereby solving the problem of information asymmetry. The present invention provides an application of traceable and tamper-proof recording functions based on blockchain technology to solve the security problem of data information storage, ensure the integrity, reliability and trustworthiness of operational data, and thus create a higher level of security and compliance. BRIEF DESCRIPTION OF THE DRAWINGS

[0104] The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments, and the above and / or other advantages of the present invention will become more clear.

[0105] Figure 1 It is a system workflow diagram of the present invention.

[0106] Figure 2 It is a document handover flow chart of the present invention.

[0107] Figure 3 It is a flow chart of device issuance of the present invention.

[0108] Figure 4 It is a data verification flow chart of the present invention.

[0109] Figure 5 It is a data uplink flow chart of the present invention. DETAILED DESCRIPTION

[0110] The present invention provides an intensive document handover record system based on blockchain technology, such as Figure 1 The flowchart of the present invention is shown as follows. It is characterized by comprising a business device end module, a hub module, a business service end module and a blockchain trusted module.

[0111] The business device end module runs on the IoT device, registers and issues the IoT device, and the IoT device that is successfully registered and issued is called a trusted IoT device.

[0112] The IoT device includes the following states: unissued, issued, and deregistered, where the unissued state refers to a device that has not been used after registration, the issued state refers to the device being in use, and the deregistered state means that the current device has been abandoned and cannot perform business operations.

[0113] The central module receives and processes document data uploaded by multiple business device end modules, and provides users with face login verification, document information verification, signature confirmation and document information upload functions.

[0114] The business service module provides an upload binding interface for the central module, and receives and processes the data uploaded synchronously by the central module.

[0115] The blockchain trusted module is used to issue trusted IoT devices and identity tags, verify the source of data, and provide data on-chain and on-chain query API interfaces for the business server module.

[0116] The registration and issuance of the IoT device is as follows:

[0117] Step 1.1: Obtain device information for unissued IoT devices, including manufacturer, device model, production date, product batch, MAC address, etc., and concatenate them in order to generate device_id. The sample data is as follows:

[0118] Manufacturer: QCDOC;

[0119] Equipment model: M1;

[0120] Production date: 20200101;

[0121] Product batch: 010101;

[0122] mac address: 00:0A:02:0B:03:0C;

[0123] device_id: QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C;

[0124] Step 1.2, the IoT device obtains device information, including imei and device_id generated in step 1.1, and calls the device registration interface of the business server module to register. The sample data is as follows:

[0125] Device imei: 000000000000001;

[0126] device_id: QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C;

[0127] Step 1.3, the registration interface of the business server module receives the value of step 1.2, and first verifies that device_id and imei are not empty to ensure that the data is valid;

[0128] Step 1.4, the business server module has device_id

[0129] The IoT device with QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C and imei of 0000000000000001 performs on-chain service query. Since there is no registration record, the device_id and imei are called on-chain for registration, and the on-chain ID of the currently registered device is returned. The sample data is as follows:

[0130] Device imei: 000000000000001;

[0131] device_id: QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C;

[0132] On-chain ID:

[0133] 87141dc179be5aab0d59af1cff06cd2cf8312e4807cb25b9a1836a5cb2694b82;

[0134] Step 1.5: After step 1.4 succeeds, the on-chain issuance is carried out according to the returned on-chain ID. The issued IoT device is a trusted IoT device, and the trusted IoT device can perform related business operations. At this time, the IoT device status is issued.

[0135] After the IoT device is started, it performs a self-test operation, and the steps are as follows:

[0136] Step 2.1, after the IoT device is started, obtain the device_id, and carry the device_id to call the device verification interface of the business server module. The sample data is as follows:

[0137] device_id: QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C;

[0138] Step 2.2, the business service module receives the device_id passed in by the business device, verifies that the device_id is not empty, and ensures that the data is valid. If the data verification fails, a data exception is returned, and the device_id is not empty, and the subsequent operations are continued;

[0139] Step 2.3, query the service registration record according to device_id. If no result is found, the registration is not performed and abnormal data is returned. The example is as follows:

[0140] The device with device_id QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C has a record in the database, so continue with the subsequent operations;

[0141] Step 2.4: Verify the status of the queried record. If the status is unissued or cancelled, the data is returned as abnormal. Otherwise, the device verification is successful and related business operations can be performed. The example is as follows:

[0142] The device with device_id QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C is in the issued state, the verification is successful, and the success state is returned;

[0143] Step 2.5: The IoT device receives the return value of successful authentication and is a trusted device, so it can perform subsequent operations.

[0144] The steps of issuing the trusted ID are as follows:

[0145] Step 3.1, paste the identity label on the document cover;

[0146] Step 3.2: The trusted IoT device identifies the unique code of the document and the content of the identity tag. At this time, the identity tag status is pending issuance, and the content is encrypted. The sample data is as follows:

[0147] Document unique code: Q01KYQ3798;

[0148] ID tag: 86F000001A01Q01;

[0149] Step 3.3: The trusted IoT device carries the ciphertext and signature generated in step 3.2 and uploads them to the business server module, which then performs the issuance operation.

[0150] Step 3.4: After step 3.3 is successful, the identity tag is in the issued state, and the trusted ID is the content of the identity tag.

[0151] The steps of distributed collection, data signing and data synchronization of the document information are as follows:

[0152] Step 4.1, scan and identify the unique code of the document. The unique code of the sample document is: Q01KYQ3798;

[0153] Step 4.2, collecting document image data and generating document information;

[0154] Step 4.3: Encrypt the current operation node attributes and the document information generated in step 4.2. The sample data is as follows:

[0155] Unique ID uuid: 154639695805361

[0156] Trusted ID: 86F000001A01Q01

[0157] Asset ID: Q01KYQ3798

[0158] Resource owner: XXXX Bank - XXX Department - Wang XX

[0159] Status: Pending registration

[0160] Process: Collection process

[0161] Behavior: Information Collection

[0162] Operation hash: 7e9fca97e1d076343a191e383a0f0abc

[0163] File hash: cb3198738c417fae30156887c1a55313

[0164] Operator: Zhao XX

[0165] device_id: QCDOC-M1-20200101-010101-00:0A:02:0B:03:0C

[0166] Operation time: 2022-03-02 10:00:00

[0167] Step 4.4, upload the encrypted document information and signature to the central module synchronously, and update the document status to registered. If the upload in step 4.4 fails, the failure reason will be prompted and the problem will be solved. Steps 4.1 to 4.3 will be executed again until success.

[0168] Step 4.5, the central module receives and stores the document data uploaded by multiple business device modules;

[0169] Step 4.6: The customer logs in to the central module through face recognition of the central module, and manually checks the document information of the current operation. If the manual check is correct, the customer signs to confirm and generates an operation record;

[0170] Step 4.7: After the customer signs, the document information and signature temporarily stored in the central module are uploaded through the business server module upload binding interface;

[0171] Step 4.8: The business server module receives the uploaded document information and signature, first performs signature verification and ciphertext decryption, and then verifies whether the document identity tag status has been issued. If it is not issued, it returns that the document is untrustworthy. For example, the trusted ID is 86F000001A01Q01, and the status is issued.

[0172] Step 4.9, the document identity tag status has been issued, and the document operation node attributes are verified to be non-empty to ensure that the data is valid. If the data verification fails, a data exception is returned;

[0173] Step 4.10, after verification, obtain the requested req_uuid as a unique identifier, example req_uuid: 164629695800001;

[0174] Step 4.11: Differentiate the chainSize (number of chains) in two modes:

[0175] Mode 1: Synchronous on-chain, applicable when chainSize is less than or equal to the threshold of 200;

[0176] Step 4.11.1.1, execute the synchronous chain operation, synchronously obtain the chain ID of the current data chain and related request result information, example chain ID: chain202203030808081035;

[0177] Step 4.11.1.2, based on the returned result information, verify whether the result information is correct, obtain the returned result status, if the status is OK, it is successful, save the current on-chain information ID to the corresponding record of the business system, based on the returned result information, if the verification result information is incorrect, feedback the abnormal result information and remind;

[0178] Mode 2: Asynchronous batch chaining, applicable when chainSize is greater than the threshold of 200;

[0179] Step 4.11.2.1, perform asynchronous batch on-chain operations;

[0180] Step 4.11.2.2, based on the returned result information, verify whether the result information is correct, obtain the returned result status, if the status is OK, it is successful, save the current task ID information, if the verification result information is incorrect, feedback the abnormal result information and remind;

[0181] Step 4.11.2.3, based on the returned task ID, use the scheduled task to query the on-chain ID. After querying the ID, save the current on-chain information ID to the corresponding record of the business system to facilitate subsequent associated queries.

[0182] Step 4.12: The central module receives the return value from the business service module. If the status is OK, the operation continues. If the status is abnormal, the abnormalities are eliminated one by one according to the abnormal prompt information and 4.6 to 4.12 are re-executed.

[0183] The scanning and loading operation has two modes:

[0184] Mode 1 is applicable to operations with less than 60 documents. The steps are as follows:

[0185] Step 5.1.1, physically isolate an area in the operation area as the scanning and loading verification area;

[0186] Step 5.1.2, scan and identify the document’s unique code, example document’s unique code: Q01KYQ3798;

[0187] Step 5.1.3, call the query interface of the business service module, obtain the document status according to the document unique code, and judge whether it meets the current operation requirements according to the status. If the status is bound, continue to execute the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification. The sample data is as follows:

[0188] Document unique code: Q01KYQ3798;

[0189] Status: Bound;

[0190] Step 5.1.4, encrypt the operation node attributes. The sample data is as follows:

[0191] Unique ID uuid: 154639695805361

[0192] Trusted ID: 86F000001A01Q01

[0193] Asset ID: Q01KYQ3798

[0194] Resource owner: XXXX Bank - XXX Department - Wang XX

[0195] Status: Registered

[0196] Process: Collection process

[0197] Action: Scan and load

[0198] Operation hash: 06945f3c660bce86a39e5579403aeb57

[0199] Operator: Zhao XX

[0200] The encrypted sample data is as follows:

[0201] U2FsdGVkX1 / R9C8+jKP65MQIYROwCu3hHlmNlSrM2+4+Lz4uBrS2S3PUnfU5HEEpzCL6j KfjkmiZlZ5sNfJmmP0RLDjAJd / IFcDh7n9s27iD2EYIJ / upuDL2RMmD6DxpC / EyOR0hJzg LNijQ6bnKsg+MM5GI2rsnTDqNU0S0d+ZDjg9Yupdi4XhovEvJ3zdBN2djCGk8ZMAu65VdUqJ9x3B5cVLJbf0h01BGK05ISyTuQnvIxofD9iyqk3ht1IUEg4e2AQAeTSNAJig8pBu7Us H8N6jALQcguXhYUG1QVNv / LdNisHsS4cyX4U8jqvSgrJFC+BrBI0WAbyRZlQ4egKWz5Dx S / ujYiwRnHGxb7oHNOypdzkpG4vaY1bhzIMKgrmgo36DiiBwSJkB0+VwFG0C5N9bIGrKDP 6 / LslchePu20oehU5JhYMw64F1iy34ovpI / L2aKf1dOxQ70 / W50FWPRcXPq90CbUkHxcA OvLOk8GTOVg2gyXNT6V33g0HkoDkf7eludH+Nd9LD65OCQqmWBCmVD2GbbOOtPsZmdebo=

[0202] Step 5.1.5: After the encryption in step 5.1.4 is successful, the scanning and loading interface of the business server is called with the encrypted document information and signature to execute steps 4.8 to 4.11 for chain operation, and the document status is updated to loaded;

[0203] Step 5.1.6, load the documents into the truck;

[0204] Step 5.1.7: Repeat steps 5.1.2 to 5.1.6 until all document operations are completed;

[0205] Step 5.1.8, scan and check the documents in the waiting area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps 5.1.2 to 5.1.6 after correcting the abnormal documents until all documents are loaded;

[0206] Step 5.1.9, after all documents are loaded, generate and print the handover note. After the customer checks and signs, the truck is transported to the warehouse.

[0207] Mode 2 is applicable to operations with more than 60 documents. The steps are as follows:

[0208] Step 5.2.1, physically isolate an area in the operation area as the scanning and loading verification area;

[0209] Step 5.2.2, batch scan document identity tags to obtain trusted IDs, example identity tag: 86F000001A01Q01;

[0210] Step 5.2.3, call the query interface of the business service module, obtain the document status according to the document trusted ID, and determine whether it meets the current operation requirements based on the status. If the status is bound, continue to execute the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification;

[0211] Step 5.2.4, encrypt the document identity tag and the operation node attribute. The sample data is as follows:

[0212] Unique ID uuid: 154639695805361

[0213] Trusted ID: 86F000001A01Q01

[0214] Asset ID: Q01KYQ3798

[0215] Resource owner: XXXX Bank - XXX Department - Wang XX

[0216] Status: Registered

[0217] Process: Collection process

[0218] Action: Scan and load

[0219] Operation hash: 06945f3c660bce86a39e5579403aeb57

[0220] Operator: Zhao XX

[0221] The encrypted sample data is as follows:

[0222] U2FsdGVkX1 / R9C8+jKP65MQIYROwCu3hHlmNlSrM2+4+Lz4uBrS2S3PUnfU5HEEpzCL6j KfjkmiZlZ5sNfJmmP0RLDjAJd / IFcDh7n9s27iD2EYIJ / upuDL2RMmD6DxpC / EyOR0hJzg LNijQ6bnKsg+MM5GI2rsnTDqNU0S0d+ZDjg9Yupdi4XhovEvJ3zdBN2djCGk8ZMAu65VdUqJ9x3B5cVLJbf0h01BGK05ISyTuQnvIxofD9iyqk3ht1IUEg4e2AQAeTSNAJig8pBu7Us H8N6jALQcguXhYUG1QVNv / LdNisHsS4cyX4U8jqvSgrJFC+BrBI0WAbyRZlQ4egKWz5Dx S / ujYiwRnHGxb7oHNOypdzkpG4vaY1bhzIMKgrmgo36DiiBwSJkB0+VwFG0C5N9bIGrKDP 6 / LslchePu20oehU5JhYMw64F1iy34ovpI / L2aKf1dOxQ70 / W50FWPRcXPq90CbUkHxcA OvLOk8GTOVg2gyXNT6V33g0HkoDkf7eludH+Nd9LD65OCQqmWBCmVD2GbbOOtPsZmdebo=

[0223] Step 5.2.5: After step 5.2.4 succeeds, the encrypted document information and signature will be carried to call the scanning and loading interface of the business server and execute steps 4.8 to 4.11 to upload the document to the chain, and the document status will be updated to loaded;

[0224] Step 5.2.6, load the documents into the truck;

[0225] Step 5.2.7, scan and check the documents in the waiting area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps 5.2.3 to 5.2.6 after correcting the abnormal documents until all documents are loaded;

[0226] Step 5.2.8, after all documents are loaded, generate and print the handover note. After the customer checks and signs, the truck is transported to the warehouse.

[0227] The scanning and storage operation has two modes:

[0228] Mode 1 is applicable to operations with less than 60 documents. The steps are as follows:

[0229] Step 6.1.1, physically isolate an area in the operation area as the scanning and warehousing verification area;

[0230] Step 6.1.2, take the document from the truck, scan and identify the document unique code, example document unique code: Q01KYQ3798;

[0231] Step 6.1.3, call the query interface of the business service module, obtain the document status according to the document unique code, and judge whether it meets the current operation requirements according to the status. If the status is loaded, continue to perform the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification. The sample data is as follows:

[0232] Document unique code: Q01KYQ3798;

[0233] Status: Loaded;

[0234] Step 6.1.4, encrypt the document operation node attributes. The sample data is as follows:

[0235] Unique ID uuid: 154639695805361

[0236] Trusted ID: 86F000001A01Q01

[0237] Asset ID: Q01KYQ3798

[0238] Resource owner: XXXX Bank - XXX Department - Wang XX

[0239] Status: Loaded

[0240] Process: Collection process

[0241] Behavior: Scan and store

[0242] Operation hash: 480c62bfdd7c29220c5c39df657118de

[0243] Operator: Zhao XX

[0244] The encrypted sample data is as follows:

[0245] U2FsdGVkX1 / R9C8+jKP65MQIYROwCu3hHlmNlSrM2+4+Lz4uBrS2S3PUnfU5HEEpzCL6j KfjkmiZlZ5sNfJmmP0RLDjAJd / IFcDh7n9s27iD2EYIJ / upuDL2RMmD6DxpC / EyOR0hJzg LNijQ6bnKsg+MM5GI2rsnTDqNU0S0d+ZDjg9Yupdi4XhovEvJ3zdBN2djCGk8ZMAu65VdUqJ9x3B5cVLJbf0h01BGK05ISyTuQnvIxofD9iyqk3ht1IUEg4e2AQAeTSNAJig8pBu7Us H8N6jALQcguXhYUG1QVNv / LdNisHsS4cyX4U8jqvSgrJFC+BrBI0WAbyRZlQ4egKWz5Dx S / ujYiwRnHGxb7oHNOypdzkpG4vaY1bhzIMKgrmgo36DiiBwSJkB0+VwFG0C5N9bIGrKDP 6 / LslchePu20oehU5JhYMw64F1iy34ovpI / L2aKf1dOxQ70 / W50FWPRcXPq90CbUkHxcA OvLOk8GTOVg2gyXNT6V33g0HkoDkf7eludH+Nd9LD65OCQqmWBCmVD2GbbOOtPsZmdebo=

[0246] Step 6.1.5: After step 6.1.4 succeeds, call the scanning and loading interface of the business server with the encrypted operation node attributes and signature to execute steps 4.8 to 4.11 for chain operation, and update the document status to stored;

[0247] Step 6.1.6, put the document into the secure storage area;

[0248] Step 6.1.7: Repeat steps 6.1.2 to 6.1.6 until all document operations in the truck are completed;

[0249] Step 6.1.8, scan and check the documents in the waiting area one by one, analyze the cause of the abnormality according to the status of the document, and execute steps 6.1.3 to 6.1.6 after correcting the abnormal documents until all documents are placed in the safe storage area.

[0250] Mode 2 is applicable to operations with more than 60 documents. The steps are as follows:

[0251] Step 6.2.1, physically isolate an area in the operation area as the scanning and warehousing verification area;

[0252] Step 6.2.2, take the documents from the truck, and scan the document identity tags in batches to obtain the trusted ID. Example trusted ID: 86F000001A01Q01;

[0253] Step 6.2.3, call the query interface of the business service module, obtain the document status according to the document trusted ID, and determine whether it meets the current operation requirements based on the status. If the status is loaded, continue to perform the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification. The sample data is as follows:

[0254] Trusted ID: 86F000001A01Q01;

[0255] Status: Loaded;

[0256] Step 6.2.4, encrypt the document unique code and operation node attributes. The sample data is as follows:

[0257] Unique ID uuid: 154639695805361

[0258] Trusted ID: 86F000001A01Q01

[0259] Asset ID: Q01KYQ3798

[0260] Resource owner: XXXX Bank - XXX Department - Wang XX

[0261] Status: Loaded

[0262] Process: Collection process

[0263] Behavior: Scan and store

[0264] Operation hash: 480c62bfdd7c29220c5c39df657118de

[0265] Operator: Zhao XX

[0266] The encrypted sample data is as follows:

[0267] U2FsdGVkX1 / R9C8+jKP65MQIYROwCu3hHlmNlSrM2+4+Lz4uBrS2S3PUnfU5HEEpzCL6j KfjkmiZlZ5sNfJmmP0RLDjAJd / IFcDh7n9s27iD2EYIJ / upuDL2RMmD6DxpC / EyOR0hJzg LNijQ6bnKsg+MM5GI2rsnTDqNU0S0d+ZDjg9Yupdi4XhovEvJ3zdBN2djCGk8ZMAu65VdUqJ9x3B5cVLJbf0h01BGK05ISyTuQnvIxofD9iyqk3ht1IUEg4e2AQAeTSNAJig8pBu7Us H8N6jALQcguXhYUG1QVNv / LdNisHsS4cyX4U8jqvSgrJFC+BrBI0WAbyRZlQ4egKWz5Dx S / ujYiwRnHGxb7oHNOypdzkpG4vaY1bhzIMKgrmgo36DiiBwSJkB0+VwFG0C5N9bIGrKDP 6 / LslchePu20oehU5JhYMw64F1iy34ovpI / L2aKf1dOxQ70 / W50FWPRcXPq90CbUkHxcA OvLOk8GTOVg2gyXNT6V33g0HkoDkf7eludH+Nd9LD65OCQqmWBCmVD2GbbOOtPsZmdebo=

[0268] Step 6.2.5: After step 6.2.4 succeeds, the scanning and loading interface of the business server is called with the encrypted document operation node attributes and signature, and steps 4.8 to 4.11 are executed for chain operation, and the document status is updated to stored;

[0269] Step 6.2.6, put the document into the secure storage area;

[0270] Step 6.2.7, scan and check the documents in the waiting area one by one, analyze the cause of the abnormality according to the status of the document, and execute steps 6.2.3 to 6.2.6 after correcting the abnormal documents until all documents are placed in the safe storage area.

[0271] The present invention provides an intensive document handover record system based on blockchain technology. There are many methods and ways to implement the technical solution. The above is only a preferred implementation of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention. All components not specified in this embodiment can be implemented using existing technologies.

Claims

1. An intensive document handover record system based on blockchain technology, characterized in that: It includes business device module, hub module, business service module and blockchain trusted module; The business device end module runs on the IoT device, registers and issues the IoT device, and the IoT device that is successfully registered and issued is called a trusted IoT device; The central module receives and processes document data uploaded by multiple business device modules, and provides users with face login verification, document information verification, signature confirmation and document information upload functions; The business service module provides an upload binding interface for the central module, and receives and processes the data uploaded synchronously by the central module; The blockchain trusted module is used to issue trusted IoT devices and identity tags, verify the source of data, and provide data on-chain and on-chain query API interfaces for the business server module; The business service module is used to receive and process data from the business device module, and provide the business device module with an equipment registration and issuance interface, an equipment verification interface, a document query interface, a scanning and loading interface, and a scanning and warehousing interface; The device registration and issuance interface is responsible for registering and issuing the device on the chain for the device_id and imei passed in by the business device module, which specifically includes the following steps: Step a1, accept the device_id and imei passed in by the service device module, verify that the device_id and imei are not empty to ensure that the data is valid. If the data verification fails, a data exception is returned; Step a2, query the device_id and imei on the chain service to confirm whether they have been registered. If they have been registered, return duplicate registration exception information; Step a3: If the device is not registered, perform the device registration operation, call the chain registration according to device_id and imei, and return the chain ID of the currently registered device; Step a4: After the device is successfully registered, it is issued on the chain according to the returned on-chain ID. The issued IoT device is a trusted IoT device. The device authentication interface is responsible for checking the device to verify whether it is a trusted IoT device, specifically including the following steps: Step b1, receiving the device_id passed in by the service device module, verifying that the device_id is not empty to ensure that the data is valid. If the data verification fails, a data exception is returned; Step b2: query the service registration record according to device_id. If no result is found, registration is not performed and abnormal data is returned. Step b3: Verify the status of the queried record. If the status is unissued or cancelled, return data exception. Otherwise, return device verification success and related business operations can be performed. The document query interface is responsible for querying the node attribute information on the real chain based on the chain ID of the data that has been uploaded to the chain; The scanning loading interface is responsible for scanning and checking the data that has been bound and is ready to be loaded. If the check passes, the flow status is changed to loaded. If the check fails, data abnormality information is returned; The scanning and warehousing interface is responsible for scanning and checking the data that has been loaded and is ready to be put into the warehouse. If the check passes, the flow status is changed to "put into the warehouse". If the check fails, data abnormality information is returned.

2. The system according to claim 1, characterized in that The service device end module registers and issues the IoT device, including the following steps: Step c1, generate device_id based on the IoT device information, where device_id refers to a unique identification code based on the IoT device information; Step c2, carry device_id and imei, call the device registration interface of the service server module to register, imei refers to the international mobile equipment identity; Step c3, after successful registration, obtain the on-chain device ID; The iot device refers to an internet of things device with networking function; The IoT device information includes manufacturer, product model, production date, product batch, MAC address, device_id, and imei; The IoT device includes the following states: unissued, issued, and deregistered, where the unissued state refers to a device that has not been used after registration, the issued state refers to the device being in use, and the deregistered state means that the current device has been abandoned and cannot perform business operations.

3. The system according to claim 2, characterized in that After the business device module is started, it performs a self-check and sends the device_id to the business server module for verification. If the business server returns true, the self-check passes, indicating that the IoT device is a trusted IoT device and can be operated. Otherwise, the self-check fails, indicating that the IoT device is untrustworthy and the output fails.

4. The system according to claim 3, characterized in that The business device-side module can encrypt and sign the collected data through the Hash algorithm. The encryption refers to the business device-side module encrypting the transmitted data through the built-in public key and hash algorithm, and the business service-side module receives the ciphertext information and decrypts it through the corresponding private key to obtain the correct transmission information; the signing refers to the business device-side module encrypting the device_id through the built-in private key and hash algorithm, and the business service-side module receives the encrypted device_id and decrypts it through the corresponding public key to obtain the correct device_id.

5. The system according to claim 4, characterized in that The business device module is also used for distributed collection of document information, data signing and data synchronization, and specifically includes the following steps: Step d1, scan and identify the unique code of the document; Step d2, collecting document image data and generating document information; Step d3, encrypting the current operation node attribute and the document information generated in step d2; Step d4: if step d3 is successful, the encrypted document information and signature are synchronously uploaded to the central module, and the document status is updated to registered; If step d3 fails, the failure reason is prompted and investigated, and steps d1 to d3 are executed again.

6. The system according to claim 5, characterized in that The business device module is also used to complete the scanning and loading operation. The scanning and loading operation includes two modes, namely mode 1 and mode 2. Mode 1 is suitable for a small number of document operations, that is, when the number of documents is less than or equal to a threshold, and specifically includes the following steps: Step e1, physically isolate an area in the operation area as a scanning and loading verification area; Step e2, scanning and identifying the unique code of the document; Step e3, calling the query interface of the business service module, obtaining the document status according to the document unique code, judging whether it meets the current operation requirements according to the status, if the status is bound, continue to execute the following steps, otherwise, the process is terminated, an error message is output, and the document is placed in the waiting area for verification; Step e4, encrypting the document unique code and the operation node attribute; Step e5: After step e4 succeeds, the scanning and loading interface of the business server is called with the encrypted document information and signature to update the document status to loaded; Step e6, loading the documents into the truck; Step e7, repeating steps e2 to e6 until all document operations are completed; Step e8, scan and check the documents in the to-be-checked area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps e3 to e6 after correcting the abnormal documents until all the documents have been loaded; Step e9: After all documents are loaded, a handover note is generated and printed. After the customer checks and signs, the truck is transported to the warehouse; Mode 2 is applicable to operations involving a large number of documents, that is, when the number of documents is greater than the threshold, and includes the following steps: Step f1, physically isolate an area in the operation area as a scanning and loading verification area; Step f2, batch scanning of document identity tags; Step f3, calling the query interface of the business service module, obtaining the document status according to the document identity tag, judging whether it meets the current operation requirements according to the status, if the status is bound, continue to execute the following steps, otherwise, the process is terminated, an error message is output, and the document is placed in the waiting area for verification; Step f4, encrypting the document identity tag and the operation node attribute; Step f5: After step f4 succeeds, the encrypted document information and signature will be carried to call the scanning and loading interface of the business server to update the document status to loaded; Step f6, loading the documents into the truck; Step f7, scan and check the documents in the to-be-checked area one by one, analyze the abnormal reasons according to the status of the documents, and perform steps f3 to f6 after correcting the abnormal documents until all the documents have been loaded; Step f8: After all documents are loaded onto the truck, a handover note is generated and printed. After the customer checks and signs for correctness, the truck is transported to the warehouse.

7. The system according to claim 6, characterized in that The business device module is also used for scanning and warehousing operations. The scanning and warehousing operations include two modes, namely mode 1 and mode 2. Mode 1 is suitable for operations with a small number of documents, that is, when the number of documents is less than or equal to a threshold, and specifically includes the following steps: Step g1, physically isolate an area in the operation area as a scanning and warehousing verification area; Step g2, taking out the document from the truck, scanning and identifying the unique code of the document; Step g3, call the query interface of the business service module, obtain the document status according to the document unique code, and judge whether it meets the current operation requirements according to the status. If the status is loaded, continue to execute the following steps, otherwise, terminate the process, output an error message, and put the document in the waiting area for verification; Step g4, encrypting the document operation node attributes; Step g5: After step g4 succeeds, the scanning and loading interface of the business server is called with the encrypted document information and signature to update the document status to "in storage"; Step g6, putting the document into the secure storage area; Step g7, repeat steps g2 to g6 until all document operations in the truck are completed; Step g8, scan and check the documents in the to-be-checked area one by one, analyze the abnormal reasons according to the status of the documents, and execute steps g3 to g6 after correcting the abnormal documents until all the documents are put into the safe storage area; Mode 2 is applicable to operations involving a large number of documents, that is, when the number of documents is greater than the threshold, and includes the following steps: Step h1, physically isolate an area in the operation area as a scanning and warehousing verification area; Step h2, taking the documents from the truck and scanning the document identity tags in batches; Step h3, call the query interface of the business service module, obtain the document status according to the document identity tag, and judge whether it meets the current operation requirements according to the status. If the status is loaded, continue to execute the following steps, otherwise terminate the process, output an error message, and put the document in the waiting area for verification; Step h4, encrypting the document identity tag and the operation node attribute; Step h5: After step h4 succeeds, the encrypted document information and signature are carried to call the scanning and loading interface of the business server to update the document status to stored; Step h6, putting the document into the secure storage area; Step h7, scan and check the documents in the area to be checked one by one, analyze the cause of the abnormality according to the status of the document, and execute steps h3 to h6 after correcting the abnormal document until all documents are placed in the safe storage area.

8. The system according to claim 7, characterized in that The central module specifically performs the following steps: Step i1, the user enters the account number and enters the central module after face login verification; Step i2: Enter the central module to view the list of documents collected under the account, sign and confirm after verification, and generate an operation record; In step i3, the custodian uploads the verified document to the business server, calls the upload binding interface, and updates the document status to bound.

9. The system according to claim 8, characterized in that The business service module is used to collect document operation node attributes and send the collected document operation node attributes to the blockchain trusted module. The operation node attributes include: operation node unique identifier node_uuid, document unique code, trusted ID, resource owner, status, process, behavior, operation hash, file hash, operator, device ID and operation time, specifically including the following steps: Step j1, receiving the collected data and making preparations before uploading to the chain, verifying whether the document identity tag status has been issued. If it is not issued, the document is returned as untrustworthy; Step j2: If the document identity tag status has been issued, the document operation node attribute is verified to be non-empty to ensure the data is valid. If the data verification fails, a data exception is returned; Step j3, after verification, obtain the requested req_uuid as a unique identifier; Step j4, distinguish and process the number of data on the chain, obtain the number of data on the chain currently (chainSize), and perform corresponding processing for different data volumes, specifically including the following steps: Step j4-1, if chainSize is less than or equal to the threshold, synchronous chaining is used for operation. After executing the chaining, synchronous chaining can synchronously obtain the chain ID of the current data chaining and related request result information; Step j4-2, verify whether the result information is correct according to the returned result information, obtain the returned result status, if the status is OK, it is successful, and save the current on-chain information ID to the corresponding record of the business system; Step j4-3, based on the returned result information, verify that the result information is incorrect, and provide feedback and reminder on the abnormal result information; Step j4-4, if chainSize is greater than the threshold, asynchronous batch chaining is used for operation, and asynchronous chaining needs to be processed according to the task ID of the execution feedback; Step j4-5, verify whether the result information is correct according to the returned result information, obtain the returned result status, if the status is OK, it is successful, and save the current task ID information; Step j4-6, based on the result information returned by the execution, verify that the result information is incorrect, and provide feedback and reminder on the abnormal result information; Step j4-7, when asynchronously uploading to the chain, use the scheduled task to query the on-chain ID according to the returned task ID. After the ID is queried, save the current on-chain information ID to the corresponding record of the business system; The trusted ID is the identity tag content; The identity tag status includes: to be produced, to be issued, and issued; The identity tag has an issuance operation, including the following steps: Step k1, affixing the identity label to the document cover; Step K2: The trusted IoT device identifies the unique code of the document and the identity tag content, and encrypts the content; Step k3: After step k2 succeeds, the trusted IoT device carries the ciphertext and signature generated in step k2 and uploads them to the business server module synchronously, and the business server module performs the issuance operation; Step k4: After step k3 succeeds, the identity tag is in an issued state, and the trusted ID is the content of the identity tag.

Images