Transaction implementation method and apparatus, device, and storage medium

Abstract

Embodiments of the present application provide a transaction implementation method and apparatus, a device, and a storage medium. A method applied to a first transaction server comprises: in response to a project registration operation of a registered user, determining, on the basis of idle resource information of the registered user, a resource transaction record of the registered user corresponding to a target project; reporting the resource transaction record and a yield rate file of the target project to a second transaction server, so that the second transaction server generates a project transaction record on the basis of resource transaction records of different registered users corresponding to the target project and triggers a project transaction of the target project, and in response to project transaction execution success information, updates a gain resource amount of the registered user on the basis of the yield rate file of the target project; and updating the idle resource information of the registered user. In the embodiments of the present application, comprehensive resource transactions for any registered user are implemented from the dimension of a target project, thereby ensuring the flexibility and accuracy of transaction implementation.

Description

A transaction implementation method, apparatus, device, and storage medium

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411560735.X, filed on November 4, 2024, entitled "A Transaction Realization Method, Apparatus, Device and Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of data processing technology, specifically to a transaction implementation method, apparatus, device, and storage medium. Background Technology

[0004] In investment and trading scenarios of various financial products, clients with some idle cash assets in their brokerage accounts usually use a cash management service system provided by the brokerage to reinvest the client's idle funds into profitable financial products in order to maximize the value and benefits of the idle funds.

[0005] However, the current cash management service system uses relatively limited transaction methods and cannot meet the normal transaction needs of various diversified investment scenarios. Summary of the Invention

[0006] This application provides a transaction implementation method, apparatus, device, and storage medium, enabling any registered user to conduct comprehensive transactions in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources from the perspective of the target project, ensuring the flexibility and accuracy of transaction implementation.

[0007] In a first aspect, embodiments of this application provide a transaction implementation method, which is applied to a first transaction server and includes:

[0008] Obtain information on the idle resources of registered users;

[0009] In response to the project registration operation of the registered user, the resource transaction records of the registered user in the target project are determined based on the idle resource information of the registered user;

[0010] The resource transaction records and the interest rate file of the target project are reported to the second transaction server so that the second transaction server can generate project transaction records based on the resource transaction records of different registered users corresponding to the target project and trigger the project transaction of the target project. In response to the project transaction execution success information, the registered users' gain resource amount is updated according to the interest rate file of the target project.

[0011] Receive the amount of gain resources of registered users under the target project returned by the second transaction server, and update the idle resource information of the registered users.

[0012] Secondly, embodiments of this application provide a transaction implementation method, which is applied to a second transaction server and includes:

[0013] Receive resource transaction records of different registered users in the target project and interest rate files of the target project reported by the first transaction server;

[0014] Based on the resource transaction records of different registered users corresponding to the target project, generate corresponding project transaction records and trigger project transactions for the target project;

[0015] In response to the successful execution of the project transaction, the gain resource amount of each of the registered users is updated according to the interest rate file of the target project;

[0016] The gain resource amount of each registered user is returned to the first transaction server so that the first transaction server updates the idle resource information of the registered users according to the gain resource amount.

[0017] Thirdly, embodiments of this application provide a transaction implementation apparatus, which is configured on a first transaction server and includes:

[0018] The idle resource acquisition module is used to acquire idle resource information of registered users;

[0019] The resource transaction module is used to respond to the project registration operation of the registered user and determine the resource transaction record of the registered user in the target project based on the idle resource information of the registered user.

[0020] The first project transaction module is used to report the resource transaction records and the interest rate file of the target project to the second transaction server, so that the second transaction server generates project transaction records based on the resource transaction records of different registered users corresponding to the target project and triggers the project transaction of the target project. In response to the project transaction execution success information, the module updates the gain resource amount of the registered users according to the interest rate file of the target project.

[0021] The first idle resource update module is used to receive the amount of gain resources of registered users under the target project returned by the second transaction server, and update the idle resource information of the registered users.

[0022] Fourthly, embodiments of this application provide a transaction implementation apparatus, which is configured on a second transaction server and includes:

[0023] The resource transaction record receiving module is used to receive resource transaction records of different registered users in the target project and the interest rate file of the target project reported by the first transaction server.

[0024] The second project transaction module is used to generate corresponding project transaction records based on the resource transaction records of different registered users for the target project, and to trigger project transactions for the target project.

[0025] The gain resource update module is used to update the gain resource amount of each registered user according to the interest rate file of the target project in response to the successful execution information of the project transaction;

[0026] The second idle resource update module is used to return the amount of gain resources of each registered user to the first transaction server, so that the first transaction server updates the idle resource information of the registered users according to the amount of gain resources.

[0027] Fifthly, embodiments of this application provide an electronic device, which includes:

[0028] A processor and a memory, the memory being used to store a computer program, and the processor being used to invoke and run the computer program stored in the memory to execute the transaction implementation methods provided in the first and second aspects of this application.

[0029] Sixthly, embodiments of this application provide a computer-readable storage medium for storing a computer program that causes a computer to execute the transaction implementation methods provided in the first and second aspects of this application.

[0030] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the transaction implementation methods provided in the first and second aspects of this application.

[0031] The technical solution provided in this application embodiment involves a first transaction server that acquires the idle resource information of registered users in real time. Upon detecting a registered user's project registration operation, the first server determines the resource transaction record corresponding to the registered user's registered target project based on the idle resource information. Then, the first server reports the resource transaction record and the target project's interest rate file to a second transaction server. This allows the second server to generate a project transaction record based on the resource transaction records of different registered users for that target project and trigger the project transaction. After the project transaction is successfully executed, the first server can update the gain resource amount of each registered user according to the target project's interest rate file. When the first transaction server receives the gain resource amount of a registered user under that target project from the second transaction server, it can update the registered user's idle resource information accordingly. From the perspective of the target project, this completes the entire transaction process for a registered user using any idle resource to initiate any transaction target, enabling comprehensive transactions for any registered user in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 is a schematic diagram illustrating the principle of transaction implementation by the first and second transaction servers provided in the embodiments of this application;

[0034] Figure 2 is a flowchart of a transaction implementation method provided in an embodiment of this application;

[0035] Figure 3 is a flowchart of another transaction implementation method provided in an embodiment of this application;

[0036] Figure 4 is a flowchart of the transaction interaction process between the first transaction server and the second transaction server provided in an embodiment of this application.

[0037] Figure 5 is a schematic block diagram of a transaction realization device provided in an embodiment of this application;

[0038] Figure 6 is a schematic block diagram of another transaction implementation device provided in an embodiment of this application;

[0039] Figure 7 is a schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0041] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0042] In various business investment and trading scenarios, users can leverage a cash management service system provided by a broker to reinvest their idle resources into financial products represented by various trading instruments, thereby maximizing the value and benefits of these idle resources. The trading instruments can be financial products such as stocks, funds, and options, or combinations of one or more of these products. Idle resources can include balance information in different currencies across various accounts that can be used to trade these trading instruments.

[0043] Considering that customers' idle resources may exist in various forms, such as multiple currencies, and support investment in financial products represented by multiple trading instruments, this application introduces the concept of "target projects" to enable comprehensive trading for any user in diversified trading scenarios consisting of multiple trading instruments and multiple idle resources. When a customer initiates a transaction using idle resources of a certain currency against a specific trading instrument, the transaction can be added to a corresponding target project based on the currency type of the idle resources used and the specific trading instrument. Each pre-deployed target project can operate independently. Therefore, this application can accurately implement the specific transaction process initiated by any user each time they use any type of idle resource against any type of trading instrument, from the perspective of target projects.

[0044] It is understandable that the entire transaction process of reinvesting a client's idle resources in any financial product can be considered as the whole process from the initiation of the transaction to the distribution of corresponding returns to the client after the transaction is successful. Therefore, to ensure the efficiency and accuracy of the transaction, as shown in Figure 1, a cash management service system provided by a brokerage firm can include two parts: a first transaction server and a second transaction server.

[0045] The first transaction server can act as a custodian of customers' idle resources, providing corresponding management solutions such as resource balance, interest rate, interest calculation calendar, dividend payment, and view services. The second transaction server can act as an upstream service of the first transaction server, providing corresponding transaction, interest calculation, and dividend payment capabilities for any transaction initiated by the first transaction server for customers' idle resources.

[0046] Specifically, in order to ensure the accuracy of transactions between the first and second transaction servers, the various transaction functions supported by the first and second transaction servers can be broken down into multiple functional modules within each server, thereby ensuring the accurate execution of transactions.

[0047] The functional modules within the first and second transaction servers can be described in detail from the following two aspects:

[0048] Firstly, regarding the first transaction server, based on the requirements of internal functional cohesion and clear boundaries between services, and according to the different service functions and target audiences, the services of the first transaction server can be divided into two layers: a core business layer and a presentation layer. The core business layer may include functional modules such as the first customer management service, customer balance management service, first project management service, calendar service, upstream report storage service, operational report service, dividend distribution service, and first interactive scripts. The presentation layer may include functional modules such as the first management backend view service and client view service.

[0049] Specifically, as shown in Figure 1, the specific service functions of each functional module within the first transaction server can be as follows:

[0050] 1) First Customer Management Service

[0051] The first customer management service can be used to manage the registration (i.e., joining) and exit status of various customers, providing interfaces for customer registration and exit, and supporting the configuration of specific customer packages to manage the whitelist of various target projects.

[0052] 2) Customer Balance Management Service

[0053] The customer balance management service can be used to manage the resource balances of various customers in different currencies. Then, based on each customer's balance and registration status, corresponding transaction records can be automatically generated to reinvest the customer's idle resources. Furthermore, the customer balance management service can interact with upstream reporting and storage services to reconcile the resource balances of various customers and update the balances after reconciliation.

[0054] To ensure the accurate implementation of customer balance management services, multiple external interfaces can be provided to implement various reconciliation functions for customers' idle resource balances.

[0055] 3) First Project Management Services

[0056] The target project is a key new entity added to the cash management service system, and each target project can operate independently. Furthermore, each target project has its own registered clients, allowing for independent management of transactions, interest calculation, and balances. Therefore, the first project management service can abstract the entity of the target project and manage each target project entity to support the creation and updating of target projects. This allows the first transaction server to more flexibly configure target project attributes and adapt to the business market needs of different clients.

[0057] 4) Calendar service

[0058] The calendar service can be used to manage the transaction calendar and dividend calendar for each underlying asset. The transaction calendar can at least mark the transaction days for each underlying asset, and the dividend calendar can at least mark the dividend payment days for each underlying asset.

[0059] 5) Upstream report storage service

[0060] In the transaction process, to support the second transaction server in accurately processing any transaction initiated by the first transaction server, including transaction execution, interest calculation, and interest payment, the first transaction server typically sends the customer's registration documents, transaction documents, and relevant interest rate documents to the second transaction server to perform the corresponding transaction calculation operations. However, considering document compliance and auditing issues, the upstream reports from the second transaction server after transaction processing need to be stored on the first transaction server.

[0061] However, since upstream reports are neither part of customer management nor can they be categorized under project management, the upstream report storage service on the first transaction server side can support database storage of upstream reports, provide read and write capabilities for upstream reports, and provide corresponding read, transaction, and registration logic for customer balance management services, as well as query capabilities for the local database.

[0062] 6) Operational Reporting Service

[0063] Internal management personnel have a need to view operational reports at the transaction day and customer levels. Neither the primary customer management service nor the customer balance management service can handle this cross-boundary demand. Therefore, an independent operational reporting service was created on the primary transaction service side to manage aggregated data reports on customer, customer balance, and target projects, thereby generating operational-related report data.

[0064] 7) Dividend Payment Service

[0065] Dividend distribution services can be used to distribute the revenue generated from a client's idle resources during upstream transactions to the client, that is, to distribute the client's trading revenue to the corresponding securities account.

[0066] The dividend distribution service can primarily be implemented using Python's SBA technology, supporting the distribution of trading revenue resources obtained from corresponding projects within the cash management service system to clients. The first trading server needs to consider scenarios where dividends are distributed to clients based on the underlying projects, and where a certain fee (e.g., tax deduction) needs to be charged to clients.

[0067] Therefore, the dividend distribution service can use program_id to represent the target project of this dividend distribution, gross_amount to represent the initial dividend distribution resource amount before collection, and withholding_tax to represent the dividend collection information corresponding to this dividend distribution.

[0068] 8) First Interactive Script

[0069] The first interaction script handles data exchange between the first and second trading servers, using the Secure File Transfer Protocol (SFTP). This allows the first interaction script to convert the internal system data of the first trading server into a standard file definition format for interaction with the second trading server, without exposing the implementation details of the first trading server's internal data. The first interaction script supports sending data such as customer registration files, transaction files, and related interest rate files (denoted as Outbound), and also supports processing upstream reports from the second trading server, such as balance reports, balance allocations, dividend payment files, and transaction item interest rate files (denoted as Inbound).

[0070] The first interactive script can obtain all target projects (including expired target projects) from the first project management service, and determine whether the report of each target project has been completed or whether the output file of the target project has been interrupted (outbound cut-off). It then obtains the relevant project data for the completed or interrupted target projects to generate the transaction attribute file of the target project and sends it to the second transaction server.

[0071] 9) First Management Backend View Service

[0072] The first management backend view service is a service that interfaces with the web management backend. It relies on the interfaces provided by the core business services within the first transaction server to provide external services. It can aggregate the capabilities of the core business services and provide them to the administrator, while handling the display logic that the core business services are not concerned with. Therefore, the management backend view service can be extracted from the first transaction server.

[0073] 10) Client-side view service

[0074] For customers, the need to view data aggregation such as registration status and balance details on the front end is very common. Therefore, a client-side view service can be added to the first transaction server, providing the following interface: pull transaction service data from the first transaction server, integrate it, and then provide it to the client. The client-side view service can provide a middleware layer, achieving separation of front-end and back-end services within the first transaction server.

[0075] Secondly, for the second transaction service, based on the requirements of internal functional cohesion and clear boundaries between services, and according to the different service functions and target objects, the services of the second transaction service can also be divided into two layers: a core business layer and a presentation layer. The core business layer may include functional modules such as second customer management services, second project management services, reporting services, transaction management services, and second interactive scripts, while the presentation layer may include second management backend view services.

[0076] Specifically, as shown in Figure 1, the specific service functions of each functional module within the second transaction server can be as follows:

[0077] 1) Second Customer Management Service

[0078] Customers on the first transaction server need to register their customer information on the second transaction server. Therefore, the second customer management service can be responsible for managing customer registration information, as well as the list of accounts under each customer and customer interest rate tier information, etc.

[0079] 2) Second Project Management Services

[0080] The target project is a crucial new entity added to the cash management service system, and each target project can operate independently. Furthermore, each target project has its own registered clients, allowing for independent management of transactions, interest calculation, and balances for those clients. Therefore, the second project management service can abstract the entity of the target project and manage each target project entity.

[0081] 3) Reporting Services

[0082] The first transaction server typically sends the client's registration documents, transaction documents, and relevant interest rate documents to the second transaction server to perform the corresponding transaction calculations. However, considering document compliance and auditing issues, the second transaction server generates report data after transaction processing, and this report data needs to be stored locally.

[0083] However, since the report data does not belong to customer management or can be classified into transaction project management, the reporting service of the second transaction server can support database storage of upstream reports, provide read and write capabilities for upstream reports, and provide corresponding read, transaction, and registration logic for transaction management services and second customer management services, as well as provide query capabilities for the local database.

[0084] 4) Transaction Management Services

[0085] The transaction management service is the core of the entire second-party transaction server, used to process subscription / redemption transactions initiated by clients. Since a client's idle resources accrue interest according to their tiered benefits, the service manages the resource balances of each client's underlying assets. At this point, the underlying assets, the client's resource balance, and the interest accrued on the balance are all generated by the transaction activity; the transaction is the action, and the resources are the post-transaction state. Therefore, the second-party transaction server can extract the transaction management service to uniformly manage various transaction activities, involving the core processing logic of transactions and client resources.

[0086] 5) Second interactive script

[0087] The second interaction script handles data exchange between the first and second trading servers, using SFTP. This script converts the second trading server's internal system data into a standard file definition format for interaction with the first trading server, without exposing the implementation details of the second trading server's internal data. The second interaction script can process data from the first trading server, such as customer registration files, transaction files, and related interest rate files (denoted as Inbound), and can also return data to the first trading server, such as confirmation reports, balance allocations, dividend files, and transaction interest rate files (denoted as Outbound).

[0088] 6) Second Management Backend View Service

[0089] The second management backend view service is a service that interfaces with the web management backend. It relies on the interfaces provided by the core business services within the second transaction service to provide external services. It can aggregate the capabilities of the core business services and provide them to the administrator, while handling the display logic that the core business services are not concerned with. Therefore, the management backend view service can be extracted from the second transaction service.

[0090] In summary, to ensure flexible and accurate transaction execution, this application can analyze the idle resources used by a user in each transaction and the reinvested trading targets, thereby registering the user with a corresponding target project. Then, from the perspective of the target project, through data interaction between the first and second trading servers, the entire transaction process is executed, allowing the user to reinvest their idle resources in a specific currency into financial products represented by any trading target. This enables comprehensive trading for any user in a diversified trading scenario consisting of multiple trading targets and multiple idle resources.

[0091] The following section will elaborate on the specific transaction processes executed by the first and second transaction servers.

[0092] Figure 2 is a flowchart of a transaction implementation method provided in an embodiment of this application. This method can be applied to a first transaction server and executed by a transaction implementation device configured on the first transaction server, as provided in this application. The transaction implementation device configured on the first transaction server can be implemented using any software and / or hardware method. The first transaction server can include, but is not limited to, various electronic devices such as ultra-mobile personal computers (UMPCs), netbooks, large servers, and computing clusters; this application does not impose any restrictions on the specific type of the first transaction server.

[0093] Specifically, as shown in Figure 2, the method may include the following steps:

[0094] S210, obtain information on the idle resources of registered users.

[0095] Registered users refer to clients who have registered through the investment trading application (App) and are supported in trading various trading instruments. Idle resource information includes the types and quantities of idle resources; for example, idle resources may refer to the account balance of a registered user's account, the type of idle resources may refer to the currency of the account balance, such as including but not limited to RMB, GBP, USD, etc., and the quantity of resources may refer to the value corresponding to the account balance.

[0096] It is understandable that any transaction initiated by a registered user can be the entire process of reinvesting the user's idle resources in a financial product represented by a specific trading instrument. A registered user's idle resources may be of various types, such as multiple currencies, and support investment in financial products represented by multiple trading instruments.

[0097] Therefore, in order to ensure the successful completion of any transaction by any registered user, this application will analyze the remaining idle resources of each registered user in real time for different types of idle resources, in order to obtain the idle resource information of the registered user, so as to determine whether the idle resources of the registered user support the initiation of a corresponding transaction for a certain target project.

[0098] S220, in response to the project registration operation of a registered user, determines the resource transaction record of the registered user in the target project based on the idle resource information of the registered user.

[0099] Considering that each registered user possesses multiple types of idle resources, and that these idle resources can be traded on various tradable targets, it is clear that each registered user has corresponding trading needs within a diversified trading scenario comprised of multiple tradable targets and idle resources. Therefore, to enable any registered user to engage in comprehensive trading within this diversified scenario, this application can introduce the concept of a target project. Each target project can represent a project in which a registered user initiates a transaction using a specific type of idle resource on a specific tradable target.

[0100] Specifically, based on the various idle resources available to each registered user during each transaction and the various transaction targets that can be supported, multiple target projects can be pre-deployed, and each target project can run independently. Therefore, this application can accurately analyze the specific transaction process initiated by any registered user each time they use any type of idle resource to target any transaction from the perspective of the target project.

[0101] Specifically, the client can display the project registration interface to registered users through a visual interface and receive project registration operations from registered users through the client's project registration interface. After receiving the project registration operation from a registered user through the client, the first transaction server can determine the target project joined by the registered user based on the type of idle resources in the registered user's idle resource information, and determine the actual usage of idle resources in the target project based on the quantity of idle resources of the corresponding resource type, thereby generating the resource transaction record corresponding to the target project.

[0102] For example, the idle resource information of a registered user includes idle resource A with a resource quantity of value A and resource type A, and idle resource B with a resource quantity of value B and resource type B. After receiving the project registration operation corresponding to the registered user, the target project joined by the registered user can be determined according to the resource type of the idle resource in the idle resource information of the registered user. The target project is target project A corresponding to resource type A and target project B corresponding to resource type B. At the same time, the actual idle resource usage (i.e., value A) corresponding to target project A is determined according to the resource quantity corresponding to idle resource A, and the actual idle resource usage (i.e., value B) corresponding to target project B is determined according to the resource quantity corresponding to idle resource B.

[0103] Furthermore, in one embodiment, for any registered user, after obtaining the registered user's idle resource information, the system can first analyze whether any type of idle resource of the registered user supports initiating a corresponding transaction for a certain transaction target. Upon confirming that the registered user can use a certain type of idle resource to initiate a corresponding transaction for a certain transaction target, this application can add the registered user to a corresponding target project according to the specific type of idle resource used by the registered user and the specific transaction target of this transaction, thereby generating a project registration operation for the registered user.

[0104] Then, in response to the project registration operation of a registered user, the target project corresponding to the registered user can be determined first. By analyzing the registered user's idle resource information and the actual usage of idle resources and the actual transaction targets involved when the registered user joins the target project, the resource transaction records corresponding to the registered user in that target project can be determined.

[0105] In some feasible implementations, each independently operating project is deployed to different transaction targets and different types of idle resources. Therefore, this application can determine the resource transaction records of registered users corresponding to a particular project by: obtaining the resource type corresponding to the project; obtaining the resource quantity of the target idle resources of the registered user under the resource type corresponding to the project based on the idle resource information of the registered user; and constructing the resource transaction records of the registered user corresponding to the project based on the resource quantity of the target idle resources and the project operation information.

[0106] For the projects registered by registered users, this application first determines the resource type corresponding to the project, thereby determining which type of idle resources the registered user is using in this transaction. Then, by analyzing the idle resource information of registered users, the target idle resources of the registered user under the resource type corresponding to the project can be determined from various types of idle resources, and the quantity of the target idle resources, i.e., the balance information of the target idle resources, can be obtained to represent the actual amount of target idle resources used by the registered user in this transaction.

[0107] Furthermore, by analyzing the underlying assets of the target project, the underlying assets of the actual transactions by registered users can be determined. Then, by analyzing the actual transaction behavior of registered users using their idle resources to initiate transactions related to the underlying assets of the target project, the operational information of the target assets for each registered user can be determined. This operational information can at least include: information about registered users performing subscription or redemption operations on the underlying assets of the target project using their idle resources.

[0108] By comprehensively analyzing the quantity of the target idle resources and the aforementioned operational information, the actual usage and actual transaction targets of the target idle resources by registered users when executing transactions under the target project are determined, thereby constructing the resource transaction records of registered users corresponding to the target project.

[0109] S230, the resource transaction records and the interest rate file of the target project are reported to the second transaction server so that the second transaction server can generate project transaction records based on the resource transaction records of different registered users in the target project and trigger the project transaction of the target project. In response to the successful execution of the project transaction, the registered users' gain resource amount is updated according to the interest rate file of the target project.

[0110] Among them, the interest rate file contains resource return information in the target project, such as the resource rate of return in the target project; the second transaction service, as an upstream service of the first transaction service, can be used to analyze the specific returns of the idle resources of the client after the first transaction service joins the target project.

[0111] It is understandable that the idle resource yield standards supported by the transaction targets corresponding to different target projects may be different. Therefore, after determining the resource transaction records of registered users corresponding to the target project, this application can determine the interest rate document corresponding to the target project based on the transaction target of the target project. This interest rate document can describe the resource yield that can be obtained when the target project is traded.

[0112] Then, the registered user's resource transaction records for the target project and the interest rate document for the target project will be jointly reported to the second transaction server.

[0113] In particular, considering that multiple registered users may register at the same target project to initiate corresponding transactions, the second transaction server may simultaneously receive resource transaction records and interest rate files from multiple registered users for the same target project.

[0114] Therefore, to ensure comprehensive transactions for registered users across diverse transaction scenarios involving multiple trading targets and various idle resources, the second transaction server can aggregate the resource transaction records of different registered users for the same target project, resulting in a single overall resource transaction record, which serves as the project's transaction record. Then, based on the specific transaction operation information within this project's transaction record, the server can trigger and execute corresponding project transaction operations from the perspective of that specific target project.

[0115] Understandably, the specific resource returns for each registered user under a given project are typically only distributed to them after the project's successful execution. Therefore, after triggering the corresponding project transaction operation, the second transaction server will also determine in real time whether the project transaction was successfully executed. Furthermore, upon detecting successful transaction information and confirming that the project has been successfully completed, the second transaction server can analyze the project's interest rate file and, combined with the actual usage of idle resources corresponding to the project by each registered user during the transaction, obtain the specific resource returns for each registered user after the successful transaction, thereby determining the amount of resource gain for each registered user.

[0116] In some implementation methods, considering that each time a registered user joins a project to initiate a transaction using a certain type of idle resources, whether the project successfully completes the transaction depends on whether the issuing server of the project initiates corresponding resource settlement for this transaction. Therefore, after the first transaction server reports the registered user's resource transaction record for the project and the project's interest rate file to the second transaction server, in order to enable the second transaction server to accurately know whether the project has successfully completed the transaction, the first transaction server in this application can also receive the project transaction record returned by the second transaction server; send the project transaction instruction to the issuing server of the project based on the project transaction record; receive the transaction success indication information returned by the issuing server; and report the project transaction execution success information to the second transaction server based on the transaction success indication information, so that the second transaction server updates the registered user's gain resource amount according to the project's interest rate file in response to the project transaction execution success information.

[0117] Specifically, after the first transaction server reports the resource transaction records of registered users for the target project and the interest rate document of the target project to the second transaction server, the second transaction server will summarize the resource transaction records of different registered users for the same target project to obtain a total resource transaction record, which will serve as the project transaction record for the target project.

[0118] Considering that the successful completion of a transaction for any given project depends on whether the issuing server of the corresponding project initiates resource settlement for that transaction, and since the second transaction server, as an upstream service of the first transaction server, does not directly trigger the issuing server of the project to perform any operations, the second transaction server aggregates the resource transaction records of different registered users for the same project into a single project transaction record. This project transaction record can then be returned to the first transaction server, instructing the first transaction server to trigger the issuing server of the project to execute the corresponding project transaction operation.

[0119] Therefore, when a registered user joins any project, the first transaction server can receive the project's transaction record returned by the second transaction server, thus knowing that a corresponding transaction needs to be performed for that project. Then, the first transaction server parses the project's transaction record to determine the amount of idle resources used by each registered user during the specific transaction, thereby generating a project transaction instruction. This instruction can include the specific amount of idle resources that need to be settled by the registered user during the project transaction. Then, the first transaction server can send the project transaction instruction to the corresponding project issuing server, enabling the issuing server to perform the corresponding resource settlement operation for this project transaction, thereby executing the project transaction.

[0120] To accurately analyze whether the project transaction has been successfully completed, the issuing server can analyze the specific resource settlement results for the project. Once the resource settlement for the project has been successfully completed, the issuing server generates a corresponding transaction success indication and returns it to the first transaction server. This indication indicates that the project transaction has been successfully executed. Upon receiving the transaction success indication from the issuing server, the first transaction server can parse it to determine that the project transaction has been successfully completed, and thus generate a project transaction execution success message. Then, the first transaction server can report the successful execution information of the project transaction to the second transaction server. When the second transaction server receives the successful execution information of the project transaction, it can confirm that the project transaction has been successfully completed. By analyzing the interest rate file of the project and combining it with the actual usage of the idle resources corresponding to the project by each registered user when executing the transaction, it can determine the specific resource benefits brought to each registered user after the successful transaction of the project, thereby determining the amount of resource gain for each registered user.

[0121] S240, Receive the amount of gain resources of registered users under the target project returned by the second transaction server, and update the idle resource information of registered users.

[0122] After determining the gain resources of each registered user within the project through the second transaction server, to ensure that the project brings corresponding resource benefits to each registered user after a successful transaction, the second transaction server can return the gain resources of each registered user within the project to the first transaction server. The first transaction server then receives the gain resources of each registered user under the project returned by the second transaction server, adds the gain resources of each registered user to the original idle resource quantity of each registered user under the project, and obtains the latest idle resource quantity of each registered user after a successful transaction, thereby updating the idle resource information of the registered users and ensuring accurate distribution of dividends to each registered user after a successful transaction.

[0123] In some feasible implementations, considering that registered users typically need to remit a portion of the resource revenue generated by the project when they join a corresponding target project, this ensures that registered users can enjoy certain benefits. Therefore, this application can update the idle resource information of registered users in the following way: receiving the amount of gain resources of registered users under the target project returned by the second transaction server; updating the idle resource information of registered users based on the amount of gain resources of registered users under the target project and the resource collection information of registered users.

[0124] Specifically, the first transaction server can receive the amount of gain resources for each registered user under the target project from the second transaction server, thereby knowing the specific resource benefits brought to each registered user after the successful transaction of the target project. In order to accurately analyze the revenue contribution of registered users when they obtain resource benefits by joining the target project, this application can set up a resource collection information to represent the resource revenue contribution ratio of registered users, and different registered users have different resource collection information.

[0125] After receiving the resource gain amounts of each registered user under the target project from the second transaction server, the first transaction server can determine the resource revenue contribution ratio of each registered user by analyzing their resource collection information. Then, by multiplying the resource gain amount of each registered user under the target project by their resource revenue contribution ratio, the actual resource revenue amount actually received by the registered user can be determined and added to the registered user's original idle resource amount to update the registered user's idle resource information.

[0126] The technical solution provided in this application embodiment involves a first transaction server that acquires the idle resource information of registered users in real time. Upon detecting a registered user's project registration operation, the first server determines the resource transaction record corresponding to the registered user's registered target project based on the idle resource information. Then, the first server reports the resource transaction record and the target project's interest rate file to a second transaction server. This allows the second server to generate a project transaction record based on the resource transaction records of different registered users for that target project and trigger the project transaction. After the project transaction is successfully executed, the first server can update the gain resource amount of each registered user according to the target project's interest rate file. When the first transaction server receives the gain resource amount of a registered user under that target project from the second transaction server, it can update the registered user's idle resource information accordingly. From the perspective of the target project, this completes the entire transaction process for a registered user using any idle resource to initiate any transaction target, enabling comprehensive transactions for any registered user in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation.

[0127] Figure 3 is a flowchart of another transaction implementation method provided in an embodiment of this application. This method can be applied to a second transaction server and executed by the transaction implementation device configured on the second transaction server provided in this application. The transaction implementation device configured on the second transaction server can be implemented in any software and / or hardware manner. The second transaction server can include, but is not limited to, various electronic devices such as laptops, ultra-mobile personal computers (UMPCs), netbooks, and large servers; this application does not impose any restrictions on the specific type of the second transaction server.

[0128] Specifically, as shown in Figure 3, the method may include the following steps:

[0129] S310 receives resource transaction records and interest rate files of the target project from different registered users reported by the first transaction server.

[0130] In this application, to enable any registered user to conduct comprehensive transactions in a diversified transaction scenario comprising multiple trading targets and multiple idle resources, the concept of a target project can be introduced. Specifically, based on the various idle resources available to each registered user and the various trading targets that can support transactions in each transaction, multiple target projects can be pre-deployed, and each target project can run independently. Therefore, this application can accurately analyze the specific transaction process initiated by any registered user each time they use any idle resource to target any trading target, from the perspective of target projects.

[0131] Once the first transaction server detects that a registered user has joined a project, it analyzes the registered user's idle resource information, the actual usage of idle resources, and the actual transaction targets involved when the user joins the project to determine the registered user's resource transaction record for that project. Considering that registered users receive certain idle resource revenue with each transaction, and the second transaction server, as an upstream service of the first transaction server, typically analyzes the specific revenue from idle resources for each customer transaction by the first transaction server. Therefore, the first transaction server reports the registered user's resource transaction record for that project, along with the corresponding interest rate document, to the second transaction server, which then analyzes the registered user's specific resource revenue under that project.

[0132] Therefore, after a registered user joins a project and initiates a corresponding transaction, considering that there may be multiple registered users registering to the same project at the same time and initiating corresponding transactions, the second transaction server will receive the resource transaction records of multiple different registered users corresponding to the project and the interest rate file of the project reported by the first transaction server, so that the second transaction server can analyze the specific resource income of the registered user under the project.

[0133] S320 generates corresponding project transaction records based on the resource transaction records of different registered users in the target project, and triggers the project transaction of the target project.

[0134] To ensure comprehensive transactions for registered users across diverse transaction scenarios involving multiple trading targets and idle resources, the second transaction server can aggregate the resource transaction records of different registered users for the same target project, creating a single overall resource transaction record to generate the project's transaction record. Then, based on the specific transaction operation information within this project's transaction record, the server triggers and executes corresponding project transaction operations from the perspective of that specific target project.

[0135] Understandably, the specific resource rewards for each registered user under a given project are typically only distributed to them after the project has been successfully executed. Therefore, after triggering the corresponding project transaction operation for that project, the second transaction server will also determine in real time whether the project transaction has been successfully executed.

[0136] Considering that each time a registered user joins a project to initiate a transaction using a certain type of idle resources, the specific transaction operation for that project typically involves the issuing server of the project executing the corresponding resource settlement operation. Therefore, the second transaction server triggering the project transaction can specifically involve: returning the project transaction record to the first transaction server, so that the first transaction server can send the project transaction instruction to the issuing server of the project based on the transaction record, and receive the transaction success indication information returned by the issuing server; and receiving the project transaction execution success information reported by the first transaction server based on the transaction success indication information.

[0137] Specifically, after the second transaction server aggregates the resource transaction records of different registered users for the same target project to generate the project transaction record, it can return the project transaction record to the first transaction server to instruct the first transaction server to trigger the target issuance server corresponding to the target project to execute the corresponding project transaction operation.

[0138] After receiving the project transaction records for the target project from the second transaction server, the first transaction server can parse these records to determine the idle resource usage of each registered user during the specific transactions for that target project. This allows the first server to generate a project transaction instruction, which may include the specific amount of idle resources that need to be settled by registered users during the transaction. The first transaction server then sends this project transaction instruction to the corresponding target project issuing server, enabling the issuing server to execute the corresponding resource settlement operation for that project's transaction, thus completing the transaction execution.

[0139] To accurately analyze whether a project transaction has been successfully completed, the issuing service can analyze the specific resource settlement results for that project. Once the resource settlement for the project has been successfully completed, the issuing service generates a successful transaction indication and returns it to the first transaction service. This indication indicates that the project transaction has been successfully executed. Upon receiving this indication, the first transaction service parses it to confirm the successful completion of the project transaction. It then generates a successful transaction information report and sends it to the second transaction service. The second transaction service then receives this report from the first transaction service, confirming that the project transaction has been successfully completed.

[0140] S330, in response to the successful execution of the project transaction, updates the gain resources of each registered user according to the interest rate document of the target project.

[0141] After triggering the corresponding transaction operation for the target project, the second transaction server will determine in real time whether the transaction has been successfully executed. Upon detecting successful transaction information and confirming that the project has been successfully completed, the second transaction server can analyze the project's interest rate file and, combined with the actual usage of idle resources corresponding to the project by each registered user, determine the specific resource gains for each registered user after the successful transaction. This allows the server to determine the amount of resource gain for each registered user.

[0142] In some feasible implementations, because the returns of different target projects vary on the trading day—for example, some target projects will not generate new returns on the trading day, while others will—the second trading server updates the gain resource amount of each registered user based on the interest rate file of the target project. Specifically, this can be done by: responding to the successful execution information of the project transaction, determining the latest gain resource amount of the target project on the current trading day; and updating the gain resource amount of each registered user based on the latest gain resource amount and the interest rate file of the target project.

[0143] Specifically, when the second transaction server receives the successful execution information for a project, it can confirm that the project has been successfully executed. The second transaction server first needs to determine if there are any new resource gains for the corresponding transaction target on the current trading day to determine the latest resource gain amount for the project on that day. Then, by settling the revenue from the latest resource gain amount for the project on the current trading day, it can update the idle resource balance information of registered users. Furthermore, the second transaction server analyzes the interest rate file of the project and combines it with the idle resource balance information of each registered user when executing a transaction under that project to determine the specific resource gains brought to each registered user after the successful transaction, thereby determining the resource gain amount for each registered user.

[0144] S340, return the gain resource amount of each registered user to the first transaction server so that the first transaction server can update the idle resource information of the registered users according to the gain resource amount.

[0145] After determining the amount of gain resources for each registered user under the target project, the second transaction server can return the amount of gain resources for each registered user already registered under the target project to the first transaction server in order to ensure that the target project brings corresponding resource benefits to each registered user after a successful transaction. Upon receiving the amount of gain resources for each registered user under the target project returned by the second transaction server, the first transaction server can update the idle resource information of each registered user by adding the amount of gain resources for each registered user under the target project to the original idle resource quantity of each registered user. This ensures accurate distribution of dividends to each registered user after a successful transaction.

[0146] The technical solution provided in this application embodiment involves a second transaction server receiving resource transaction records and interest rate files for different registered users in a target project from the first transaction server. Based on these records, the second transaction server generates a project transaction record and triggers a project transaction for that target project. After successful execution of the project transaction, the second transaction server updates the gain resource amount of each registered user according to the interest rate file of the target project. The first transaction server then updates the idle resource information of the registered users based on the gain resource amount returned by the second transaction server for that target project. This completes the entire transaction process from the perspective of the target project, enabling registered users to initiate transactions using any type of idle resource for any type of transaction target. This achieves comprehensive transactions for any registered user in diversified transaction scenarios involving multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation.

[0147] Figure 4 is a flowchart of the transaction interaction process between the first transaction server and the second transaction server provided in an embodiment of this application. The method may specifically include the following steps:

[0148] S401, the first transaction server obtains the idle resource information of registered users and responds to the project registration operation of registered users. Based on the idle resource information of registered users, it determines the resource transaction records of registered users in the target project.

[0149] S402, the first transaction server reports the resource transaction records and the interest rate documents of the target project to the second transaction server.

[0150] S403, the second transaction server generates corresponding project transaction records based on the resource transaction records of different registered users in the target project.

[0151] S404, the second transaction server returns the project transaction records of the target project to the first transaction server.

[0152] S405, the first transaction server sends the project transaction instruction of the target project to the target issuance server corresponding to the target project based on the project transaction record, and receives the transaction success indication information returned by the target issuance server.

[0153] S406, The first transaction server generates the corresponding project transaction execution success information based on the transaction success indication information.

[0154] S407, the first transaction server reports the successful execution information of the project transaction to the second transaction server.

[0155] S408, the second transaction server responds to the project transaction execution success information and determines the latest gain resource amount of the target project on the current transaction day.

[0156] S409, the second transaction server updates the gain resources of each registered user based on the latest gain resource amount and the interest rate file of the target project.

[0157] S410, the second transaction server returns the gain resources of each registered user to the first transaction server.

[0158] S411, the first transaction server updates the idle resource information of registered users based on the amount of gain resources of registered users under the target project and the resource collection information of registered users.

[0159] The technical solution provided in this application embodiment involves a first transaction server that acquires the idle resource information of registered users in real time. Upon detecting a registered user's project registration operation, the first server determines the resource transaction record corresponding to the registered user's registered target project based on the idle resource information. Then, the first server reports the resource transaction record and the target project's interest rate file to a second transaction server. This allows the second server to generate a project transaction record based on the resource transaction records of different registered users for that target project and trigger the project transaction. After the project transaction is successfully executed, the first server can update the gain resource amount of each registered user according to the target project's interest rate file. When the first transaction server receives the gain resource amount of a registered user under that target project from the second transaction server, it can update the registered user's idle resource information accordingly. From the perspective of the target project, this completes the entire transaction process for a registered user using any idle resource to initiate any transaction target, enabling comprehensive transactions for any registered user in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation.

[0160] Figure 5 is a schematic block diagram of a transaction implementation device provided in an embodiment of this application, configured on a first transaction server. As shown in Figure 5, the transaction implementation device 500 may include:

[0161] The idle resource acquisition module 510 is used to acquire idle resource information of registered users;

[0162] The resource transaction module 520 is used to respond to the project registration operation of the registered user and determine the resource transaction record of the registered user in the target project based on the idle resource information of the registered user.

[0163] The first project transaction module 530 is used to report the resource transaction records and the interest rate file of the target project to the second transaction server, so that the second transaction server generates project transaction records based on the resource transaction records of different registered users corresponding to the target project and triggers the project transaction of the target project. In response to the project transaction execution success information, the registered users' gain resource amount is updated according to the interest rate file of the target project.

[0164] The first idle resource update module 540 is used to receive the amount of gain resources of the registered users under the target project returned by the second transaction server, and update the idle resource information of the registered users.

[0165] In some possible implementations, the resource transaction module 520 can be specifically used for:

[0166] Obtain the resource type corresponding to the target project;

[0167] Based on the idle resource information of the registered users, obtain the number of target idle resources of the registered users under the resource type corresponding to the target project;

[0168] Based on the quantity of the target idle resources and the target operation information, construct the resource transaction records of the registered users corresponding to the target project.

[0169] In some implementation methods, the transaction realization apparatus may further include a project transaction determination module. This project transaction determination module can be used for:

[0170] Receive the project transaction records of the target project returned by the second transaction server;

[0171] Based on the project transaction records, the project transaction instruction for the target project is sent to the target issuance server corresponding to the target project;

[0172] The system receives a transaction success indication from the target issuance server and, based on the transaction success indication, reports the project transaction execution success information of the target project to the second transaction server, so that the second transaction server, in response to the project transaction execution success information, updates the gain resource amount of registered users according to the interest rate file of the target project.

[0173] In some possible implementations, the first idle resource update module 540 can be specifically used for:

[0174] Receive the amount of gain resources of the registered user under the target project returned by the second transaction server;

[0175] Update the idle resource information of the registered users based on the amount of gain resources of the registered users under the target project and the resource collection information of the registered users.

[0176] In this embodiment, the first transaction server acquires the idle resource information of registered users in real time. Upon detecting a registered user's project registration operation, it determines the resource transaction record corresponding to the registered user's registered target project based on the idle resource information. Then, it reports the resource transaction record and the interest rate file of the target project to the second transaction server. This allows the second transaction server to generate a project transaction record based on the resource transaction records of different registered users for that target project and trigger the project transaction for that target project. After the project transaction is successfully executed, the server can update the gain resource amount of each registered user according to the interest rate file of the target project. When the first transaction server receives the gain resource amount of a registered user under that target project from the second transaction server, it can update the idle resource information of the registered user accordingly. From the perspective of the target project, this completes the entire transaction process for a registered user using any idle resource to initiate any transaction target, enabling comprehensive transactions for any registered user in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation.

[0177] It should be understood that the device embodiments configured on the first transaction server and the method embodiments applied to the first transaction server can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, they will not be repeated here. Specifically, the transaction implementation device 500 shown in FIG5 can execute any of the method embodiments applied to the first transaction server provided in this application, and the foregoing and other operations and / or functions of each module in the transaction implementation device 500 are respectively for implementing the corresponding processes in the various methods applied to the first transaction server in the embodiments of this application. For the sake of brevity, they will not be repeated here.

[0178] The transaction implementation apparatus 500 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments applied to the transaction terminal in this application embodiment can be completed by the integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method applied to the transaction terminal in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0179] Figure 6 is a schematic block diagram of another transaction implementation device provided in an embodiment of this application, configured on a second transaction server. As shown in Figure 6, the transaction implementation device 600 may include:

[0180] The resource transaction record receiving module 610 is used to receive resource transaction records of different registered users in the target project and the interest rate file of the target project reported by the first transaction server.

[0181] The second project transaction module 620 is used to generate corresponding project transaction records based on the resource transaction records of different registered users corresponding to the target project, and to trigger the project transaction of the target project.

[0182] Gain resource update module 630 is used to update the gain resource amount of each registered user according to the interest rate file of the target project in response to the successful execution information of the project transaction;

[0183] The second idle resource update module 640 is used to return the gain resource amount of each registered user to the first transaction server so that the first transaction server updates the idle resource information of the registered users according to the gain resource amount.

[0184] In some possible implementations, the second project transaction module 620 can be specifically used for:

[0185] The project transaction record of the target project is returned to the first transaction server, so that the first transaction server sends the project transaction instruction of the target project to the target issuance server corresponding to the target project based on the project transaction record, and receives the transaction success indication information returned by the target issuance server.

[0186] Receive project transaction execution success information reported by the first transaction server based on the transaction success indication information.

[0187] In some implementations, the gain resource update module 630 can be specifically used for:

[0188] In response to the successful execution of the project transaction, determine the latest gain resource amount of the target project on the current transaction day;

[0189] Update the gain resource amount for each of the registered users based on the latest gain resource amount and the interest rate file of the target project.

[0190] In this embodiment, when the second transaction server receives the resource transaction records and interest rate files of different registered users corresponding to the target project from the first transaction server, it generates project transaction records based on the resource transaction records of different registered users corresponding to the target project and triggers the project transaction of the target project. After the project transaction is successfully executed, the gain resource amount of each registered user is updated according to the interest rate file of the target project. The first transaction server updates the idle resource information of the registered users according to the gain resource amount of the registered users under the target project returned by the second transaction server. From the perspective of the target project, the entire transaction process initiated by the registered user using any idle resource to any transaction target is completed. This enables any registered user to conduct comprehensive transactions in diversified transaction scenarios consisting of multiple transaction targets and multiple idle resources, ensuring the flexibility and accuracy of transaction implementation.

[0191] It should be understood that the device embodiments configured on the second transaction server and the method embodiments applied to the second transaction server can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, they will not be repeated here. Specifically, the transaction implementation device 600 shown in FIG6 can execute any of the method embodiments applied to the second transaction server provided in this application, and the foregoing and other operations and / or functions of each module in the transaction implementation device 600 are respectively for implementing the corresponding processes in the various methods applied to the second transaction server in the embodiments of this application. For the sake of brevity, they will not be repeated here.

[0192] The transaction implementation apparatus 600 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments applied to the transaction server in this application embodiment can be completed by the integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method applied to the transaction server in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0193] Figure 7 is a schematic block diagram of an electronic device provided in an embodiment of this application.

[0194] As shown in Figure 7, the electronic device 700 may include:

[0195] The system includes a memory 710 and a processor 720. The memory 710 stores computer programs and transfers the program code to the processor 720. In other words, the processor 720 can retrieve and run the computer program from the memory 710 to implement the methods described in the embodiments of this application.

[0196] For example, the processor 720 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0197] In some embodiments of this application, the processor 720 may include, but is not limited to:

[0198] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0199] In some embodiments of this application, the memory 710 includes, but is not limited to:

[0200] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0201] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 710 and executed by the processor 720 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0202] As shown in Figure 7, the electronic device may further include:

[0203] Transceiver 730, which can be connected to processor 720 or memory 710.

[0204] The processor 720 can control the transceiver 730 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 730 may include a transmitter and a receiver. The transceiver 730 may further include antennas, and the number of antennas may be one or more.

[0205] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0206] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, this application also provides a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0207] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

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

[0209] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus 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 or components 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 through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0210] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; 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 achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0211] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for implementing a transaction, characterized in that, The method is applied to the first transaction server and includes: Obtain information on the idle resources of registered users; In response to the project registration operation of the registered user, the resource transaction records of the registered user in the target project are determined based on the idle resource information of the registered user; The resource transaction records and the interest rate file of the target project are reported to the second transaction server so that the second transaction server can generate project transaction records based on the resource transaction records of different registered users corresponding to the target project and trigger the project transaction of the target project. In response to the project transaction execution success information, the registered users' gain resource amount is updated according to the interest rate file of the target project. Receive the amount of gain resources of registered users under the target project returned by the second transaction server, and update the idle resource information of the registered users.

2. The method according to claim 1, characterized in that, The step of responding to the project registration operation of the registered user, and determining the resource transaction records of the registered user in the target project based on the registered user's idle resource information, includes: Obtain the resource type corresponding to the target project; Based on the idle resource information of the registered users, obtain the number of target idle resources of the registered users under the resource type corresponding to the target project; Based on the quantity of the target idle resources and the target operation information, construct the resource transaction records of the registered users corresponding to the target project.

3. The method according to claim 1, characterized in that, After submitting the resource transaction records and the interest rate documents of the target project to the second transaction server, the process also includes: Receive the project transaction records of the target project returned by the second transaction server; Based on the project transaction records, a project transaction instruction for the target project is sent to the target issuance server corresponding to the target project. The system receives a transaction success indication from the target issuance server and, based on the transaction success indication, reports the project transaction execution success information of the target project to the second transaction server, so that the second transaction server, in response to the project transaction execution success information, updates the gain resource amount of registered users according to the interest rate file of the target project.

4. The method according to claim 1, characterized in that, The step of receiving the amount of gain resources of the registered user under the target project returned by the second transaction server and updating the idle resource information of the registered user includes: Receive the amount of gain resources of the registered user under the target project returned by the second transaction server; Update the idle resource information of the registered users based on the amount of gain resources of the registered users under the target project and the resource collection information of the registered users.

5. The method according to claim 4, characterized in that, The step of updating the idle resource information of the registered users based on the amount of gain resources of the registered users under the target project and the resource collection information of the registered users includes: Based on the resource collection information of the registered users, determine the proportion of resource revenue to be handed over by the registered users; The actual amount of resource revenue that the registered user receives is determined based on the amount of resource gains the registered user has under the target project and the proportion of resource revenue the registered user has contributed. Update the idle resource information of the registered users based on the actual amount of resource revenue they have received and the amount of idle resources they originally had.

6. The method according to claim 1, characterized in that, The idle resource information includes the type and quantity of idle resources. The idle resources include the account balance in the corresponding account of the registered user. The type of idle resources includes the currency of the account balance, and the quantity of resources includes the value corresponding to the account balance.

7. A method for implementing a transaction, characterized in that, The method is applied to the second transaction server and includes: Receive resource transaction records of different registered users in the target project and interest rate files of the target project reported by the first transaction server; Based on the resource transaction records of different registered users corresponding to the target project, generate corresponding project transaction records and trigger project transactions for the target project; In response to the successful execution of the project transaction, the gain resource amount of each of the registered users is updated according to the interest rate file of the target project; The gain resource amount of each registered user is returned to the first transaction server so that the first transaction server updates the idle resource information of the registered users according to the gain resource amount.

8. The method according to claim 7, characterized in that, The project transaction that triggers the target project includes: The project transaction record of the target project is returned to the first transaction server, so that the first transaction server sends the project transaction instruction of the target project to the target issuance server corresponding to the target project based on the project transaction record, and receives the transaction success indication information returned by the target issuance server. Receive project transaction execution success information reported by the first transaction server based on the transaction success indication information.

9. The method according to claim 7, characterized in that, In response to the successful execution of the project transaction, the method of updating the gain resource amount of each registered user according to the interest rate file of the target project includes: In response to the successful execution of the project transaction, determine the latest gain resource amount of the target project on the current transaction day; Update the gain resource amount for each of the registered users based on the latest gain resource amount and the interest rate file of the target project.

10. The method according to claim 7, characterized in that, The step of updating the gain resource amount for each registered user based on the latest gain resource amount and the interest rate file of the target project includes: Update the idle resource balance information of the registered users based on the latest gain resource amount of the target project on the current trading day; Based on the interest rate document of the target project and the idle resource balance information of the registered users under the target project, the amount of gain resources of the registered users is determined.

11. The method according to claim 7, characterized in that, The idle resource information includes the type and quantity of idle resources. The idle resources include the account balance in the corresponding account of the registered user. The type of idle resources includes the currency of the account balance, and the quantity of resources includes the value corresponding to the account balance.

12. A transaction realization apparatus, characterized in that, The device is configured on the first transaction server and includes: The idle resource acquisition module is used to acquire idle resource information of registered users; The resource transaction module is used to respond to the project registration operation of the registered user and determine the resource transaction record of the registered user in the target project based on the idle resource information of the registered user. The first project transaction module is used to report the resource transaction records and the interest rate file of the target project to the second transaction server, so that the second transaction server generates project transaction records based on the resource transaction records of different registered users corresponding to the target project and triggers the project transaction of the target project. In response to the project transaction execution success information, the module updates the gain resource amount of the registered users according to the interest rate file of the target project. The first idle resource update module is used to receive the amount of gain resources of registered users under the target project returned by the second transaction server, and update the idle resource information of the registered users.

13. The transaction realization apparatus according to claim 12, characterized in that, The resource trading module is also used for: Obtain the resource type corresponding to the target project; Based on the idle resource information of the registered users, obtain the number of target idle resources of the registered users under the resource type corresponding to the target project; Based on the quantity of the target idle resources and the target operation information, construct the resource transaction records of the registered users corresponding to the target project.

14. The transaction realization apparatus according to claim 12, characterized in that, The transaction implementation device further includes a project transaction determination module, which is used for: Receive the project transaction records of the target project returned by the second transaction server; Based on the project transaction records, a project transaction instruction for the target project is sent to the target issuance server corresponding to the target project. The system receives a transaction success indication from the target issuance server and, based on the transaction success indication, reports the project transaction execution success information of the target project to the second transaction server, so that the second transaction server, in response to the project transaction execution success information, updates the gain resource amount of registered users according to the interest rate file of the target project.

15. The transaction realization apparatus according to claim 12, characterized in that, The first idle resource update module is also used for: Receive the amount of gain resources of the registered user under the target project returned by the second transaction server; Update the idle resource information of the registered users based on the amount of gain resources of the registered users under the target project and the resource collection information of the registered users.

16. A transaction realization apparatus, characterized in that, The device is configured on the second transaction server and includes: The resource transaction record receiving module is used to receive resource transaction records of different registered users in the target project and the interest rate file of the target project reported by the first transaction server. The second project transaction module is used to generate corresponding project transaction records based on the resource transaction records of different registered users for the target project, and to trigger project transactions for the target project. The gain resource update module is used to update the gain resource amount of each registered user according to the interest rate file of the target project in response to the successful execution information of the project transaction; The second idle resource update module is used to return the amount of gain resources of each registered user to the first transaction server, so that the first transaction server updates the idle resource information of the registered users according to the amount of gain resources.

17. The transaction realization apparatus according to claim 16, characterized in that, The second project transaction module is also used for: The project transaction record of the target project is returned to the first transaction server, so that the first transaction server sends the project transaction instruction of the target project to the target issuance server corresponding to the target project based on the project transaction record, and receives the transaction success indication information returned by the target issuance server. Receive project transaction execution success information reported by the first transaction server based on the transaction success indication information.

18. The transaction realization apparatus according to claim 16, characterized in that, The gain resource update module is also used for: In response to the successful execution of the project transaction, determine the latest gain resource amount of the target project on the current transaction day; Update the gain resource amount for each of the registered users based on the latest gain resource amount and the interest rate file of the target project.

19. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the transaction implementation method according to any one of claims 1-11.

20. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the transaction implementation method as described in any one of claims 1-11.

Images