A file fingerprint checking and tracing method and system for scientific research instrument data

Abstract

This invention provides a method and system for verifying and tracing file fingerprints for scientific instrument data, comprising: Step S1, acquiring user identity information and instrument identifier of the scientific instrument, identifying the original data file through file monitoring and automatically collecting basic metadata to generate labeled metadata; Step S2, calculating the file fingerprint based on the algorithm identifier using a digest algorithm and writing it into a fingerprint database; Step S3, performing fingerprint comparison on the file fingerprints; if the fingerprints are the same, reusing the existing content object identifier and adding a new version record; if they are different, creating a new content object identifier and adding a new version record; and when the same reservation identifier, upload time difference not exceeding a preset threshold, and fingerprint inconsistency are met, creating a version fork and recording the fork reason code and fork reason payload for traceability; Step S4, performing verification processing on the downloaded file. The beneficial effect is that this invention can meet the comprehensive requirements of traceability, auditability, and real-time performance for the security management of scientific instrument data.

Description

Technical Field

[0001] This invention relates to the technical field of scientific research data management, and more specifically, to a method and system for document fingerprint verification and traceability of scientific instrument data. Background Technology

[0002] Scientific instruments continuously generate raw test data files during experiments. This data is characterized by high scientific value, high reproduction costs, complex ownership relationships, and frequent sharing and transfer across teams. With the construction and promotion of large-scale scientific instrument sharing management platforms, centralized storage and online download of scientific data have become the norm.

[0003] However, existing scientific research data management systems still have the following technical problems in practical applications: The data generation end lacks an effective mechanism for binding and identifying users, research instruments, and sessions. Existing solutions mostly focus on storage management and access control after data is uploaded to the server, lacking automated context collection methods at the source of data generation—the computer connected to the research instrument. This makes it difficult to establish a stable association between the original data file and the user's identity, the affiliated research instrument, and the scheduled experimental task. Once the data enters subsequent circulation stages, its initial ownership and responsibility boundaries become unclear, resulting in insufficient source traceability.

[0004] The lack of a closed-loop comparison between the upload and download ends in integrity verification leads to a significant delay in tamper detection. Existing solutions typically calculate and record integrity check values ​​when data is stored in the storage system, but in the subsequent download stage, they rely solely on the basic verification mechanism of the transport layer protocol, without recalculating the content fingerprint of the downloaded file and actively comparing it with the original registered fingerprint. This means that even if data is tampered with or replaced on the server side, the downloader cannot immediately perceive the substantial changes to the file content, resulting in a prolonged period of data security issues remaining hidden and making it difficult to trigger immediate action.

[0005] The lack of structured fork recording and tracing mechanisms addresses file version changes caused by human intervention within the same experimental session. In research practice, original data files under the same scheduled experimental task may generate multiple versions due to operator annotations, changes in project attribution, or re-uploads. Existing systems typically only record these changes by simply overwriting or superimposing linear version numbers, lacking the ability to identify and record the causes of forks in the specific scenario of "dissenting changes within the same experimental context." This makes it impossible to accurately reconstruct the data change path and motivations during subsequent audits, weakening the compliance and interpretability of research data management.

[0006] The handling methods for download anomalies are simplistic, lacking risk grading and a closed-loop accountability system. When download verification detects anomalies, existing systems often limit their responses to simple prompts or log entries, failing to establish standardized, coordinated actions (such as notifying the responsible party, isolating suspicious files, and triggering administrator alerts) based on the anomaly's risk level. This results in a lack of standardized procedures for security incident response, relying heavily on manual experience and making it prone to improper handling or disruptions in the accountability chain, thus failing to create a closed-loop management system from anomaly identification to responsibility tracing.

[0007] In summary, existing technologies struggle to construct a shortest closed loop for consistency verification and anomaly tracing, driven by file fingerprints, covering the entire data generation, uploading, storage, and downloading process in scientific instrument data transfer scenarios. Therefore, there is an urgent need for a solution that can establish a trusted association at the data generation end, achieve interactive integrity verification at both the uploading and downloading ends, structurally record version discrepancies, and implement tiered handling of download anomalies. This solution aims to meet the comprehensive requirements of traceability, auditability, and real-time performance for scientific instrument data security management. Summary of the Invention

[0008] The technical problem this invention aims to solve is how to meet the comprehensive requirements of traceability, auditability, and real-time performance for the security management of scientific instrument data. To overcome the deficiencies of the existing technology (or related technology), this invention provides a document fingerprint verification and traceability method and system for scientific instrument data.

[0009] This invention provides a method for document fingerprint verification and traceability of scientific instrument data, comprising the following steps: Step S1: Deploy a controller on the computer connected to the scientific instrument to obtain the user identity information and instrument identifier of the scientific instrument, identify the original data file through file listening and automatically collect basic metadata and receive manually supplemented annotation information, and generate annotation metadata bound to the original data file. Step S2: Upon receiving an upload request, select a digest algorithm based on the algorithm identifier to calculate the file fingerprint, and associate the file fingerprint, the algorithm identifier, and the annotation metadata into the fingerprint database; Step S3: Perform fingerprint comparison on the file fingerprint based on the fingerprint database. If the fingerprints are the same, reuse the existing content object identifier and add a new version record. If they are different, create a new content object identifier and add a new version record. When the same reservation identifier, upload time difference is not greater than a preset threshold and fingerprints are inconsistent, create a version fork and record the fork reason code and fork reason payload for traceability. Step S4: After receiving the download request, calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database. If the fingerprints do not match, perform the corresponding processing according to the preset abnormal registration rules.

[0010] The document fingerprint verification and traceability method for scientific instrument data of this invention has the following advantages compared with the prior art: This invention constructs a closed-loop process covering scientific instrument data acquisition, fingerprint upload, version fork tracing, and download verification and handling through steps S1 to S4. By binding the relationship between users, scientific instruments, and files at the data generation end through a controller, it solves the problem of missing source association in existing technologies. Fingerprint comparison at both the upload and download ends achieves a closed-loop integrity verification, significantly improving the perceptibility of data tampering. The version fork mechanism, constrained by reservation identifiers and preset time thresholds, can accurately record and trace file changes caused by human modification within the same experimental session, providing clear evidence for subsequent audits. Furthermore, the implementation of tiered handling through preset anomaly registration rules ensures that abnormal events trigger standardized control actions according to risk level, avoiding arbitrariness in human judgment. Overall, this significantly enhances the security, compliance, and accountability of scientific instrument data flow.

[0011] In one possible implementation, step S1, identifying the original data file through file monitoring, includes: The controller continuously monitors the data output directory pre-agreed with the scientific instrument, and the response ends when a file creation completion event or a file write close event is detected. The file creation completion event or file write close event is then identified as the original data file generated in this experiment.

[0012] Compared with existing technologies, the above technical solution enables the controller to capture file creation completion events or file write closing events by continuously listening to the pre-agreed data output directory, and uses this as the basis for identifying the original data file. This limitation ensures the real-time and completeness of file acquisition, and avoids misreading or omission due to the file being written. It is especially suitable for scenarios where scientific instruments continuously output large original data files, making information capture at the data generation end more reliable and more automated, and providing accurate triggering opportunities for subsequent annotation metadata binding and fingerprint calculation.

[0013] In one possible implementation, in step S3, the application programming interface of the large-scale scientific instrument sharing management platform is called to obtain the reservation task identifier bound to the current user login session as the reservation identifier; or if the reservation task identifier is not obtained, a temporary reservation identifier is generated based on the user identity information, the instrument identifier and the current session start timestamp as the reservation identifier.

[0014] Compared with existing technologies, the above-mentioned technical solution can provide two flexible ways to obtain reservation identifiers. It prioritizes obtaining formal reservation task identifiers from the scientific instrument sharing management platform to maintain data consistency with external management systems. When offline or not connected to the scientific instrument sharing management platform, a temporary reservation identifier is generated based on user identity information, instrument identifier, and current session start timestamp. This solution ensures that even in complex scientific research environments with network isolation or imperfect platform integration, the binding relationship of reservation identifiers remains stable, the traceability of data flow is not interrupted, and the applicability under various actual deployment conditions is enhanced.

[0015] In one possible implementation, the fork cause encoding in step S3 includes at least a first encoding value representing a change in the uploader's identity, a second encoding value representing a change in tag information, and a third encoding value representing a change in project information.

[0016] Compared with existing technologies, the above technical solution can encode the fork cause as an enumeration type field, covering at least three typical scenarios: uploader change, tag change, and project information change. This allows the cause of version fork to be recorded in a standardized, machine-readable form, which facilitates subsequent statistical analysis, automatic report generation, and the execution of differentiated audit strategies according to the fork type, greatly improving the structuring degree and application efficiency of the traceability process.

[0017] In one possible implementation, the fork cause payload in step S3 includes structured data such as the change field name, the value before the change, the value after the change, the operator identifier, and the change timestamp.

[0018] Compared with existing technologies, the above technical solution can specifically define the structure of the bifurcation cause load, requiring the recording of changed field names, comparison of old and new values, operator and timestamp. This makes the traceability no longer limited to the conclusion that a change has occurred, but can accurately restore "who, when, and what information was changed from what value to what value", providing a complete audit trail and interpretability for the version evolution of scientific instrument data, and meeting the stringent requirements for the granularity of data change records in scientific research integrity and compliance supervision.

[0019] In one possible implementation, the preset threshold in step S3 is determined according to the instrument type of the scientific instrument. A low threshold is configured for scientific instruments with short data generation cycles, and a high threshold is configured for scientific instruments with long data generation cycles. The range of the preset threshold is 5 minutes to 30 minutes.

[0020] Compared with existing technologies, the above-mentioned technical solution can set the preset threshold to be configurable within 5 to 30 minutes according to the instrument type, which solves the problem of huge differences in the data generation rhythm of different scientific research instruments. For high-frequency sampling rapid imaging equipment, the low threshold can sensitively distinguish multiple adjustments within a single experiment; for slow-process instruments that continuously collect data for a long time, the high threshold can accommodate reasonable delays caused by instrument stabilization time or mid-process pauses. This adaptive configuration mechanism effectively balances the sensitivity and accuracy of version forks, avoids misjudgment or omissions, and improves the engineering practicality of the solution.

[0021] In one possible implementation, the preset anomaly level rule in step S4 determines the anomaly level based on a logical combination of at least two of the following conditions: whether the downloader and the owner belong to the same project group, whether the download time is within a preset high-risk period, whether the downloaded file carries a highly sensitive tag, and whether the cumulative number of fingerprint verification failures of the downloader within a preset backtracking period exceeds the upper limit.

[0022] Compared with existing technologies, the above-mentioned technical solution can dynamically determine the anomaly level by combining multiple risk dimensions. The preset anomaly level rule significantly surpasses the threshold judgment of traditional single conditions, and constructs a multi-dimensional risk assessment model. This enables the system to apply differentiated control to low-risk internal collaborative downloads and high-risk external anomaly period downloads, ensuring the data security of scientific instruments while reducing unnecessary interference with normal scientific research collaboration, and achieving a balance between security and ease of use.

[0023] In one possible implementation, after performing step S4, the method further includes: When the downloaded fingerprint does not match the registered fingerprint in the fingerprint database and the preset deep review trigger condition is met, the block fingerprint baseline pre-generated and stored for the original data file during the upload stage is obtained. The downloaded file is calculated according to the same block segmentation strategy to obtain the downloaded block fingerprint sequence. The downloaded block fingerprint sequence is compared with the block fingerprint baseline block by block to locate the block offset position of the data anomaly. The position information of the block offset position is written into the audit record and notification message.

[0024] Compared with existing technologies, the above technical solution can further introduce a deep verification mechanism based on block fingerprints after discovering that the downloaded fingerprint is inconsistent with the registered fingerprint, and locate the specific block offset position. This design provides precise positioning capability, which can distinguish between occasional network transmission errors and malicious tampering targeting specific data areas. The block offset position is written into the audit log and administrator notification message, which greatly improves the efficiency of fault diagnosis and evidence collection, and makes up for the deficiency that the underlying cause cannot be verified when relying solely on global fingerprint verification.

[0025] In one possible implementation, the algorithm identifier in step S2 is used to indicate that the selected digest algorithm is the SM3 algorithm, the SHA-256 algorithm, or the BLAKE3 algorithm, and the algorithm identifier is stored together with the file fingerprint.

[0026] Compared with existing technologies, the above technical solution can ensure the system's adaptability to different security requirements, performance requirements and compliance standards, while preventing compatibility issues caused by changes in digest algorithms that make historical fingerprints unverifiable, thus ensuring the long-term availability and algorithm evolvability of the data verification system.

[0027] This invention provides a document fingerprint verification and traceability system for scientific instrument data, which applies the above-mentioned document fingerprint verification and traceability method and includes: The controller, deployed on the computer connected to the scientific instrument, is used to acquire the user identity information, instrument identification and reservation identification of the scientific instrument, and to identify the original data file through file listening. The metadata annotation module, connected to the controller, is used to collect basic metadata and receive manually supplemented annotation information, and generate annotation metadata bound to the original data file; The fingerprint entry module, connected to the metadata annotation module, is used to select a digest algorithm based on the algorithm identifier to calculate the file fingerprint when an upload request is received, and associate the file fingerprint, the algorithm identifier and the annotation metadata into the fingerprint database; The fingerprint comparison module is connected to the fingerprint database module and is used to perform fingerprint comparison on the file fingerprint based on the fingerprint database. If the fingerprints are the same, the existing content object identifier is reused and a new version record is added. If they are different, a new content object identifier is created and a new version record is added. When the same reservation identifier, the upload time difference is not greater than a preset threshold and the fingerprints are inconsistent, a version fork is created and the fork reason code and fork reason payload are recorded for traceability. The download verification module, connected to the fingerprint entry module, is used to calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database when a download request is received. If the fingerprint does not match, the corresponding handling is performed according to the preset abnormal registration rules.

[0028] Compared with existing technologies, the document fingerprint verification and traceability system for scientific instrument data of this invention has the following advantages: In this invention, each module has a clear responsibility and a well-defined collaborative relationship. The controller is responsible for collecting raw data files, the metadata annotation module is responsible for generating and annotating metadata, the fingerprint database module is responsible for generating and storing file fingerprints, the fingerprint comparison module is responsible for version management and fork logic, and the download verification module is responsible for verifying downloaded files. This modular design makes the system easy to deploy and integrate in different scientific research instrument computing environments. Each functional component can be upgraded and maintained independently, and it has good scalability and engineering feasibility. It can directly transform the innovative processes defined in the method into runnable software entities. Attached Figure Description

[0029] Figure 1 This is a flowchart of the method steps of the present invention; Figure 2 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0030] First, those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make adjustments as needed to adapt to specific application scenarios.

[0031] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0032] See Figure 1 This invention discloses a method for verifying and tracing file fingerprints for scientific instrument data, comprising the following steps: Step S1: Deploy a controller on the computer connected to the scientific instrument to obtain the user identity information and instrument identification of the scientific instrument. Identify the original data file through file listening and automatically collect basic metadata as well as receive manually supplemented annotation information to generate annotation metadata bound to the original data file. Step S2: Upon receiving an upload request, select a digest algorithm based on the algorithm identifier to calculate the file fingerprint, and associate the file fingerprint, algorithm identifier, and annotation metadata into the fingerprint database. Step S3: Perform fingerprint comparison on file fingerprints based on fingerprint database. If the fingerprints are the same, reuse the existing content object identifier and add a new version record. If they are different, create a new content object identifier and add a new version record. When the same reservation identifier, upload time difference is not greater than the preset threshold and fingerprints are inconsistent, create a version fork and record the fork reason code and fork reason payload for traceability. Step S4: After receiving the download request, calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database. If the fingerprints do not match, perform the corresponding processing according to the preset abnormal registration rules.

[0033] In this embodiment of the invention, in step S1, the controller can run on the data acquisition workstation connected to the scientific instrument as a system service or a background daemon. After the user completes identity authentication through the login interface provided by the controller, the controller extracts the user ID from the authentication session and reads the preset instrument number from the local configuration file. The controller continuously monitors the pre-agreed data output directory by calling the file system monitoring interface provided by the operating system (such as the inotify mechanism under Linux or the ReadDirectoryChangesW API under Windows). This data output directory is usually the default data storage path of the software supporting the scientific instrument. When a file creation completion event or a file write closing event is detected, the controller identifies the file creation completion event or file write closing event as the original data file generated in this experiment. Subsequently, it automatically collects basic metadata from the system environment and the current session context, including the user name, file observation time, instrument identifier, and reservation information corresponding to the current session, and pops up a labeling interface for the user to receive manually supplemented labeling information and project attribution information. Finally, the automatically collected basic metadata and the manually supplemented labeling information are merged to generate labeling metadata bound to the original data file.

[0034] In this embodiment of the invention, in step S2, the upload request can be actively triggered by the user in the controller interface, or it can be configured to be automatically initiated after the original data file is identified. When the upload request is received, the algorithm identifier preset in the system configuration is read first to determine the digest algorithm to be used. The algorithm identifier is used to indicate that the selected digest algorithm is the SM3 cryptographic hash algorithm, the SHA-256 secure hash algorithm, or the BLAKE3 hash algorithm. Among them, the SM3 cryptographic hash algorithm can be used to meet the compliance requirements of domestic cryptography, the SHA-256 secure hash algorithm has wide applicability, and the BLAKE3 hash algorithm is suitable for the high-speed hash calculation requirements in large data volume scenarios. After selecting the digest algorithm, all bytes of the original data file are read, and the corresponding hash value is calculated by the selected digest algorithm as the file fingerprint. Then, the file fingerprint, the algorithm identifier, and the annotation metadata generated in step S1 are combined into a record, and the record is persistently saved to the fingerprint database through database writing transactions. The algorithm identifier and the file fingerprint are stored together to ensure that the same algorithm can be accurately called in the subsequent verification stage.

[0035] In this embodiment of the invention, in step S3, the comparison process is triggered immediately after the file fingerprint is generated. First, the currently calculated file fingerprint is used to perform a precise query in the content object table of the fingerprint database. If an existing record is found, it means that a file with the same content has been entered into the database. In this case, the file entity is not stored again. Instead, the content object identifier blob_id corresponding to the existing record is reused, and a new version record is created only for this upload. This version record contains information such as version identifier, parent version identifier, version sequence number, referenced blob_id, and creation time, thereby achieving content-level deduplication and effectively reducing storage space usage. If no match is found, it means that the content of the file has not yet appeared in the fingerprint database. A new content object identifier blob_id needs to be created for it, and an initial version record is created at the same time.

[0036] In this embodiment of the invention, during step S3, a fork criterion check is performed simultaneously during the version management process described above: The reservation identifier carried in the uploaded metadata is compared with the existing record in the fingerprint database to determine if they are consistent. The time difference between the current upload time and the most recent upload time with the same reservation identifier is calculated, and it is determined whether this time difference is not greater than a preset threshold. Simultaneously, it is confirmed whether the two file fingerprints are distinct. When all three conditions are met, it is determined that the current upload belongs to a version divergence under the same experimental task. A version fork branch is created for this file fingerprint, parallel to the existing version record, and the fork reason information is recorded. The preset threshold is configured differently based on the type of scientific instrument. For instruments with short data generation cycles (such as high-frequency electrical signal measuring instruments and rapid imaging equipment), a low threshold is configured; for instruments with long data generation cycles (such as slow-process environment experimental devices), a high threshold is configured. The recommended configuration range for this preset threshold is 5 minutes to 30 minutes, and the specific value can be adjusted by the system administrator according to the actual experimental process.

[0037] In this embodiment of the invention, in step S3, the fork reason is encoded as an enumeration type field, including at least: a first encoded value representing a change in the uploader's identity (e.g., U01), a second encoded value representing a change in tag information (e.g., T01), and a third encoded value representing a change in project information (e.g., P01). The fork reason payload records the change details using a structured data format (e.g., JSON), which includes at least: the name of the changed metadata field, the field value before the change, the field value after the change, the user identifier who performed the change operation, and the timestamp of the change. For example, when a user modifies the project ownership information of a file during an upload operation, the system will record the payload {"changed_field":"project_id","old_value":"PJ001","new_value":"PJ002","operator":"user_zhang","timestamp":"2025-01-15T14:30:00Z"}. Through the above structured record, the complete path and motivation of the version fork can be accurately restored in subsequent audits.

[0038] In this embodiment of the invention, in step S3, the acquisition of the reservation identifier supports two modes. The preferred mode is to obtain the reservation task identifier bound to the current user login session by calling the application programming interface of the large scientific instrument sharing management platform. The backup mode is to generate a unique temporary reservation identifier based on the current user identity information, instrument identifier and session start timestamp when the network is unavailable or the application programming interface is unavailable. This temporary reservation identifier serves as the reservation identifier for this experiment. This design ensures that the traceability of data relationships can be maintained even in an offline environment where the application programming interface is not fully integrated.

[0039] In this embodiment of the invention, in step S4, when a user initiates a download request for a target file through the file retrieval and access interface, the system first obtains the original registration fingerprint and algorithm identifier corresponding to the target file from the fingerprint database, and transmits the file content to the download end. After the target file is transmitted, the system recalculates the hash value of the downloaded file using the same algorithm recorded during the original registration to obtain the download fingerprint. Then, the download fingerprint is compared bit by bit with the registration fingerprint. When the two are consistent, it indicates that the file content has not changed during the transfer process, and the user is allowed to use the file normally. When the two are inconsistent, the system outputs the prompt message "The file may have been tampered with or the transmission is abnormal", and automatically determines the risk level according to the preset abnormality level rules.

[0040] In this embodiment of the invention, in step S4, the combination of judgment conditions for the preset anomaly level rules includes, but is not limited to, the following dimensions: First, whether the downloader and the owner belong to the same project group; if not, the risk increases. Second, whether the time of initiation of this download request is within a preset high-risk period (such as early morning or a non-working day); if so, the risk increases. Third, whether the target file carries a "high sensitivity" tag in the labeled metadata; if so, the risk increases. Fourth, whether the cumulative number of fingerprint verification failures of the current downloader's downloaded files within a preset backtracking time window (such as the past 24 hours or the past week) exceeds a preset upper limit; if so, the risk increases. The system comprehensively analyzes the combination results of at least two of the above conditions and classifies the anomaly into the following three levels: Level 1 anomaly (low risk): Execution prompts and audit logs are written; Level 2 anomaly (medium risk): In addition to Level 1 anomaly, a notification message is sent to the owner's terminal; Level 3 Anomaly (High Risk): In addition to Level 2 anomalies, the downloaded files will be moved to the quarantine area and an alarm message will be sent to the administrator terminal.

[0041] In this embodiment of the invention, in step S4, when the downloaded fingerprint does not match the registered fingerprint in the fingerprint database and the preset deep review triggering conditions are met, the system enters the deep review process. The preset deep review triggering conditions include, but are not limited to: the target file size exceeds the preset large file threshold, the above-mentioned abnormal level is determined to be level two or three, and an active review instruction is received from the administrator terminal. The specific steps of the deep review process are as follows: First, obtain the pre-generated and stored block fingerprint baseline for the original data file during the upload phase. The block fingerprint baseline is a fingerprint sequence generated by calculating the fingerprint of each data block after the file is divided according to a preset block size (such as a fixed number of bytes or a fixed number of blocks) during the upload of the original data file. During deep review, the downloaded file is processed into blocks according to the same block division strategy, and the download block fingerprint of each data block is calculated one by one. The downloaded block fingerprint sequence is compared with the block fingerprint baseline block by block number to locate the specific block offset position where data differences occur. The location information of the located block offset position and the comparison details are written into the download audit record and sent as part of the notification message to the owner and administrator to facilitate subsequent accurate fault diagnosis or evidence analysis.

[0042] See Figure 2 This invention also discloses a document fingerprint verification and traceability system for scientific instrument data, which applies the above-mentioned document fingerprint verification and traceability method and includes: The controller, deployed on the computer connected to the scientific instruments, is used to acquire user identity information, instrument identification and reservation information of the scientific instruments, and to identify raw data files through file listening. The metadata annotation module, connected to the controller, is used to collect basic metadata and receive manually supplemented annotation information, and generate annotation metadata bound to the original data file; The fingerprint entry module, connected to the metadata annotation module, is used to select a digest algorithm based on the algorithm identifier to calculate the file fingerprint when an upload request is received, and to associate the file fingerprint, algorithm identifier and annotation metadata and write them into the fingerprint database. The fingerprint comparison module is connected to the fingerprint database module. It is used to perform fingerprint comparison on file fingerprints based on the fingerprint database. If the fingerprints are the same, the existing content object identifier is reused and a new version record is added. If they are different, a new content object identifier is created and a new version record is added. When the same reservation identifier, upload time difference is not greater than the preset threshold and fingerprints are inconsistent, a version fork is created and the fork reason code and fork reason payload are recorded for traceability. The download verification module, connected to the fingerprint entry module, is used to calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database when a download request is received. If the fingerprint does not match, the corresponding handling is performed according to the preset abnormal registration rules.

[0043] In the description of this invention, the references to "one embodiment," "some embodiments," "in this embodiment," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0044] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for verifying and tracing file fingerprints for scientific instrument data, characterized in that, Includes the following steps: Step S1: Deploy a controller on the computer connected to the scientific instrument to obtain the user identity information and instrument identifier of the scientific instrument, identify the original data file through file listening and automatically collect basic metadata and receive manually supplemented annotation information, and generate annotation metadata bound to the original data file. Step S2: Upon receiving an upload request, select a digest algorithm based on the algorithm identifier to calculate the file fingerprint, and associate the file fingerprint, the algorithm identifier, and the annotation metadata into the fingerprint database; Step S3: Perform fingerprint comparison on the file fingerprint based on the fingerprint database. If the fingerprints are the same, reuse the existing content object identifier and add a new version record. If they are different, create a new content object identifier and add a new version record. When the same reservation identifier, upload time difference is not greater than a preset threshold and fingerprints are inconsistent, create a version fork and record the fork reason code and fork reason payload for traceability. Step S4: After receiving the download request, calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database. If the fingerprints do not match, perform the corresponding processing according to the preset abnormal registration rules.

2. The document fingerprint verification and traceability method according to claim 1, characterized in that, In step S1, identifying the original data file through file monitoring includes: The controller continuously monitors the data output directory pre-agreed with the scientific instrument, and the response ends when a file creation completion event or a file write close event is detected. The file creation completion event or file write close event is then identified as the original data file generated in this experiment.

3. The document fingerprint verification and traceability method according to claim 1, characterized in that, In step S3, the application programming interface of the large-scale scientific instrument sharing management platform is called to obtain the reservation task identifier bound to the current user login session as the reservation identifier; or if the reservation task identifier is not obtained, a temporary reservation identifier is generated based on the user identity information, the instrument identifier and the current session start timestamp as the reservation identifier.

4. The document fingerprint verification and traceability method according to claim 1, characterized in that, The fork cause encoding in step S3 includes at least a first encoding value representing a change in the uploader's identity, a second encoding value representing a change in tag information, and a third encoding value representing a change in project information.

5. The document fingerprint verification and traceability method according to claim 1, characterized in that, The fork cause payload in step S3 includes structured data such as the changed field name, the value before the change, the value after the change, the operator identifier, and the change timestamp.

6. The document fingerprint verification and traceability method according to claim 1, characterized in that, The preset threshold in step S3 is determined according to the instrument type of the scientific instrument. A low threshold is configured for scientific instruments with short data generation cycles, and a high threshold is configured for scientific instruments with long data generation cycles. The range of the preset threshold is 5 minutes to 30 minutes.

7. The document fingerprint verification and traceability method according to claim 1, characterized in that, The preset anomaly level rule in step S4 determines the anomaly level based on a logical combination of at least two of the following conditions: whether the downloader and the owner belong to the same project group, whether the download time is within a preset high-risk period, whether the downloaded file carries a highly sensitive tag, and whether the cumulative number of fingerprint verification failures by the downloader within a preset backtracking period exceeds the upper limit.

8. The document fingerprint verification and traceability method according to claim 1, characterized in that, After performing step S4, the process further includes: When the downloaded fingerprint does not match the registered fingerprint in the fingerprint database and the preset deep review trigger condition is met, the block fingerprint baseline pre-generated and stored for the original data file during the upload stage is obtained. The downloaded file is calculated according to the same block segmentation strategy to obtain the downloaded block fingerprint sequence. The downloaded block fingerprint sequence is compared with the block fingerprint baseline block by block to locate the block offset position of the data anomaly. The position information of the block offset position is written into the audit record and notification message.

9. The document fingerprint verification and traceability method according to claim 1, characterized in that, The algorithm identifier in step S2 is used to indicate whether the selected digest algorithm is SM3, SHA-256, or BLAKE3, and the algorithm identifier is stored together with the file fingerprint.

10. A document fingerprint verification and traceability system for scientific instrument data, characterized in that, The document fingerprint verification and tracing method described in any one of claims 1-9 includes: The controller, deployed on the computer connected to the scientific instrument, is used to acquire the user identity information, instrument identification and reservation identification of the scientific instrument, and to identify the original data file through file listening. The metadata annotation module, connected to the controller, is used to collect basic metadata and receive manually supplemented annotation information, and generate annotation metadata bound to the original data file; The fingerprint entry module, connected to the metadata annotation module, is used to select a digest algorithm based on the algorithm identifier to calculate the file fingerprint when an upload request is received, and associate the file fingerprint, the algorithm identifier and the annotation metadata into the fingerprint database; The fingerprint comparison module is connected to the fingerprint database module and is used to perform fingerprint comparison on the file fingerprint based on the fingerprint database. If the fingerprints are the same, the existing content object identifier is reused and a new version record is added. If they are different, a new content object identifier is created and a new version record is added. When the same reservation identifier, the upload time difference is not greater than a preset threshold and the fingerprints are inconsistent, a version fork is created and the fork reason code and fork reason payload are recorded for traceability. The download verification module, connected to the fingerprint entry module, is used to calculate the download fingerprint of the downloaded file and compare it with the registered fingerprint in the fingerprint database when a download request is received. If the fingerprint does not match, the corresponding handling is performed according to the preset abnormal registration rules.

Images