Resource allocation method and apparatus, electronic device, and computer readable medium

Abstract

Embodiments of the present disclosure disclose a resource allocation method, device, electronic equipment and computer readable medium. A specific embodiment of the method comprises: obtaining historical value request information sets; for each historical value request user identifier, performing the following steps: obtaining user value request feature information; inputting the user value request feature information into a pre-obtained value risk level classification model; for each application subject identifier, generating an application subject risk level corresponding to the application subject identifier according to the obtained respective pre-obtained value risk levels; obtaining user attribute information and a request user historical request information sequence; generating a user risk level according to the user historical request information sequence, the user attribute information and the generated respective application subject risk levels; and performing a resource allocation operation according to the user risk level. The embodiment can save resources and improve resource and server system security.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more particularly to resource allocation methods, apparatus, electronic devices, and computer-readable media. Background Technology

[0002] Rational allocation of limited resources can improve resource utilization and save resources. For example, rational allocation of storage space resources can save storage space. Similarly, rational allocation of valuable resources can improve the security of those resources. Currently, the common method for resource allocation is to allocate resources sequentially based on the order in which resource requests are received.

[0003] However, the inventors discovered that when using the above method to allocate resources, the following technical problems often arise: the value or risk coefficient of different users occupying the same resource is not the same; allocating resources only according to the order of time results in resources being assigned to users with low utilization rates or high risk coefficients, thus causing resource waste or low resource security; in addition, controlling resource requests only by issuing warnings to users cannot intercept abnormal resource allocation requests by users themselves, resulting in high system security risks (for example, when a user makes an abnormal resource allocation request, they may maliciously modify the front-end script, causing the server system to handle an excessive number of requests).

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the present disclosure concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure provide resource allocation methods, apparatuses, electronic devices, and computer-readable media to address the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a resource allocation method, the method comprising: in response to the current time meeting a preset duration condition, obtaining a historical value request information group corresponding to each historical value request user identifier, wherein the historical value request information in the historical value request information group includes an applicant entity identifier; for each historical value request user identifier included in the historical value request user identifier, performing the following steps: obtaining user value request feature information corresponding to the historical value request user identifier; generating a pre-acquisition value risk level based on the user value request feature information and a pre-generated pre-acquisition value risk level classification model information; for each applicant entity identifier included in the historical value request information group, generating an applicant entity risk level corresponding to the applicant entity identifier based on the obtained pre-acquisition value risk levels; in response to receiving resource allocation request information of a corresponding request user, obtaining user attribute information corresponding to the request user and a sequence of historical request information of the request user for a preset time period; generating a user risk level based on the user historical request information sequence, the user attribute information, and the generated applicant entity risk levels; and performing a resource allocation operation based on the user risk level.

[0008] Secondly, some embodiments of this disclosure provide a resource allocation apparatus, comprising: a first acquisition unit configured to acquire historical value request information groups corresponding to each historical value request user identifier in response to a preset duration condition being met at the current time, wherein the historical value request information in the aforementioned historical value request information group includes an applicant entity identifier; and a first execution unit configured to perform the following steps for each historical value request user identifier included in the aforementioned historical value request user identifier: acquiring user value request feature information corresponding to the aforementioned historical value request user identifier; and generating a pre-acquisition value risk level classification model based on the aforementioned user value request feature information and pre-generated pre-acquisition value risk level classification model information. The system comprises the following components: a risk level; a first generation unit configured to generate an applicant risk level corresponding to each applicant identifier in the aforementioned historical value request information group, based on the obtained pre-acquired value risk levels; a second acquisition unit configured to acquire user attribute information corresponding to the aforementioned requesting user and a sequence of historical request information of the requesting user within a preset time period in response to receiving resource allocation request information from the corresponding requesting user; a second generation unit configured to generate a user risk level based on the aforementioned user historical request information sequence, the aforementioned user attribute information, and the generated applicant risk levels; and a second execution unit configured to execute a resource allocation operation based on the aforementioned user risk level.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in any implementation of the first aspect.

[0011] The above embodiments of this disclosure have the following beneficial effects: the resource allocation method of some embodiments of this disclosure can save resources and improve resource security and server system security. Specifically, the reasons for resource waste or low security of resources and server systems are as follows: the value or risk coefficient of different users occupying the same resources is not the same. Allocating resources solely according to time sequence results in resources being assigned to users with low utilization or high risk coefficients, thus causing resource waste or low resource security. Furthermore, controlling resource requests only by issuing warnings to users cannot intercept abnormal resource allocation requests from users themselves, leading to high system security risks (e.g., users maliciously modifying front-end scripts during abnormal resource allocation requests, causing the server system to handle an excessive number of requests). Based on this, some embodiments of the resource allocation method of this disclosure firstly, in response to the current time meeting a preset duration condition, obtain historical value request information groups corresponding to each historical value request user identifier. The historical value request information in the aforementioned historical value request information group includes the applicant entity identifier. Thus, various historical value request information in the database can be obtained periodically, which can then be used to reclassify each applicant entity. Secondly, for each historical value request user identifier included in the aforementioned historical value request user identifier, the following steps are performed: obtaining user value request feature information corresponding to the aforementioned historical value request user identifier; based on the aforementioned user value request feature information and the preset duration condition... The system generates a pre-acquisition value risk level classification model based on the pre-acquisition value risk level information. This allows for the prediction of the pre-acquisition value proportion of each historical value requesting user, thus determining the type of each applicant. Then, for each applicant identifier included in the aforementioned historical value request information group, a corresponding applicant risk level is generated based on the obtained pre-acquisition value risk levels. This reveals the type of each applicant in terms of pre-acquisition value proportion, allowing for the determination of the user's risk type. Next, in response to receiving resource allocation request information from the corresponding requesting user, the system acquires the user attribute information and a sequence of historical request information for a preset time period. This provides the basic information of the requesting user, used to determine the user's risk type. Then, based on the user's historical request information sequence, user attribute information, and the generated applicant risk levels, a user risk level is generated. This determines the risk level of the user requiring resource usage, allowing for resource allocation. Finally, resource allocation is performed based on the user risk level. This allows for resource allocation according to the type of user requiring resource usage, improving resource utilization and security, and ultimately saving resources.Because when allocating resources, the risk level of applicants is first classified periodically as a derivative feature of user risk level classification. Then, users who need to occupy resources are classified by risk, and resources are allocated according to user type. This can improve the accuracy of user risk level, thereby improving resource utilization and the security of resources and server systems. As a result, resources can be saved and the security of resources and server systems can be improved. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the resource allocation method according to this disclosure;

[0014] Figure 2 This is a schematic diagram of the structure of some embodiments of the resource allocation device according to the present disclosure;

[0015] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0016] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0017] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0018] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0019] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0020] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0021] The collection, storage, and use of user personal information (such as user attribute information and historical value request information) involved in this disclosure shall be subject to the obligations of relevant organizations or individuals, including conducting personal information security impact assessments, informing personal information subjects, obtaining prior authorization and consent from personal information subjects, and complying with relevant laws and regulations, before the execution of such operations.

[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] Figure 1 A flow 100 of some embodiments of a resource allocation method according to the present disclosure is shown. The resource allocation method includes the following steps:

[0024] Step 101: In response to the current time meeting the preset duration condition, obtain the historical value request information group corresponding to each historical value request user identifier.

[0025] In some embodiments, the executing entity of the resource allocation method (e.g., a server) may, in response to a preset duration condition being met at the current time, obtain a group of historical value request information corresponding to each historical value request user identifier. The preset duration condition may be: the interval between the current time and the last time each applicant identifier was classified. The preset duration may be a pre-set duration, for example, one month. The historical value request user identifiers among the historical value request user identifiers may be unique identifiers of value request users at a past time. The value request user may be a user requesting pre-obtained value information (e.g., a loan). For example, the value request user may be a user applying for a loan. The historical value request information in the historical value request information group may represent the information of the corresponding value request user requesting pre-obtained value information at a past time. The historical value request information in the historical value request information group may include, but is not limited to, applicant identifiers. The applicant identifier may be a unique identifier of the applicant entity. The applicant entity may be the entity verifying the request for pre-obtained value information. For example, the applicant entity may be a financial institution. In practice, the aforementioned implementing entities can retrieve historical value request information groups corresponding to each historical value request user identifier from the database via wired or wireless connections. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future known wireless connection methods.

[0026] Step 102: For each historical value request user identifier included in each historical value request user identifier, perform the following steps:

[0027] Step 1021: Obtain the user value request feature information corresponding to the historical value request user identifier.

[0028] In some embodiments, the executing entity may obtain user value request characteristic information corresponding to the aforementioned historical value request user identifier. This user value request characteristic information may characterize the behavioral characteristics of the value requesting user. Specifically, it may characterize the user's pre-acquisition value behavior over a past period. For example, it may characterize the user's borrowing behavior. This user value request characteristic information may include, but is not limited to, total number of requests, average number of requests, average number of requests per applicant, total number of applicants, total number of requests per applicant, average number of requests per applicant, and maximum number of requests per applicant. The total number of requests may be the total number of times a historical value requesting user has requested pre-acquisition value information (e.g., loans) over a past period. The average number of requests may be the average number of times a user requests pre-acquisition value information (e.g., loans) per day. The average number of requests per applicant may be the average number of applicants a historical value requesting user requests pre-acquisition value information (e.g., loans) from per applicant per day. The total number of applicants may be the total number of applicants a historical value requesting user requests pre-acquisition value information (e.g., loans) from per applicant per day. The total number of requests from applicants in the aforementioned set of total request counts can be the total number of times historical value-requesting users have requested the corresponding applicants within a past period. The average number of requests from applicants in the set of average request counts from applicants can be the average number of times historical value-requesting users have requested the corresponding applicants per day. The maximum number of requests from an applicant can be the maximum value of the number of requests from each applicant to each applicant within a past period. The aforementioned user value request characteristic information can be generated in advance through data statistics of historical value request information groups. In practice, the aforementioned executing entity can obtain the user value request characteristic information corresponding to the aforementioned historical value-requesting user identifiers from the database via wired or wireless connections.

[0029] Step 1022: Generate a pre-acquisition value risk level based on the user value request feature information and the pre-generated pre-acquisition value risk level classification model information.

[0030] In some embodiments, the executing entity can generate a pre-acquisition value risk level based on the user value request feature information and a pre-generated pre-acquisition value risk level classification model. The pre-acquisition value risk level classification model information can characterize the pre-acquisition value risk level classification model. This information may include, but is not limited to, the pre-acquisition value risk level classification model and a preset feature identifier set. The preset feature identifiers in the preset feature identifier set can be unique identifiers of features with pre-defined feature weights. The pre-acquisition value risk level classification model can be a classification model that takes the target user value request feature information as input and the pre-acquisition value risk level as output. The target user value request feature information can be feature information corresponding to the preset feature identifier set. The pre-acquisition value risk level can be a level divided according to the level of pre-acquisition value risk (e.g., loan risk). The pre-acquisition value risk level can be, but is not limited to, one of the following: Level 1, Level 2, Level 3, and Level 4. It should be noted that the higher the level, the higher the corresponding pre-acquisition value risk. In practice, the aforementioned executing entity can input each feature of the corresponding preset feature identifier set included in the aforementioned user value request feature information as target user value request feature information into the aforementioned pre-acquired value risk level classification model included in the pre-acquired value risk level classification model information to obtain the pre-acquired value risk level.

[0031] Optionally, the above-mentioned pre-acquired value risk level classification model is pre-generated through the following generation steps:

[0032] The first generation step involves obtaining samples. These samples may include a pre-acquisition value ratio and a sample requesting user identifier. The sample requesting user identifier can be the identifier of the user requesting the value of the corresponding sample. In practice, the executing entity can obtain samples from a database via wired or wireless connections.

[0033] The second generation step involves obtaining preset user value request feature information corresponding to the aforementioned sample request user identifier. This preset user value request feature information can be pre-defined user value request feature information. In practice, the executing entity can obtain the preset user value request feature information corresponding to the aforementioned sample request user identifier from a database via a wired or wireless connection.

[0034] The third generation step involves inputting the aforementioned preset user value request feature information into the initial pre-acquisition value risk level classification model to obtain the pre-acquisition value risk level corresponding to the aforementioned samples. The aforementioned initial pre-acquisition value risk level classification model can be a model used for parameter initialization in classification. For example, the aforementioned initial pre-acquisition value risk level classification model can be an XGBoost-based classification model.

[0035] The fourth generation step involves determining the preset pre-acquired value risk level corresponding to the aforementioned sample pre-acquired value ratio as the sample pre-acquired value risk level. This preset pre-acquired value risk level can be a pre-defined pre-acquired value risk level. Each preset pre-acquired value risk level can correspond to a range of pre-acquired value ratios. This range of pre-acquired value ratios can be a range of pre-acquired value ratios. This pre-acquired value ratio can be the ratio of the net value information (e.g., interest) obtained by the applicant to the pre-acquired value information obtained by the value requesting user within the pre-acquired value information time period. For example, the pre-acquired value ratio can be the credit interest rate. The pre-acquired value information time period can be the period during which the value requesting user possesses the pre-acquired value information. For example, the pre-acquired value information time period can be the loan period. As an example, when the preset pre-acquired value risk level is Level 1, the corresponding pre-acquired value ratio range can be [0, 0.1); when the preset pre-acquired value risk level is Level 2, the corresponding pre-acquired value ratio range can be [0.1, 0.2); when the preset pre-acquired value risk level is Level 3, the corresponding pre-acquired value ratio range can be [0.2, 0.3); and when the preset pre-acquired value risk level is Level 4, the corresponding pre-acquired value ratio range can be [0.3, 0.4]. The preset pre-acquired value risk level corresponding to the above sample pre-acquired value ratio can be: the preset pre-acquired value risk level corresponding to the pre-acquired value ratio range to which the sample pre-acquired value ratio belongs.

[0036] The fifth step involves comparing the pre-acquisition value risk level of the corresponding sample with the pre-acquisition value risk level of the sample to obtain a comparison result. This comparison can be used to determine whether the pre-acquisition value risk level of the sample is the same as the pre-acquisition value risk level of the sample mentioned above.

[0037] The sixth step, based on the comparison results, determines whether the initial pre-acquisition value risk level classification model has achieved the optimization objective. This optimization objective can be that the accuracy of the generated samples is greater than a preset accuracy. The preset accuracy is not limited; for example, it could be 95%.

[0038] The seventh generation step, in response to determining that the initial pre-acquired value risk level classification model has reached the optimization objective, involves obtaining the current feature weight set corresponding to the initial pre-acquired value risk level classification model. Here, the current feature weights in the aforementioned current feature weight set can be the weight values ​​of the corresponding features.

[0039] The eighth generation step involves determining the current feature weights that satisfy a preset weight condition within the aforementioned current feature weight set as the target feature weight set. Each target feature weight in the target feature weight set corresponds to a preset feature identifier. The preset weight condition can be that the current feature weight is greater than a preset feature weight. The preset feature weight can be a pre-defined weight indicating that the importance of the characteristic feature is negligible. For example, the preset feature weight can be 0.

[0040] The ninth generation step involves updating the initial pre-acquisition value risk level classification model based on the aforementioned target feature weight set, resulting in a pre-acquisition value risk level classification model. In practice, the executing entity can update the current feature weight set of the corresponding initial pre-acquisition value risk level classification model to the aforementioned target feature weight set to obtain the pre-acquisition value risk level classification model.

[0041] The ninth generation step involves determining the preset feature identifiers corresponding to the aforementioned target feature weight set and the aforementioned pre-acquired value risk level classification model as pre-acquired value risk level classification model information.

[0042] Optionally, the above generation steps further include:

[0043] The tenth generation step, in response to the determination that the initial pre-acquired value risk level classification model has not achieved the optimization objective, adjusts the model parameters of the initial pre-acquired value risk level classification model, and uses unused samples to form a sample set. The adjusted initial pre-acquired value risk level classification model is then used as the new initial pre-acquired value risk level classification model, and the above generation steps are executed again. As an example, the back propagation algorithm (BP algorithm) and gradient descent methods (such as stochastic mini-batch gradient descent algorithm) can be used to adjust the model parameters of the initial pre-acquired value risk level classification model. The model parameters may include, but are not limited to, a set of feature weights. The feature weights in the feature weight set can be the weights of the corresponding features.

[0044] This simplifies the input variables of the model, thereby reducing the amount of computation and saving computing resources.

[0045] Step 103: For each applicant entity identifier included in the historical value request information group, generate the applicant entity risk level corresponding to the applicant entity identifier based on the obtained pre-acquisition value risk levels.

[0046] In some embodiments, the executing entity may, for each applicant identifier included in the historical value request information group, generate an applicant risk level corresponding to the applicant identifier based on the obtained pre-acquisition value risk levels. The applicant risk level may be a type categorized according to the risk level of the applicant's proportion of pre-acquisition value. The applicant risk level may be, but is not limited to, one of the following: high-risk applicant, medium-high-risk applicant, medium-low-risk applicant, or low-risk applicant. In practice, for each applicant identifier included in the historical value request information group, the executing entity may generate an applicant risk level corresponding to the applicant identifier based on the obtained pre-acquisition value risk levels through various methods.

[0047] In some optional implementations of certain embodiments, the aforementioned executing entity may generate an applicant risk level corresponding to the aforementioned applicant identifier based on the obtained pre-acquisition value risk levels through the following steps:

[0048] The first step is to determine the target level value as the median of the preset level values ​​for each of the obtained pre-acquired value risk levels. Each pre-acquired value risk level corresponds one-to-one with each preset level value. The preset level value can be a pre-set value corresponding to the pre-acquired value risk level. For example, if the pre-acquired value risk level is level one, the preset level value can be 1; if the pre-acquired value risk level is level two, the preset level value can be 2.

[0049] The second step is to determine the preset applicant risk level corresponding to the aforementioned target level value as the applicant risk level. This preset applicant risk level can be a pre-defined risk level for the applicant. Each preset applicant risk level corresponds to a preset level value. For example, when the preset applicant risk level is high-risk, the preset level value can be 4; when the preset applicant risk level is medium-high-risk, the preset level value can be 3.

[0050] Step 104: In response to receiving the resource allocation request information of the corresponding requesting user, obtain the user attribute information of the corresponding requesting user and the sequence of historical request information of the requesting user within a preset time period.

[0051] In some embodiments, the execution entity may, in response to receiving resource allocation request information from a corresponding requesting user, obtain user attribute information and a sequence of historical request information for the requesting user within a preset time period. The requesting user may be a user currently requesting pre-acquired value information. The resource allocation request information may represent a request for resource allocation. The resource may be storage resource corresponding to storage space, or value resource corresponding to pre-acquired value information. The preset time period may be a pre-defined time period. For example, the preset time period may be the time period corresponding to the current time and a target historical time point. The target historical time point may be the interval between the current time and the time point, defined as a preset historical interval. The preset historical interval may be a pre-defined interval. For example, the preset historical interval may be 3 days. The sequence of historical request information for the requesting user may be a sequence of historical request information for each requesting user arranged in ascending chronological order. The historical request information for the requesting user may be information about the requesting user requesting pre-acquired value information at the corresponding historical time point. The historical request information for the requesting user may include, but is not limited to, a requesting user identifier and request value information. The requesting user identifier may be a unique identifier for the requesting user. The aforementioned requested value information can be the pre-obtained value information needed by the requesting user. For example, the requested value information could be the loan amount. The aforementioned user attribute information can be information characterizing the user's attributes. The aforementioned user attribute information can include, but is not limited to, user identifier, user age, user employment information, and user value-related information. The aforementioned user identifier can be the user's unique identifier. The aforementioned user employment information can include, but is not limited to, the user's affiliated entity identifier and affiliated entity type. The aforementioned user affiliated entity identifier can be the identifier of the user's affiliated entity. The aforementioned user affiliated entity can be the entity to which the user belongs. For example, the aforementioned user affiliated entity can be the user's workplace. The aforementioned affiliated entity type can be the type of the user's affiliated entity. For example, the aforementioned affiliated entity type can be, but is not limited to, one of the following: state-owned enterprise, private enterprise, joint-stock limited company. The aforementioned user value-related information can include, but is not limited to, user acquired value information and user circulating value information. The aforementioned user acquired value information can be the value information obtained by the user (e.g., money). For example, the aforementioned user acquired value information can be the user's income. The aforementioned user circulating value information can be the value information flowing out by the user. For example, the aforementioned user circulating value information can be the user's consumption amount.

[0052] Step 105: Generate a user risk level based on the user's historical request information sequence, user attribute information, and the generated risk levels of each applicant entity.

[0053] In some embodiments, the executing entity may generate a user risk level based on the user's historical request information sequence, the user attribute information, and the generated risk levels for each applicant. The user risk level characterizes the degree of risk associated with a user requesting to obtain valuable information. The user risk level may be, but is not limited to, one of the following: high risk, medium risk, or low risk. In practice, the executing entity may generate a user risk level using various methods based on the user's historical request information sequence, the user attribute information, and the generated risk levels for each applicant.

[0054] Optionally, the historical request information of the requesting user in the aforementioned historical request information set may further include a user applicant identifier and an applicant type. The user applicant identifier may be an identifier of the applicant entity requested by the requesting user. The applicant type may characterize the attributes of the applicant entity. The applicant type may be, but is not limited to, one of the following: a value-based applicant type (e.g., a banking institution type) or a non-value-based applicant type (e.g., a non-banking institution type).

[0055] In some optional implementations of certain embodiments, the aforementioned executing entity may generate a user risk level by following these steps: based on the user applicant entity identifiers included in the aforementioned sequence of historical request information and the generated risk levels of each applicant entity.

[0056] The first step is to perform the following steps for each requester's historical request information in the above sequence of requester historical request information:

[0057] The first sub-step is to determine the risk level of the applicant entity that corresponds to the user applicant entity identifier included in the above-mentioned historical request information of the requesting user among the generated risk levels of each applicant entity as the target applicant entity risk level.

[0058] The second sub-step involves combining the risk level of the target applicant and the historical request information of the requesting user to obtain the update request information. This combination can be achieved through character concatenation.

[0059] The second step involves performing feature extraction processing on the obtained update request information and the aforementioned user attribute information to obtain user feature information. In practice, the executing entity can use a preset feature vector extraction algorithm to perform feature extraction processing on the obtained update request information and the aforementioned user attribute information to obtain user feature information. The preset feature vector extraction algorithm can be an algorithm for extracting feature vectors. For example, the preset feature vector extraction algorithm can be a neural network-based feature vector extraction algorithm.

[0060] The third step involves inputting the aforementioned user characteristic information into a pre-generated user risk level generation model to obtain the user risk level. This user risk level generation model can be a mapping table that takes user characteristic information as input and outputs the user risk level generation model.

[0061] Step 106: Perform resource allocation operations based on the user's risk level.

[0062] In some embodiments, the executing entity may perform a resource allocation operation based on the user's risk level. This resource allocation operation may involve allocating resources to the requesting user. The resources may be pre-acquired value information resources (e.g., loan funds in a fund pool). For example, the resource allocation operation may involve transferring the requested loan to the requesting user's bank account. As another example, when the resources are storage resources corresponding to storage space, the resource allocation operation may involve allocating storage space required for the corresponding requesting user's user information, resource allocation request, and the requesting user's historical request information sequence for information storage. In practice, the executing entity may perform the resource allocation operation in response to determining that the user's risk level meets a preset risk condition. This preset risk condition may be that the user's risk level is low risk.

[0063] In the process of adopting technical solutions to address the technical problems mentioned in the background, the following technical problem often arises: how to verify the authenticity of resource allocation requests before resource allocation is performed. A conventional solution to this second technical problem is to have the requesting user sign the request before resource allocation to verify the allocation information. However, this conventional solution still has the following drawback: user signatures are easily forged, leading to low accuracy of user confirmation information and consequently, low resource security.

[0064] Based on the available image processing technologies, the following solutions can be adopted:

[0065] Optionally, the aforementioned resource allocation request information includes request value information and request pre-acquisition value ratio information. The request pre-acquisition value ratio information can be the pre-acquisition value ratio requested by the user.

[0066] In some optional implementations of certain embodiments, the aforementioned execution entity may perform resource allocation operations based on the user's risk level according to the following steps:

[0067] The first step, in response to determining that the user's risk level meets the preset risk type conditions, is to generate pre-acquisition value contract information based on the resource allocation request information and the user attribute information. In practice, the executing entity can, in response to determining that the user's risk level meets the preset risk type conditions, fill the resource allocation request information, including the requested value information, the requested pre-acquisition value ratio information, and the user attribute information, into a preset pre-acquisition value contract template to obtain the pre-acquisition value contract information. The preset pre-acquisition value contract template can be a pre-defined template for a pre-acquisition value contract (e.g., a loan contract). The preset pre-acquisition value contract template includes underscores corresponding to the requested value information, the requested pre-acquisition value ratio information, and the user attribute information.

[0068] The second step involves encrypting the aforementioned pre-acquired value contract information to obtain encrypted contract information. In practice, the executing entity can use a preset encryption algorithm to encrypt the pre-acquired value contract information to obtain encrypted contract information. This preset encryption algorithm can be, but is not limited to, AES encryption algorithm or blockchain encryption algorithm.

[0069] The third step is to send the aforementioned encrypted contract information to the requesting terminal corresponding to the requesting user. The requesting terminal can be the terminal used by the requesting user.

[0070] The fourth step involves, in response to receiving the signed contract information corresponding to the encrypted contract information sent by the requesting terminal, obtaining the user signature information and user facial expression image sequence corresponding to the signed contract information. The signed contract information can be encrypted contract information with a user digital signature. The user signature information can represent the user's signature on the encrypted contract information. The user signature information can be a user signature image. The user signature image can be an image of the user's signature on the encrypted contract information. The user facial expression image sequence can be a sequence of user facial expression images arranged in ascending chronological order. The user facial expression image can be an image representing the user's facial expression when signing. In practice, the executing entity can, in response to receiving the signed contract information corresponding to the encrypted contract information sent by the requesting terminal, obtain the user signature information and user facial expression image sequence corresponding to the signed contract information from a database via a wired or wireless connection.

[0071] The fifth step involves performing signature verification processing on the aforementioned user signature information to obtain the signature verification result. In practice, firstly, the executing entity can retrieve the pre-signature information corresponding to the requesting user from the database. This pre-signature information can be the signature registered by the requesting user when registering their account. Secondly, a preset image feature extraction algorithm is used to extract features from the pre-signature information to obtain first feature information. This preset image feature extraction algorithm can be, but is not limited to, one of the following: histogram feature extraction algorithm or neural network-based feature extraction algorithm. Then, the preset image feature extraction algorithm is used to extract features from the user signature information to obtain second feature information. Afterward, the cosine similarity between the first and second feature information is determined as the information similarity. Finally, in response to determining that the information similarity is greater than or equal to a preset similarity, a preset signature matching success message is determined as the signature verification information. This preset similarity can be the similarity representing two signatures from the same user. For example, the preset similarity can be 90%. The preset signature matching success message can represent that the pre-defined signature was signed by the same user. For example, the preset signature matching success message can be 1. In response to determining that the similarity of the above information is less than the preset similarity, the preset signature matching failure information is determined as signature verification information. The preset signature matching failure information can indicate that the pre-defined signature was not signed by the same user.

[0072] Step 6: Perform expression verification processing on the aforementioned user expression image sequence to obtain the expression verification result. In practice, the executing entity can input the aforementioned user expression image sequence into a pre-generated expression verification result generation model to obtain the expression verification result. The expression verification result generation model can be a neural network that takes the user expression image sequence as input and the expression verification result as output. This neural network can be an LSTM neural network. The expression verification result can characterize the type of the user's expression. The expression verification result can be, but is not limited to, one of the following: relaxed, nervous, or afraid.

[0073] Step 7: Determine the preset signature verification score corresponding to the above signature verification result as the signature verification score. The preset signature verification score can be a pre-set score representing the impact of signature verification on the authenticity of the signed contract.

[0074] Step 8: Determine the preset expression verification score corresponding to the above expression verification results as the expression verification score. The preset expression verification score can be a pre-set score representing the impact of expression verification on the authenticity of the signed contract.

[0075] Step 9: In response to determining that the resource allocation request information, including the request value information, meets a preset value condition, the sum of the product of the first preset signature score weight and the signature verification score, and the product of the first preset expression score weight and the expression verification score, is determined as the signature verification score. The preset value condition can be that the request value information is greater than a preset request value information. The preset value request information can be pre-set value request information (e.g., loan amount). The first preset signature score weight can be a pre-set proportion representing the influence of the signature verification result on the final contract signing verification score. The first preset expression score weight can be a pre-set proportion representing the influence of the expression verification result on the final contract signing verification score. It should be noted that the sum of the first preset signature score weight and the first preset expression score weight can be 1.

[0076] Step 10: In response to the determination that the requested value information included in the resource allocation request information does not meet the preset value condition, the sum of the product of the second preset signature score weight and the signature verification score, and the product of the second preset expression score weight and the expression verification score, is determined as the signature verification score. The second preset signature score weight can be a pre-set proportion representing the influence of the signature verification result on the final contract signing verification score. The second preset expression score weight can be a pre-set proportion representing the influence of the expression verification result on the final contract signing verification score. It should be noted that the sum of the second preset signature score weight and the second preset expression score weight can be 1. The first preset signature score weight is greater than the second preset signature score weight. The first preset expression score weight is less than the second preset expression score weight. As an example, the first preset signature score weight can be 0.7, the first preset expression score weight can be 0.3, the second preset signature score weight can be 0.5, and the second preset expression score weight can be 0.5.

[0077] Step 11: In response to determining that the aforementioned signature verification score meets the preset verification conditions, a resource allocation operation is performed. The preset verification conditions can be that the signature verification score is greater than or equal to a preset signature verification score. The preset signature verification score can be a pre-defined score representing that the signed contract is a genuine signature from the requesting user.

[0078] The above-described technical solution and related content, as an inventive point of this disclosure, solve the technical problem that "user signatures are easily imitated, leading to low accuracy of user confirmation information and thus low resource security." Factors leading to low resource security often include: user signatures are easily imitated, resulting in low accuracy of user confirmation information and thus low resource security. Solving these factors can improve resource security. To achieve this, the resource allocation method of this disclosure first confirms resource allocation information through user signature. Then, when verifying the user signature, it not only verifies the signature but also collects the user's facial expression image during the signature process, classifies the user's emotions during the signature, and combines the user signature and the emotions during the signature to determine the authenticity of the user signature, thereby improving the accuracy of verifying the authenticity of the user signature. This improves resource security.

[0079] Optionally, the aforementioned implementing entity may also perform the following steps:

[0080] The first step, in response to determining that the user's risk level meets the preset user risk conditions, is to send preset risk anomaly information to the requesting terminal corresponding to the requesting user, and to identify the requesting user as an abnormal user. The preset user risk conditions can be a user risk level indicating high risk. The preset risk anomaly information can be pre-set information indicating a high user risk level. For example, the preset risk anomaly information can be "risk anomaly".

[0081] The second step involves intercepting the resource allocation request information received in response to the aforementioned abnormal user identifier. This resource allocation request information can be the same as a resource allocation request sent at a historical time point.

[0082] Therefore, when a high-risk user maliciously submits multiple resource allocation requests, the request information can be directly intercepted, thereby reducing malicious resource allocation requests and improving the stability of the server system.

[0083] Optionally, the aforementioned implementing entity may also perform the following steps:

[0084] The first step involves, in response to the detection of applicant risk level query information corresponding to each applicant entity identifier, sorting the applicant entity identifiers according to the generated applicant risk levels to obtain a sequence of applicant entity identifiers. The applicant risk level query information can be a request to query the applicant risk level corresponding to each applicant entity identifier. In practice, the executing entity may, in response to the detection of applicant risk level query information corresponding to each applicant entity identifier, sort the applicant entity identifiers according to the pre-acquisition value risk level represented by the corresponding applicant risk level, from low to high, to obtain a sequence of applicant entity identifiers.

[0085] The second step is to send the aforementioned applicant identifier sequence to the associated display device for display. This display device can be a screen.

[0086] The above-described embodiments of this disclosure have the following beneficial effects: the resource allocation method of some embodiments of this disclosure can save resources and improve resource security and server system security. Specifically, the reasons for resource waste or low resource and server system security are: the value or risk coefficient generated by different users occupying the same resources is different; resource allocation based solely on time sequence results in resources being allocated to users with low utilization or high risk coefficients, thus causing resource waste or low resource security; in addition, controlling resource requests solely by issuing warnings to users cannot intercept abnormal resource allocation requests from users themselves, leading to high system security risks (for example, a user maliciously modifying the front-end script when making abnormal resource allocation requests, causing the server system to handle an excessive number of requests). Based on this, the resource allocation method of some embodiments of this disclosure firstly, in response to the current time meeting a preset duration condition, obtains historical value request information groups corresponding to each historical value request user identifier. The historical value request information in the aforementioned historical value request information groups includes the applicant entity identifier. Therefore, various historical value request information in the database can be obtained periodically, which can then be used to reclassify each applicant entity. Secondly, for each historical value request user identifier included in the aforementioned historical value request user identifiers, the following steps are performed: user value request feature information corresponding to the aforementioned historical value request user identifier is obtained; based on the aforementioned user value request feature information and the pre-generated pre-acquisition value risk level classification model information, a pre-acquisition value risk level is generated. This allows prediction of the pre-acquisition value proportion of each historical value request user's intention, which can then be used to determine the type of each applicant entity. Then, for each applicant entity identifier included in the aforementioned historical value request information group, an applicant entity risk level corresponding to the aforementioned applicant entity identifier is generated based on the obtained pre-acquisition value risk levels. This allows obtaining the type of each applicant entity in terms of pre-acquisition value proportion, which can then be used to determine the user's risk type. Afterwards, in response to receiving resource allocation request information from the corresponding requesting user, user attribute information corresponding to the aforementioned requesting user and a sequence of historical request information for the requesting user within a preset time period are obtained. This allows obtaining the basic information of the requesting user, which can then be used to determine the user's risk type. Next, based on the aforementioned user historical request information sequence, the aforementioned user attribute information, and the generated risk levels of each applicant entity, a user risk level is generated. Therefore, it is possible to determine the risk level of users who need to use resources, and to allocate resources accordingly. Finally, based on the user risk level, the resource allocation operation is performed. This allows for resource allocation based on the type of user needing resources, thereby improving resource utilization and security, and ultimately saving resources.Because when allocating resources, the risk level of applicants is first classified periodically as a derivative feature of user risk level classification. Then, users who need to occupy resources are classified by risk, and resources are allocated according to user type. This can improve the accuracy of user risk level, thereby improving resource utilization and the security of resources and server systems. As a result, resources can be saved and the security of resources and server systems can be improved.

[0087] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a resource allocation device, which are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0088] like Figure 2 As shown, the resource allocation device 200 in some embodiments includes: a first acquisition unit 201, a first execution unit 202, a first generation unit 203, a second acquisition unit 204, a first generation unit 205, and a second execution unit 206. The first acquisition unit 201 is configured to acquire historical value request information groups corresponding to each historical value request user identifier in response to a preset duration condition being met at the current time. The historical value request information in the aforementioned historical value request information groups includes an applicant entity identifier. The first execution unit 202 is configured to perform the following steps for each historical value request user identifier: acquire user value request feature information corresponding to the aforementioned historical value request user identifier; generate a pre-acquisition value risk level based on the aforementioned user value request feature information and a pre-generated pre-acquisition value risk level classification model information; the first generation unit 203 is configured to... For each applicant entity identifier included in the aforementioned historical value request information group, an applicant entity risk level corresponding to the aforementioned applicant entity identifier is generated based on the obtained pre-acquisition value risk levels; the second acquisition unit 204 is configured to, in response to receiving resource allocation request information of the corresponding requesting user, acquire user attribute information corresponding to the aforementioned requesting user and a sequence of historical request information of the requesting user within a preset time period; the second generation unit 205 is configured to generate a user risk level based on the aforementioned user historical request information sequence, the aforementioned user attribute information, and the generated applicant entity risk levels; the second execution unit 206 is configured to execute resource allocation operations based on the aforementioned user risk level.

[0089] It is understandable that the units described in the resource allocation device 200 and the reference Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0090] The following is for reference. Figure 3 This document illustrates a structural schematic of an electronic device 300 suitable for implementing some embodiments of the present disclosure. The electronic devices in some embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0091] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0092] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0093] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0094] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0095] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0096] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following steps to be performed: In response to the current time meeting a preset duration condition, the electronic device acquires a historical value request information group corresponding to each historical value request user identifier, wherein the historical value request information in the aforementioned historical value request information group includes an applicant entity identifier; for each historical value request user identifier included in the aforementioned historical value request user identifier, the electronic device performs the following steps: acquires user value request feature information corresponding to the aforementioned historical value request user identifier; inputs the aforementioned user value request feature information into a pre-generated pre-acquisition value risk level classification model to obtain a pre-acquisition value risk level; for each applicant entity identifier included in the aforementioned historical value request information group, the electronic device generates an applicant entity risk level corresponding to the aforementioned applicant entity identifier based on the obtained pre-acquisition value risk levels; in response to receiving resource allocation request information from a corresponding request user, the electronic device acquires user attribute information corresponding to the aforementioned request user and a sequence of historical request information from the request user over a preset time period; generates a user risk level based on the aforementioned user historical request information sequence, the aforementioned user attribute information, and the generated applicant entity risk levels; and performs a resource allocation operation based on the aforementioned user risk level.

[0097] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a first acquisition unit, a first execution unit, a first generation unit, a second acquisition unit, a first generation unit, and a second execution unit. The names of these units do not necessarily limit the unit itself; for example, an acquisition unit may also be described as "a unit that, in response to a preset duration condition being met at the current time, acquires historical value request information groups corresponding to each historical value request user identifier."

[0100] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0101] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A resource allocation method, comprising: In response to the current time meeting a preset duration condition, the historical value request information group corresponding to each historical value request user identifier is obtained. The historical value request information group includes the applicant entity identifier. The preset duration condition is: the interval between the current time and the last time each applicant entity identifier was classified is the preset duration. For each historical value request user identifier included in the aforementioned historical value request user identifiers, the following steps are performed: Obtain user value request feature information corresponding to the historical value request user identifier; Based on the user value request feature information and the pre-generated pre-acquisition value risk level classification model information, a pre-acquisition value risk level is generated; For each applicant entity identifier included in the historical value request information group, an applicant entity risk level corresponding to the applicant entity identifier is generated based on the obtained pre-acquisition value risk levels; In response to receiving the resource allocation request information of the corresponding requesting user, the system obtains the user attribute information of the corresponding requesting user and the historical request information sequence of the requesting user within a preset time period. A user risk level is generated based on the user's historical request information sequence, the user attribute information, and the generated risk levels of each applicant entity. Based on the user's risk level, perform resource allocation operations, including: In response to determining that the user's risk level meets the preset risk type conditions, a pre-acquisition value contract information is generated based on the resource allocation request information and the user attribute information. The pre-acquired value contract information is encrypted to obtain encrypted contract information; The encrypted contract information is sent to the requesting terminal of the corresponding requesting user; In response to receiving the signed contract information corresponding to the encrypted contract information sent by the requesting terminal, the user signature information and user facial expression image sequence corresponding to the signed contract information are obtained; The user signature information is subjected to signature verification processing to obtain the signature verification result; The user's facial expression image sequence is subjected to facial expression verification processing to obtain facial expression verification results; The preset signature verification score corresponding to the signature verification result is determined as the signature verification score; The preset expression verification score corresponding to the expression verification result is determined as the expression verification score; In response to determining that the resource allocation request information includes request value information that meets a preset value condition, the sum of the product of the first preset signature score weight and the signature verification score, and the product of the first preset expression score weight and the expression verification score, is determined as the signature verification score. In response to determining that the resource allocation request information, including the request value information, does not meet the preset value condition, the sum of the product of the second preset signature score weight and the signature verification score, and the product of the second preset expression score weight and the expression verification score, is determined as the signature verification score. In response to determining that the signature verification score meets the preset verification conditions, a resource allocation operation is performed.

2. The method according to claim 1, wherein, The method further includes: In response to determining that the user risk level meets the preset user risk conditions, preset risk anomaly information is sent to the request terminal corresponding to the requesting user, and the requesting user identifier is identified as an abnormal user identifier. In response to receiving a resource allocation re-request information corresponding to the abnormal user identifier, the resource allocation re-request information is intercepted.

3. The method according to claim 1, wherein, The requesting user's historical request information sequence includes the user's applicant entity identifier and applicant entity type; and the generation of user risk levels based on the user's historical request information sequence, the user attribute information, and the generated risk levels of each applicant entity includes: For each historical request information of a requesting user in the sequence of historical request information, the following steps are performed: The risk level of the applicant entity corresponding to the user applicant entity identifier included in the historical request information of the requesting user among the generated risk levels of each applicant entity is determined as the target applicant entity risk level; The risk level of the target applicant and the historical request information of the requesting user are combined to obtain the updated request information; Feature extraction processing is performed on each update request information and the user attribute information to obtain user feature information; The user characteristic information is input into a pre-generated user risk level generation model to obtain the user risk level.

4. The method according to claim 1, wherein, The step of generating an applicant risk level corresponding to the applicant identifier based on the obtained pre-acquisition value risk levels includes: Each of the pre-acquisition value risk levels corresponding to the applicant entity identifier in the obtained pre-acquisition value risk levels is determined as the target pre-acquisition value risk level group; The median or average of each preset level value corresponding to the target pre-acquisition value risk level group is determined as the target level value; The preset risk level of the applicant corresponding to the target level value is determined as the applicant risk level.

5. The method according to claim 1, wherein, The pre-acquisition value risk level classification model information is generated in advance through the following generation steps: Obtain samples, wherein the samples include a sample pre-acquisition value ratio and a sample request user identifier; Obtain the preset user value request feature information corresponding to the user identifier of the sample request; The preset user value request feature information is input into the initial pre-acquisition value risk level classification model to obtain the pre-acquisition value risk level corresponding to the sample; The preset pre-acquisition value risk level corresponding to the sample pre-acquisition value ratio is determined as the sample pre-acquisition value risk level. The pre-acquisition value risk level corresponding to the sample is compared with the pre-acquisition value risk level of the sample to obtain the comparison result; Based on the comparison results, determine whether the initial pre-acquisition value risk level classification model has achieved the optimization objective; In response to the determination that the initial pre-acquired value risk level classification model has reached the optimization objective, the current feature weight set of the corresponding initial pre-acquired value risk level classification model is obtained; Each current feature weight that satisfies a preset weight condition in the current feature weight set is determined as the target feature weight set, wherein the target feature weights in the target feature weight set correspond to preset feature identifiers; Based on the target feature weight set, the initial pre-acquisition value risk level classification model is updated to obtain the pre-acquisition value risk level classification model. Each preset feature identifier corresponding to the target feature weight set and the pre-acquired value risk level classification model are determined as the pre-acquired value risk level classification model information.

6. The method according to claim 5, wherein, The generation step further includes: In response to the determination that the initial pre-acquired value risk level classification model has not achieved the optimization objective, the model parameters of the initial pre-acquired value risk level classification model are adjusted, and a sample set is formed using unused samples. The adjusted initial pre-acquired value risk level classification model is used as the initial pre-acquired value risk level classification model, and the generation step is executed again. The model parameters include a feature weight set.

7. The method according to claim 1, wherein, The method further includes: In response to detecting the applicant risk level query information corresponding to each applicant entity identifier, the applicant entity identifiers are sorted according to the generated applicant risk levels to obtain an applicant entity identifier sequence; The applicant's identifier sequence is sent to the associated display device for display.

8. A resource allocation device, comprising: The first acquisition unit is configured to acquire historical value request information groups corresponding to each historical value request user identifier in response to the current time meeting a preset duration condition. The historical value request information group includes the applicant entity identifier. The preset duration condition is: the interval between the current time and the last time each applicant entity identifier was classified is the preset duration. The first execution unit is configured to perform the following steps for each historical value requesting user identifier included in the respective historical value requesting user identifiers: Obtain user value request feature information corresponding to the historical value request user identifier; Based on the user value request feature information and the pre-generated pre-acquisition value risk level classification model information, a pre-acquisition value risk level is generated; The first generation unit is configured to generate an applicant risk level corresponding to each applicant identifier included in the historical value request information group, based on the obtained pre-acquired value risk levels. The second acquisition unit is configured to, in response to receiving resource allocation request information from the corresponding requesting user, acquire user attribute information corresponding to the requesting user and a sequence of historical request information of the requesting user within a preset time period. The second generation unit is configured to generate a user risk level based on the user's historical request information sequence, the user attribute information, and the generated risk levels of each applicant entity; The second execution unit is configured to perform resource allocation operations based on the user's risk level, including: In response to determining that the user's risk level meets the preset risk type conditions, a pre-acquisition value contract information is generated based on the resource allocation request information and the user attribute information. The pre-acquired value contract information is encrypted to obtain encrypted contract information; The encrypted contract information is sent to the requesting terminal of the corresponding requesting user; In response to receiving the signed contract information corresponding to the encrypted contract information sent by the requesting terminal, the user signature information and user facial expression image sequence corresponding to the signed contract information are obtained; The user signature information is subjected to signature verification processing to obtain the signature verification result; The user's facial expression image sequence is subjected to facial expression verification processing to obtain facial expression verification results; The preset signature verification score corresponding to the signature verification result is determined as the signature verification score; The preset expression verification score corresponding to the expression verification result is determined as the expression verification score; In response to determining that the resource allocation request information includes request value information that meets a preset value condition, the sum of the product of the first preset signature score weight and the signature verification score, and the product of the first preset expression score weight and the expression verification score, is determined as the signature verification score. In response to determining that the resource allocation request information, including the request value information, does not meet the preset value condition, the sum of the product of the second preset signature score weight and the signature verification score, and the product of the second preset expression score weight and the expression verification score, is determined as the signature verification score. In response to determining that the signature verification score meets the preset verification conditions, a resource allocation operation is performed.

9. An electronic device, comprising: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images