Intelligent data management system for member system and authentication

Abstract

The invention relates to the technical field of business data management, in particular to an intelligent data management system for a member system and authentication. Comprising a dynamic risk assessment module used for locally collecting and calculating local risk indexes at a user terminal, a cloud authentication and access control center, a modular subsystem composed of a plurality of independent function modules with unified data interfaces, a deep learning data management engine and a cloud database cluster. Compared with the prior art in which static authentication is generally adopted or the risk assessment is carried out purely by the cloud, the method has the advantages that the response is slow and the terminal environment change is difficult to capture in real time; according to the invention, the scheme that the lightweight risk assessment model is deployed at the user terminal and the matching degree analysis is carried out based on the environment behavior data collected in real time and the historical behavior feature baseline stored locally is adopted, so that non-inductive, real-time and accurate security risk assessment is realized; and the quantized local risk index can be used as a core variable for driving subsequent authentication and access control.

Description

Technical Field

[0001] This invention relates to the field of commercial data management technology, and in particular to an intelligent data management system for membership systems and authentication. Background Technology

[0002] Membership management and authentication systems are a core component of modern enterprise customer relationship management, aiming to achieve unified management of member information, secure authentication, and personalized services. With the increasing prevalence of multi-store operations and digital services, such systems need to effectively integrate online and offline data and provide members with a consistent, secure, and convenient experience.

[0003] Existing membership management technologies have several shortcomings in practice. Many systems use static authentication methods, relying solely on account passwords, which are insufficient to prevent unauthorized access or account theft. Membership data between different stores or business systems often forms information silos, leading to inconsistencies in member information and fragmented cross-store shopping experiences. Data access permissions between modules within a system are sometimes too broad, making it easy for data to spread if a module is compromised. Furthermore, traditional systems typically lack intelligent data cleaning and integration capabilities when dealing with multi-source, heterogeneous membership data, making it difficult to automatically correct data conflicts or fill in missing information. From an architectural perspective, some systems lack scalability and struggle to cope with high-concurrency scenarios and rapidly changing business needs.

[0004] This patent aims to solve the aforementioned problems by constructing an intelligent data management system for membership systems and authentication. The system generates a dynamic risk index through real-time environmental and behavioral analysis on the user's local terminal. The cloud then dynamically adjusts authentication strength and data access scope based on this index, achieving a balance between security and user experience. The system adopts a modular design, strictly limiting each functional module to accessing only specific sub-databases and employing independent encryption algorithms to effectively enhance internal data security. Simultaneously, the system integrates a deep learning data governance engine, capable of automatically parsing, resolving conflicts, and intelligently populating multi-source member data to generate high-quality, standardized member profiles. Through the synergistic work of these technologies, this invention provides a more secure, intelligent, and scalable integrated solution for membership management and authentication. Summary of the Invention

[0005] To overcome the problems mentioned in the background art, the present invention proposes an intelligent data management system for membership systems and authentication.

[0006] The technical solution of this invention is: an intelligent data management system for membership systems and authentication, comprising:

[0007] A dynamic risk assessment module used to collect and calculate local risk indices on user terminals.

[0008] A cloud-based authentication and access control center used to dynamically select authentication methods based on local risk indices and control the scope of data access based on indices and data sensitivity.

[0009] A modular subsystem consisting of multiple independent functional modules with a unified data interface, wherein each module is configured to access only a specified sub-database, and different modules use different encryption algorithms to communicate.

[0010] A deep learning data governance engine for intelligently reading, filling, repairing and organizing messy member data from different sources to generate standardized member data;

[0011] The cloud-based database cluster is used to store different types of member data using multiple sharded databases. When it receives a read request from a subsystem module, it verifies the module's permissions, retrieves the data from the corresponding sharded database, encrypts it using the encryption algorithm specified by the module, and then sends it.

[0012] As a preferred option, the specific workflow of the dynamic risk assessment module is as follows:

[0013] S11: Real-time collection of native security data on the current environment and behavior of user terminals;

[0014] S12: Obtain the user's historical behavioral characteristics baseline from local secure storage;

[0015] S13: Perform a matching degree analysis between the collected native security data and the historical behavioral feature baseline, and calculate the feature matching degree in multiple dimensions;

[0016] S14: Input the key indicators of the native security data and the feature matching degree of multiple dimensions into a lightweight risk assessment model pre-deployed locally on the user terminal to calculate a quantitative local risk index.

[0017] S15: Securely report the calculated local risk index to the cloud-based risk control center.

[0018] As a preferred option, the specific workflow of the cloud-based authentication and access control center is as follows:

[0019] S21: Receive an access request from the user terminal, which includes the user identifier, the identifier of the data resource to be accessed, and the local risk index calculated by the user terminal;

[0020] S22: Based on the preset policy mapping rules, and according to the local risk index and the data sensitivity level corresponding to the data resource identifier, dynamically determine the authentication strength level required for the current session;

[0021] S23: Based on the determined authentication strength level, initiate the corresponding authentication process to the user terminal and verify the authentication result;

[0022] S24: Based on successful authentication, the access control policy engine calculates the actual data range that the current session is allowed to access according to the local risk index and data resource identifier. The actual data range is a subset of the requested data resources.

[0023] S25: Process the access request based on the determined actual data range: if the range is not empty, allow access and return the data within the range; if the range is empty, reject the access request.

[0024] As a preferred option, the dynamic data access blocking rule table includes the following strategies:

[0025] A11: When the local risk index is below the first threshold, no data fields with sensitivity labels are prohibited;

[0026] A12: Access to core privacy data is prohibited when the local risk index is between the first and second thresholds;

[0027] A13: When the local risk index is higher than the second threshold, in addition to prohibiting access to core privacy data, access to transaction records and account asset data will be further prohibited.

[0028] As a preferred approach, the modular subsystem is constructed and operates as follows:

[0029] S31: System construction, which breaks down the overall business functions into multiple functionally independent business modules, and defines standardized data request interfaces and data formats for each business module to form a modular subsystem;

[0030] S32: Module registration and binding. Create a unique identity for each business module registered in the cloud and assign it a clear data access permission mapping relationship. This mapping relationship limits the one or more specific databases that this module is allowed to access.

[0031] S33: Request reception and authentication. Receives encrypted data requests from business modules and verifies the identity and legitimacy of the requesting module and its access rights to the target database.

[0032] S34: Secure data acquisition and return. After successful authorization verification, plaintext data is extracted from the target database and encrypted using the proprietary encryption algorithm and key corresponding to the request module. The encrypted data is then returned to the request module.

[0033] As a preferred option, the system construction steps specifically include:

[0034] S311: Decouple the functions of the complete membership management system and encapsulate them into multiple independently deployable business modules. These business modules include: an authentication module responsible for identity verification, a membership account module responsible for managing basic information, a transaction processing module responsible for handling payment and points changes, and a marketing analysis module responsible for user profiling and marketing.

[0035] S312: Define a unified data request interface specification for all business modules, including request header format, authentication method, resource identification method, and response format.

[0036] As a preferred approach, the data request process for the cloud database cluster processing module is as follows:

[0037] S41: Receive a digital signature data request from a subsystem functional module. The request must include at least the module identifier, the request operation type, the target database identifier, and the timestamp.

[0038] S42: Verify the validity of the digital signature and the freshness of the request;

[0039] S43: After the signature and freshness verification are passed, query the predefined permission mapping table based on the module identifier to verify whether the module has the right to perform the requested operation type on the database specified by the target database identifier;

[0040] S44: After the permission verification is successful, retrieve and extract the plaintext data result set from the database sub-database corresponding to the target database identifier according to the request;

[0041] S45: Based on the module identifier that initiated the request, retrieve the proprietary encryption algorithm and key pre-configured for that module from the encryption policy library;

[0042] S46: Use a proprietary encryption algorithm and key to encrypt the plaintext data result set, generate a ciphertext payload, and return a response containing the ciphertext payload to the subsystem function module that initiated the request.

[0043] As a preferred option, verifying whether the module has the authority to perform the requested operation type on the target database specifically involves:

[0044] Query the permission mapping table, which records a list of one or more database identifiers that each module identifier is authorized to access and their corresponding operation permissions;

[0045] Determine whether the target database identifier in the request exists in the list of database identifiers authorized for the requesting module, and whether the request operation type is within the scope of its authorized operation permissions.

[0046] As a preferred option, the sharded database includes:

[0047] The core privacy information database is used to store ID card numbers and biometric information;

[0048] The member account information database is used to store basic identity information and contact details;

[0049] The transaction log database is used to store records of spending, top-ups, and points changes.

[0050] A behavior log library used to store user action and activity logs.

[0051] As a preferred option, a deep learning data governance engine, when in operation, specifically includes:

[0052] S51: Receive raw member data in real time or in batches from multiple heterogeneous data sources. The raw member data includes structured, semi-structured, and unstructured data.

[0053] S52: Using a trained deep learning model, the original member data is automatically parsed to identify and extract predefined member entity fields;

[0054] S53: Compare multiple records extracted from different data sources that point to the same member entity, detect field conflicts, and generate consistent merged records according to predefined conflict resolution rules;

[0055] S54: For fields missing or obvious errors in the merged records, the predictive model is called to intelligently fill and correct them, generating complete and accurate member profile data;

[0056] S55: Format the processed member profile data according to the standard data model of the target system and write it into the corresponding sub-database of the member master database.

[0057] The beneficial effects of this invention are:

[0058] 1. Compared with existing technologies that typically employ static authentication or risk assessment solely through the cloud, which are slow to react and difficult to capture changes in the terminal environment in real time, this invention adopts a solution that deploys a lightweight risk assessment model on the user terminal and performs matching degree analysis based on real-time collected environmental behavior data and locally stored historical behavior feature baselines. This solution has the advantages of achieving seamless, real-time, and accurate security risk assessment, and can use the quantified local risk index as the core variable driving subsequent authentication and access control.

[0059] 2. Compared to existing technologies that often statically bind authentication strength and data access scope, making it impossible to make fine adjustments based on real-time security conditions, which often sacrifices either security or user experience, this invention adopts a scheme that uses a two-dimensional decision matrix jointly determined by the local risk index and data sensitivity level to dynamically determine the authentication strength level and dynamically trims the actual data access scope based on the risk index. This scheme has the advantages of achieving fine-grained control of security policies and real-time risk adaptation, while optimizing user convenience while ensuring the security of core data.

[0060] 3. Compared with existing technologies where system modules typically have broad data access permissions, and a single module being compromised can easily lead to large-scale data leakage, the internal security boundaries of such systems are blurred and the risk spreads easily. This invention adopts a scheme that decouples system functions into independent modules and statically binds the minimum access permissions of the sub-databases to each module. Furthermore, when returning data from the cloud, each module uses its own encryption algorithm and key for encryption. This scheme has the advantages of forming strict internal security boundaries, achieving deep permission isolation, and effectively curbing the horizontal spread of security incidents within the system.

[0061] 4. Compared to existing technologies that rely mainly on predefined rules and manual intervention when processing multi-source member data, resulting in low efficiency and difficulty in guaranteeing data quality, and which lack adaptability and accuracy when facing chaotic and heterogeneous data sources, this invention adopts a solution based on deep learning models to automatically identify entities and resolve conflicts in multi-source raw data, and uses predictive models to intelligently fill in and correct missing error values. This solution has the advantages of systematically improving the automation level of data governance and the accuracy and completeness of the output data, providing a high-quality data foundation for upper-level business.

[0062] 5. Compared to existing technologies that may only focus on single-point technological improvements and lack organic connections between components, their technical effects are often isolated and difficult to cope with comprehensive challenges in complex scenarios. This invention systematically integrates multiple innovative points such as dynamic risk assessment, dynamic access control, modular isolation, and intelligent data governance, so that they work together to form an organic whole driven by real-time risk and based on data quality. This solution has the advantages of generating synergistic effects, achieving comprehensive improvement in security, availability, and data quality, and overall performance that is superior to the simple summation of individual parts. Attached Figure Description

[0063] Figure 1 The diagram shown is a schematic representation of the intelligent data management system for membership systems and authentication according to the present invention. Detailed Implementation

[0064] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0065] Please see Figure 1 The present invention provides an embodiment of an intelligent data management system for membership systems and authentication, comprising:

[0066] A dynamic risk assessment module used to collect and calculate local risk indices on user terminals.

[0067] A cloud-based authentication and access control center used to dynamically select authentication methods based on local risk indices and control the scope of data access based on indices and data sensitivity.

[0068] A modular subsystem consisting of multiple independent functional modules with a unified data interface, wherein each module is configured to access only a specified sub-database, and different modules use different encryption algorithms to communicate.

[0069] A deep learning data governance engine for intelligently reading, filling, repairing and organizing messy member data from different sources to generate standardized member data;

[0070] The cloud-based database cluster is used to store different types of member data using multiple sharded databases. When it receives a read request from a subsystem module, it verifies the module's permissions, retrieves the data from the corresponding sharded database, encrypts it using the encryption algorithm specified by the module, and then sends it.

[0071] Specifically, in this embodiment, each module is as follows:

[0072] I. Dynamic Risk Assessment Module

[0073] The specific workflow of the dynamic risk assessment module is as follows:

[0074] S11: Real-time collection of native security data on the user terminal's current environment and behavior, including data from the following dimensions:

[0075] Device security data, network security data, and user behavior data;

[0076] Among them, the collection of device security dimension data is periodic, while the collection of network security dimension data and user behavior dimension data is related to the current authentication or data access request trigger.

[0077] S12: Obtain the user's historical behavioral characteristic baseline from local secure storage, wherein the historical behavioral characteristic baseline is established and stored in the following manner:

[0078] On the user terminal, historical behavioral data of the user under a secure state is collected and statistically analyzed over a long period of time.

[0079] Historical behavior data is aggregated and analyzed to generate statistical models and threshold ranges that characterize normal user behavior patterns;

[0080] The statistical model and threshold range are used as the baseline for historical behavioral characteristics and are encrypted and stored in the local secure area of ​​the user terminal.

[0081] S13: Perform a matching degree analysis between the collected native security data and the historical behavioral feature baseline, and calculate the feature matching degree in multiple dimensions, specifically including:

[0082] S131: For each item in the native security data, find the corresponding behavior pattern or threshold in the historical behavior feature baseline;

[0083] S132: Compare the current data with the corresponding behavioral pattern or threshold to calculate the single-item matching degree;

[0084] S133: Weighted fusion of multiple individual matching scores across the three dimensions of device security, network security, and user behavior to obtain a comprehensive matching score for each dimension;

[0085] S14: The key indicators of the native security data are matched with the feature ratios of multiple dimensions and then input into a lightweight risk assessment model pre-deployed locally on the user terminal to calculate a quantitative local risk index. The calculation process includes:

[0086] The key indicators in the original security data are combined with the comprehensive matching scores of each dimension to form a feature vector;

[0087] The feature vectors are input into the gradient boosting decision tree model;

[0088] The model outputs a value between 0 and 100 as a local risk index, where a higher value indicates a higher risk assessment level.

[0089] S15: Securely report the calculated local risk index to the cloud-based risk control center.

[0090] Among them, the equipment security dimension data includes:

[0091] The device's unique fingerprint identifier; the operating system integrity verification result, used to indicate whether the device has been jailbroken, rooted, or has been tampered with; and a list of applications marked as risky from the list of applications installed on the device.

[0092] The cybersecurity dimension data includes:

[0093] The type of current network connection; the detection result of whether the current network is accessed through a proxy or virtual private network; the strength level of the encryption protocol used by the current communication channel.

[0094] User behavior data includes:

[0095] The precise timestamp of the current operation; the geographical location information when the operation was initiated; the action sequence of the current operation; and the frequency of specific operations within this session.

[0096] II. Cloud-based Authentication and Access Control Center

[0097] The specific workflow of the cloud-based authentication and access control center is as follows:

[0098] S21: Receive an access request from the user terminal, which includes the user identifier, the identifier of the data resource to be accessed, and the local risk index calculated by the user terminal;

[0099] S22: Based on the preset policy mapping rules, and according to the local risk index and the data sensitivity level corresponding to the data resource identifier, dynamically determine the authentication strength level required for the current session, specifically including:

[0100] S221: Based on the data resource identifier, query the data sensitivity classification directory to determine the data sensitivity level of the resource;

[0101] S222: Match the local risk index with multiple preset risk threshold ranges to determine the current risk level;

[0102] S223: Based on a predefined two-dimensional decision matrix consisting of data sensitivity level and current risk level, the corresponding authentication strength level is obtained by querying. The authentication strength level includes: no authentication level, simple authentication level and complex authentication level.

[0103] S23: Based on the determined authentication strength level, initiate the corresponding authentication process to the user terminal and verify the authentication result, including:

[0104] When the certification strength level is the certification-free level, the certification steps are skipped and the certification is considered successful directly.

[0105] When the authentication strength level is simple authentication level, a single authentication factor is requested from the user terminal.

[0106] When the authentication strength level is complex authentication level, at least two different types of authentication factors are requested from the user terminal.

[0107] When the authentication strength level is complex authentication level, the requested combination of authentication factors must include at least: a time-based one-time password and a liveness detection based on the user's biometrics.

[0108] S24: Based on successful authentication, and according to the local risk index and data resource identifier, the access control policy engine calculates the actual data range that the current session is allowed to access. The actual data range is a subset of the requested data resources, specifically including:

[0109] S241: Based on the data resource identifier, obtain the complete set of associated data fields;

[0110] S242: Based on the local risk index, query the dynamic data access blocking rule table to determine the data field types or sensitivity tag sets that are prohibited from access under the current risk index;

[0111] S243: From the complete set of data fields, remove all data field types that are prohibited from access and fields with prohibited sensitivity labels to form the actual data range;

[0112] S25: Process the access request based on the determined actual data range: if the range is not empty, allow access and return the data within the range; if the range is empty, reject the access request.

[0113] The dynamic data access interception rule table defines the mapping relationship between the local risk index and the data sensitivity labels that are prohibited from access. The higher the local risk index, the higher the level and the wider the range of the data sensitivity labels that are prohibited from access.

[0114] The dynamic data access interception rule table includes the following policies:

[0115] A11: When the local risk index is below the first threshold, no data fields with sensitivity labels are prohibited;

[0116] A12: Access to core privacy data is prohibited when the local risk index is between the first and second thresholds;

[0117] A13: When the local risk index is higher than the second threshold, in addition to prohibiting access to core privacy data, access to transaction records and account asset data will be further prohibited.

[0118] When processing access requests based on the determined actual data range, if access is permitted, the following further applies:

[0119] S251: Based on the user identifier and data resource identifier, determine the backend functional module authorized to process the request;

[0120] S252: Retrieve data from the cloud-based sharded database within a defined actual data range;

[0121] S253: Encrypt the acquired data using a dedicated key assigned to a specific backend functional module;

[0122] S254: Return the encrypted data to the user terminal, or forward it directly to the backend functional module.

[0123] III. Modular Subsystem

[0124] The modular subsystem is constructed and operates as follows:

[0125] S31: System construction involves breaking down the overall business functionality into multiple functionally independent business modules, and defining standardized data request interfaces and data formats for each module to form a modular subsystem. This includes:

[0126] S311: Decouple the functions of the complete membership management system and encapsulate them into multiple independently deployable business modules. These business modules include: an authentication module responsible for identity verification, a membership account module responsible for managing basic information, a transaction processing module responsible for handling payment and points changes, and a marketing analysis module responsible for user profiling and marketing.

[0127] S312: Define a unified data request interface specification for all business modules, including request header format, authentication method, resource identification method, and response format;

[0128] S32: Module registration and binding. A unique identifier is created for each business module registered in the cloud, and a clear data access permission mapping is assigned to it. This mapping restricts the one or more specific database shards that this module is allowed to access, specifically including:

[0129] S321: When a new business module is connected to the system, it is registered in the cloud center management system. The cloud generates a globally unique module identifier for the module and generates a pair of asymmetric encryption keys for it. The public key is stored in the cloud, and the private key is securely distributed and stored in the business module.

[0130] S322: In the cloud-based permission configuration center, configure the list of databases that the module identifier is allowed to access. The database list points to the specific database shards in the cloud database cluster.

[0131] S323: In the cloud-based encryption policy center, specify an encryption algorithm and corresponding encryption key for the module identifier, which is used for encryption operations when the cloud returns data to the module;

[0132] S33: Request Reception and Authentication. Receives encrypted data requests from business modules, verifies the identity and legitimacy of the requesting module and its access rights to the target database, specifically including:

[0133] S331: Receive a data request from a business module and sign the request digest containing the module identifier, timestamp, target database identifier, and operation type using the private key of the requesting module;

[0134] S332: Verify the validity of the digital signature and the freshness of the timestamp of the request;

[0135] S333: Based on the module identifier in the request, query its data access permissions in the permission configuration center;

[0136] S334: Determine whether the target database identifier in the request is in the list of databases that the module is allowed to access. If not, reject the request.

[0137] S34: Secure Data Acquisition and Return. After successful authorization verification, plaintext data is extracted from the target database shard. The data is then encrypted using the proprietary encryption algorithm and key corresponding to the request module. Finally, the encrypted data is returned to the request module. This includes:

[0138] S341: Based on the request, retrieve the required plaintext data from the corresponding sub-database;

[0139] S342: Based on the module identifier that made the request, obtain the encryption algorithm and key specified for the module from the encryption policy center;

[0140] S343: Use an encryption algorithm and key to encrypt the retrieved plaintext data and generate a ciphertext data payload;

[0141] S344: Encapsulate the encrypted data payload in a standard response format and return it to the requesting business module, which then decrypts it using the decryption key it holds.

[0142] Specifically, when configuring the list of databases that a module identifier is allowed to access, the configured permission mapping relationship is static and minimal, which prevents a business module from accessing a shard database that is unrelated to its function, and the access permissions of multiple business modules to the same shard database are independent of each other.

[0143] Different business modules are assigned different encryption algorithms, including using different algorithm types and different keys.

[0144] Based on this, the data request process for the cloud database cluster processing module is as follows:

[0145] S41: Receive a digital signature data request from a subsystem functional module. The request includes at least a module identifier, a request operation type, a target database identifier, and a timestamp. The digital signature is generated by signing the request digest consisting of the module identifier, the request operation type, the target database identifier, and the timestamp using the private key of the requesting module.

[0146] S42: Verify the validity of the digital signature and the freshness of the request, specifically including:

[0147] The digital signature is verified using the public key corresponding to the module identifier to confirm the integrity and authenticity of the request.

[0148] Verify whether the difference between the timestamp in the request and the server's current time is within a preset valid time window to defend against replay attacks;

[0149] If the digital signature is invalid or the request has expired, the processing flow will be terminated and an authentication error message will be returned to the request module. Subsequent permission verification and data extraction steps will not be executed.

[0150] S43: After the signature and freshness verification pass, query the predefined permission mapping table based on the module identifier to verify whether the module has the right to perform the requested operation type on the database specified by the target database identifier, specifically:

[0151] Query the permission mapping table, which records a list of one or more database identifiers that each module identifier is authorized to access and their corresponding operation permissions;

[0152] Determine whether the target database identifier in the request exists in the list of database identifiers authorized for the requesting module, and whether the request operation type is within the scope of its authorized operation permissions;

[0153] S44: After the permission verification is successful, retrieve and extract the plaintext data result set from the database sub-database corresponding to the target database identifier according to the request;

[0154] S45: Based on the module identifier that initiated the request, retrieve the proprietary encryption algorithm and key pre-configured for this module from the encryption policy library, specifically:

[0155] The encryption policy library stores the mapping relationship between module identifiers and encryption configurations, which include algorithm type, key identifier or key value;

[0156] Using the module identifier as an index, the corresponding encryption algorithm type and key material can be retrieved from the encryption policy library;

[0157] S46: Use a proprietary encryption algorithm and key to encrypt the plaintext data result set, generate a ciphertext payload, and return a response containing the ciphertext payload to the subsystem function module that initiated the request.

[0158] IV. Deep Learning Data Governance Engine

[0159] The workflow of a deep learning data governance engine is as follows:

[0160] S51: Receive raw member data in real time or in batches from multiple heterogeneous data sources. The raw member data includes structured, semi-structured, and unstructured data.

[0161] S52: Utilize a trained deep learning model to automatically parse the raw member data, identify and extract predefined member entity fields, specifically including:

[0162] S521: For unstructured and semi-structured text data, a Transformer-based named entity recognition model is used to identify and extract member names, phone numbers, addresses, and email addresses.

[0163] S522: For image or scanned document data, convert it into text using optical character recognition technology before processing;

[0164] S523: For structured data, perform field mapping and preliminary format cleaning directly;

[0165] S524: Organize all extracted entity fields into a temporary member record;

[0166] S53: Compare multiple records extracted from different data sources that point to the same member entity, detect field conflicts, and generate a consistent merged record according to predefined conflict resolution rules. Specifically, this includes:

[0167] S531: Based on core identifiers including member ID, mobile phone number and ID card number, temporary member records from different data sources are associated and clustered to form a set of records pointing to the same real member.

[0168] S532: Within the same record set, compare the values ​​of the same field in records from different sources;

[0169] S533: When there are multiple different values ​​for the same field, a final value is selected according to the predefined conflict resolution rules. The conflict resolution rules take into account the credibility weight of the data source, the freshness of the data, and the frequency of the value in the set.

[0170] S54: For missing or obvious errors in merged records, the predictive model is invoked for intelligent filling and correction, generating complete and accurate member profile data, specifically including:

[0171] S541: Identify missing fields in required or business-critical fields in the processed merged records;

[0172] S542: Based on the existing complete fields, use clustering algorithms to find member groups in the entire member database that are similar to the current member's behavioral characteristics and demographic attributes;

[0173] S543: Based on the value distribution of similar member groups on the missing field, calculate the most likely filler value through a prediction model. The prediction model includes, but is not limited to, the K-nearest neighbor algorithm, classification or regression model.

[0174] S544: Apply business rules to fields such as numeric and date data for validation. For erroneous values ​​that clearly exceed the reasonable range, call the context-based correction model to correct them.

[0175] S55: Format the processed member profile data according to the target system's standard data model and write it into the corresponding sub-database of the main member database. Specifically, this includes:

[0176] S551: Convert all field values ​​to the format, unit, and encoding defined by the target data model;

[0177] S552: Label each field with its data source, processing history, and confidence score;

[0178] S553: ​​Write the standardized complete member profile data into the corresponding sub-database of the member master database according to its data type and sensitivity.

[0179] The conflict resolution rules employ a weighted voting mechanism, in which:

[0180] Predefine a static base credibility weight for each data source;

[0181] Calculate the dynamic freshness coefficient by combining the timestamps of the data records;

[0182] For a conflicting field, the final score for each candidate value is the sum of the products of the data source credibility weight and the freshness coefficient of all records that provide that value;

[0183] The candidate value with the highest final score is selected as the resolved value for this field.

[0184] V. Cloud Database Cluster

[0185] The sharded databases in the cloud database cluster include:

[0186] The core privacy information database is used to store ID card numbers and biometric information;

[0187] The member account information database is used to store basic identity information and contact details;

[0188] The transaction log database is used to store records of spending, top-ups, and points changes.

[0189] A behavior log library used to store user action and activity logs.

[0190] Example 1:

[0191] This example demonstrates how a system can provide a secure and seamless cross-business service to a VIP member, using a group that owns shopping malls, hotels, office buildings, and residential properties as an example.

[0192] Scene trigger

[0193] Mr. Zhang, a member, drove to the group's shopping mall. He opened the group's membership mini-program, intending to use his membership points to pay for parking and book the hotel's executive lounge.

[0194] System operation process

[0195] Mr. Zhang's mobile device first activated the dynamic risk assessment module, collecting real-time data on its device security status, the currently connected public Wi-Fi network in the mall, and his operational behavior. This data was then compared with a baseline of historical behavioral characteristics stored locally on the phone. Except for the network environment changing from the usual 4G / 5G to public Wi-Fi, the matching degree across all other dimensions was very high. After comprehensive calculation by the lightweight risk assessment model, a low local risk index of only 15 points (out of 100) was generated and securely reported to the cloud.

[0196] The cloud-based authentication and access control center received a request containing the user's identifier, the requested points balance and hotel booking status (marked as "low-sensitivity" data), and a low-risk index. Based on a pre-defined two-dimensional decision matrix, the system determined that the authentication strength required for this session was "simple authentication," requiring Mr. Zhang to quickly complete authentication via his mobile phone fingerprint recognition. Furthermore, due to the very low risk index, dynamic access control rules allowed him to access all requested data fields.

[0197] Next, the system enters the modular subsystem collaborative operation phase. User point redemption requests are handled by the transaction processing module, which is strictly limited to accessing only the transaction record database. It initiates a data request with a digital signature to the cloud database cluster. After verifying its signature and permissions, the cloud retrieves the plaintext point data from the transaction record database, encrypts it using an AES-256 algorithm and key specifically configured for this module, and then returns it. Similarly, requests to book hotel executive lounges are handled by the membership account module, whose permissions are limited to accessing the membership account information database, and it uses a different encryption algorithm (such as the SM4 algorithm) to retrieve the data.

[0198] Throughout the process, the deep learning data governance engine runs continuously in the background. Through named entity recognition technology, it associates Mr. Zhang's license plate number, which he may have registered in the hotel system, with his dining preferences, which he filled out in the shopping mall, with his unique membership identity based on core identifiers (such as his mobile phone number). It also automatically resolves potential field conflicts (such as inconsistent email addresses stored through different channels), providing the front-end business modules with a complete, accurate, and unified member profile.

[0199] Example 2:

[0200] This example uses a medical and health management organization where a researcher needs to access a batch of anonymous health data in a different location using a new device for research and analysis.

[0201] Scene trigger

[0202] Researcher Dr. Li, at home, used his newly issued laptop to log into the institution's research data platform via a browser to download a dataset containing anonymized health records for analysis.

[0203] System operation process

[0204] The dynamic risk assessment module on Dr. Li's computer immediately began working. It detected that the device was newly activated, lacked a trusted historical fingerprint, logged in at 2 AM (anomaly), and requested to download bulk data directly from a remote home network via VPN (high-risk behavior). These indicators deviated significantly from Dr. Li's historical baseline, which typically worked on a fixed device in the office. The risk assessment model therefore calculated a high local risk index, reaching 75 points.

[0205] Upon receiving the request, the cloud-based authentication and access control center identified the target data as "core privacy data," indicating an extremely high level of sensitivity. Based on a high-risk index, the system determined that the highest level of "complex authentication" was required. Dr. Li not only needed to enter his account password but also had to use an authenticator app to obtain a time-based one-time password and complete a facial recognition liveness detection. Even after successful authentication, because the high-risk index exceeded the security threshold, dynamic data access blocking rules were activated, prohibiting Dr. Li from directly accessing the original anonymized health records. However, the system did not completely reject the request but instead implemented granular access control, allowing him to access aggregated analysis results generated from this data (such as statistical reports and trend charts). These derived data do not contain individually identifiable information.

[0206] Dr. Li's request was handled by the backend marketing analytics module (which also functions as a data analysis module in this scenario). This module's permissions were set to only allow access to the anonymized behavior log library or a specific analysis results library. When it attempted to request the core privacy information library, the cloud database cluster denied it unauthorized access. The system then executed a backup plan, extracting relevant data from the behavior log library, generating aggregated results, and encrypting the results using the SM4 encryption algorithm and key specified by the module before returning them.

[0207] At the data level, the deep learning data governance engine first performs intelligent cleaning and standardization when processing raw medical and health data, such as standardizing date formats and completing missing codes. Then, it uses algorithms like clustering to rigorously anonymize the data, generating a standard dataset that meets research requirements, ensuring data usability and protecting personal privacy. All of this processing history and data confidence levels are recorded, guaranteeing the transparency and reliability of the data governance process.

[0208] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. An intelligent data management system for membership system and certification, characterized in that: Comprise: a dynamic risk assessment module for collecting and calculating a local risk index locally at the user terminal; a cloud authentication and access control center for dynamically selecting an authentication method according to the local risk index and controlling the data access range according to the index and the data sensitivity; a modular subsystem composed of multiple independent functional modules with a unified data interface, wherein each module is configured to access only a specified sub-database, and different modules use different encryption algorithms for communication; a deep learning data governance engine for intelligently reading, filling, repairing and arranging chaotic member data from different sources to generate standardized member data; a cloud database cluster for storing different types of member data using multiple sub-database databases, verifying module permissions and retrieving data from the corresponding sub-database database when receiving a reading request from the subsystem module, and then sending the data after encryption using the module specified encryption algorithm.

2. The intelligent data management system for membership and certification as claimed in claim 1, wherein: The specific workflow of the dynamic risk assessment module is: S11: Real-time collection of native security data of the current environment and behavior of the user terminal; S12: Obtain the historical behavior characteristic baseline of the user from the local security storage; S13: Perform matching degree analysis on the collected native security data and the historical behavior characteristic baseline, and calculate the feature matching degree of multiple dimensions; S14: Input the key indicators of the native security data and the feature matching degree of multiple dimensions into the lightweight risk assessment model pre-deployed locally on the user terminal to calculate a quantitative local risk index; S15: Safely report the calculated local risk index to the cloud risk control center.

3. The intelligent data management system for membership and certification as claimed in claim 2, wherein: The specific workflow of the cloud authentication and access control center is: S21: Receive an access request from the user terminal, including user identification, data resource identification to be accessed, and a local risk index calculated by the user terminal; S22: According to the preset strategy mapping rule, based on the local risk index and the data sensitivity level corresponding to the data resource identification, dynamically determine the authentication strength level required for the current session; S23: According to the determined authentication strength level, initiate the corresponding authentication process to the user terminal, and verify the authentication result; S24: On the basis of successful authentication, according to the local risk index and the data resource identification, calculate the actual data range allowed to be accessed in the current session through the access control strategy engine, wherein the actual data range is a subset of the requested data resource; S25: According to the determined actual data range, process the access request: if the range is not empty, allow access and return the data in the range; if the range is empty, reject the access request.

4. The intelligent data management system for membership hierarchy and certification as claimed in claim 3 wherein: The dynamic data access interception rule table contains the following strategies: A11: When the local risk index is below the first threshold, no data field with any sensitivity label is prohibited; A12: When the local risk index is between the first threshold and the second threshold, access to core privacy data is prohibited; A13: When the local risk index is higher than the second threshold, in addition to prohibiting access to core privacy data, further prohibiting access to transaction records and account asset data.

5. The intelligent data management system for membership hierarchy and certification as claimed in claim 4 wherein: The construction and working mode of the modular subsystem is: S31: System construction, the overall business function is split into multiple functionally independent business modules, and a standardized data request interface and data format are defined for each business module to form a modular subsystem; S32: Module registration and binding, a unique identity is created for each business module registered in the cloud, and a clear data access permission mapping relationship is assigned to it, which limits the module to access one or more specific sub-database databases; S33: Request receiving and authentication, receiving encrypted data requests from business modules, verifying the legitimacy of the request module and its access permissions to the target database; S34: Data security acquisition and return, after permission verification, extract the plaintext data from the target sub-database, and use the exclusive encryption algorithm and key corresponding to the request module to encrypt the data, then return the encrypted data to the request module.

6. The intelligent data management system for membership hierarchy and certification as claimed in claim 5 wherein: The system construction step specifically includes: S311: Decouple the functions of the complete membership management system and encapsulate them into multiple independently deployable business modules, wherein the business modules include: an authentication module responsible for identity verification, a member account module responsible for managing basic information, a transaction processing module responsible for handling payments and point changes, and a marketing analysis module responsible for user profiling and marketing; S312: Define a unified data request interface specification for all business modules, including request header format, authentication method, resource identification method, and response format.

7. The intelligent data management system for membership hierarchy and certification as claimed in claim 6 wherein: The process of the cloud database cluster processing module data request is: S41: Receive digital signature data requests from subsystem function modules, the request at least includes module identifier, request operation type, target database identifier and timestamp; S42: Verify the validity of the digital signature and the freshness of the request; S43: After the signature and freshness verification, query the pre-defined permission mapping table according to the module identifier to verify whether the module has the right to perform the request operation type on the database specified by the target database identifier; S44: After permission verification, retrieve and extract the plaintext data result set from the sub-database corresponding to the target database identifier according to the request; S45: According to the module identifier of the request initiator, obtain the exclusive encryption algorithm and key pre-configured for the module from the encryption strategy library; S46: Use the exclusive encryption algorithm and key to encrypt the plaintext data result set, generate the ciphertext payload, and return the response containing the ciphertext payload to the subsystem function module that initiated the request.

8. The intelligent data management system for membership hierarchy and certification as claimed in claim 7, wherein: Verifying whether the module has the right to perform the request operation type on the target database specifically includes: Query the permission mapping table, which records the list of one or more database identifiers that each module identifier is authorized to access and the corresponding operation permissions; Determine whether the target database identifier in the request exists in the database identifier list authorized for the request module, and whether the request operation type is within the scope of its authorized operation permissions.

9. The intelligent data management system for membership hierarchy and certification as claimed in claim 8, wherein: The sub-database database includes: Core private information database for storing identity card numbers and biometric information; Member account information database for storing basic identity information and contact information; Transaction record database for storing consumption, recharge, and point change records; A behavior log library is configured to store user operation and activity logs.

10. The intelligent data management system for membership hierarchy and certification as claimed in claim 9, wherein: The deep learning data governance engine comprises the following steps when working: S51: Real-time or batch receiving original member data from multiple heterogeneous data sources, the original member data including structured, semi-structured and unstructured data; S52: Using a trained deep learning model to automatically analyze the original member data, identify and extract predefined member entity fields; S53: Comparing multiple records extracted from different data sources and pointing to the same member entity, detecting field conflicts, and generating consistent merged records according to predefined conflict resolution rules; S54: For the missing fields or obvious errors in the merged records, calling the prediction model for intelligent filling and correction to generate complete and accurate member portrait data; S55: Formatting the processed member portrait data according to the standard data model of the target system, and writing it into the corresponding sub-database of the member master database.

Images