Block chain-based after-sales service quality real-time monitoring method and system

Abstract

The invention provides an after-sales service quality real-time monitoring method and system based on a block chain, and relates to the technical field of after-sales service monitoring. The method comprises the following steps: acquiring a node identifier and an uploading requirement corresponding to the node identifier; according to the corresponding node identifier, controlling or prompting the service terminal to perform data acquisition for the unstructured data and the specified metadata according to an uploading requirement corresponding to the node identifier; generating a corresponding hash value as a unique identifier according to the unstructured data; combining the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submitting the structured data packet to a preset distributed account book; updating of the service record state is monitored in real time, and the intelligent contract deployed on the distributed account book is used for checking the unstructured data hash value record associated with the current forced data association node. According to the method, the credibility and the utilization value of the unstructured information generated in the service process are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of after-sales service monitoring, and in particular, to a real-time monitoring method and system for after-sales service quality based on blockchain. Background Art

[0002] Enterprises providing after-sales service for users is an indispensable part of the product life cycle. When the product purchased by a user has abnormal functions during use, the user usually initiates a repair request through the service channels provided by the enterprise. After the service management system within the enterprise receives the user's repair request, it will intelligently dispatch the service task to a service personnel with corresponding qualifications and conditions by comprehensively considering various factors such as product type, user geographical location, and the skill specialties of available service personnel. After receiving the dispatched task, the service personnel will actively contact the user, negotiate and determine the specific on-site service time and location, and then go to the user's location to provide on-site service, or provide service through remote guidance and other means if conditions permit.

[0003] During the service execution process, the service personnel need to conduct a comprehensive inspection of the abnormal product, diagnose the cause of the fault, and perform operations such as troubleshooting, repair, or replacement of damaged parts. To ensure the transparency and traceability of the service process, the service personnel also need to record in detail the key information during the service process, which usually includes but is not limited to the specific start time of the service, the end time of the service, a detailed description of the product fault, the treatment methods and steps taken, the part code used during the repair, the quantity of the parts used, etc. After the service work is completed, the service personnel need to organize and submit a complete service report based on these records. After receiving the service report, the user usually needs to confirm the service result and is invited to evaluate the entire service process and the performance of the service personnel, including service attitude, problem-solving situation, etc.

[0004] To further enhance the authenticity of after-sales service data, ensure the immutability and traceability of data, and at the same time improve the objectivity and fairness of service quality evaluation, some enterprises have started to actively explore and introduce Distributed Ledger Technology (DLT). Under this new technical framework, a series of key data in the after-sales service process, such as the details of repair requests initiated by users, the dispatching information of service tasks, the actual start and end times of services, the content of service reports submitted by service personnel, the confirmation status of service results by users, and the service evaluations submitted by users, are collected through specific data collection mechanisms and recorded on the distributed ledger in a structured form. The core feature of the distributed ledger lies in its data structure and consensus mechanism design, making it extremely difficult to tamper with data once it is successfully recorded on the ledger, thus greatly improving the credibility of these key service data.

[0005] On this basis, enterprises further utilize smart contracts to automate the processing of business logics based on this trusted data on the chain. For example, preset smart contracts can automatically and accurately calculate the service fees to be paid, or evaluate and calculate the performance scores of service personnel, according to structured data such as the service type recorded on the distributed ledger, the actual duration of the service, and the part information used during the repair. If the user completes the confirmation and evaluation of the service within the preset specified time, the smart contract can further trigger corresponding reward (for service personnel) or penalty logics to encourage high-quality services and restrain improper behaviors. When service disputes occur, due to the immutability of the key service process data recorded on the distributed ledger, these data can be used as objective and reliable evidence for tracing the truth and assisting in fair arbitration.

[0006] However, in actual after-sales service scenarios, there are some very important pieces of information that often exist in unstructured or semi-structured forms, making it difficult to collect them through standardized processes and also difficult to directly adapt and store them in the structured data fields preset in the distributed ledger. For example, when service personnel handle complex or rare faults, they may need to communicate with users for a long time and in detail to explain the root causes of the faults, analyze different treatment options, and obtain user consent; unexpected emergencies may occur during the service process, requiring service personnel to temporarily adjust the plan or take emergency response measures; when users evaluate the service, in addition to selecting the preset rating levels, they often provide a large amount of text descriptions covering aspects such as service details, the communication attitude of service personnel, and whether the problem has been completely resolved. These unstructured or semi-structured pieces of information, such as service notes recorded by service personnel on-site, detailed text content entered by users in their evaluations, photos taken during the service process to record the on-site situation or fault points, and audio clips recorded to record communication content or on-site sounds, are of extremely important value for comprehensively and deeply understanding the entire service process, accurately evaluating service quality, analyzing the underlying causes of complex problems, and continuously improving service processes and enhancing the skills of service personnel.

[0007] These unstructured or semi-structured information, due to its diverse content forms (text, pictures, audio, etc.), complex structure and potentially large content volume, is difficult to be directly stored in the storage unit with limited capacity of the distributed ledger and mainly designed for structured data, and is also difficult to be directly parsed and utilized by the smart contract that conducts logical judgment based on structured data. Although a common practice is to store this unstructured information in an off-chain storage system (such as a distributed file system), and then only record a unique identifier pointing to the off-chain storage location in the on-chain distributed ledger, such as the hash value of the data. This way can ensure the "integrity" of the information (that is, once the data stored off-chain is modified, its hash value will change, resulting in the hash value recorded on-chain no longer matching, thus tampering can be detected), but it does not fundamentally solve the problem of how to ensure the "authenticity" of these off-chain stored unstructured or semi-structured information itself. When service personnel or users submit this unstructured information, they may still be affected by subjective factors, and there is a possibility of selective uploading and exaggerating facts. For example, in order to prove the correctness of their operations, service personnel may only selectively upload photos or recordings that are beneficial to themselves; when expressing dissatisfaction, users may exaggerate the faults of service personnel in written evaluations. Due to the lack of strict trustworthy collection and verification processes in the generation and collection links of this information, its original authenticity is in doubt. Therefore, the smart contract cannot fully rely on the on-chain hash value of this information for automated business processing (for example, it cannot judge whether the content of a photo meets the requirements based on the hash value of the photo), and service quality monitoring cannot fully trust and utilize these key detailed information for comprehensive and in-depth analysis. Especially when service disputes occur, the authenticity of the unstructured evidence stored off-chain often needs to be additionally verified and corroborated through other independent channels, which undoubtedly increases the complexity and difficulty of dispute handling.

[0008] Therefore, in the current after-sales service quality monitoring system adopting the distributed ledger and smart contract architecture, how to design an effective mechanism that can credibly capture, securely store, reliably associate with the on-chain structured service records, and ultimately be able to effectively utilize the unstructured or semi-structured key information generated during these services has become the key challenge to improve the after-sales service quality monitoring ability, enhance data credibility, and optimize the dispute handling process. Summary of the Invention

[0009] The object of the present invention is to provide a real-time monitoring method and system for after-sales service quality based on blockchain. By forcibly associating unstructured data and its metadata at key nodes of the after-sales service process, and using the distributed ledger and smart contract for on-chain verification, the credibility and utilization value of the unstructured information (such as photos, recordings, detailed notes, etc.) generated during the service process are significantly improved.

[0010] In a first aspect, the present invention provides a method for real-time monitoring of after-sales service quality based on blockchain, comprising the following steps: Obtain the node identifier of a preset mandatory data association node in the service process, and the corresponding upload requirements, where the upload requirements include the specified unstructured data type and the upload quantity; When the service terminal enters the mandatory data association node, according to the corresponding node identifier, control or prompt the service terminal to collect data for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier; Upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value for the unstructured data as a unique identifier; Combine the specified metadata and the corresponding unstructured data hash value into a structured data packet, and submit it as a piece of on-chain transaction data to a preset distributed ledger; Real-time monitor the update of the service record status, and when the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node; if the verification passes, allow the service status to advance; if the verification fails, prevent the service status from advancing, and mark the service record status as an abnormal status.

[0011] The method for real-time monitoring of after-sales service quality based on blockchain provided by the present invention establishes a mandatory association mechanism in the product after-sales service quality monitoring system based on a distributed ledger and a smart contract, so as to ensure that unstructured key information (such as on-site photos, recordings, etc.) in the service process can be reliably collected, irreversibly associated with the on-chain structured service record, and its existence can be verified at the smart contract level, thereby improving the credibility and automated processing ability of this information as the basis for service quality evaluation and dispute traceability.

[0012] In a second aspect, the present invention provides a system for real-time monitoring of after-sales service quality based on blockchain, comprising: An acquisition module, configured to obtain the node identifier of a preset mandatory data association node in the service process, and the corresponding upload requirements, where the upload requirements include the specified unstructured data type and the upload quantity; The collection module is used to control or prompt the service terminal to collect unstructured data and specified metadata according to the corresponding upload requirements corresponding to the node identifier when the service terminal enters the forced data association node; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier. The generation module is used to upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier according to the unstructured data. The transaction module is used to combine the specified metadata and the corresponding unstructured data hash value into a structured data packet and submit it as a piece of on-chain transaction data to a preset distributed ledger. The verification module is used to monitor the update of the service record status in real time, and when the service record status attempts to advance from the current forced data association node to the next forced data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current forced data association node; if the verification passes, the service status is allowed to advance; if the verification fails, the service status advancement is blocked, and the service record status is marked as an abnormal status.

[0013] As can be seen from the above, the real-time monitoring method for after-sales service quality based on blockchain provided by the present invention, by forcibly collecting and recording metadata at key process points, collaborating with off-chain and on-chain storage and association, and using smart contracts for forced verification, transforms unstructured data from "optional and doubtful" into key service evidence that is "necessary for the process, reliably associated, and provable on-chain", greatly improving the efficiency and reliability of service quality monitoring and dispute handling. In this way, the collection of unstructured data is closely coupled with the advancement of the service process, and the immutable and automated verification characteristics of the distributed ledger and smart contract are used to ensure the reliable association and on-chain traceability of unstructured data.

[0014] Other features and advantages of the present invention will be described in the subsequent specification, and part of them will become obvious from the specification, or can be understood by implementing the embodiments of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the structures specifically pointed out in the written specification and the drawings. Description of the Drawings

[0015] Figure 1 It is a flowchart of a real-time monitoring method for after-sales service quality based on blockchain provided by an embodiment of the present invention.

[0016] Figure 2It is a schematic structural diagram of a real-time monitoring system for after-sales service quality based on blockchain provided by an embodiment of the present invention.

[0017] Label description: 100, acquisition module; 200, collection module; 300, generation module; 400, transaction module; 500, verification module. Specific implementation manners

[0018] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Usually, the components of the embodiments of the present invention described and illustrated herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the present invention to be protected, but only represents the selected embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.

[0019] It should be noted that: similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of the present invention, terms such as "first", "second", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0020] Referring to the attached Figure 1 , the present invention provides a real-time monitoring method for after-sales service quality based on blockchain, including the following steps: Obtain the node identifier of a preset mandatory data association node in the service process, and the upload requirements corresponding to the node identifier, where the upload requirements include the specified unstructured data type and the upload quantity; When the service terminal enters the mandatory data association node, according to the corresponding node identifier, control or prompt the service terminal to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier; Upload the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier according to the unstructured data (if someone attempts to modify the unstructured data stored off-chain, its hash value will change, resulting in no longer matching the hash value recorded on the chain, thereby detecting tampering behavior); Combine the specified metadata and the corresponding unstructured data hash value as associated information into a structured data packet, and submit it as a piece of on-chain transaction data to a preset distributed ledger; when the distributed ledger confirms and records this transaction, an immutable on-chain record is formed. Monitor the update of the service record status in real time. When the service record status attempts to advance from the current mandatory data association node to the next mandatory data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current mandatory data association node. If the verification passes, allow the service status to advance; if the verification fails, block the service status from advancing and mark the service record status as an abnormal status.

[0021] This method obtains the node identifier of the preset mandatory data association node in the service process, as well as the upload requirements corresponding to this node identifier. The upload requirements include the specified unstructured data type and the upload quantity. This step determines which links in the service process require data collection, as well as the data type and quantity to be collected, thereby ensuring data collection at key links in the service process. Further, when the service terminal enters a mandatory data association node, according to the corresponding node identifier, control or prompt the service terminal to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to this node identifier. The specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier. This step obtains the unstructured evidence and its associated context information in the service process, providing a data basis for subsequent verification and traceability. Thus, the technical problem of trustworthy association of unstructured data is solved.

[0022] Specifically, this method solves the technical problem of trustworthy association and verification of unstructured data in the after-sales service process by forcibly collecting unstructured data and its associated metadata at specific nodes in the after-sales service process and recording the hash values of these data on a distributed ledger. First, the method obtains the identifiers of the preset forced data association nodes in the service process and the corresponding upload requirements. This step sets the trigger conditions and content specifications for data collection. Next, when the service terminal reaches these preset nodes, the method controls or prompts the service terminal to collect unstructured data and specified metadata according to the node identifiers. The metadata includes the service record ID, collection time, geographical location, terminal device identifier, and operator identifier. These information provide the context in which the unstructured data is generated and associate it with specific service records. Then, the collected unstructured data and metadata are uploaded to an off-chain distributed file storage system. The method calculates the hash value of the unstructured data and uses the hash value as the identifier of the data. Off-chain storage solves the problem that a large amount of unstructured data is not suitable for direct uploading to the chain, and the hash value provides proof of data integrity. Subsequently, the method combines the metadata and the hash value of the unstructured data into a structured data packet and submits it as an on-chain transaction to the preset distributed ledger. The characteristics of the distributed ledger ensure that these associated information and hash values cannot be tampered with once recorded. Thus, the technical problem of trustworthy association of unstructured data is solved. Finally, the method monitors the service record status in real time. When a service record attempts to advance from the current forced data association node to the next forced data association node, the smart contract deployed on the distributed ledger queries the corresponding on-chain data through the ID identifier of the current service record status and verifies the hash value record of the unstructured data associated with the current forced data association node. If the verification passes, the service status is allowed to advance. If the verification fails, the service status advancement is blocked and the service record status is marked as an abnormal status. This step uses the immutable hash value on the chain to verify the integrity of the off-chain data and combines the verification result with the service process control to ensure that the service can continue only when the data is complete and the association is correct, realizing the automated control and anomaly detection of the service process based on trustworthy data, and thus solving the technical problem of trustworthy verification of unstructured data.

[0023] In some specific embodiments, assume that a service technician is diagnosing a washing machine failure, and the system requires that a photo of the failure point must be uploaded. The service technician uses the service terminal application to take a photo of the damaged motor inside the washing machine. This photo file is the unstructured data. The terminal application automatically records the specific time of shooting, the user's home address (geographical location) where the service technician is located, the model of the mobile phone used by the service technician (terminal device identifier), and the service technician's work number (operator identifier) when taking the photo. These are the collected metadata.

[0024] According to the steps, this photo file and these collected metadata will be uploaded to an off-chain distributed file storage system, such as a storage cluster built based on IPFS (InterPlanetary File System) or Ceph. At the same time, the system will calculate a hash value for this photo file, for example, obtaining a unique string of characters using the SHA-256 algorithm.

[0025] The function of this process is that the photo itself (unstructured data) and the background information at the time of its shooting (collected metadata) are securely stored, and a hash value representing the uniqueness of the photo content is generated. Subsequently, this hash value and the association information of the photo with the current service record and the "fault diagnosis" node will be recorded on the distributed ledger. If someone attempts to modify the content of the photo stored off-chain, its hash value will change and no longer match the hash value recorded on the chain, thus detecting the tampering behavior. The collected metadata can help determine whether the photo was taken by the service personnel at the time and location of the service, increasing the credibility of the photo as evidence. The off-chain distributed file storage system can be implemented using various technologies, such as distributed storage solutions like IPFS, Ceph, MinIO, or a distributed storage architecture built based on cloud storage services.

[0026] In some other specific embodiments, assume a home appliance repair service with a service record ID of "SR789". The service process reaches the "fault diagnosis" node. The service personnel use the terminal application to take a photo of the faulty component. According to this method, the terminal application calculates the hash value of this photo, for example, "HashXYZ". At the same time, the terminal records the time when the photo was taken (e.g., "2023-10-27 10:30:00"), the geographical location (e.g., "N31.2 E121.5"), the terminal device identifier (e.g., "DeviceA"), and the service personnel identifier (e.g., "Tech001").

[0027] The function of this step is to combine this information: "SR789" (service record ID), "fault diagnosis" (current service node identifier), "HashXYZ" (unstructured data hash value), "2023-10-27 10:30:00" (collection timestamp), "photo" (data type), "Tech001" (operator identifier) into a structured data packet to form a piece of on-chain transaction data and submit it to the distributed ledger.

[0028] Once this transaction is confirmed and recorded by the distributed ledger, it forms an immutable on-chain record, proving that at a specific time, specific location, by a specific service personnel, a photo is associated with the "fault diagnosis" node of the service record "SR789", and its content is uniquely determined by "HashXYZ".

[0029] The specific implementation method of submitting such associated information to the distributed ledger can be as follows: The service terminal application directly submits transactions through the client interface of the distributed ledger; or the service terminal sends data to the enterprise backend service, and the backend service constructs and submits the transactions to the distributed ledger on behalf of it.

[0030] Through this step, even if the original photo is stored off-chain, the hash value and associated metadata recorded on the chain provide an immutable proof of the existence, relevance, and partial authenticity context of the photo. Subsequently, the smart contract can query the records on the chain to confirm whether the "fault diagnosis" node of the service record "SR789" has associated the photo hash and perform process control based on this. In case of disputes, the photo can be retrieved from the off-chain storage system through the hash value and metadata recorded on the chain, and the metadata can be used to assist in verifying the authenticity of the photo.

[0031] In some embodiments, when the service terminal enters the forced data association node, according to the corresponding node identifier, when controlling or prompting the service terminal to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier, the following is executed: A1. When the service terminal enters the forced data association node, the service terminal scans the QR code corresponding to the node identifier, parses to obtain the data collection instruction, and the data collection instruction includes the unstructured data type, quantity requirement, and metadata type; A2. Judge the unstructured data type according to the data collection instruction. If it is an image type, execute step A3; if it is an audio type, execute step A4; A3. Start the camera of the service terminal, forcibly turn on the flash, and prompt the operator to adjust the shooting angle. When the image clarity is greater than the preset threshold, take a specified number of images, and at the same time record the shooting timestamp, geographical location, terminal device identifier, and operator identifier as metadata; A4. Start the microphone of the service terminal, forcibly turn on the noise reduction mode, and prompt the operator to record an audio for a specified duration, and at the same time record the recording timestamp, geographical location, terminal device identifier, and operator identifier as metadata.

[0032] Specifically, for the mandatory data association nodes in the after-sales service process, such as the repair completion node, it is preset that this node needs to collect image evidence at the repair site. When a service terminal, such as a mobile device used by a repairman, enters this node, by scanning the QR code associated with this node, the service terminal obtains a data collection instruction. This instruction clearly requires the type of image to be collected, the quantity (e.g., 3 pieces), and the type of metadata to be recorded (service record ID, timestamp, location, device ID, operator ID). The service terminal determines that the data type is an image according to the instruction, then starts the camera application and forcibly turns on the flash to improve the lighting conditions. The system prompts the operator to adjust the shooting angle and monitors the image clarity in real time. Only when the image clarity reaches the preset numerical threshold (e.g., the variance of the image gradient calculated by the Laplacian operator is greater than a certain value) is shooting allowed. The system controls the shooting of the specified number of images, and each time a shooting is successful, it automatically records the current system time as the timestamp, obtains the geographical location through GPS or network positioning, reads the unique identifier of the terminal device, and the identifier of the currently logged-in operator. These metadata are associated with the collected images. If the instruction requires the collection of audio, such as for recording the communication content with the user, the system then starts the microphone application, forcibly turns on the noise reduction function, and prompts the operator to start recording, while setting a recording duration limit (e.g., 60 seconds). During or after the recording, the system automatically records the timestamp of the start or end of the recording, the geographical location, the identifier of the terminal device, and the identifier of the operator as metadata. Through the above controlled collection process, it is ensured that the unstructured data collected at key nodes meets the preset requirements and is associated with the necessary context information, solving the problem of uncontrollable data collection process or non-compliant collection results.

[0033] In some embodiments, the steps of uploading the unstructured data and specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system and generating a corresponding hash value as the unique identifier according to the unstructured data include: Segment the unstructured data collected by the service terminal to generate multiple data chunks; among them, the data chunking strategy includes fixed-size chunking, content-based chunking, or data-type-based chunking; Upload the multiple data chunks to the off-chain distributed file storage system in parallel. The off-chain distributed file storage system is an IPFS system. The IPFS system stores the data chunks in a content-addressable manner and generates a unique content identifier CID for each data chunk; According to the multiple content identifiers CIDs corresponding to the unstructured data, construct a Merkle tree. The leaf nodes of the Merkle tree are the respective content identifiers CIDs, the intermediate nodes are the hierarchical combined hash values of the leaf node hash values, and the root node is the final Merkle root hash value; Use the Merkle root hash value as the unique identifier for unstructured data for subsequent on-chain data verification.

[0034] This method first divides the collected unstructured data to generate multiple data chunks. The division strategy can select a fixed size, content-based, or data type-based according to the data characteristics. Data division breaks large data into small chunks for easy processing and distributed storage. Then, these data chunks are uploaded in parallel to an off-chain distributed file storage system, specifically the IPFS system. The IPFS system uses content addressing to generate a unique identifier (CID) based on the data content itself, ensuring that data with the same content has the same CID and supporting distributed storage and retrieval of data. Each data chunk will obtain a unique CID after being uploaded. Then, use the CIDs corresponding to these data chunks to construct a Merkle tree. A Merkle tree is a hash tree, where the leaf nodes are the CIDs of the data chunks and the non-leaf nodes are the combined hashes of the hashes of their child nodes. Finally, a unique Merkle root hash value is generated. Finally, use this Merkle root hash value as the unique identifier for the entire unstructured data. This root hash value can represent the integrity of all data chunks. If any data chunk is modified or lost, its CID will change, causing the hash values on the corresponding path in the Merkle tree to change, ultimately resulting in a change in the Merkle root hash value.

[0035] Specifically, this technical solution solves the problem of processing unstructured data and generating unique identifiers. When the content volume of unstructured data is large, directly calculating the overall hash value is inefficient and difficult to manage distributed storage. By splitting the unstructured data collected by the service terminal, multiple data chunks are generated, and data chunking strategies such as fixed-size chunking, content-based chunking, or data type-based chunking can be adopted. Thus, the large file is decomposed into small chunks that can be processed in parallel. The multiple data chunks are uploaded to the off-chain distributed file storage system in parallel. This system is the IPFS system. The IPFS system stores the data chunks using content addressing and generates a unique content identifier CID for each data chunk. Parallel uploading improves efficiency, and the content addressing of IPFS ensures the unique identification and distributed storage of data. According to the multiple content identifiers CID corresponding to the unstructured data, a Merkle tree is constructed. The leaf nodes of the Merkle tree are the respective content identifiers CID, the intermediate nodes are the gradually combined hash values of the leaf node hash values, and the root node is the final Merkle root hash value. The Merkle tree structure aggregates the CIDs of all data chunks into a single root hash value. The Merkle root hash value is used as the unique identifier of the unstructured data for subsequent on-chain data verification. Only this compact Merkle root hash value needs to be stored and verified on-chain, enabling efficient and reliable verification of the integrity of the entire unstructured data stored off-chain, thus solving the challenge of integrity verification of large-capacity unstructured data.

[0036] In some embodiments, the steps of combining the specified metadata and the corresponding unstructured data hash value into a structured data packet and submitting it as a piece of on-chain transaction data to a preset distributed ledger include: Calculating a transaction priority score based on the importance of the service record of the transaction to be submitted, the criticality of the data associated node, and the historical transaction congestion situation; Determining the Gas fee of the structured data packet according to the transaction priority score. If the transaction priority score is higher than a preset first threshold, it is set as a high Gas fee; if the transaction priority score is lower than a preset second threshold, it is set as a low Gas fee, and the transaction is selected to be submitted during an idle network period; Combining the specified metadata, the corresponding unstructured data hash value, and the Gas fee set in the previous step into a structured data packet, and signing the structured data packet to generate on-chain transaction data; Submitting the on-chain transaction data to the preset distributed ledger, and by monitoring the status of the transaction pool, real-time tracking the progress of transaction confirmation. If the transaction is not confirmed for a long time, the Gas fee is dynamically adjusted according to the current network congestion situation, and the transaction is resubmitted until the transaction is confirmed and recorded by the distributed ledger.

[0037] Specifically, this solution solves the problem of how to dynamically adjust the Gas fee of a transaction according to the urgency of service records and the congestion of the blockchain network by optimizing the process of submitting on-chain transactions. This ensures that critical service records are uploaded to the chain in a timely manner while reducing the overall transaction cost and improving the efficiency and availability of the system. First, the solution calculates a transaction priority score based on the priority of the service record of the transaction to be submitted, the priority of the data associated nodes, and the historical transaction network status. This scoring mechanism takes into account business requirements and network status, and differentiates the transaction processing order according to priority. Further, based on the calculated transaction priority score, the Gas fee of the transaction is determined. Transactions with a high priority are set with a higher Gas fee to increase the probability of the transaction being packaged and confirmed, and to shorten the transaction confirmation time. Transactions with a low priority are set with a lower Gas fee and submitted during periods of lower network load to reduce transaction fees. Thus, by leveraging the Gas mechanism of the blockchain network, the confirmation speed of transactions is affected by paying different fees. Then, the specified metadata, the hash value of the unstructured data, and the determined Gas fee are combined and signed to generate on-chain transaction data. This is the process of constructing a blockchain transaction. Finally, the generated on-chain transaction data is submitted to the distributed ledger. The solution further adds a mechanism to monitor the status of the transaction pool and track the progress of transaction confirmation. If the transaction confirmation time exceeds the preset duration, the system adjusts the Gas fee according to the current network load status and submits it again. This adjustment and resubmission mechanism enables the system to cope with network load fluctuations, adjust transaction parameters until the transaction is confirmed and recorded by the distributed ledger. Through these steps, the Gas fee of the transaction is dynamically adjusted according to the urgency of service records and the congestion of the blockchain network, thereby ensuring that critical service records are uploaded to the chain in a timely manner while reducing the overall transaction cost and improving the efficiency and availability of the system.

[0038] In some specific embodiments, for example, when a critical maintenance service related to product safety is completed and it is necessary to upload the on-site photos and the hash value of the maintenance report to the blockchain, the service record is marked as highly important, and the corresponding mandatory data association node is also marked as a critical node. The system calculates a relatively high transaction priority score based on this information and the congestion situation of the current blockchain network's transaction pool. According to this score, it is determined that a relatively high Gas fee should be used for this transaction. Subsequently, metadata such as the service record ID, photo hash value, and report hash value are combined with the determined high Gas fee, and chain - based transaction data is generated, signed, and submitted to the distributed ledger. The system continuously monitors the status of this transaction in the transaction pool. If it is found that the transaction has not been packaged and confirmed for a long time, the system will dynamically calculate and adjust the Gas fee according to the current real - time network congestion situation. For example, the Gas price is increased by a certain percentage, and then the transaction is resubmitted. In this way, it is ensured that the on - chain recording of critical service data can be completed in a timely manner, allowing the service process to smoothly progress to the next stage. At the same time, through the priority scoring and dynamic adjustment mechanism, unnecessary Gas expenditures are avoided, and resource utilization is optimized.

[0039] In certain embodiments, the step of combining the specified metadata and the hash value of the corresponding unstructured data into a structured data packet as associated information and submitting it as a piece of chain - based transaction data to a preset distributed ledger includes: Obtain a preset cross - chain interoperability protocol, which defines the data transmission standards, verification mechanisms, and Gas fee settlement methods for the source chain and the target chain; According to the service record ID, query the specified metadata and the hash value of the corresponding unstructured data on the source chain, and encapsulate the specified metadata and the corresponding hash value into a cross - chain transaction request according to the data format specified by the cross - chain interoperability protocol; Send the cross - chain transaction request to a preset cross - chain bridging node, and verify the legality of the cross - chain transaction request through the cross - chain bridging node, including signature verification, data format verification, and Gas fee verification; If the verification passes, the cross - chain bridging node forwards the cross - chain transaction request to the target chain. The smart contract on the target chain parses the cross - chain transaction request according to the cross - chain interoperability protocol and writes the specified metadata and the corresponding hash value into the target chain to complete cross - chain data synchronization.

[0040] The acquisition of the cross-chain interoperability protocol can be obtained through configuration or registration. This protocol defines a set of rules for data exchange and verification between different distributed ledgers. Querying the source chain data according to the service record ID can be achieved by calling the smart contract interface deployed on the source chain. This interface retrieves the metadata and hash values stored on the chain based on the provided service record ID. Encapsulating the queried data into a cross-chain transaction request requires following the data structure and encoding method defined by the protocol to ensure that the target chain can correctly parse it. After receiving the request, the cross-chain bridging node executes a series of verification logics, including checking whether the digital signature of the request initiator is valid, whether the data format carried by the request conforms to the protocol specification, and whether the Gas fee required for the transaction has been correctly paid or reserved. After passing the verification, the bridging node is responsible for securely delivering the request to the target chain network. The smart contract on the target chain is designed to receive and process requests from the cross-chain bridging node. It parses the request content according to the cross-chain interoperability protocol, extracts the service record ID, metadata, and hash values, and records this information as a new transaction or state update in the state database of the target chain.

[0041] Specifically, this technical solution addresses the issue of how to achieve cross-chain sharing and consistency of key after-sales service data in the presence of multiple heterogeneous distributed ledgers. First, by obtaining and following a unified cross-chain interoperability protocol, a basic standard for data communication between different chains is established. When it is necessary to synchronize or share specific service record data on the source chain to the target chain, the system accurately locates and extracts the specified metadata and the hash value of the unstructured data related to the record on the source chain according to the unique ID of the service record. These data are the key information of the service process, and the hash value represents the integrity of the off-chain unstructured data. Then, the extracted data are encapsulated in a specific format stipulated by the cross-chain interoperability protocol to form a standard cross-chain transaction request packet. This request packet contains the data to be transmitted as well as the necessary routing and verification information. Subsequently, this cross-chain transaction request is sent to one or a group of preset cross-chain bridging nodes. These bridging nodes act as trust intermediaries connecting the source chain and the target chain. After receiving the request, they will strictly check the legality of the request according to the protocol to ensure the authenticity and integrity of the request and prevent malicious or incorrect data transmission. After passing the verification, the bridging nodes forward the request to the target chain network. On the target chain, a pre-deployed smart contract is responsible for receiving and processing the request from the bridging nodes. The smart contract parses the request content according to the cross-chain interoperability protocol, extracts the service record ID, metadata, and hash value, and writes this information as a new data record or an update to the existing record into the ledger of the target chain. Thus, the key service data on the source chain are safely and credibly synchronized to the target chain, achieving cross-chain sharing and consistency of data, enabling applications or participants on different chains to access and utilize these data, and improving the data interoperability and usability of the entire after-sales service quality monitoring system.

[0042] In some specific embodiments, assume that the source chain is a consortium chain based on Ethereum, and the target chain is a permissioned chain based on Hyperledger Fabric. The cross-chain interoperability protocol can adopt a mechanism based on message relay and verification. For example, a standard data packet structure is defined, which includes a service record ID, metadata, a hash value, a source chain identifier, a timestamp, and a signature of the source chain smart contract. The cross-chain bridging nodes can be a cluster of servers running a specific relay service, which listen for cross-chain events emitted by a specific smart contract on the source chain. When the smart contract on the source chain records new service data and triggers a cross-chain event, the relay service captures the event, queries the detailed data from the source chain, and constructs a cross-chain transaction request according to the protocol format. The request is sent to the bridging nodes. After receiving the request, the bridging nodes first verify the validity of the signature of the source chain smart contract to confirm that the data indeed comes from a trusted contract on the source chain. Then, they check whether the format of the data packet conforms to the protocol definition. After passing the verification, the bridging nodes forward the request to a specific smart contract in the target chain network. After receiving the request, the smart contract on the target chain parses the data packet, extracts the service record ID, metadata, and hash value, and writes them as a new record into the state database of the Fabric ledger. For example, using the service record ID as the key and the metadata and hash value as the value. In this way, the key after-sales service data on the source chain is synchronized to the target chain, enabling applications on the target chain to also access this data for subsequent processing or analysis, such as performing cross-regional service data aggregation or auditing.

[0043] In certain embodiments, the steps of real-time monitoring the update of the service record status and, when the service record status attempts to advance from the current forced data association node to the next forced data association node, using a smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status and verifying the hash value record of the unstructured data associated with the current forced data association node include: B1. When the service record status attempts to advance from the current forced data association node to the next node, the smart contract queries the on-chain data associated with the ID identifier of the current service record status. If the query result is empty, step B2 is executed; if the query result is non-empty, step B3 is executed; B2. The smart contract suspends the advancement of the service record status and sends a data supplementation instruction to the service terminal. The data supplementation instruction includes the node identifier of the current forced data association node, the unstructured data type, the quantity requirement, and the metadata type. At the same time, a timer is started to record the supplementation waiting time; The smart contract extracts the hash value record of the unstructured data associated with the currently mandatory data association node in the on-chain data, and retrieves the hash value corresponding to the ID identifier of the current service record status from the off-chain distributed file storage system. If the hash value of the off-chain record is consistent with that of the on-chain record, step B31 is executed; if the hash value of the off-chain record is inconsistent with that of the on-chain record, step B32 is executed; B31. The smart contract allows the service status to advance to the next node, and records the advancement time and the operator identifier; B32. The smart contract prevents the service status from advancing, marks the service record status as an abnormal status, and generates an exception report. The exception report includes the service record ID, the abnormal node identifier, the abnormal type (hash value mismatch), the occurrence time, and the operator identifier, and sends the exception report to the preset administrator account; B4. The smart contract monitors the supplementary recording waiting time. If the supplementary recording waiting time exceeds the preset threshold, step B32 is executed. If the data re-uploaded by the service terminal is received within the preset threshold, step B3 is executed.

[0044] Specifically, when the service record status attempts to advance from the current forced data association node to the next node, the data integrity verification process is triggered by a smart contract deployed on the distributed ledger, addressing potential issues of tampering or missing key unstructured data during the service process. The smart contract first queries the distributed ledger based on the unique ID of the service record to check whether the current forced data association node has recorded the associated information as required, including the hash value of the unstructured data. If the corresponding record is not found on the chain, indicating that there may be a problem with the data upload link at this node, the smart contract will suspend the automatic advancement of the service process and send a clear data re-entry instruction to the service terminal, prompting the operator to re-collect and upload the required data. At the same time, a timer is started to limit the completion time of the re-entry operation. If the data re-entry and upload are completed within the specified time, the process will continue with the verification. If the corresponding record exists on the chain, the smart contract will extract the recorded hash value of the unstructured data and compare it with the hash value calculated from the actual unstructured data retrieved from the off-chain distributed file storage system. This comparison is the core integrity verification step. If the two hash values are consistent, proving that the unstructured data stored off-chain has not been tampered with since it was uploaded and the hash value was recorded on the chain, the smart contract allows the service record status to advance smoothly to the next node and records the relevant advancement information. If the two hash values are inconsistent, or no valid data is received after the re-entry waiting time exceeds the preset threshold, it indicates that the data may have been tampered with or failed to be uploaded in a timely manner. The smart contract will block the advancement of the service status, mark the service record as an abnormal status, and automatically generate a report containing detailed abnormal information and send it to the administrator for handling. Thus, by forcing on-chain and off-chain data consistency verification at key nodes, this solution ensures the authenticity and integrity of key unstructured data in the service process, prevents the advancement of the process based on untrue data, improves the credibility of after-sales service quality monitoring, and provides an automated processing and traceability mechanism for abnormal situations.

[0045] In some specific embodiments, assume that a service process includes two mandatory data association nodes: "on-site detection" and "troubleshooting". When the service personnel complete the "on-site detection" and attempt to advance the service status to the "troubleshooting" node at the service terminal, the system triggers the execution of a smart contract for verification. The smart contract first queries the data on the chain using the service record ID to find the record associated with the "on-site detection" node. If the query result is empty, the smart contract pauses the status advancement, sends a supplementary recording instruction to the service terminal, requests the upload of on-site detection photos and relevant metadata, and starts a timer, for example, a 5-minute timer. After the service personnel upload the data within 5 minutes, the process enters the verification. If the query result on the chain is not empty, the smart contract extracts the hash value of the on-site detection photo in the chain record, obtains the corresponding photo data from the off-chain storage system, and calculates its hash value. The smart contract compares the hash value on the chain with the hash value calculated off-chain. If they are consistent, the smart contract allows the service status to advance to the "troubleshooting" node and records the advancement time. If they are inconsistent, or the supplementary recording timer times out, the smart contract blocks the status advancement, marks the service record as abnormal, generates an exception report, including the service record ID, the node "on-site detection", the exception type "hash value mismatch" or "supplementary recording timeout", the occurrence time, the operator ID, and sends the report to the administrator account.

[0046] Reference appendix Figure 2 , the present invention provides a real-time monitoring system for after-sales service quality based on blockchain, including: An acquisition module 100, configured to acquire the node identifier of a preset mandatory data association node in the service process, and the corresponding upload requirements, where the upload requirements include the specified unstructured data type and the upload quantity; A collection module 200, configured to, when the service terminal enters a mandatory data association node, control or prompt the service terminal to perform data collection for unstructured data and specified metadata according to the corresponding node identifier and the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier; A generation module 300, configured to upload the unstructured data and the specified metadata collected by the service terminal to a pre-established off-chain distributed file storage system, and generate a corresponding hash value as a unique identifier according to the unstructured data; A transaction module 400, configured to combine the specified metadata and the corresponding unstructured data hash value into a structured data packet, and submit it as a piece of on-chain transaction data to a preset distributed ledger; The verification module 500 is used to monitor the update of the service record status in real time. When the service record status attempts to advance from the current forced data association node to the next forced data association node, it queries the corresponding on-chain data through the ID identifier of the current service record status by using the smart contract deployed on the distributed ledger, and verifies the unstructured data hash value record associated with the current forced data association node. If the verification passes, the service status is allowed to advance; if the verification fails, the service status advancement is blocked, and the service record status is marked as an abnormal status.

[0047] In this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0048] The above are only the embodiments of the present invention and are not used to limit the protection scope of the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A real-time monitoring method for after-sales service quality based on blockchain, characterized in that, Including the following steps: Obtain the node identifier of the preset forced data association node in the service process, and the upload requirements corresponding to the node identifier. The upload requirements include the specified unstructured data type and the upload quantity; When the service terminal enters the forced data association node, according to the corresponding node identifier, control or prompt the service terminal to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier; the specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier; Upload the unstructured data and specified metadata collected by the service terminal to the pre-established off-chain distributed file storage system, and generate a corresponding hash value for the unstructured data as the unique identifier; Combine the specified metadata and the corresponding unstructured data hash value into a structured data packet, and submit it as a piece of on-chain transaction data to the preset distributed ledger; Monitor the update of the service record status in real time, and when the service record status attempts to advance from the current forced data association node to the next forced data association node, use the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verify the unstructured data hash value record associated with the current forced data association node; If the verification passes, allow the service status to advance; if the verification fails, block the service status from advancing and mark the service record status as an abnormal status.

2. The real-time monitoring method for after-sales service quality based on blockchain according to claim 1, wherein, When the service terminal enters the forced data association node, according to the corresponding node identifier, when controlling or prompting the service terminal to perform data collection for unstructured data and specified metadata according to the upload requirements corresponding to the node identifier, execute: A1. When the service terminal enters the forced data association node, the service terminal scans the QR code corresponding to the node identifier and parses to obtain the data collection instruction. The data collection instruction includes the unstructured data type, the quantity requirement, and the metadata type; A2. Judge the unstructured data type according to the data collection instruction. If it is an image type, execute step A3; if it is an audio type, execute step A4; A3. Start the camera of the service terminal, force the flash to turn on, and prompt the operator to adjust the shooting angle. When the image clarity is greater than the preset threshold, take the specified number of images, and at the same time record the shooting timestamp, geographical location, terminal device identifier, and operator identifier as metadata; A4. Start the microphone of the service terminal, force the noise reduction mode to turn on, and prompt the operator to record the audio for the specified duration. At the same time, record the recording timestamp, geographical location, terminal device identifier, and operator identifier as metadata.

3. The real-time monitoring method for after-sales service quality based on blockchain according to claim 1, characterized in that, The steps of uploading the unstructured data and specified metadata collected by the service terminal to the pre-established off-chain distributed file storage system and generating a corresponding hash value for the unstructured data as the unique identifier include: Split the unstructured data collected by the service terminal to generate multiple data chunks; Parallel upload multiple data chunks to an off-chain distributed file storage system, where the off-chain distributed file storage system is an IPFS system. The IPFS system stores data chunks using content addressing and generates a unique content identifier CID for each data chunk. Construct a Merkle tree based on the multiple content identifiers CIDs corresponding to the unstructured data. The leaf nodes of the Merkle tree are the respective content identifiers CIDs, the intermediate nodes are the gradually merged hash values of the leaf node hash values, and the root node is the final Merkle root hash value. Use the Merkle root hash value as the unique identifier for the unstructured data for subsequent on-chain data verification.

4. The real-time monitoring method for after-sales service quality based on blockchain according to claim 3, characterized in that, The steps of splitting the unstructured data collected by the service terminal to generate multiple data chunks include: Adopt a data chunking strategy such as fixed-size chunking, content-based chunking, or data type-based chunking to split the unstructured data collected by the service terminal to generate multiple data chunks.

5. The real-time monitoring method for after-sales service quality based on blockchain according to claim 1, characterized in that The steps of combining the specified metadata and the corresponding unstructured data hash value into a structured data packet and submitting it as an on-chain transaction data to a preset distributed ledger include: Calculate a transaction priority score based on the importance of the service record of the transaction to be submitted, the criticality of the data associated node, and the historical transaction congestion situation. Determine the Gas fee for the structured data packet according to the transaction priority score. If the transaction priority score is higher than a preset first threshold, set it as a high Gas fee; if the transaction priority score is lower than a preset second threshold, set it as a low Gas fee and choose to submit the transaction during an idle network period. Combine the specified metadata, the corresponding unstructured data hash value, and the Gas fee set in the previous step into a structured data packet, and sign the structured data packet to generate on-chain transaction data. Submit the on-chain transaction data to a preset distributed ledger, and by monitoring the status of the transaction pool, track the transaction confirmation progress in real time. If the transaction is not confirmed for a long time, dynamically adjust the Gas fee according to the current network congestion situation and resubmit the transaction until the transaction is confirmed and recorded by the distributed ledger.

6. The real-time monitoring method for after-sales service quality based on blockchain according to claim 1, wherein The steps of combining the specified metadata and the corresponding unstructured data hash value into a structured data packet and submitting it as an on-chain transaction data to a preset distributed ledger include: Obtain a preset cross-chain interoperability protocol. Query the specified metadata and the corresponding unstructured data hash value on the source chain according to the service record ID, and encapsulate the specified metadata and the corresponding hash value into a cross-chain transaction request in the data format specified by the cross-chain interoperability protocol. Send the cross-chain transaction request to a preset cross-chain bridging node, and verify the legality of the cross-chain transaction request through the cross-chain bridging node, including signature verification, data format verification, and Gas fee verification. If the verification passes, the cross-chain bridging node forwards the cross-chain transaction request to the target chain. The smart contract on the target chain parses the cross-chain transaction request according to the cross-chain interoperability protocol and writes the specified metadata and the corresponding hash value to the target chain to complete cross-chain data synchronization.

7. The real-time monitoring method for after-sales service quality based on blockchain according to claim 1, wherein The real-time monitoring service records the update of the status, and when the service record status attempts to advance from the current forced data association node to the next forced data association node, the steps of using the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status and verifying the hash value record of the unstructured data associated with the current forced data association node include: B1. When the service record status attempts to advance from the current forced data association node to the next node, the smart contract queries the on-chain data associated with the ID identifier of the current service record status. If the query result is empty, step B2 is executed; if the query result is not empty, step B3 is executed; B2. The smart contract pauses the advancement of the service record status and sends a data supplementation instruction to the service terminal. The data supplementation instruction includes the node identifier of the current forced data association node, the unstructured data type, the quantity requirement, and the metadata type. At the same time, a timer is started to record the supplementation waiting time; B3. The smart contract extracts the hash value record of the unstructured data associated with the current forced data association node from the on-chain data and retrieves the hash value corresponding to the ID identifier of the current service record status from the off-chain distributed file storage system. If the hash value of the off-chain record is consistent with the on-chain record, step B31 is executed; if the hash value of the off-chain record is inconsistent with the on-chain record, step B32 is executed; B31. The smart contract allows the service status to advance to the next node and records the advancement time and the operator identifier; B32. The smart contract blocks the advancement of the service status, marks the service record status as an abnormal status, generates an exception report at the same time, and sends the exception report to a preset administrator account.

8. The real-time monitoring method for after-sales service quality based on blockchain according to claim 7, characterized in that, After step B2, the following steps are also included: B4. The smart contract monitors the supplementation waiting time. If the supplementation waiting time exceeds the preset threshold, step B32 is executed. If the data re-uploaded by the service terminal is received within the preset threshold, step B3 is executed.

9. The real-time monitoring method for after-sales service quality based on blockchain according to claim 7, characterized in that The exception report includes the service record ID, the abnormal node identifier, the abnormal type, the occurrence time, and the operator identifier.

10. A real-time monitoring system for after-sales service quality based on blockchain, characterized in that Including: An acquisition module for acquiring the node identifier of the preset forced data association node in the service process and the corresponding upload requirements for the node identifier. The upload requirements include the specified unstructured data type and the upload quantity; A collection module for controlling or prompting the service terminal to perform data collection for unstructured data and specified metadata according to the corresponding node identifier when the service terminal enters the forced data association node. The specified metadata includes the ID identifier of the current service record status, the collection timestamp, the geographical location, the terminal device identifier, and the operator identifier; A generation module for uploading the unstructured data and the specified metadata collected by the service terminal to the pre-established off-chain distributed file storage system and generating a corresponding hash value as the unique identifier according to the unstructured data; A transaction module for combining the specified metadata and the corresponding unstructured data hash value as association information into a structured data packet and submitting it as a piece of on-chain transaction data to the preset distributed ledger; The verification module is used to monitor the update of the service record status in real time. When the service record status attempts to advance from the current forced data association node to the next forced data association node, it uses the smart contract deployed on the distributed ledger to query the corresponding on-chain data through the ID identifier of the current service record status, and verifies the unstructured data hash value record associated with the current forced data association node; If the verification passes, the service status is allowed to advance; if the verification fails, the service status advancement is blocked, and the service record status is marked as an abnormal state.

Images