Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without inventive effort for a person skilled in the art. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.
As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.
Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.
The inventor researches and analyzes the data, and finds that, although the common blockchain payment technology can ensure traceability and non-falsification of online transactions, leakage of payment business data in the payment business process is a problem to be considered at present for users. For example, in the processing process of the blockchain payment service, in order to uniformly manage the payment service data of both transaction parties, both transaction parties usually upload the payment service data to the cloud for backup. However, the payment service data of the users may be leaked, that is, the third party directly analyzes the payment service data without authorization of both parties of the transaction so as to realize user portrait analysis, and then pushes related service products.
For example, after a transaction party A and a transaction party B perform block chain payment service processing, payment service data Da of the transaction party A stored in the cloud end are directly called by a third-party platform C, and then the third-party platform C performs user portrait analysis according to the payment service data Da, so that a service product is pushed to the transaction party A, the privacy of the transaction party A is violated, and the transaction party A can frequently receive product pushing messages.
Therefore, in order to improve the above problems, it is necessary to analyze the data call request of the payment service data, so as to avoid leakage and theft of the payment service data caused by responding to an unauthorized data call request.
First, an exemplary big data and blockchain finance-based payment data processing method is described, referring to fig. 1, which is a flowchart illustrating an exemplary big data and blockchain finance-based payment data processing method and/or process according to some embodiments of the present invention, and the big data and blockchain finance-based payment data processing method may include the technical solutions described in the following steps S1 to S4.
Step S1, obtaining target payment service data containing the undetermined payment behavior label, and performing service event identification processing on the target payment service data to obtain payment service event content corresponding to the target payment service data.
For example, the pending payment behavior tag is used to represent whether the target payment business data corresponds to an abnormal behavior, the target payment business data may be data generated by the blockchain device during the payment business and uploaded to the cloud server, the business event identification process may be understood as performing identification of the payment business event, and accordingly, the content of the payment business event may include different types of payment business events, such as a transfer business event, a shopping business event, a payment business event, and the like, which is not limited herein. Further, the to-be-determined payment behavior tag may be used to distinguish different payment service data, where the different payment service data may be payment service data of different time periods corresponding to the same blockchain device, or payment service data of the same time period corresponding to different blockchain devices, and is not limited herein.
Step S2, obtaining a target data tracking policy corresponding to the target payment business data, extracting a first data usage intention and a second data usage intention from the payment business event content through the target data tracking policy, and integrating the first data usage intention and the second data usage intention to obtain a global usage intention of the business event content associated with the target payment business data.
For example, the target data tracking policy may be used to track and analyze the usage intention of the target payment service data to determine different data usage intents, which may facilitate subsequent analysis of the usage intention to determine the validity of the usage intention and whether the usage intention is authorized by the corresponding blockchain device before the target payment service data is used, thereby preventing the target payment service data from being illegally called and stolen. Further, the first data usage intent and the second data usage intent may represent a real-time usage intent and a delayed usage intent, respectively, while the global usage intent enables integration of different data usage intents to reflect usage intent of business event content associated with the targeted payment business data based on a timing level.
For another example, the real-time usage intention may be a current usage intention for the target payment service data, may be a payment behavior habit analysis performed on the target payment service data to optimize a subsequent payment verification manner (the intention may correspond to the cloud server, and the intention is authorized by the corresponding blockchain device), and may also be a user portrait analysis performed on the target payment service data to obtain interest preference information of the user (the intention may correspond to a third-party platform, and in general, such intention is not authorized by the corresponding blockchain device). For another example, the delayed usage intention may be a potential analysis requirement for the target payment transaction data, may be a continuous analysis intention for a payment period distribution of the target payment transaction data, and the like, and is not limited herein.
Step S3, according to the global usage intention of the business event content and the target data tracking strategy, data theft behavior recognition is carried out on the payment business event content, and a data theft behavior recognition result corresponding to the payment business event content is obtained.
For example, data misappropriation behavior may be understood as abnormal behavior of privately invoking relevant content of payment business event content for user portrait analysis without authorization of a corresponding blockchain device. Due to the fact that authorization of the blockchain device is not performed, problems of data leakage or data tampering and the like may occur in the calling process of the payment service data, and subsequent data safety hazards may be caused.
Step S4, if the data theft behavior recognition result indicates that the payment service event content meeting the data theft determination index exists in the target payment service data, determining the pending payment behavior tag as an abnormal behavior tag, and intercepting a data call request for instructing to transmit the target payment service data to a target service end device having a tracking path corresponding relationship with the target data tracking policy.
For example, the data theft determination index may be obtained from historical payment service data, and this will be described later and will not be further described here. The abnormal behavior tag is used for representing that the target payment service data is stolen by a third-party platform with high possibility, and under the condition, a data call request related to the target payment service data needs to be verified and analyzed, so that an illegal data call request is identified, and leakage and theft of the target payment service data caused by response to an unauthorized data call request are avoided.
For another example, the trace path correspondence relationship may be used to represent that there is a data trace path or data flow direction information corresponding to an abnormal data usage behavior, and the target service end device may be understood as an intelligent device corresponding to a third-party platform, and it may be understood that, if a certain data call request Q and a target data trace policy have a trace path correspondence relationship, the data call request Q may be considered as an abnormal call request, that is, the target service end device corresponding to the data call request Q may call the target payment service data for user portrait analysis without permission of the corresponding block chain device.
Thus, based on the contents described in the above steps S1-S4, the payment transaction event content can be obtained by performing transaction event identification processing on the target payment transaction data, and different data usage intents can be extracted from the payment transaction event content according to the obtained target data tracking policy, so that a global usage intention corresponding to the target payment transaction data can be obtained, and thus, data theft behavior identification of the payment transaction event content can be realized, so that when the payment transaction content satisfying the data theft determination index exists in the target payment transaction data, a data call request for instructing transmission of the target payment transaction data to a target transaction terminal device having a tracking path corresponding relation with the target data tracking policy is intercepted, and a data call request related to the target payment transaction data can be verified and analyzed, the leakage and the theft of payment business data caused by responding to unauthorized data calling requests are avoided.
In the following, some alternative embodiments will be described, which should be understood as examples and not as technical features essential for implementing the present solution.
For some possible embodiments, on the basis of the above contents, the obtaining of the target payment service data including the pending payment behavior tag, and performing service event identification processing on the target payment service data to obtain the payment service event content corresponding to the target payment service data, which are described in step S1, may include the contents described in steps S11 and S14 below.
Step S11, if the service event corresponding to the payer blockchain device corresponds to the first payment service network environment, when the payee blockchain device associated with the payer blockchain device triggers a collection action, collecting target service requirement event information associated with the target service requirement label through the payee blockchain device; the target business requirement event information comprises payment business records corresponding to at least one business requirement label. For example, the payer blockchain device and the payee blockchain device may both be mobile phones, notebook computers, or other intelligent electronic devices, the first payment service network environment may be a data network communication environment or a wifi communication environment, whether to trigger a payment receiving behavior may be obtained by detecting a payment receiving request, and the target service requirement tag may be used to distinguish corresponding service requirements of the blockchain devices at different ends in the payment service.
Step S12, obtaining a payment service record corresponding to the target service requirement label from the payment service record corresponding to the at least one service requirement label of the target service requirement event information, and performing service interaction behavior recognition on the payment service record corresponding to the target service requirement label to obtain a service interaction behavior recognition result. For example, the service interaction behavior may be understood as a back-and-forth interaction behavior between blockchain devices at different ends, such as identity information confirmation between a payer blockchain device and a payee blockchain device, transaction information confirmation (e.g., interaction in a text or voice form), and the like, and is not limited herein.
Step S13, based on the service interaction behavior recognition result, obtaining payment service data corresponding to the service interaction behavior of the target service requirement label from the payment service record corresponding to the target service requirement label, and taking the obtained payment service data as the target payment service data containing the label of the pending payment behavior; the pending payment behavior tag corresponds to a business interaction behavior of the target business requirement tag.
Step S14, acquiring event identification instruction information for performing service event identification processing on the target payment service data, and performing service event identification processing on the target payment service data based on the event identification instruction information to obtain payment service event content corresponding to the target payment service data. For example, the event identification indication information may be used to indicate targeted data analysis for the target payment service data, so as to accurately determine the content of the payment service event from the target payment service data, and reduce interference of noise data.
By implementing the above steps S11-S14, the service requirement analysis and service interaction analysis are performed on the blockchain devices at different ends, so that the target payment service data can be ensured to be highly correlated with the payment behavior of the blockchain devices, and further, the service event identification processing is performed through the event indication identification information, so that the payment service event content can be accurately determined from the target payment service data, and the interference of noise data is reduced.
Further, on the basis of the above step S11, if the service event corresponding to the payer blockchain device corresponds to the first payment service network environment, when the payee blockchain device associated with the payer blockchain device triggers a collection action, collecting target service requirement event information associated with the target service requirement tag through the payee blockchain device, which may further include the contents described in the following steps S111 to S114.
Step S111, responding to the payment service initiation operation aiming at the payer block chain equipment, and accessing a target database corresponding to the payment service data acquisition thread corresponding to the payer block chain equipment. For example, the payment service initiating operation may be a touch operation or a voice operation, the payment service data acquisition thread may be a thread for performing payment service data acquisition in the payer blockchain device, and writing of a thread code belongs to the prior art, which is not described herein further. The target database may be a cloud-based database, such as a mysql database or a hive database.
Step S112, when the service event corresponding to the payer blockchain device corresponds to the first payment service network environment, accessing the payee blockchain device associated with the payer blockchain device.
Step S113, in a payment verification valid period corresponding to the payee blockchain device, collecting at least one payment service record carrying a target service requirement label of the payment service initiation operation through the payee blockchain device, and caching the collected at least one payment service record to a target database corresponding to the payment service data collection thread. For example, the payment verification valid period may be a period configured in advance by the payee blockchain device for performing the secret-free verification, and the payment transaction operation may not be performed multiple times during this period.
Step S114, determining the at least one payment service record cached in the target database corresponding to the payment service data acquisition thread as the target service demand event information associated with the target service demand label.
It can be understood that by implementing the above steps S111-S114, the payment transaction record can be cached in the target database, so as to avoid the related record information in the transaction payment record from being updated by mistake with time, which can ensure that the target transaction requirement event information associated with the target transaction requirement tag conforms to the actual transaction situation.
For some optional embodiments, on the basis of step S13, the obtaining, based on the service interaction behavior recognition result, payment service data corresponding to the service interaction behavior of the target service requirement label from the payment service record corresponding to the target service requirement label, and using the obtained payment service data as the target payment service data including the pending payment behavior label, may further include the following step S131 and step S132.
Step S131, if the service interaction behavior recognition result represents that the payment service record corresponding to the target service requirement label has target usage intention content corresponding to the service interaction behavior data, determining the payment and receipt event content corresponding to the service interaction behavior of the target service requirement label in the payment service record corresponding to the target service requirement label based on the target usage intention content. For example, the target usage intention content may be usage intention content related to identification information or portrait information recognition and confirmation, and the receipt and payment event content may be understood as event content corresponding to the receipt behavior or payment behavior of different block-link node devices.
Step S332, intercepting the content of the payment receiving and paying event from the payment service record corresponding to the target service requirement label, determining a pending payment behavior label in the content of the payment receiving and paying event according to the service interaction behavior of the target service requirement label, and taking the payment service data corresponding to the pending payment behavior label as the target payment service data in the content of the payment receiving and paying event.
In this way, when the technical solutions described in the above steps S331 and S332 are applied, the target use intention content can be analyzed, so as to ensure that the determined target payment service data is related to the identity information and/or portrait information of the user.
In an actual implementation process, in order to facilitate management of information content, event content may be generally split into a plurality of content blocks, and further, the number of content blocks of the payment transaction event content is multiple, on this basis, the target data tracking policy described in step S2 for obtaining the target payment transaction data corresponds to the target payment transaction data, a first data usage intention and a second data usage intention are extracted from the payment transaction event content through the target data tracking policy, and the first data usage intention and the second data usage intention are integrated for usage intention, so as to obtain a global usage intention of the transaction event content associated with the target payment transaction data, which may include the following steps S21 and S24.
Step S21, acquiring a target data tracking strategy corresponding to the target payment service data; the target data tracking policy includes: real-time use intention extraction network and delayed use intention extraction network. For example, the target data tracking strategy may be a neural network model, and the real-time use intention extraction network and the delayed use intention extraction network may be understood as different functional network layers in the neural network model, and training and function debugging on the neural network model are common in the industry, and therefore are not described more herein.
Step S22, extracting a usage intention information segment from each of the payment transaction event contents through the real-time usage intention extraction network, and determining the first data usage intention according to the extracted usage intention information segment of each of the payment transaction event contents. For example, different pieces of usage intention information may characterize different intention requirements, and these intention requirements may be associated with each other or independent of each other, and are not limited herein.
Step S23, extracting the usage intention change information from each of the payment transaction event contents through the delayed usage intention extraction network, and determining the second data usage intention according to the extracted usage intention change information of each of the payment transaction event contents. For example, the usage intent change information may be used to characterize changes that may exist in the content of the corresponding delayed usage intent of each of the payment transaction events.
Step S24, integrating the first data usage intention of each payment transaction event content with the second data usage intention corresponding to the payment transaction event content to obtain a global usage intention of each payment transaction event content, and determining the global usage intention of each payment transaction event content as the global usage intention of the transaction event content associated with the target payment transaction data.
In this way, by implementing the above steps S21-S24, it is possible to extract different types of data usage intents based on the real-time usage intention extraction network and the delayed usage intention extraction network in the target data tracking policy, so as to ensure that the global usage intention of the business event content associated with the target payment business data can take the usage intents of different periods into account, and provide reliable decision basis for the subsequent data theft behavior identification.
For some possible embodiments, the data flow direction is an important factor reflecting the data usage intention, and for this reason, the target data tracking policy may further include: on the basis that the data flow direction identification network is used for tracking the data stealing intention of the payment service data to which the payment service event content belongs in the target payment service data, the data stealing behavior identification of the payment service event content according to the global usage intention of the service event content and the target data tracking policy described in step S3 to obtain the data stealing behavior identification result corresponding to the payment service event content may include the contents described in the following steps S31 to S33.
Step S31, inputting the global usage intention of the business event content into the data flow direction identification network in the target data tracking strategy, and determining an intention matching result between the global usage intention of the business event content and a plurality of sample abnormal usage intents in the data flow direction identification network by the data flow direction identification network; the intention matching result is used for representing evaluation information that the global use intention of the business event content and each sample abnormal use intention respectively correspond to the same payment business data. For example, the evaluation information may be used to describe the data usage safety of the sample abnormal usage intention, the evaluation information may be represented by an evaluation value, and the evaluation value may range from 0 to 1, or other values, which are not limited herein, and the larger the evaluation value, the lower the data usage safety of the sample abnormal usage intention is.
Step S32, based on the intention matching result, obtaining a sample abnormal use intention having a maximum intention matching evaluation value with the global use intention of the business event content from the plurality of sample abnormal use intentions, and taking the sample abnormal use intention having the maximum intention matching evaluation value as a target sample abnormal use intention.
Step S33, using the sample service data corresponding to the target sample abnormal usage intention as target payment service data corresponding to the global usage intention of the service event content, and determining a data theft behavior recognition result after tracking the data theft intention of the payment service event content in the target payment service data based on the target payment service data and the maximum intention matching evaluation value associated with the target payment service data.
It can be understood that by implementing the contents described in the above steps S31-S33, the data usage intention can be analyzed based on the data flow direction layer, so that the data theft intention tracking can be accurately performed on the payment business event content in the target payment business data through the maximum intention matching evaluation value, and the credibility of the data theft behavior recognition result can be ensured.
In some possible embodiments, a payment transaction event content corresponds to a data theft behavior recognition result; the sample service data corresponding to the multiple sample abnormal usage intents includes theft behavior type service data, and on the basis of the above contents, if the data theft behavior identification result represents that payment service event content meeting a data theft determination index exists in the target payment service data, the to-be-determined payment behavior tag is determined as an abnormal behavior tag, and a data call request for instructing to transmit the target payment service data to a target service end device having a tracking path corresponding relationship with the target data tracking policy is intercepted, which may include the contents described in the following steps S41 to S43.
And step S41, acquiring a data theft judgment index corresponding to the target data tracking strategy.
Step S42, if there is a data theft behavior recognition result that the target payment service data corresponds to the theft behavior service data in the data theft behavior recognition result, determining, in the payment service event content, the payment service event content corresponding to the target payment service data as the payment service event content meeting the data theft determination index. For example, the theft behavior-like business data may be business data related to illegal user portrait analysis.
Step S43, determining the pending payment behavior tag included in the target payment service data as an abnormal behavior tag, and intercepting a data call request for instructing to transmit the target payment service data to a target service end device having a tracking path corresponding relationship with the target data tracking policy.
It can be understood that by implementing the contents described in the above steps S41-S43, the analysis and determination of the data theft behavior identification result can be realized based on the theft behavior class service data, so as to verify and analyze the data call request related to the target payment service data, and avoid the leakage and theft of the payment service data caused by responding to the unauthorized data call request.
In a possible embodiment, the intercepting of the data call request for instructing the transmission of the target payment service data to the target service-side device having a tracking path corresponding relationship with the target data tracking policy, which is described in step S43, may include the following steps S431 to S436.
Step S431, obtaining i data call request items of the data call request queue to be processed, where the data call request items are initiated for the target payment service data, and i is a positive integer.
Step S432 is to divide each data call request transaction into at least two request content transaction messages having different security evaluation values of the data application scenario.
Step S433, determining the content item request message in which the payment service data to be verified is located from at least two content item request messages included in each data call request item.
Step S434, according to the request content item message of the payment service data to be verified in each data call request item, selecting at least one traceable data segment from the payment service data to be verified included in the i data call request items.
Step S435, determining a data transmission verification result corresponding to the payment service data to be verified according to the at least one traceable data segment; and analyzing a data transmission path of each data call request item corresponding to the to-be-processed data call request queue according to the data transmission verification result to obtain an analysis result of the data transmission path corresponding to each data call request item.
Step S436, judging whether the analysis result and the target data tracking strategy have a tracking path corresponding relation; and intercepting a data call request item corresponding to the analysis result when the analysis result and the target data tracking strategy are judged to have the tracking path relation. For example, determining whether the analysis result and the target data tracking policy have a tracking path correspondence relationship may be implemented in the following manner: determining a data transmission path topology corresponding to the analysis result and a data tracking path topology corresponding to the target data tracking strategy, calculating cosine distances of the data transmission path topology and the data tracking path topology, and if the cosine distances are greater than a set value, determining that the analysis result and the target data tracking strategy have the tracking path relation.
Therefore, the request content item message analysis can be carried out on different data call request items, traceable data fragments can be determined, and whether the analysis result and the target data tracing strategy have the corresponding relation of the tracing path or not can be determined according to the similarity between the path topological graphs, so that the legality detection of the different data call request items can be realized, and the leakage and the embezzlement of payment service data caused by the response of unauthorized data call requests can be avoided.
The dividing of each data call request transaction into at least two request content transaction messages with different security evaluation values of the data application scenario described in step S432 may include implementation in the following embodiment a or embodiment b.
In the embodiment a, each data call request transaction is divided into at least two request content transaction messages having different security evaluation values of the data application scenario according to the preset correspondence between the security evaluation value of the data application scenario and the transaction division manner.
The implementation mode b is characterized in that the corresponding relation between the security evaluation value and the item dividing mode of the data application scene is determined by counting the security evaluation value and the item dividing mode of the data application scene of each request content item message in the pre-stored verified data call request items; and dividing each data call request transaction into at least two request content transaction messages with different safety evaluation values of the data application scene according to the determined corresponding relation.
For the request content item message described in the above step S434, which is located in each data invocation request item according to the payment service data to be verified, selecting at least one traceable data segment from the payment service data to be verified, which is included in the i data invocation request items, the following step S4340 may be included: determining data fragment classification information of the payment service data to be verified, which is included in each data calling request item; and selecting at least one traceable data segment from the payment service data to be verified included in the i data call request items according to the request content item message of the payment service data to be verified in each data call request item and the data segment classification information of the payment service data to be verified included in each data call request item.
In some embodiments, the at least two request content transaction messages include a real-time request content transaction message and a delayed request content transaction message, the security rating of the data application scenario of the real-time request content transaction message is higher than the security rating of the data application scenario of the delayed request content transaction message, based on which the request content transaction message described in step S4340 is located in each data call request transaction according to the payment service data to be verified, and the data fragment classification information of the payment service data to be verified included in each data call request transaction, at least one traceable data fragment is selected from the payment service data to be verified included in the i data call request transactions, which may include the contents described in the following steps S4341 to S4343.
Step S4341, when the payment service data to be verified is in the real-time request content item message in j data invocation request items included in the i data invocation request items, selecting the payment service data to be verified having the largest data segment usage frequency of the data segment classification information as a first candidate payment service data to be verified from the payment service data to be verified included in the j data invocation request items according to the data segment classification information of the payment service data to be verified included in the j data invocation request items, where j is a positive integer smaller than i.
Step S4342, when the payment service data to be verified is in the delayed request content item message in k data invocation request items included in the i data invocation request items, selecting, from the payment service data to be verified included in the k data invocation request items, the payment service data to be verified having the largest data fragment usage frequency of the data fragment classification information as a second candidate payment service data to be verified according to the data fragment classification information of the payment service data to be verified included in the k data invocation request items, where k is a positive integer smaller than i, and the sum of k and j is equal to i.
Step S4343, selecting at least one traceable data segment from the first candidate payment service data to be verified and the second candidate payment service data to be verified according to a segment classification comparison result between the data segment classification information of the first candidate payment service data to be verified and the data segment classification information of the second candidate payment service data to be verified.
Therefore, different candidate payment service data to be verified can be determined based on the use frequency of the data fragments, so that the use heat of traceable data fragments is ensured, and the reliability of subsequent data theft analysis is facilitated.
In an alternative embodiment, in step S4, the data theft determination index is determined by the contents described in the following steps S51 to S55.
Step S51, obtaining first payment service data and second payment service data corresponding to historical payment service data, where the first payment service data includes data usage record information that does not include payment service feedback information in the historical payment service data, and the second payment service data includes data usage record information that includes payment service feedback information in the historical payment service data.
Step S52, performing data flow direction analysis processing on the first payment service data to obtain a data flow direction analysis result corresponding to the first payment service data.
Step S53, performing data flow analysis processing on the second payment service data to obtain a feedback information analysis result corresponding to the second payment service data.
And step S54, performing data usage authority identification on the feedback information analysis result and the data flow direction analysis result to obtain a data usage analysis result corresponding to the historical payment service data.
Step S55, classifying the data use scenes of the data use analysis results to obtain the use scene statistical information corresponding to the historical payment service data; and under the condition that the using scene statistical information comprises a statistical result with an abnormal scene identifier, generating a data stealing judgment index according to the statistical result with the abnormal scene identifier, the data flow direction analysis result and the feedback information analysis result.
By adopting the design, based on the steps S51-S55, the payment service feedback information and the data usage record information in the historical payment service data can be analyzed, so as to determine the data flow direction analysis result and the feedback information analysis result, and further obtain the data usage analysis result corresponding to the historical payment service data. Therefore, data use scene classification and abnormal scene identification determination can be carried out on the data use analysis result, and a data theft judgment index can be accurately generated, so that accurate and reliable identification of the data theft behavior identification result is realized.
In an alternative embodiment, the first payment service data and the second payment service data corresponding to the acquired historical payment service data described in step S51 may include the following: performing payment service detection on the historical payment service data to obtain first data usage record information which does not contain payment service feedback information in the historical payment service data, and splitting the first data usage record information in the historical payment service data to serve as the first payment service data; and according to the first data usage record information, second data usage record information containing payment service feedback information in the historical payment service data is obtained, and the second data usage record information in the historical payment service data is split to serve as the second payment service data.
In an alternative embodiment, the performing, as described in step S52, a data flow analysis process on the first payment service data to obtain a data flow analysis result corresponding to the first payment service data includes: calling a first data flow direction analysis network layer in a preset data flow direction recognition model, and performing data flow direction analysis processing on the first payment service data to obtain a data flow direction analysis result corresponding to the first payment service data.
In an alternative embodiment, the performing, as described in step S53, a data flow analysis process on the second payment service data to obtain a feedback information analysis result corresponding to the second payment service data includes: and calling a second data flow direction analysis network layer in the preset data flow direction identification model, and performing data flow direction analysis processing on the second payment service data to obtain a feedback information analysis result corresponding to the second payment service data.
In an alternative embodiment, the performing data usage right identification on the feedback information analysis result and the data flow direction analysis result as described in step S54 to obtain a data usage analysis result corresponding to the historical payment service data includes: and calling an authority feature analysis network layer in the preset data flow direction identification model, and performing data use authority identification on the feedback information analysis result and the data flow direction analysis result to obtain a data use analysis result corresponding to the historical payment service data.
In an alternative embodiment, the classifying the data usage scenario according to the result of the data usage analysis in step S55 to obtain the usage scenario statistical information corresponding to the historical payment service data includes: and calling a scene classification network layer in the preset data flow direction identification model, and carrying out data use scene classification on the data use analysis result to obtain use scene statistical information corresponding to the historical payment service data.
The above functional network layer may adjust the model parameters according to actual requirements, and will not be further described here.
It can be understood that the above technical solution can be applied to a person-to-person blockchain payment transaction, and can also be applied to a business-to-business blockchain payment transaction. For individuals, by implementing the technical scheme, the payment service data of the individuals can be prevented from being illegally called by a third-party platform so as to ensure the privacy of the personal information. For enterprises, by implementing the technical scheme, the business secrets of the enterprises can be prevented from being leaked. In addition, by implementing the technical scheme, the data storage reliability of the cloud server can be improved, so that the cloud server does not release any data calling request, the data storage reliability of the cloud server is improved, and data leakage and embezzlement are avoided.
Next, for the payment data processing method based on big data and blockchain finance, an exemplary payment data processing apparatus based on big data and blockchain finance is further provided in an embodiment of the present invention, and as shown in fig. 2, the payment data processing apparatus 200 based on big data and blockchain finance may include the following functional modules.
The data identification module 210 is configured to acquire target payment service data including a to-be-paid behavior tag, and perform service event identification processing on the target payment service data to obtain payment service event content corresponding to the target payment service data.
The intention extraction module 220 is configured to obtain a target data tracking policy corresponding to the target payment business data, extract a first data usage intention and a second data usage intention from the payment business event content through the target data tracking policy, and integrate the first data usage intention and the second data usage intention to obtain a global usage intention of the business event content associated with the target payment business data.
And the behavior identification module 230 is configured to perform data theft behavior identification on the payment business event content according to the global usage intention of the business event content and the target data tracking policy, so as to obtain a data theft behavior identification result corresponding to the payment business event content.
A request intercepting module 240, configured to determine the pending payment behavior tag as an abnormal behavior tag if the data theft behavior identification result indicates that the payment service event content meeting the data theft determination index exists in the target payment service data, and intercept a data call request for instructing to transmit the target payment service data to a target service end device having a tracking path corresponding relationship with the target data tracking policy.
Then, based on the above method embodiment and apparatus embodiment, the embodiment of the present invention further provides a system embodiment, that is, a payment data processing system based on big data and blockchain finance, please refer to fig. 3, where the payment data processing system 30 based on big data and blockchain finance may include the cloud server 10 and the blockchain device 20. Where the cloud server 10 and the blockchain device 20 communicate to implement the above method, further, the functionality of the big data and blockchain finance based payment data processing system 30 is described below.
A big data and blockchain finance based payment data processing system comprising a cloud server and a blockchain device in communication with each other; wherein the cloud server is configured to:
acquiring target payment service data containing a tag of pending payment behavior, and performing service event identification processing on the target payment service data to obtain payment service event content corresponding to the target payment service data;
acquiring a target data tracking strategy corresponding to the target payment business data, extracting a first data use intention and a second data use intention from the payment business event content through the target data tracking strategy, and integrating the first data use intention and the second data use intention to obtain a global use intention of the business event content associated with the target payment business data;
according to the global use intention of the business event content and the target data tracking strategy, carrying out data theft behavior identification on the payment business event content to obtain a data theft behavior identification result corresponding to the payment business event content;
and if the data theft behavior identification result represents that the payment business event content meeting the data theft judgment index exists in the target payment business data, determining the undetermined payment behavior label as an abnormal behavior label, and intercepting a data call request for indicating that the target payment business data is transmitted to target business end equipment with a tracking path corresponding relation with the target data tracking strategy.
Further, referring to fig. 4 in combination, the cloud server 10 may include a processing engine 110, a network module 120, and a memory 130, wherein the processing engine 110 and the memory 130 communicate through the network module 120.
Processing engine 110 may process the relevant information and/or data to perform one or more of the functions described herein. For example, in some embodiments, processing engine 110 may include at least one processing engine (e.g., a single core processing engine or a multi-core processor). By way of example only, the Processing engine 110 may include a Central Processing Unit (CPU), an Application-Specific Integrated Circuit (ASIC), an Application-Specific Instruction Set Processor (ASIP), a Graphics Processing Unit (GPU), a Physical Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller Unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination thereof.
Network module 120 may facilitate the exchange of information and/or data. In some embodiments, the network module 120 may be any type of wired or wireless network or combination thereof. Merely by way of example, the Network module 120 may include a cable Network, a wired Network, a fiber optic Network, a telecommunications Network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth Network, a Wireless personal Area Network, a Near Field Communication (NFC) Network, and the like, or any combination thereof. In some embodiments, the network module 120 may include at least one network access point. For example, the network module 120 may include wired or wireless network access points, such as base stations and/or network access points.
The Memory 130 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like. The memory 130 is used for storing a program, and the processing engine 110 executes the program after receiving the execution instruction.
It is to be understood that the configuration shown in fig. 4 is merely illustrative, and that cloud server 10 may include more or fewer components than shown in fig. 2, or have a different configuration than shown in fig. 4. The components shown in fig. 4 may be implemented in hardware, software, or a combination thereof.
Based on the above scheme, the inventor also finds that the problem of data leakage also needs to be considered when the cloud server stores the payment service data, and therefore, an additional payment data processing method based on big data and block chain finance is proposed, and as described below, it can be understood that the following method may be implemented by referring to the embodiment of the method shown in fig. 1, and therefore, details are not described later.
It is to be understood that the description of the method steps shown in a1 can be further described with reference to fig. 5, as follows.
A1. A big data and blockchain finance-based payment data processing method, comprising:
step S61, obtaining target payment service data, and determining a data theft behavior identification result according to the target payment service data;
and step S62, intercepting a data call request for indicating that the target payment service data is transmitted to the target service end equipment having a tracking path corresponding relation with a preset target data tracking strategy according to the data theft identification result and a preset data theft judgment index.
A2. According to the method as set forth in a1,
obtaining target payment service data, and determining a data stealing behavior identification result according to the target payment service data, wherein the data stealing behavior identification result comprises the following steps:
acquiring target payment service data containing a tag of pending payment behavior, and performing service event identification processing on the target payment service data to obtain payment service event content corresponding to the target payment service data;
acquiring a target data tracking strategy corresponding to the target payment business data, extracting a first data use intention and a second data use intention from the payment business event content through the target data tracking strategy, and integrating the first data use intention and the second data use intention to obtain a global use intention of the business event content associated with the target payment business data;
according to the global use intention of the business event content and the target data tracking strategy, carrying out data theft behavior identification on the payment business event content to obtain a data theft behavior identification result corresponding to the payment business event content;
intercepting a data call request for indicating that target payment service data are transmitted to target service end equipment with a tracking path corresponding relation with a preset target data tracking strategy through the data theft identification result and a preset data theft judgment index, wherein the data call request comprises the following steps:
and if the data theft behavior identification result represents that the payment business event content meeting the data theft judgment index exists in the target payment business data, determining the undetermined payment behavior label as an abnormal behavior label, and intercepting a data call request for indicating that the target payment business data is transmitted to target business end equipment with a tracking path corresponding relation with the target data tracking strategy.
It is understood that further description of a2 can refer to the above description of the step in fig. 1, and will not be repeated herein.
It should be understood that, for the above, a person skilled in the art can deduce from the above disclosure to determine the meaning of the related technical term without doubt, for example, for some values, coefficients, weights, indexes, factors, and other terms, a person skilled in the art can deduce and determine from the logical relationship between the above and the following, and the value range of these values can be selected according to the actual situation, for example, 0 to 1, for example, 1 to 10, and for example, 50 to 100, which are not limited herein.
The skilled person can unambiguously determine some preset, reference, predetermined, set and target technical features/terms, such as threshold values, threshold intervals, threshold ranges, etc., from the above disclosure. For some technical characteristic terms which are not explained, the technical solution can be clearly and completely implemented by those skilled in the art by reasonably and unambiguously deriving the technical solution based on the logical relations in the previous and following paragraphs. Prefixes of unexplained technical feature terms, such as "first", "second", "previous", "next", "current", "history", "latest", "best", "target", "specified", and "real-time", etc., can be unambiguously derived and determined from the context. Suffixes of technical feature terms not to be explained, such as "list", "feature", "sequence", "set", "matrix", "unit", "element", "track", and "list", etc., can also be derived and determined unambiguously from the foregoing and the following.
The foregoing disclosure of embodiments of the present invention will be apparent to those skilled in the art. It should be understood that the process of deriving and analyzing technical terms, which are not explained, by those skilled in the art based on the above disclosure is based on the contents described in the present application, and thus the above contents are not an inventive judgment of the overall scheme.
It should be appreciated that the system and its modules shown above may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules of the present application may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).
It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.
Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be considered merely illustrative and not restrictive of the broad application. Various modifications, improvements and adaptations to the present application may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present application and thus fall within the spirit and scope of the exemplary embodiments of the present application.
Also, this application uses specific language to describe embodiments of the application. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.
Moreover, those skilled in the art will appreciate that aspects of the present application may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereon. Accordingly, various aspects of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.
The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.
Computer program code required for the operation of various portions of the present application may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).
Additionally, the order in which elements and sequences of the processes described herein are processed, the use of alphanumeric characters, or the use of other designations, is not intended to limit the order of the processes and methods described herein, unless explicitly claimed. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.
Similarly, it should be noted that in the preceding description of embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.
Numerals describing the number of components, attributes, etc. are used in some embodiments, it being understood that such numerals used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the numbers allow for adaptive variation. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.
The entire contents of each patent, patent application publication, and other material cited in this application, such as articles, books, specifications, publications, documents, and the like, are hereby incorporated by reference into this application. Except where the application is filed in a manner inconsistent or contrary to the present disclosure, and except where the claim is filed in its broadest scope (whether present or later appended to the application) as well. It is noted that the descriptions, definitions and/or use of terms in this application shall control if they are inconsistent or contrary to the statements and/or uses of the present application in the material attached to this application.
Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present application. Other variations are also possible within the scope of the present application. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the present application can be viewed as being consistent with the teachings of the present application. Accordingly, the embodiments of the present application are not limited to only those embodiments explicitly described and depicted herein.