The application discloses a division application of China patent application with the name of data processing method, device and system, which is filed by China patent office, application number 201310305847.6 and is named as data processing method, device and system in 2013, 07 and 19.
Detailed Description
The main idea of the application is that the data interaction between users is accomplished in an off-line situation by creating, processing and transmitting credential data. Specifically, the credential data is created online, and corresponding signing and/or signing verification processing is carried out on the credential data through a server and a user client based on an asymmetric encryption mechanism, so that data interaction between users can be finished offline based on the credential data. More specifically, signing the credential data with the private key of the server that created the credential data may ensure the legitimacy of the credential data, while signing the credential data with the private key of the client that requested to create the credential data may ensure the anti-repudiation characteristics of the credential data.
In this credential data based data interaction process, which is implemented by means of an asymmetric encryption mechanism, data interaction between users can be accomplished by a third party based on credential data created by a user request server, in addition to the users themselves. Therefore, the method can be used for completing data interaction without naming, online or registering in a server. In addition, the credential data can be stored, carried, or transmitted to the opposing user in a variety of ways. In addition, the users of both sides in the actual interaction get rid of the dependence on the network as far as possible. Therefore, according to the conception of the application, the flexibility and convenience of data interaction can be increased, the use of a user is convenient, and the user experience is enhanced.
The present application will be described in further detail with reference to the drawings and the embodiments, in order to make the objects, technical solutions and advantages of the present application more apparent.
To facilitate an understanding of the inventive concept, a typical application scenario of a data processing system according to an embodiment of the present application, namely, online payment, is described herein first in connection with fig. 1. It should be noted that embodiments of the inventive concept will be specifically described herein in connection with this exemplary application scenario, but the present application is not limited thereto, and may be applied to any other suitable data interaction scenario, existing or developed in the future.
FIG. 1 depicts a schematic diagram of the architecture of a data processing system according to an embodiment of the application. As shown in fig. 1, the system 100 may include at least a server 110, a first client 120, and a second client 130.
In the application scenario of the present embodiment, the server 110 may be a server of a payment service provider, which may be a server of a third party payment platform such as a payment device, a financial payment device, cheng Futong, or a server of an internet banking. Both the first client 120 and the second client 130 may be terminal devices such as cell phones, personal computers, personal digital assistants, portable devices, and the like. The first client 120 may be a payer, which is a transaction creator, and an account is opened on the server side. The second client 130 may be a payee, who is a transaction shipper, who also opens an account on the server side.
The first client 120 may establish a connection with the server 110 through a communication network such as the internet, a local area network, a wide area network, etc., and send a credential creation request online to the server 110 to apply for creation of credential data for offline payment.
In response to the credential creation request of the first client 120, the server 110 creates credential data for offline payment and may perform a signing operation (first signing operation) on the credential data. After completing the signing operation on the credential data, the server 110 sends the signed credential data to the first client 120 through the communication network.
The first client 120 performs a signing operation (second signing operation) again on the credential data after receiving the credential data from the server 110, and transmits the credential data signed by the first and second signing to the second client 130, or to a third party, and then transmitted to the second client 130 by the third party.
The second client 130, after receiving the first signed and second signed credential data from the first client 120 or the third party, performs a signature verification operation (first signature verification operation) on the credential data, and transmits the credential data for which the signature verification is successful to the server 110 to request a receipt process.
The server 110 receives the credential data from the second client 130, performs a signature verification operation (second signature verification operation) again on the credential data, performs a collection process (credential process) on the credential data for which the signature verification was successful, and feeds back the result information of the collection process to the second client 130.
The second client 130 passes the user or the third party of the first client 120 after receiving the receipt success information.
The workflow of the overall system architecture under a typical scenario according to an embodiment of the present application is described above in connection with fig. 1, but the present application is not limited thereto. For example, the offline of the payee in the payment process can be realized on the premise of ensuring that the credit status of the payee is good and the payee cannot pay for malicious reuse of the credential by taking advantage of the opportunity that the payee cannot pay in real time based on the credential data. In this case, the collection process may be completed in batch when the second client, i.e., the recipient, is online after a period of time has elapsed, that is, the second client may release the first client or the third party after receiving the credential data.
According to the data processing system provided by the embodiment of the application, the data interaction between the clients can be realized through the credential data under the condition that the clients are offline, namely disconnected with the server. In a typical scenario, the payment process of a transaction with the payee may be completed through credential data with the payer offline, even with the payee offline, i.e., disconnected from the server. Therefore, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
The data processing procedure of each side of the server (payment facilitator), the first client (payer), the second client (payee) in the system architecture is described in more detail below in connection with fig. 2 to 4.
Fig. 2 shows a flow chart of a data processing method according to an embodiment of the present application, in which a data processing procedure on the side of a first client (first client 120 of fig. 1, payer) is described.
At step S210, the first client 120 transmits a credential creation request to the server 110.
Specifically, as mentioned above, the first client 120 may establish a connection with the server 110 through a communication network such as the internet, a local area network, a wide area network, or the like, and send a credential creation request online to the server 110 to apply for creation of credential data for offline data interactions.
In one example, a user of the first client 120 may apply online to the server 110 to create a pending payment transaction and may apply offline payment means for the pending payment transaction. The server 110 may create offline payment credential data for the payment to pay transaction in response to the credential creation request of the first client 120.
More specifically, the voucher data can include, for example, a document number, document type, creation time, payment account number, payment amount, collection account number, and the like, but is not limited thereto. For example, the credential data may not include a collection account number and/or a payment amount, and thus directional, non-directional, rated, or un-rated payments may be implemented as desired. In one particular example, the credential data can be, for example, electronic check data or other similar data.
In another example, the user of the first client 120 may apply online directly to the server 110 to create electronic check data for offline payment.
Next, at step S220, the first client 120 receives credential data from the server 110, the credential data being created by the server 110 according to the credential creation request and performing a first signing operation.
Specifically, in response to the credential creation request of the first client 120, the server 110 may perform a signing operation, i.e., a first signing operation, on credential data for offline payment after the credential data is created as described above. In one particular embodiment, the credential data may be first signed according to a private key of the server 110. In another embodiment, the credential data may be first signed according to a public key of the server 110. In a preferred embodiment, the server 110 may perform a corresponding freezing process on the account of the first client, i.e. freeze the corresponding application amount from the payment account, simultaneously with or after the first signing operation on the credential data.
Here, the validity of the credential data can be ensured by signing the credential data with a private key or a public key of a server (payment service provider).
At step S230, the first client 120 performs a second signing operation on the first signed credential data to obtain first and second signed credential data.
Specifically, after receiving the credential data from the server 110, the first client 120 performs the signing operation on the credential data again, that is, the second signing operation. In one particular embodiment, the credential data may be subjected to a second signing operation based on the private key of the first client 120, which is the private key of a set of proprietary asymmetric keys, i.e., private-public key pairs, created in advance for it by the server 110. In another embodiment, the credential data may be subjected to a second signing operation based on the public key of the first client 120, which public key of the first client 120 is the public key of a set of proprietary asymmetric keys, i.e., private-public key pairs, created in advance for it by the server 110.
Here, the anti-repudiation property of the credential data can be ensured by signing the credential data with the private key or the public key of the first client (payer).
Then, at step S240, the first client 120 transmits the first signed and second signed credential data to the second client 130.
Specifically, the first client 120 may transmit the signed credential data to the second client 130 in any suitable manner. According to embodiments of the present application, the transmission may be performed by any one or more means such as two-dimensional code, sound wave, bluetooth, wifi, etc.
In one example, the first client 120 may transmit the signed credential data via the first and second signs to the second client 130 via a third party (as shown in the dashed box of fig. 1). Specifically, the first client 120 may transmit the first signed credential data to the third party in any suitable manner, and then the third party may transmit the first signed credential data to the second client 130 in any suitable manner. The third party may be any party other than the user of the first client 120, and may not have an account on the server side, or may have an account on the server side.
In another example, the first client 120 may directly transmit the signed credential data to the second client 130 via any suitable means, without passing through a third party.
In addition, according to the embodiment of the present application, in the case where the payment amount is not included at the time of initial creation of the credential data, that is, at the time of non-rated payment, an amount to be actually paid may be input or given at the time of providing the credential data to the payee, which amount may not be generally larger than the maximum amount value set in the non-rated credential application.
The data processing procedure on the first client (payer) side is described above in connection with fig. 2. In the data processing process, the first client only needs to apply online to create the credential data of offline data interaction, so that the data interaction with the second client based on the credential data can be realized even in an offline state. In a typical scenario, a payer only needs to apply online to create credential data for offline payment, so that payment that can be transacted with a payee based on the credential data even in an offline state can be achieved. Therefore, according to the data processing method of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
The following describes the data processing procedure on the second client side (second client 130 of fig. 1, payee) with reference to fig. 3.
As shown in fig. 3, at step S310, the second client 130 receives credential data (see fig. 1) from the first client 120, the credential data being created by the server 110 according to a credential creation request from the first client 120 and passing through a first signing operation of the server 110 and a second signing operation of the first client 120.
Specifically, the second client 130 may receive credential data from the first client 120 in any suitable manner. According to embodiments of the present application, the reception may be performed by any one or more means such as two-dimensional code, sound wave, bluetooth, wifi, etc. In a preferred case, the second client 130 may receive the credential data from the first client 120 in a case where the first client 120 is offline, i.e., in a case where the first client 120 is disconnected from the server 110.
As mentioned above, the credential data may include, for example, a document number, a document type, a creation time, a payment account number, a payment amount, a collection account number, and the like, but is not limited thereto. For example, the credential data may not include a collection account number and/or a payment amount, and thus directional, non-directional, rated, or un-rated payments may be implemented as desired. In one particular example, the credential data can be, for example, electronic check data or other similar data.
In a specific embodiment, the credential data received by the second client 130 may be signed via the server 110 according to the private or public key of the server 110 and signed via the first client 120 according to the private or public key of the first client 120.
Next, at step S320, the second client 130 performs a first signing operation on the received credential data.
Specifically, the second client 130 performs the first signing operation on the received credential data according to the public key or the private key of the server 110. In a specific embodiment, if the received credential data is signed by the server 110 according to the private key of the server 110, the second client 130 performs the first signing operation according to the public key of the server 110. In another embodiment, if the received credential data is signed by the server 110 according to the public key of the server 110, the second client 130 performs the first signing operation according to the private key of the server 110.
After the first signature verification operation is successful, in step S320, the second client 130 sends a credential processing request to the server 110, so that the server 110 performs a second signature verification operation on the credential data and performs the credential processing operation on the credential data after the second signature verification operation is successful.
Specifically, the second client 130 may establish a connection with the server 110 through a communication network such as the internet, a local area network, a wide area network, or the like, send credential data that the first authentication succeeds to the server 110 online, and request the server 110 to perform a credential processing operation. After receiving the credential processing request, the server 110 performs a signing operation (second signing operation) on the credential data, and then performs the credential processing operation on the credential data that has been successfully signed.
In an embodiment of the present application, the voucher processing operation may include a collection operation in which a funds transfer operation from a payment account number to a collection account number is performed in accordance with information, such as a payment account number, a payment amount, and the like, included in voucher data, such as an electronic check.
Next, at step S330, the second client 130 receives result information of the credential processing operation from the server 110.
In particular, the server 110 may feed back result information of the credential processing operation to the second client 130 in response to the credential processing request of the second client 130. More specifically, when the credential data verification is successful and the credential processing operation is performed successfully, the second client 130 may receive information that the credential processing operation is successful. The second client 130 may receive information of the credential processing operation failure when the credential data validation fails and/or the credential processing operation execution fails.
In one example scenario, when the server verifies that the offline payment credential data is successful and the collection operation is performed successfully, a notification of the collection success may be sent to the payee. After the payee receives the notification of successful receipt, the payee may release the payment or the third party to the transaction.
The data processing procedure on the second client (payee) side is described above in connection with fig. 3. In the data processing process, the second client may apply for completing data interaction with the first client based on the credential data to the server in a case where the first client is offline, i.e., in a case where the first client is disconnected from the server. In a typical scenario, the payee may request to the server to perform a payee operation based on offline payment credential data in a state where the payer is offline. Therefore, according to the data processing method of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
The following describes a data processing procedure on the server side (server 110 of fig. 1, payment service provider) with reference to fig. 4.
As shown in fig. 4, at step S410, a credential creation request is received from the first client 120 (see fig. 1).
Specifically, as mentioned above, the server 110 may receive the credential creation request from the first client 120 via a network connection, such as the internet, a local area network, a wide area network, etc., with the first client 120.
Next, at step S420, credential data is created and a first signing operation is performed on the credential data according to the credential creation request.
In one example, when a user of the first client 120 is applying for creation of a pending payment transaction to the server 110 and applying for offline payment for the pending payment transaction, the server 110 may create the transaction and generate offline payment credential data for the pending payment transaction in response to the credential creation request of the first client 120.
More specifically, the voucher data can include, for example, a document number, document type, creation time, payment account number, payment amount, collection account number, and the like, but is not limited thereto. For example, the credential data may not include a collection account number and/or a payment amount, and thus directional, non-directional, rated, or un-rated payments may be implemented as desired. In one particular example, the credential data can be, for example, electronic check data or other similar data.
In another example, when a user of the first client 120 is applying for creating electronic check data directly to the server 110, the server 110 may directly create electronic check data accordingly for use by the user in various offline payment scenarios.
After the credential data is created, the server 110 performs a signing operation (first signing operation) on the credential data. According to an embodiment of the present application, the server 110 may sign the credential data according to the server's private or public key. More preferably, the server 110 may perform a corresponding freezing process on the account of the first client 120, that is, freeze the corresponding application amount from the payment account, simultaneously with or after performing the first signing operation on the credential data.
Next, at step S430, the first signed credential data is sent to the first client 120 to perform a second signing operation on the first signed credential data by the first client 120 and to transmit the first and second signed credential data to the second client 130.
Specifically, the server 110 transmits the first signed credential data to the first client 120 over a network connection with the first client 120.
As mentioned above, after receiving the first signed credential data from the server 110, the first client 120 may perform a second signing operation (second signing operation) on the first signed credential data according to the private key or the public key of the first client 120 and transmit the first signed and second signed credential data to the second client 130 in any suitable manner.
Then, at step S440, a credential processing request is received from the second client 130, the credential processing request being issued by the second client 130 after receiving the first signed and second signed credential data from the first client 120 and performing the first signing operation successfully on the first signed and second signed credential data.
Specifically, after the second client 130 performs the signing verification operation on the signed credential data from the first client 120 according to the public key or the private key of the server, a network connection is established with the server 110, and a credential processing request is sent online to the server 110, so that the server 110 receives the request accordingly.
Next, at step S450, according to the credential processing request, a second signing operation is performed on the credential data and a credential processing operation is performed on the credential data for which the second signing operation was successful.
Specifically, the server 110 performs a signing operation (second signing operation) on the credential data according to the public key or the private key of the first client 120 to determine the validity of the credential data. If the signature verification is successful, continuing to execute the credential processing operation; if the signature verification fails, the second client 130 is fed back with the result information of the signature verification failure.
In one example, the voucher processing operation may include a collection operation in which a funds transfer operation from a payment account number to a collection account number is performed in accordance with information, such as a payment account number, a payment amount, a collection account number, and the like, included in voucher data, such as an electronic check. In one particular embodiment, if the collection account number is not included in the credential data, the payee and collection account are determined from the uploading party of the credential data. In a specific embodiment, if the server 110 performs a corresponding freezing process on the account of the first client 120 at the same time or after performing the first signing operation on the credential data when the first client applies to create the offline payment credential data, the server 110 thaws the funds of the frozen payer account and transfers the funds to the payee account after the credential data from the second client 130 is successfully signed.
Next, at step S460, the result information of the credential processing operation is transmitted to the second client 130.
If the server 110 successfully signs against the credential data and the credential processing operations are also performed successfully, the second client 130 is notified that the operations were successful. If the server 110 fails to verify the signing for the credential data and/or the credential processing operation fails to perform, the second client 130 is notified of the operation failure.
The second client 130 may then determine whether to pass the first client 120 or the third party based on the result information of the credential processing operation.
The data processing procedure on the server (payment facilitator) side is described above in connection with fig. 4. During this data processing, the server may create credential data and cause the data interaction between the first client and the second client to be completed based on the credential data if the first client is offline, i.e., disconnected from the server. In a typical scenario, the server may perform a collection operation based on offline payment credential data from the payee in a state where the payer is offline. Therefore, according to the data processing method of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
The data processing method according to the embodiment of the present application has been described so far with reference to fig. 2 to 4, and the above-described embodiment is only a preferred example of the present application, to which the present application is not limited, but various modifications may be made. For example, in other embodiments of the present application, the payee's offline during payment can also be implemented without taking advantage of the payee's offline opportunity to be unable to pay based on credential data in real time to artificially and maliciously reuse the credential for payment, while ensuring that the payee's credit is in good condition. In this case, the collection process may be completed in batch when the second client, i.e., the recipient, is online after a period of time has elapsed, that is, the second client may release the first client or the third party after receiving the credential data.
Similar to the data processing method, the embodiment of the application also provides a corresponding device.
Fig. 5 shows a schematic structural diagram of a data processing apparatus according to an embodiment of the present application, in which a first client (payer) side data processing apparatus 500 is described.
As shown in fig. 5, the apparatus 500 may include a first request sending module 510, a first signed credential receiving module 520, a signed module 530, and a credential transmitting module 540.
Specifically, the first request sending module 510 may be configured to send a credential creation request to a server. The first signing credential receipt module 520 may be configured to receive credential data from a server that was created by the server in accordance with the credential creation request and to perform a first signing operation. The signing module 530 may be configured to perform a second signing operation on the first signed credential data to obtain the first signed and second signed credential data. The credential transmission module 540 may be configured to transmit the first signed and second signed credential data to the second client.
By means of the data processing device, the first client can realize data interaction with the second client based on the credential data even in an offline state only by applying online to create the credential data of offline data interaction. In a typical scenario, a payer only needs to apply online to create credential data for offline payment, so that payment that can be transacted with a payee based on the credential data even in an offline state can be achieved. Therefore, according to the data processing device of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
Fig. 6 shows a schematic structural diagram of a data processing apparatus according to another embodiment of the present application, in which a data processing apparatus 600 on the second client (payee) side is described.
As shown in fig. 6, the apparatus 600 may include a credential receiving module 610, a signature verification module 620, a second request sending module 630, and an information receiving module 640.
In particular, the credential receiving module 610 may be configured to receive credential data from a first client that is created by a server according to a credential creation request from the first client and passed through a first signing operation of the server and a second signing operation of the first client. The signature verification module 620 may be configured to perform a first signature verification operation on the credential data. The second request sending module 630 may be configured to send, after the first signing operation is successful, a credential processing request to the server, so that the server performs a second signing operation on the credential data and performs a credential processing operation on the credential data after the second signing operation is successful. The information receiving module 640 may be used to receive result information of the credential processing operations from the server.
By means of the data processing device of the embodiment, the second client can apply for completing data interaction with the first client based on the credential data to the server under the condition that the first client is offline, namely, the first client is disconnected from the server. In a typical scenario, the payee may request to the server to perform a payee operation based on offline payment credential data in a state where the payer is offline. Therefore, according to the data processing method of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
Fig. 7 shows a schematic configuration diagram of a data processing apparatus according to still another embodiment of the present application, in which a server (payment facilitator) side data processing apparatus 700 is described.
As shown in fig. 7, the apparatus 700 may include a first request receiving module 710, a create and sign-up module 720, a first sign-up credential transmitting module 730, a second request receiving module 740, a sign-up and processing module 750, and an information transmitting module 760.
In particular, the first request receiving module 710 may be configured to receive a credential creation request from a first client. The create and sign module 720 may be configured to create credential data and perform a first sign-on operation on the credential data according to the credential creation request. The first signed credential sending module 730 may be configured to send the first signed credential data to the first client, so that the first client performs a second signing operation on the first signed credential data and transmits the first signed credential data to the second client. The second request receiving module 740 may be configured to receive a credential processing request from the second client, where the credential processing request is sent by the second client after receiving the first signed and second signed credential data from the first client and performing the first signing operation on the first signed and second signed credential data. The signature verification and processing module 750 may be configured to perform a second signature verification operation on the credential data according to the credential processing request and perform a credential processing operation on the credential data for which the second signature verification operation is successful. The information sending module 760 may be used to send the result information of the credential processing operation to the second client.
With the data processing apparatus of the present embodiment, the server can create credential data and cause data interaction between the first client and the second client to be completed based on the credential data in a case where the first client is offline, i.e., disconnected from the server. In a typical scenario, the server may perform a collection operation based on offline payment credential data from the payee in a state where the payer is offline. Therefore, according to the data processing method of the embodiment, the flexibility and convenience of data interaction (online payment) can be improved, the use of a user is facilitated, and the user experience is enhanced.
In addition, each of the data processing apparatuses described above corresponds to the processing of the corresponding data processing method described previously, and therefore, for more detailed technical details, reference may be made to the method described previously.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, 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, 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 one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
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 storage media for a computer 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, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
The above description is only an example of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.