Resource transfer method, system, device, server and storage medium

Abstract

The present invention discloses a resource transfer method, system, device, server and storage medium, belonging to the technical field of e-commerce, including: a terminal sends a first transfer request to a first server, the first transfer request carries a user identification of a user; the first server receives the first transfer request, obtains the user's contract identification according to the user identification, selects a target resource transfer token from a resource transfer token in a resource transfer token library, the resource transfer token in the resource transfer token library is a resource transfer token sent by a second server; generates a resource transfer tag according to the contract identification and the target resource transfer token; sends a second transfer request carrying the resource transfer tag to a second server; the second server receives the second transfer request, and performs resource transfer according to the second transfer request. The resource transfer process is dynamically verified by the target resource transfer token, so that sensitive information leakage is avoided after the second transfer request is intercepted, thereby improving the security of resource transfer.

Description

Technical Field

[0001] The present invention relates to the technical field of e-commerce, and in particular to a resource transfer method, system, device, server and storage medium. Background Art

[0002] With the development of e-commerce technology, the way of transferring resources through physical cards is gradually replaced by electronic resource transfer or cardless resource transfer. Before users transfer resources electronically or cardless, they need to bind a resource transfer card in a third-party application installed on the terminal; when users transfer resources, the resource transfer is realized through the first server corresponding to the third-party application and the second server corresponding to the resource transfer card. Summary of the invention

[0003] The embodiments of the present invention provide a resource transfer method, system, device, server and storage medium, which can solve the problem that the second transfer request carries the user's sensitive information. When the second transfer request is intercepted, other users can obtain the user's sensitive information, resulting in low security of resource transfer. The technical solution is as follows:

[0004] In one aspect, a resource transfer method is provided, the method comprising:

[0005] The terminal sends a first transfer request to the first server, wherein the first transfer request carries a user identifier of the user;

[0006] The first server receives the first transfer request, obtains the user's subscription identifier according to the user identifier, and selects a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is the resource transfer token sent by the second server; generates a resource transfer tag according to the subscription identifier and the target resource transfer token; and sends a second transfer request to the second server, where the second transfer request carries the resource transfer tag;

[0007] The second server receives the second transfer request and performs resource transfer according to the second transfer request.

[0008] In a possible implementation, the method further includes:

[0009] The first server sends an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token;

[0010] The second server receives the acquisition request, generates a new resource transfer token, and sends the new resource transfer token to the first server;

[0011] The first server receives the new resource transfer token, and adds the new resource transfer token to the resource transfer token library.

[0012] In another possible implementation manner, before the terminal sends the first transfer request to the first server, the method further includes:

[0013] The terminal sends a binding request to the first server, wherein the binding request carries the to-be-verified information of the user;

[0014] The first server receives the binding request sent by the terminal, and verifies the information to be verified;

[0015] In response to the verification being successful, the first server generates a contract identification of the user according to the information to be verified, and stores the user identification and the contract identification in an associated manner.

[0016] In another possible implementation manner, after the first server generates the signing identifier of the user according to the information to be verified, the method further includes:

[0017] The first server sends the signing identifier to the second server;

[0018] The second server receives the contract identification, and adds the contract identification to a contract identification library.

[0019] On the other hand, a resource transfer method is provided, the method being applied to a first server, the method comprising:

[0020] receiving a first transfer request, wherein the first transfer request carries a user identifier of a user;

[0021] According to the user identifier, obtaining the user's contract identifier, and selecting a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server;

[0022] Generate a resource transfer mark according to the contract identification and the target resource transfer token;

[0023] A second transfer request is sent to the second server, where the second transfer request carries the resource transfer tag and is used to request the second server to perform resource transfer.

[0024] In a possible implementation, selecting a target resource transfer token from a resource transfer token library includes:

[0025] Determining the status of a plurality of resource transfer tokens in the resource transfer token library;

[0026] According to the states of the plurality of resource transfer tokens, a target resource transfer token in an unused state is selected from the resource transfer tokens in the resource transfer token library.

[0027] In another possible implementation, the selecting a target resource transfer token from a resource transfer token library includes:

[0028] Selecting a resource transfer token from the resource transfer token library;

[0029] determining a status of the resource transfer token;

[0030] In response to the resource transfer token being in a state of being unused, the resource transfer token is used as a target resource transfer token.

[0031] In another possible implementation, the selecting a target resource transfer token from a resource transfer token library includes:

[0032] Determining the validity period of each resource transfer token in the resource transfer token library;

[0033] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the current time is selected from the resource transfer tokens in the resource transfer token library.

[0034] In another possible implementation, selecting, according to the validity period of each resource transfer token, a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library includes:

[0035] Determine a first timestamp based on the current time and a preset duration;

[0036] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the first timestamp is selected from the resource transfer tokens in the resource transfer token library.

[0037] In another possible implementation, selecting, according to the validity period of each resource transfer token, a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library includes:

[0038] Determine a second timestamp according to the current time, the preset duration and the time coefficient;

[0039] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the second timestamp is selected from the resource transfer tokens in the resource transfer token library.

[0040] In another possible implementation, the method further includes:

[0041] Sending an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token;

[0042] The new resource transfer token is received, and the new resource transfer token is added to the resource transfer token library.

[0043] In another possible implementation manner, before receiving the first transfer request, the method further includes:

[0044] receiving a binding request sent by the terminal, wherein the binding request carries the user's information to be verified;

[0045] Verifying the information to be verified;

[0046] In response to the verification being successful, generating a signing identification of the user according to the information to be verified;

[0047] The user identifier and the contract identifier are stored in association.

[0048] In another possible implementation, after generating the signing identifier of the user according to the information to be verified, the method further includes:

[0049] The contract identification is sent to the second server, so that the second server adds the contract identification to a contract identification library.

[0050] In another possible implementation, the method further includes:

[0051] When sending the second transfer request to the second server, changing the state of the target resource transfer token from unused to in-use;

[0052] Upon receiving the transfer completion indication returned by the second server, changing the state of the target resource transfer token from being in use to being used;

[0053] In response to clearing resource transfer tokens, resource transfer tokens in the resource transfer token library whose status is that they have been used or whose validity period does not include the current time are deleted.

[0054] In another possible implementation, generating a resource transfer mark according to the subscription identifier and the target resource transfer token includes:

[0055] The subscription identifier is added to a first field in a resource transfer mark message, and the target resource transfer token is added to a second field in the resource transfer mark message to obtain the resource transfer mark.

[0056] In another possible implementation, before generating a resource transfer mark according to the subscription identifier and the target resource transfer token, the method further includes:

[0057] Get resource transfer information;

[0058] Generating a resource transfer mark according to the contract identifier and the target resource transfer token includes:

[0059] The subscription identifier is added to the first field in the resource transfer mark message, the target resource transfer token is added to the second field in the resource transfer mark message, and the resource transfer information is added to the third resource in the resource transfer mark message to obtain the resource transfer mark.

[0060] On the other hand, a resource transfer method is provided, the method being applied in a second server, the method comprising:

[0061] receiving a second transfer request sent by the first server, wherein the second transfer request carries a resource transfer mark;

[0062] Parsing the resource transfer mark to obtain a signing identifier and a target resource transfer token;

[0063] Verifying the second transfer request according to the subscription identifier and the target resource transfer token;

[0064] In response to the verification being successful, performing resource transfer according to the second transfer request.

[0065] In a possible implementation manner, the verifying the second transfer request according to the subscription identifier and the target resource transfer token includes:

[0066] Verifying whether the target resource transfer token is a valid resource transfer token, and verifying whether the signing identifier exists in a signing identifier library;

[0067] In response to the target resource transfer token being a valid resource transfer token and the contract identifier existing in the contract identifier library, it is determined that the verification is successful.

[0068] In another possible implementation manner, before receiving the second transfer request sent by the first server, the method further includes:

[0069] A resource transfer token is generated, and the resource transfer token is sent to the first server, so that the first server adds the resource transfer token to a resource transfer token library.

[0070] In another possible implementation, the method further includes:

[0071] Receiving an acquisition request sent by the first server;

[0072] Generate a new resource transfer token according to the acquisition request;

[0073] The new resource transfer token is sent to the first server, so that the first server adds the new resource transfer token to the resource transfer token library.

[0074] In another possible implementation manner, before verifying the second transfer request according to the subscription identifier and the target resource transfer token, the method further includes:

[0075] Receiving the signing identifier sent by the first server;

[0076] The signing identity is added to a signing identity library.

[0077] In another possible implementation, generating a resource transfer token includes:

[0078] Determine the current time, a third timestamp, where the third timestamp is the expiration time point of the current time period, and obtain a preset duration and a time coefficient;

[0079] Determine, according to the current time, the preset duration and the time coefficient, a fourth timestamp for generating the resource transfer token;

[0080] In response to the fourth timestamp being within the third timestamp, generating a resource transfer token having a validity period equal to the third timestamp according to the third timestamp;

[0081] In response to the fourth timestamp not being within the third timestamp, a fifth timestamp is determined according to the third timestamp, and a resource transfer token having a validity period of the fifth timestamp is generated.

[0082] On the other hand, a resource transfer system is provided, the system comprising: a terminal, a first server and a second server;

[0083] The terminal is used to send a first transfer request to the first server, wherein the first transfer request carries a user identifier of a user;

[0084] The first server is configured to receive the first transfer request, obtain the user's subscription identifier according to the user identifier, and select a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server; generate a resource transfer tag according to the subscription identifier and the target resource transfer token; and send a second transfer request to the second server, where the second transfer request carries the resource transfer tag;

[0085] The second server is used to receive the second transfer request and perform resource transfer according to the second transfer request.

[0086] In a possible implementation, the first server is further used to send an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token;

[0087] The second server is further configured to receive the acquisition request, generate a new resource transfer token, and send the new resource transfer token to the first server;

[0088] The first server is further configured to receive the new resource transfer token and add the new resource transfer token to the resource transfer token library.

[0089] In another possible implementation, the terminal is further configured to send a binding request to the first server, wherein the binding request carries the to-be-verified information of the user;

[0090] The first server is further configured to receive a binding request sent by the terminal and verify the information to be verified;

[0091] The first server is further configured to generate a signing identifier of the user according to the information to be verified in response to the verification being successful, and store the user identifier and the signing identifier in an associated manner.

[0092] In another possible implementation manner, the first server is further configured to send the signing identifier to the second server;

[0093] The second server is further configured to receive the contract signing identifier and add the contract signing identifier to a contract signing identifier library.

[0094] On the other hand, a resource transfer device is provided, the device is applied to a first server, and the device includes:

[0095] A first receiving module, configured to receive a first transfer request, wherein the first transfer request carries a user identifier of a user;

[0096] A first acquisition module, configured to acquire a contract identification of the user according to the user identification, and select a target resource transfer token from a resource transfer token in a resource transfer token library, wherein the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server;

[0097] A first generating module, configured to generate a resource transfer mark according to the signing identifier and the target resource transfer token;

[0098] The first sending module is used to send a second transfer request to the second server, where the second transfer request carries the resource transfer tag and is used to request the second server to perform resource transfer.

[0099] In a possible implementation, the first acquisition module is further used to determine the status of multiple resource transfer tokens in the resource transfer token library; and select a target resource transfer token with an unused status from the resource transfer tokens in the resource transfer token library according to the status of the multiple resource transfer tokens.

[0100] In another possible implementation, the first acquisition module is further configured to select a resource transfer token from the resource transfer token library;

[0101] Determine the state of the resource transfer token; in response to the state of the resource transfer token being unused, use the resource transfer token as a target resource transfer token.

[0102] In another possible implementation, the first acquisition module is further used to determine the validity period of each resource transfer token in the resource transfer token library; and according to the validity period of each resource transfer token, select a target resource transfer token whose validity period includes the current time from the resource transfer tokens in the resource transfer token library.

[0103] In another possible implementation, the first acquisition module is further used to determine a first timestamp based on the current time and a preset duration; and select a target resource transfer token whose validity period includes the first timestamp from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token.

[0104] In another possible implementation, the first acquisition module is further used to determine a second timestamp based on the current time, a preset duration and a time coefficient; and select a target resource transfer token whose validity period includes the second timestamp from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token.

[0105] In another possible implementation, the device further includes:

[0106] A second sending module, used for sending an acquisition request to the second server, wherein the acquisition request is used for requesting the second server to generate a new resource transfer token;

[0107] The second receiving module is used to receive the new resource transfer token and add the new resource transfer token to the resource transfer token library.

[0108] In another possible implementation, the device further includes:

[0109] A third receiving module, configured to receive a binding request sent by the terminal, wherein the binding request carries the user's information to be verified;

[0110] A first verification module, used to verify the information to be verified;

[0111] A second generating module, configured to generate a signing identification of the user according to the information to be verified in response to the verification being passed;

[0112] The storage module is used to store the user identifier and the contract identifier in an associated manner.

[0113] In another possible implementation, the device further includes:

[0114] The third sending module is configured to send the signing identifier to the second server, so that the second server adds the signing identifier to a signing identifier library.

[0115] In another possible implementation, the device further includes:

[0116] A first modification module, configured to modify the state of the target resource transfer token from unused to in-use when sending a second transfer request to the second server;

[0117] A second modification module, configured to modify the state of the target resource transfer token from being in use to being used upon receiving a transfer completion indication returned by the second server;

[0118] The deleting module is used to delete the resource transfer tokens in the resource transfer token library in response to clearing the resource transfer tokens, which are in a used state or whose validity period does not include the current time.

[0119] In another possible implementation, the first generating module is used to add the subscription identifier to a first field in a resource transfer mark message, and to add the target resource transfer token to a second field in the resource transfer mark message, so as to obtain the resource transfer mark.

[0120] In another possible implementation, the device further includes:

[0121] A second acquisition module, configured to acquire resource transfer information;

[0122] The first generation module is further configured to add the signing identifier to the first field in the resource transfer mark message, add the target resource transfer token to the second field in the resource transfer mark message, and add the resource transfer information to the third resource in the resource transfer mark message, to obtain the resource transfer mark.

[0123] On the other hand, a resource transfer device is provided. The device is applied to a second server, and the device includes:

[0124] A fourth receiving module, configured to receive a second transfer request sent by a first server, where the second transfer request carries a resource transfer mark;

[0125] An analysis module, configured to analyze the resource transfer mark to obtain a signing identifier and a target resource transfer token;

[0126] A second verification module, configured to verify the second transfer request according to the signing identifier and the target resource transfer token;

[0127] A resource transfer module, configured to, in response to passing the verification, perform resource transfer according to the second transfer request.

[0128] In a possible implementation, the second verification module is further configured to verify whether the target resource transfer token is a valid resource transfer token, and verify whether the signing identifier exists in the signing identifier library; in response to the target resource transfer token being a valid resource transfer token and the signing identifier existing in the signing identifier library, determine that the verification passes.

[0129] In another possible implementation, the device further includes:

[0130] A third generation module, configured to generate a resource transfer token, and send the resource transfer token to the first server, so that the first server adds the resource transfer token to the resource transfer token library.

[0131] In another possible implementation, the device further includes:

[0132] A fifth receiving module, configured to receive an acquisition request sent by the first server;

[0133] The third generation module is further configured to generate a new resource transfer token according to the acquisition request;

[0134] The fourth sending module is used to send the new resource transfer token to the first server, so that the first server adds the new resource transfer token to the resource transfer token library.

[0135] In another possible implementation, the device further includes:

[0136] A sixth receiving module, configured to receive the signing identifier sent by the first server;

[0137] The adding module is used to add the signing identity to the signing identity library.

[0138] In another possible implementation, the third generation module is also used to determine the current time, a third timestamp, where the third timestamp is the expiration time point of the current time period, and to obtain a preset duration and a time coefficient; determine a fourth timestamp for generating the resource transfer token based on the current time, the preset duration and the time coefficient; in response to the fourth timestamp being within the third timestamp, generate a resource transfer token with a validity period of the third timestamp based on the third timestamp; in response to the fourth timestamp not being within the third timestamp, determine a fifth timestamp based on the third timestamp, and generate a resource transfer token with a validity period of the fifth timestamp.

[0139] On the other hand, a first server is provided, which includes one or more processors and one or more memories, wherein at least one instruction is stored in the one or more memories, and the at least one instruction is loaded and executed by the one or more processors to implement the operations performed by the resource transfer method described in any possible implementation method described above.

[0140] On the other hand, a second server is provided, which includes one or more processors and one or more memories, wherein at least one instruction is stored in the one or more memories, and the at least one instruction is loaded and executed by the one or more processors to implement the operations performed by the resource transfer method described in any possible implementation method described above.

[0141] On the other hand, a non-temporary computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the operations performed by the resource transfer method as described in any possible implementation manner described above.

[0142] On the other hand, a non-temporary computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the operations performed by the resource transfer method as described in any possible implementation manner described above.

[0143] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0144] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0145] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0146] Figure 1 is a system architecture diagram involved in a resource transfer method according to some exemplary embodiments of the present invention;

[0147] Figure 2 is a system architecture diagram involving a resource transfer method according to some exemplary embodiments of the present invention;

[0148] Figure 3 is a flow chart of a resource transfer method provided according to an exemplary embodiment;

[0149] Figure 4 is a flow chart of a resource transfer method provided according to an exemplary embodiment;

[0150] Figure 5 is a flow chart of a resource transfer method provided according to an exemplary embodiment;

[0151] Figure 6 is a schematic diagram of a resource transfer mark provided according to an exemplary embodiment;

[0152] Figure 7 is a flow chart of a resource transfer method provided according to an exemplary embodiment;

[0153] Figure 8 is a block diagram of a resource transfer device provided according to an exemplary embodiment;

[0154] Fig. 9 is a block diagram of a resource transfer device provided according to an exemplary embodiment;

[0155] Fig.10 is a schematic diagram of the structure of a terminal according to some exemplary embodiments of the present invention;

[0156] Fig.11 It is a schematic diagram of the structure of a server according to some exemplary embodiments of the present invention. DETAILED DESCRIPTION

[0157] In order to make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0158] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0159] Figure 1 1 is a system architecture diagram of a resource transfer method according to some exemplary embodiments of the present invention, and the system architecture includes: a terminal 101, a first server 102, and a second server 103. The terminal 101 is a terminal 101 that initiates a resource transfer request in an embodiment of the present invention. A third-party application can be installed on the terminal 101, the first server 102 is a server corresponding to the third-party application, and the second server 103 is a server for performing resource transfer. For example, the second server 103 can be a server corresponding to a bank system. When the terminal 101 initiates a resource transfer request, a first transfer request is sent to the first server 102 through the third-party application on the terminal 101. The first server 102 receives the first transfer request, determines the user's contract identifier according to the first transfer request, and selects a target resource transfer token from the resource transfer token in the resource transfer token library according to the first transfer request, and sends a second transfer request to the second server 103 according to the contract identifier and the target resource transfer token. The second server 103 receives the second transfer request and performs resource transfer according to the second transfer request.

[0160] Among them, the first server 102 exchanges data with the terminal 101 and the second server 103 respectively through a network link or a data interface. The terminal 101 can be a mobile phone, a computer or a wearable device, etc. The third-party application is an application corresponding to an independent organization with certain strength and credibility guarantee, and the third-party application can be a payment application, a social application or a bank client, etc. The terminal 101 is connected to the first server 102 through the third application to facilitate the resource transfer parties to complete the resource transfer. Accordingly, the resource transfer process can be a payment process. For example, when shopping online, ordering takeout, paying parking fees online or paying living expenses online, payment operations can be performed through a third-party application. Accordingly, when the resource transfer process is a payment process, the resource transfer token can be a payment token, the contract identification can be an identification of the user's bank card number, and the transfer request can be a payment request. The payment process may be as follows: when the terminal 101 receives an order for online shopping, ordering takeout, paying parking fees online or paying living expenses online, the terminal 101 initiates a payment request according to the order; correspondingly, the third-party application in the terminal 101 sends a first payment request to the first server 102 according to the order, the first server 102 selects a target payment token in the payment token library according to the first payment request, and sends a second payment request to the second server 103 according to the target payment token, the second server 103 receives the second payment request, verifies the signing identifier and the target payment token in the second payment instruction, and completes the payment operation according to the second payment request in response to the verification being successful.

[0161] Figure 2 is a flow chart of a resource transfer method provided according to an exemplary embodiment. Figure 2 As shown, the resource transfer method includes the following steps:

[0162] Step 201: A terminal sends a first transfer request to a first server, where the first transfer request carries a user identifier of a user.

[0163] Step 202: The first server receives the first transfer request, obtains the user's contract identifier based on the user identifier, and selects a target resource transfer token from a resource transfer token library, where the resource transfer tokens in the resource transfer token library are resource transfer tokens sent by the second server; generates a resource transfer tag based on the contract identifier and the target resource transfer token; and sends a second transfer request to the second server, where the second transfer request carries the resource transfer tag.

[0164] Step 203: The second server receives the second transfer request, and performs resource transfer according to the second transfer request.

[0165] In a possible implementation, the method further includes:

[0166] The first server sends an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token;

[0167] The second server receives the acquisition request, generates a new resource transfer token, and sends the new resource transfer token to the first server;

[0168] The first server receives the new resource transfer token, and adds the new resource transfer token to the resource transfer token library.

[0169] In another possible implementation manner, before the terminal sends the first transfer request to the first server, the method further includes:

[0170] The terminal sends a binding request to the first server, where the binding request carries the user's information to be verified;

[0171] The first server receives the binding request sent by the terminal, and verifies the information to be verified;

[0172] In response to the verification being successful, the first server generates a contract identification of the user according to the information to be verified, and stores the user identification and the contract identification in an associated manner.

[0173] In another possible implementation, after the first server generates the signing identifier of the user according to the information to be verified, the method further includes:

[0174] The first server sends the signing identifier to the second server;

[0175] The second server receives the contract identification, and adds the contract identification to a contract identification library.

[0176] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0177] Figure 3 is a flow chart of a resource transfer method provided according to an exemplary embodiment. Figure 3 As shown, the method is applied to the first server, and the resource transfer method includes the following steps:

[0178] Step 301: Receive a first transfer request, where the first transfer request carries a user identifier of a user.

[0179] Step 302: According to the user identifier, the user's contract identifier is obtained, and a target resource transfer token is selected from a resource transfer token in a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server.

[0180] Step 303: Generate a resource transfer tag according to the subscription identifier and the target resource transfer token.

[0181] Step 304: Send a second transfer request to the second server, where the second transfer request carries the resource transfer tag and is used to request the second server to perform resource transfer.

[0182] In a possible implementation, selecting a target resource transfer token from a resource transfer token library includes:

[0183] Determining the status of a plurality of resource transfer tokens in the resource transfer token library;

[0184] According to the states of the plurality of resource transfer tokens, a target resource transfer token in an unused state is selected from the resource transfer tokens in the resource transfer token library.

[0185] In another possible implementation, selecting a target resource transfer token from a resource transfer token library includes:

[0186] Select a resource transfer token from the resource transfer token library;

[0187] Determining the status of the resource transfer token;

[0188] In response to the resource transfer token being in a state of being unused, the resource transfer token is used as a target resource transfer token.

[0189] In another possible implementation, selecting a target resource transfer token from a resource transfer token library includes:

[0190] Determine the validity period of each resource transfer token in the resource transfer token library;

[0191] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the current time is selected from the resource transfer tokens in the resource transfer token library.

[0192] In another possible implementation, selecting a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token includes:

[0193] Determine a first timestamp based on the current time and a preset duration;

[0194] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the first timestamp is selected from the resource transfer tokens in the resource transfer token library.

[0195] In another possible implementation, selecting a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token includes:

[0196] Determine a second timestamp according to the current time, the preset duration and the time coefficient;

[0197] According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the second timestamp is selected from the resource transfer tokens in the resource transfer token library.

[0198] In another possible implementation, the method further includes:

[0199] Sending an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token;

[0200] The new resource transfer token is received, and the new resource transfer token is added to the resource transfer token library.

[0201] In another possible implementation manner, before receiving the first transfer request, the method further includes:

[0202] receiving a binding request sent by the terminal, wherein the binding request carries the user's information to be verified;

[0203] Verifying the information to be verified;

[0204] In response to the verification being passed, generating a signing identification of the user according to the information to be verified;

[0205] The user ID and the contract ID are stored in association.

[0206] In another possible implementation, after generating the signing identifier of the user according to the information to be verified, the method further includes:

[0207] The contract identification is sent to the second server, so that the second server adds the contract identification to a contract identification library.

[0208] In another possible implementation, the method further includes:

[0209] When sending the second transfer request to the second server, changing the state of the target resource transfer token from unused to in-use;

[0210] Upon receiving the transfer completion indication returned by the second server, changing the status of the target resource transfer token from being used to having been used;

[0211] In response to clearing resource transfer tokens, resource transfer tokens in the resource transfer token library whose status is that they have been used or whose validity period does not include the current time are deleted.

[0212] In another possible implementation, generating a resource transfer mark according to the subscription identifier and the target resource transfer token includes:

[0213] The subscription identifier is added to the first field in the resource transfer mark message, and the target resource transfer token is added to the second field in the resource transfer mark message to obtain the resource transfer mark.

[0214] In another possible implementation, before generating the resource transfer mark according to the subscription identifier and the target resource transfer token, the method further includes:

[0215] Get resource transfer information;

[0216] Generate a resource transfer mark according to the contract identifier and the target resource transfer token, including:

[0217] The subscription identifier is added to the first field in the resource transfer mark message, the target resource transfer token is added to the second field in the resource transfer mark message, and the resource transfer information is added to the third resource in the resource transfer mark message to obtain the resource transfer mark.

[0218] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0219] Figure 4is a flow chart of a resource transfer method provided according to an exemplary embodiment. Figure 4 As shown, the method is applied to the second server, and the resource transfer method includes the following steps:

[0220] Step 401: Receive a second transfer request sent by a first server, where the second transfer request carries a resource transfer mark.

[0221] Step 402: Parse the resource transfer tag to obtain a contract identification and a target resource transfer token.

[0222] Step 403: Verify the second transfer request according to the subscription identifier and the target resource transfer token.

[0223] Step 404: In response to the verification being successful, perform resource transfer according to the second transfer request.

[0224] In another possible implementation, verifying the second transfer request according to the subscription identifier and the target resource transfer token includes:

[0225] Verify whether the target resource transfer token is a valid resource transfer token, and verify whether the signing identifier exists in the signing identifier library;

[0226] In response to the target resource transfer token being a valid resource transfer token and the contract identifier existing in the contract identifier library, it is determined that the verification is successful.

[0227] In another possible implementation, before receiving the second transfer request sent by the first server, the method further includes:

[0228] A resource transfer token is generated, and the resource transfer token is sent to the first server, so that the first server adds the resource transfer token to a resource transfer token library.

[0229] In another possible implementation, the method further includes:

[0230] Receiving an acquisition request sent by the first server;

[0231] Generate a new resource transfer token based on the acquisition request;

[0232] The new resource transfer token is sent to the first server, so that the first server adds the new resource transfer token to the resource transfer token library.

[0233] In another possible implementation, before verifying the second transfer request according to the subscription identifier and the target resource transfer token, the method further includes:

[0234] Receiving the signing identifier sent by the first server;

[0235] Add the signing ID to the signing ID library.

[0236] In another possible implementation, generating a resource transfer token includes:

[0237] Determine the current time, a third timestamp, the third timestamp being the expiration time point of the current time period, and obtain a preset duration and a time coefficient;

[0238] Determine, according to the current time, the preset duration and the time coefficient, a fourth timestamp for generating the resource transfer token;

[0239] In response to the fourth timestamp being within the third timestamp, generating a resource transfer token having a validity period equal to the third timestamp according to the third timestamp;

[0240] In response to the fourth timestamp not being within the third timestamp, a fifth timestamp is determined according to the third timestamp, and a resource transfer token having a validity period of the fifth timestamp is generated.

[0241] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0242] Figure 5 is a flow chart of a resource transfer method provided according to an exemplary embodiment. Figure 5 As shown, the resource transfer method includes the following steps:

[0243] Step 501: A terminal sends a first transfer request to a first server, where the first transfer request carries a user identifier of a user.

[0244] In response to the terminal needing to transfer resources, the terminal sends a first transfer request to the first server. The first transfer request carries a user identifier of a user, who may be a currently logged-in user in the terminal. The user identifier is used to indicate the object of this resource transfer operation.

[0245] Step 502: The first server receives the first transfer request and obtains the subscription identifier of the user according to the user identifier.

[0246] In this step, after receiving the first transfer request, the terminal determines the contract identifier of the user according to the user identifier in the first transfer request and from the correspondence between the user identifier and the contract identifier.

[0247] The first server may directly determine the contract identifier corresponding to the user identifier from the correspondence between the user identifier and the contract identifier stored locally. The first server may also send the user identifier to the second server, and the correspondence between the user identifier and the contract identifier is stored in the second server accordingly. The second server determines the contract identifier corresponding to the user identifier from the correspondence between the user identifier and the contract identifier according to the user identifier.

[0248] The contract signing identifier may be a contract signing identifier uniquely corresponding to the user's resource transfer card, which is a resource transfer card bound to the user's account.

[0249] Accordingly, before this step, the terminal can bind the resource transfer card of the user to the user account through the first server to generate a contract identification uniquely corresponding to the card number of the resource transfer card. The process of generating the contract identification can be implemented through the following steps (1)-(3), including:

[0250] (1) The terminal sends a binding request to the first server, where the binding request carries the user's information to be verified.

[0251] The verification information may include at least one of a user identifier, a card number of a user's resource transfer card, a user's name, a user's ID number, and a user's mobile phone number. The verification information is used by the first server to authenticate the user.

[0252] In response to the terminal detecting a triggering operation of a binding request, a binding request may be sent to the first server through a third-party application in the terminal. For example, a binding button may be displayed in the interface of the third-party application. In response to the terminal detecting that the binding button is triggered, it is determined that a triggering operation of a binding request is detected, and the terminal sends a binding request to the first server. The user may be a new user of the third-party application or a historical user of the third-party application. In response to the user being a new user of the third-party application, the terminal also sends a registration request to the first server, and the registration request may carry the binding request; in response to the user being a historical user of the third-party application, the binding request may be used for the user to add a new resource transfer card. In the embodiments of the present invention, this is not specifically limited.

[0253] (2) The first server receives the binding request sent by the terminal and verifies the information to be verified.

[0254] The first server may store in advance the correspondence between user information of a plurality of users. Accordingly, in response to the first server receiving the information to be verified sent by the terminal, a user information is selected from the user information of a plurality of users according to the verification information to be verified, and the information to be verified is compared with the user information. In response to the information to be verified being the same as the user information, it is determined that the verification of the information to be verified has been passed, and step (3) is executed. In response to the information to be verified being different from the user information, it is determined that the verification information has not passed the verification, and a first prompt message indicating a verification failure is sent to the terminal. Accordingly, when the terminal receives the first prompt message, a second prompt message is displayed according to the first prompt message. The second prompt message is used to prompt the user that the current verification has failed, and may also prompt the user to check whether the information to be verified is filled in correctly. For example, the second prompt message may be "binding failed, please confirm whether the information is filled in correctly", etc.

[0255] One point that needs to be explained is that the terminal can also verify the information to be verified through a third server. Accordingly, the first server sends the information to be verified to the third server, the third server receives the information to be verified, verifies the information to be verified, obtains the verification result of the information to be verified, sends the verification result to the first server, and the first server receives the verification result. Among them, the process of the third server verifying the information to be verified is similar to the process of the first server verifying the information to be verified, which will not be repeated here. In addition, the third server and the second server can be the same server or different servers, and this is not specifically limited in the embodiments of the present invention.

[0256] (3) In response to the verification being successful, the first server generates a contract identification of the user according to the information to be verified, and stores the user identification and the contract identification in an associated manner.

[0257] In this step, in response to the information to be verified passing the verification, the first server randomly generates a contract identification, and associates the contract identification with the user information of the user. The first server can also generate a contract identification according to the card number of the resource transfer card in the user information. In the embodiment of the present invention, the generation method of the contract identification is not specifically limited. The first server associates the contract identification with the user identification and stores it in the designated storage space.

[0258] One point that needs to be explained is that in response to the first server verifying the information to be verified through the third server, the third server can directly generate a signing identifier after the verification is successful, and send the signing identifier to the first server. After the first server receives the signing identifier, it associates the signing identifier with the user identifier and stores it.

[0259] In addition, after the first server generates the contract identification, the first server may also send the contract identification to the second server, and the second server stores the contract identification in the contract identification library. Accordingly, the process may be implemented by the following steps: the first server sends the contract identification to the second server; the second server receives the contract identification; the second server adds the contract identification to the contract identification library. It should be noted that this step may be executed before step (3), after step (3), or simultaneously with step (3). In the embodiment of the present invention, the execution order of this step and step (3) is not specifically limited.

[0260] In this implementation, the terminal sends a binding request to the first server, and the first server verifies the information to be verified sent by the terminal based on the binding request. In response to the verification being successful, it generates a signing identifier for the information to be verified and sends the first identifier to the second server so that the second server can transfer resources based on the signing identifier, thereby avoiding the leakage of user sensitive information and improving the security of resource transfer.

[0261] Step 503: The first server selects a target resource transfer token from a resource transfer token library, where the resource transfer tokens in the resource transfer token library are resource transfer tokens sent by the second server.

[0262] The first server stores a resource transfer token library, in which a plurality of resource transfer tokens are stored. The terminal can select a resource transfer token from the plurality of resource transfer tokens as a target resource transfer token.

[0263] In one possible implementation, the first server may randomly select a resource transfer token from the resource transfer tokens in the resource transfer token library as the target resource transfer token. In another possible implementation, the first server may also select an unused resource transfer token from the resource transfer tokens in the resource transfer token library as the target resource transfer token. In another possible implementation, the first server may also select a resource transfer token whose generation time is within the validity period as the target resource transfer token based on the generation time of the resource transfer token in the resource transfer token library.

[0264] In response to the first server selecting the target resource transfer token according to the token state of the resource transfer token, the first server may select the target resource transfer token from the resource transfer tokens in the resource transfer token library in the following two implementation manners.

[0265] In a first implementation, the terminal determines the status of multiple resource transfer tokens in a resource transfer token library and selects a target resource transfer token from the multiple resource transfer tokens. This process can be implemented by the following steps (A1)-(A2), including:

[0266] (A1) The first server determines the status of multiple resource transfer tokens in the resource transfer token library.

[0267] The multiple resource transfer tokens may be all resource transfer tokens in the resource transfer token library, or may be a preset number of resource transfer tokens, which are not specifically limited in the embodiment of the present invention. Furthermore, the specified number may be set and changed as needed, which are not specifically limited in the embodiment of the present invention. For example, the preset number may be 20, 25, or 30, etc.

[0268] The status of the resource transfer token may be unused, in use, used, etc. Accordingly, the first server may mark the status of the resource transfer token in the resource transfer token library according to the usage of the resource transfer token.

[0269] In an embodiment of the present invention, the first server receives a newly generated resource transfer token sent by the second server, and the first server may mark the received resource transfer token as unused. After the first server confirms the contract identifier and the target resource transfer token, the first server may send a second transfer request to the second server. When the first server sends the second transfer request to the second server, the state of the resource transfer token corresponding to the target resource transfer token in the resource transfer token library is changed from unused to in use. After the second server performs resource transfer according to the second transfer request, it may send a transfer completion indication to the first server. Accordingly, when the first server receives the transfer completion indication returned by the second server, it changes the state of the resource transfer token corresponding to the target resource transfer token in the resource transfer token library from in use to used. Among them, the first server may mark the state of the resource transfer token by any marking method. In an embodiment of the present invention, the method of marking the resource transfer token by the first server is not specifically limited. For example, the first server may mark the state of the unused resource transfer token as 1, mark the state of the in-use resource transfer token as 0, and mark the state of the used resource transfer token as -1.

[0270] (A2) The first server selects a target resource transfer token in an unused state from the resource transfer tokens in the resource transfer token library according to the states of the plurality of resource transfer tokens.

[0271] In this step, the first server randomly selects a target resource transfer token from resource transfer tokens that are not in use according to the state of each resource transfer token.

[0272] In this implementation, the first server determines the status of multiple resource transfer tokens and selects an unused resource transfer token from the multiple resource transfer tokens, thereby avoiding multiple resource transfer operations using the same resource transfer token, causing resource transfer operation failure.

[0273] In a second implementation, the first server randomly selects a resource transfer token from the resource transfer token library, and then determines the state of the resource transfer token. In response to the state of the selected resource transfer token being unused, the selected resource transfer token is used as the target resource transfer token. In response to the state of the selected resource transfer token being not unused, the resource transfer token is discarded, and a resource transfer token is selected again from the resource transfer tokens in the resource transfer token library. This process can be implemented by the following steps (B1)-(B3), including:

[0274] (B1) The first server selects a resource transfer token from the resource transfer token library.

[0275] In this step, the first server may randomly select a resource transfer token from the resource transfer tokens in the resource transfer token library.

[0276] It should be noted that, after the server has selected a resource transfer token, if the status of the selected resource transfer token is not unused, the first server discards the resource transfer token and selects a resource transfer token from other resource transfer tokens.

[0277] (B2) The first server determines the status of the resource transfer token.

[0278] In this step, the first server may determine the state of the resource transfer token according to the state mark of the resource transfer token. For example, when the state mark of the resource transfer token is 1, the first server determines that the state of the resource transfer token is unused.

[0279] (B3) In response to the resource transfer token being in an unused state, the first server uses the resource transfer token as a target resource transfer token.

[0280] In response to the status of the resource transfer token being in use or having been used, the first server discards the resource transfer token, re-executes steps (B1)-(B3), re-randomly selects a resource transfer token from the resource transfer tokens in the resource transfer token library, and determines the status of the re-selected resource transfer token.

[0281] In this implementation, the first server selects a resource transfer token from multiple resource transfer tokens, determines the status of the resource transfer token, and selects an unused resource transfer token from the multiple resource transfer tokens, thereby avoiding multiple resource transfer operations using the same resource transfer token, causing the resource transfer operation to fail.

[0282] In response to the first server selecting a resource transfer token with a generation time within the validity period as a target resource transfer token based on the generation time of the resource transfer token in the resource transfer token library, the first server may select a resource transfer token from the resource transfer tokens in the resource transfer token library to determine whether the resource transfer token is within the validity period; if the resource transfer token is within the validity period, use the resource transfer token as the target transfer token; if the resource transfer token is not within the validity period, reselect a resource transfer token to determine whether the reselected resource transfer token is within the validity period; if so, use the reselected resource transfer token as the target resource transfer token; if not, reselect again until a resource transfer token within the validity period is selected.

[0283] In response to the first server selecting a resource transfer token with a generation time within the validity period as the target resource transfer token based on the resource transfer token library, the first server may also determine the resource transfer tokens within the validity period in the resource transfer token library, select a resource transfer token from the resource transfer tokens within the validity period, and use the resource transfer token as the target resource transfer token.

[0284] The first server may also determine the resource transfer tokens in the resource transfer token library that are within a validity period. For each resource transfer token in the resource transfer token library, the first server determines whether the resource transfer token is within a validity period.

[0285] The process of the first server determining whether the resource transfer token is within the validity period can be: in one possible implementation, when the second server sends the resource transfer token to the first server, the validity period of the resource transfer token is directly sent to the first server, and accordingly, the first server receives the validity period of the resource transfer token sent by the second server; in another possible implementation, when the second server sends the resource transfer token to the first server, the validity period of the resource transfer token is sent to the first server, and accordingly, the first server determines the validity period of the target resource transfer token according to the time when the resource transfer token is received and the validity period of the resource transfer token. For example, the time when the first server receives the resource transfer token is 13:00:00, and the validity period of the resource transfer token is 1 hour, then the validity period of the resource transfer token is 14:00:00.

[0286] One point that needs to be explained is that when the first server determines the validity period of the resource transfer token, the generation time, usage time and maintenance time of the resource transfer token can also be subtracted. For example, the time when the first server receives the resource transfer token is 13:00:00, and the validity period of the resource transfer token is 1 hour. The generation time, usage time and maintenance time of the first resource transfer token are 5 seconds in total, then the validity period of the resource transfer token is 13:59:55.

[0287] The process of the first server determining the current time and the preset duration to determine whether the resource transfer token is within the validity period can be implemented by the following steps (C1)-(C2), including:

[0288] (C1) The first server determines a first timestamp according to the current time and a preset duration.

[0289] The preset duration can be determined according to the duration required for generating the resource transfer token. In the embodiment of the present invention, the preset duration is not specifically limited. For example, the preset duration can be 10s, 15s or 20s. The first timestamp can be the time point after the current time is added to the preset duration. For example, the current time is t c = 13:00:00, the preset duration is t s =10s, then the first timestamp is t 1 =13:00:10.

[0290] (C2) The first server selects a target resource transfer token whose validity period includes the first timestamp from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token.

[0291] Among them, the validity period of the resource transfer token can be set as needed. In the embodiment of the present invention, the validity period of the resource transfer token is not specifically limited. For example, the validity period of the resource transfer token can be 1 hour, 1.5 hours or 2 hours. In one possible implementation, the first server can randomly select a resource transfer token from the resource transfer tokens in the resource transfer token library, determine the validity period of the resource transfer token, and determine whether the first timestamp is within the validity period of the resource transfer token. In another possible implementation, the first server can determine the validity periods of multiple resource transfer licenses, and select a resource transfer token whose first timestamp is within the validity period from the multiple resource transfer tokens.

[0292] It should be noted that the first server may only determine whether the first timestamp is within the validity period, and the first server may also determine whether the second timestamp including the usage or maintenance time of the resource transfer token in the first server is within the validity period of the resource transfer token. Accordingly, the process of the first server determining whether the second timestamp is within the validity period of the resource transfer token can be implemented by the following steps (C2-1)-(C2-2), including:

[0293] (C2-1) The first server determines a second timestamp according to the current time, a preset duration and a time coefficient.

[0294] The time coefficient may be determined according to the duration of the use of the resource transfer token by the first server, and the time coefficient may be any number greater than 1. In the embodiment of the present invention, the time coefficient is not specifically limited. For example, the time coefficient may be 1.2, 1.5, or 2. The second timestamp may be the sum of the product of the preset duration and the time coefficient and the current time. For example, the current time t c = 13:00:00, the preset duration is t s =10s, the time coefficient is μ=1.2, then the second timestamp is t 1 =13:00:12.

[0295] (C2-2) The first server selects a target resource transfer token whose validity period includes the second timestamp from the resource transfer tokens in the resource transfer token library according to the validity period of each resource transfer token.

[0296] In this implementation, the first server selects a resource transfer token within a validity period from a plurality of resource transfer tokens, thereby avoiding the problem that the resource transfer token is not used for a long time, causing leakage of the resource transfer token and leading to unsafe resource transfer.

[0297] In this implementation, the first server selects an unused resource transfer token within the validity period from multiple resource transfer tokens, thereby preventing repeated selection of a resource transfer token that has been used and avoiding multiple resource transfer operations using the same resource transfer token, causing resource transfer operations to fail.

[0298] One point that needs to be explained is that the first server may first determine the contract identifier and then determine the target resource transfer token; the first server may also first determine the target resource transfer token and then determine the contract identifier; the first server may also simultaneously determine the contract identifier and the target resource transfer token. In the embodiment of the present invention, the order in which the first server determines the contract identifier and the target resource transfer token is not specifically limited. That is, the first server may first execute step 502 and then execute step 503; the first server may also first execute step 503 and then execute step 502; the first server may also simultaneously execute step 502 and step 503. In the embodiment of the present invention, the execution order of step 502 and step 503 is not specifically limited.

[0299] Step 504: The first server generates a resource transfer tag according to the contract identifier and the target resource transfer token.

[0300] The resource transfer mark may be a resource transfer mark including the subscription identifier and a resource transfer token.

[0301] The resource transfer tag may be a message tag, and the resource transfer tag may be composed of a string corresponding to the contract identifier and a string corresponding to the target resource transfer token. The resource transfer tag message may be a multi-bit resource transfer tag message. In the embodiment of the present invention, the number of bits of the resource transfer tag message is not specifically limited. For example, the resource transfer tag message may be 36 bits. Figure 6 As shown, Figure 6 The diagram is a schematic diagram of a resource transfer marking message according to an exemplary embodiment.

[0302] Correspondingly, the process of generating a resource transfer mark can be implemented through the following steps, including: the first server adds the signing identifier to the first field in the resource transfer mark message; adds the target resource transfer token to the second field in the resource transfer mark message to obtain the resource transfer mark.

[0303] Among them, the signing identifier can be a randomly generated string, the number of bits of the string can be an 8-bit string, the string can be a string composed of numbers, or a string composed of numbers and letters. In the embodiment of the present invention, the composition of the string is not specifically limited.

[0304] In this step, the string corresponding to the resource transfer token is determined. The resource transfer token may be a multi-bit string randomly generated by the second server. In the embodiment of the present invention, the number of bits of the resource transfer token is not specifically limited. For example, the resource transfer token may be an 8-bit string. In addition, the string may be a string consisting of numbers or a string consisting of numbers and letters. In the embodiment of the present invention, this is not specifically limited.

[0305] One point that needs to be explained is that the resource transfer marking message may also include other resource transfer information. Accordingly, the first server may also obtain the resource transfer information and add the resource transfer information to the resource transfer message. The above steps may be replaced by: the first server adds the signing identifier to the first field in the resource transfer marking message, and adds the target resource transfer token to the second field in the resource transfer marking message, and adds the resource transfer information to the third resource in the resource transfer marking message to obtain the resource transfer marker.

[0306] The resource transfer information may include at least one of a serial number identifying a resource transfer request, a number indicating a service type supported by a resource transfer card, a code number of an issuing institution corresponding to the resource transfer card, and a reserved field. The resource transfer tag message may include multiple fields, each field corresponding to different resource transfer information. For example, continue to refer to Figure 6 The resource transfer tag message includes 6 fields, a total of 36 resource transfer tags. Among them, the first field corresponds to the target resource transfer token, which takes an 8-bit string. The first field can be composed of a random string and / or numbers, and special symbols can be added to the random string and / or numbers, such as Figure 6 As shown, the string of the first field can be "AsfAd~12". In addition, in order to allow the second server to perceive the expiration time of the target resource transfer token, the target resource transfer token can be composed of two parts: two time points + six token random codes. For example, 13j2L23~ means that the target resource transfer token with the token random code j2L23~ expires at 13:00 on the same day. The second field corresponds to the contract identification, which takes an 8-bit string. The second field can also be composed of random strings and / or numbers, and special symbols can be added to the random strings and / or numbers, such as Figure 6 As shown, the string of the second field can be "TAG14214". The third field corresponds to the resource transfer request serial number, which takes a 12-digit string. The third field can be composed of random numbers, and the random numbers can have the current time + water machine code, such as Figure 6As shown, the third field can be "201911442795". The fourth field corresponds to the business type number of the resource transfer card, which takes a 3-digit string. The fourth field can be composed of numbers, such as Figure 6 As shown, the fourth field can be "001". The fifth field corresponds to the code number of the issuing institution of the resource transfer card, which takes a 3-digit string. The fifth field can be composed of numbers, such as Figure 6 As shown, the fifth field can be "101". The sixth field is a reserved field, which takes a 2-bit string and provides excess reservation for the third field, such as Figure 6 As shown, the sixth field can be "00".

[0307] In this implementation, the first server adds the contract signing identifier, resource transfer token and other resource transfer information to the resource transfer mark message to obtain a resource transfer mark, thereby improving the security during data transmission.

[0308] Step 505: The first server sends a second transfer request to the second server, where the second transfer request carries the resource transfer tag.

[0309] After the first server generates a resource transfer tag corresponding to this resource transfer, it completes the resource transfer operation through the second server. During this process, the first server carries the resource transfer tag in the second transfer request and sends the second transfer request to the second server.

[0310] Step 506: The second server receives the second transfer request.

[0311] Step 507: The second server parses the resource transfer mark to obtain a contract identification and a target resource transfer token.

[0312] In this step, after the second server receives the resource transfer tag, it parses the contract identifier and the target resource transfer token from the resource transfer tag. Accordingly, before this step, the second server and the first server determine a specified parsing rule, and the second server parses the resource transfer tag according to the specified parsing rule to obtain the contract identifier and the target resource transfer token in the resource transfer tag.

[0313] It should be noted that the resource transfer token also includes other resource transfer information. After the second server parses the resource transfer token, it can determine other resource transfer information of this resource transfer.

[0314] Step 508: The second server verifies the second transfer request according to the subscription identifier and the target resource transfer token.

[0315] In this step, the second server verifies the second transfer request according to the contract identifier and the target resource transfer token. The verification process can be implemented by the following steps (1)-(3), including:

[0316] (1) The second server verifies whether the target resource transfer token is a valid resource transfer token.

[0317] In this step, the second server may determine whether the target resource transfer token is a valid resource transfer token by verifying the timeliness and / or whether the resource transfer token has been used.

[0318] (2) The second server verifies whether the contract identification exists in the contract identification database.

[0319] It should be noted that the second server may first execute step (1) and then execute step (2); the second server may first execute step (2) and then execute step (1); the second server may also execute step (1) and step (2) simultaneously. In the embodiment of the present invention, the execution order of step (1) and step (2) is not specifically limited.

[0320] (3) In response to the target resource transfer token being a valid resource transfer token and the contract identifier existing in the contract identifier library, the second server determines that the verification is successful.

[0321] In this implementation, the first server verifies the resource transfer token and the contract identifier to ensure that one resource transfer corresponds to one resource transfer token, different resource transfer operations correspond to different resource transfer tokens, and the resource transfer token is within its validity period, thereby avoiding leakage of the resource transfer token due to long-term use, thereby improving the security of resource transfer.

[0322] Step 509: In response to the verification being successful, the second server performs resource transfer according to the second transfer request.

[0323] In this step, the second server transfers resources through the resource transfer tag in the second transfer request. The second server determines the payer and recipient of this resource transfer from the resource transfer tag, as well as the resource transfer value, and performs resource transfer based on the payer, recipient and resource transfer value.

[0324] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0325] In an embodiment of the present invention, a resource transfer token library is stored in the first server, and the resource transfer token library includes multiple resource transfer tokens. The multiple resource transfer tokens are generated by the second server and sent to the second server. In one possible implementation, the second server periodically sends resource transfer tokens to the first server. Correspondingly, the second server sends multiple resource transfer tokens to the first server every first preset time period. The first preset time period can be set and changed as needed. In an embodiment of the present invention, the first preset time period is not specifically limited. For example, the first preset time period can be 1min, 2min, or 2.5min. In another possible implementation, the first server sends a request for acquisition to the second server. After receiving the request for acquisition sent by the first server, the second server sends a resource transfer token to the first server. Figure 7 As shown, Figure 7 is a flow chart of a resource transfer method according to an exemplary embodiment. The method includes:

[0326] Step 701: The first server sends an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token.

[0327] In a possible implementation, when the first server detects that the number of resource transfer tokens in the resource transfer token library is less than a preset number, the first server sends a request to obtain the second server, wherein the preset number can be set as needed, and is not specifically limited in the embodiment of the present invention. For example, the preset number can be 10, 15, or 20, etc.

[0328] In another possible implementation, the first server sends a request to the second server every second preset time. The second preset time can be set as needed, and the second preset time can be the same as the first preset time, or the same as the first preset time. The second preset time is not specifically limited in the embodiment of the present invention. For example, the second preset time can be 1 minute, 2 minutes, or 2.5 minutes.

[0329] In another possible implementation manner, the first server may also send an acquisition request to the second server each time it detects that a resource transfer token in the resource transfer token library is used.

[0330] Step 702: The second server receives the acquisition request.

[0331] Step 703: The second server generates a new resource transfer token according to the acquisition request.

[0332] In this step, the second server can directly generate a new resource transfer token based on the current time; the second server can also generate a resource transfer token with a validity period based on the current time. The process of the second server generating a new resource transfer token based on factors such as the current time can be implemented by the following steps (1)-(4), including:

[0333] (1) The second server determines the current time, a third timestamp, where the third timestamp is the expiration time point of the current time period, and obtains a preset duration and a time coefficient.

[0334] It should be noted that the third timestamp can be an expiration time point within the current time period, for example, the third timestamp can be an hourly time point. The third timestamp can also be an expiration time point determined by the second server based on the current time and the validity period. For example, if the current time is 13:00:00 and the validity period is 2 hours, the third timestamp can be 15:00:00.

[0335] (2) The second server determines to generate a fourth timestamp of the resource transfer token according to the current time, the preset duration, and the time coefficient.

[0336] In this step, the second server uses the sum of the product of the preset duration and the time coefficient and the current time as the fourth timestamp, ie, the time when the resource transfer token is generated.

[0337] (3) In response to the fourth timestamp being within the third timestamp, generating a resource transfer token with a validity period equal to the third timestamp according to the third timestamp.

[0338] In response to the fourth timestamp being within the third timestamp, it indicates that the resource transfer token can be invalidated within a preset period of time after being generated, has utilization value, and can generate a resource transfer token within the validity period.

[0339] (4) In response to the fourth timestamp not being within the third timestamp, determining a fifth timestamp based on the third timestamp, and generating a resource transfer token with a validity period equal to the fifth timestamp.

[0340] In response to the fourth timestamp not being within the third timestamp, a fifth timestamp after the third timestamp is determined, and a resource transfer token with a validity period of the fifth timestamp is generated. For example, if the time of generating the resource transfer token is 12:59:55, then when the resource transfer token corresponds to the third timestamp of 13:00:00 as the validity period, the resource transfer token is a meaningless resource transfer token, and the validity period of the resource transfer token can be increased by 1 hour to generate a resource transfer token with a validity period of 14:00:00.

[0341] Step 704: The second server sends the new resource transfer token to the first server.

[0342] Step 705: The first server receives the new resource transfer token, and adds the new resource transfer token to the resource transfer token library.

[0343] It should be noted that the storage space in the resource transfer token library may be limited, and the first server can clear the useless resource transfer tokens in the resource transfer token library. For example, the resource transfer token library can delete the resource transfer tokens that have been used, or the resource transfer token library can delete the expired resource transfer tokens. In addition, in a possible implementation, when the first server detects a resource transfer token that has been used, or detects a resource transfer token that has exceeded the validity period, the first server deletes the resource transfer token that has been used and the resource transfer token that has exceeded the validity period. In another possible implementation, the first server deletes all resource transfer tokens in the resource transfer token library every third preset time. The third preset time can be set as needed, and the third preset time and the first preset time can be the same as or different from the second preset time. In the embodiment of the present invention, this is not specifically limited. For example, the third preset time can be 1min, 2min or 2.5min, etc. In another possible implementation, the first server can delete the resource transfer token that has been used and the resource transfer token that has exceeded the validity period in the resource transfer token library every fourth preset time. The fourth preset duration can be set as needed, and the fourth preset duration can be the same as or different from the first preset duration, the second preset duration, and the third preset duration, which is not specifically limited in the embodiment of the present invention. For example, the fourth preset duration can be 1 minute, 2 minutes, or 2.5 minutes.

[0344] The method for deleting a resource transfer token in a resource transfer token library according to the usage status of the resource transfer token can be implemented by the following steps (1)-(3), including:

[0345] (1) When sending the second transfer request to the second server, the first server changes the status of the target resource transfer token from unused to in-use.

[0346] This step is similar to the process in step 502 in which the first server can mark the status of the resource transfer token in the resource transfer token library according to the usage of the resource transfer token, and will not be repeated here.

[0347] (2) Upon receiving the transfer completion indication returned by the second server, the first server changes the status of the target resource transfer token from being used to being used.

[0348] This step is similar to the process in step 502 in which the first server can mark the status of the resource transfer token in the resource transfer token library according to the usage of the resource transfer token, and will not be repeated here.

[0349] (3) In response to clearing resource transfer tokens, the first server deletes resource transfer tokens in the resource transfer token library that are in a used state or whose validity period does not include the current time.

[0350] One thing that needs to be explained is that the first server can also mark the resource transfer token with a validity period. Accordingly, the first server can periodically detect the resource transfer tokens in the resource transfer token library. In response to detecting that the resource transfer token is a resource transfer token that has exceeded its validity period, the resource transfer token can be marked as an expired resource transfer token.

[0351] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0352] Moreover, in an embodiment of the present invention, the first server promptly deletes the resource transfer tokens that have been used and have expired in the resource transfer token library, thereby saving storage space in the resource transfer token library, ensuring the usability of the resource transfer tokens in the resource transfer token library, and improving the security of the resource transfer tokens.

[0353] Figure 8 is a block diagram of a resource transfer device provided according to an exemplary embodiment. Figure 8As shown, the device is applied to the first server, and the resource transfer result processing device includes:

[0354] A first receiving module 81 is used to receive a first transfer request, where the first transfer request carries a user identifier of a user;

[0355] A first acquisition module 82 is used to acquire a contract identification of the user according to the user identification, and select a target resource transfer token from a resource transfer token in a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server;

[0356] A first generating module 83, configured to generate a resource transfer mark according to the contract identification and the target resource transfer token;

[0357] The first sending module 84 is used to send a second transfer request to the second server, where the second transfer request carries the resource transfer tag and is used to request the second server to perform resource transfer.

[0358] In a possible implementation, the first acquisition module 82 is also used to determine the status of multiple resource transfer tokens in the resource transfer token library; based on the status of the multiple resource transfer tokens, select a target resource transfer token with an unused status from the resource transfer tokens in the resource transfer token library.

[0359] In another possible implementation, the first acquisition module 82 is further configured to select a resource transfer token from the resource transfer token library;

[0360] Determine the state of the resource transfer token; in response to the state of the resource transfer token being unused, use the resource transfer token as a target resource transfer token.

[0361] In another possible implementation, the first acquisition module 82 is also used to determine the validity period of each resource transfer token in the resource transfer token library; based on the validity period of each resource transfer token, a target resource transfer token whose validity period includes the current time is selected from the resource transfer tokens in the resource transfer token library.

[0362] In another possible implementation, the first acquisition module 82 is also used to determine a first timestamp based on the current time and a preset duration; and based on the validity period of each resource transfer token, select a target resource transfer token whose validity period includes the first timestamp from the resource transfer tokens in the resource transfer token library.

[0363] In another possible implementation, the first acquisition module 82 is also used to determine a second timestamp based on the current time, a preset duration and a time coefficient; and according to the validity period of each resource transfer token, select a target resource transfer token whose validity period includes the second timestamp from the resource transfer tokens in the resource transfer token library.

[0364] In another possible implementation, the device further includes:

[0365] A second sending module, used for sending an acquisition request to the second server, where the acquisition request is used for requesting the second server to generate a new resource transfer token;

[0366] The second receiving module is used to receive the new resource transfer token and add the new resource transfer token to the resource transfer token library.

[0367] In another possible implementation, the device further includes:

[0368] A third receiving module is used to receive a binding request sent by the terminal, where the binding request carries the user's information to be verified;

[0369] A first verification module, used to verify the information to be verified;

[0370] A second generating module is used to generate a signing identification of the user according to the information to be verified in response to the verification being passed;

[0371] The storage module is used to store the user identifier and the contract identifier in an associated manner.

[0372] In another possible implementation, the device further includes:

[0373] The third sending module is used to send the contract identification to the second server, so that the second server adds the contract identification to the contract identification library.

[0374] In another possible implementation, the device further includes:

[0375] A first modification module, configured to modify the state of the target resource transfer token from unused to in-use when sending a second transfer request to the second server;

[0376] A second modification module, configured to modify the state of the target resource transfer token from being in use to being used upon receiving a transfer completion indication returned by the second server;

[0377] The deleting module is used to delete the resource transfer tokens in the resource transfer token library whose status is used or whose validity period does not include the current time in response to clearing the resource transfer tokens.

[0378] In another possible implementation, the first generating module 83 is used to add the subscription identifier to the first field in the resource transfer mark message, and add the target resource transfer token to the second field in the resource transfer mark message to obtain the resource transfer mark.

[0379] In another possible implementation, the device further includes:

[0380] The second acquisition module is used to acquire resource transfer information;

[0381] The first generation module 83 is also used to add the signing identifier to the first field in the resource transfer marking message, add the target resource transfer token to the second field in the resource transfer marking message, and add the resource transfer information to the third resource in the resource transfer marking message to obtain the resource transfer marker.

[0382] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0383] Fig. 9 is a block diagram of a resource transfer device provided according to an exemplary embodiment. Fig. 9 As shown, the device is applied to the second server, and the resource transfer result processing device includes:

[0384] A fourth receiving module 91 is configured to receive a second transfer request sent by the first server, wherein the second transfer request carries a resource transfer mark;

[0385] A parsing module 92, used to parse the resource transfer mark to obtain a contract identification and a target resource transfer token;

[0386] A second verification module 93, configured to verify the second transfer request according to the subscription identifier and the target resource transfer token;

[0387] The resource transfer module 94 is configured to perform resource transfer according to the second transfer request in response to the verification being successful.

[0388] In one possible implementation, the second verification module 93 is also used to verify whether the target resource transfer token is a valid resource transfer token, and to verify whether the contract identifier exists in the contract identifier library; in response to the target resource transfer token being a valid resource transfer token and the contract identifier existing in the contract identifier library, it is determined that the verification is successful.

[0389] In another possible implementation, the device further includes:

[0390] The third generating module is used to generate a resource transfer token, and send the resource transfer token to the first server, so that the first server adds the resource transfer token to the resource transfer token library.

[0391] In another possible implementation, the device further includes:

[0392] A fifth receiving module, configured to receive an acquisition request sent by the first server;

[0393] The third generating module is further used to generate a new resource transfer token according to the acquisition request;

[0394] The fourth sending module is used to send the new resource transfer token to the first server, so that the first server adds the new resource transfer token to the resource transfer token library.

[0395] In another possible implementation, the device further includes:

[0396] A sixth receiving module, configured to receive the signing identifier sent by the first server;

[0397] The adding module is used to add the signing ID to the signing ID library.

[0398] In another possible implementation, the third generation module is also used to determine the current time, a third timestamp, where the third timestamp is the expiration time point of the current time period, and to obtain a preset duration and a time coefficient; determine a fourth timestamp for generating the resource transfer token based on the current time, the preset duration and the time coefficient; in response to the fourth timestamp being within the third timestamp, generate a resource transfer token with a validity period of the third timestamp based on the third timestamp; in response to the fourth timestamp not being within the third timestamp, determine a fifth timestamp based on the third timestamp, and generate a resource transfer token with a validity period of the fifth timestamp.

[0399] In the embodiment of the present invention, the first server selects a target resource transfer token from the resource transfer token library sent by the second server according to the first transfer request, generates a resource transfer tag according to the target resource transfer token and the contract identifier, sends a second transfer request carrying the resource transfer tag to the second server, and the second server performs resource transfer according to the second transfer request. By dynamically verifying the resource transfer process with the target resource transfer token, one resource transfer corresponds to one resource transfer token, avoiding the leakage of user's sensitive information after the second transfer request is intercepted, and improving the security of resource transfer.

[0400] It should be noted that: the resource transfer device provided in the above embodiment only uses the division of the above functional modules as an example to illustrate when transferring resources. In actual applications, the above functional allocation can be completed by different functional modules as needed, that is, the internal structure of the terminal is divided into different functional modules to complete all or part of the functions described above. In addition, the resource transfer device provided in the above embodiment and the resource transfer method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0401] Fig.10 The structure block diagram of the terminal 1000 provided by some exemplary embodiments of the present invention is shown. The terminal 1000 may be: a smart phone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III, Moving Picture Experts Group Audio Layer 3), an MP4 (Moving Picture Experts Group Audio Layer IV, Moving Picture Experts Group Audio Layer 4) player, a notebook computer or a desktop computer. The terminal 1000 may also be called a user device, a portable terminal, a laptop terminal, a desktop terminal or other names.

[0402] Typically, the terminal 1000 includes a processor 1001 and a memory 1002 .

[0403] The processor 1001 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1001 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1001 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1001 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0404] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1002 is used to store at least one instruction, which is used to be executed by the processor 1001 to implement the resource transfer method provided in the method embodiment of the present invention.

[0405] In some embodiments, the terminal 1000 may also optionally include: a peripheral device interface 1003 and at least one peripheral device. The processor 1001, the memory 1002 and the peripheral device interface 1003 may be connected via a bus or a signal line. Each peripheral device may be connected to the peripheral device interface 1003 via a bus, a signal line or a circuit board. Specifically, the peripheral device includes: at least one of a radio frequency circuit 1004, a display screen 1005, a camera assembly 1006, an audio circuit 1007, a positioning assembly 1008 and a power supply 1009.

[0406] The peripheral device interface 1003 may be used to connect at least one peripheral device related to I / O (Input / Output) to the processor 1001 and the memory 1002. In some embodiments, the processor 1001, the memory 1002, and the peripheral device interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, the memory 1002, and the peripheral device interface 1003 may be implemented on a separate chip or circuit board, which is not limited in this embodiment.

[0407] The radio frequency circuit 1004 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The radio frequency circuit 1004 communicates with the communication network and other communication devices through electromagnetic signals. The radio frequency circuit 1004 converts the electrical signal into an electromagnetic signal for transmission, or converts the received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 1004 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, and the like. The radio frequency circuit 1004 can communicate with other terminals through at least one wireless communication protocol. The wireless communication protocol includes, but is not limited to: a metropolitan area network, various generations of mobile communication networks (2G, 3G, 4G and 5G), a wireless local area network and / or a WiFi (Wireless Fidelity) network. In some embodiments, the radio frequency circuit 1004 may also include circuits related to NFC (Near Field Communication), which is not limited in the present invention.

[0408] The display screen 1005 is used to display a UI (User Interface). The UI may include graphics, text, icons, videos, and any combination thereof. When the display screen 1005 is a touch display screen, the display screen 1005 also has the ability to collect touch signals on the surface or above the surface of the display screen 1005. The touch signal can be input to the processor 1001 as a control signal for processing. At this time, the display screen 1005 can also be used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, the display screen 1005 can be one, and the front panel of the terminal 1000 is set; in other embodiments, the display screen 1005 can be at least two, which are respectively set on different surfaces of the terminal 1000 or are folded; in some other embodiments, the display screen 1005 can be a flexible display screen, which is set on the curved surface or folded surface of the terminal 1000. Even, the display screen 1005 can also be set to a non-rectangular irregular shape, that is, a special-shaped screen. The display screen 1005 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0409] The camera assembly 1006 is used to capture images or videos. Optionally, the camera assembly 1006 includes a front camera and a rear camera. Typically, the front camera is arranged on the front panel of the terminal, and the rear camera is arranged on the back of the terminal. In some embodiments, there are at least two rear cameras, which are any one of a main camera, a depth of field camera, a wide-angle camera, and a telephoto camera, so as to realize the fusion of the main camera and the depth of field camera to realize the background blur function, the fusion of the main camera and the wide-angle camera to realize the panoramic shooting and VR (Virtual Reality) shooting function or other fusion shooting functions. In some embodiments, the camera assembly 1006 may also include a flash. The flash can be a monochrome temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cold light flash, which can be used for light compensation at different color temperatures.

[0410] The audio circuit 1007 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals and input them into the processor 1001 for processing, or input them into the radio frequency circuit 1004 to achieve voice communication. For the purpose of stereo acquisition or noise reduction, there may be multiple microphones, which are respectively arranged at different parts of the terminal 1000. The microphone may also be an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signal from the processor 1001 or the radio frequency circuit 1004 into sound waves. The speaker may be a traditional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signal into sound waves audible to humans, but also convert the electrical signal into sound waves inaudible to humans for purposes such as ranging. In some embodiments, the audio circuit 1007 may also include a headphone jack.

[0411] The positioning component 1008 is used to locate the current geographical location of the terminal 1000 to implement navigation or LBS (Location Based Service). The positioning component 1008 can be a positioning component based on the US GPS (Global Positioning System), China's Beidou system, Russia's Grenas system or the European Union's Galileo system.

[0412] The power supply 1009 is used to power various components in the terminal 1000. The power supply 1009 can be an alternating current, a direct current, a disposable battery, or a rechargeable battery. When the power supply 1009 includes a rechargeable battery, the rechargeable battery can support wired charging or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0413] In some embodiments, the terminal 1000 further includes one or more sensors 1010 , including but not limited to: an acceleration sensor 1011 , a gyroscope sensor 1012 , a pressure sensor 1013 , a fingerprint sensor 1014 , an optical sensor 1015 , and a proximity sensor 1016 .

[0414] The acceleration sensor 1011 can detect the magnitude of acceleration on the three coordinate axes of the coordinate system established by the terminal 1000. For example, the acceleration sensor 1011 can be used to detect the components of gravity acceleration on the three coordinate axes. The processor 1001 can control the display screen 1005 to display the user interface in a horizontal view or a vertical view according to the gravity acceleration signal collected by the acceleration sensor 1011. The acceleration sensor 1011 can also be used to collect motion data of games or users.

[0415] The gyro sensor 1012 can detect the body direction and rotation angle of the terminal 1000, and the gyro sensor 1012 can cooperate with the acceleration sensor 1011 to collect the user's 3D actions on the terminal 1000. The processor 1001 can implement the following functions based on the data collected by the gyro sensor 1012: motion sensing (such as changing the UI according to the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0416] The pressure sensor 1013 can be set on the side frame of the terminal 1000 and / or the lower layer of the display screen 1005. When the pressure sensor 1013 is set on the side frame of the terminal 1000, it can detect the user's holding signal of the terminal 1000, and the processor 1001 performs left and right hand recognition or shortcut operation according to the holding signal collected by the pressure sensor 1013. When the pressure sensor 1013 is set on the lower layer of the display screen 1005, the processor 1001 controls the operability controls on the UI interface according to the user's pressure operation on the display screen 1005. The operability controls include at least one of a button control, a scroll bar control, an icon control, and a menu control.

[0417] The fingerprint sensor 1014 is used to collect the user's fingerprint, and the processor 1001 identifies the user's identity based on the fingerprint collected by the fingerprint sensor 1014, or the fingerprint sensor 1014 identifies the user's identity based on the collected fingerprint. When the user's identity is identified as a trusted identity, the processor 1001 authorizes the user to perform relevant sensitive operations, which include unlocking the screen, viewing encrypted information, downloading software, paying, and changing settings. The fingerprint sensor 1014 can be set on the front, back, or side of the terminal 1000. When a physical button or a manufacturer logo is set on the terminal 1000, the fingerprint sensor 1014 can be integrated with the physical button or the manufacturer logo.

[0418] The optical sensor 1015 is used to collect the ambient light intensity. In one embodiment, the processor 1001 can control the display brightness of the display screen 1005 according to the ambient light intensity collected by the optical sensor 1015. Specifically, when the ambient light intensity is high, the display brightness of the display screen 1005 is increased; when the ambient light intensity is low, the display brightness of the display screen 1005 is reduced. In another embodiment, the processor 1001 can also dynamically adjust the shooting parameters of the camera assembly 1006 according to the ambient light intensity collected by the optical sensor 1015.

[0419] The proximity sensor 1016, also called a distance sensor, is usually arranged on the front panel of the terminal 1000. The proximity sensor 1016 is used to collect the distance between the user and the front of the terminal 1000. In one embodiment, when the proximity sensor 1016 detects that the distance between the user and the front of the terminal 1000 is gradually decreasing, the processor 1001 controls the display screen 1005 to switch from the screen-on state to the screen-off state; when the proximity sensor 1016 detects that the distance between the user and the front of the terminal 1000 is gradually increasing, the processor 1001 controls the display screen 1005 to switch from the screen-off state to the screen-on state.

[0420] Those skilled in the art will understand that Fig. 9 The structure shown in the figure does not constitute a limitation on the terminal 1000, and the terminal 1000 may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.

[0421] Fig.11 It is a structural diagram of a server provided by an exemplary embodiment of the present invention. The server can be the first server or the second server. The server 1100 may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 1101 and one or more memories 1102, wherein the memory 1102 stores at least one instruction, and the at least one instruction is loaded and executed by the processor 1101 to implement the resource transfer method provided by the above-mentioned various method embodiments. Of course, the server may also have components such as a wired or wireless network interface, a keyboard, and an input and output interface for input and output. The server may also include other components for implementing device functions, which will not be repeated here.

[0422] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including instructions, and the instructions can be executed by a processor in a terminal to complete the resource transfer method in the above embodiment. For example, the computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device.

[0423] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0424] The above contents are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A resource transfer method, It is characterized in that The method comprises: The terminal sends a first transfer request to the first server, wherein the first transfer request carries a user identifier of the user; The first server receives the first transfer request, obtains the user's subscription identifier according to the user identifier, and selects a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is the resource transfer token sent by the second server; generates a resource transfer tag according to the subscription identifier and the target resource transfer token; and sends a second transfer request to the second server, where the second transfer request carries the resource transfer tag; The second server receives the second transfer request, verifies the contract identification and the target resource transfer token in the second transfer request, and performs resource transfer according to the second transfer request in response to successful verification; The terminal is installed with a third-party application, the first server is a server corresponding to the third-party application, and the second server is a server for performing resource transfer.

2. The method according to claim 1, It is characterized in that The method further comprises: The first server sends an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token; The second server receives the acquisition request, generates a new resource transfer token, and sends the new resource transfer token to the first server; The first server receives the new resource transfer token, and adds the new resource transfer token to the resource transfer token library.

3. The method according to claim 1, It is characterized in that Before the terminal sends the first transfer request to the first server, the method further includes: The terminal sends a binding request to the first server, wherein the binding request carries the to-be-verified information of the user; The first server receives the binding request sent by the terminal, and verifies the information to be verified; In response to the verification being successful, the first server generates a contract identification of the user according to the information to be verified, and stores the user identification and the contract identification in an associated manner.

4. The method according to claim 3, It is characterized in that After the first server generates the signing identification of the user according to the information to be verified, the method further includes: The first server sends the signing identifier to the second server; The second server receives the contract identification, and adds the contract identification to a contract identification library.

5. A resource transfer method, It is characterized in that The method is applied to a first server, and the method includes: receiving a first transfer request, wherein the first transfer request carries a user identifier of a user; According to the user identifier, obtaining the user's contract identifier, and selecting a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server; Generate a resource transfer mark according to the contract identification and the target resource transfer token; Sending a second transfer request to a second server, where the second transfer request carries the resource transfer tag and is used to request the second server to perform resource transfer; The first server is a server corresponding to a third-party application, and the second server is a server for performing resource transfer.

6. The method according to claim 5, It is characterized in that The step of selecting a target resource transfer token from a resource transfer token library comprises: Determining the status of a plurality of resource transfer tokens in the resource transfer token library; According to the states of the plurality of resource transfer tokens, a target resource transfer token in an unused state is selected from the resource transfer tokens in the resource transfer token library.

7. The method according to claim 5, It is characterized in that The step of selecting a target resource transfer token from a resource transfer token library comprises: Selecting a resource transfer token from the resource transfer token library; determining a status of the resource transfer token; In response to the resource transfer token being in a state of being unused, the resource transfer token is used as a target resource transfer token.

8. The method according to claim 5, It is characterized in that The step of selecting a target resource transfer token from a resource transfer token library comprises: Determining the validity period of each resource transfer token in the resource transfer token library; According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the current time is selected from the resource transfer tokens in the resource transfer token library.

9. The method according to claim 8, It is characterized in that The step of selecting, according to the validity period of each resource transfer token, a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library comprises: Determine a first timestamp based on the current time and a preset duration; According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the first timestamp is selected from the resource transfer tokens in the resource transfer token library.

10. The method according to claim 8, It is characterized in that The step of selecting, according to the validity period of each resource transfer token, a target resource transfer token within the validity period at the current time from the resource transfer tokens in the resource transfer token library comprises: Determine a second timestamp according to the current time, the preset duration and the time coefficient; According to the validity period of each resource transfer token, a target resource transfer token whose validity period includes the second timestamp is selected from the resource transfer tokens in the resource transfer token library.

11. The method according to any one of claims 5 to 10, It is characterized in that The method further comprises: Sending an acquisition request to the second server, where the acquisition request is used to request the second server to generate a new resource transfer token; The new resource transfer token is received, and the new resource transfer token is added to the resource transfer token library.

12. The method according to claim 5, It is characterized in that Before receiving the first transfer request, the method further includes: Receiving a binding request sent by a terminal, wherein the binding request carries the user's information to be verified; Verifying the information to be verified; In response to the verification being successful, generating a signing identification of the user according to the information to be verified; The user identifier and the contract identifier are stored in association.

13. The method according to claim 12, It is characterized in that After generating the user's signing identification according to the information to be verified, the method further includes: The contract identification is sent to the second server, so that the second server adds the contract identification to a contract identification library.

14. The method according to claim 8, It is characterized in that The method further comprises: When sending the second transfer request to the second server, changing the state of the target resource transfer token from unused to in-use; Upon receiving the transfer completion indication returned by the second server, changing the state of the target resource transfer token from being in use to being used; In response to clearing resource transfer tokens, resource transfer tokens in the resource transfer token library whose status is that they have been used or whose validity period does not include the current time are deleted.

15. The method according to claim 5, It is characterized in that The generating a resource transfer mark according to the subscription identifier and the target resource transfer token includes: The subscription identifier is added to a first field in a resource transfer mark message, and the target resource transfer token is added to a second field in the resource transfer mark message to obtain the resource transfer mark.

16. The method according to claim 5, It is characterized in that Before generating a resource transfer mark according to the subscription identifier and the target resource transfer token, the method further includes: Get resource transfer information; Generating a resource transfer mark according to the contract identifier and the target resource transfer token includes: The subscription identifier is added to the first field in the resource transfer mark message, the target resource transfer token is added to the second field in the resource transfer mark message, and the resource transfer information is added to the third field in the resource transfer mark message to obtain the resource transfer mark.

17. A resource transfer method, It is characterized in that The method is applied in the second server, and the method includes: receiving a second transfer request sent by the first server, wherein the second transfer request carries a resource transfer mark; Parsing the resource transfer mark to obtain a signing identifier and a target resource transfer token; Verifying the second transfer request according to the subscription identifier and the target resource transfer token; In response to the verification being successful, performing resource transfer according to the second transfer request; The first server is a server corresponding to a third-party application, and the second server is a server for performing resource transfer.

18. The method according to claim 17, It is characterized in that The verifying the second transfer request according to the subscription identifier and the target resource transfer token includes: Verifying whether the target resource transfer token is a valid resource transfer token, and verifying whether the signing identifier exists in a signing identifier library; In response to the target resource transfer token being a valid resource transfer token and the contract identifier existing in the contract identifier library, it is determined that the verification is successful.

19. The method according to claim 17 or 18, It is characterized in that Before receiving the second transfer request sent by the first server, the method further includes: A resource transfer token is generated, and the resource transfer token is sent to the first server, so that the first server adds the resource transfer token to a resource transfer token library.

20. The method according to claim 19, It is characterized in that The method further comprises: Receiving an acquisition request sent by the first server; Generate a new resource transfer token according to the acquisition request; The new resource transfer token is sent to the first server, so that the first server adds the new resource transfer token to the resource transfer token library.

21. The method according to claim 17, It is characterized in that Before verifying the second transfer request according to the subscription identifier and the target resource transfer token, the method further includes: Receiving the signing identifier sent by the first server; The signing identity is added to a signing identity library.

22. The method according to claim 19, It is characterized in that The generating of a resource transfer token comprises: Determine the current time, a third timestamp, where the third timestamp is the expiration time point of the current time period, and obtain a preset duration and a time coefficient; Determine, according to the current time, the preset duration and the time coefficient, a fourth timestamp for generating the resource transfer token; In response to the fourth timestamp being within the third timestamp, generating a resource transfer token having a validity period equal to the third timestamp according to the third timestamp; In response to the fourth timestamp not being within the third timestamp, a fifth timestamp is determined according to the third timestamp, and a resource transfer token having a validity period of the fifth timestamp is generated.

23. A resource transfer system, It is characterized in that The system comprises: a terminal, a first server and a second server; The terminal is used to send a first transfer request to the first server, wherein the first transfer request carries a user identifier of a user; The first server is configured to receive the first transfer request, obtain the user's subscription identifier according to the user identifier, and select a target resource transfer token from a resource transfer token library, where the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server; generate a resource transfer tag according to the subscription identifier and the target resource transfer token; and send a second transfer request to the second server, where the second transfer request carries the resource transfer tag; The second server is configured to receive the second transfer request, verify the contract identification and the target resource transfer token in the second transfer request, and perform resource transfer according to the second transfer request in response to successful verification; The terminal is installed with a third-party application, the first server is a server corresponding to the third-party application, and the second server is a server for performing resource transfer.

24. The system according to claim 23, It is characterized in that The first server is further used to send an acquisition request to the second server, wherein the acquisition request is used to request the second server to generate a new resource transfer token; The second server is further configured to receive the acquisition request, generate a new resource transfer token, and send the new resource transfer token to the first server; The first server is further configured to receive the new resource transfer token and add the new resource transfer token to the resource transfer token library.

25. The system according to claim 23, It is characterized in that The terminal is further configured to send a binding request to the first server, wherein the binding request carries the to-be-verified information of the user; The first server is further configured to receive a binding request sent by the terminal and verify the information to be verified; The first server is further configured to generate a signing identifier of the user according to the information to be verified in response to the verification being successful, and store the user identifier and the signing identifier in an associated manner.

26. The system according to claim 25, It is characterized in that The first server is further configured to send the signing identifier to the second server; The second server is further configured to receive the contract signing identifier and add the contract signing identifier to a contract signing identifier library.

27. A resource transfer device, It is characterized in that The device is applied to a first server, and includes: A first receiving module, configured to receive a first transfer request, wherein the first transfer request carries a user identifier of a user; A first acquisition module, configured to acquire a contract identification of the user according to the user identification, and select a target resource transfer token from a resource transfer token in a resource transfer token library, wherein the resource transfer token in the resource transfer token library is a resource transfer token sent by the second server; A first generating module, configured to generate a resource transfer mark according to the signing identifier and the target resource transfer token; A first sending module, configured to send a second transfer request to a second server, wherein the second transfer request carries the resource transfer tag and is configured to request the second server to perform resource transfer; The first server is a server corresponding to a third-party application, and the second server is a server for performing resource transfer.

28. A resource transfer device, It is characterized in that The device is applied to a second server, and includes: A fourth receiving module, configured to receive a second transfer request sent by the first server, wherein the second transfer request carries a resource transfer mark; A parsing module, used for parsing the resource transfer mark to obtain a signing identifier and a target resource transfer token; A second verification module, configured to verify the second transfer request according to the subscription identifier and the target resource transfer token; A resource transfer module, configured to perform resource transfer according to the second transfer request in response to the verification being passed; The first server is a server corresponding to a third-party application, and the second server is a server for performing resource transfer.

29. A first server, It is characterized in that The first server includes one or more processors and one or more memories, wherein at least one instruction is stored in the one or more memories, and the at least one instruction is loaded and executed by the one or more processors to implement the operation performed by the resource transfer method as described in any one of claims 5 to 16.

30. A second server, It is characterized in that The second server includes one or more processors and one or more memories, wherein at least one instruction is stored in the one or more memories, and the at least one instruction is loaded and executed by the one or more processors to implement the operations performed by the resource transfer method as described in any one of claims 17 to 22.

31. A non-transitory computer-readable storage medium, It is characterized in that The storage medium stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the operation performed by the resource transfer method according to any one of claims 5 to 16.

32. A non-transitory computer-readable storage medium, It is characterized in that The storage medium stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the operation performed by the resource transfer method according to any one of claims 17 to 22.

Images