Time factor calibration method and system for digital currency transaction

Abstract

The embodiment of the invention provides a time factor calibration method and system for digital currency transaction. The method comprises the following steps that: a background server receives authorization information which is forwarded by an acceptance terminal, is sent by a hard wallet and is used for calibrating a time factor; the background server executes an operation of generating a time factor calibration instruction or executes a time factor calibration operation according to the authorization information under the condition of confirming that the authorization information is trusted; and the background server forwards the time factor calibration instruction to the hard wallet through the acceptance terminal so as to enable the hard wallet to execute the time factor calibration operation, or sends a processing result of executing the time factor calibration operation by the background server to the acceptance terminal. The method can ensure time synchronization of the hard wallet and the background server.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to a time factor calibration method and system for digital currency transaction. BACKGROUND

[0002] With the continuous development of computer technology and information security technology, the application scenarios of digital currency wallets are becoming more and more extensive, and the use scenarios are increasingly rich. Generally, a digital currency wallet includes a soft wallet and a hard wallet, wherein the hard wallet can perform offline transactions, a terminal receives transaction information and sends the transaction information to a background, the background processes the transaction, and the hard wallet needs to be connected to the network to synchronize and update relevant transaction data and information after a certain number of offline transactions are completed.

[0003] In some scenarios, the time of the hard wallet needs to be synchronized with the background to normally complete the digital currency transaction, but there is currently no corresponding technical solution to meet the above requirements. SUMMARY

[0004] At least one embodiment of the present disclosure provides a time factor calibration method for digital currency transaction, wherein the method comprises: a background server receiving authorization information for calibrating a time factor sent by a hard wallet forwarded by a terminal; the background server executing a time factor calibration operation or generating a time factor calibration instruction according to the authorization information if it is confirmed that the authorization information is trustworthy; the background server forwarding the time factor calibration instruction to the hard wallet through the terminal to make the hard wallet execute the time factor calibration operation, or sending a processing result of the time factor calibration operation executed by the background server to the terminal.

[0005] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the authorization information includes a first instruction identifier, and the background server generates a time factor calibration instruction containing a time factor and a hard wallet check value in response to the first instruction identifier.

[0006] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the method further comprises: the background server receiving code information obtained by scanning a payment code provided by the hard wallet through the terminal, and confirming whether the code information is valid; the background server sends a first prompt information to the terminal to prompt the user to perform a corresponding operation if it is confirmed that the code information is invalid, so that the hard wallet and the terminal interact to send the authorization information to the terminal.

[0007] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the background server performs at least one of the following verifications on the code information, and if the judgment result is no, it is confirmed that the code information is invalid: judging whether the receiving time of the code information meets the set time range; judging whether the institution identifier of the code information meets the requirement; verifying whether the check code in the code information is valid.

[0008] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0009] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0010] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0011] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0012] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0013] For example, in the step of verifying whether the check code in the check code information is valid, according to the time factor calibration method of at least one embodiment of the present disclosure, the method comprises: determining an account index from the code information, and searching for corresponding hard wallet data according to the account index; calculating a first expected time for generating the check code according to the hard wallet data, and calculating a first check code based on the first expected time; and verifying whether the check code in the check code information is consistent with the calculated first check code, and if consistent, confirming that the check code is valid.

[0014] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, when receiving the time factor calibration instruction, the terminal further judges whether the hard wallet is in communication interaction with the terminal, and if the communication is abnormal, a second prompt information is generated to prompt the user to keep the hard wallet and the terminal in communication.

[0015] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the method further comprises: the terminal scans the payment code provided by the hard wallet to obtain code information, and sends it to the background server to confirm whether the code information is valid; the terminal receives the first prompt information sent by the background server when confirming that the code information is invalid to prompt the user to perform the corresponding operation, and makes the hard wallet and the terminal interact to send the authorization information to the terminal, wherein the first prompt information is sent by the background server to the terminal when confirming that the code information is invalid.

[0016] At least one embodiment of the present disclosure provides a time factor calibration method for digital currency transaction, wherein the method comprises: the hard wallet sends authorization information for calibrating the time factor to the terminal in interaction; the hard wallet receives the time factor calibration instruction generated by the background server forwarded by the terminal, and performs the time factor calibration operation according to the time factor calibration instruction.

[0017] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the step of the hard wallet performing the time factor calibration operation according to the time factor calibration instruction comprises a time difference judgment step: judging whether the time difference between the time factor in the time factor calibration instruction and the current hard wallet reference time of the hard wallet is greater than at least one set time step, and if the judgment result is greater than at least one set time step, the hard wallet reference time is updated to the time factor.

[0018] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, before the hard wallet performs the time factor calibration operation according to the time factor calibration instruction, it further comprises: judging whether the time difference between the time of sending the authorization information to the terminal and the current hard wallet reference time of the hard wallet is less than the first set time range, and if the judgment result is less than the first set time range, the time factor calibration operation is performed.

[0019] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, the method further comprises: the hard wallet sends the authorization information in response to the digital currency transaction instruction sent by the terminal; the step of the hard wallet performing the time factor calibration operation according to the time factor calibration instruction further comprises: judging whether the time difference between receiving the time factor calibration instruction and receiving the digital currency transaction instruction is less than the second set time range, and if the judgment result is less than the second set time range, the time difference judgment step is performed.

[0020] At least one embodiment of the present disclosure provides a time factor calibration system for digital currency transaction, wherein the system comprises a hard wallet, a receiving terminal and a background server, the hard wallet is configured to send authorization information for calibrating a time factor to the receiving terminal, and receive a time factor calibration instruction from the receiving terminal to perform a time factor calibration operation; the receiving terminal is configured to: receive the authorization information for calibrating the time factor from the hard wallet in the interaction; send the authorization information to the background server if it is confirmed that the authorization information is trustworthy; forward the time factor calibration instruction received from the background server to the hard wallet, or receive a processing result of the time factor calibration operation performed by the background server from the background server; the background server is configured to perform the operation of generating the time factor calibration instruction or perform the time factor calibration operation according to the authorization information if it is confirmed that the authorization information is trustworthy.

[0021] At least one embodiment of the present disclosure provides an electronic device, comprising: one or more processors; a memory storing one or more computer program modules; wherein the one or more computer program modules are configured to be executed by the one or more processors to implement the method provided by at least one embodiment of the present disclosure.

[0022] At least one embodiment of the present disclosure provides a computer-readable medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by one or more processors, implement the method provided by at least one embodiment of the present disclosure.

[0023] The time factor calibration scheme for digital currency transaction of the embodiments of the present disclosure can ensure the time synchronization of the hard wallet and the background server, and further ensure that the dynamic offline payment code generated based on the time factor remains valid. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments of the present disclosure will be briefly introduced below. Obviously, the drawings described below only relate to some embodiments of the present disclosure, not limit the present disclosure.

[0025] Figure 1 A block diagram of a time factor calibration system for digital currency transaction according to at least one embodiment of the present disclosure is shown;

[0026] Figure 2 A block diagram of an exemplary digital currency hard wallet according to at least one embodiment of the present disclosure is shown;

[0027] Figure 3 A flowchart of a time factor calibration method for digital currency transaction according to at least one embodiment of the present disclosure is shown;

[0028] Figure 4 FIG. 8 shows a flowchart of a time factor calibration method for digital currency transactions according to an example of at least one embodiment of the present disclosure;

[0029] Figure 5 FIG. 8 shows a flowchart of a time factor calibration method for digital currency transactions according to an example of at least one embodiment of the present disclosure;

[0030] Figure 6 FIG. 8 shows a flowchart of a time factor calibration method for digital currency transactions according to an example of at least one embodiment of the present disclosure;

[0031] Figure 7 FIG. 9 shows a schematic diagram of an electronic device according to at least one embodiment of the present disclosure;

[0032] Figure 8 FIG. 10 shows a schematic diagram of a computer readable medium according to at least one embodiment of the present disclosure. DETAILED DESCRIPTION

[0033] Reference will now be made in detail to specific embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. While the present disclosure will be described in conjunction with specific embodiments, it will be understood that the present disclosure is not intended to be limited to the described embodiments. On the contrary, the present disclosure is intended to cover alternatives, modifications, and equivalents, which can be included within the spirit and scope of the present disclosure as defined by the appended claims. It should be noted that the method operations described herein can be implemented by any of a number of functional blocks or functional arrangements, and any functional block or arrangement can be implemented as physical entities or logical entities, or a combination thereof.

[0034] In order for those skilled in the art to better understand the present disclosure, the present disclosure will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0035] Note that the examples to be introduced next are merely specific examples, and are not intended to limit the embodiments of the present disclosure to specific shapes, hardware, connection relationships, operations, values, conditions, data, sequences, etc. shown and described. Those skilled in the art can construct more embodiments not mentioned in the present specification by reading the present specification using the concept of the present disclosure.

[0036] The terms used in the present disclosure are those general terms currently widely used in the art in consideration of the functions in the present disclosure, but these terms can vary according to the intention of those skilled in the art, precedents, or new technology in the art. Also, specific terms can be chosen by the applicant, and in this case, their detailed meanings will be described in the detailed description of the present disclosure. Therefore, the terms used in the specification should be understood not as simple names but based on the meaning of the terms and the overall description of the present disclosure.

[0037] Flowcharts are used in the present disclosure to illustrate the operations performed by the system according to embodiments of the present disclosure. It should be understood that the foregoing or following operations are not necessarily performed in sequence. Instead, various steps can be processed in reverse order or simultaneously, as needed. Meanwhile, other operations can also be added to these processes, or one or more steps of operations can be removed from these processes.

[0038] First, the abbreviations and related terms involved in the present disclosure are defined and explained.

[0039] Digital currency wallet: in form, it can be a soft wallet and a hard wallet, etc. The hard wallet refers to a physical medium for storing digital currency opened through a counter or an electronic channel, which is a digital currency carrier with a hardware security unit medium, and has the basic functions of cashing out, cashing back, storing, withdrawing, consumption, transfer, and inquiry. For example, a mobile phone with a secure element (SE), an NFC-SIM card, an IC card, and a wearable device, etc.

[0040] Hard wallet application: supports basic functions such as hard wallet opening / cancellation, online / offline payment, and balance inquiry. It has a secure authentication when performing financial operations such as transfer / consumption, and also has offline security authentication, providing services such as modifying authentication methods and resetting passwords for users.

[0041] Interconnection platform: a platform that supports the switching and clearing of digital currency / electronic payment between central banks and various operating agencies, and the exchange of messages. It realizes the interconnection between central banks and various operating agencies.

[0042] Non-contact transaction: also known as "contactless payment", a technology that can complete payment without contacting (such as card insertion transaction) terminal equipment. This technology uses wireless communication technology, such as radio frequency identification (RFID) or near field communication (NFC) or UWB or Bluetooth technology, to enable data transmission and interaction between the payment terminal and the receiving terminal.

[0043] It should be noted that in the technical solutions disclosed in the present disclosure, the collection, collection, updating, analysis, processing, use, transmission, storage, etc. of user personal information involved in the technical solutions comply with relevant laws and regulations, are used for legal purposes, and do not violate public order and good customs. Necessary measures are taken to prevent illegal access to user personal information data, and the security of user personal information, network security and national security are maintained.

[0044] In order to expand the use of the hardware wallet, facilitate user selection of the digital currency payment method of the hardware wallet, a new mode of digital currency transaction through scanning a dynamic offline payment code (hereinafter referred to as "payment code") is set in some newly opened visual hardware wallets. Then, the visual hardware wallet is required to generate a dynamic offline payment code according to the control, and in some cases, the visual hardware wallet needs to use a time factor (for example, generally refers to the reference time of the hardware wallet) when generating the dynamic offline payment code. In order to ensure the validity of the generated payment code, the time factor of the hardware wallet needs to be synchronized with the time factor of the background, but the internal clock timer of the visual hardware wallet will stop timing after the power is consumed, which will cause the hardware wallet and the background time to be out of synchronization. Even after the hardware wallet is charged, the dynamic offline payment code generated by the hardware wallet will be checked as invalid when checked by the background, resulting in transaction abnormalities and causing the transaction to be unable to proceed normally. In addition, in some scenarios, the time of the background also needs to be adjusted based on the time factor of the hardware wallet, but there is no good solution at present.

[0045] At least one embodiment of the present disclosure provides a time factor calibration method, system, electronic device and computer storage medium for digital currency transaction, which can calibrate in time when it is found that the reference time of the hardware wallet and the reference time recorded by the background are out of synchronization. For example, the front-end and back-end time factors can be automatically calibrated at the same time of payment code transaction or non-transaction, or the hardware wallet can spontaneously calibrate the time factors of the front-end and back-end in the non-transaction period, to ensure the time synchronization of the front-end and back-end, make the generated dynamic offline payment code always valid and available, and greatly reduce the occurrence of transaction abnormalities.

[0046] Figure 1 A block diagram of a time factor calibration system 100 for digital currency transaction according to at least one embodiment of the present disclosure is shown.

[0047] As shown in Figure 1 The transaction system 100 includes a visual hardware wallet 102, a receiving terminal 104, a background server 105 (for example, one example in the figure, which can include a first server 106 and a second server 110 and an interconnection platform 108).

[0048] In the embodiment of the present disclosure, the hardware wallet 102 can be an electronic device including an NFC card chip. For example, the hardware wallet 102 can be a terminal capable of supporting one or more NFC functions (NFC payment function) and having a display function, such as a mobile phone, a tablet computer, a smart watch, etc. Figure 2The visual card type hardware wallet is shown. Generally, the hardware wallet 102 can use NFC to perform payment or communication. In the case of using NFC to perform payment or communication, the built-in digital currency application, for example, the hardware wallet application, can be driven and used. In the embodiments of the present disclosure, the visual hardware wallet also supports the code scanning transaction mode, can generate a dynamic offline payment code, and display the payment code through the display module, and the terminal can complete the digital currency transaction by scanning the payment code. Since in the code scanning transaction mode, the visual hardware wallet needs to generate a payment code, and the generation of the payment code relies on the reference time stored in the hardware wallet, it is very important to ensure the synchronization of the reference time of the hardware wallet and the reference time of the hardware wallet recorded by the background server. If they are not synchronized, the payment code cannot pass the verification of the background server, resulting in a failed transaction.

[0049] Figure 2 A block diagram of an exemplary digital currency hardware wallet according to at least one embodiment of the present disclosure is shown. As shown in Figure 2 The hardware wallet 102 is a visual card, which includes a security unit 1021, a power module 1023, a display module 1022, an input element 1024, a controller 1025, and a communication module 1026.

[0050] For example, the security unit 1021 includes a hard wallet application 1021A and a data storage area 1021B. The hard wallet application 1021A is mainly responsible for the management of digital currency payment behavior, and its functions include: reading and writing of account personalized information, wallet management, wallet transaction, and wallet query functions. The data storage area 1021B stores: wallet SEID, wallet ID, wallet control information, wallet transaction related information, key and certificate information. Among them, the wallet ID can be a real wallet account ID or an associated code of the wallet account. The associated code is one-to-one corresponding to the wallet account to ensure the security of the wallet data. In addition, the key and authentication information include symmetric key, asymmetric key, and institution certificate. When the wallet is initialized (i.e., the wallet is opened), the symmetric key, asymmetric key, and institution certificate are issued by the wallet issuer to the hard wallet, and the above data is written into the data storage area 1021B of the security unit 1021. The communication module 1026 is mainly connected with the receiving terminal 104, and the communication method it follows can be Bluetooth, near-field NFC radio frequency, WIFI, UWB, and mobile network, etc. The display module 1022 can be a visual device specially equipped for the hardware wallet, or a visual device (such as a mobile phone screen, a tablet computer screen, etc.) possessed by the medium serving as the carrier of the hardware wallet application. The visual device can be in the form of a screen, such as an electronic screen (such as a segment code screen, a dot matrix screen, etc.), an ink screen, etc. The input element 1024 can include components such as touch screens or keypads to accept user-triggered input operations, such as the operation of displaying the payment code by pressing the switch component. The power module 1023 can power the hard wallet 102, which can be a lithium-ion battery or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. The controller 1025 mainly generates a dynamic offline payment code according to user operations, specifically according to the key in the data storage area 1021B and the hard wallet reference time to generate the payment code. In addition, the controller 1025 can also call the display interface to display the payment code and transaction amount / balance information on the display module 1022. A timer (not shown) is provided inside or independently of the controller 1025. When the hard wallet 102 is in a powered state, the timer will continue to count, so as to ensure that the reference time of the hard wallet and the reference time of the background server are basically consistent. However, when the hard wallet 102 is in a non-powered state, the timer will stop counting, which will cause the reference time after charging to be different from the reference time of the background server, and the payment code generated will be invalid when checked at the background server end, and the transaction cannot be successfully performed.

[0051] For example, the acceptance terminal 104 can be a terminal device that accepts DC / EP transactions, such as a point-of-sale (POS) terminal or a mobile terminal capable of transacting with a hard wallet. DC / EP refers to digital currency / electronic payment, a technological ecosystem used to support the operation of the digital yuan. Besides accepting DC / EP transactions, the acceptance terminal 104 can also accept other electronic payment transactions. The acceptance terminal 104 can adjust the transaction mode according to user settings or the counterparty's situation. In this embodiment, the acceptance terminal 104 can communicate with the hard wallet 102 in a contactless manner via NFC. Using NFC, the acceptance terminal 104 can perform the following functions with the hard wallet 102: contactless mobile payment, security authentication, and data exchange. Furthermore, the acceptance terminal 104 also includes sensors (such as a camera and / or a vision sensor) to scan the payment code generated by the hard wallet 102 and send it to the backend server 105 for processing to complete the digital currency transaction.

[0052] For example, messages between the receiving terminal 104 and the backend server 105 can be sent over a communication network using a secure communication protocol, such as, but not limited to, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Secure Hypertext Transfer Protocol (HTTPS). The communication network can include any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), a secure custom connection, a wide area network (WAN), a wireless network, etc.

[0053] In this embodiment, the backend server 105 is a backend system supporting digital currency payment functions. It may include a backend server for the payment and collection operation institution and an interconnection platform, supporting digital currency transactions within the institution and across institutions. The backend server 105 may be conventional in terms of hardware, but it may be controlled by software to cause it to perform the operations described below. For example, the backend server 105 may be composed of server computer hardware, the specifics of which will not be elaborated further.

[0054] like Figure 1 As shown, in most cases, the backend server 105 may include a first server (accepting institution backend) 106 and a second server (payment institution backend) 110, both of which can process digital currency transactions within the institution and generate echo instructions. To facilitate information exchange among multiple operating institutions, in this embodiment, the backend server also includes an interconnecting system or server (such as...) that communicates with the systems or servers corresponding to each operating institution. Figure 1 Interoperability platform 108 in China.

[0055] For example, in the embodiments of the present disclosure, when a digital currency transaction is performed according to the payer institution identifier, the payee institution identifier and the transaction amount in the transaction information, if the operation institutions corresponding to the payer institution identifier and the payee institution identifier belong to the same operation institution, the transaction is performed as an intra-institution transaction; if the operation institutions corresponding to the payer institution identifier and the payee institution identifier do not belong to the same operation institution, a transaction request is sent through the interconnection platform, and a cross-institution transaction is performed.

[0056] In addition to the above, an issuer (not shown) is also involved. When issuing certain hard wallets, the issuer should write user information (including, for example, a key for generating a payment code), capability identification and supportable application scenarios, etc. into the hard wallets according to the scene requirements, so that the hard wallets have personalized configurations.

[0057] Figure 3 A flowchart of a time factor calibration method 300 for a digital currency transaction according to at least one embodiment of the present disclosure is shown, which is used for Figure 1 The calibration of the time factor in the system shown. For example, the method 300 includes the following steps S310-S314.

[0058] In step S310, the receiving terminal 104 receives authorization information for calibrating the time factor from the hard wallet 102 in the interaction.

[0059] In step S312, the receiving terminal 104 sends the authorization information to the background server 105 if it is confirmed that the authorization information is trustworthy.

[0060] In step S314, the receiving terminal 104 forwards the time factor calibration instruction received from the background server 105 to the hard wallet 102 to make the hard wallet 102 perform the time factor calibration operation, or receives the processing result of the background server 105 performing the time factor calibration operation from the background server 105.

[0061] For example, in step S310, the hard wallet 102 can send the authorization information in response to the digital currency transaction initiated by the receiving terminal 104, to complete the calibration of the time while the transaction is being processed; or the hard wallet 102 can initiate by itself, for example, to query information such as card sticking with the receiving terminal. In a non-contact transaction for example, the hard wallet 102 can complete the calibration of the hard wallet reference time on the hard wallet side and / or the calibration of the hard wallet reference time on the background server side in the process of performing the transaction. In the case of self-initiation, the hard wallet 102 can calibrate the time factor on the hard wallet side or the background server side by querying the information such as the balance information in the form of card sticking query information after establishing communication with the receiving terminal 104, or directly sending the authorization information to the receiving terminal 104 after establishing communication interaction with the receiving terminal 104, which is not limited in the embodiments of the present disclosure. The receiving terminal 104 can send a time calibration authorization information request instruction to the hard wallet 102 after establishing communication with the hard wallet, and the hard wallet 102 returns the authorization information after receiving the instruction. In other examples, the hard wallet 102 can also return the content containing the authorization information to the receiving terminal 104 in response to the information query instruction or the transaction instruction sent by the receiving terminal 104.

[0062] For example, in one example, the authorization information can include the hard wallet identifier, the key dispersion factor (such as the counter), the terminal check value (such as the random number generated by the terminal), the receiving terminal identifier, the first instruction identifier, and the background check value. The first instruction identifier can represent a request for the background server to issue a time factor calibration instruction to calibrate the hard wallet reference time stored on the hard wallet side. The purpose of the hard wallet sending such an instruction identifier is mainly to request the background server to synchronize the reference time on the hard wallet side according to the hard wallet reference time stored by the background server, in case that the reference time on the hard wallet side is inconsistent with the hard wallet reference time stored by the background server due to power failure or the like. The background server 105 confirms that the authorization information is trustworthy, and then executes the operation of generating the time factor calibration instruction according to the first instruction identifier of the authorization information.

[0063] For example, in another example, the authorization information can include the hard wallet identifier, the key dispersion factor (such as the counter), the terminal check value (such as the random number generated by the terminal), the terminal identifier, the time of the receiving terminal (referred to as terminal time), the second instruction identifier, the hard wallet reference time, and the background check value. The second instruction identifier can represent an instruction for the background server to calibrate the locally stored hard wallet reference time. The background server 105 confirms that the authorization information is trustworthy, and then executes the time factor calibration operation according to the second instruction identifier of the authorization information.

[0064] For "the authorization information is trustworthy", it can be understood that the authorization information is verified to confirm that the information has security and integrity, and to ensure that the information is not tampered with or damaged during transmission or storage. For example, MAC value verification, information value (such as random number) comparison verification, and the like can be used for verification, and the specific method is not limited.

[0065] For example, in step S312, the receiving terminal 104 can confirm whether the authorization information is trustworthy by verifying the terminal verification value. The terminal verification value can be a terminal random number carried by the receiving terminal 104 when sending the authorization information request instruction to the hardware wallet 104. When the receiving terminal 104 confirms whether the terminal verification value is valid, it only needs to determine whether the terminal random number in the authorization information and the terminal random number stored by the receiving terminal 104 are consistent. If they are consistent, it is confirmed that the terminal verification value is valid, and then the receiving terminal 104 can determine that the authorization information is trustworthy. Of course, in addition to the above method, other verification methods can also be used, for example, the terminal verification value can also be a MAC value, and the receiving terminal 104 can confirm the validity by comparing the calculated MAC value with the terminal verification value. By performing step S312, the receiving terminal can confirm the reliability and security of the authorization information sent by the hardware wallet, effectively prevent security problems caused by tampering or damage of information, and ensure that information security problems in the first link of transmitting authorization information (information transmission from the hardware wallet to the receiving terminal) are discovered in time.

[0066] For example, in at least one embodiment of the present disclosure, in the method 300, the background server 105 can verify the background verification value (such as the MAC value) according to the hardware wallet identifier and the key dispersion factor, so as to confirm whether the authorization information is trustworthy. In this example, the background server 105 uses the MAC value verification method to compare whether the calculated MAC value and the MAC value in the authorization information are consistent. The specific steps include: obtaining the corresponding hardware wallet key according to the hardware wallet identifier; dispersing the hardware wallet key to obtain an authentication key by using the key dispersion factor, and calculating a verification value from the information in the authorization information except the background verification value by using the authentication key; comparing the calculated verification value with the background verification value, and if they are consistent, it is determined that the background verification value is valid, thereby confirming that the authorization information is trustworthy. Based on this, the background server can confirm the reliability and security of the authorization information sent by the receiving terminal, and effectively prevent security problems caused by tampering or damage of information in the second link of transmitting authorization information (information transmission from the receiving terminal to the background).

[0067] For example, in at least one embodiment of the present disclosure, in the method 300, the authorization information includes a first instruction identifier, which means that when the background server 105 issues a time factor calibration instruction, the background server 105 generates a time factor calibration instruction containing a time factor and a hard wallet verification value in response to the first instruction identifier, and sends the time factor calibration instruction to the receiving terminal corresponding to the terminal identifier; then, the receiving terminal 104 sends the time factor calibration instruction to the hard wallet 102; the hard wallet 102 confirms that the hard wallet verification value is valid, and then performs a time factor calibration operation according to the time factor calibration instruction. In this process, after the hard wallet 102 receives the time factor calibration instruction, the hard wallet verification value, such as the MAC value, is extracted from the instruction, and the validity of the hard wallet verification value is determined by comparing the calculated MAC value with the extracted MAC value from the instruction, so as to confirm the trustworthiness of the instruction and ensure that the instruction forwarded by the receiving terminal 104 is trustworthy, and then the subsequent time factor calibration operation is performed. In this example, since the information verification is performed in the last link, the receiving terminal 104 generally does not need to perform the trustworthiness verification of the information, and of course the verification link can also be set according to the needs.

[0068] For example, in at least one embodiment of the present disclosure, the step of performing a time factor calibration operation by the hard wallet according to the time factor calibration instruction includes a time difference judgment step: judging whether the time difference between the time factor in the time factor calibration instruction and the current hard wallet reference time of the hard wallet is greater than at least one set time step, and if the judgment result is greater than at least one set time step, the hard wallet reference time is updated to the time factor. In one example, the time step can be set to 60 seconds, and the purpose of such setting is to frequently update the time if the time difference does not meet at least one step, which will affect the storage life of the hard wallet. Moreover, in this case, although the reference time stored in the background and the reference time of the hard wallet are not completely consistent, it does not affect the validity of the generated payment code. Of course, if the storage life is not considered, the time difference judgment step can also be omitted, and the current hard wallet reference time of the hard wallet 102 is directly updated to the time factor in the time factor calibration instruction.

[0069] In this embodiment, the "hard wallet reference time" generally refers to UTC (Coordinated Universal Time) time, and can also be other time, such as the starting timing time agreed in advance by the front end and the back end, which is not limited in the present disclosure.

[0070] For example, in at least one embodiment of the present disclosure, in the method 300, when the terminal 104 receives the time factor calibration instruction, it further judges whether the hard wallet 102 is in communication interaction with the terminal 104, and if the communication is abnormal, a second prompt information is sent to prompt the user to keep the hard wallet 102 and the terminal 104 in communication. In order to realize the synchronization of the hard wallet reference time, in the case of communication disconnection, for example, the hard wallet 102 is not in the range of effective communication with the terminal 104, the terminal 104 prompts the user to re-establish the communication connection between the hard wallet 102 and the terminal 104, for example, to re-paste the card, until the instruction is executed or timeout. In the case of timeout, the user is prompted to perform a new round of time factor operation.

[0071] For example, in at least one embodiment of the present disclosure, in the method 300, before the hard wallet performs the time factor calibration operation according to the time factor calibration instruction, it further includes: judging whether the time difference between the time of sending the authorization information to the terminal and the current hard wallet reference time of the hard wallet is less than the first set time range, and if the result of the judgment is less than the first set time range, the time factor calibration operation is performed. When the hard wallet receives the instruction to return the authorization information, the local time of the current hard wallet is recorded at the same time of generating the authorization information; when the hard wallet receives the time factor calibration instruction, it judges whether the current local time of the hard wallet and the local time recorded when the authorization information is returned are too different, if they are too different, the update cannot be performed, because of the delay of information transmission, if the update is performed, the time synchronization between the hard wallet and the background cannot be guaranteed. The first set time range can be set as needed, for example, 10 seconds, which is not limited in the present disclosure.

[0072] For example, in at least one embodiment of the present disclosure, in the method 300, if the hard wallet is to send the authorization information in response to the digital currency transaction instruction sent by the receiving terminal 104, the hard wallet 102 further judges whether the time difference between receiving the time factor calibration instruction and receiving the digital currency transaction instruction is less than a second set time range after receiving the time factor calibration instruction; when the judgment result is less than the second set time range, the hard wallet 102 further performs the above-mentioned time difference judgment step, that is, judges whether the time difference between the time factor in the time factor calibration instruction and the current hard wallet reference time of the hard wallet is greater than at least one set time step, and if the judgment result is greater than at least one set time step, the hard wallet reference time is updated to the time factor. In one example, after the hard wallet 102 receives the echo instruction and the time factor calibration instruction returned by the receiving terminal 104 after executing the transaction processing, the trustworthiness of the instruction can be verified first, and then it is judged whether the time difference between receiving the digital currency transaction instruction sent by the receiving terminal 104 and the time factor calibration instruction is within a set time range of, for example, 10 seconds, so as to control the difference between the updated hard wallet reference time in the background instruction and the reference time in the hard wallet within 10 seconds as much as possible. If it is determined to be satisfied, it is judged that the time difference between the background transmission time and the current hard wallet reference time is at least one fault tolerance step (for example, 60 seconds), and if it exceeds, the reference time of the hard wallet is updated, and if it does not exceed, the time does not need to be changed. In this way, the situation that the payment code background verification is invalid due to the continuous accumulation of the hard wallet timer offset being too large is reduced.

[0073] For example, in at least one embodiment of the present disclosure, in the method 300, further comprising: the receiving terminal 104 scans the payment code provided by the hard wallet 102 to obtain code information, and sends it to the background server 105; the background server 105 confirms whether the code information is valid, and if it is invalid, sends the first prompt information to the receiving terminal 104 to prompt the user to perform the corresponding operation, so that the hard wallet and the receiving terminal 104 interact to send the authorization information to the receiving terminal 104. Specifically, if the code information is invalid, the background server 105 will send the first prompt information such as "please stick the card for inquiry" or "please stick the card for transaction" to the receiving terminal 104, then the user will stick the hard wallet 102 close to the receiving terminal 104, so that the hard wallet 102 and the receiving terminal 104 establish near field communication, and the hard wallet 102 sends the authorization information of the calibration time factor to the receiving terminal 104 in response to the request instruction, the inquiry instruction or the transaction instruction of the receiving terminal 104.

[0074] The present embodiment is applied to a scenario of digital currency transaction by scanning a payment code, which is a visual code generated by the controller 1025 of the hardware wallet 102 according to a control signal generated by the user triggering the input element 1024. In an example, the controller 1025 calls the key issued at the time of opening from the data storage area 1021B, generates an offline payment code through the key, the operation factor (such as account index, random number) and the hardware wallet reference time, and the payment code includes code information including the institution identifier, the code type, the user index and the check code. In an example, the payment code can be a quick response QR code, and the hardware wallet 102 sends the payment code to the display module 1022 to provide the receiving terminal 104 for scanning, the receiving terminal 104 safely scans or captures the displayed payment code through, for example, a camera, and then the receiving terminal 104 obtains the code information from the payment code.

[0075] For example, in at least one embodiment of the present disclosure, in the method 300, the background server 105 performs at least one of the following verifications on the code information, and if the judgment result is no, it is determined that the code information is invalid: (1) judging whether the receiving time of the code information meets the set time range; (2) judging whether the institution identifier of the code information meets the requirement; (3) verifying whether the check code in the code information is valid. By verifying item (1), it can be judged whether the time of receiving the code information is within the set fault tolerance time, for example, within 60 seconds, and if it exceeds, it is considered that the receiving code information time is overdue, the code information is invalid, and the transaction is rejected; in an example, the code information includes the institution identifier, the code type, the user index and the check code, and by verifying item (2), the belonging operation institution of the hardware wallet can be confirmed according to the institution identifier, and when it is determined that the institution or the corresponding code number meets the corresponding institution identifier, it is considered that the code information is valid, otherwise, the transaction is rejected; by verifying item (3), it is mainly judged whether the payment code generated by the hardware wallet is valid, which indirectly reflects whether the reference time of the hardware wallet is consistent with the background stored hardware wallet reference time, and the specific verification method will be described later. For the three verifications, at least one of them can be selected to be executed, and as long as one of them does not meet the requirement, it is determined that the code information is invalid, and the following transaction processing is rejected. In addition, it can also be judged whether the code type is an offline code or an online code, and in the code scanning transaction of the present embodiment, it is considered that the offline code meets the requirement, and if it is not an offline code, the execution flow of the online code is entered.

[0076] For example, in at least one embodiment of the present disclosure, in the method 300, in the step of verifying whether the check code in the code information is valid, the account index is determined from the code information, the corresponding hardware wallet data is searched according to the account index, the first expected time of generating the payment code is calculated according to the hardware wallet data, and the first check code is calculated based on the first expected time; whether the check code in the code information is consistent with the first check code calculated is verified, and if it is consistent, it is determined that the check code is valid.

[0077] The hard wallet data for different hard wallets is stored in the background server 105, and the data is found by a hard wallet account index, and the hard wallet data at least contains information such as a key, a payment code calculation factor, a hard wallet reference time, a time stamp recording the hard wallet reference time. For example, in at least one embodiment of the present disclosure, the background server 105 obtains a first predicted time based on the hard wallet reference time stored by the background server, the current time of the background server, and the recording time of the recording hard wallet reference time. The first predicted time is the time when the currently received payment code is generated at the hard wallet end, and then the first predicted time and the operation factor obtained by calculation are processed using the key in the hard wallet data to obtain a first check code. The first check code and the check code in the code information are compared to determine whether the check code is valid. If it is valid, the transaction processing is performed, and it is indicated that the reference time of the hard wallet end and the reference time of the background server end are consistent, and the digital currency transaction is performed, and the time factor calibration operation is not triggered.

[0078] For example, in at least one embodiment of the present disclosure, in the method 300, if the check code in the code information is inconsistent with the first check code obtained by calculation, the following steps are performed: processing the first predicted time based on a set time step to obtain a second predicted time, and calculating a second check code based on the second predicted time; whether the check code in the check code information is consistent with the second check code obtained by calculation, if consistent, it is confirmed that the check code is valid.

[0079] In this example, considering the delay in information transmission, a fault tolerance step time is set, for example, a time step of 60 seconds can be set as the fault tolerance step time, when the first check code calculated by the first predicted time is different from the check code in the code information, the first predicted time is added or subtracted by the set time step (such as 60 seconds) to obtain the second predicted time, and then the consistency of the second check code calculated by the second predicted time and the check code in the code information is compared. If consistent, the check passes; if it still does not pass, the first predicted time is added or subtracted by 2 times the set step time (120 seconds) to obtain a new second predicted time, and a new second check code is calculated by using the new second predicted time. If the new second check code is consistent with the check code in the code information, it is judged that the check passes, and the transaction processing is performed. Of course, the set step time can be adjusted as needed, and in addition to the above example of processing the first predicted time twice, the number of processing times can be increased as needed, which is not limited in the present embodiment.

[0080] For example, taking the first estimated time 2024-05-15 14:33:46 as an example, the converted current calculation time is 1715754826 seconds, divided by the step size 60 seconds to get 28595913 minutes, and plus or minus one step size to get 28595914 minutes and 28595912 minutes, and plus or minus two step sizes to get 28595915 minutes and 28595911 minutes. First, calculate the check value using 28595913 minutes, then compare, if not consistent, then calculate the check value using 28595914 minutes and 28595912 minutes respectively, if not consistent, then calculate the check value using 28595915 minutes and 28595911 minutes.

[0081] For example, in at least one embodiment of the disclosure, in the method 300, the background server 105 also updates the hard wallet reference time recorded by the background server 105 to the time when the check code is confirmed to be valid. In this example, if the check is passed, and there is a step size deviation between the hard wallet reference time recorded by the background and the reference time of the wallet end, that is, the check is passed by adding or subtracting the set step size time from the first estimated time, then adjust the hard wallet reference time recorded by the background to the time when the check is passed, such as the check code in the check code information based on the first estimated time (or the second estimated time) check is passed, the hard wallet reference time recorded by the background is updated to the first estimated time (or the second estimated time). In this way, the reference times of the background and the hard wallet can be guaranteed to be synchronized, and there is no need to separately trigger the calibration operation of the reference time of the background.

[0082] For example, in at least one embodiment of the disclosure, in the method 300, the authorization information includes a second instruction identifier, a time of the receiving terminal, and a hard wallet reference time, the second instruction identifier representing an instruction to calibrate the hard wallet reference time of the background server 105; the background server 105 calculates a time factor to be calibrated according to the time of the receiving terminal, the hard wallet reference time, and the current time of the background server 105 in response to the second instruction identifier, updates the hard wallet reference time stored by the background server 105 using the time factor to be calibrated, and sends a processing result of the time factor calibration operation to the receiving terminal 104 corresponding to the terminal identifier. In this example, in addition to synchronously performing time calibration in the transaction, the hard wallet 102 can also initiate a time factor calibration of the background server 105, the background server 105 calculates a time value by the terminal time, the hard wallet reference time, and the current time of the background server 105, adjusts the stored hard wallet reference time to the calculated time value, completes the time factor calibration operation of the background end, and then sends the processing result information to the receiving terminal 104 to enable the hard wallet user to understand the execution result of the background.

[0083] In summary, the time factor calibration scheme for digital currency transaction in the embodiments of the present disclosure can ensure the time synchronization of the hard wallet and the background server, and thus the dynamic offline payment code generated based on the time factor remains valid. Moreover, in the calibration process, the security of information transmission is ensured by verifying the trustworthiness of the information, thereby preventing problems caused by malicious tampering or data loss.

[0084] To better understand the embodiments of the present disclosure, four scenarios are given below to further illustrate the technical solutions of the embodiments of the present disclosure.

[0085] <Scenario One>

[0086] Figure 4 A flowchart of a time factor calibration method for digital currency transaction according to Example One of at least one embodiment of the present disclosure is shown. In this example, the hard wallet self-checks the locally stored hard wallet reference time, which involves the interaction of the visual hard wallet 102, the receiving terminal 104 and the background server 105. The following describes each step with reference to Figure 4 .

[0087] S401: The hard wallet 102 calibrates the time factor at the hard wallet end by querying information through card swiping, the receiving terminal 104 and the visual hard wallet 102 establish a communication connection, and both select the hard wallet application of the other party.

[0088] S402: The receiving terminal 104 generates a terminal random number and saves it in the local storage.

[0089] S403: The receiving terminal 104 sends an authorization information request instruction to the visual hard wallet 102, which can include the terminal random number and the terminal identifier.

[0090] S404: After receiving the request instruction, the hard wallet 102 increases the value of the counter, uses the new counter value to disperse the hard wallet key generation process key, and uses the process key to calculate the MAC value of the set information, which includes the hard wallet identifier, the counter value, the terminal random number, the terminal identifier and the identifier representing the instruction to be issued (generally the first instruction identifier).

[0091] S405: The hard wallet 102 sends authorization information to the receiving terminal 104, which includes the hard wallet identifier, the counter value, the terminal random number, the terminal identifier, the identifier representing the instruction to be issued and the MAC value calculated based on the above information.

[0092] S406: After receiving the authorization information, the receiving terminal 104 checks the terminal random number in the authorization information, and judges whether the terminal random number in the authorization information is consistent with the terminal random number stored in the local storage. If they are consistent, the check is passed, and S407 is executed, otherwise, an error message is displayed.

[0093] S407: The terminal 104 sends the authorization information to the background server 105.

[0094] S408: The background server 105 checks the MAC value in the authorization information. After the check is passed, it is identified that the instruction to be issued is a time factor calibration instruction, and then an issued instruction with a time factor (a hard wallet reference time stored in the background) and a MAC value is organized and generated, and then it is issued to the corresponding terminal 104 according to the terminal identification.

[0095] S409: The background server 105 requests the response of the terminal 104, that is, requests to return the authorization result and the APDU instruction for calibrating the hard wallet time.

[0096] S410: The terminal 104 judges whether the hard wallet 102 maintains normal communication. If the communication has been disconnected, the user is prompted to reattach the card until the instruction execution is completed or the communication connection is disconnected again after the timeout.

[0097] S411: The terminal 104 sends the time calibration instruction to the hard wallet 102.

[0098] S412: After the hard wallet 102 receives the time calibration instruction, the process key is dispersed according to the current counter value, and the MAC value is calculated for the time factor using the process key. The calculated MAC value is checked with the MAC value in the instruction. If they are consistent, the check is passed. After the MAC check is passed, the reference time of the hard wallet is updated to the time factor in the instruction. Or after the MAC check is passed, it is further judged whether the time in the time calibration instruction and the current visual hard wallet reference time exceed the fault tolerance step time (such as 1 minute). If they exceed, the time is updated. If they do not exceed, the time does not need to be changed.

[0099] S413: The hard wallet 102 returns the instruction execution result to the terminal 104.

[0100] S414: The terminal 104 sends the instruction execution result to the background server 105. According to the execution result, it is confirmed that the update is successful, and then the original hard wallet reference time can be no longer reserved.

[0101] Through the above steps, the calibration of the reference time of the hard wallet end is completed.

[0102] <Scenario two>

[0103] Figure 5A flow chart of a time factor calibration method for digital currency transaction according to Example Two of at least one embodiment of the present disclosure is shown. In this example, the hard wallet spontaneously checks the hard wallet reference time stored in the background, which involves the interaction of the visual hard wallet 102, the receiving terminal 104 and the background server 105. The following describes each step. Figure 5

[0104] S401-S402, S406, S407 are similar to Scene One, and will not be described here.

[0105] S403': the receiving terminal 104 sends an authorization information request instruction to the visual hard wallet 102, which can include a terminal random number, a terminal identifier and a terminal time.

[0106] S504: after receiving the request instruction, the hard wallet 102 increases the value of the counter, uses the new counter value to disperse the hard wallet key generation process key, and uses the process key to calculate the MAC value of the setting information, which includes the hard wallet identifier, the counter value, the terminal random number, the terminal identifier, the terminal time, the instruction identifier of the calibration background time factor (generally the second instruction identifier), and the hard wallet reference time.

[0107] S505: the hard wallet 102 sends authorization information to the receiving terminal 104, which includes the hard wallet identifier, the counter value, the terminal random number, the terminal identifier, the terminal time, the instruction identifier of the calibration background time factor, the hard wallet reference time and the MAC value calculated based on the above information.

[0108] S508: the background server 105 checks the MAC value in the authorization information. After the check is passed, it is identified that the instruction identifier is the calibration background server time factor, and then the calibration time T is calculated according to the terminal time T T , the hard wallet reference time T w and the background current time T b (For example, T = T b -T T +T w ) and saved for use, and the time factor calibration of the background end is completed, and then the calibration processing result is issued to the corresponding receiving terminal 104 according to the terminal identifier.

[0109] S509: the background server 105 requests a response from the receiving terminal 104.

[0110] S510: the receiving terminal 104 receives the calibration processing result and displays the synchronization result to prompt the user.

[0111] Through the above steps, the calibration of the reference time of the background server end is completed.

[0112] ​<Scenario Three>

[0113] Figure 6 An operation flow chart of the time factor calibration method in the payment code transaction scenario of Example Three according to at least one embodiment of the present disclosure is shown. In this example, the time factor calibration is performed while the digital currency transaction is performed by scanning the payment code, which involves the interaction of the hard wallet 102, the receiving terminal 104, and the background server 105. The following describes each step with reference to Figure 6 .

[0114] S601: The receiving terminal 104 scans the payment code displayed by the visual hard wallet 102 to obtain the corresponding code information.

[0115] Specifically, the hard wallet 102 generates an offline payment code in advance using the current local UTC time and key information, and in the transaction, the user scans the payment code through the camera of the receiving terminal 104 to obtain the corresponding payment code information. The receiving terminal 104 initiates a collection request using the payment code information obtained by scanning.

[0116] S603: The receiving terminal 104 sends the transaction information (which contains the code information) to the background of the receiving institution.

[0117] The background of the receiving institution identifies the payment institution according to the institution identifier in the payment code information, i.e., determines that this transaction is a non-institution transaction, and then forwards it to the background of the payment institution through the interconnection platform. In this example, for convenience of description, it is assumed that this transaction is an internal transaction of the institution, and the subsequent processing is directly performed by the background server 105.

[0118] S605: The background server 105 checks the correctness of the payment code based on the code information, and if the check passes and there is a step deviation, updates the reference time of the background and performs transaction processing, and if the check fails, returns an error code to the receiving terminal 104 and rejects the transaction.

[0119] Specifically, the background server 105 first determines whether the message (containing code information and transaction information) is sent within 60s, and if not, rejects the transaction; if so, performs the following operations to verify the payment code as follows:

[0120] (1) Check whether the institution identifier in the payment code is correct;

[0121] (2) Determine whether it is an online code or an offline code according to the code type;

[0122] (3) If it is determined to be an offline code, first derive the account index according to the payment code, then find the corresponding hard wallet data based on the account index, and according to the hard wallet data and the time T QRThe verification code information is calculated, and then compared with the verification code information in the payment code.

[0123] If the comparison fails, the estimated time T for generating the payment code will be adjusted according to the specified step size (e.g., 60 seconds). QR After adding or subtracting 60 seconds before and after, calculate the verification code again, and then compare it with the verification code information in the payment code; if the comparison still fails, use T. QR The new verification code is calculated by adding or subtracting 120 seconds before and after, and then compared with the verification code information in the payment code. If the verification passes and there is a step size deviation, that is, the verification passes by adding or subtracting 60 seconds or 120 seconds, the base time corresponding to the hardware wallet recorded in the background is adjusted to the time when the verification code passes.

[0124] The timestamp (estimated time of payment code generation) T corresponding to the payment code is calculated using the following expression. QR :

[0125] T QR =T W_UTC +(T b -T r_UTC )

[0126] T W_UTC This indicates the base UTC time of the hard wallet (recorded in the background); T b Indicates the current timestamp in the background; T r_UTC This indicates the timestamp at the time when the baseline UTC time was recorded.

[0127] S607: Backend server 105 returns transaction results.

[0128] S608: The acceptance terminal 104 judges the transaction result. If successful, it prompts the user that the transaction is successful. If it fails, that is, all time window verifications in the institution's backend fail, it generates an instruction to prompt the user to tack the card to query the synchronization time based on the time factor in the backend, or the user can tack the card in the management App of the acceptance terminal (including mobile terminal) to conduct a transaction with a delivery instruction. The time factor to be calibrated is present in the delivery instruction.

[0129] See below for details. Figure 6 The S61 operation process within the dashed box—synchronizing the hardware wallet base time after payment code verification failure—includes the following steps:

[0130] S611: When the hardware wallet 102 approaches the contactless card recognition area of ​​the acceptance terminal 104, the acceptance terminal 104 sends an application selection command after successfully finding the card, and selects the hardware wallet application.

[0131] S612: The receiving terminal 104 generates a terminal random number and saves it locally.

[0132] S613: The terminal 104 sends a transaction instruction to the hardware wallet 102, and the instruction contains the terminal random number.

[0133] S614: After receiving the transaction instruction, the hardware wallet 102 increases the counter value, disperses the process key, calculates the MAC value of the set information using the process key, and the set information includes the hardware wallet identifier, the counter, the terminal random number, the terminal identifier, and the identifier representing the instruction to be issued.

[0134] S615: The hardware wallet 102 sends the hardware wallet authorization information to the terminal 104, which can include the hardware wallet identifier, the counter, the terminal random number, the terminal identifier, the identifier representing the instruction to be issued, and the MAC value calculated based on the above information. The hardware wallet 102 also records the local UTC timestamp.

[0135] S616, the terminal 104 checks whether the terminal random number is valid, and if it is valid, it executes step S617.

[0136] S617: The terminal 104 sends transaction information to the terminal 104, and the terminal 104 identifies the hardware wallet operator according to the hardware wallet identifier, and forwards the transaction information to the operator server 105 through interconnection, and the transaction information contains the authorization information.

[0137] S618, the operator server 105 finds the corresponding wallet data and key according to the wallet identifier, and obtains the process key according to the counter in the authorization information, and calculates the MAC using the process key, and identifies the instruction to be issued after the MAC verification is passed, and the operator organizes the APDU instruction to be issued, and the instruction content can include the current UTC timestamp (in seconds) of the background, the echo information and the MAC value, and is forwarded to the terminal 104 through interconnection.

[0138] S619: The terminal 104 sends the request response to the terminal 104, and the terminal 104 parses the APDU instruction in the message.

[0139] S6110: Before or during sending the instruction, there may be a card breakage exception, so it is necessary to determine whether the hardware wallet 102 maintains communication with the terminal 104, and if communication abnormalities occur, the user needs to be reminded to reattach the card.

[0140] S6111: The terminal 104 sends the instruction to the hardware wallet 102.

[0141] S6112: The hard wallet disperses the process key according to the current counter, calculates the MAC, and checks the correctness of the MAC in the instruction. If correct, it checks whether the difference between the recorded time stamp and the current local time stamp is within the set time (e.g., 10s). If so, the internal time factor is updated to the time factor in the message. Alternatively, after the MAC check passes, it is further judged whether the time in the time calibration instruction and the reference time of the current visual hard wallet exceed the fault tolerance step time (e.g., 1 minute). If so, the time is updated. If not, the time does not need to be changed.

[0142] <Scenario Four>

[0143] In this example, the time factor calibration is performed while the digital currency transaction is performed in a non-contact manner, mainly including the following steps.

[0144] Step one: The visual hard wallet 102 initiates a tap-to-tap transaction to the receiving terminal 104, and the two establish a communication connection and select the hard wallet application with each other. The receiving terminal 104 sends the transaction information to the background of the receiving institution.

[0145] Step two: The background (e.g., the first server) of the receiving institution identifies the payment institution according to the payment information. If it is a transaction of another institution, it can be forwarded to the background (e.g., the second server) of the payment institution through the interconnection platform.

[0146] Step three: The background of the payment institution verifies the transaction information. If the verification is passed and the payment is successful, and the payment terminal is identified as a visual hard wallet, the balance echoing operation is performed and the current time factor is returned. When returning the echoing instruction and the time factor, the above information is encrypted and integrity-protected through a key before being sent to the receiving terminal 104.

[0147] Step four: After the visual hard wallet 102 receives the echoing instruction and the time factor returned by the receiving terminal 104, it first performs key and integrity verification. If passed, it first judges whether the transmission time of the instruction (the time difference between receiving the transaction instruction and receiving the echoing instruction and the time factor) is within the set time (e.g., 10s). If passed, it further judges whether the time delivered by the background of the payment institution and the reference time of the current visual hard wallet exceed the fault tolerance step time (e.g., 1 minute). If so, the time is updated. If not, the time does not need to be changed. Of course, the reference information of the hard wallet can also be directly updated to the time factor.

[0148] It should be noted that the above application scenario is only exemplary, so as to describe one or more aspects of the present disclosure in a specific scenario, but these aspects are not necessarily required, and various modifications can be made to the application scenario, and the embodiments of the present disclosure are not limited.

[0149] For example, the disclosure also provides at least one embodiment of a time factor calibration system for digital currency transaction. As shown in Figure 1 The system includes a hardware wallet 102, a receiving terminal 104 and a background server 105.

[0150] For example, the hardware wallet 102 is configured to send authorization information for calibrating a time factor to the receiving terminal 104, and receive a time factor calibration instruction from the receiving terminal 104 to perform a time factor calibration operation.

[0151] For example, the receiving terminal 104 is configured to receive authorization information for calibrating a time factor from the hardware wallet 102 in the interaction; send the authorization information to the background server 105 if it is confirmed that the authorization information is trustworthy; forward the time factor calibration instruction received from the background server 105 to the hardware wallet 102, or receive the processing result of the background server 105 performing the time factor calibration operation from the background server.

[0152] For example, the background server 105 is configured to perform the operation of generating a time factor calibration instruction or perform a time factor calibration operation according to the authorization information if it is confirmed that the authorization information is trustworthy.

[0153] Since the details of the content involved in the operation of the above-mentioned time factor calibration system 100 have been introduced in the process of the time factor calibration method for digital currency transaction and the four application scenarios described above, for the sake of brevity, the relevant details will not be described here, and the relevant details can be referred to the description of the method above. Figure 3

[0154] The disclosure also provides at least one embodiment of an electronic device. Figure 7 A schematic diagram of the electronic device 800 according to at least one embodiment of the disclosure is shown.

[0155] As Figure 7 ​As shown, the electronic device 800 includes one or more processors 810 and a memory 820. The memory 820 includes one or more computer program modules 821. The one or more computer program modules 821 are stored in the memory 820 and configured to be executed by the processor 810, and the one or more computer program modules 821 include instructions for performing the time factor calibration method 300 for digital currency transactions and additional aspects thereof according to at least one embodiment of the present disclosure, which, when executed by the processor 810, can perform one or more steps of the time factor calibration method 300 for digital currency transactions and additional aspects thereof according to at least one embodiment of the present disclosure. The memory 820 and the processor 810 can be interconnected by a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0156] Exemplarily, the processor 810 can be a central processing unit (CPU), a digital signal processor (DSP), or other forms of processing units with data processing and / or program executing capabilities, such as a field programmable gate array (FPGA), etc. The processor 810 can be a general purpose processor or a special purpose processor, and can control other components in the electronic device 800 to perform desired functions.

[0157] Exemplarily, the memory 820 can include any combination of one or more computer program products, which can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory, for example, can include random access memory (RAM), cache memory, etc. Non-volatile memory, for example, can include read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), compact disc read-only memory (CD-ROM), USB memory, flash memory, etc. One or more computer program modules 821 can be stored on the computer-readable storage media, and the processor 810 can run the one or more computer program modules 821 to implement various functions of the electronic device 800. The computer program modules include a plurality of computer-executable instructions. Various application programs and various data used and / or generated by the application programs, etc. can also be stored in the computer-readable storage media.

[0158] For example, the electronic device 800 can further include input devices such as a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices such as a liquid crystal display, a speaker, a vibrator, etc.; storage devices such as a magnetic tape, a hard disk (HDD or SDD), etc.; and communication devices such as a LAN card, a modem, etc. The communication devices can allow the electronic device 800 to communicate with other devices wirelessly or via wires to exchange data, perform communication processing via a network such as the Internet. Drivers are connected to the I / O interface as needed. Removable storage media such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. are mounted on the drivers as needed, so that computer programs read from them are installed in the storage devices as needed.

[0159] For example, the electronic device 800 can further include a peripheral interface (not shown) and the like. The peripheral interface can be various types of interfaces, such as a USB interface, a lighting interface, and the like. The communication devices can communicate with networks and other devices through wireless communication, the networks being, for example, the Internet, an intranet, and / or a wireless network such as a cellular telephone network, a wireless local area network (LAN), and / or a metropolitan area network (MAN). The wireless communication can use any of a plurality of communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., based on IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n standards), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email, instant messaging, and / or Short Message Service (SMS), or any other suitable communication protocol.

[0160] The electronic device 800 can be, for example, a system on chip (SOC) or a device including the SOC, such as a mobile phone, a tablet computer, a notebook computer, an e-book, a game console, a television, a digital photo frame, a navigator, a home appliance, a communication base station, an industrial controller, a server, or any device, and can be any data processing apparatus and combination of hardware, without limitation. The specific functions and technical effects of the electronic device 800 can be referred to the description of the method 300 for calibrating a time factor for a digital currency transaction and additional aspects thereof according to at least one embodiment of the present disclosure above, which will not be repeated here.

[0161] Figure 8 A schematic diagram of a computer readable medium 900 according to at least one embodiment of the present disclosure is shown.

[0162] As shown in Figure 8 the computer instructions 910 stored on the computer readable medium 900 are executed by a processor to perform one or more steps of the time factor calibration method 300 for digital currency transactions and additional aspects thereof as described above.

[0163] Exemplarily, when the program code is read by the computer, the computer can execute the program code stored in the computer storage medium to perform one or more steps of the time factor calibration method 300 for digital currency transactions and additional aspects thereof according to at least one embodiment of the present disclosure, for example.

[0164] Exemplarily, the computer readable medium can include a memory card of a smart phone, a memory component of a tablet computer, a hard disk of a personal computer, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM), a portable compact disc read only memory (CD-ROM), a flash memory, and other computer readable medium or any combination thereof.

[0165] At least part of the embodiments in the specification are described in a progressive manner, and each embodiment focuses on the difference from other embodiments, and the same or similar parts between various embodiments can be referred to each other.

[0166] It should be noted that, in this document, the relationship terms such as first, second and the like are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. The terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but further includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device. Without more limitations, the elements defined by the statement "include" do not exclude the presence of other same elements in the process, method, article or device including the elements.

[0167] For the present disclosure, the following points need to be explained:

[0168] (1) The drawings of the embodiments of the present disclosure only involve the structures related to the embodiments of the present disclosure, and other structures can refer to the general design.

[0169] (2) In the case of no conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0170] The above-described exemplary embodiments of the present disclosure are merely for the purpose of illustration and are not intended to limit the scope of the present disclosure, which is defined by the appended claims.

Claims

1. A time factor calibration method for digital currency transactions, wherein, The method comprises: The background server receives the authorization information for calibrating the time factor sent by the hard wallet forwarded by the receiving terminal; If the background server confirms that the authorization information is trustworthy, the background server executes the operation of generating the time factor calibration instruction or executes the time factor calibration operation according to the authorization information; The background server forwards the time factor calibration instruction to the hard wallet through the receiving terminal to make the hard wallet execute the time factor calibration operation, or sends the processing result of the time factor calibration operation executed by the background server to the receiving terminal.

2. The time factor calibration method according to claim 1, wherein The authorization information comprises a first instruction identifier, The background server generates the time factor calibration instruction containing the time factor and the hard wallet check value in response to the first instruction identifier.

3. The time factor calibration method of claim 1, wherein, The method further comprises: The background server receives the code information obtained by scanning the payment code provided by the hard wallet through the receiving terminal, and confirms whether the code information is valid; If the background server confirms that the code information is invalid, the background server sends first prompt information to the receiving terminal to prompt the user to execute corresponding operations, so that the hard wallet and the receiving terminal interact to send the authorization information to the receiving terminal.

4. The time factor calibration method of claim 3, wherein, The background server checks the code information by at least one of the following: Determine whether the receiving time of the code information meets the set time range; Determine whether the institution identifier of the code information meets the requirement; Check whether the check code in the code information is valid.

5. The time factor calibration method of claim 4, wherein, In the step of checking whether the check code in the code information is valid, the following steps are included: Determine the account index from the code information, and find the corresponding hard wallet data according to the account index; Calculate the first expected time for generating the payment code according to the hard wallet data, and calculate the first check code based on the first expected time; Check whether the check code in the code information is consistent with the calculated first check code, and if consistent, confirm that the check code is valid.

6. The time factor calibration method according to claim 5, wherein The first expected time is obtained based on the hard wallet reference time stored by the background server, the current time of the background server, and the record time of the hard wallet reference time.

7. The time factor calibration method of claim 6, wherein, If the check code in the code information is inconsistent with the calculated first check code, the following steps are executed: Process the first expected time based on the set time step to obtain the second expected time, and calculate the second check code based on the second expected time; Check whether the check code in the code information is consistent with the calculated second check code, and if consistent, confirm that the check code is valid.

8. The time factor calibration method according to claim 5 or 7, wherein, Further comprising: The background server updates the hard wallet reference time stored by the background server to the time when the check code is confirmed to be valid.

9. The time factor calibration method according to claim 1, wherein The authorization information comprises a second instruction identifier, the time of the receiving terminal, and the hard wallet reference time; The background server, in response to the second instruction identification, calculates a time factor to be calibrated according to the time of the receiving terminal, the hard wallet reference time and the current time of the background server, updates the hard wallet reference time stored in the background server by using the time factor to be calibrated, and sends a processing result of performing the time factor calibration operation to the receiving terminal.

10. A time factor calibration method for digital currency transactions, wherein, The method comprises: The receiving terminal receives authorization information for calibrating a time factor from the hard wallet in interaction; If the receiving terminal confirms that the authorization information is trustworthy, the receiving terminal sends the authorization information to the background server, so that the background server, in a case where the authorization information is confirmed to be trustworthy, performs an operation of generating the time factor calibration instruction or performs a time factor calibration operation according to the authorization information; The receiving terminal forwards the time factor calibration instruction received from the background server to the hard wallet to make the hard wallet perform the time factor calibration operation, or receives a processing result of the time factor calibration operation performed by the background server.

11. The time factor calibration method according to claim 10, wherein, When the receiving terminal receives the time factor calibration instruction, the receiving terminal judges whether the hard wallet is in communication interaction with the receiving terminal, and if the judgment result is that the communication is abnormal, the receiving terminal generates second prompt information to prompt the user to keep the communication between the hard wallet and the receiving terminal.

12. The time factor calibration method of claim 10, wherein, The method further comprises: The receiving terminal scans a payment code provided by the hard wallet to obtain code information, and sends the code information to the background server to confirm whether the code information is valid; The receiving terminal receives first prompt information sent by the background server to prompt the user to perform a corresponding operation, so that the hard wallet and the receiving terminal interact to send the authorization information to the receiving terminal; The first prompt information is sent by the background server to the receiving terminal when the background server confirms that the code information is invalid.

13. A time factor calibration method for digital currency transactions, wherein, The method comprises: The hard wallet sends authorization information for calibrating a time factor to a receiving terminal in interaction; The hard wallet receives a time factor calibration instruction generated by the background server and forwarded by the receiving terminal, and performs a time factor calibration operation according to the time factor calibration instruction.

14. The time factor calibration method according to claim 13, wherein The step of performing a time factor calibration operation by the hard wallet according to the time factor calibration instruction comprises a time difference judgment step: Judging whether a time difference between the time factor in the time factor calibration instruction and a current hard wallet reference time of the hard wallet is greater than at least one set time step, and if the judgment result is that the time difference is greater than at least one set time step, updating the hard wallet reference time to the time factor.

15. The time factor calibration method of claim 14, wherein, Before the hard wallet performs the time factor calibration operation according to the time factor calibration instruction, the method further comprises: determining whether a time difference between a time when the authorization information is sent to the receiving terminal and a current hard wallet reference time of the hard wallet is less than a first set time range, and when the determination result is less than the first set time range, performing a time factor calibration operation.

16. The time factor calibration method of claim 14, wherein, The method further includes that the hard wallet sends the authorization information in response to a digital currency transaction instruction sent by the receiving terminal. The step of performing the time factor calibration operation by the hard wallet according to the time factor calibration instruction further includes: determining whether a time difference between receiving the time factor calibration instruction and receiving the digital currency transaction instruction is less than a second set time range, and when the determination result is less than the second set time range, performing the time difference determination step.

17. A time factor calibration system for digital currency transactions, wherein, The system includes a hard wallet, a receiving terminal and a background server, The hard wallet is configured to send authorization information for calibrating a time factor to the receiving terminal, and receive a time factor calibration instruction from the receiving terminal to perform a time factor calibration operation. The receiving terminal is configured to: receive the authorization information for calibrating the time factor from the hard wallet in the interaction; send the authorization information to the background server when it is confirmed that the authorization information is trustworthy; forward the time factor calibration instruction received from the background server to the hard wallet, or receive a processing result of the time factor calibration operation performed by the background server from the background server; The background server is configured to perform an operation of generating a time factor calibration instruction or perform a time factor calibration operation according to the authorization information when it is confirmed that the authorization information is trustworthy.

18. An electronic device comprising: one or more processors; a memory storing one or more computer program modules, wherein the one or more computer program modules are configured to be executed by the one or more processors to implement the method according to any one of claims 1-16.

19. A computer readable medium storing computer executable instructions, wherein, Computer executable instructions are executed by one or more processors to implement the method according to any one of claims 1-16.

Images