Disclosure of Invention
The technical problem to be solved by the embodiments of the present application is to provide a service processing method, which can effectively prevent the execution of abnormal services, thereby improving the security of service processing.
Correspondingly, the embodiment of the application also provides a service processing device and an intelligent terminal, which are used for ensuring the realization and the application of the method.
In order to solve the above problem, the present application discloses a service processing method, including:
a service processing method comprises the following steps:
receiving a service request of a first user;
sending a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user;
receiving the verification result of the second client to the verification request;
and when the verification result accords with a preset rule, terminating the processing of the service request.
Optionally, the second user is determined by:
determining the second user according to a verification rule corresponding to the first user; or
Searching in a mapping relation among the first user information, the verification rule and the second user information according to the first user information and the service information carried by the service request to obtain the information of the second user; or
And searching the mapping relation between the first user information and the second user information according to the first user information carried by the service request to obtain the information of the second user.
Optionally, the step of determining the second user according to the validation rule corresponding to the first user includes:
and when the service information carried in the service request and/or the service information carried in the service request in a preset time period conforms to the verification rule, obtaining second user information corresponding to the verification rule according to a mapping relation between the pre-established verification rule and the second user information, and using the second user information as the information of the second user.
Optionally, the method further comprises:
sending a termination message to a first client of the first user; the termination message is used to indicate the termination of the service request.
Optionally, the method further comprises:
receiving a setting request; the setting request carries first user information, second user information and corresponding verification rules;
sending the setting request to a second client corresponding to a second user according to the second user information;
receiving a first confirmation message which is returned by the second client and aims at the setting request;
after receiving the first confirmation message, establishing a mapping relation between the verification rule and the second user information, or a mapping relation between the first user information and the second user information, or a mapping relation between the first user, the verification rule and the second user.
Optionally, the method further comprises:
determining the current state of a user account corresponding to the first user information, and rejecting the setting request when the current state is a preset state; or
Rejecting the setting request according to a first rejection message which is returned by the second client and aims at the setting request; or
Determining a third user corresponding to the verification rule of which the verification range exceeds the verification range corresponding to the verification rule, sending the setting request to a third client of the third user, receiving a third rejection message which is returned by the third client and aims at the setting request, and rejecting the setting request according to the third rejection message.
Optionally, the method further comprises:
receiving a cancel request or a change request; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
sending the cancel request or the change request to a second client corresponding to a second user according to the second user information;
receiving a second confirmation message which is returned by the second client and aims at the cancel request or the change request;
and after receiving the second confirmation message, deleting the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user.
Optionally, the method further comprises:
receiving a second rejection message for the cancel request or the change request returned by the second client;
and after receiving the second rejection message, maintaining the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user.
Optionally, the verification result includes: and if the preset rule is blocked or allowed, the preset rule comprises the following steps:
at least one verification result comprises a block; or
The number of blocks is greater than a first threshold; or
The ratio of the number of blocks relative to the number of rejections is greater than a second threshold.
Optionally, the validation rule includes: one or more rules corresponding to the service information;
the service information includes at least one of the following information: the service corresponding parameters, the service object, the service source, the service occurrence time, the service occurrence place and the service occurrence times in a preset time period;
the validation rules include at least one of the following:
the corresponding parameters of the service are within the preset limit range;
the service object is in the range of the preset object;
the service source is within a preset source range;
the service occurrence time is within a preset time range;
the service occurrence place is within the range of the preset place; and
the number of times of service occurrence in the preset time period is within the preset number range.
On the other hand, the application discloses a service processing method, which comprises the following steps:
receiving a verification request which is sent by a server and corresponds to a service request of a first user;
verifying the verification request through a second user to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user;
and sending the verification result to the server.
Optionally, the method further comprises:
receiving a setting request sent by a server; the setting request carries first user information, second user information and corresponding verification rules;
acquiring a first confirmation message aiming at the setting request by a second user;
sending the first acknowledgement message to the server.
Optionally, the method further comprises:
obtaining a first rejection message aiming at the setting request by a second user;
sending the first rejection message to the server.
Optionally, the method further comprises:
receiving a cancel request or a change request sent by a server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
acquiring a second confirmation message aiming at the cancel request or the change request by a second user;
sending the second acknowledgement message to the server.
Optionally, the method further comprises:
acquiring a second cancellation message aiming at the cancellation request or the change request by a second user;
sending the second cancellation message to the server.
In another aspect, the present application discloses a service processing method, including:
sending a service request of a first user to a server so that the server sends a verification request corresponding to the service request to a second client of a second user, and the second user verifies the verification request to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user.
Optionally, the method further comprises:
receiving a termination message returned by the server aiming at the service request; the termination message is used to indicate the termination of the service request.
Optionally, the method further comprises:
sending a setting request to a server; the setting request carries first user information, second user information and corresponding verification rules.
Optionally, the method further comprises:
sending a cancel request or a change request to a server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules.
In another aspect, the present application discloses a service processing apparatus, including:
the first receiving module is used for receiving a service request of a first user;
the first sending module is used for sending a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user;
a second receiving module, configured to receive a verification result of the second client on the verification request; and
and the termination module is used for terminating the processing of the service request when the verification result accords with a preset rule.
Optionally, the apparatus further comprises: a determining module for determining the second user;
the determining module includes:
the first determining submodule determines the second user according to a verification rule corresponding to the first user; or
The second determining submodule searches a mapping relation among the first user information, the verification rule and the second user information according to the first user information and the service information carried by the service request so as to obtain the information of the second user; or
And the third determining submodule searches a mapping relation between the first user information and the second user information according to the first user information carried by the service request so as to obtain the information of the second user.
Optionally, the first determining sub-module includes:
and the searching unit is used for obtaining second user information corresponding to the verification rule according to a mapping relation between the pre-established verification rule and the second user information when the service information carried in the service request and/or the service information carried in the service request in a preset time period conforms to the verification rule, and the second user information is used as the information of the second user.
Optionally, the apparatus further comprises:
a second sending module, configured to send a termination message to a first client of the first user; the termination message is used to indicate the termination of the service request.
Optionally, the apparatus further comprises:
a third receiving module, configured to receive a setting request; the setting request carries first user information, second user information and corresponding verification rules;
a third sending module, configured to send the setting request to a second client corresponding to a second user according to the second user information;
a fourth receiving module, configured to receive a first acknowledgement message, which is returned by the second client and is in response to the setting request;
and the establishing module is used for establishing a mapping relation between the verification rule and the second user information, or a mapping relation between the first user information and the second user information, or a mapping relation between the first user, the verification rule and the second user after receiving the first confirmation message.
Optionally, the apparatus further comprises:
the first rejection module is used for determining the current state of a user account corresponding to the first user information, and rejecting the setting request when the current state is a preset state; or
The second rejection module is used for rejecting the setting request according to a first rejection message which is returned by the second client and aims at the setting request; or
And the second rejection module is used for determining a third user corresponding to the verification rule of which the verification range exceeds the verification range corresponding to the verification rule, sending the setting request to a third client of the third user, receiving a third rejection message which is returned by the third client and aims at the setting request, and rejecting the setting request according to the third rejection message.
Optionally, the apparatus further comprises:
a fifth receiving module, configured to receive a cancel request or a change request; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
a fourth sending module, configured to send the cancel request or the change request to a second client corresponding to a second user according to the second user information;
a sixth receiving module, configured to receive a second acknowledgement message, which is returned by the second client and is addressed to the cancel request or the change request;
and the deleting module is used for deleting the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user after receiving the second confirmation message.
Optionally, the apparatus further comprises:
a seventh receiving module, configured to receive a second reject message, which is returned by the second client and is addressed to the cancel request or the change request;
and the maintaining module is used for maintaining the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user after receiving the second rejection message.
On the other hand, the present application discloses a service processing apparatus, including:
the first receiving module is used for receiving a verification request which is sent by the server and corresponds to the service request of the first user;
the verification module is used for verifying the verification request through a second user to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user; and
and the first sending module is used for sending the verification result to the server.
Optionally, the apparatus further comprises:
the second receiving module is used for receiving a setting request sent by the server; the setting request carries first user information, second user information and corresponding verification rules;
a first obtaining module, configured to obtain, by a second user, a first confirmation message for the setting request;
and the second sending module is used for sending the first confirmation message to the server.
Optionally, the apparatus further comprises:
the second obtaining module is used for obtaining a first refusal message aiming at the setting request through a second user;
a third sending module, configured to send the first reject message to the server.
Optionally, the apparatus further comprises:
the third receiving module is used for receiving a cancel request or a change request sent by the server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
a third obtaining module, configured to obtain, by a second user, a second confirmation message for the cancel request or the change request;
a fourth sending module, configured to send the second acknowledgement message to the server.
Optionally, the apparatus further comprises:
a fourth obtaining module, configured to obtain, by a second user, a second cancel message for the cancel request or the change request;
a fifth sending module, configured to send the second cancellation message to the server.
In another aspect, the present application discloses a service processing apparatus, including:
the first sending module is used for sending a service request of a first user to a server so that the server sends a verification request corresponding to the service request to a second client of a second user and the second user verifies the verification request to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user.
Optionally, the apparatus further comprises:
a receiving module, configured to receive a termination message returned by the server for the service request; the termination message is used to indicate the termination of the service request.
Optionally, the apparatus further comprises:
the second sending module is used for sending a setting request to the server; the setting request carries first user information, second user information and corresponding verification rules.
Optionally, the apparatus further comprises:
the third sending module is used for sending a cancel request or a change request to the server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules.
In yet another aspect, the present application discloses an intelligent terminal comprising a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for:
receiving a service request of a first user;
sending a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user;
receiving the verification result of the second client to the verification request;
and when the verification result accords with a preset rule, terminating the processing of the service request.
Compared with the prior art, the embodiment of the application has the following advantages:
in the processing flow of the service request, the embodiment of the application executes the verification operation by a second user except the first user; since the second user is usually a user having a preset user relationship with the first user, the second user has an ability to effectively control the risk of the service request, so that the embodiment of the present application can effectively prevent the execution of the abnormal service, thereby improving the security of the service processing.
For example, the second user may be a friend of the first user, and the second user can timely know that the user account of the first user is stolen, so that after it is determined that the user account of the first user is stolen, the illegal service corresponding to the user account of the first user can be prevented.
For another example, the second user may be a guardian of the first user, and the second user has the capability of blocking abnormal services corresponding to the user account of the guarded user, so that the second user can control the services corresponding to the accounts of children of the second user, so as to prevent the children from making bad payment under the conditions of being deceived and the like.
For another example, the second user may be any user having a preset user relationship with the first user, and when the first user triggers the service request under the condition of misoperation, the second user may timely know the misoperation condition, so that the misoperation service corresponding to the user account of the first user may be prevented.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present application more comprehensible, the present application is described in further detail with reference to the accompanying drawings and the detailed description.
In the existing payment scheme, generally, after a user inputs a credential in an intelligent terminal, the user no longer has control capability on a payment service. In fact, the intelligent terminal lacks effective judgment capability for the user, so that various payment safety problems are caused. For example, a user may illegally transfer or use large amounts of funds after the account number is stolen.
The inventor of the present invention has found through research that users usually have a wide range of interpersonal relationships (hereinafter, collectively referred to as user relationships), for example, there are various effective information communication and identity confirmation methods between users, and illegal users (such as network attackers and terminal thieves) usually cannot know the user relationships, so that it is difficult to pretend to be users having user relationships with legal users to cheat.
Therefore, one of the core concepts of the embodiments of the present application is to introduce a verification link in a processing flow of a service request, where the verification link is performed by a second user other than a first user; since the second user is usually a user having a preset user relationship with the first user, the second user can effectively control the risk of the service request, so that the embodiment of the application can effectively prevent the execution of the abnormal service, and the security of service processing can be improved. For example, the second user may be a friend of the first user, and the second user can timely know that the user account of the first user is stolen, so that after it is determined that the user account of the first user is stolen, the illegal service corresponding to the user account of the first user can be prevented. For another example, the second user may be a guardian of the first user, and the second user has the capability of blocking abnormal services corresponding to the user account of the guarded user, so that the second user can control the services corresponding to the accounts of children of the second user, so as to prevent the children from making bad payment under the conditions of being deceived and the like. For another example, the second user may be any user having a preset user relationship with the first user, and when the first user triggers the service request under the condition of misoperation, the second user may timely know the misoperation condition, so that the misoperation service corresponding to the user account of the first user may be prevented.
Method embodiment one
Referring to fig. 1, a flowchart illustrating steps of a first embodiment of a service processing method according to the present application is shown, which may specifically include the following steps:
step 101, receiving a service request of a first user;
step 102, sending a verification request corresponding to the service request to a second client of a second user; wherein the second user may have a preset user relationship with the first user;
step 103, receiving the verification result of the second client to the verification request;
and step 104, terminating the processing of the service request when the verification result accords with a preset rule.
The service processing method provided by the embodiment of the application can be applied to application environments corresponding to the client and the server. The client and the server can be located in a wired or wireless network, and the client and the server perform data interaction through the wired or wireless network.
The client can run on the intelligent terminal and can be applied to the environments of the Web APP (APPlication program), Hybrid APP (Hybrid) APP, Native APP (Native) APP and the like of the intelligent terminal. The intelligent terminal specifically includes but is not limited to: smart phones, tablet computers, electronic book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptop portable computers, car-mounted computers, desktop computers, set-top boxes, smart televisions, wearable devices, and the like.
Specifically, the client may receive a service request input by a user, where the service request may carry information such as service information and user information. For convenience of distinction, in the embodiment of the present application, the first client, the second client, and the third client are respectively used to represent clients corresponding to the first user, the second user, and the third user, and actually, the embodiment of the present application does not limit specific clients.
In an alternative embodiment of the present application, the client may process the service request by performing the above steps 101 and 102.
In another alternative embodiment of the present application, the client may send the service request to the server, so that the server processes the service request by performing the step 101 and the step 102. Because the operation work required by processing the service request is executed in the server, the operation amount of the client can be reduced, namely, the resource consumption of the client can be greatly reduced, so that the operation time and the operation efficiency of the client can be improved, and the practicability of the client can be improved; in addition, the advantage of abundant server-side computing resources (cloud resources in the cloud server) can be exerted, so that the processing efficiency and the processing accuracy of the service request can be improved.
It can be understood that the application environments corresponding to the client and the server are only used as an application example, and an object of the service processing method according to the embodiment of the present application is to perform the function of effectively controlling the risk of the service request by the second user by verifying the service request by the second user, so that the security of service processing can be improved without limiting a specific application environment.
In this embodiment of the application, the second user and the first user corresponding to the service request may have a preset user relationship, where the preset user relationship specifically may include: a friendship, a colleague relationship, a guardian relationship, a relationship of relatives, etc., so the second user has the ability to effectively control the risk of the service request. Wherein, the effective control may specifically include: blocking the processing of the service request, or allowing the processing of the service request, etc.
The service in the embodiment of the present application may include: the embodiments of the present application specifically take the payment service as an example for description, and other services may refer to each other.
In this embodiment, the second user may be a preset user for verifying the service request of the first user. In practical applications, the setting of the second user may be performed through a setting request. The setting request can be triggered by the first user or the second user.
Referring to fig. 2, a flowchart illustrating steps of a method for setting a second user according to the present application is shown, which may specifically include the following steps:
step 201, a first client sends a setting request to a server; the setting request carries first user information, second user information and corresponding verification information;
in an application example of the present application, a user D may log in a first client through a user account D in the intelligent terminal 1, open a second user setting interface of the first client, input a user account and authentication rule information of a second user in the second user setting interface, for example, a user account B of a user B, and trigger a confirmation control.
Step 202, after receiving the setting request, the server sends the setting request to a second client corresponding to a second user according to second user information carried in the setting request;
the server may determine, according to the second user information, that the setting request corresponds to a user account of the second user, and send the setting request to the user account of the second user.
Step 203, after receiving the setting request from the server, the second client obtains a first confirmation message aiming at the setting request through a second user, and returns the first confirmation message or a first rejection message to the server;
in an application example of the present application, the user B may log in a second client through the user account B in the smart terminal 2, and receive a setting request from the user account B in the second client, and then the user B may determine to confirm the setting request or episode the setting request on the basis of communicating with the user D, and accordingly, may return a first confirmation message or a first rejection message to the server through the second client.
Step 204, after receiving the first confirmation message, the server establishes a mapping relationship between the verification information and the second user information, or a mapping relationship between the first user information and the second user information.
In an optional embodiment of the present application, the server may further send the first acknowledgement message or the first rejection message to the first client. For example, after the first client that the user D logs in receives the first confirmation message or the first rejection message, the process of setting the second user is ended.
It should be noted that the first client and the second client may correspond to APPs used for implementing service functions, such as a payment APP, and the embodiments of the present application do not limit the APPs corresponding to the first client and the second client.
It should be noted that the authentication information carried by the setting request may be related to the service authenticated by the second user.
In an optional embodiment of the present application, the verification information carried in the setting request may specifically include: authentication information of all services, or authentication information of a part of services.
When the verification information includes verification information of all services, the server may establish a mapping relationship between the first user information and the second user information after receiving the first confirmation message. For example, in a case where all services of the user D are verified by the user B, the user D may be regarded as a first user, and a mapping relationship between the user D and the user B is established. The above situation may be applicable to a situation where the confidence level of the user D for the user B is high, for example, the user B is a guardian of the user D, or the user B is a relative of the user D.
In the case where the authentication information includes authentication information of a part of the services, the authentication information may include an authentication rule. The above situation does not limit the trust level of the user D to the user B, where the user B may be a guardian, a relative, a friend, or the like of the user D.
In this embodiment of the present application, the verification rule may be used to restrict the service verified by the second user. In an optional embodiment of the present application, the validation rule may specifically include: and one or more types of rules corresponding to the service information. That is, the verification rule may relate to one or more service information, where when the service information relates to multiple service information, the multiple service information may be combined according to a preset syntax rule to obtain a corresponding verification rule, where the preset syntax rule may be a regular rule, a logical operation rule, or the like, and the specific verification rule is not limited in the embodiment of the present application.
In an optional embodiment of the present application, the service information may specifically include at least one of the following information: the service corresponding parameters, the service object, the service source, the service occurrence time, the service occurrence place and the service occurrence times in a preset time period;
the validation rule may specifically include at least one of the following rules:
the corresponding parameters of the service are within the preset limit range;
the service object is in the range of the preset object;
the service source is within a preset source range;
the service occurrence time is within a preset time range;
the service occurrence place is within the range of the preset place; and
the number of times of service occurrence in the preset time period is within the preset number range.
The period of the preset time period may be one day, one week, etc.
Taking a payment scenario as an example, the service corresponding parameter may specifically include a payment amount, for example: single payment amount, or payment amount in a preset time period, and the like; the business object may specifically include a payment object, and the business source may specifically include a payment source, for example: bank card, balance value-added service, etc.; the service occurrence time may specifically include a payment time, and the service occurrence location may specifically include a payment location. The validation rule may specifically include at least one of the following rules:
the payment amount is within the preset amount range;
the payment object is within the range of the preset object;
the payment source is within a preset source range;
the payment time is within a preset payment time range;
the payment place is within the range of the preset payment place; and
the number of payments within the preset time period is within a preset number range.
In an optional embodiment of the present application, in a case that the verification information includes a verification rule, after receiving the first confirmation message, the server may establish a mapping relationship between the verification rule and the second user information for the first user. In another optional embodiment of the present application, in a case that the verification information includes a verification rule, after receiving the first confirmation message, the server may further establish a mapping relationship between the first user information, the verification rule, and the second user information.
Referring to fig. 3, a flowchart illustrating steps of a method for establishing a mapping relationship between a validation rule and second user information according to the present application is shown, and specifically, the method may include:
step 301, receiving a setting request; the setting request carries first user information, second user information and corresponding verification rules;
step 302, sending the setting request to a second client corresponding to a second user according to the second user information;
step 303, receiving a first confirmation message for the setting request, which is returned by the second client;
step 304, after receiving the first confirmation message, establishing a mapping relationship between the validation rule and the second user information, or a mapping relationship between the first user information and the second user information.
The process shown in fig. 3 may be executed by a first client or a server, and a second user may be used to represent a second user set by the first user, such as the aforementioned user B.
Referring to table 1, an example of a mapping relationship between a validation rule and a second user of the present application is shown. One second user may correspond to one or more validation rules, for example, the second user C may correspond to one validation rule, and the second users a and B may correspond to a plurality of validation rules. Also, the validation rules may be associated with the current service request or with the service request within a preset time period (e.g., one day).
TABLE 1
It should be noted that, the establishment of the mapping relationship between the first user and the second user by the server, the establishment of the mapping relationship between the validation rule and the second user by the server, or the establishment of the mapping relationship between the first user and the validation rule and the second user by the server is only an optional embodiment of the present application, and has an advantage of preventing the mapping relationship from being tampered by the user, so that the security of the service processing can be improved. In other embodiments of the present application, the first client and/or the second client may also establish a mapping relationship between the first user and the second user, establish a mapping relationship between the validation rule and the second user, or establish a mapping relationship between the first user and the validation rule and the second user, and may also encrypt the mapping relationship data at the first client and/or the second client for the purpose of improving security.
In addition, it should be noted that the process of forwarding the setting request and the first confirmation message through the server in fig. 2 is only an optional embodiment, and actually, the first client and the second client may communicate directly, and may communicate with each other through a communication platform provided by a service APP, an instant communication platform provided by another APP, or a short message platform, and the like.
In addition, it should be noted that the process of the first user triggering the setting request through the first client in fig. 2 is only an example, and actually, the second user may also trigger the setting request through the second client.
The embodiment of the application can provide the following technical scheme for determining the second user:
technical solution 1
In technical solution 1, the second user may be determined by the following steps:
step A1, determining the second user according to the verification rule corresponding to the first user.
In practical application, the service request may carry first user information (e.g., user account information of the first user), so that the verification rule corresponding to the first user may be determined according to the first user information, and then the second user may be determined according to the verification rule. The verification rule corresponding to the first user may be determined according to a mapping relationship between the first user and the verification rule, or the corresponding verification rule may be directly read from the pre-stored content corresponding to the first user.
In an optional embodiment of the present application, the step a1 may specifically include: and when the service information carried in the service request and/or the service information carried in the service request in a preset time period conforms to the verification rule corresponding to the first user, obtaining second user information corresponding to the verification rule according to a mapping relation between the pre-established verification rule and the second user information, and using the second user information as the information of the second user.
In practical application, the service information carried in the service request may be matched with a validation rule similar to the mapping relationship shown in table 1, and if the matching is successful, the service information corresponding to the service request may be considered to conform to the validation rule. For example, if the payment amount corresponding to the service request is 20000, the service request may be considered to conform to the verification rule that "the primary payment amount is greater than 10000", so as to obtain the information of the second user a. For another example, assuming that the payment source corresponding to the service request is a balance, the service request may be considered to conform to a verification rule of "payment by balance", so that the information of the second user C may be obtained. It can be seen that the second user may be one or more.
Similarly, the service information carried in the service request in the preset time period may be matched with the validation rule in the mapping relationship shown in table 1, and if the matching is successful, the service information carried in the service request in the preset time period may be considered to conform to the validation rule. For example, if the number of service requests in a day is 5 and the payment amount involved in each service request is not 20000, the service request in a day may be considered to conform to the verification rule of "the payment amount in a day is 100000 or more", and the information of the second user B may be obtained. For another example, assuming that the number of service requests in a day is 10, the service requests in a day may be considered to conform to the verification rule of "transaction number in a day is greater than or equal to 10", so that the information of the second user a may be obtained.
Technical solution 2
In technical solution 2, the second user may be determined by the following steps:
step B1, according to the first user information and the service information carried by the service request, searching in the mapping relation among the first user information, the verification rule and the second user information to obtain the information of the second user.
In practical application, the first user information and the service information carried by the service request may be respectively matched with the first user information and the verification rule in the mapping relationship among the first user information, the verification rule and the second user information, and when the matching between the first user information and the verification rule is successful, the corresponding second user information is obtained.
Technical solution 3
In technical solution 3, the second user may be determined by the following steps:
and step C1, searching the mapping relation between the first user information and the second user information according to the first user information carried by the service request to obtain the information of the second user.
Technical scheme 3 may be applicable to a situation where the second user is used to verify all services, for example, when all services of user D are verified by user B, the mapping relationship between user D and user B may be established in advance, and when the first user information is the information of user D, the second user is obtained by searching.
The technical solution for determining the second user is described in detail through technical solutions 1 to 3, and it can be understood that a person skilled in the art may adopt any one or a combination of the above technical solutions 1 to 3 or may also adopt other technical solutions for determining the second user according to practical application requirements, and the embodiment of the present application does not limit the specific technical solution for determining the second user.
In an optional embodiment of the present application, the verification result obtained in step 103 may specifically include: either blocked or allowed. And when the verification result meets the preset rule, the step 104 may terminate the processing of the service request, so that an illegal service or bad payment corresponding to the user account of the first user may be prevented.
It should be noted that the number of the second users may be one or more, and when there are a plurality of second users, the corresponding verification results of the plurality of second users may be different, in this case, the service request may be blocked or released by using a corresponding preset rule according to an actual application requirement. For example, one preset rule may be that at least one verification result includes a block, i.e. the processing of the service request may be blocked once the blocked verification result occurs. As another example, a preset rule may be that the number of blocks is greater than a first threshold. As another example, a preset rule may be that the ratio of the number of blocks to the number of rejections is greater than a second threshold. Wherein the second threshold may be a value greater than 1, and the like.
It is to be appreciated that in an alternative embodiment of the present application, the processing of the service request may be continued when the verification result does not comply with preset rules. For example, when there is one second user and the verification result corresponding to the second user is allowable, the processing of the service request may be continued.
To sum up, in the processing flow of the service request, the embodiment of the present application executes the verification operation by a second user other than the first user; since the second user is usually a user having a preset user relationship with the first user, the second user has an ability to effectively control the risk of the service request, so that the embodiment of the present application can effectively prevent the execution of the abnormal service, thereby improving the security of the service processing.
Method embodiment two
Referring to fig. 4, a flowchart illustrating steps of a second embodiment of the service processing method in the present application is shown, which may specifically include the following steps:
step 401, a server receives a service request of a first user;
step 402, the server sends a verification request corresponding to the service request to a second client of a second user; wherein the second user may have a preset user relationship with the first user;
step 403, the server receives the verification result of the second client to the verification request;
step 404, the server terminates the processing of the service request when the verification result conforms to a preset rule;
step 405, the server sends a termination message to the first client of the first user; the termination message is used to indicate the termination of the service request.
With respect to the first method embodiment shown in fig. 1, the process in fig. 4 may be applied to a server, where a termination message sent by the server to the first client may be used to indicate termination of the service request, so that the first user knows the status of the service request.
In an optional embodiment of the present application, when the verification result does not meet a preset rule, the server may continue to process the service request, and send a corresponding processing result to the first client of the first user.
Method embodiment three
Referring to fig. 5, a flowchart illustrating steps of a third embodiment of a service processing method according to the present application is shown, which may specifically include the following steps:
step 501, a first client sends a service request of a first user to a server;
step 502, the server sends a verification request corresponding to the service request to a second client of a second user; wherein the second user may have a preset user relationship with the first user;
step 503, the second client receives a verification request corresponding to the service request of the first user, which is sent by the server;
step 504, the second client verifies the verification request through the second user to obtain a corresponding verification result;
step 505, the second client sends the verification result to the server;
step 506, the server receives the verification result of the second client to the verification request, and terminates the processing of the service request when the verification result conforms to a preset rule.
It should be noted that the service request may carry information such as service information, and the verification request may carry the service information and the first user information, and in this case, the verification request and the service request may carry different information. Or, the service request may carry information such as service information and first user information, and in this case, the authentication request may carry the same information. It can be understood that, in the embodiment of the present application, no limitation is imposed on the specific information carried by the service request and the authentication request.
For a person skilled in the art to better understand the embodiment of the present application, referring to fig. 6, a schematic structural diagram of a payment transaction processing system of the present application is shown, which may specifically include: the server 601, the first client 602, and the second client 603, accordingly, a flowchart of steps of an example of a payment service processing method according to the present application is provided herein, which may specifically include the following steps:
step S1, the first client 602 receives the payment service request initiated by the user account D, and sends the payment service request to the server 601;
step S2, the server 601 determines whether the payment service request needs to be verified, if yes, step S3 is executed, otherwise, the payment service request is processed according to the conventional flow;
in an optional embodiment of the present application, the process of the server determining whether the payment service request needs to be verified may specifically include: and matching the service information carried in the payment service request and/or the service information carried in the payment service request in a preset time period with the verification rule of the user account D, and if the matching is successful, determining that the payment service request needs to be verified. Or, the process of the server determining whether the payment service request needs to be verified may specifically include: and matching the first user information carried in the payment service request with the first user information in the mapping relation between the first user information and the second user information, and if the matching is successful, determining that the payment service request needs to be verified. It can be understood that the specific determination process of whether the payment service request needs to be verified is not limited in the embodiment of the present application.
Step S3, the server 601 determines the second user B who pays;
step S4, the server 601 sends a verification request to the second client 603 of the second user B corresponding to the user account B;
step S5, the second client 603 receives the verification request and receives the verification result input from the user account B;
in practical applications, after receiving the verification request in the payment application, the user B may determine the verification result corresponding to the verification request through communication with the user D (in-plane communication, communication based on instant messaging, etc.), and input the verification result in the payment application.
Step S6, the second client 603 sends the verification result to the server 601;
step S7, when the verification result conforms to the preset rule, the server 601 terminates the processing of the payment service request.
For example, if the verification result of the user B is allowed, the payment service request of the user D is processed according to the conventional flow until the end. If the authentication of user B is blocked, the payment service request of user D is terminated.
In step S8, the server 601 sends termination information to the first client 602 corresponding to the user account D, so that the user D receives operation result information in the payment application.
Method embodiment three
The present embodiment is an optional embodiment of the first method embodiment or the second method embodiment, and may further include the following optional technical solutions on the basis of the first method embodiment or the second method embodiment.
In this embodiment, in order to prevent an illegal user from setting a second user by himself after stealing a user account or prevent a minor from setting the second user by himself under the deceased condition, the embodiment of the present application may further reject a setting request from the first user in the following manner, and accordingly, the embodiment of the present application may provide the following manner of rejecting the setting request:
mode 1
In the method 1, after receiving the setting request, the current state of the user account corresponding to the first user information may be determined, and when the current state is a preset state, the setting request is rejected.
Mode 1 may determine whether to deny the setup request depending on whether the current status of the user account is a preset status. Since the preset state can be used for indicating the state that the user account is not controlled by a legal user, the setting request under the condition is rejected, and the safety of service verification can be improved.
For example, the initial state of the user account D may be a normal state, and after the smart terminal of the user account D is lost or the login password or the payment password is stolen, a loss report request may be sent to the server, and the server may set the current state of the user account D to a loss report state, which may be a preset state. For another example, the user account C is a minor, and the status thereof may specifically include: a control state and a non-control state; for example, in the daytime, the state of the user account C may be the non-control state because the parent is not nearby, and in the night time, the state of the user account C may be the control state because the parent is nearby. In addition, the current state of the user account C may be determined according to the trigger of the parent corresponding to the user account, and the specific determination manner of the current state of the user account is not limited in the embodiment of the present application.
Mode 2,
In mode 2, the embodiment of the present application may further include the following steps:
step D1, receiving a setting request; the setting request carries first user information, second user information and corresponding verification rules;
step D2, sending the setting request to a second client corresponding to a second user according to the second user information;
step D3, rejecting the setting request according to the first reject message for the setting request returned by the second client.
Because the second user can timely know the condition that the user account of the first user is stolen, the second user can reject the setting request of the first user after determining that the user account of the first user is stolen, so that the first user is prevented from maliciously setting the second user through the setting request.
Mode 3,
In mode 3, the embodiment of the present application may further include the following steps:
step E1, receiving a setting request; the setting request carries first user information, second user information and corresponding verification rules;
step E2, determining a third user corresponding to the verification rule of which the verification range exceeds the verification range corresponding to the verification rule;
step E3, sending the setting request to a third client of a third user;
step E4, receiving a third reject message for the setting request returned by the third client;
step E5, rejecting the setting request according to the third reject message.
In this embodiment of the application, the verification rule usually has a corresponding verification range, and the verification range may include the preset quota range, the preset object range, and the like, in the manner 3, the third user is a user that has been successfully set for verification, and when the setting request corresponds to the verification range that is less than or equal to the verification range of the third user, the verification of the third user needs to be passed.
Taking table 1 as an example, if the second user corresponding to the original verification rule "the primary payment amount is greater than 10000" is the user a, the embodiment of the present application does not allow the first user to unilaterally narrow the verification range, for example, if the first user wants to add a new verification rule "the primary payment amount is greater than 20000", the new addition needs to be validated by the authenticator of the user a because the new verification rule is in the verification range corresponding to the original verification rule.
It should be noted that, with respect to the mode 1, when the current state is not the preset state, the setting request may be allowed. With regard to the mode 3, after receiving a third confirmation message for the setting request returned by the third client, the setting request may be allowed. The embodiment of the application does not limit the allowed time corresponding to the setting request.
Method example four
The present embodiment is an optional embodiment of the first method embodiment or the second method embodiment or the third method embodiment, and on the basis of the first method embodiment or the second method embodiment or the third method embodiment, the following optional technical solutions may also be included.
In this embodiment, the first user is not allowed to cancel the verification or narrow the verification range in a single way, so that even if the first user is stolen, the original second user can still effectively verify the service request, and thus the normalization of the service verification can be improved.
Taking table 1 as an example, if the second user corresponding to the verification rule "the primary payment amount is greater than 10000" is the user a, the embodiment of the present application does not allow the first user to cancel the verification rule unilaterally, and the cancellation of the verification rule needs to be valid by the validation party of the user a. In addition, the embodiment of the present application does not allow the first user to unilaterally narrow the verification range, for example, if the first user modifies the verification rule that "the primary payment amount is greater than 10000" to "the primary payment amount is greater than 20000", since the modified verification rule is within the verification range corresponding to the original verification rule, the modification of the verification rule needs to be validated by the authenticator of the user a.
In this embodiment of the application, the control process of the cancel request or the change request may specifically include:
step F1, receiving a cancel request or a change request; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
in practical applications, the first client may send a cancel request or a change request to the server.
Step F2, sending the cancel request or change request to a second client corresponding to a second user according to the second user information;
step F3, receiving a second confirmation message for the cancel request or the change request returned by the second client;
in practical application, the second client may obtain, by the second user, a second cancel message for the cancel request or the change request; sending the second cancellation message to the server. The second cancellation message of the second user for the cancellation request or the change request may be acquired in the form of a keyboard, a voice, a mouse, or the like.
Step F4, after receiving the second confirmation message, deleting the mapping relationship between the corresponding verification rule and the second user information, or the mapping relationship between the first user information and the second user information, or the mapping relationship between the first user, the verification rule, and the second user.
In an optional embodiment of the present application, the control process of canceling the request or changing the request may further include:
step F5, receiving a second reject message for the cancel request or the change request returned by the second client;
step F6, after receiving the second reject message, maintaining the mapping relationship between the corresponding verification rule and the second user information, or the mapping relationship between the first user information and the second user information, or the mapping relationship between the first user, the verification rule, and the second user.
Examples of applications in the control process of canceling a request are provided herein. In the application example, a user account D initiates a cancellation request for an authentication rule 1 in a payment application, and if a second user corresponding to the authentication rule 1 is a user account B, a first client corresponding to the user account D may send the cancellation request and information of the corresponding user account B to a server; the server may send the cancellation request to the user account B; after receiving the cancellation request from the user account a in the payment application, the user B may agree to cancel or refuse to cancel on the basis of communicating with the user a, and the user account B may send a corresponding second confirmation message or a second rejection message to the server. The server may delete the mapping relationship between the corresponding authentication rule and the second user information after receiving the second confirmation message, and maintain the mapping relationship between the corresponding authentication rule and the second user information after receiving the second rejection message. And the server can also send a corresponding operation result message to the first client corresponding to the user account D.
Examples of applications in the control of change requests are provided herein. In the application example, a user account D initiates a change request for an authentication rule 1 in payment application, and after the change, an authentication range of an authentication rule 2 is smaller than an authentication range of the authentication rule 1 (for example, a payment limit is increased on the basis of the authentication rule 1), assuming that a second user corresponding to the authentication rule 1 is a user account B, a first client corresponding to the user account D may send the change request and information of the corresponding user account B to a server; the server can send the change request to the user account B; after receiving the change request from the user account a in the payment application, the user B may agree to the change or reject the change on the basis of communicating with the user a, and the user account B may send a corresponding second confirmation message or a second rejection message to the server. The server may delete the mapping relationship between the corresponding authentication rule and the second user information after receiving the second confirmation message, and maintain the mapping relationship between the corresponding authentication rule and the second user information after receiving the second rejection message. And the server can also send a corresponding operation result message to the first client corresponding to the user account D.
It should be noted that, for simplicity of description, the method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the embodiments are not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the embodiments. Further, those skilled in the art will also appreciate that the embodiments described in the specification are presently preferred and that no particular act is required of the embodiments of the application.
Apparatus embodiment one
Referring to fig. 7, a block diagram of a first embodiment of a service processing apparatus according to the present application is shown, where the apparatus may be applied to a server side, and specifically includes the following modules:
a first receiving module 701, configured to receive a service request of a first user;
a first sending module 702, configured to send a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user;
a second receiving module 703, configured to receive a verification result of the second client for the verification request; and
a terminating module 704, configured to terminate processing of the service request when the verification result meets a preset rule.
In an optional embodiment of the present application, the apparatus may further include: a determining module for determining the second user;
the determining module may specifically include:
the first determining submodule determines the second user according to a verification rule corresponding to the first user; or
The second determining submodule searches a mapping relation among the first user information, the verification rule and the second user information according to the first user information and the service information carried by the service request so as to obtain the information of the second user; or
And the third determining submodule searches a mapping relation between the first user information and the second user information according to the first user information carried by the service request so as to obtain the information of the second user.
In another optional embodiment of the present application, the first determining sub-module may specifically include:
and the searching unit is used for obtaining second user information corresponding to the verification rule according to a mapping relation between the pre-established verification rule and the second user information when the service information carried in the service request and/or the service information carried in the service request in a preset time period conforms to the verification rule, and the second user information is used as the information of the second user.
In yet another optional embodiment of the present application, the apparatus may further include:
a second sending module, configured to send a termination message to a first client of the first user; the termination message is used to indicate the termination of the service request.
In yet another optional embodiment of the present application, the apparatus may further include:
a third receiving module, configured to receive a setting request; the setting request carries first user information, second user information and corresponding verification rules;
a third sending module, configured to send the setting request to a second client corresponding to a second user according to the second user information;
a fourth receiving module, configured to receive a first acknowledgement message, which is returned by the second client and is in response to the setting request;
and the establishing module is used for establishing a mapping relation between the verification rule and the second user information, or a mapping relation between the first user information and the second user information, or a mapping relation between the first user, the verification rule and the second user after receiving the first confirmation message.
In an optional embodiment of the present application, the apparatus may further include:
the first rejection module is used for determining the current state of a user account corresponding to the first user information, and rejecting the setting request when the current state is a preset state; or
The second rejection module is used for rejecting the setting request according to a first rejection message which is returned by the second client and aims at the setting request; or
And the second rejection module is used for determining a third user corresponding to the verification rule of which the verification range exceeds the verification range corresponding to the verification rule, sending the setting request to a third client of the third user, receiving a third rejection message which is returned by the third client and aims at the setting request, and rejecting the setting request according to the third rejection message.
In another optional embodiment of the present application, the apparatus may further include:
a fifth receiving module, configured to receive a cancel request or a change request; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
a fourth sending module, configured to send the cancel request or the change request to a second client corresponding to a second user according to the second user information;
a sixth receiving module, configured to receive a second acknowledgement message, which is returned by the second client and is addressed to the cancel request or the change request;
and the deleting module is used for deleting the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user after receiving the second confirmation message.
In yet another optional embodiment of the present application, the apparatus may further include:
a seventh receiving module, configured to receive a second reject message, which is returned by the second client and is addressed to the cancel request or the change request;
and the maintaining module is used for maintaining the mapping relation between the corresponding verification rule and the second user information, or the mapping relation between the first user information and the second user information, or the mapping relation between the first user, the verification rule and the second user after receiving the second rejection message.
Device embodiment II
Referring to fig. 8, a block diagram of a second embodiment of a service processing apparatus according to the present application is shown, where the apparatus may be applied to a second user side corresponding to a second user, and specifically may include the following modules:
a first receiving module 801, configured to receive a verification request sent by a server and corresponding to a service request of a first user;
the verification module 802 is configured to verify the verification request by the second user to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user; and
a first sending module 803, configured to send the verification result to the server.
In an optional embodiment of the present application, the apparatus may further include:
the second receiving module is used for receiving a setting request sent by the server; the setting request carries first user information, second user information and corresponding verification rules;
a first obtaining module, configured to obtain, by a second user, a first confirmation message for the setting request;
and the second sending module is used for sending the first confirmation message to the server.
In another optional embodiment of the present application, the apparatus may further include:
the second obtaining module is used for obtaining a first refusal message aiming at the setting request through a second user;
a third sending module, configured to send the first reject message to the server.
In yet another optional embodiment of the present application, the apparatus may further include:
the third receiving module is used for receiving a cancel request or a change request sent by the server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules;
a third obtaining module, configured to obtain, by a second user, a second confirmation message for the cancel request or the change request;
a fourth sending module, configured to send the second acknowledgement message to the server.
In yet another optional embodiment of the present application, the apparatus may further include:
a fourth obtaining module, configured to obtain, by a second user, a second cancel message for the cancel request or the change request;
a fifth sending module, configured to send the second cancellation message to the server.
Device embodiment III
The present application further provides a third embodiment of a service processing apparatus, where the apparatus may be applied to a first client side corresponding to a first user, and specifically may include the following modules:
the first sending module is used for sending a service request of a first user to a server so that the server sends a verification request corresponding to the service request to a second client of a second user and the second user verifies the verification request to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user.
In another optional embodiment of the present application, the apparatus may further include:
a receiving module, configured to receive a termination message returned by the server for the service request; the termination message is used to indicate the termination of the service request.
In yet another optional embodiment of the present application, the apparatus may further include:
the second sending module is used for sending a setting request to the server; the setting request carries first user information, second user information and corresponding verification rules.
In yet another optional embodiment of the present application, the apparatus may further include:
the third sending module is used for sending a cancel request or a change request to the server; the cancellation request or the change request carries first user information, second user information and corresponding verification rules.
For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.
The present application further provides an embodiment of a service processing system, where the system may specifically include: the system comprises a server, a first client and a second client;
the server may specifically include:
the first receiving module is used for receiving a service request of a first user;
the first sending module is used for sending a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user;
a second receiving module, configured to receive a verification result of the second client on the verification request; and
the termination module is used for terminating the processing of the service request when the verification result accords with a preset rule;
the second client may specifically include:
the third receiving module is used for receiving a verification request which is sent by the server and corresponds to the service request of the first user;
the verification module is used for verifying the verification request through a second user to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user; and
the second sending module is used for sending the verification result to the server;
the first client specifically may include:
a third sending module, configured to send a service request of a first user to a server, so that the server sends a verification request corresponding to the service request to a second client of a second user, and the second user verifies the verification request to obtain a corresponding verification result; wherein the second user has a preset user relationship with the first user.
Intelligent terminal embodiment
Referring to fig. 9, a structural block diagram of an embodiment of an intelligent terminal according to the present application is shown, which may specifically include: at least one memory 901, a display 902, at least one processor 903, and at least one input unit 904.
The input unit 904 may be used to receive numeric or character information input by a user and a control signal. Specifically, in this embodiment, the input unit 904 may include a touch screen 941, which can collect touch operations of a user (for example, operations of the user on the touch screen 941 by using a finger, a stylus pen, or any other suitable object or attachment) thereon or nearby and drive a corresponding connection device according to a preset program. Of course, the input unit 904 may include other input devices such as a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a mouse, etc., in addition to the touch screen 941.
The Display 902 may specifically include a Display panel, and optionally, the Display panel may be configured in the form of a Liquid Crystal Display (LCD) or an Organic Light-Emitting Diode (OLED). The touch screen 941 may cover the display panel to form a touch display screen, and when the touch display screen detects a touch operation on or near the touch display screen, the touch display screen transmits the touch operation to the processor 903 to perform corresponding processing.
In the embodiment of the present application, the processor 903 receives a service request of the first user by calling a program, and/or a module, and/or data stored in the memory 901; sending a verification request corresponding to the service request to a second client of a second user; wherein the second user has a preset user relationship with the first user; receiving the verification result of the second client to the verification request; and when the verification result accords with a preset rule, terminating the processing of the service request.
The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
As will be appreciated by one of skill in the art, embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
In a typical configuration, the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium. Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (fransitory media), such as modulated data signals and carrier waves.
Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present application have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the true scope of the embodiments of the application.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.
The service processing method, the service processing device and the intelligent terminal provided by the application are introduced in detail, and a specific example is applied in the text to explain the principle and the implementation of the application, and the description of the embodiment is only used for helping to understand the method and the core idea of the application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.