Resource return plan generation method and device, equipment and storage medium

Abstract

The invention provides a resource return plan generation method and device, equipment and a storage medium, and relates to the technical field of data processing, and the technical scheme is as follows: obtaining a resource return plan generation request of a resource return party; the resource return plan generation request comprises resource condition data of a resource return party and at least one resource return proposal; verifying each resource return proposal based on the resource condition data of the resource return party, and determining a verification result corresponding to each resource return proposal; from the resource return proposals, determining the resource return proposals whose verification results are passed as target resource return proposals; and generating a resource return plan of the resource return party based on each target resource return proposal. Through the resource return proposals in different time periods, the resource scheduling requirements of the return party in different time periods can be responded in a targeted manner, and the generated resource return plan is ensured to be matched with the resource bearing capacity of the return party, so that the stability of resource return is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of data processing, and in particular, to a resource return plan generation method and device, equipment and a storage medium. BACKGROUND

[0002] Resource aid refers to the measure of resource holders issuing resources to demanders to maintain their operation or development. However, the one-way flow of resources is only the starting point of the aid process, and the key to improving aid effectiveness is to realize the recycling of resources, and the achievement of this goal depends on the subsequent resource return link.

[0003] At present, the related resource return method usually jointly formulates a resource return plan by the resource holder and the demander when the resource is issued, and the demander subsequently returns the resource according to the plan.

[0004] However, in the actual resource return process of the demander, the resource return process may be interrupted due to unexpected problems, but the related resource return rules cannot respond to the unexpected problems of the demander, resulting in a disconnection between the resource return plan and the actual situation of the demander, and reducing the stability of resource return. SUMMARY

[0005] Embodiments of the present application provide a resource return plan generation method, device, equipment and storage medium, which can respond to the resource scheduling needs of the returner in different periods through resource return proposals in different periods, ensure that the generated resource return plan matches the resource carrying capacity of the returner, and thus improve the stability of resource return.

[0006] To achieve the above purpose, embodiments of the present application adopt the following technical solutions: In a first aspect, a resource return plan generation method is provided, which comprises: First, a resource return plan generation request of a resource returner is obtained. The resource return plan generation request includes resource status data of the resource returner and at least one resource return proposal. The resource return proposal includes a resource return period, a resource return method, a resource return amount, and an amount recalculation identifier. The amount recalculation identifier indicates whether to recalculate the resource return amount of the current resource return proposal under the condition of triggering the amount recalculation condition. In addition, the amount recalculation condition includes that the resource returner returns the resource in advance or the resource use cost coefficient of the returned resource is updated. Second, based on the resource status data of the resource returner, each resource return proposal is verified to determine the respective verification result of each resource return proposal. Then, from the resource return proposal, the resource return proposal with a passed verification result is determined as a target resource return proposal. Finally, based on each target resource return proposal, a resource return plan of the resource returner is generated.

[0007] The embodiment of the present application provides a resource return plan generation method. The method first acquires a plurality of independent resource return proposals submitted by a resource return party, wherein each proposal contains a self-defined return configuration for a specific period, including return mode, recalculation identifier and other parameters, so that the resource return party can flexibly define the return arrangement according to the actual situation, and the applicability of the proposal is improved. On this basis, the feasibility of each proposal is verified based on resource status data, and the target proposal matched with the real-time resource return ability of the resource return party is selected. Finally, the target proposal that passes the verification is integrated to generate a resource return plan that matches the change of the resource status of the resource return party, effectively improving the stability of the resource return process. Compared with the related art, the mechanism for generating the resource return plan by establishing the self-defined resource return proposal enables the resource return party to actively submit the return proposal with countermeasures when encountering foreseeable resource problems. The mechanism effectively solves the disconnection problem of the resource return plan caused by the fixed return rule, ensures the cooperation degree and return willingness of the resource return party, and enhances the stability and executability of the resource return.

[0008] In a possible implementation manner of the first aspect, the resource return proposal can further include a resource return identifier. The resource return identifier is used to indicate whether the resource return party performs resource return in the resource return period corresponding to the resource return proposal.

[0009] It should be understood that the above method introduces the resource return identifier, so that the resource return party can customize the resource return state. The resource scheduling pressure of the resource return party can be effectively alleviated, and the robustness and fault tolerance of the return process under abnormal conditions are improved.

[0010] In another possible implementation manner of the first aspect, the resource status data of the resource return party includes output resource time sequence data of the resource return party, cost resource time sequence data of the resource return party and resource exchange contract data of the resource return party. Based on the resource status data of the resource return party, each resource return proposal is verified to determine a respective verification result of each resource return proposal, including: processing the resource status data by using a disposable resource model to obtain disposable resource time sequence data of the resource requester. The disposable resource time sequence data includes the disposable resource amount of the resource output party at different times. In the disposable resource time sequence data, based on the resource return period of each resource return proposal, the disposable resource amount corresponding to the resource return period of each resource return proposal is determined. Based on the respective resource return amount of each resource return proposal and the respective disposable resource amount corresponding to each resource return proposal, the respective verification result of each resource return proposal is determined.

[0011] It should be understood that the method realizes the forward-looking assessment of the resource return ability of the resource return party by establishing the disposable resource model. Specifically, the model infers the disposable resource level of the resource return party at different times by considering multi-dimensional data such as output, cost and contract obligations. This data-driven verification method effectively improves the objectivity and accuracy of the proposal review, and ensures the feasibility of the generated plan from the source.

[0012] In a possible implementation of the first aspect, the determining of the respective verification result of each resource return proposal comprises: for any first resource return proposal in the resource return proposals, determining an amount threshold of the amount of disposable resources corresponding to the first resource return proposal that can be used for resource return. The amount threshold is determined based on the amount of disposable resources corresponding to the first resource return proposal and a preset amount of safety redundancy resources. The preset amount of safety redundancy resources refers to the amount of resources reserved by the resource return party to cope with uncertain events. In a case where the resource return amount of the first resource return proposal is less than or equal to the amount threshold, the verification result of the first resource return proposal is determined to be passed.

[0013] It should be understood that the method introduces the amount threshold mechanism containing safety redundancy, which guarantees the performance of the resource return obligation while reserving resource buffer space for the resource return party to cope with unexpected situations. This design not only ensures the executability of the return plan, but also effectively reduces the possibility of return interruption due to unexpected resource scheduling difficulties, thereby improving the stability and fault tolerance of the resource return process.

[0014] In a possible implementation of the first aspect, the generating of the resource return plan of the resource return party based on each target resource return proposal comprises: in a case where the sum of the resource return amounts of the resource return proposals is less than the total resource return amount of the resource return party, determining a difference between the total resource return amount of the resource return party and the sum of the resource return amounts of the resource return proposals as a remaining resource return amount. Based on the remaining resource return amount, a complementary resource return scheme is generated. The resource return period corresponding to the complementary resource return scheme includes a period within the preset total resource return period of the target resource and / or a period outside the preset total resource return period of the target resource. The resource return proposals and the complementary resource return scheme are spliced based on the sequence of the resource return periods to generate the resource return plan of the resource return party.

[0015] It should be understood that the method can automatically calculate the difference and generate a supplementary return scheme when the self-defined proposal of the resource return party does not completely cover the total return amount. By integrating the self-defined proposal and the supplementary scheme in time sequence, the flexibility of the self-defined return proposal and the hard constraint of the total return amount are coordinated, and the closed loop of the resource return process is ensured.

[0016] In a possible implementation form of the first aspect, the method further includes: based on the remaining amount of resource return, generating a complementary resource return scheme, including: determining a remaining resource return duration based on the remaining amount of resource return and a preset resource return manner; determining at least one remaining resource return time period based on a starting time of the resource return plan, the remaining resource return duration, and a resource return time period of the target resource return proposal; and generating at least one complementary resource return scheme based on the at least one remaining resource return time period and the preset resource return manner.

[0017] It should be understood that, by matching the remaining amount with the preset return rule, the time span required by the complementary scheme is automatically derived, ensuring the coordination of the complementary scheme in the remaining resource amount and the complementary time period, thereby improving the rationality and executability of the complementary scheme.

[0018] In a possible implementation form of the first aspect, the method further includes: based on each target resource return proposal, generating a resource return plan of the resource return party, including: in a case where a sum of resource return amounts of the resource return proposals is equal to a total amount of resource return of the resource return party and resource return time periods of the resource return proposals cover a preset total time period of resource return of the target resource, splicing the resource return proposals based on an order of the resource return time periods to generate the resource return plan of the resource return party.

[0019] It should be understood that, when the proposal defined by the return party has completely covered the total amount and total time period of resource return, the resource return plan can be directly generated according to the proposal content, so that the generated return plan is highly consistent with the real-time situation, thereby improving the willingness and feasibility of the return party to execute the plan.

[0020] In a possible implementation form of the first aspect, the resource return plan generation request further includes: trusted information of the resource requester and field classification identification information of the resource requester. After obtaining the resource return plan generation request of the resource return party for the target resource return contract, the method further includes: determining a trusted score of the resource requester based on the trusted information; determining a field sensitivity score of the resource requester based on the field classification identification information and a preset classification and field sensitivity score mapping table; and in a case where the trusted score is less than or equal to a trusted score threshold and / or the field sensitivity score is less than or equal to a field sensitivity score threshold, sending prompt information to the resource return party. The prompt information is used to indicate that the resource return plan generation request of the resource return party is not passed.

[0021] It should be understood that this scheme, by assessing the historical status of resource recipients and the characteristics of their respective fields, can effectively identify recipients with insufficient fulfillment capabilities or whose fields do not have high requirements for resource stability. This helps to prevent performance delays that may arise due to the recipient's lack of fulfillment capabilities or insufficient field adaptability, thereby ensuring the reliability and overall stability of the resource return process.

[0022] Secondly, a resource return plan generation apparatus is provided, the apparatus comprising: The acquisition module is used to acquire resource return plan generation requests from resource return providers for target resources. The resource return plan generation request includes: resource status data of the resource return provider and at least one resource return proposal. The resource return proposal includes: resource return period, resource return method, resource return amount, and amount recalculation flag. The amount recalculation flag indicates whether the resource return amount of the current resource return proposal should be recalculated if the amount recalculation condition is triggered. The amount recalculation condition includes: the resource return provider returning resources early or the resource usage cost coefficient of the returned resources being updated.

[0023] The processing module verifies each resource return proposal based on the resource status data of the resource return provider, determining the verification result for each proposal. From the resource return proposals, those that pass verification are identified as target resource return proposals. Based on each target resource return proposal, a resource return plan for the target resource is generated for the resource return provider.

[0024] Thirdly, a resource return plan generation apparatus is provided, the apparatus comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the resource return plan generation apparatus to perform the method as described in the first aspect and any possible implementation thereof.

[0025] Fourthly, a computer-readable storage medium is provided that stores computer instructions. When executed by a processor, the computer instructions are used to implement the method as described in the first aspect and any possible implementation thereof.

[0026] Fifthly, a computer program product is provided that, when running on a computer or executed by a computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be the resource return plan generation device described in the third aspect and any possible implementation thereof.

[0027] It is understood that the beneficial effects that the resource return plan generation apparatus described in the second aspect, the resource return plan generation device described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can achieve can be referred to the beneficial effects in the first aspect and any possible implementation thereof, and will not be repeated here. Attached Figure Description

[0028] Figure 1 A flowchart illustrating a method for generating a resource return plan provided in an embodiment of this application; Figure 2 A flowchart illustrating another method for generating a resource return plan provided in an embodiment of this application; Figure 3 A flowchart illustrating a resource return proposal verification method provided in this application embodiment; Figure 4 A flowchart illustrating another method for generating a resource return plan provided in this application embodiment; Figure 5 A flowchart illustrating a method for generating a supplementary resource return scheme, provided in an embodiment of this application; Figure 6 A flowchart illustrating a method for verifying a resource return plan generation request provided in an embodiment of this application; Figure 7 A schematic diagram of a resource return plan generation device provided in an embodiment of this application; Figure 8 This is a schematic diagram of a resource return plan generation device provided in an embodiment of this application. Detailed Implementation

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0030] 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 represent 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.

[0031] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

[0032] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0033] In resource assistance scenarios, resource return is a crucial step in achieving resource recycling. However, traditional resource return mechanisms employ fixed rules and uniform execution standards, lacking adaptability to the actual circumstances of the resource returners. When resource returners face difficulties in resource allocation due to unforeseen problems, existing rules fail to provide effective solutions, directly causing interruptions or failures in the return process. This rigid management approach not only increases the fulfillment pressure on resource returners and reduces their willingness to return resources but also affects resource recovery efficiency and the sustainable operation of the assistance system.

[0034] Therefore, how to design a resource return plan generation mechanism that can adapt to the dynamic changes of the resource return party and improve the stability of the return process has become an urgent problem to be solved.

[0035] In view of this, this application provides a method for generating a resource return plan. By establishing a flexible mechanism that includes proposal submission, multi-dimensional verification, and dynamic integration, the resource returner can submit a return proposal with custom configuration based on its own resource status. After verification, a return plan matching its real-time resource status is generated, thereby effectively improving the stability of resource return.

[0036] The embodiments are described in detail below with reference to the accompanying drawings.

[0037] The resource return plan generation method provided in this application can be applied to computing devices. Specifically, the computing device can be a single server or a server cluster composed of multiple servers, or a computer, or a processor or processing chip in a server or computer, etc. This application does not limit the specific device form of the computing device.

[0038] like Figure 1 As shown, the resource return plan generation method provided in this application embodiment, when applied to the above-mentioned computing device, specifically includes the following steps S101-S104: S101, Obtain a request from the resource return party to generate a resource return plan for the target resource.

[0039] In this context, a resource returner refers to an entity that, in a resource assistance scenario, has received the target resources from the resource provider and is therefore obligated to return them. The resource returner can be an individual, organization, or enterprise (institution), etc. The target resources are those that the resource returner needs to return. A resource return plan generation request refers to an electronic instruction or data packet sent by the resource returner to the computing device.

[0040] Specifically, a resource return plan generation request may include: resource status data of the resource returner and at least one resource return proposal. The resource status data includes the resource returner's historical resource reserves and flow, providing a data foundation for subsequent assessment of the resource returner's resource return capability and the feasibility of the proposal. The resource return proposal is the resource returner's proposed return plan for a specific period within the total resource return period.

[0041] Specifically, the resource return proposal includes: the resource return period, the resource return method, the resource return amount, and the amount recalculation indicator.

[0042] The resource return period refers to a future time interval defined by the resource returner within the total resource return period. The resource return period is used to define the effective date of the resource return proposal to which it belongs.

[0043] For example, the time unit for the resource return period can be a month, quarter, or year, and the specific value of the resource return period can be 1 month, 2 quarters, or 1 year, etc. This application embodiment does not limit the time granularity and specific value of the resource return period.

[0044] The resource return method refers to the specific method by which the resource returner returns resources or the calculation rules for the resource return amount during the effective period of the corresponding resource return proposal.

[0045] The quota recalculation flag indicates whether the resource return quota of the current resource return proposal should be recalculated if the quota recalculation conditions are triggered. Quota recalculation conditions include: the resource returner returns resources in advance or the resource usage cost coefficient of the returned resources is updated.

[0046] Early return of resources by the resource returnor refers to the act of the resource returnor voluntarily returning part or all of the resources to the resource provider before the planned return date stipulated in the resource return proposal. This act changes the total base amount of resources to be returned, thereby triggering a recalculation of subsequent return amounts. An update to the resource usage cost coefficient of returned resources refers to a change in the parameter used as the benchmark for calculating resource usage costs (such as interest). This parameter is usually related to the market benchmark interest rate or the agreed floating interest rate mechanism, and its update will directly affect the total amount to be returned in the future, thus constituting a recalculation condition.

[0047] Specifically, the credit limit recalculation flag can be set to either locked or unlocked. When the flag is unlocked, the computing device will recalculate the return amount in the resource return proposal based on the triggered credit limit recalculation conditions. If the flag is locked, the computing device will skip automatic recalculation and instead handle the credit limit changes caused by the triggered conditions by adjusting the plan duration or setting a grace period.

[0048] The following examples illustrate the technical terms mentioned above in specific scenarios.

[0049] For example, in the context of SME loans, the target resource could be the principal and the interest accrued on that principal. A resource return proposal could be: the resource return period is "October 2024", the resource return method is "equal principal and interest payments", the resource return amount calculated based on this method is "12,500 yuan", and the recalculation indicator is "yes". This data means that the returner proposes to repay 12,500 yuan in October according to the equal principal and interest payment rule; if they repay part of the principal before this date (triggering condition), the calculation device can automatically trigger the recalculation process of the amount due in October based on this indicator.

[0050] For example, in an equipment leasing scenario, the target resource is the quarterly usage right of a certain model of CNC machine tool. A resource return proposal could be: the resource return period is "fourth quarter", the resource return method is "fixed rent", the resource return amount is "90,000 yuan", and the amount recalculation indicator is "no". This means that the returning party plans to pay a fixed rent of 90,000 yuan in the fourth quarter; even if the market rent fluctuates (triggering condition), the fixed amount for the current quarter will not be adjusted based on this proposal.

[0051] For example, in a technical assistance scenario, the target resource is an annual license for a data analytics software. A resource return proposal could be: the return period is "fiscal year 2024," the return method is "5% of net profit," the return amount is 5% of net profit, and the recalculation indicator is "yes." This indicates that the returning party proposes that the technology usage fee for fiscal year 2024 be calculated based on 5% of its net profit; when the software license agreement is renewed mid-fiscal year, resulting in a rate adjustment (triggering condition), the computing device will automatically recalculate the revenue sharing ratio for the current fiscal year based on the new rate.

[0052] As can be seen from the above examples, the embodiments of this application do not limit the type of application scenario, the form of resources, or the specific content of the resource return method.

[0053] In some embodiments, a resource return proposal may further include: a resource return identifier; the resource return identifier is used to indicate whether the resource returner will return the resource within the resource return period of the current corresponding resource return proposal.

[0054] Specifically, the resource return flag can be a Boolean or enumerated control signal used to indicate the status of the resource return obligation within the resource return period of the relevant proposal. When the flag is set to "In Progress" or "True", it means that the return obligation must be fulfilled according to the proposal agreement within this period; when it is set to "Suspended" or "False", it means that the resource returner requests a suspension of return within this specific period.

[0055] When the resource return flag is set to "Suspended" or "False", the computing device will initiate an impact assessment and consolidation process for the outstanding resources. Specifically, the computing device will calculate the principal of all resources not returned on time during the suspension period and their associated usage costs, and will reallocate these outstanding resources to subsequent return arrangements. Possible consolidation methods include: including the full amount of the outstanding resource in the first return period after the suspension ends; amortizing it evenly over all remaining return periods and updating the repayment amount accordingly; or extending all repayment periods corresponding to the suspension period to the end of the original contract.

[0056] It should be understood that this approach, by introducing a resource return identifier, allows the returner to customize the resource return status. This can effectively alleviate the resource scheduling pressure on the returner and improve the robustness and fault tolerance of the return process under abnormal conditions.

[0057] In some embodiments, the resource return direction computing device may submit a request when it first generates a resource return plan for the target resource, or when it modifies an existing resource return plan.

[0058] Specifically, when modifying an existing resource return plan, the generation request must include a unique identifier that can be associated with the original plan, and the newly submitted resource return proposal will be used as the update input for generating the new version of the plan.

[0059] One possible implementation is that the computing device can call a pre-built application programming interface to parse asynchronous messages from a message middleware. Correspondingly, the specific data format for the resource return plan generation request in the above manner can be: a structured data object (such as a JSON object conforming to the JSON Schema specification or a serialized byte stream conforming to the Protocol Buffer definition), or an event message encapsulated in a message queue (whose message header contains the request type and source identifier, and whose message body is Base64 encoded request data).

[0060] In some embodiments, before obtaining a resource return plan generation request, the computing device may also provide the resource returner with a proposal template or recommended options to assist them in constructing a reasonable resource return proposal. The recommendation may be generated based on the returner's historical return records, behavioral pattern analysis of similar returners, or a preset intelligent algorithm.

[0061] For example, using a scenario from the financial sector, the specific content of the resource return proposal is described.

[0062] For example, as shown in Table 1, assume that the total resource return period for Resource Returner A (hereinafter referred to as Returner A) is 360 months (from January 1, 2010 to January 1, 2040). The default resource return plan is as follows: Table 1

[0063] Scenario 1: On December 4, 2024, Party A submitted a resource return proposal, which specifically included: the resource return period being from December 4, 2024 to January 1, 2040; the resource return method being equal principal repayment; and the corresponding resource return plan is shown in Table 2. Table 2

[0064] Scenario 2: On December 4, 2024, Party A submitted a resource return proposal, which specifically included: the resource return period was from December 4, 2024 to January 1, 2025, and the resource return was marked as "suspended," as shown in Table 3. Table 3

[0065] Scenario 3: On December 4, 2024, the returner A submitted two related resource return proposals.

[0066] The first proposal targets the recent resource return period (January 1, 2025 to December 1, 2025). Its core is to set a fixed resource return amount (1,000 yuan) and set the recalculation mark of the amount to "prohibit recalculation" (corresponding to "whether to lock" is "yes").

[0067] The second proposal targets the subsequent resource return period (January 1, 2026 to January 1, 2040), and its core is to change the resource return method to "equal principal repayment".

[0068] The computing device processes the two proposals sequentially, ultimately generating a resource return plan consisting of three phases, as shown in Table 4: Table 4

[0069] Based on the above, the computing device will adjust the resource return plan into three segments according to the needs of returnee A. The first segment is the previously executed plan; the second segment is the customer's requested plan with a fixed low amount for the next year, and the amount is locked and will not be recalculated with changes in parameters; the third segment is the return plan with equal principal payments for the remaining term.

[0070] For example, Party B submitted a resource return proposal for a target resource with a short term. The original contract for the target resource was valid until December 6, 2024, and the resource return method was "one-time repayment of principal and interest".

[0071] Party B, the returner, has requested an extension of the total validity period of the resource return contract. This request is considered a special resource return proposal, the core of which is to maintain the "one-time repayment of principal and interest" resource return method unchanged, but to adjust the end date of the final resource return period from December 6, 2024 to December 6, 2025.

[0072] The computing device first updates the contract's metadata (expiration date) based on this proposal. Subsequently, when generating the resource return plan, the computing device creates a new plan containing only one resource return period, covering the entire extended contract validity period, and inheriting the original return method, as shown in Table 5. Table 5

[0073] S102. Based on the resource status data of the resource returner, verify each resource return proposal and determine the verification result corresponding to each resource return proposal.

[0074] The verification of each resource return proposal refers to the process by which computing devices automatically evaluate and logically judge the feasibility and rationality of various configurations in the resource return proposal based on the resource status data of the resource returner. Its purpose is to technically select proposals that conform to the actual resource status of the returner.

[0075] In some embodiments, verifying each resource return proposal may include the following aspects: resource return capability verification, policy compatibility verification, and rule consistency verification.

[0076] Specifically, resource return capability verification refers to assessing whether the resource return amount stipulated in the resource return proposal exceeds the amount of resources available to the returner during the specified return period. Its core purpose is to ensure that the fulfillment of a single proposal does not lead to resource depletion for the returner or trigger a chain reaction of default risks.

[0077] Please refer to the following text for details. Figure 3 The details and related descriptions are not elaborated here.

[0078] Specifically, strategy compatibility verification is used to assess the match between the resource return method and the returnee's resource situation, aiming to ensure that the selected method is adapted to its revenue structure characteristics and risk tolerance. For example, for returnees with volatile revenue, a fixed amount method may be difficult to fulfill due to its lack of flexibility, while a floating amount method can better adapt to changes in their resources.

[0079] One possible implementation involves the computing device determining policy compatibility based on a pre-defined resource structure pattern and a valid return method mapping library. The computing device first performs time-series analysis on the historical resource inflow sequence, extracting statistical features such as mean, variance, and autocorrelation coefficient, and then constructs a resource structure pattern, such as a "stable pattern," "cyclical pattern," or "fluctuating pattern." Subsequently, the computing device searches the mapping library to verify whether the return method specified in the proposal belongs to the valid set corresponding to that pattern.

[0080] For example, analysis of resource inflow data over the past 12 months shows a low mean, large variance, and no significant peak in the autocorrelation coefficient; the computing device categorizes this as a "fluctuation pattern." The corresponding valid repayment methods in the mapping library for this pattern are {"proportional floating," "flexible repayment"}. If the method specified in the proposal is "fixed amount," the computing device determines that the strategy compatibility verification fails.

[0081] Rule consistency verification is used to check whether each element in the resource return proposal conforms to preset business rules. For example, it verifies whether a specific return method matches the specified recalculation identifier, or whether the resource return period is within the validity period of the target resource. This verification ensures the technical compliance and legality of the proposal.

[0082] One possible implementation involves configuring a business rule engine on the computing device. This engine loads a set of business rules defined in the form of logical expressions or decision tables. The computing device inputs the parsed resource return proposal elements into the rule engine, which then outputs a consistency determination result through pattern matching and logical reasoning.

[0083] For example, suppose a preset business rule logical expression is: (Resource Return Method == "Equal Principal and Interest Repayment") -> (Credit Limit Recalculation Flag == True). This rule requires that if the return method is equal principal and interest repayment, the credit limit recalculation function should be enabled. Suppose the computing device receives a proposal element of {Resource Return Method: "Equal Principal and Interest Repayment", Credit Limit Recalculation Flag: False}. After performing reasoning, the rule engine finds that the facts do not match the rule conclusion, and therefore determines that the proposal has failed the rule consistency verification.

[0084] In some embodiments, during the verification of each resource return proposal based on resource status data, the computing device can: invoke a predefined verification workflow to execute multiple verification sub-processes sequentially. The computing device first creates a verification context for each proposal, which binds the proposal data to the corresponding resource status data snapshot. Subsequently, the computing device, according to preset dependencies, sequentially or in parallel launches the solvency verifier, policy compatibility verifier, and rule consistency verifier. Each verifier populates its own judgment result back into the verification context. Finally, the main process aggregates all sub-results to generate the final comprehensive verification result.

[0085] One possible implementation is as follows: the computing device employs a pipeline filter architecture, organizing the validation process into a processing pipeline. Each validator acts as an independent filter, receiving input and passing output through a standardized data structure (e.g., a Java object or Python dictionary containing fields for proposalData, resourceStatus, and validationResults). The computing device's main controller encapsulates the proposal and resource status data into this data structure and sequentially passes it through the cascaded validation filters, ultimately collecting the complete validation results at the end of the pipeline.

[0086] For example, the computing device first injects proposal P001 and its resource status data S001 into the validation pipeline. The first filter in the pipeline, the "solvency validator," calculates a "pass" conclusion and writes the result {"solvency": "PASS"} into the validationResults field of the data structure. Subsequently, this data structure flows into the "policy compatibility validator," which, based on the resource fluctuation characteristics in S001, determines that the fixed-amount method of proposal P001 is incompatible, and appends {"compatibility": "FAIL", "reason": "Incompatible with volatile incomepattern"} to validationResults. Finally, based on the summarized results, the computing device determines the final validation result of proposal P001 as "fail."

[0087] It should be understood that this step establishes a multi-dimensional automated verification mechanism to conduct a feasibility assessment of resource return proposals at the initial stage of the return plan generation process. This mechanism can effectively identify and exclude proposals with insufficient solvency, conflicting return strategies, or those that do not comply with business rules, laying a reliable data foundation for the subsequent generation of feasible return plans. This technical approach reduces the risk of return interruption due to plan infeasibility from the front end of the process, thereby significantly improving the stability and success rate of the resource return process itself.

[0088] S103. From the resource return proposals, the resource return proposals that have passed the verification are identified as the target resource return proposals.

[0089] The target resource return proposal refers to the resource return proposal that passed the verification in S102 above. This proposal will serve as input data for subsequent planned integration operations.

[0090] In some embodiments, the computing device can obtain the target resource return proposal by parsing the verification context output in S102. Specifically, the computing device iterates through the verification context object created for each proposal in S102 and checks its final verification status field. For proposals with a status of "passed", the computing device extracts a complete copy of the proposal data from its associated context and moves it into the target proposal set.

[0091] In some embodiments, after determining the target resource return proposal, the computing device may also verify whether the resource return periods of each target resource return proposal overlap, and resolve conflicts for overlapping periods.

[0092] One possible implementation involves the computing device using an interval tree data structure to efficiently detect overlapping time periods. The resource return period for each proposal is modeled as a time interval and inserted into the interval tree. A query operation quickly finds all sets of overlapping intervals. For each detected overlapping set, the computing device determines the processing order according to preset business rules, which may be based on the submission sequence of the proposals or key conclusions from the S102 verification process.

[0093] For example, the computing device detects that proposals A and B overlap in their time periods within January. Based on the preset rule of "last submission first," the computing device automatically retains proposal B, which is later in the request data sequence, and marks proposal A as "rejected due to time period conflict." Simultaneously, the computing device sends a notification to the resource returner via a messaging service, explaining the conflict resolution result and the identifier of the rejected proposal.

[0094] Another possible implementation involves the computing device executing proposal reconciliation logic. When time period overlap is detected, the computing device does not simply reject one of the proposals, but instead attempts to create a new reconciliation proposal. The resource return period of this new proposal covers the original conflicting time period, and its resource return amount is the weighted average of the amounts of the original conflicting proposals. It also inherits the higher priority resource return methods from the original proposals.

[0095] For example, the computing device detects an overlap between proposal C (time period: Q3 2024, amount: 30,000 yuan) and proposal D (time period: August-September 2024, amount: 15,000 yuan). The computing device automatically generates a new proposal E with the time period "Q3 2024", the amount determined by calculating the time-weighted average as 25,000 yuan, and adopts the same return method as proposal C. The original proposals C and D are then marked as "replaced by reconciliation proposal E".

[0096] In some embodiments, for a given target resource return proposal, the computing device may additionally send a confirmation request to the resource returner. Specifically, the computing device encapsulates the data of the target proposal into a confirmation message, sends it to the resource returner's terminal device through a pre-defined communication interface, and waits for confirmation from the resource returner.

[0097] In this case, the resource returner can make a final confirmation of the proposal through client applications on their terminal devices (such as bank apps or enterprise service portals) or interactive messages (such as SMS messages or emails containing confirmation links).

[0098] In addition, the party returning the resource can initiate a modification request after reviewing the proposal. This proposal includes both the initially validated target resource return proposal and the reconciliation proposal automatically generated by the computing device to resolve conflicts.

[0099] At this point, the computing device can individually verify the proposals in the modification request and send another confirmation request to the resource returner until the resource returner finally confirms all proposals.

[0100] It should be understood that S103, through an iterative process of conflict detection and resolution, user confirmation and modification, constructs a proposal determination mechanism that is both automated and fully respects user wishes. This mechanism ensures that the target proposal set entering the integration phase not only complies with business rules and technical feasibility but also obtains final approval from the resource return party, laying a solid foundation for generating a highly executable resource return plan.

[0101] S104. Based on each target resource return proposal, generate a resource return plan for the target resource from the resource return party.

[0102] Specifically, the computing device first sorts all target resource return proposals according to their chronological order of return periods, forming an ordered proposal sequence. Then, based on a preset resource return cycle, the computing device decomposes the resource return period of each proposal into one or more discrete resource return time points. For each resource return time point, the computing device determines the specific resource return amount at that time point based on the amount type defined in its corresponding proposal: if the proposal amount is the total amount for the time period (i.e., the total amount within the proposal's time period), it is allocated according to the number of cycles; if the proposal amount is already the amount for the resource return cycle, it is directly adopted. Simultaneously, this time point fully inherits the resource return method of its corresponding proposal. Finally, the computing device integrates these execution units, each assigned a specific time, amount, and method, and encapsulates them to generate a resource return plan.

[0103] One possible implementation involves a built-in plan entry generator in the computing device. This generator iterates through the sorted sequence of proposals. For each proposal, it first calls a period decomposer to convert the proposal's time period into a continuous list of time points based on the computing device's globally configured return period (e.g., "month"). Then, the generator checks the "quota type" field of the proposal: if the type is "total quota," it calls a quota calculator to divide the total proposal amount equally by the number of time points (or other preset rules) as the quota for each time point; if the type is "periodic quota," it directly uses the proposal quota as the quota for each time point.

[0104] For example, the preset repayment period is "monthly". The computing device processes a sorted proposal with the content {Time Period: January to March 2024, Amount: 9000 yuan, Amount Type: Total Amount, Method: Equal Principal and Interest Repayment}. The period decomposer breaks it down into three time points: [2024-01-31, 2024-02-29, 2024-03-31]. Since the amount type is "Total Amount", the amount calculator divides the 9000 yuan equally, assigning an amount of 3000 yuan to each time point. Finally, the proposal generates three execution units: {Time Point: 2024-01-31, Amount: 3000, Method: Equal Principal and Interest Repayment}, {Time Point: 2024-02-29, Amount: 3000, Method: Equal Principal and Interest Repayment}, and {Time Point: 2024-03-31, Amount: 3000, Method: Equal Principal and Interest Repayment}.

[0105] For example, another proposal has the following content: {Time Period: January to March 2024, Amount: 3500 yuan, Amount Type: Recurring Amount, Method: Fixed Rent}. The periodic decomposer also generates three time points. Since the amount type is "Recurring Amount", each time point directly inherits the 3500 yuan amount from the proposal. This ultimately generates three execution units: {Time Point: 2024-01-31, Amount: 3500, Method: Fixed Rent}, {Time Point: 2024-02-29, Amount: 3500, Method: Fixed Rent}, and {Time Point: 2024-03-31, Amount: 3500, Method: Fixed Rent}.

[0106] This application provides a method for generating a resource return plan. The method first obtains multiple independent resource return proposals submitted by the resource returner. Each proposal includes a customized return configuration for a specific time period, including parameters such as return method and recalculation flag, allowing the resource returner to flexibly define return arrangements based on their actual situation, thus improving the applicability of the proposals. Based on this, the feasibility of each proposal is verified using resource status data, and target proposals matching the returner's real-time resource return capabilities are selected. Finally, by integrating the verified target proposals, a resource return plan that aligns with changes in the resource returner's resource status is generated, effectively improving the stability of the resource return process. Compared with related technologies, this application establishes a mechanism for generating resource return plans from customized resource return proposals, enabling the resource returner to proactively submit return proposals with corresponding countermeasures when encountering foreseeable resource problems. This mechanism effectively solves the problem of disconnected resource return plans caused by fixed return rules, ensuring the cooperation and willingness of the resource returner, and enhancing the stability and executability of resource returns.

[0107] The following section, in conjunction with the accompanying diagrams, details the verification process for the resource return proposal.

[0108] In some embodiments, the resource status data of the resource returner includes: the output resource time series data of the resource returner, the cost resource time series data of the resource returner, and the resource exchange contract data of the resource returner.

[0109] Specifically, the resource returner's output resource time-series data refers to the ordered record of the positive resource inflows generated by the resource returner entity through its main business activities at various historical and predicted future time points. This data sequence objectively reflects the entity's ability to continuously acquire resources and its stability.

[0110] For example, in the context of SME loans, this data can be represented as the company's monthly bank account transaction records for the past 24 months, as well as the expected sales revenue sequence for the next 12 months based on its order contracts and business model.

[0111] The cost resource time-series data of the resource returnee refers to the orderly record of the necessary and routine resource consumption incurred by the entity at the corresponding time point in order to maintain its basic existence and operation. These consumptions are the resource outflows necessary to maintain its basic functions.

[0112] For example, continuing from the previous example, this set of data specifically includes the company's monthly expenditure records for raw material purchases, employee salaries, various taxes and social insurance, office space rent, and utility expenses such as water, electricity, and internet during the same period.

[0113] Resource exchange contract data for the returning entity refers to detailed information about resource transfer obligations that the entity is required to fulfill at a specific future point in time due to previously entered into binding agreements. These obligations constitute a sequence of high-priority resource outflows that are determined to occur at a future point in time.

[0114] For example, the data is specifically represented by the remaining repayment schedule of other outstanding bank loans under the company's name (clearly stating the repayment date and amount for each future period), and a future rental payment schedule stipulated in an equipment finance lease contract that has not yet expired.

[0115] Based on the resource status data of the aforementioned resource returnor, the computing device performs the following specific execution process based on the solvency verification in S102 above: Figure 2 As shown, S102 specifically includes the following steps S201-S203: S201. Process resource status data through the available resource model to obtain the available resource time series data of the resource requester.

[0116] Among them, the time-series data of available resources includes the amount of available resources for resource producers at different times.

[0117] The available resource model is a data processing model used to calculate net resource availability. This model performs time-series alignment and aggregation operations on multi-dimensional resource status data to output quantitative data reflecting the actual available resource level of the resource provider.

[0118] Specifically, the available resource model can be a predictive model based on machine learning.

[0119] Examples include Long Short-Term Memory (LSTM) networks, Autoregressive Integral Moving Average (IMA) models, and Gradient Boosting Decision Trees. These models can predict future available resources based on historical patterns. This application does not limit the specific implementation of the available resource model.

[0120] One possible implementation method is as follows: the process of processing resource status data based on the disposable resource model implemented by the Long Short-Term Memory Network model is as follows: the computing device uses historical output, cost and contract data as training input, learns its long-term dependencies and periodic patterns through the LSTM network, thereby predicting the amount of disposable resources at each future time point, and outputting it as disposable resource time series data.

[0121] The training process of the disposable resource model: A computing device constructs an LSTM network, using historical sequence data (such as output, cost, and contract data from the past 24 months) as input features and the corresponding actual disposable resource amount for the same period as labels. The training set and validation set are split using time series cross-validation. The backpropagation algorithm and Adam optimizer are used to minimize the prediction error (such as mean squared error), and the network weights are iteratively updated until the model's performance on the validation set tends to stabilize.

[0122] The reasoning process of the disposable resource model: After training, the computing device inputs the latest, continuous historical resource status data sequence (e.g., data from the last 24 months) into the trained LSTM model. Based on the learned temporal dependencies, the model outputs predicted values ​​for the amount of disposable resources at each point in time within a future period (e.g., the next 12 months), thereby generating disposable resource time-series data for proposal validation.

[0123] Another possible implementation method, based on the autoregressive integral moving average model, involves the following process for processing resource status data: The computing device first performs a stationarity test and difference processing on the historical disposable resource sequence, and then fits the inherent pattern of the sequence through autoregression and moving average terms to predict the amount of disposable resources at future points in time, thereby generating disposable resource time series data.

[0124] The training process of the autoregressive integral moving average (ARIMA) model is as follows: The computing device performs a stationarity test (e.g., ADF test) on a historical sequence of available resources. If the sequence is non-stationary, it is differencing by order d until it becomes stationary. Subsequently, the autoregressive order p and the moving average order q are determined by analyzing the autocorrelation plot (ACF) and partial autocorrelation plot (PACF) of the differencing sequence, thus determining the structure of the ARIMA(p,d,q) model. Finally, methods such as maximum likelihood estimation are used to fit the model parameters.

[0125] The reasoning process of the autoregressive integral moving average (ARIMA) model: The computing device applies the established ARIMA model to the complete historical sequence of available resources. Utilizing the historical values ​​and prediction errors of the sequence itself, the model calculates the predicted values ​​of available resource amounts at each future time point and possible confidence intervals through recursion or direct prediction, thus forming the predicted time series data.

[0126] In some embodiments, the available resource model can be a machine learning-based predictive model. For example, long short-term memory networks, autoregressive integral moving average models, etc.

[0127] One possible implementation method is as follows: the process of processing resource status data based on the Long Short-Term Memory (LSTM) network model is as follows: the computing device uses historical output, cost and contract data as training input, learns its long-term dependencies and periodic patterns through the LSTM network, thereby predicting the amount of available resources at each future time point, and outputting it as time series data of available resources.

[0128] Another possible implementation method, based on the autoregressive integral moving average (ARIMA) model, involves the following process for processing resource status data: The computing device first performs a stationarity test and difference processing on the historical available resource sequence, and then fits the inherent pattern of the sequence through autoregression and moving average terms to predict the amount of available resources at future points in time, thereby generating available resource time series data.

[0129] S202. In the time series data of available resources, based on the resource return period of each resource return proposal, determine the amount of available resources corresponding to the resource return period of each resource return proposal.

[0130] The available resource limit for each resource return proposal refers to the amount of available resources extracted from the time-series data of available resources within one or more time periods that perfectly match the resource return period specified in the proposal. This limit represents the theoretically maximum amount of resources that the resource returner can freely use to fulfill the return obligation under this proposal within that specific period, after deducting all necessary expenses.

[0131] In this context, "quota" refers to a quantitative measure of a target resource, representing a unified and calculable representation of the resource in terms of quantity. The reason for abstracting resources into quotas is threefold: First, different forms of resources (such as funds, physical goods, and service duration) require a unified quantitative standard for consistent comparison and calculation; second, the quota-based representation allows complex resource situations to be handled by mathematical models, providing a numerical basis for automated verification; and finally, as a measurable execution unit, the quota provides a clear quantitative benchmark for subsequent plan generation and performance monitoring.

[0132] In some embodiments, the computing device can determine the available resource amount corresponding to the resource return period of each resource return proposal through time interval query and statistical aggregation. Specifically, the computing device first maps the resource return period of the proposal to the time axis of available resource time series data, extracts the available resource values ​​at all time points within the period to form a sample set, and then applies a statistical aggregation function to the set to obtain a representative value.

[0133] One possible implementation is for the computing device to adopt a conservative strategy, using the MIN() aggregation function of the time-series database to obtain the minimum amount of available resources within a given time period as the corresponding available resource limit. This method ensures that even under the most unfavorable circumstances, the party making the return still has the ability to fulfill its obligations.

[0134] For example, a proposal's resource return period is the first quarter of 2025 (January, February, and March). Querying time-series data reveals available resource quotas of 15,000 units, 16,000 units, and 14,500 units for these three months. Aggregating using the MIN() function determines the available resource quota for this proposal to be 14,500 units.

[0135] In other embodiments, the computing device can determine the available resource amount corresponding to each resource return proposal's return period through time interval querying and statistical aggregation. Specifically, after extracting the set of available resource values ​​within the time period, the computing device uses a trend-considering weighted average strategy for aggregation, assigning higher weights to later time points within the time period to reflect positive expectations of resource growth.

[0136] One possible implementation is that the computing device uses a linear weighted average function to assign a weight w_i = i / sum(1..n) to the i-th time point within the time period, where n is the total number of time points within the time period. The weighted average is then calculated as the corresponding available resource amount.

[0137] For example, the available resources for the same proposal period (January, February, and March) remain 15,000, 16,000, and 14,500 units, respectively. Weighting is calculated as follows: January weight = 1 / 6 ≈ 0.167, February weight = 2 / 6 ≈ 0.333, March weight = 3 / 6 = 0.5. The weighted average is 15,000 * 0.167 + 16,000 * 0.333 + 14,500 * 0.5 ≈ 15,167 units. This result is more optimistic than the simple minimum, reflecting expectations of improved resource conditions in the future.

[0138] S203. Based on the resource return amount of each resource return proposal and the available resource amount corresponding to each resource return proposal, determine the verification result corresponding to each resource return proposal.

[0139] The verification result refers to the binary judgment conclusion on whether the resource return proposal is feasible for repayment, obtained through quantitative comparison.

[0140] Specifically, the verification result may include: a Boolean "pass / fail" status indicator, detailed comparison data (such as the percentage of resource return amount to available resource amount), and specific judgment reason codes (such as "limit exceeded" or "meets safety margin"). This application embodiment does not limit the specific form of the verification result.

[0141] In some embodiments, the computing device may directly compare the resource return amount with the available resource amount.

[0142] For example, the computing device performs a direct arithmetic comparison between the resource return amount set in the proposal (e.g., 8,000 units) and the corresponding available resource amount determined in step S202 (e.g., 10,000 units). If the resource return amount is less than or equal to the available resource amount (8,000 ≤ 10,000), the proposal is deemed to have passed verification; otherwise, it is deemed to have failed.

[0143] In other embodiments, the computing device can directly compare the resource return amount to the available resource amount. Specifically, the computing device first calculates the resource return proposal's utilization rate, i.e., the ratio of the resource return amount to the corresponding available resource amount; then it compares this ratio with a preset risk threshold and outputs a verification conclusion based on the comparison result.

[0144] One possible implementation is that the computing device has a built-in proportional comparator. This component receives the resource return amount and the available resource amount as input, calculates the percentage value of the two, performs a logical judgment on this percentage value with a preset threshold parameter, and finally outputs a Boolean type verification result.

[0145] For example, a proposal has a resource return quota of 8,000 units, and its corresponding available resource quota is 10,000 units. The computing device calculates that the quota utilization rate is 80%. The preset risk threshold is 85%. Since 80% is less than or equal to 85%, the computing device determines that the proposal has passed verification and appends "quota utilization rate: 80%" as metadata to the verification result.

[0146] It should be understood that this approach, by establishing a disposable resource model, enables a forward-looking assessment of the returnee's resource return capability. Specifically, the model infers the returnee's disposable resource level at different times by considering multi-dimensional data such as output, cost, and contractual obligations. This data-driven verification method effectively improves the objectivity and accuracy of proposal review, ensuring the feasibility of the generated plan from the outset.

[0147] In some embodiments, the computing device may also introduce a security redundancy mechanism in S203, performing a more prudent resource status verification by calculating a reserved buffer threshold. In this case, the process of determining the verification result corresponding to any first resource return proposal in the resource return proposal is as follows: Figure 3 As shown, S203 specifically includes the following steps S301-S302: S301. Determine the threshold amount of available resources that can be used for resource return within the first resource return proposal.

[0148] The quota threshold refers to the upper limit of the total available resources of the resource returner during a specific resource return period, after security reservation and adjustment, that can be used to fulfill the corresponding proposal resource return obligations.

[0149] In some embodiments, in determining the threshold amount of available resources that can be used for resource return corresponding to the first resource return proposal, the computing device may employ dynamic calculation based on a volatility model. The computing device first extracts historical net resource inflow data (obtained from resource status data) associated with the period of the first resource return proposal and calculates its volatility index using a statistical model. Subsequently, the computing device determines a buffer ratio based on the mapping relationship between the volatility index and a preset safety factor, and finally calculates the specific value using the formula: Threshold = Available Resource Amount * (1 - Buffer Ratio).

[0150] One possible implementation involves a built-in volatility analysis module in the computing device. This module calculates the coefficient of variation using net resource inflow data from the past N periods. The computing device pre-stores a lookup table that maps coefficient of variation intervals to different buffer ratios. The calculation process is as follows: the computing device acquires historical data -> calculates the coefficient of variation -> queries the mapping table to obtain the buffer ratio -> applies a formula to calculate the quota threshold.

[0151] Where N is an integer, and the specific N periods can be monthly, quarterly, or annual, and N can be 1, 2, or other values. This application does not impose any restrictions on the specific value of N.

[0152] For example, a computing device processes a proposal with a corresponding available resource quota of 100,000 units. The computing device analyzes its monthly net inflow data over the past 12 months and calculates a coefficient of variation of 0.3, which is considered a moderate level of volatility. According to a pre-stored mapping table, this volatility level corresponds to a proposal buffer ratio of 15%. Therefore, the computing device determines the quota threshold to be 100,000 * (1 - 0.15) = 85,000 units.

[0153] S302. If the resource return amount of the first resource return proposal is less than or equal to the amount threshold, the verification result of the first resource return proposal is determined to be passed.

[0154] In some embodiments, the computing device can directly determine the verification result of the first resource return proposal by executing numerical comparison logic. The computing device invokes a comparator component, whose inputs are the resource return amount parsed from the first resource return proposal and the amount threshold calculated in step S401. The comparator performs a less than or equal to logical judgment; if the condition is true, a status identifier is generated and passed.

[0155] In some embodiments, the computing device may also employ a tiered judgment mechanism when executing the verification result for determining the first resource return proposal. The computing device not only requires the resource return amount to be less than or equal to a threshold, but also further calculates a safety margin, i.e., (threshold - resource return amount) / threshold. Based on the size of the safety margin, the computing device further subdivides "pass" into different levels, such as "safe pass" and "critical pass," and assigns different confidence labels to different levels for subsequent steps to prioritize or differentiate during planned integration.

[0156] One possible implementation involves configuring a state decision-maker in the computing device. This decision-maker receives the resource return amount and a threshold value as input. The decision-maker internally pre-sets multiple threshold ranges; for example, when the safety margin is greater than 20%, it is determined as "safely passed"; when the safety margin is between 5% and 20%, it is determined as "critically passed". Based on the calculation results, the decision-maker marks the proposal with the corresponding state and writes the state code and the calculated safety margin value together into the verification context of the proposal.

[0157] For example, the first resource return proposal has a resource return amount of 80,000 units, and its corresponding threshold is 100,000 units. The computing device calculates a safety margin of (100,000-80,000) / 100,000=20%. According to the preset rules, the proposal is determined to be "safely passed" and is accompanied by metadata {"safety_margin":0.2}.

[0158] In some embodiments, after determining that the verification result of the first resource return proposal is passed, the computing device may also perform a resource reservation operation. The computing device temporarily reserves a corresponding resource amount in a simulated resource pool based on the resource return amount and time period of the passed proposal. This aims to ensure that when multiple proposals with resource contention or overlapping time periods are verified in parallel, the actual resource consumption can be simulated, preventing subsequent verification proposals from failing due to virtual resource occupation, thereby ensuring the overall rationality and consistency of the verification results of the entire proposal set.

[0159] It should be understood that this approach, by introducing a threshold mechanism with safety redundancy, ensures the fulfillment of resource return obligations while reserving resource buffer space for the returner to cope with unforeseen circumstances. This design not only ensures the feasibility of the return plan but also effectively reduces the possibility of return interruption due to sudden resource scheduling difficulties, thereby improving the stability and fault tolerance of the resource return process.

[0160] The following section, in conjunction with the accompanying diagrams, details the process of generating the resource return plan.

[0161] The resource return proposals submitted by the resource returners include at least two situations: the sum of the resource return amounts in the resource return proposals is less than the total resource return amount of the resource returners, and the sum of the resource return amounts in the resource return proposals is equal to the total resource return amount of the resource returners.

[0162] Specifically, if the sum of the resource return amounts in the resource return proposals is less than the total resource return amount of the resource return party, it means that the resource return party has only submitted a return intention plan for a portion of the total resource return period, and has not yet made any plans for the remaining periods. In this case, the computing device needs to automatically generate a return plan for these unplanned remaining periods according to the preset (i.e., default) return rules.

[0163] Specifically, the sum of the resource return amounts in the resource return proposals equals the total resource return amount of the resource returner, meaning that the resource returner has established an allocation plan for all resources to be returned through its submitted proposals. This includes two scenarios: whether the resource return periods in the proposals completely cover the total resource return period, i.e., complete coverage and incomplete coverage. Complete coverage means that the periods of each proposal seamlessly fill the entire total resource return period (i.e., the union of the periods of each proposal equals or is greater than the total resource return period). Incomplete coverage means that although the total amount has been allocated, there are still time gaps within the total resource return period that are not covered by the proposals.

[0164] In some embodiments, when the sum of the resource return amounts of the resource return proposals equals the total resource return amount of the resource return party and the resource return period of the resource return proposals does not cover the preset total resource return period of the target resource, S104 can be implemented as follows: based on preset gap rules, verify the time gaps within the preset total resource return period that are not covered by the resource return proposals, reconcile the time periods of the resource return proposals based on the verification results, and splice the reconciled proposals in chronological order to generate a resource return plan.

[0165] The preset gap rules refer to the constraints on the uncovered time gaps allowed within the total resource return period, including but not limited to: the maximum duration of a single gap, the upper limit of the total number of gaps, and the time range limit for the occurrence of gaps.

[0166] Harmonization processes may include: generating zero-quota placeholder proposals to fill compliance gaps, or adjusting the boundaries of return periods for adjacent proposals to optimize gap distribution.

[0167] One possible implementation involves the computing device first verifying the identified time slots based on gap rules. For gaps that conform to the rules, a corresponding zero-quota placeholder proposal is generated; for gaps that do not conform to the rules, the time slot boundaries of adjacent proposals are adjusted to conform to the rules before generating the corresponding placeholder proposal. Finally, the computing device concatenates all original proposals and generated placeholder proposals in chronological order to form a complete resource return plan.

[0168] For example, the preset rules allow a single gap to be no more than 15 days. When the computing device identifies a compliant gap of 10 days, it directly generates a zero-quota placeholder proposal; when it identifies an excessive gap of 25 days, it shortens the gap to the rule-compliant 15 days by extending the end time of the previous proposal by 10 days, and then generates the corresponding placeholder proposal.

[0169] In other embodiments, when the sum of the resource return amounts of the resource return proposals equals the total resource return amount of the resource return party and the resource return period of the resource return proposals covers the preset total resource return period of the target resource, S104 can be implemented as: splicing the resource return proposals based on the order of the resource return periods to generate the resource return plan of the resource return party.

[0170] For details on the splicing process, please refer to S104 above; it will not be elaborated here.

[0171] It should be understood that this implementation method can directly generate a resource return plan based on the content of the proposal when the returner's custom proposal has fully covered the total amount of resources to be returned and the total time period requirements. This makes the generated return plan highly consistent with its real-time situation, thereby improving the returner's willingness and feasibility to execute the plan.

[0172] In other embodiments, when the sum of the resource return amounts in the resource return proposals is less than the total resource return amount of the resource return party, the specific process of the computing device generating the resource return plan for the resource return party is as follows: Figure 4 As shown, S104 specifically includes the following steps S401-S403: S401. Determine the difference between the total amount of resource return from the resource return party and the sum of the resource return amounts in the resource return proposal, and use this difference as the remaining amount of resource return.

[0173] The remaining amount of resource return refers to the amount of resource return obligations that still need to be fulfilled, which are not yet covered by all the proposals submitted by the resource returner.

[0174] In some embodiments, the computing device can obtain the remaining resource return quota by performing an arithmetic subtraction operation. The computing device first queries the total resource return quota corresponding to the target resource from persistent storage based on the unique identifier of the target resource, then parses all currently received resource return proposals and sums the resource return quota fields therein, and finally subtracts the sum of the proposal quotas from the total quota to obtain the remaining resource return quota.

[0175] For example, the computing device receives a total resource return quota of 1,000,000 units, and the two currently received proposal quotas are 200,000 units and 300,000 units respectively. After the computing device passes the verification, it performs the calculation: 1,000,000 - (200,000 + 300,000) = 500,000 units, and determines 500,000 units as the remaining resource return quota.

[0176] S402. Generate a supplementary resource return plan based on the remaining amount of resource return.

[0177] Among them, supplementary resource return schemes refer to one or more standardized resource return arrangements automatically generated by computing devices to cover the remaining resource return quota. They are used to fill the plan gaps caused by user proposals not fully covering return obligations.

[0178] Specifically, the resource return period corresponding to the supplementary resource return plan includes the period within the preset total resource return period of the target resource and / or the period outside the preset total resource return period of the target resource.

[0179] The time period within the preset total resource return period of the target resource refers to the time segment within the total resource return period that has not yet been covered by any resource return proposal submitted by the resource returner. During such time periods, the computing device generates supplementary plans to utilize the remaining idle time within the original return cycle to complete part or all of the remaining return obligations.

[0180] The time period outside the preset total resource return period for the target resource refers to the time interval later than the end time of the aforementioned total resource return period. During such periods, the computing device generates supplementary solutions designed to complete part or all of the remaining return obligations (i.e., deferral) by activating additional time periods beyond the original return cycle.

[0181] In some embodiments, when generating supplementary resource return schemes based on remaining resource return quotas, the computing device may employ an idle time slot priority filling strategy. The computing device first attempts to generate supplementary schemes within the total resource return period, in idle time slots not covered by user proposals. If the remaining quota can be fully allocated to these idle time slots, all supplementary schemes are within the total period; if the idle time slots are insufficient to cover all remaining quota, the computing device generates additional supplementary schemes outside the total period by extending the total period for the unallocated remaining portion. Specifically, this process can be referred to below. Figure 5 This will not be elaborated upon here.

[0182] In some embodiments, when generating a supplementary resource return scheme based on the remaining resource return quota, the computing device may also employ a supportive time period selection strategy based on resource stability. This strategy determines whether to allow the generation of a supplementary scheme outside the total resource return period based on the stability of resource flow to the resource returner, aiming to achieve a balance between resource recycling efficiency and alleviating pressure on the returner.

[0183] One possible implementation involves a computing device driving decision-making by quantitatively analyzing historical resource flow volatility in resource status data and comparing it to a preset threshold. The computing device first constructs a net resource inflow time series from the historical resource flow data and obtains a standardized volatility quantification index by calculating the coefficient of variation of this series. Subsequently, the computing device compares this coefficient of variation with a preset stability threshold: if the coefficient of variation is below the threshold, the resource flow is considered stable, and the computing device strictly limits the generated supplementary solutions to within the total resource return period; if the coefficient of variation is above the threshold, the resource flow volatility is considered high, and the computing device is allowed to generate supplementary solutions covering areas outside the total resource return period.

[0184] For example, consider a case where the remaining resource return quota is 60,000 units. Using the method described above, the computing device calculates the coefficient of variation (COP) of the net resource inflow to the returner as 0.13, and determines that it is less than the stability threshold of 0.25, thus classifying the resource status as stable. Accordingly, all compensation schemes generated by the computing device are allocated within idle periods of the total resource return period. Conversely, if the calculated COP exceeds this threshold, the computing device will utilize periods outside the total return period to generate some or all of the compensation schemes.

[0185] S403. Based on the order of resource return periods, the resource return proposal and the supplementary resource return plan are combined to generate the resource return plan of the resource return party.

[0186] In this context, "stitching" refers to the computational process by which the computing device sorts and integrates structured return items along a timeline. The purpose of this step is to combine validated, discrete user proposals and supplementary solutions into a resource return plan that is temporally continuous and obligatoryly complete.

[0187] In some embodiments, when concatenating resource return proposals and supplementary resource return schemes based on the order of resource return time periods, the computing device may employ a timeline sorting method. The computing device first parses the resource return time periods defined in all resource return proposals and supplementary resource return schemes, extracting the start time point of each time period. Subsequently, based on these start time points, the computing device arranges all proposals and schemes to be concatenated in ascending order along a timeline, forming an ordered task queue.

[0188] One possible implementation involves the computing device invoking a plan stitcher module that operates based on a priority queue data structure. All input proposals and schemes are encapsulated as plan entry objects and inserted into the queue using their start timestamp as the sorting key. The plan stitcher sequentially retrieves objects from the queue and appends them to the end of the final plan list. For supplementary schemes, the generation logic is designed to strictly fill in gaps in the timeline of the resource return proposal sequence, ensuring that entries are sequential and non-overlapping during stitching.

[0189] For example, the resource returner submits two proposals: Proposal A (period: January to January 2024) and Proposal B (period: March to March 2024). The computing device detects a gap in February 2024 and therefore generates a supplementary proposal C (period: February to February 2024). The planner arranges these three entries into a sequence [A, C, B] by their start time. During the arrangement process, the computing device processes these entries in this chronological order to generate a complete resource return plan that is temporally continuous and non-overlapping, executing A, C, and B sequentially.

[0190] It should be understood that this method can automatically calculate the difference and generate a supplementary return plan when the custom proposal from the resource returner does not fully cover the total amount due. By integrating the custom proposal and the supplementary plan in chronological order, it achieves a synergy between the flexibility of the custom return proposal and the hard constraint of the total return amount, ensuring a closed loop in the resource return process.

[0191] In some embodiments, the computing device can generate a supplementary resource return plan by executing a remaining quota allocation and time-period planning algorithm. This process is as follows: Figure 5 As shown, S402 specifically includes the following steps S501-S503: S501. Determine the remaining resource return duration based on the remaining resource return amount and the preset resource return method.

[0192] The preset resource return method refers to the default method pre-configured by the computing device or specified by business rules, which is used to determine the resource allocation amount for the resource return cycle when generating the supplementary plan. The remaining resource return duration refers to the total time required to clear the remaining resource return amount based on the preset resource return method, which is also the total duration of the supplementary resource return plan.

[0193] In some embodiments, the computing device can obtain a preset resource return method by querying the contract configuration associated with the target resource or by calling the global system parameter service. The computing device first retrieves the resource return contract associated with the target resource based on its unique identifier, and parses the default resource return method field from the contract terms; if it is not explicitly specified in the contract, the computing device then calls the system configuration service to obtain the globally preset default return method for generating the supplementary solution.

[0194] In some embodiments, when determining the remaining resource return duration based on the remaining resource return amount and a preset resource return method, the computing device can employ a duration-based reverse calculation method using a resource return method calculation model. The computing device takes the remaining resource return amount, the preset resource return method, and the contractually agreed resource usage cost coefficient as input, and feeds them into the corresponding periodic amortization calculation model for reverse calculation. This process calculates the total number of periods in which the sum of the present values ​​of future return amounts equals the remaining amount, and then converts this number of periods into a specific duration based on the return frequency.

[0195] The periodic amortization calculation model is a mathematical model used to simulate the allocation process of resources over time. This model encapsulates the mathematical relationship between resource quotas, allocation rules, and time periods. Its core function is to reverse-engineer the total number of time periods required to complete the repayment of all resources, given that the remaining resource repayment quota and the preset resource repayment method are known.

[0196] One possible implementation involves configuring a pluggable model computation engine in the computing device, which embeds inverse solvers for different resource return methods. The computing device takes as input the remaining resource return amount, resource usage cost coefficients, and allocation rules determined by the preset resource return method. The core of the engine is an iterative computation module, which iteratively assumes different number of cycles N and simulates the entire return process based on the preset resource return method, calculating the sum of the present values ​​of all future return amounts under the assumed N cycles. The computing device compares this sum of present values ​​with the input remaining resource return amount and continuously adjusts the value of N using an optimization algorithm (such as bisection) until the difference is less than a preset tolerance threshold; the corresponding N value at this point represents the total number of cycles solved. Finally, the computing device multiplies this number of cycles N by the return frequency to obtain the specific remaining resource return duration.

[0197] For example, in a financial lending scenario, the default resource repayment method is "equal principal and interest payments." The computing device uses the present value formula PV=PMT*[1-(1+r)^-N] / r corresponding to this method as the basis for simulation calculations. Here, the remaining resource repayment amount is represented by PV (present value), the resource usage cost coefficient is represented by the monthly interest rate r, and a target period amount PMT is set. The computing device estimates the amount using the transformation formula N=-log(1-(PV*r) / PMT) / log(1+r), and then uses an iterative method for precise calibration. Assuming PV is 120,000 yuan, r is 0.005 (i.e., 0.5%), and the target PMT is 1,000 yuan, the computing device iteratively solves and determines N to be 139 periods. If the repayment frequency is "monthly," then the remaining resource repayment period is 139 months.

[0198] For example, in an equipment rental scenario, the default resource return method is "fixed rent". The simulation rule used by the calculation device is: the total remaining quota equals the fixed periodic rent multiplied by the number of periods. The calculation device directly divides the remaining resource return quota (90,000 units) by the fixed periodic rent (15,000 units / quarter) to obtain the total number of periods N=6. If the return frequency is "quarterly", then the remaining resource return period is 6 quarters.

[0199] S502. Based on the start time of the resource return plan, the remaining resource return duration, and the resource return period of the target resource return proposal, determine at least one remaining resource return period.

[0200] The remaining resource return period refers to one or more specific time intervals allocated for implementing the supplementary resource return plan.

[0201] In some embodiments, the computing device can obtain the start time of the resource return plan, the remaining resource return duration, and the resource return period information of all target resource return proposals by parsing the context data of the planned task generation.

[0202] In some embodiments, when determining at least one remaining resource return period, the computing device may employ a time slot detection and filling strategy. The computing device first identifies all time slots not covered by the target resource return proposal within a time range defined by the remaining resource return duration, starting from the start time, and then determines one or more remaining resource return periods based on the slot distribution.

[0203] One possible implementation involves a built-in timeline analyzer in the computing device. This analyzer constructs a timeline starting from the initial moment and extending to the remaining resource return duration, marks the time period of the target proposal as occupied, and then scans and identifies consecutive gap intervals as candidate remaining resource return periods.

[0204] For example, within a preset total time period, the remaining resource return period is determined: the starting time is January 1, 2024, and the remaining resource return duration is 3 months. Existing target proposal A covers January, and proposal B covers March. Therefore, the computing device identifies February as a gap period and determines the remaining resource return period to be February.

[0205] For example, the remaining resource return period is determined outside the preset total time period: the starting time is January 1, 2024, and the original total resource return period was January to June. The existing target proposal already covers January to May, leaving a remaining resource return period of 2 months. Since there is only one gap left in June within the original total time period, the computing device determines that the first remaining resource return period is June, and the second remaining resource return period is extended to July, outside the original total time period.

[0206] S503. Based on at least one remaining resource return period and a preset resource return method, generate at least one supplementary resource return scheme.

[0207] In some embodiments, when generating at least one supplementary resource return scheme based on at least one remaining resource return period and a preset resource return method, the computing device may employ a periodic quota allocation strategy. The computing device first determines the number of return periods based on the length of the remaining resource return period, then calculates the specific return quota for each period based on the preset resource return method and the remaining resource return quota, and finally generates a supplementary scheme that includes the complete period, quota, and method definition.

[0208] One possible implementation involves a built-in scheme generator in the computing device. This generator receives a list of remaining resource return periods and a preset resource return method as input. For each period, it divides it into several standard return cycles (e.g., monthly, quarterly). Subsequently, according to the calculation rules corresponding to the preset resource return method (e.g., equal apportionment, proportional calculation, etc.), it allocates the remaining resource return amount to each cycle, forming a structured supplementary resource return scheme.

[0209] For example, a remaining resource return period is from July to September 2024 (3 months), with a remaining resource return quota of 9,000 units, and the preset resource return method is "equal apportionment". The computing device divides this period into 3 calendar months, calculates the monthly return quota as 3,000 units using the equal apportionment method, and generates a supplementary plan containing 3 return cycles.

[0210] For example, another remaining resource return period is the first quarter of 2025, with a remaining resource return quota of 15,000 units. The preset resource return method is "proportional allocation in the first phase". The computing equipment adopts an allocation strategy of paying 50% in the first phase and 25% in the remaining two phases, generating supplementary plans with return amounts of 7,500, 3,750 and 3,750 units respectively.

[0211] It should be understood that this method automatically derives the time span required for the replenishment plan by matching the remaining amount with the preset return rules, ensuring the coordination of the replenishment plan in terms of the remaining resource amount and the replenishment period, thereby improving the rationality and feasibility of the replenishment plan.

[0212] In some embodiments, the resource return plan generation request further includes: trusted information of the resource returner and domain classification identification information of the resource returner. This can be used to pre-verify the trustworthiness and security of the resource returner, as well as the stability and sensitivity of its domain, to ensure the reliability and security of subsequent resource return proposal verification and plan generation, and to prevent high-risk or sensitive domain returners from excessively consuming resources. In this case, such as Figure 6 As shown, after S101, the method further includes the following steps S601-S603: S601. Based on trusted information, determine the trust score of the resource requester.

[0213] Among them, the credibility score reflects the historical willingness and ability of the resource requester to fulfill its obligations.

[0214] For example, the specific form of the credibility score can be a percentage value, a probability value within the range of [0,1], or a preset grade sequence (e.g., A / B / C / D, Excellent / Good / Average / Poor). This application does not limit the specific form of the credibility score.

[0215] In some embodiments, trusted information may include: historical performance data, third-party credit data, and social behavior data.

[0216] Historical performance data refers to the collection of historical records of the resource returner's fulfillment of its resource return obligations in past contracts, directly reflecting the party's willingness and habit of fulfilling its obligations. Third-party credit data refers to quantitative credit assessment results of the resource returner provided by independent credit reporting agencies, offering a neutral, cross-scenario credit perspective. Social behavior data refers to behavioral traces left by the resource returner in public domain activities that indirectly reflect its stability and credibility, providing multi-dimensional cross-validation information for credibility assessment.

[0217] In some embodiments, a computing device can determine the trust score of a resource requester by performing a weighted aggregation operation on the individual data items in the trust information.

[0218] One possible implementation involves the computing device first standardizing the heterogeneous data items in the trusted information, mapping them uniformly to a preset numerical range, then determining a set of weight combinations applicable to the domain based on the domain classification identification information of the resource returner, and assigning weights to the standardized scores corresponding to each data item, thereby calculating the final trusted score through a weighted summation formula.

[0219] For example, a computing device processes a resource returner categorized as "Manufacturing." Its reliable information includes: a historical fulfillment rate of 95%, a third-party credit rating of "AA," and zero administrative penalty records. The computing device maps the fulfillment rate to 0.95 points, the "AA" rating to 0.9 points, and the zero penalties to 1.0 points. Based on the weighted combination of this category {fulfillment rate: 0.6, credit rating: 0.3, penalty records: 0.1}, the reliable score is calculated as (0.95 × 0.6) + (0.9 × 0.3) + (1.0 × 0.1) = 0.94, resulting in a final output score of 94.

[0220] In other embodiments, the computing device may employ a prediction method based on machine learning models to determine the trustworthiness score of the resource requester based on trusted information.

[0221] One possible implementation is that the computing device inputs standardized trustworthy information data items as feature vectors into a pre-trained classification or regression model, and the model directly outputs the corresponding trustworthy score.

[0222] For example, a computing device processes the credibility information of a resource returner, which has been standardized into a feature vector containing ten dimensions, including historical performance rate, average overdue days, and debt-to-equity ratio. The computing device inputs this vector into a trained gradient boosting decision tree model. The model performs non-linear combinations and judgments on the features through its internal multi-layer decision rules, and finally outputs a continuous value between 0.75 and 0.82. The computing device uses this value as the final credibility score of the requester.

[0223] S602. Based on the domain classification identification information and the preset classification and domain sensitivity score mapping table, determine the domain sensitivity score of the resource requester.

[0224] The domain classification identifier indicates the industry or business domain category to which the resource requester belongs. The domain sensitivity score indicates the degree to which the normal operation of the industry or domain to which the resource returner belongs depends on and is sensitive to the stability of resource flow. The preset classification-domain sensitivity score mapping table refers to a data mapping relationship table predefined and stored in the system. This table clearly defines the association between different domain classification identifiers and their corresponding domain sensitivity scores.

[0225] For example, the healthcare sector typically receives a high sensitivity score. This reflects the sector's extremely high dependence on the stability of resource flows, as any disruption to these flows could directly impact public health and safety. In contrast, sectors like retail or entertainment services may receive lower sensitivity scores. This is because these sectors are less dependent on the stability of resource flows, exhibiting greater resilience and stability, and can withstand short-term resource fluctuations.

[0226] For example, the specific form of the domain sensitivity score can be referred to the introduction of the credibility score in S601 above.

[0227] In some embodiments, the computing device may deploy a classification and domain sensitivity score mapping table locally, which is obtained and configured in the computing device by domain experts through comprehensive analysis of historical resource fluctuation data of various industries, macroeconomic resilience reports and critical infrastructure dependence assessments.

[0228] One possible implementation is that the computing device generates domain classification identifier information in the request based on the resource return plan, determines the domain classification by calling the built-in industry classification parser, and then retrieves and returns a predefined score that is precisely associated with the domain classification code in the classification and domain sensitivity score mapping table by performing a key-value query operation, thereby determining the domain sensitivity score of the resource requester.

[0229] Specifically, the industry classification parser is a data processing module that integrates standardized rules and fuzzy matching algorithms. This is because the original industry information provided by the resource returner may include different industry expressions, non-standard abbreviations, or colloquial descriptions. The core function of this parser is to normalize the diverse input information into a unified, predefined industry classification system.

[0230] S603. If the credibility score is less than or equal to the credibility score threshold and / or the domain sensitivity score is less than or equal to the domain sensitivity score threshold, send a prompt message to the resource returner.

[0231] The notification message indicates that the resource return plan generation request from the resource returner failed.

[0232] Specifically, a credibility score less than or equal to the credibility score threshold means that the creditworthiness or performance capability assessment of the resource returner does not meet the standards for the computing device to allow it to submit a custom return proposal. A domain sensitivity score less than or equal to the domain sensitivity score threshold means that the industry or business domain to which the resource returner belongs has a low dependence on the stability of resource flow, and its business operations have strong resistance to volatility and tolerance to resource interruptions.

[0233] By assessing trustworthiness and domain sensitivity scores, the computing and storage resources used by the system to process resource return plan generation requests can be centrally allocated to key returnees with controllable credit risk and higher requirements for resource flow stability. This improves the overall risk resistance of the resource assistance system and the overall efficiency of resource circulation.

[0234] In some embodiments, S603 can also be implemented as: sending a prompt message to the resource returner when the credibility score is less than the credibility score threshold and / or the domain sensitivity score is less than the domain sensitivity score threshold. This application embodiment does not specifically limit S603 or the boundary conditions for numerical judgments mentioned above.

[0235] In some embodiments, the notification message may include a core reason identifier code for the failed request and specific improvement guidelines. The core reason identifier code helps the resource returner quickly identify the type of problem, such as insufficient credibility score or unmet domain sensitivity score requirements. The specific improvement guidelines are associated with the reason identifier code, providing the resource returner with suggestions for subsequent actions. For example, they may suggest providing supplementary asset documentation or credit guarantees to improve the credibility score, or guide them to understand the standard return rules applicable to non-sensitive domains.

[0236] It should be understood that this scheme, by assessing the historical status of resource recipients and the characteristics of their respective fields, can effectively identify recipients with insufficient fulfillment capabilities or whose fields do not have high requirements for resource stability. This helps to prevent performance delays that may arise due to the recipient's lack of fulfillment capabilities or insufficient field adaptability, thereby ensuring the reliability and overall stability of the resource return process.

[0237] like Figure 7 This is a schematic diagram of a resource return plan generation device provided in an embodiment of this application. Figure 7 As shown, the resource return plan generation device includes: an acquisition module 701 and a processing module 702.

[0238] The acquisition module 701 is used to acquire the resource return plan generation request from the resource return party for the target resource. The resource return plan generation request includes: resource status data of the resource return party and at least one resource return proposal. The resource return proposal includes: resource return period, resource return method, resource return amount, and amount recalculation flag. The amount recalculation flag indicates whether the resource return amount of the current resource return proposal should be recalculated if the amount recalculation condition is triggered. The amount recalculation condition includes: the resource return party returns the resource early or the resource usage cost coefficient of the returned resource is updated.

[0239] Processing module 702 is used to verify each resource return proposal based on the resource status data of the resource returner, and determine the verification result for each resource return proposal. From the resource return proposals, those that pass verification are identified as target resource return proposals. Based on each target resource return proposal, a resource return plan for the target resource is generated for the resource returner.

[0240] In other embodiments, the resource return proposal may further include a resource return identifier. The resource return identifier is used to indicate whether the resource returner will return the resource within the resource return period of the corresponding resource return proposal.

[0241] In other embodiments, the resource status data of the resource returner includes: the resource output time-series data of the resource returner, the cost resource time-series data of the resource returner, and the resource exchange contract data of the resource returner. Processing module 702 is specifically used to: process the resource status data through the available resource model to obtain the available resource time-series data of the resource requester. The available resource time-series data includes the available resource amount of the resource producer at different times. Based on the resource return period of each resource return proposal, the available resource amount corresponding to each resource return proposal's resource return period is determined within the available resource time-series data. Based on the resource return amount of each resource return proposal and the available resource amount corresponding to each resource return proposal, the verification result corresponding to each resource return proposal is determined.

[0242] In other embodiments, the processing module 702 is specifically configured to: for any first resource return proposal among the resource return proposals, determine a threshold amount of available resources corresponding to the first resource return proposal that can be used for resource return. The threshold amount is determined based on the available resources corresponding to the first resource return proposal and a preset security redundancy resource limit. The preset security redundancy resource limit refers to the resource limit reserved by the resource returner to cope with uncertain events. If the resource return amount of the first resource return proposal is less than or equal to the threshold amount, the verification result of the first resource return proposal is determined to be passed.

[0243] In other embodiments, processing module 702 is specifically configured to: determine the difference between the total resource return amount of the resource return proposal and the sum of the resource return amounts of the resource return party when the sum of the resource return amounts of the resource return proposal is less than the total resource return amount of the resource return party, and use this difference as the remaining resource return amount. Based on the remaining resource return amount, a supplementary resource return plan is generated. The resource return period corresponding to the supplementary resource return plan includes the period within the preset total resource return period of the target resource and / or the period outside the preset total resource return period of the target resource. The resource return proposal and the supplementary resource return plan are concatenated based on the order of the resource return periods to generate the resource return plan of the resource return party.

[0244] In other embodiments, the processing module 702 is specifically configured to: determine the remaining resource return duration based on the remaining resource return quota and a preset resource return method; determine at least one remaining resource return period based on the start time of the resource return plan, the remaining resource return duration, and the resource return period of the target resource return proposal; and generate at least one supplementary resource return scheme based on the at least one remaining resource return period and the preset resource return method.

[0245] In other embodiments, the processing module 702 is specifically used to: when the sum of the resource return amounts of the resource return proposals is equal to the total resource return amount of the resource return party and the resource return period of the resource return proposals covers the preset total resource return period of the target resource, splice the resource return proposals based on the order of the resource return periods to generate the resource return plan of the resource return party.

[0246] In other embodiments, the resource return plan generation request further includes: the resource requester's trust information and the resource requester's domain classification identifier information. The acquisition module 701 is further configured to: determine the resource requester's trust score based on the trust information; determine the resource requester's domain sensitivity score based on the domain classification identifier information and a preset classification-domain sensitivity score mapping table; and send a prompt message to the resource returner if the trust score is less than or equal to a trust score threshold and / or the domain sensitivity score is less than or equal to a domain sensitivity score threshold. The prompt message indicates that the resource return plan generation request from the resource returner has failed.

[0247] The resource return plan generation device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0248] Figure 8 This is a schematic diagram of a resource return plan generation device provided in an embodiment of this application. Figure 8 As shown, the resource return plan generation device includes: a memory 801, a transceiver 802, and at least one processor 803.

[0249] The transceiver 802 is used to interact with other devices to send and receive data.

[0250] For example, in this embodiment of the application, transceiver 802 can be used to obtain the resource return plan generation request from the resource return party for the target resource, or to send a prompt message to the resource return party.

[0251] The memory 801 stores computer program code, which includes computer instructions. These computer instructions run in the resource return plan generation device described above to implement the method shown in the above method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk, or optical disc, etc.

[0252] Processor 803 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 803 can also be other general-purpose processors. A general-purpose processor can be a microprocessor or any conventional processor.

[0253] The memory 801, transceiver 802, and processor 803 are communicatively connected. For example, the memory 801 and transceiver 802 can be connected to the processor 803 via a system bus to complete communication between them. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0254] Optionally, the memory 801 can be either standalone or integrated with the processor 803. When the memory 801 is set up independently, it is connected to the processor 803 via the system bus.

[0255] This application also provides a chip for executing instructions, which is used to execute the technical solution of the resource return plan generation method in the above embodiments.

[0256] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the resource return plan generation method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the resource return plan generation device can execute the technical solution of the resource return plan generation method described in the above embodiments.

[0257] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the resource return plan generation method in the above embodiments.

[0258] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0259] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

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

[0261] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0262] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0263] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0264] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0265] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0266] 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 method for generating a resource return plan, characterized in that, include: The resource return recipient generates a request for a resource return plan for the target resource; The resource return plan generation request includes: resource status data of the resource returner and at least one resource return proposal; the resource return proposal includes: resource return period, resource return method, resource return amount, and amount recalculation identifier; wherein, the amount recalculation identifier is used to indicate whether the resource return amount of the current resource return proposal is recalculated when the amount recalculation condition is triggered; the amount recalculation condition includes: the resource returner returns resources in advance or the resource usage cost coefficient of the returned resources is updated; Based on the resource status data of the resource returner, each resource return proposal is verified, and the verification result corresponding to each resource return proposal is determined. From the resource return proposals, the resource return proposals that pass the verification are identified as the target resource return proposals; Based on each of the target resource return proposals, a resource return plan for the target resource is generated by the resource return party.

2. The method according to claim 1, characterized in that, The resource return proposal may further include: a resource return identifier; the resource return identifier is used to indicate whether the resource return party will return resources within the resource return period of the corresponding resource return proposal.

3. The method according to claim 1, characterized in that, The resource status data of the resource returner includes: the output resource time series data of the resource returner, the cost resource time series data of the resource returner, and the resource exchange contract data of the resource returner; The process of verifying each resource return proposal based on the resource status data of the resource returner, and determining the verification result for each resource return proposal, includes: The resource status data is processed by the available resource model to obtain the available resource time series data of the resource requester; the available resource time series data includes the available resource amount of the resource producer at different times. In the available resource time series data, based on the resource return period of each resource return proposal, the available resource amount corresponding to each resource return period of each resource return proposal is determined; Based on the resource return amount of each resource return proposal and the available resource amount corresponding to each resource return proposal, the verification result corresponding to each resource return proposal is determined.

4. The method according to claim 3, characterized in that, Determining the verification result corresponding to each of the resource return proposals includes: For any one of the resource return proposals, determine a threshold amount of available resources corresponding to the first resource return proposal that can be used for resource return; the threshold amount is determined based on the available resources corresponding to the first resource return proposal and a preset security redundancy resource amount; the preset security redundancy resource amount refers to the resource amount reserved by the resource returner to cope with uncertain events. If the resource return amount of the first resource return proposal is less than or equal to the amount threshold, the verification result of the first resource return proposal is determined to be passed.

5. The method according to claim 1, characterized in that, The step of generating a resource return plan for the target resource based on each target resource return proposal includes: If the sum of the resource return amounts in the resource return proposals is less than the total resource return amount of the resource return party, the difference between the total resource return amount of the resource return party and the sum of the resource return amounts in the resource return proposals is determined as the remaining resource return amount. Based on the remaining amount of resource return, a supplementary resource return plan is generated; the resource return period corresponding to the supplementary resource return plan includes the period within the preset total resource return period of the target resource and / or the period outside the preset total resource return period of the target resource; Based on the chronological order of resource return periods, the resource return proposal and the supplementary resource return scheme are combined to generate the resource return plan of the resource returnor.

6. The method according to claim 5, characterized in that, The step of generating a supplementary resource return plan based on the remaining resource return amount includes: Based on the remaining amount of resource return and the preset resource return method, the remaining resource return duration is determined; Based on the start time of the resource return plan, the remaining resource return duration, and the resource return period of the target resource return proposal, at least one remaining resource return period is determined; Based on the at least one remaining resource return period and the preset resource return method, at least one supplementary resource return scheme is generated.

7. The method according to claim 1, characterized in that, The step of generating a resource return plan for the target resource based on each target resource return proposal includes: If the sum of the resource return amounts in the resource return proposals equals the total resource return amount of the resource return party, and the resource return period of the resource return proposals covers the preset total resource return period of the target resource, the resource return proposals are spliced ​​together based on the order of the resource return periods to generate the resource return plan of the resource return party.

8. The method according to claim 1, characterized in that, The resource return plan generation request also includes: the trusted information of the resource requester and the domain classification identifier information of the resource requester; After obtaining the resource return plan generation request from the resource return party for the target resource return contract, the method further includes: Based on the trusted information, a trust score is determined for the resource requester; Based on the domain classification identification information and the preset classification and domain sensitivity score mapping table, the domain sensitivity score of the resource requester is determined. If the credibility score is less than or equal to the credibility score threshold and / or the domain sensitivity score is less than or equal to the domain sensitivity score threshold, a prompt message is sent to the resource returner; the prompt message is used to indicate that the resource returner's resource return plan generation request failed.

9. A resource return plan generation device, characterized in that, include: The acquisition module is used to acquire the resource return plan generation request from the resource return party for the target resource; The resource return plan generation request includes: resource status data of the resource returner and at least one resource return proposal; the resource return proposal includes: resource return period, resource return method, resource return amount, and amount recalculation identifier; wherein, the amount recalculation identifier is used to indicate whether the resource return amount of the current resource return proposal is recalculated when the amount recalculation condition is triggered; the amount recalculation condition includes: the resource returner returns resources in advance or the resource usage cost coefficient of the returned resources is updated; The processing module is used to verify each resource return proposal based on the resource status data of the resource return party, and determine the verification result corresponding to each resource return proposal; from the resource return proposals, the resource return proposals with the verification result of passing are determined as target resource return proposals; and based on each target resource return proposal, a resource return plan for the target resource is generated by the resource return party.

10. A resource return plan generation device, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the resource return plan generation device performs the method as described in any one of claims 1-8.

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

12. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1-8.

Images