Data processing method and device, equipment and storage medium

Abstract

The invention provides a data processing method and device, equipment and a storage medium, and relates to the field of block chains. The method comprises the following steps: acquiring bank product resources, a bank product resource acquisition request of a target user and user information of the target user from a block chain; and determining user permission groups of the target user according to the user information, wherein different user permission groups correspond to different bank product resources. And under the condition that the bank product resource acquisition request passes qualification verification, allocating target bank product resources to the target users according to the user permission groups. And when the time condition of the bank product right resource is satisfied, determining a target bank product resource corresponding to the bank product right resource and user information of a target user corresponding to the target bank product resource, and issuing the bank product right resource and the target bank product resource in the block chain. According to the method provided by the invention, the distribution efficiency of bank product resources in the block chain is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain, and more particularly to a data processing method, apparatus, device, and storage medium. Background Technology

[0002] In today's rapidly developing digital age, banking products and services, as a type of financial activity closely related to socio-economic life, are undergoing profound changes in their operating models. With the popularization of internet technology, banking products and services are gradually expanding from traditional offline models to online platforms to attract more users and broaden service coverage. Blockchain technology, with its decentralized, immutable, and traceable characteristics, provides a more secure and reliable technical guarantee for online banking products and services. Currently, some banking product management methods incorporate blockchain technology to achieve security. This involves receiving requests for banking product resources from terminal devices, verifying them, generating transaction information, and writing it into the blockchain to complete the banking product and service transaction.

[0003] However, while existing blockchain-based methods for allocating banking product resources can ensure the security and immutability of transaction information, they lack an efficient and intelligent allocation mechanism. When faced with a large number of users simultaneously applying for banking products, it is difficult to quickly and accurately allocate resources according to established rules. This results in a cumbersome and time-consuming allocation process, failing to meet user needs in a timely manner and severely impacting the overall operational efficiency and user experience of banking products and services.

[0004] Therefore, improving the efficiency of bank product resource allocation in blockchain is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and storage medium to solve the technical problem of low allocation efficiency of bank product resources in current blockchain applications.

[0006] Firstly, this application provides a data processing method, including:

[0007] Obtain bank product resources from the blockchain, the target user's bank product resource acquisition request, and the target user's user information;

[0008] Based on the user information, the user permission group of the target user is determined, and different user permission groups correspond to different bank product resources;

[0009] If the request to acquire bank product resources passes the qualification verification, the target bank product resources will be allocated to the target user according to the user permission group.

[0010] When the time conditions for bank product rights and resources are met, the target bank product resources corresponding to the bank product rights and resources, as well as the user information of the target users corresponding to the target bank product resources, are determined, and the bank product rights and resources and the target bank product resources are published in the blockchain.

[0011] Optionally, the step of allocating target bank product resources to the target user based on the user permission group includes:

[0012] Determine the candidate bank product resources corresponding to the user permission groups;

[0013] Generate a random number for resource allocation in the bank product resource acquisition request;

[0014] Based on the resource allocation random number, the target bank product resources are allocated to the target user from the candidate bank product resources.

[0015] Optionally, the step of allocating the target bank product resource to the target user from the candidate bank product resources based on the resource allocation random number includes:

[0016] The resource allocation weight of the target user is determined based on the attribute information corresponding to the bank product resource acquisition request. The attribute information includes at least one of the following: storage duration of the bank product resource acquisition request, request time, on-chain time, and the target user's activity level.

[0017] Based on the resource allocation random number and the resource allocation weight, the target bank product resources are allocated to the target user from the candidate bank product resources.

[0018] Optionally, determining the user permission group for the target user based on the user information includes:

[0019] Based on the user information, obtain the target user's historical bank product smart contracts;

[0020] If the smart contract of the historical banking product corresponds to at least two alliance parties, then obtain at least two user permission levels of the target user from the at least two alliance parties;

[0021] Based on the at least two user permission levels, determine the user permission grouping of the target user.

[0022] Optionally, determining the user permission grouping of the target user based on the at least two user permission levels includes:

[0023] The user permission grouping of the target user is determined based on the highest user permission level among the at least two user permission levels.

[0024] Optional, also includes:

[0025] Obtain updated information on the target user's user behavior, including transaction behavior and application behavior;

[0026] Based on the updated information, update the user permission grouping of the target user.

[0027] Optionally, the bank product resource acquisition request and the target user's user information are stored in an off-chain distributed file system corresponding to the blockchain;

[0028] The hash value and storage address of the file storing the bank's product resource acquisition request and the target user's user information in the distributed file system are stored in the blockchain.

[0029] Optionally, the distributed file system is the InterPlanetary File System (IPFS).

[0030] Optionally, the request for obtaining bank product resources is encrypted and stored by overlaying a digital signature;

[0031] And / or,

[0032] The user information is stored after being encrypted or anonymized using an encryption algorithm.

[0033] Secondly, this application provides a data processing apparatus, comprising:

[0034] The acquisition module is used to acquire bank product resources, the target user's bank product resource acquisition request, and the target user's user information from the blockchain;

[0035] The first processing module is used to determine the user permission group of the target user based on the user information, and different user permission groups correspond to different bank product resources.

[0036] The second processing module is used to allocate target bank product resources to the target user according to the user permission group when the bank product resource acquisition request passes the qualification verification.

[0037] The control module is used to determine the target bank product resource corresponding to the bank product rights and interests resource, and the user information of the target user corresponding to the target bank product resource, when the time conditions of the bank product rights and interests resource are met, and publish the bank product rights and interests resource and the target bank product resource in the blockchain.

[0038] Thirdly, this application provides an electronic device, including: a processor and a memory; the processor and the memory are communicatively connected.

[0039] The memory stores computer-executed instructions;

[0040] The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0041] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the data processing method as described in any one of the first aspects.

[0042] Fifthly, this application provides a computer program product, which, when executed by a processor, is used to implement the data processing method as described in any one of the first aspects.

[0043] The data processing method, apparatus, equipment, and storage medium provided in this application obtain bank product resources, target user's bank product resource acquisition requests, and target user's user information from the blockchain. Based on the user information, the method determines the target user's user permission group. If the bank product resource acquisition request passes qualification verification, the method allocates target bank product resources to the target user according to the user permission group. When the time conditions for bank product rights and resources are met, the method determines the target bank product resources corresponding to the bank product rights and resources, as well as the user information of the target user corresponding to the target bank product resources, and publishes the bank product rights and resources and the target bank product resources on the blockchain. This method improves the efficiency of bank product resource allocation in the blockchain by grouping users to be allocated bank product resources and allocating different bank product resources to different groups. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] Figure 1 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0046] Figure 2 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0047] Figure 3 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0048] Figure 4 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0050] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0051] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0053] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0054] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0055] It should be noted that the data processing method, apparatus, equipment and storage medium provided in this application can be used in the blockchain field, or in any field other than the blockchain field. The application field of the data processing method, apparatus, equipment and storage medium in this application is not limited.

[0056] In the existing blockchain-based allocation of bank product resources, although blockchain technology, with its distributed ledger, encryption algorithms and other characteristics, can effectively guarantee the security and immutability of transaction information and build a solid security defense for bank product transactions, it has exposed obvious shortcomings in the allocation of bank product resources.

[0057] Currently, common bank product resource allocation mechanisms primarily rely on a combination of traditional centralized logic and blockchain storage. Specifically, once a user initiates a request to obtain a bank product and passes verification, the relevant transaction information is recorded on the blockchain. However, in the subsequent resource allocation phase, the system often employs a relatively simple, rule-based sequential processing method. For example, it might sort users according to the order in which they applied for bank products, or filter them based on fixed rules regarding product numbers, thereby determining which users are eligible to obtain the products.

[0058] When faced with a large number of users simultaneously applying for bank products, it is necessary to process each user's application information one by one, comparing and filtering according to established rules. Due to the large number of users and the dramatic increase in data volume, a significant amount of computing resources are required to process this data, resulting in slower processing speeds and inefficient allocation of bank product resources.

[0059] In view of this, embodiments of this application provide a data processing method that obtains bank product resources, target user's bank product resource acquisition requests, and target user's user information from a blockchain. Based on the user information, the method determines the target user's user permission group. If the bank product resource acquisition request passes qualification verification, the method allocates target bank product resources to the target user according to the user permission group. When the time conditions for bank product rights and resources are met, the method determines the target bank product resources corresponding to those resources, as well as the user information of the target user corresponding to those resources, and publishes the bank product rights and resources and the target bank product resources on the blockchain. This method improves the efficiency of bank product resource allocation in the blockchain by grouping users to be allocated bank product resources and allocating different bank product resources to different groups.

[0060] The data processing method provided in this application can be executed by, for example, a resource allocation platform for bank products, or an electronic device serving as a resource allocation platform, such as a bank's server or database. Alternatively, the executing entity can be hardware with computing capabilities, such as chips within these electronic devices. When the executing entity is an electronic device, a computer program for executing the data processing method can be deployed on the electronic device, thereby efficiently allocating bank product resources.

[0061] Figure 1 This is a flowchart illustrating a data processing method provided in an embodiment of this application. Figure 1 As shown, the method may include:

[0062] S101. Obtain bank product resources from the blockchain, the target user's bank product resource acquisition request, and the target user's user information.

[0063] In this embodiment, the blockchain, as a decentralized distributed ledger, has a unique structure and characteristics for data storage. Bank product resources are stored on the blockchain in a structured manner, consisting of multiple features across different dimensions, such as bank product information. For example, bank product resources can include product type features, such as different types of exclusive deposit products, limited-edition commemorative certificates of deposit, and special service benefits; they can also include product rule features, such as minimum deposit amount, service period, and conditions for obtaining benefits; and product validity period features. These features combine to form a dataset of bank product resources.

[0064] A target user's request to acquire bank product resources is a collection of various information, such as a bank product application request. This request can explicitly express the type of product the user desires, which corresponds to the type characteristics in the bank's product resources to identify the specific product the user wants. The request can also include quantity characteristics, indicating the share or quantity of products the user wishes to acquire. Furthermore, the request can carry a time characteristic, recording the specific moment the user initiated the request, which is crucial for subsequent resource allocation and eligibility verification.

[0065] The target user's information includes their identifier (e.g., account number, name), age, contact information, account status, and user permissions. The identifier is used to distinguish different users within the blockchain, and user permissions are used to determine subsequent user permission groups. This user information can be retrieved from the target user's account registration information or carried in the bank's product resource acquisition request (e.g., the target user filled in their user information in the bank's product resource acquisition request).

[0066] Optionally, the target user's information can be stored after being encrypted or anonymized using an encryption algorithm. Encryption algorithms can be, for example, symmetric or asymmetric encryption algorithms, to encrypt the target user's sensitive information, allowing only authorized individuals to decrypt and view it. Anonymization, on the other hand, obscures the target user's identity information, retaining only necessary non-sensitive information, thereby protecting the target user's privacy.

[0067] A request to acquire bank product resources can be a request sent by a target user to a bank's server. This request can be encrypted by overlaying a digital signature (such as a private key signature) before being sent, and then stored encrypted on the blockchain. The digital signature ensures the authenticity and integrity of the request, preventing tampering with the request information.

[0068] Optionally, in this embodiment, the bank product resource acquisition request and the target user's user information can be stored in an off-chain distributed file system corresponding to the blockchain, such as the InterPlanetary File System (IPFS). This storage method can reduce the storage burden on the blockchain and improve data storage efficiency. The hash value and storage address of the file storing the bank product resource acquisition request and the target user's user information in the distributed file system are stored in the blockchain. This allows the corresponding file to be retrieved from the distributed file system when needed using the hash value and storage address on the blockchain.

[0069] Specifically, the query mechanism of blockchain can be used to obtain bank product resources, target user's bank product resource acquisition requests, and target user information from the blockchain. For example, this can be obtained through the query interface provided by the blockchain, which can locate and retrieve data based on different data identifiers.

[0070] For bank product resources, the first step is to determine their storage location on the blockchain. Since blockchain is a distributed storage system, bank product resources may be scattered across multiple nodes. The corresponding storage node can be found in the blockchain's indexing system using the globally unique identifier of the bank product resource, such as a specific hash value or number, and the bank product resource can then be retrieved from that node.

[0071] For a target user's request to acquire bank product resources and their user information, the hash value and storage address of the file storing the request and information can be determined in the blockchain using the corresponding user identifier. Based on this hash value and storage address, the request and information can then be retrieved from IPFS. Optionally, the target user's identifier can be verified first to ensure its legitimacy and authenticity. After successful verification, the corresponding information can then be retrieved from IPFS based on the target user's identifier.

[0072] S102. Determine the user permission grouping of the target user based on the user information.

[0073] In order to meet the needs of different users and manage resources, users can be classified according to their characteristics and behaviors, and user permission groups for target users can be determined. Different user permission groups correspond to different bank product resources.

[0074] When determining user permission groups, the target user's historical banking product smart contracts can be retrieved based on user information. These historical banking product smart contracts are agreements signed by the target user during past participation in banking product-related activities, recording the target user's historical behavior and rights. Smart contracts exist on the blockchain in the form of code and are characterized by automatic execution and immutability. Using the target user's user information (e.g., based on the user identifier in the user information), the target user's historical banking product smart contracts can be found in the blockchain's smart contract database. The smart contract database stores smart contract information for all users and can be categorized and stored according to user identifiers and contract signing times.

[0075] Specifically, based on the target user's historical banking product smart contracts, one or more alliance parties corresponding to the historical banking product smart contracts can be identified. Then, based on the target user's user permission level in those one or more alliance parties, the target user's user permission group can be determined.

[0076] In this context, alliance partners are different organizations or institutions involved in banking product-related businesses, such as different branches of a bank or partner financial institutions. Each alliance partner has its own user access control system. Different alliance partners may assign different access levels to users based on their behavior and contributions on the platform. For example, one alliance partner might determine a user's access level based on their deposit amount on the platform, with higher deposit amounts resulting in higher access levels; another alliance partner might determine access levels based on the frequency of a user's product participation, and so on.

[0077] For example, if the target user's historical banking product smart contract corresponds to only one consortium partner, then the target user's user permission group is determined based on the target user's user permission level within that consortium partner. If the target user's historical banking product smart contract corresponds to multiple consortium partners, then the target user's user permission group can be determined comprehensively based on the target user's user permission levels within those multiple consortium partners.

[0078] In this step, user permission levels can be obtained through data interaction with various consortium members. For example, cross-chain communication technology of blockchain can be used to send query requests to the systems of each consortium member. Each consortium member's system looks up the corresponding permission level information in its own user permission database based on the user's identity identifier and returns the result to the system.

[0079] Different user permission groups correspond to different bank product resources. For example, users in the high-permission group have access to a wider range of limited products, while users in the low-permission group have access to a smaller range of products. The correspondence between user permission groups and bank product resources can be pre-defined and stored in a configuration file or database. By querying the configuration file or database, the specific bank product resources corresponding to each user permission group can be determined.

[0080] S103. If the request to obtain bank product resources passes the qualification verification, the target bank product resources are allocated to the target users according to their user permissions.

[0081] In this context, qualification verification is used to ensure that the target user has the right to access the requested banking product resources. Qualification verification may include checks on the legality of the request for access to banking product resources and the matching of user permissions.

[0082] The legality check for requests to obtain bank product resources includes verifying the correctness of the request format and the completeness and authenticity of the information contained within. For example, it might check whether the type and quantity of products requested in the request comply with regulations, and whether the request is made within the product application's validity period. If the request format is incorrect or the information is incomplete, the request can be deemed illegal and rejected.

[0083] For user permission matching checks, user permission groups can be compared with the requested bank product resources. Different bank product resources correspond to different permission requirements. If a user's permission group does not meet the permission requirements of a bank product resource, the request to obtain that bank product resource can be rejected. For example, a certain limited-edition commemorative certificate of deposit requires the user to belong to the high-level permission group. If the target user belongs to the medium-level permission group, then the target user's request to obtain the bank product resource will fail the permission matching check.

[0084] Once the request to acquire bank product resources passes the qualification verification, the target bank product resources can be allocated to the target users based on their user permissions.

[0085] S104. When the time conditions for bank product equity resources are met, determine the target bank product resources corresponding to the bank product equity resources, as well as the user information of the target users corresponding to the target bank product resources, and publish the bank product equity resources and target bank product resources in the blockchain.

[0086] Among them, bank product equity resources are the rights and interests corresponding to bank products, such as exclusive returns upon product maturity, additional service rights, and redemption rights. The target bank product resources corresponding to the bank product equity resources are the bank product resources that generate the rights and interests. The time conditions for bank product equity resources are the pre-set rights and interests realization time, such as a specific date, a product cycle node, or the achievement of certain event triggering conditions (such as the completion of product share allocation).

[0087] When the time conditions for obtaining bank product rights and resources are met, the user information of the target user corresponding to the target bank product resource can be identified. For example, the unique identifier of the target bank product resource can be used to search for the target user who acquired or holds the target bank product resource in the blockchain's transaction record database. The transaction record database records all transaction information for bank product resources, including the identity of the acquirer, transaction time, etc. By locating the corresponding transaction record based on the identifier of the target bank product resource, the identity of the target user can be obtained. Then, the user's detailed user information can be searched in the blockchain's user information database using the user's identity.

[0088] Finally, the bank product rights and resources, as well as the target bank product resources, are published on the blockchain. Blockchain's characteristics of transparency and immutability ensure the authenticity and fairness of the information. During publication, the information regarding the bank product rights and resources, and the target bank product resources, can be encrypted to protect sensitive information. Simultaneously, a unique hash value can be generated for each published bank product rights and resources, and the storage location of this hash value, along with the storage location of the bank product rights and resources, is recorded on the blockchain. Other users can obtain detailed information about the bank product rights and resources, and the target bank product resources, by querying the hash value and storage location on the blockchain.

[0089] Optionally, user information of target users corresponding to the target bank's product resources can be published on the blockchain to ensure transparency for rights holders. Alternatively, to protect user privacy, user information of target users corresponding to the target bank's product resources may not be published. Furthermore, whether or not to publish user information of target users corresponding to the target bank's product resources depends on the choices made by the target users themselves.

[0090] The method provided in this application retrieves bank product resources, target user's bank product resource acquisition requests, and target user information from a blockchain. Based on the user information, it determines the target user's user permission group. If the bank product resource acquisition request passes qualification verification, it allocates target bank product resources to the target user according to the user permission group. When the time conditions for bank product rights and resources are met, it determines the target bank product resources corresponding to those resources, as well as the user information of the target user corresponding to those resources, and publishes the bank product rights and resources and the target bank product resources on the blockchain. This method improves the efficiency of bank product resource allocation in the blockchain by grouping users to be allocated bank product resources and allocating different bank product resources to different groups.

[0091] The following section provides a detailed explanation of how step S103 involves allocating target bank product resources to target users based on user permissions. Figure 2 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Figure 2 As shown, the aforementioned step S103 may specifically include:

[0092] S201. Determine the candidate bank product resources corresponding to the user permission group.

[0093] In this step, the candidate bank product resources corresponding to the target user can be determined based on the mapping relationship between user permission groups and candidate bank product resources, and the target user's user permission group. This mapping relationship can be pre-defined according to actual needs and stored in a configuration file or a specific database. If the mapping relationship is stored in a configuration file, the bank product resources corresponding to each user permission group can be extracted from the configuration file, and these extracted bank product resources can be identified as candidate bank product resources corresponding to the user permission group. If the mapping relationship is stored in a database, which can be a relational database or a non-relational database, the candidate bank product resources corresponding to the user permission group can be determined by querying the database.

[0094] For example, the pool of candidate bank products for the high-level permission group may include limited-edition commemorative certificates of deposit and high-benefit special services; the pool of candidate bank products for the intermediate-level permission group may include ordinary special deposit products and regular service benefits; and the pool of candidate bank products for the low-level permission group may include basic deposit products and basic service benefits.

[0095] Optionally, after identifying candidate bank product resources, these resources can be screened and organized. Screening criteria could include, for example, the validity period of the bank product resources and the number of remaining shares. Expired bank product resources or those with zero remaining shares can be removed from the candidate pool. The organization process could include classifying and sorting the candidate bank product resources, such as by product type or equity level, to improve the efficiency of subsequent allocation operations.

[0096] S202. Generate a random number for resource allocation in the bank product resource acquisition request.

[0097] The purpose of generating a random number for resource allocation in the bank product resource acquisition request is to achieve fair and random resource allocation. In this step, a random number generation algorithm can be used to generate this random number. This random number generation algorithm can be, for example, a pseudo-random number generation algorithm (such as the linear congruential method, Mason tweening algorithm, etc.) or a true random number generation algorithm (for example, using random signals generated by physical processes such as electronic noise and radioactive decay as the source of random numbers).

[0098] Specifically, a suitable random number generation algorithm can be selected based on actual needs. If the requirement for randomness is low but the requirement for generation efficiency is high, a pseudo-random number generation algorithm can be selected; if the requirement for randomness is high but the requirement for generation efficiency is low, a true random number generation algorithm can be selected.

[0099] The range of generated random numbers for resource allocation can be determined based on the number of candidate bank product resources. For example, if there are n types of candidate bank product resources, the range of random numbers for resource allocation can be set to 1-n. The distribution of random numbers for resource allocation should be uniform, meaning that each number should have an equal probability of appearing within this range, to ensure that each candidate bank product resource has an equal chance of being allocated.

[0100] S203. Based on the resource allocation random number, allocate target bank product resources to the target user from the candidate bank product resources.

[0101] One possible implementation is to select candidate bank product resources based on the magnitude of the resource allocation random number. Specifically, the candidate bank product resources can be numbered in a certain order, such as by product type, benefit level, or other rules. Assume there are four candidate bank product resources, A, B, C, and D, numbered 1, 2, 3, and 4 respectively. The resource allocation random number is generated in the range of 1-4. When the generated resource allocation random number is 3, candidate bank product resource C, numbered 3, is directly selected as the target bank product resource and allocated to the target user.

[0102] Another possible implementation method is to determine the target bank product resource based on the attribute information corresponding to the bank product resource acquisition request and the resource allocation random number. Specifically, this implementation method can be achieved through the following sub-steps:

[0103] S2031. Determine the resource allocation weight of the target user based on the attribute information corresponding to the bank product resource acquisition request.

[0104] The attribute information includes at least one of the following: storage duration of the bank product resource acquisition request, request time, on-chain time, and the target user's activity level.

[0105] In this embodiment, the storage duration of a bank product resource acquisition request reflects the dwell time of the request. A longer storage duration indicates a more urgent need from the target user, and the request should be prioritized. For example, a correspondence can be established between the storage duration of a bank product resource acquisition request and its resource allocation weight. For instance, a lower resource allocation weight corresponds to a storage duration within a certain range; as the storage duration increases, the resource allocation weight also increases accordingly. For example, a weight of 0.2 might be assigned to a storage duration of 1-5 time units, and a weight of 0.4 might be assigned to a storage duration of 6-10 time units.

[0106] Request time can refer to the time when a request to acquire bank product resources is initiated, the time when the request is received, etc. Earlier initiated requests for acquiring bank product resources can have higher priority. Specifically, different resource allocation weights can be assigned to bank product resource acquisition requests from different time periods based on the order of their requests.

[0107] On-chain time refers to the time when a bank's product resource acquisition request is recorded on the blockchain. The earlier the on-chain time, the earlier the record of that request appears on the blockchain. Based on the order of on-chain time, requests can be divided into different stages, each with a different weight. For example, the first Q on-chain requests have a weight of 0.6; the first Q to P requests have a weight of 0.4, and so on.

[0108] The activity level of a target user is calculated based on their activity level in transactions. Users with higher activity levels indicate greater participation in transactions and are likely to bring more value, thus warranting higher resource allocation weight. Activity level is calculated by considering multiple factors such as login frequency, transaction frequency, and the number of times a user participates in activities. For example, activity levels can be divided into high, medium, and low, with a weight of 0.8 for high-activity users, 0.5 for medium-activity users, and 0.2 for low-activity users.

[0109] When determining the resource allocation weight, a weight coefficient can be set for each piece of attribute information according to the importance of this attribute information. Suppose the weight coefficient of storage duration is a, the weight coefficient of request time is b, the weight coefficient of on-chain time is c, and the weight coefficient of activity level is d, and a + b + c + d = 1. Calculate the scores corresponding to each piece of attribute information respectively, then multiply the scores by the corresponding weight coefficients, and finally add up all the results to obtain the resource allocation weight of the target user.

[0110] S2032. Allocate target bank product resources for the target user from the candidate bank product resources according to the resource allocation random number and the resource allocation weight.

[0111] After obtaining the resource allocation weight, combine it with the resource allocation random number to allocate the target bank product resources. First, the priorities of the candidate bank product resources can be adjusted. For example, the initial priority score of each candidate bank product resource can be multiplied by the resource allocation weight of the target user to obtain the adjusted priority score.

[0112] For example, the initial priority scores of candidate bank product resources A, B, and C are P1, P2, and P3 respectively. The resource allocation weight of the target user is W. Then the adjusted priority scores are P1’ = P1 * W, P2’ = P2 * W, and P3’ = P3 * W respectively.

[0113] Then, compare the resource allocation random number with the adjusted priority scores. The adjusted priority scores can be sorted in ascending order to form a priority score interval. For example, if the adjusted priority scores are P1’ < P2’ < P3’, then the formed intervals are [0, P1’], (P1’, P2’], and (P2’, P3’].

[0114] When the generated resource allocation random number falls within a certain interval, the candidate bank product resource corresponding to this interval can be selected as the target bank product resource and allocated to the target user. For example, if the resource allocation random number is R, if 0 < R ≤ P1’, then select candidate bank product resource A as the target bank product resource; if P1’ < R ≤ P2’, then select candidate bank product resource B as the target bank product resource; if P2’ < R ≤ P3’, then select candidate bank product resource C as the target bank product resource.

[0115] In this way, target users with high resource allocation weights have greater advantages when selecting candidate bank product resources and are more likely to obtain target bank product resources with higher priorities, thus reflecting the differentiated allocation strategy for different users.

[0116] The following section provides a detailed explanation of how step S102 above determines the user permission grouping of the target user based on user information. Figure 3 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Figure 3 As shown, the aforementioned step S102 may specifically include:

[0117] S301. Obtain the target user's historical banking product smart contract based on user information.

[0118] In this embodiment, the target user's user information includes various user characteristics, among which the target user's identifier can be used to obtain the target user's historical banking product smart contracts. These historical banking product smart contracts are contracts signed by the target user when participating in banking product activities in the past, recording the target user's historical transaction behavior.

[0119] In this step, the target user's historical banking product smart contracts can be determined based on the identifiers included in the user information and the mapping relationship between these identifiers and historical banking product smart contracts. For example, historical banking product smart contracts are stored in a smart contract database. By searching the smart contract record corresponding to the user information in the smart contract database's index system, the node and specific storage address of the target user's historical banking product smart contract can be determined. After determining the storage address, the target user's historical banking product smart contract can be retrieved from the corresponding node through inter-node communication protocols. The retrieved historical smart contract contains detailed contract information, such as the contract signing time, contract rules, and the target user's rights and obligations under the contract.

[0120] S302. If the smart contract of a historical bank product corresponds to at least two alliance parties, then obtain at least two user permission levels of the target user from at least two alliance parties.

[0121] Once the target user's historical banking product smart contracts are obtained, it can be checked whether the contract corresponds to at least two consortium parties. Consortium parties are different organizations or institutions participating in banking product activities, and each consortium party has its own independent user permission management system.

[0122] If a historical banking product's smart contract corresponds to at least two consortium partners, then data interaction with each partner is necessary to obtain the target user's user permission levels across different partners. Each consortium partner has its own user permission database, storing user permission level information.

[0123] For example, cross-chain communication technology can be used to send query requests to the systems of various consortium members. The query request includes the target user's identifier, enabling the consortium systems to accurately locate the target user's permission level information. Upon receiving the query request, the consortium systems will search their user permission database based on the target user's identifier and return the query results.

[0124] Different affiliate partners can determine user access levels based on different criteria. For example, affiliate A might categorize access levels based on a user's deposit amount on its platform, with higher deposits resulting in higher access levels; affiliate B might determine access levels based on a user's frequency of activity participation, with higher participation rates leading to higher access levels. Therefore, the access levels of target users acquired may differ across affiliate partners.

[0125] S303. Determine the user permission grouping for the target user based on at least two user permission levels.

[0126] One possible approach is to construct a comprehensive evaluation model to determine the user permission grouping of the target user. This comprehensive evaluation model can consider multiple factors such as the importance of each alliance party, the user's permission level in different alliance parties, and the user's activity level in different alliance parties. By weighted fusion of multiple factors, the user permission grouping of the target user is determined (for example, by weighted fusion of multiple factors to determine the user permission score of the target user, and then based on a preset score range, the user permission grouping corresponding to the user permission score is determined).

[0127] For example, a score can be assigned to each permission level of the target user based on their permission level with different affiliate partners. For instance, permission levels can be divided into basic, intermediate, and advanced, corresponding to scores of 1, 2, and 3 respectively. Next, the weight of each affiliate partner is multiplied by the target user's permission level score with that partner to obtain a weighted score for that affiliate partner. For example, if affiliate partner A has a weight of 0.6, and the target user's permission level with affiliate partner A is intermediate with a score of 2, then the weighted score for affiliate partner A is 0.6 * 2 = 1.2. The weighted scores of all affiliate partners are summed to obtain a comprehensive score. Finally, based on the range of the comprehensive score, the target user is divided into different user permission groups. For example, a comprehensive score between 1 and 2 indicates a low-level permission group; between 2 and 3 indicates an intermediate-level permission group; between 3 and 4 indicates an advanced-level permission group, and so on.

[0128] Another possible implementation is to determine the target user's user permission group based on the highest of at least two user permission levels. For example, if the target user has a high permission level in alliance A and a medium permission level in alliance B, then the user is assigned to the high permission group based on the high permission level. This method can quickly determine the user's permission group, improving the system's processing efficiency.

[0129] Figure 4 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Figure 4 As shown, the method may further include:

[0130] S401. Obtain updated information on the target user's user behavior.

[0131] User behavior includes transaction behavior and application behavior. The transaction and application behaviors of target users are important information reflecting their activity within the system. This can be achieved by receiving user behaviors actively performed by target users and recording related updates.

[0132] For transactions, such as purchasing banking products or participating in deposit transactions, detailed transaction information can be recorded promptly after completion, including the transaction time, amount, and counterparty. This information is stored in a blockchain transaction record database. By periodically querying this database, updated information on the target user's transaction behavior can be obtained.

[0133] Application behavior refers to various requests made by target users, such as applying for new bank product resources or participating in specific activities. When a target user submits an application, information such as the content and time of the application can be recorded. This application information is stored in an application record database. Similarly, by querying this database, updated information on the target user's application behavior can be obtained.

[0134] The frequency of obtaining updated information can be set according to actual needs. For example, it can be set to obtain information daily, weekly, or in real time.

[0135] S402. Update the user permission groups for the target user based on the updated information.

[0136] Based on the obtained user behavior update information of the target user, it can be determined whether the user's permission group needs to be adjusted.

[0137] If a target user exhibits positive transaction behavior, such as frequently purchasing high-value banking products, it indicates increased spending power and contribution to transactions, potentially warranting a higher privilege level. Based on pre-defined rules, when a user's transaction amount reaches a certain threshold or the transaction frequency reaches a certain number of times, the user's privilege level can be upgraded from low to medium or from medium to high.

[0138] If a target user exhibits positive application behavior, such as frequently applying to participate in important events and performing exceptionally well during those events, their privilege group can be upgraded. For instance, if a user compliantly participates in multiple product activities they apply for, it indicates strong user activity and cooperation, and their privilege group can be upgraded.

[0139] Conversely, if a target user's transaction activity decreases, or if their application behavior violates regulations, such as frequently submitting invalid applications, it may be necessary to downgrade their permission group. Depending on the specific violation and preset rules, the user's permission group can be downgraded from high to medium or from medium to low.

[0140] When updating a user's permission group, the user's permission group information can be modified in the user permission management database. Simultaneously, the updated information is recorded on the blockchain to ensure traceability and immutability. The updated permission group affects the bank's product resources and services that the user can subsequently access, thereby incentivizing users to maintain positive behavior.

[0141] Figure 5 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. Figure 5 As shown, the data processing device may include: an acquisition module 11, a first processing module 12, a second processing module 13, and a control module 14.

[0142] The acquisition module 11 is used to acquire bank product resources, bank product resource acquisition requests from target users, and user information of target users from the blockchain.

[0143] The first processing module 12 is used to determine the user permission group of the target user based on the user information, and different user permission groups correspond to different bank product resources.

[0144] The second processing module 13 is used to allocate target bank product resources to target users according to user permission groups when the bank product resource acquisition request passes the qualification verification.

[0145] The control module 14 is used to determine the target bank product resources corresponding to the bank product rights and interests resources, as well as the user information of the target users corresponding to the target bank product resources, when the time conditions of the bank product rights and interests resources are met, and publish the bank product rights and interests resources and the target bank product resources in the blockchain.

[0146] Optionally, the second processing module 13 is specifically used to determine the candidate bank product resources corresponding to the user's permission group. It generates a resource allocation random number for the bank product resource acquisition request. Based on the resource allocation random number, it allocates the target bank product resource to the target user from the candidate bank product resources.

[0147] Optionally, the second processing module 13 is specifically used to determine the resource allocation weight of the target user based on the attribute information corresponding to the bank product resource acquisition request. Based on the resource allocation random number and the resource allocation weight, the target bank product resource is allocated to the target user from the candidate bank product resources. The attribute information includes at least one of the following: storage duration of the bank product resource acquisition request, request time, on-chain time, and the target user's activity level.

[0148] Optionally, the first processing module 12 is specifically used to obtain the target user's historical banking product smart contracts based on user information. If the historical banking product smart contracts correspond to at least two alliance parties, then at least two user permission levels of the target user from the at least two alliance parties are obtained. Based on the at least two user permission levels, the user permission grouping of the target user is determined.

[0149] Optionally, the first processing module 12 is specifically used to determine the user permission group of the target user based on the highest user permission level among at least two user permission levels.

[0150] Optionally, the acquisition module 11 is also used to acquire updated information about the target user's user behavior, including transaction behavior and application behavior. The first processing module 12 is also used to update the target user's user permission grouping based on the updated information.

[0151] Optionally, the bank's product resource acquisition request and the target user's information are stored in an off-chain distributed file system corresponding to the blockchain. The hash value and storage address of the file storing the bank's product resource acquisition request and the target user's information in the distributed file system are stored in the blockchain.

[0152] Optionally, the distributed file system is the InterPlanetary File System (IPFS).

[0153] Optionally, the bank product resource acquisition request is encrypted and stored by superimposing a digital signature, and / or the user information is stored after being encrypted or anonymized by an encryption algorithm.

[0154] The data processing apparatus provided in this application embodiment can execute the data processing method in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0155] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device is used to execute the aforementioned data processing method. Figure 6 As shown, the electronic device 600 may include at least one processor 601, a memory 602, and a communication interface 603.

[0156] The memory 602 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0157] The memory 602 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0158] The processor 601 is used to execute computer execution instructions stored in the memory 602 to implement the methods described in the foregoing method embodiments. The processor 601 may be a CPU, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0159] The processor 601 can communicate and interact with external devices through the communication interface 603. These external devices can be, for example, the aforementioned database. In specific implementations, if the communication interface 603, memory 602, and processor 601 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0160] Optionally, in a specific implementation, if the communication interface 603, memory 602, and processor 601 are integrated on a single chip, then the communication interface 603, memory 602, and processor 601 can communicate through an internal interface.

[0161] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used in the methods described in the above embodiments.

[0162] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of a computing device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the computing device to perform the data processing method described above.

[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method, characterized in that, The method includes: Obtain bank product resources from the blockchain, the target user's bank product resource acquisition request, and the target user's user information; Based on the user information, the user permission group of the target user is determined, and different user permission groups correspond to different bank product resources; If the request to acquire bank product resources passes the qualification verification, the target bank product resources will be allocated to the target user according to the user permission group. When the time conditions for bank product rights and resources are met, the target bank product resources corresponding to the bank product rights and resources, as well as the user information of the target users corresponding to the target bank product resources, are determined, and the bank product rights and resources and the target bank product resources are published in the blockchain.

2. The method according to claim 1, characterized in that, The step of allocating target bank product resources to the target user based on the user permission group includes: Determine the candidate bank product resources corresponding to the user permission groups; Generate a random number for resource allocation in the bank product resource acquisition request; Based on the resource allocation random number, the target bank product resources are allocated to the target user from the candidate bank product resources.

3. The method according to claim 2, characterized in that, The step of allocating the target bank product resource to the target user from the candidate bank product resources based on the resource allocation random number includes: The resource allocation weight of the target user is determined based on the attribute information corresponding to the bank product resource acquisition request. The attribute information includes at least one of the following: storage duration of the bank product resource acquisition request, request time, on-chain time, and the target user's activity level. Based on the resource allocation random number and the resource allocation weight, the target bank product resources are allocated to the target user from the candidate bank product resources.

4. The method according to claim 1, characterized in that, The step of determining the user permission group of the target user based on the user information includes: Based on the user information, obtain the target user's historical bank product smart contracts; If the smart contract of the historical banking product corresponds to at least two alliance parties, then obtain at least two user permission levels of the target user from the at least two alliance parties; Based on the at least two user permission levels, determine the user permission grouping of the target user.

5. The method according to claim 4, characterized in that, The step of determining the user permission grouping of the target user based on the at least two user permission levels includes: The user permission grouping of the target user is determined based on the highest user permission level among the at least two user permission levels.

6. The method according to any one of claims 1-5, characterized in that, Also includes: Obtain updated information on the target user's user behavior, including transaction behavior and application behavior; Based on the updated information, update the user permission grouping of the target user.

7. The method according to any one of claims 1-5, characterized in that, The bank product resource acquisition request and the target user's user information are stored in an off-chain distributed file system corresponding to the blockchain; The hash value and storage address of the file storing the bank's product resource acquisition request and the target user's user information in the distributed file system are stored in the blockchain.

8. The method according to claim 7, characterized in that, The distributed file system is the InterPlanetary File System (IPFS).

9. The method according to claim 8, characterized in that, The request for obtaining bank product resources is encrypted and stored by overlaying a digital signature; And / or, The user information is stored after being encrypted or anonymized using an encryption algorithm.

10. A data processing apparatus, characterized in that, The device includes: The acquisition module is used to acquire bank product resources, the target user's bank product resource acquisition request, and the target user's user information from the blockchain; The first processing module is used to determine the user permission group of the target user based on the user information, and different user permission groups correspond to different bank product resources. The second processing module is used to allocate target bank product resources to the target user according to the user permission group when the bank product resource acquisition request passes the qualification verification. The control module is used to determine the target bank product resource corresponding to the bank product rights and interests resource, and the user information of the target user corresponding to the target bank product resource, when the time conditions of the bank product rights and interests resource are met, and publish the bank product rights and interests resource and the target bank product resource in the blockchain.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 9.

Images