Multi-terminal user data security classification protection system

Abstract

This invention discloses a multi-terminal user data security hierarchical protection system, comprising three independent data storage domains: a user terminal, a platform terminal, and a hospital terminal. The user terminal is configured to store personalized data and interaction records. The platform terminal is configured to store operational data and non-sensitive data using user identity identifiers in encrypted partitions. The hospital terminal is configured to exclusively store sensitive medical data and prohibits the transmission of complete data copies to external domains. The user terminal obtains an authentication token issued by the platform terminal through two-factor authentication. When a user terminal accesses data on the hospital terminal, the hospital terminal sends the authentication token to the platform terminal to verify the user's identity. If the verification is successful, a de-identified data index is returned. A dynamic access link is generated based on the index, allowing the user to view non-downloadable data rendered by the hospital terminal's page service within a limited time. This invention reduces the risk of privacy leaks, effectively eliminates redundant caching, and reduces the cost of multi-location storage.

Description

Technical Field

[0001] This invention relates to the field of multi-terminal data management technology, and in particular to a multi-terminal user data security hierarchical protection system. Background Technology

[0002] Currently, an increasing number of application systems need to integrate data from multiple systems to achieve data exchange and flow between them. However, traditional data flow methods suffer from the following problems:

[0003] (1) Risk of plaintext transmission: Most of them exchange data directly or transmit it in plaintext; for example, when a municipal hospital connects with a third-party health APP, the patient's test report is transmitted in plaintext with Base64 encoding, which makes it possible for a man-in-the-middle attack to completely restore the data.

[0004] (2) No hierarchical storage: All terminals use the same storage method for storage, without classifying the data or adopting different levels of storage schemes; for example, a certain Internet medical platform stores user consultation records and electronic medical records in the public cloud, which violates the regulations on local storage of sensitive data.

[0005] (3) Redundant storage costs: Each end needs to cross-read the data, resulting in repeated data storage; for example, a regional medical platform caches all patient history records on the insurance company's end, which increases storage costs by 200% annually.

[0006] Therefore, it is necessary to provide a multi-terminal user data security classification protection system to overcome the above-mentioned defects. Summary of the Invention

[0007] The purpose of this invention is to provide a multi-terminal user data security hierarchical protection system, which aims to solve the problems of easy leakage and high cost of redundant storage in multi-terminal data circulation and transmission.

[0008] To achieve the above objectives, the present invention provides a multi-terminal user data security hierarchical protection system, which includes three independent data storage domains: user terminal, platform terminal, and hospital terminal.

[0009] The user terminal is configured to store personalized data and interaction records;

[0010] The platform is configured to store operational data and non-sensitive data uploaded with user authorization in a partitioned and encrypted manner using user identity identifiers.

[0011] The hospital terminal is configured to store sensitive medical data exclusively. The sensitive data includes electronic medical records, diagnostic reports, and medical imaging data, and complete copies of the data are prohibited from being transmitted to external domains.

[0012] This involves setting up a cross-domain authentication gateway to achieve the following:

[0013] The user terminal obtains the authentication token issued by the platform through two-factor authentication, and binds the identity identifier of the corresponding medical institution to the hospital terminal; the identity identifier of the medical institution is uniquely associated with the user identity identifier on the platform terminal;

[0014] When the user terminal accesses data on the platform, it verifies whether the transmitted authentication token is valid. If the verification is successful, the corresponding data is displayed; otherwise, it is not displayed. When the platform responds to a data request, it only obtains the corresponding data from the user terminal or the hospital terminal if there is no valid cache locally.

[0015] When the user accesses data from the hospital, the hospital sends the authentication token to the platform to verify the legitimacy of the user's identity. If the verification is successful, a de-identified data index is returned. A dynamic access link is generated based on the index, allowing the user to view non-downloadable data rendered by the hospital's page service within a limited time.

[0016] In a preferred embodiment, a hierarchical encryption storage strategy is adopted for data at each end, specifically including the following steps:

[0017] When hospital data is entered into the database, metadata features are extracted, and the data sensitivity coefficient λ is calculated using the following formula;

[0018] λ = α·S + β·P + γ·C, where S is the data source weight, P is the privacy relevance, C is the compliance requirement coefficient, and α, β, and γ are preset adjustment factors.

[0019] The storage location of the corresponding entered data is dynamically matched based on the data sensitivity coefficient; wherein, when the data sensitivity coefficient is less than the first coefficient threshold, the corresponding entered data is allowed to be stored on the user terminal; when the data sensitivity coefficient is greater than or equal to the first coefficient threshold and less than the second coefficient threshold, the corresponding entered data is forcibly stored on the platform terminal; when the data sensitivity coefficient is greater than or equal to the second coefficient threshold, the corresponding entered data is only allowed to be stored on the hospital terminal; the first coefficient threshold is less than the second coefficient threshold.

[0020] In a preferred embodiment, the user terminal obtaining the authentication token issued by the platform through two-factor authentication specifically includes:

[0021] The user enters their account password via the client, and the platform sends an SMS verification code containing a dynamic salt value.

[0022] Code=Hash(UID||Timestamp||SecretKey) xWhere UID is the user's identity identifier, SecretKey is the pre-set key, Timestamp is the timestamp, || indicates concatenation, and the index x indicates taking the first x bits of the hash value;

[0023] Once the verification is successful, an authentication token with a predetermined validity period is generated.

[0024] In a preferred embodiment, the method for generating the de-identified data index is as follows:

[0025] The hospital receives the user identity identifier that has been successfully verified by the platform.

[0026] Based on the user's identity identifier, retrieve the identity identifier matching the medical institution and extract the data feature vector;

[0027] A verifiable index is generated by combining the data feature vectors with random numbers using a zero-knowledge proof algorithm.

[0028] In a preferred embodiment, when a user views non-downloadable data rendered by the hospital-side page service within a limited time via the access link, the hospital-side data display employs streaming encrypted rendering, specifically including:

[0029] After the dynamic access link is activated by the user, the hospital loads data fragments on demand, and each fragment is encrypted using the SM4 algorithm.

[0030] The client uses WebAssembly to decrypt and render in real time, and prohibits download operations.

[0031] In a preferred embodiment, an automatic erasing mechanism is also provided, specifically including:

[0032] The user's interaction log storage time T log Satisfy: T log =min(T) R 0.5×T A ), T R The preset maximum retention time; T A The duration from the generation date to the last access date, in days;

[0033] The cached data on the platform is processed by T after access. c Automatically deleted after a certain duration: T0 is the preset cache retention time, and a is the preset data sensitivity coefficient erase threshold.

[0034] In a preferred embodiment, T R The time is 30 days, T0 is 24 hours, and a is 0.3.

[0035] The multi-terminal user data security classification protection system provided by this invention has the following beneficial effects:

[0036] (1) Physical isolation of sensitive data: The hospital serves as the sole storage point for core sensitive data and has no complete data output interface, thereby blocking the outflow of data copies and reducing the risk of sensitive data leakage by about 80%, thus reducing the risk of privacy leakage.

[0037] (2) Tokenized authentication chain: The original identity information is replaced by authentication tokens, and dynamic verification is required for each access. Only the token and index are transmitted, reducing the amount of cross-domain data transmission by about 75%.

[0038] (3) On-demand retrieval mechanism: The platform only caches the de-identified index, while the complete data is kept on the source side. The storage cost of each side is reduced by 60%, effectively eliminating redundant caching and reducing the cost of multi-location storage. Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This invention provides an architecture diagram of a multi-terminal user data security classification protection system.

[0041] Figure 2 The flowchart of the multi-terminal user data security classification protection system provided by the present invention is shown. Detailed Implementation

[0042] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described in this specification are merely for explaining the invention and are not intended to limit the invention.

[0043] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0044] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0045] In embodiments of the present invention, a multi-terminal user data security hierarchical protection system is provided, particularly for use between users, third-party enterprises, and medical institutions such as hospitals, to manage data flow, prevent the leakage of sensitive patient data, and rationally allocate data storage locations to avoid storage redundancy.

[0046] like Figure 1 As shown, the multi-terminal user data security classification protection system includes three independent data storage domains: the user terminal, the platform terminal, and the hospital terminal. Among them, the platform terminal (also known as the "company terminal") is a third-party enterprise service platform excluding users and hospitals, mainly used to provide caching storage and authentication.

[0047] The user-side configuration is set to store personalized data and interaction records (such as AI question-and-answer records).

[0048] The platform is configured to use user identifiers (UIDs) to encrypt and store service-based operational data and non-sensitive data uploaded with user authorization. Data storage is identified by user identity, distinguishing data permissions for different users and different data types within the same user.

[0049] The hospital-side configuration is designated as the sole storage location for sensitive medical data, including electronic medical records, diagnostic reports, and medical imaging data. Complete copies of this data are prohibited from being transferred to external domains. Specifically, medical record data, diagnostic reports, and medical imaging data exist only on the hospital-side and must not be stored on other devices. When a user needs to access these data, they will be required to access a page service provided by the hospital using their user identity.

[0050] In this system, the data from the three terminals is stored independently, and access to the data is achieved through mutual authentication. Therefore, combining... Figure 2 As shown, this system achieves the following data flow by setting up a cross-domain authentication gateway.

[0051] The user obtains an authentication token issued by the platform through two-factor authentication. Specifically, the user enters their account password on the client side, and the platform sends an SMS verification code containing a dynamic salt value: Code = Hash(UID / / Timestamp / / SecretKey)x, where UID is the user's identifier, SecretKey is the pre-set key, Timestamp is the timestamp, / / indicates concatenation, and the index x indicates taking the first x digits of the hash value (e.g., x = 6 means taking the first 6 digits). Upon successful verification, an authentication token with a predetermined expiration time is generated. For example, for the initial binding to the hospital, the authentication token's expiration time can be set to 600 seconds, while for regular access, the expiration time can be set to 3600 seconds.

[0052] After registering on the platform, users can also bind the identity identifier of the corresponding medical institution on the hospital side (such as patient ID, social security number, or outpatient number); the identity identifier of the medical institution is uniquely associated with the user's identity identifier on the platform.

[0053] When a user accesses data on the platform, the validity of the transmitted authentication token is verified. If the verification passes, the corresponding data is displayed; otherwise, it is not displayed. Specifically, when responding to a data request, the platform only retrieves the relevant data from the user or hospital if there is no valid local cache, thus avoiding redundant storage.

[0054] When a user accesses data from the hospital, the hospital sends an authentication token to the platform to verify the user's identity. If the verification is successful, a de-identified data index is returned. Specifically, the de-identified data index is generated as follows: the hospital receives the user's identity identifier (UID) successfully verified by the platform; it retrieves the identity identifier of the matching medical institution based on the user's identity identifier and extracts the data feature vector; and it combines the data feature vector with a random number (Salt) to generate a verifiable index using a zero-knowledge proof algorithm (ZKP), ensuring that the index cannot be used to deduce the original data.

[0055] In this embodiment, after generating an index, the hospital generates a dynamic access link based on the index, allowing users to view non-downloadable data rendered by the hospital's page service within a limited time through this access link. The hospital's data display employs streaming encrypted rendering, specifically: after the dynamic access link is activated by the user, the hospital loads data fragments on demand, each fragment being encrypted using the SM4 algorithm; the user's end decrypts the rendering in real-time via WebAssembly and prohibits downloading operations.

[0056] In one embodiment, a hierarchical encryption storage strategy is adopted for data from each end, which specifically includes the following steps: when hospital data is entered into the database, metadata features are extracted, and the data sensitivity coefficient λ is calculated using the following formula;

[0057] λ = α·S + β·P + γ·C, where S is the weight of the data source (e.g., medical record = 1.0, registration record = 0.3), P is the privacy correlation degree (e.g., direct identification = 1.0, indirect identification = 0.5), C is the compliance requirement coefficient (mandatory regulation = 1.0, recommended = 0.6); α, β, and γ are preset adjustment factors (preferably 0.4, 0.4, and 0.2 respectively).

[0058] The physical meaning of the data source weight S is the sensitivity of the data generation scenario. A pre-defined scenario-weight mapping table can be created first. For example, electronic medical records = 1.0, prescriptions = 0.8, registration records = 0.3, and device logs = 0.1, resulting in a data source weight S = 0.9 for a "CT image report". The physical meaning of the privacy relevance S is the strength of the binding between data and personal identity. This can be achieved by identifying data types through NLP. For example, ID number / genetic data = 1.0, mobile phone number = 0.7, and age / gender = 0.3, resulting in a privacy relevance S = 1.0 for a "patient gene sequencing result". The physical meaning of the compliance requirement coefficient C is the level of legal and regulatory enforcement. This is linked to the regulatory knowledge base. For example, HIPAA / GDPR coverage = 1.0, industry standards = 0.6, and no requirement = 0.2, resulting in a compliance requirement coefficient C = 1.0 for a "HIV diagnosis record".

[0059] After determining the data sensitivity coefficient, the storage location of the corresponding entered data is dynamically matched based on the data sensitivity coefficient. Specifically, when the data sensitivity coefficient is less than the first coefficient threshold, the corresponding entered data is allowed to be stored on the user end; when the data sensitivity coefficient is greater than or equal to the first coefficient threshold and less than the second coefficient threshold, the corresponding entered data is forced to be stored on the platform end; when the data sensitivity coefficient is greater than or equal to the second coefficient threshold, the corresponding entered data is only allowed to be stored on the hospital end; the first coefficient threshold is less than the second coefficient threshold.

[0060] It should be noted that the technical essence of this embodiment is to achieve automated hierarchical storage decisions for sensitive data by dynamically calculating the feature weights of data elements. This avoids subjective misjudgments and solves the inconsistency in the sensitivity of manually labeled electronic medical records (e.g., doctor A labels it as high-risk, while doctor B labels it as medium-risk), using a unified quantification for the same type of data. Therefore, the vague concept of "sensitive data" is transformed into a calculable physical quantity. Through dynamic weight adjustment and real-time feature analysis, the storage architecture is optimized while ensuring compliance, thus solving the pain points of hierarchical storage of medical data.

[0061] The following simulation example will further illustrate the above technical solution:

[0062] Example: User-uploaded genetic testing report, extracted data features: S=0.9 (medical diagnostic grade data), P=1.0 (including user DNA sequence), C=1.0 (in accordance with the "Regulations on the Management of Human Genetic Resources");

[0063] Calculation: Data sensitivity coefficient λ = 0.4 * 0.9 + 0.4 * 1.0 + 0.2 * 1.0 = 0.96 > 0.8 (second coefficient threshold);

[0064] Execution: Triggers the hospital-side storage instruction to generate a unique access token Token_H. The platform only stores the de-identified index: "User123_Gene Report_HospitalToken_H";

[0065] When a user requests to view a page through the app (i.e., the user's client): the platform sends a Token_H to the hospital. After the hospital verifies the token, it returns a streaming page (downloading is prohibited) for the user to view.

[0066] In one embodiment, the system also includes an automatic erasure mechanism, specifically comprising:

[0067] User interaction log storage time T log Satisfy: T log =min(T) R 0.5×T A ), T R The maximum retention time is preset, for example, T. R For 30 days; T A The duration from the generation date to the last access date, in days;

[0068] The cached data on the platform is processed by T after access. c Automatically deleted after a certain duration: T0 is the preset cache retention time, such as 24h; a is the preset data sensitivity coefficient erase threshold, preferably 0.3.

[0069] The triggering condition in this embodiment can be set as follows: when the user generates a new interaction log (such as AI Q&A records or page operation logs), the timer starts and the system automatically records the initial generation timestamp of the log.

[0070] Dynamic timeliness calculation: Update the last access timestamp T each time a user accesses this log. A The system calculates the remaining validity period of each log in real time according to the above formula. If the current time - T A ≥0.5×T A(Example: If the last view was 3 days ago, it will be deleted 1.5 days after today), or if the current time - T0 > 30 days (mandatory fallback), the system will perform a batch cleanup task every day at midnight. A specific example illustrates the calculation method for the above validity period: For instance, a consultation record generated by a user on 2025-01-01: If it was last viewed on 2025-01-05 (four days ago) → validity period until min(30d, 0.5×4d) = 2025-01-07; if it was not viewed until 2025-01-31 → forced deletion on 2025-01-31 (30 days later).

[0071] Therefore, for high-frequency access logs, sensitive operation records are quickly destroyed to reduce the risk of leakage; for low-frequency access logs, idle data is released from storage space in advance; for logs that have not been accessed for a long time, they are deleted at the top of the 30th day to meet compliance requirements, reducing the amount of redundant data on the user end by more than 35% through dynamic cleanup. It is understandable that the above automatic erasure mechanism combines a data value decay model with compliance requirements, resulting in a short retention period for frequently used data (which may contain sensitive operations), while low-frequency data is retained proportionally, at 0.5T. A To prevent prolonged idleness, a hard limit of 30 days meets audit requirements; in addition, the cleanup task runs during low-load periods and automatically renews when users access the site, achieving seamless execution.

[0072] In summary, the multi-terminal user data security classification protection system provided by this invention has the following beneficial effects:

[0073] (1) Physical isolation of sensitive data: The hospital serves as the sole storage point for core sensitive data and has no complete data output interface, thereby blocking the outflow of data copies and reducing the risk of sensitive data leakage by about 80%, thus reducing the risk of privacy leakage.

[0074] (2) Tokenized authentication chain: The original identity information is replaced by authentication tokens, and dynamic verification is required for each access. Only the token and index are transmitted, reducing the amount of cross-domain data transmission by about 75%.

[0075] (3) On-demand retrieval mechanism: The platform only caches the de-identified index, while the complete data is kept on the source side. The storage cost of each side is reduced by 60%, effectively eliminating redundant caching and reducing the cost of multi-location storage.

[0076] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0077] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0078] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0079] In the embodiments provided by this invention, it should be understood that the disclosed systems, devices / terminal equipment, and methods can be implemented in other ways. For example, the system or device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of systems or units may be electrical, mechanical, or other forms.

[0080] The present invention is not limited to the description in the specification and embodiments, and thus other advantages and modifications can be readily realized by those skilled in the art. Therefore, the present invention is not limited to the specific details, representative devices and illustrated examples shown and described herein without departing from the spirit and scope of the general concept as defined by the claims and their equivalents.

Claims

1. A multi-terminal user data security hierarchical protection system, characterized in that, It includes three independent data storage domains: user-side, platform-side, and hospital-side. The user terminal is configured to store personalized data and interaction records; The platform is configured to store operational data and non-sensitive data uploaded with user authorization in a partitioned and encrypted manner using user identity identifiers. The hospital terminal is configured to store sensitive medical data exclusively. This sensitive medical data includes electronic medical records, diagnostic reports, and medical imaging data, and complete copies of this data are prohibited from being transmitted to external domains. The user terminal obtains an authentication token issued by the platform through two-factor authentication, and can bind the identity identifier of the corresponding medical institution on the hospital terminal after registering on the platform terminal; the identity identifier of the medical institution is uniquely associated with the user identity identifier on the platform terminal; When the user terminal accesses data on the platform, it verifies whether the transmitted authentication token is valid. If the verification is successful, the corresponding data is displayed; otherwise, it is not displayed. When the platform responds to a data request, it only obtains the corresponding data from the user terminal or the hospital terminal if there is no valid cache locally. When the user accesses data from the hospital, the hospital sends the authentication token to the platform to verify the legitimacy of the user's identity. If the verification is successful, a de-identified data index is returned. A dynamic access link is generated based on the index, allowing the user to view non-downloadable data rendered by the hospital's page service within a limited time.

2. The multi-terminal user data security hierarchical protection system as described in claim 1, characterized in that, A tiered encryption storage strategy is adopted for data across all terminals, specifically including the following steps: When hospital data is entered into the database, metadata features are extracted, and the data sensitivity coefficient λ is calculated using the following formula; λ = α·S + β·P + γ·C, where S is the data source weight, representing the sensitivity of the data generation scenario, assigned according to a pre-set scenario-weight mapping table; P is the privacy correlation degree, representing the strength of the binding between data and personal identity, assigned through data type identification; C is the compliance requirement coefficient, representing the mandatory level of laws and regulations on data, assigned according to the regulatory knowledge base; α, β, and γ are preset adjustment factors. The storage location of the corresponding entered data is dynamically matched based on the data sensitivity coefficient; wherein, when the data sensitivity coefficient is less than the first coefficient threshold, the corresponding entered data is allowed to be stored on the user terminal; when the data sensitivity coefficient is greater than or equal to the first coefficient threshold and less than the second coefficient threshold, the corresponding entered data is forcibly stored on the platform terminal; when the data sensitivity coefficient is greater than or equal to the second coefficient threshold, the corresponding entered data is only allowed to be stored on the hospital terminal; the first coefficient threshold is less than the second coefficient threshold.

3. The multi-terminal user data security hierarchical protection system as described in claim 1, characterized in that, The user terminal obtains the authentication token issued by the platform through two-factor authentication, specifically including: The user enters their account password via the client, and the platform sends an SMS verification code containing a dynamic salt value. Code=Hash(UID∥Timestamp∥SecretKey) x Where UID is the user's identity identifier, SecretKey is the pre-set key, Timestamp is the timestamp, ∥ indicates concatenation, and the index x indicates taking the first x bits of the hash value; Once the verification is successful, an authentication token with a predetermined validity period is generated.

4. The multi-terminal user data security hierarchical protection system as described in claim 1, characterized in that, The method for generating the de-identified data index is as follows: The hospital receives the user identity identifier that has been successfully verified by the platform. Based on the user's identity identifier, retrieve the identity identifier matching the medical institution and extract the data feature vector; A verifiable index is generated by combining the data feature vectors with random numbers using a zero-knowledge proof algorithm.

5. The multi-terminal user data security hierarchical protection system as described in claim 1, characterized in that, In the non-downloadable data rendered by the hospital-side page service when a user views it through the access link within a limited time, the hospital-side data display adopts streaming encrypted rendering, specifically including: After the dynamic access link is activated by the user, the hospital loads data fragments on demand, and each fragment is encrypted using the SM4 algorithm. The client uses WebAssembly to decrypt and render in real time, and prohibits download operations.

6. The multi-terminal user data security classification protection system as described in claim 2, characterized in that, It also features an automatic erasing mechanism, specifically including: The user's interaction log storage time T log Satisfy: T log =min(T R 0.5×T A ), T R The preset maximum retention time; T A The duration from the generation date to the last access date, in days; The cached data on the platform is processed by T after access. c Automatically deleted after a certain duration: T0 is the preset cache retention time, and a is the preset data sensitivity coefficient erase threshold. This is the calculated data sensitivity coefficient.

7. The multi-terminal user data security classification protection system as described in claim 6, characterized in that, T R The time is 30 days, T0 is 24 hours, and a is 0.3.

Images