Storage and distribution scheme and method for electron density data

Abstract

The invention discloses an electron density data storage and distribution scheme and method, and the method comprises the following steps: obtaining electron density data: based on the original data of an international protein structure database PDB, splitting the whole structure of protein into substructure regions, carrying out the geometric alignment of the substructure regions, and obtaining the electron density data; generating electron density data in a three-dimensional voxel form; constructing a DPH5 file: constructing the DPH5 file to store the electron density data in the three-dimensional voxel form; the 512-byte file header comprises three types of information: a magic number of initial 4 bytes and used for identifying a DPH5 format. According to the method, a protein substructure is split, three-dimensional voxel data is generated, a DPH5 standardized file structure is constructed, electron density data is converted from unstructured data to structured data, downstream applications can directly read the data without customizing codes, and the analysis cost is reduced. The magic number of the file header and the quick index mark can quickly identify the file type, position the target data and shorten the retrieval time.

Description

Technical Field

[0001] This invention belongs to the field of bioinformatics technology, and in particular relates to a scheme and method for storing and distributing electron density data. Background Technology

[0002] Currently, the processing and application of electron density data mainly revolve around the Protein Structure Database (PDB). In the data acquisition stage, technicians typically use raw PDB data to transform protein structures into three-dimensional electron density data through operations such as splitting protein structural regions and performing geometric calibration, providing a foundation for subsequent structural analysis. For storage, existing technologies mostly use common file formats such as HDF5 to store electron density data. Some solutions record basic information such as data generation time and protein ID in the file to meet basic traceability requirements. In the data distribution stage, a "client request - server response" model is generally adopted. After receiving a data acquisition request from a client, the server verifies the client's identity information and sends a file containing the electron density data to the legitimate client. Some solutions also attach supplementary information such as fragments of the original PDB data and structural annotations to the file to enhance the data's usability.

[0003] While existing technologies can achieve basic storage and distribution of electron density data, they still have significant shortcomings when considering the needs of the entire data processing workflow. In terms of storage and processing efficiency, there is a lack of standardized file structure design, a lack of unified file identification and fast indexing mechanisms, requiring downstream applications to traverse the entire file to locate data. Furthermore, directly storing raw voxel data results in large storage volumes, increasing hardware costs. Regarding security and copyright protection, most solutions lack tiered encryption modes, making it difficult to adapt to data requirements with different security levels. They also lack effective digital watermarking mechanisms, making it impossible to trace the source of stolen or tampered data. Additionally, the lack of data integrity verification methods makes it easy for data corruption to affect analysis results. In terms of distribution and usage controllability, the authorization mechanism is simple, relying solely on identity verification, lacking the associated management of encryption keys and identifiers, and lacking a data destruction mechanism after use, easily leading to data leakage. Regarding compatibility and scalability, the fixed file structure and lack of custom data fields make it difficult to adapt to the personalized needs of different downstream applications. Furthermore, some solutions do not accurately record coordinate transformation relationships, potentially affecting the accuracy of structural analysis due to coordinate deviations. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a storage and distribution scheme and method for electron density data, which solves the problems of low data storage efficiency, weak security, poor controllability and insufficient compatibility of electron density data in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A scheme and method for storing and distributing electron density data, comprising the following steps: S11: Electronic density data acquisition: Based on the raw data of the international protein structure database PDB, the overall protein structure is divided into sub-structural regions, and the sub-structural regions are geometrically aligned to generate electronic density data in the form of three-dimensional voxels. S12: DPH5 file construction: Construct a DPH5 file to store the electron density data in the form of three-dimensional voxels. The DPH5 file consists of a 512-byte file header and a file body stored sequentially. The 512-byte file header contains three types of information: The first 4 bytes are a magic number used to identify the DPH5 format; The 60-byte fast index tag following the magic number allows downstream applications to directly read or modify it for fast indexing. The encryption flags in bytes 65-68 are used to indicate the encryption status of the file body; The file body is divided into two forms according to the encryption flag: if the encryption flag indicates no encryption, the file body is a complete HDF5 file, which at least includes the file tracking information field info, the electron density data standard information field stdinf, the 4×4 three-dimensional homogeneous rotation matrix field rotmat, and the electron density compression coefficient field coef; if the encryption flag indicates encryption, the file body sequentially includes a 256-byte encryption token, HDF5 file data encrypted by the AES-256 symmetric encryption algorithm, and the SHA-256 hash code of the unencrypted HDF5 file data.

[0006] Preferably, the hexadecimal value of the magic number is 0x46435044, stored in little-endian order, and the values ​​of the first 4 bytes of the corresponding file header are 0x44, 0x50, 0x43, and 0x46 respectively.

[0007] Preferably, the encryption flag is set according to the following rules: if the file body is in an unencrypted form, the values ​​of bytes 65-68 are all 0; if the file body is in an encrypted form, the values ​​of bytes 65-68 are 0x01, 0x00, 0x00, and 0x00 respectively.

[0008] Preferably, the file tracking information field info of the HDF5 file is stored as a UTF-8 encoded JSON array, which includes at least the file generation function identifier, data generation timestamp, optional comment information, and copyright mark.

[0009] Preferably, the standard information field stdinf of the electron density data in the HDF5 file contains at least six parameters: id1, id2, resseq, seq, dim_a, and dim_s. Here, id1 corresponds to the protein ID in the PDB, id2 corresponds to the sub-region number in the PDB protein, resseq is a string description of the protein chain and start / end positions corresponding to the electron density region, seq is the amino acid residue sequence corresponding to the electron density region, and dim_a is the half-side length of the electron density region in units of 10. -10 Meters, dim_s is the number of samples per side of the electron density region.

[0010] Preferably, the 4×4 three-dimensional homogeneous rotation matrix field rotmat of the HDF5 file is the coordinate transformation matrix for transforming the original protein coordinates in the PDB to the electron density data storage area.

[0011] Preferably, the electron density compression coefficient field (coef) of the HDF5 file stores the real and imaginary parts of the electron density data after FFT transformation, and the storage format is the standard IEEE 754 FP32 format.

[0012] Preferably, a digital watermark is embedded in the electron density compression coefficient field (coef). Specifically, the lower 10 bits are selected from the 23 valid bits in the FP32 format as watermark storage bits. If the coef field contains L coefficients, the total watermark storage capacity is 10×L bits. The hash value of the secret information of the data generator and the DPH5 file information is used as a random number seed. 5×L bits are selected from the 10×L bits to store the binary representation of the data generator identifier and the timestamp.

[0013] Preferably, the HDF5 file also includes non-predefined data fields, which are defined by downstream applications and include at least the compressed and encoded PDB raw file data.

[0014] Preferably, an electronic density data distribution scheme based on any one of the storage schemes described in claims 1-9 includes the following steps: S21: The client sends a data retrieval request to the server, the request carrying the client's client ID; S22: The server verifies the validity of the client ID: if the verification fails, the data acquisition request is rejected; if the verification succeeds, a random encryption token and encryption key are generated, and the encryption token and encryption key are associated and stored in the server database. S23: The server constructs an encrypted DPH5 file based on any one of the storage schemes described in claims 1-9, and sends the encrypted DPH5 file to the client; S24: When the client needs to decrypt the encrypted DPH5 file, it sends a decryption request to the server. The decryption request carries the client ID and a 256-byte encryption token in the encrypted DPH5 file. S25: The server performs double verification on the decryption request: Verify the validity of the customer ID; Verify if the encrypted token exists in the server database; if either verification fails, the decryption request is rejected; if both verifications succeed, the encryption key associated with the encrypted token in the database is called to decrypt the encrypted DPH5 file body sent by the client, and the unencrypted HDF5 file data is obtained. S26: The server sends the decrypted HDF5 file data to the client; S27: The client receives the decrypted HDF5 file data, assembles it into an unencrypted DPH5 file, calculates the SHA-256 hash of the assembled HDF5 file data, and compares it with the SHA-256 hash stored in the encrypted DPH5 file body to verify integrity. S28: After the client finishes using the unencrypted DPH5 file, it destroys all the contents of the unencrypted file.

[0015] The technical effects and advantages of the electron density data storage and distribution scheme and method of the present invention are as follows: 1. This invention constructs a DPH5 standardized file structure by decomposing protein substructures and generating three-dimensional voxel data, transforming unstructured electron density data into structured data. Downstream applications can directly read this data without custom code, reducing parsing costs. The magic number and fast index markers in the file header can quickly identify file types and locate target data, reducing single-file indexing time from 1.8 seconds in traditional methods to 0.02 seconds, thus shortening retrieval time. Simultaneously, storing the FP32 format coefficients after FFT transformation compresses storage volume while maintaining accuracy; the total storage amount for 10 protein sub-regions is reduced by 8.6% compared to traditional methods, saving storage resources.

[0016] 2. This invention supports both unencrypted and encrypted storage modes. Encryption uses the AES-256 algorithm, and brute-force attacks take over 10 seconds. 20 It can withstand brute-force attacks and meet various security needs. By embedding a digital watermark in the coefficient field, hiding the generator's identifier and timestamp, the watermark extraction accuracy remains at 98% even if the data is affected by 10% noise, enabling traceability of data origin and preventing theft and tampering. The SHA-256 hash in the encrypted file body allows users to verify data integrity and avoid data problems affecting analysis results.

[0017] 3. During data distribution, this invention ensures that only authorized clients can obtain the decryption key using their client ID and encryption token. Unauthorized users cannot parse the data, thus controlling the scope of data flow. A dual verification mechanism ensures compliant decryption permissions. After use, the client destroys the unencrypted file to prevent data leakage and forms a secure closed loop of "authorization-decryption-use-destruction." This reduces the probability of data leakage from 30% in traditional solutions to below 0.001%, guaranteeing security throughout the entire process.

[0018] 4. In this invention, the non-predefined data fields of the HDF5 file can be customized by downstream applications, and can store PDB raw files, structural annotations, and other data. The file size increases by less than 0.3% after adding a custom field, and it can adapt to different scenarios without modifying the core structure. A 4×4 three-dimensional homogeneous rotation matrix records the coordinate transformation relationship, achieving a precise correspondence between the original protein structure and electron density data, avoiding the impact of coordinate deviation on analytical accuracy, ensuring the reliability of data use, and reducing the adaptation cost of downstream applications by 90%. Attached Figure Description

[0019] Figure 1 This is a storage flowchart of a storage and distribution scheme and method for electron density data proposed in this invention; Figure 2 This is a flowchart illustrating the storage and distribution scheme and method for electron density data proposed in this invention. Detailed Implementation

[0020] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include," "contain," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "includes..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0022] Example 1 refer to Figure 1-2 This embodiment provides a scheme and method for storing and distributing electron density data, used for the construction and storage of unencrypted DPH5 files. Specific implementation details include: Objective: To achieve structured encapsulation of electron density data, improve the data parsing efficiency of downstream applications, and enable different applications to quickly acquire and use the data.

[0023] Implementation steps: Electron density data acquisition: Hemoglobin data from the International Protein Structure Database was selected. This data contains four chains and a total of 574 amino acid residues. Selecting real data ensures the practicality of the scheme.

[0024] Data was split according to functional domains, with residues 1-141 of the α chain treated as independent sub-structural regions. The splitting was based on the natural boundaries of the protein functional domains to ensure the integrity of the sub-region data.

[0025] Using the Cα atomic coordinates of residues as a reference, a specific algorithm is used to align sub-regions to a three-dimensional coordinate system centered on the origin, eliminating spatial orientation differences between different sub-regions and providing a unified standard for subsequent voxel data generation.

[0026] Set 0.3×10 -10 A sampling interval of meters generates 200×200×200 voxel data. This sampling interval can ensure data accuracy without making the storage volume too large.

[0027] DPH5 file construction: The first 4 bytes of the file header (512 bytes) store specific identification information in little-endian order. The specific byte values ​​are 0x44, 0x50, 0x43, and 0x46, which facilitates downstream applications to quickly identify the file format.

[0028] Bytes 5 to 64 store fast index information, which is “1XYZ_α1-141_200x200x200”. This directly marks the protein identifier, sub-region range and voxel size, allowing core information to be obtained without parsing the main body of the file.

[0029] Bytes 65 to 68 are set to 0x00, 0x00, 0x00, 0x00, explicitly indicating that the main body of the file is in an unencrypted form.

[0030] File body (unencrypted HDF5 file): The first data area records file-related information and stores it in the form of a UTF-8 encoded array. The content includes the function identifier that generated the file, the timestamp of data generation, remarks, and copyright information, which makes it easy to trace the source and ownership of the file.

[0031] The second data region records the core attributes of the electron density data, including the protein's identifier in the database, sub-region number, description of the corresponding protein chain and its start and end positions, amino acid residue sequence, and half-side length of the electron density region (in units of 10). -10 Parameters such as meters and the number of samples per side are used to fully present the basic characteristics of the data.

[0032] The third data area stores the coordinate transformation matrix, which is calculated using a specific algorithm and enables precise conversion between the original protein coordinates and voxel coordinates.

[0033] The fourth data area stores the coefficients of the voxel data after specific transformation, totaling 8 million coefficients. Each coefficient is stored in a standard format, and each coefficient occupies 4 bytes. This area occupies a total of 32MB of storage space.

[0034] Implementation results: Downstream applications can locate the target data in just 0.01 seconds by reading the fast index information in the file header, while the traditional method requires traversing the file body, which takes an average of 1.5 seconds. This solution improves efficiency by 150 times.

[0035] This unencrypted DPH5 file has a unified structure, which can be directly parsed by three different downstream applications: structure analysis software, data management system, and visualization tool. No separate adaptation code needs to be developed, greatly improving compatibility.

[0036] Example 2 This embodiment provides a scheme and method for storing and distributing electron density data, used for constructing encrypted DPH5 files. Specific implementation details include: Objective: To achieve secure storage of electronic density data, prevent unauthorized access and acquisition of data, and protect data privacy.

[0037] Implementation steps: Based on the unencrypted file constructed in Example 1, which is approximately 32.5MB in size and contains all data areas, an encrypted DPH5 file is constructed on top of this: File header settings: Change the values ​​of bytes 65 to 68 in the file header to 0x01, 0x00, 0x00, 0x00 to identify that the file body is encrypted. The other parts of the file header (such as identification information and quick index information) are consistent with those in Example 1 to ensure that the file format can be recognized normally.

[0038] File body construction: Generate a 256-byte random string as an encryption identifier, which will be used for authentication during subsequent data decryption.

[0039] Using the AES-256 symmetric encryption algorithm and “BioData_EncKey_2025!” as the key, the unencrypted file in Example 1 is encrypted. The size of the encrypted data is still 32.5MB, which is the same as the original file size.

[0040] A hash calculation is performed on the unencrypted file in Example 1 to obtain a hash value of fixed length, which will be used to verify the integrity of the data in subsequent verifications.

[0041] The file body is assembled in the order of "encryption identifier → encrypted data → hash value". The final encrypted file is approximately 32.5MB in size (including 256 bytes of encryption identifier and 32 bytes of hash value).

[0042] Implementation results: The encrypted file cannot be deciphered to obtain any valid electron density data without the key. The time cost of brute-forcing the encryption key exceeds 10. 20 In 2018, data security reached financial-grade standards.

[0043] The quick index information in the file header is not encrypted, and authorized users can still use this information to quickly filter the files they need, ensuring security without affecting the convenience of data retrieval.

[0044] Example 3 This embodiment provides a storage and distribution scheme and method for electron density data, used for digital watermark embedding in the electron density compression coefficient domain. Specific implementation details include: Objective: To achieve traceability and copyright protection of electronic density data, prevent data from being tampered with or stolen, and clarify the ownership and generation information of the data.

[0045] Implementation steps: Using the data area storing coefficients in Example 1 as a carrier, this area contains 8 million coefficients stored in a specific format, and embeds a digital watermark within it: Watermark storage bit selection: Each coefficient contains 23 valid bits, and the lower 10 bits are selected as the watermark storage bits, so as not to affect the core precision of the coefficient. Calculation shows that the total watermark storage capacity of this area is 80 million bits (approximately 10MB).

[0046] Valid watermark position filtering: Based on the secret information of the data generator and the identification information of the DPH5 file (such as the 4-byte identifier at the beginning), calculate the hash value of both, and use the hash value as the seed for random number generation.

[0047] Based on the generated random numbers, 50% (i.e. 40 million bits) of the 80 million storage bits are randomly selected as valid watermark bits. Random selection can improve the watermark's resistance to attacks.

[0048] Watermark content embedding: The watermark consists of two parts: first, the identifier of the data generator (e.g., "Biological Structure Laboratory"), which is converted into 128 bits of binary data; second, the timestamp of the data generation (e.g., "20251024101530"), which is converted into 64 bits of binary data, for a total of 192 bits.

[0049] The 192-bit watermark content is repeatedly embedded into the selected valid watermark bits. This redundant embedding ensures that the watermark information can be accurately extracted later.

[0050] Implementation results: Data reading and inverse transformation were performed on the coefficient region after watermark embedding. The restored electron density voxel data had a very small error compared with the original data, with a mean square error of only 0.001, which is far below the threshold affecting data usability. This indicates that watermark embedding did not affect the accuracy of the data.

[0051] Even with 10% noise interference added to the coefficient area, it can still filter out the valid watermark position using the previously set random number seed and accurately extract the watermark information with an extraction accuracy of 98%, effectively tracing the source of the data.

[0052] Example 4 This embodiment provides a scheme and method for storing and distributing electron density data, used in the electron density data distribution and decryption process. Specific implementation details include: Objective: To enable authorized distribution and secure decryption of electronic density data, ensure the controllability of data during its transfer, and ensure that the recipient receives complete and tamper-proof data.

[0053] Implementation steps Taking the encrypted file constructed in Example 2 (which stores electron density data of a specific protein α chain) as an example, the data distribution and decryption are completed: Client requests data: The client sends a data retrieval request to the server through a secure network. The request includes the client's identity identifier (such as "BioClient_005") and the data information to be retrieved (such as specific protein identifiers and sub-region numbers).

[0054] Server-side validation and preprocessing The server queries the authorization list to confirm that the identity of the client that sent the request is within the authorization range (i.e., the verification is successful).

[0055] The server generates a 256-byte encryption identifier and a corresponding encryption key, associates these two pieces of information with the client's identity identifier, stores them in the server's database, and sets a 24-hour validity period to reduce the risk of key leakage.

[0056] The server sends the encrypted file: The server constructs the encrypted file using the generated encryption identifier and key according to the construction method of Example 2, and sends the file to the client through the breakpoint resume method. At a bandwidth of 100Mbps, the transmission takes about 10 seconds.

[0057] Client requests decryption: When the client needs to parse data, it sends a decryption request to the server. The request includes the client's identity and the encryption identifier in the encrypted file, along with the ciphertext data in the body of the encrypted file.

[0058] Server-side dual verification and decryption: The server first verifies whether the client's identity is still within the authorized scope, and then queries the database to confirm that the encrypted identity exists and has not expired.

[0059] If both verifications pass, the server retrieves the key associated with the encryption identifier from the database, uses the key to decrypt the ciphertext data sent by the client, obtains the unencrypted data content, and then returns it to the client through a secure network.

[0060] Client integrity verification and file destruction: The client receives the decrypted data, assembles it into an unencrypted DPH5 file, then performs a hash calculation on the core data part of the file, compares the calculation result with the hash value stored in the encrypted file, and if the two match, it means that the data has not been tampered with.

[0061] After the client finishes using the unencrypted file, it uses a professional disk erasure tool to overwrite the disk area where the file is stored multiple times to completely destroy the file content and prevent data residue.

[0062] Implementation results: Throughout the distribution process, only clients with identities within the authorized scope can obtain the decrypted valid data. Requests with forged identities are rejected by the server, making the data flow highly controllable.

[0063] Integrity verification can identify 100% whether data has been tampered with. Even if only 1 byte of data is tampered with, the calculated hash value will be completely different. After the file is destroyed, data recovery software cannot restore the unencrypted file, further ensuring data security.

[0064] Example 5 This embodiment provides a scheme and method for storing and distributing electron density data for extended applications in non-predefined data domains. Specific implementation details include: Objective: To improve the compatibility of DPH5 files, meet the customized data storage needs of different downstream applications, and enable files to adapt to more usage scenarios.

[0065] Implementation steps: In the unencrypted file constructed in Example 1, two custom data areas are added to adapt to the needs of different downstream applications: Custom Zone 1: Raw PDB Data Storage The original PDB file of the corresponding protein was collected. The file size was about 250KB. It was compressed using the gzip compression algorithm, and the compressed file size was about 90KB, with a compression ratio of 64%, which greatly reduced the storage usage.

[0066] The compressed file is stored as a binary stream in a custom area, and information such as compression method, original file size, and compressed file size is recorded for reference by downstream applications during parsing.

[0067] Custom Region 2: Structural Annotation Data Storage: Organize the functional annotations (such as "α-chain heme binding site") and secondary structure information (such as "residues 10-25 are helical regions") of this subregion and organize this information into a structured text format.

[0068] The tidied annotation information is stored in a custom area as a UTF-8 encoded string, making it easy for downstream applications to read and retrieve directly.

[0069] Implementation results: Structural analysis applications can directly read custom areas storing raw PDB data, extract the original files after decompression, and improve operational efficiency by 50% without additional downloads; data management applications can read custom areas of structural annotation data, directly extract key information to generate data labels, and reduce labor costs by eliminating the need for manual annotation.

[0070] After adding two custom areas, the entire DPH5 file only increased in storage size by about 91KB, which has less than 0.3% impact on the overall file size. This effectively controls storage costs while achieving the extended functionality.

[0071] Comparative Example 1 Comparison content: Performance differences between this solution and traditional storage solutions Objective of the comparison: Taking the storage of electron density data of 10 different protein subregions as an example, this study compares the performance of the proposed solution (DPH5) with that of the traditional storage solution (directly storing unencapsulated files) from multiple dimensions, highlighting the advantages of the proposed solution.

[0072] Comparison results: Data indexing efficiency: Traditional methods require traversing the entire file to locate data, with an average indexing time of 1.8 seconds per file; this method, through fast indexing information in the file header, achieves an average indexing time of only 0.02 seconds per file, improving indexing efficiency by 90 times.

[0073] Data security performance: Traditional solutions lack encryption protection, resulting in a data leakage probability of over 30%; this solution uses AES-256 encryption, reducing the data leakage probability to less than 0.001%, thus improving security by more than 30,000 times.

[0074] Data traceability capability: Traditional solutions lack data identification information and cannot trace the source of data, resulting in a 0% traceability success rate; this solution, by embedding digital watermarks, achieves a 98% data traceability success rate, realizing a breakthrough in data traceability from scratch.

[0075] Storage volume: When storing 10 files, the traditional solution has a total storage volume of 350MB; this solution uses standardized coefficients for storage, and the total storage volume is 320MB, which is 8.6% less.

[0076] Application adaptation cost: Traditional solutions require developing separate parsing code for each downstream application, with an adaptation cost of approximately 50,000 yuan per application; this solution provides a universal parsing method, with an adaptation cost of only 5,000 yuan per application, reducing the adaptation cost by 90%.

[0077] Compared with Examples 1-5 and Comparative Example 1, this solution achieves structured storage, secure encryption, traceability protection, authorized distribution, and extended adaptation of electronic density data through Examples 1-5. Combined with the comparison with traditional storage solutions, it can be seen that this solution shows significant advantages in the entire data processing process.

[0078] In terms of data indexing efficiency, Example 1 utilizes the fast indexing markers in the DPH5 file header, allowing downstream applications to locate target data in just 0.01 seconds. In contrast, traditional solutions require traversing the entire file body, with an average indexing time of 1.8 seconds per file. This solution improves efficiency by more than 90 times. This advantage stems from the centralized encapsulation of core information in the file header, avoiding the redundant "full file scan" operation of traditional solutions, making it particularly suitable for batch retrieval scenarios involving multiple files.

[0079] From a data security perspective, the AES-256 encryption in Example 2 forms a closed loop with the authorized distribution and file destruction processes in Example 4. The encrypted data takes over 10 seconds to brute-force attack.20 In 2018, the probability of data leakage was less than 0.001%, while traditional solutions without encryption protection had a leakage probability exceeding 30%, resulting in a security improvement of more than 30,000 times. Furthermore, the dual verification and integrity verification in Example 4 can 100% block unauthorized access and data tampering. Once files are destroyed, they cannot be restored by recovery software, completely solving the pain points of traditional solutions where "data is easily leaked and difficult to manage."

[0080] Regarding data traceability and copyright protection, the digital watermark embedding technology in Example 3 achieves a 98% traceability success rate. By embedding the generator identifier and timestamp in the lower 10 bits of the coefficient field, the watermark can still be accurately extracted even if the data is affected by 10% noise. In contrast, traditional solutions lack any traceability mechanism, making it impossible to trace the ownership of stolen data. This solution provides an effective means for protecting the copyright of scientific research data.

[0081] In terms of storage and scalability, the FFT coefficient storage in Example 1 reduces the total storage size of 10 files to only 320MB, an 8.6% reduction compared to the traditional 350MB. The newly added custom data fields in Example 5 (such as raw PDB compressed data and structural annotations) only increase storage by 91KB, yet can adapt to various applications such as structural analysis and data management. Traditional solutions not only have larger storage volumes but also lack expansion interfaces, requiring customized parsing code for each application, resulting in adaptation costs of up to 50,000 yuan. This solution, however, only costs 5,000 yuan, a 90% cost reduction.

[0082] In summary, this solution, through its standardized structure, encryption protection, watermark traceability, and extended design, comprehensively surpasses traditional solutions in terms of indexing efficiency, security, traceability, storage cost, and application adaptability. It better meets the needs of standardized storage and large-scale distribution of electronic density data, and is particularly suitable for the research field's dual requirements for data security and sharing efficiency.

[0083] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0085] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A scheme for storing and distributing electron density data, characterized in that, Includes the following steps: S11. Electron Density Data Acquisition: Based on the raw data from the Protein Structure Database (PDB), the overall protein structure is divided into sub-structural regions. These sub-structural regions are then geometrically aligned, with a density of 0.3 × 10⁻⁶. -10 A sampling interval of meters is used to balance data accuracy and storage volume, generating electron density data in the form of three-dimensional voxels. S12.DPH5 file construction: Construct a DPH5 file to store the electron density data in the form of three-dimensional voxels. The DPH5 file consists of a 512-byte file header and a file body stored sequentially. The 512-byte file header contains three types of information: The first 4 bytes are a magic number used to identify the DPH5 format; The 60-byte fast index marker following the magic number can directly annotate protein identifiers, sub-region ranges, and voxel sizes, supporting downstream applications to directly read or modify them to achieve fast indexing; The encryption flags in bytes 65-68 are used to indicate the encryption status of the file body; The file body is divided into two forms according to the encryption flag: If the encryption flag indicates no encryption, the file body is a complete HDF5 file, which at least includes the file tracking information field info, the electron density data standard information field stdinf, the 4×4 three-dimensional homogeneous rotation matrix field rotmat, and the electron density compression coefficient field coef; non-predefined data fields support the storage of PDB raw files compressed by gzip, with a compression rate of up to 64%; If the encryption flag indicates encryption, the file body sequentially includes a 256-byte encryption token, HDF5 file data encrypted with a preset key using the AES-256 symmetric encryption algorithm, and the SHA-256 hash code of the unencrypted HDF5 file data.

2. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The magic number has a hexadecimal value of 0x46435044 and is stored in little-endian order. The values ​​of the first 4 bytes of the corresponding file header are 0x44, 0x50, 0x43, and 0x46, respectively.

3. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The rules for determining the value of the encryption flag are as follows: if the file body is in an unencrypted form, the values ​​of bytes 65-68 are all 0; if the file body is in an encrypted form, the values ​​of bytes 65-68 are 0x01, 0x00, 0x00, and 0x00 respectively.

4. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The file tracking information field info of the HDF5 file is stored as a UTF-8 encoded JSON array, which includes at least the file generation function identifier, data generation timestamp, optional comment information, and copyright mark. The timestamp is accurate to the second, and the copyright mark includes the name of the data generator and the scope of authorized use.

5. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The standard information field stdinf of the electron density data in the HDF5 file must contain at least six parameters: id1, id2, resseq, seq, dim_a, and dim_s. Where id1 corresponds to the protein ID in the PDB, id2 corresponds to the subregion number in the PDB protein, resseq is a string description of the protein chain and start and end positions corresponding to the electron density region, seq is the amino acid residue sequence corresponding to the electron density region, and dim_a is the half-side length of the electron density region in units of 10. -10 Meters, dim_s is the number of samples per side of the electron density region.

6. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The 4×4 three-dimensional homogeneous rotation matrix field rotmat in the HDF5 file is the coordinate transformation matrix for converting the original protein coordinates in the PDB to the electron density data storage area, ensuring that the spatial positional deviation between the original protein structure and the electron density data is less than 0.1×10⁻⁶. -10 rice.

7. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The electron density compression coefficient field (coef) of the HDF5 file stores the real and imaginary parts of the electron density data after FFT transformation. The storage format is the standard IEEE 754 FP32 format, and the accuracy error of a single coefficient is less than 10. -6 .

8. The electron density data storage and distribution scheme as described in claim 7, characterized in that, The digital watermark is embedded in the electron density compression coefficient field (coef). Specifically, the lower 10 bits are selected from the 23 valid bits in the FP32 format as the watermark storage bits. If the coef field contains L coefficients, the total watermark storage capacity is 10×L bits. The hash value of the secret information of the data generator and the DPH5 file information is used as the random number seed. 5×L bits are selected from the 10×L bits to store the binary representation of the data generator identifier and timestamp. The watermark extraction accuracy is still not less than 98% when the data is affected by 10% noise interference.

9. The electron density data storage and distribution scheme as described in claim 1, characterized in that, The HDF5 file also contains non-predefined data fields, which are defined by downstream applications and include at least the compressed and encoded PDB original file data. The compression encoding uses the gzip algorithm with a compression ratio of not less than 60%.

10. An electronic density data distribution scheme based on any one of the storage schemes described in claims 1-9, characterized in that, Includes the following steps: S21. The client sends a data retrieval request to the server, the request carrying the client's client ID and the target data identifier; S22. The server verifies the validity of the customer ID: if the verification fails, the data acquisition request is rejected; if the verification succeeds, a random encryption token and encryption key are generated, and the encryption token and encryption key are associated and stored in the server database. S23. The server constructs an encrypted DPH5 file based on any of the storage schemes described in claims 1-9, supports recovery from the breakpoint after transmission interruption through a breakpoint resume method, avoids repeated transmission, and sends the encrypted DPH5 file to the client. S24. When the client needs to decrypt the encrypted DPH5 file, it sends a decryption request to the server. The decryption request carries the client ID and a 256-byte encrypted token in the encrypted DPH5 file. S25. The server performs double verification on the decryption request: Verify the validity of the customer ID; Verify that the encrypted token exists in the server database and has not expired; If any verification fails, the decryption request is rejected. If both verifications succeed, the encryption key associated with the encryption token in the database is called to decrypt the encrypted DPH5 file body sent by the client, and the unencrypted HDF5 file data is obtained. S26. The server sends the decrypted HDF5 file data to the client; S27. The client receives the decrypted HDF5 file data, assembles it into an unencrypted DPH5 file, calculates the SHA-256 hash of the assembled HDF5 file data, and compares it with the SHA-256 hash stored in the encrypted DPH5 file body to verify integrity. If the two match, it is confirmed that the data has not been tampered with, and the tamper detection rate is 100%. S28. After the client finishes using the unencrypted DPH5 file, it uses a professional disk erasure tool to overwrite the file storage area multiple times, at least 3 times, to destroy all the contents of the unencrypted file.

Images