Time factor calibration method and system for digital currency transaction

Abstract

Embodiments of the present disclosure provide a time factor calibration method and system for a digital currency transaction. The method comprises: a background server receives authorization information which is used for calibrating a time factor, sent by a hardware wallet and forwarded via an acceptance terminal; when confirming that the authorization information is trusted, on the basis of the authorization information, the background server executes an operation of generating a time factor calibration instruction or executes a time factor calibration operation; and the background server forwards the time factor calibration instruction to the hardware wallet via the acceptance terminal, so that the hardware wallet executes the time factor calibration operation, or sends to the acceptance terminal a processing result of the background server executing the time factor calibration operation.

Description

A time factor calibration method and system for digital currency transactions

[0001] This application claims priority to Chinese Patent Application No. 202410917983.9, filed on July 9, 2024, entitled "A Time Factor Calibration Method and System for Digital Currency Transactions", the entire contents of which are incorporated herein by reference. Technical Field

[0002] The embodiments disclosed herein relate to the field of computer technology, and more particularly to a time factor calibration method and system for digital currency transactions. Background Technology

[0003] With the continuous development of computer technology and information security technology, the application scenarios of digital currency wallets are becoming increasingly widespread and their usage scenarios are becoming increasingly diverse. Typically, digital currency wallets include software wallets and hardware wallets. Hardware wallets can conduct offline transactions. The receiving terminal sends transaction information to the backend, which processes the transactions. After a certain number of offline transactions are completed, the hardware wallet needs to connect to the internet to synchronize and update the relevant transaction data and information.

[0004] In some scenarios, it is necessary to synchronize the time of the hardware wallet with the backend in order to complete digital currency transactions normally, but there is currently no corresponding technical solution that can meet the above requirements. Summary of the Invention

[0005] At least one embodiment of this disclosure provides a time factor calibration method for digital currency transactions. The method includes: a backend server receiving authorization information for calibrating a time factor from a hard wallet forwarded by a receiving terminal; the backend server, in response to confirming that the authorization information is trustworthy, performing an operation to generate a time factor calibration instruction or performing a time factor calibration operation based on the authorization information; and the backend server forwarding the time factor calibration instruction to the hard wallet via the receiving terminal to cause the hard wallet to perform the time factor calibration operation, or sending the processing result of the backend server performing the time factor calibration operation to the receiving terminal.

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

[0007] For example, the time factor calibration method according to at least one embodiment of the present disclosure further includes: a backend server receiving code information obtained by scanning the payment code provided by the hard wallet through the acceptance terminal, and confirming whether the code information is valid; and when the backend server confirms that the code information is invalid, sending a first prompt message to the acceptance terminal to prompt the user to perform a corresponding operation, so that the hard wallet and the acceptance terminal interact to send authorization information to the acceptance terminal.

[0008] For example, according to the time factor calibration method of at least one embodiment of this disclosure, the backend server performs at least one of the following checks on the code information to obtain a judgment result: determining whether the reception time of the code information meets the set time range; determining whether the organization identifier of the code information meets the requirements; and checking whether the check code in the code information is valid. When the judgment result is negative, the backend server confirms that the code information is invalid.

[0009] For example, in the time factor calibration method according to at least one embodiment of the present disclosure, the step of checking whether the verification code in the verification code information is valid includes: determining the account index from the code information, searching for the corresponding hard wallet data according to the account index; calculating a first estimated time for generating the payment code according to the hard wallet data, and calculating a first verification code based on the first estimated time; and checking whether the verification code in the verification code information is consistent with the calculated first verification code, and confirming that the verification code is valid when they are consistent.

[0010] For example, according to at least one embodiment of the time factor calibration method of this disclosure, a first estimated time is obtained based on the hard wallet reference time stored on the backend server, the current time of the backend server, and the recording time of the hard wallet reference time.

[0011] For example, according to at least one embodiment of the time factor calibration method of this disclosure, when the check code in the code information is inconsistent with the calculated first check code, the following steps are performed: processing the first estimated time based on the set time step to obtain the second estimated time, and calculating the second check code based on the second estimated time; and checking whether the check code in the check code information is consistent with the calculated second check code. If they are consistent, the check code is confirmed to be valid.

[0012] For example, the time factor calibration method according to at least one embodiment of the present disclosure further includes: the backend server updating the hardware wallet reference time stored on the backend server to the time when the verification code is confirmed to be valid.

[0013] For example, according to at least one embodiment of the time factor calibration method of this disclosure, the authorization information includes a second instruction identifier, the time of the receiving terminal, and the hardware wallet reference time; the backend server responds to the second instruction identifier, calculates the time factor to be calibrated based on the time of the receiving terminal, the hardware wallet reference time, and the current time of the backend server, updates the hardware wallet reference time stored in the backend server using the time factor to be calibrated, and sends the processing result of performing the time factor calibration operation to the receiving terminal.

[0014] At least one embodiment of this disclosure provides a time factor calibration method for digital currency transactions. The method includes: a receiving terminal receiving authorization information for calibrating the time factor from an interactive hardware wallet; the receiving terminal confirming that the authorization information is trustworthy, and then sending the authorization information to a backend server, so that the backend server, in response to confirming that the authorization information is trustworthy, performs an operation to generate a time factor calibration instruction or performs a time factor calibration operation based on the authorization information; the receiving terminal forwards the time factor calibration instruction received from the backend server to the hardware wallet so that the hardware wallet performs the time factor calibration operation, or receives the processing result of the backend server performing the time factor calibration operation from the backend server.

[0015] For example, according to the time factor calibration method of at least one embodiment of the present disclosure, when the receiving terminal receives the time factor calibration instruction, it further determines whether the hardware wallet is in communication interaction with the receiving terminal. When it is determined that the communication is abnormal, a second prompt message is generated to prompt the user to maintain communication between the hardware wallet and the receiving terminal.

[0016] For example, the time factor calibration method according to at least one embodiment of this disclosure further includes: the accepting terminal scanning the payment code provided by the hardware wallet to obtain code information, and sending it to the backend server to confirm whether the code information is valid; and the accepting terminal receiving a first prompt message sent by the backend server when the confirmation code information is invalid to prompt the user to perform the corresponding operation, so that the hardware wallet and the accepting terminal interact to send authorization information to the accepting terminal, wherein the first prompt message is sent by the backend server to the accepting terminal when the confirmation code information is invalid.

[0017] At least one embodiment of this disclosure provides a time factor calibration method for digital currency transactions, wherein the method includes: a hardware wallet sending authorization information for calibrating the time factor to an acceptance terminal in the interaction; and the hardware wallet receiving a time factor calibration instruction generated by a backend server forwarded by the acceptance terminal, and performing a time factor calibration operation according to the time factor calibration instruction.

[0018] For example, according to at least one embodiment of the time factor calibration method of this disclosure, the step of the hard wallet performing time factor calibration operation 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 is greater than at least one set time step; when the judgment result is greater than at least one set time step, updating the hard wallet reference time to the time factor.

[0019] For example, according to at least one embodiment of the time factor calibration method of this disclosure, before the hard wallet performs a time factor calibration operation according to the time factor calibration instruction, it further includes: determining whether the time difference between the time of sending authorization information to the acceptance terminal and the current hard wallet reference time is less than a first set time range, and performing a time factor calibration operation when the determination result is less than the first set time range.

[0020] For example, according to at least one embodiment of the time factor calibration method of this disclosure, the method further includes: a hardware wallet sending authorization information in response to a digital currency transaction instruction sent by a receiving terminal; the step of the hardware wallet performing a time factor calibration operation according to the time factor calibration instruction further includes: determining whether the time difference between receiving the time factor calibration instruction and receiving the digital currency transaction instruction is less than a second preset time range, and if the determination result is less than the second preset time range, then performing a time difference determination step.

[0021] At least one embodiment of this disclosure provides a time factor calibration system for digital currency transactions. The system includes a hardware wallet, a receiving terminal, and a backend server. The hardware wallet is configured to send authorization information for calibrating the time factor to the receiving terminal, and to 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 hardware wallet in the interaction; send the authorization information to the backend server in response to confirming that the authorization information is trustworthy; forward the time factor calibration instruction received from the backend server to the hardware wallet, or receive the processing result of the backend server performing the time factor calibration operation; and the backend server is configured to, if the authorization information is confirmed to be trustworthy, perform an operation to generate a time factor calibration instruction or perform a time factor calibration operation based on the authorization information.

[0022] At least one embodiment of this disclosure provides an electronic device including: one or more processors; and 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 a method provided according to at least one embodiment of this disclosure.

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

[0024] The time factor calibration scheme for digital currency transactions disclosed in this embodiment can ensure time synchronization between the hardware wallet and the backend server, thereby keeping the dynamic offline payment code generated based on the time factor valid. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0026] Figure 1 shows a block diagram of a time factor calibration system for digital currency transactions according to at least one embodiment of the present disclosure;

[0027] Figure 2 shows a block diagram of an exemplary digital currency hard wallet according to at least one embodiment of the present disclosure;

[0028] Figure 3 shows a flowchart of a time factor calibration method for digital currency transactions according to at least one embodiment of the present disclosure;

[0029] Figure 4 shows a flowchart of a time factor calibration method for digital currency transactions according to at least one embodiment of the present disclosure;

[0030] Figure 5 shows a flowchart of a time factor calibration method for digital currency transactions according to at least one embodiment of the present disclosure;

[0031] Figure 6 shows an operation flowchart of a time factor calibration method in a payment code transaction scenario according to Example 3 of at least one embodiment of the present disclosure;

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

[0033] Figure 8 shows a schematic diagram of a computer-readable medium according to at least one embodiment of the present disclosure. Detailed Implementation

[0034] Reference will now be made in detail to specific embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Although the present disclosure will be described in conjunction with specific embodiments, it will be understood that it is not intended to limit the present disclosure to the described embodiments. Rather, it is intended to cover variations, modifications, and equivalents included within the 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 functional block or functional arrangement, and any functional block or functional arrangement can be implemented as a physical entity or a logical entity, or a combination of both.

[0035] To enable those skilled in the art to better understand this disclosure, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] Note that the examples described below are merely specific examples and are not intended to limit the embodiments of this disclosure to the specific shapes, hardware, connections, operations, values, conditions, data, sequences, etc., shown and described. Those skilled in the art can utilize the concepts of this disclosure to construct further embodiments not mentioned herein by reading this specification.

[0037] The terminology used in this disclosure is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, these terms may vary depending on the intent, precedent, or new technology of those skilled in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of this disclosure. Therefore, the terminology used in this specification should not be construed as simple names, but rather based on the meaning of the terms and the overall description of this disclosure.

[0038] This disclosure uses flowcharts to illustrate the operations performed by a system according to embodiments of this disclosure. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously, as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

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

[0040] Digital currency wallets can take the form of soft wallets or hardware wallets. Hardware wallets are physical media for storing digital currency, opened through over-the-counter or electronic channels. They are digital currency carriers with hardware security elements and have basic functions such as withdrawal, redemption, deposit, withdrawal, spending, transfer, and inquiry. Examples include mobile phones with secure elements (SE), NFC-SIM cards, IC cards, and wearable devices.

[0041] Hardware wallet application: Supports basic functions such as opening / closing a hardware wallet, online / offline payments, and balance inquiry. It provides security authentication for financial operations such as transfers and purchases, including offline security authentication, and offers services such as changing authentication methods and resetting passwords.

[0042] Interoperability Platform: A platform supporting the transfer, clearing, and message exchange of digital currency / electronic payments between the central bank and various operating institutions. It enables interoperability between the central bank and various operating institutions.

[0043] Contactless transactions, also known as "contactless payments," are a technology that allows payments to be completed without physical contact (such as card transactions) with the terminal device. This technology utilizes wireless communication technologies, such as Radio Frequency Identification (RFID), Near Field Communication (NFC), UWB, or Bluetooth, to enable data transmission and interaction between the payment terminal and the accepting terminal.

[0044] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solutions disclosed herein all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0045] To expand the usability of hardware wallets and facilitate user choices for cryptocurrency payments, some newly established visual hardware wallets have implemented a new mode for cryptocurrency transactions via scanning dynamic offline payment codes (hereinafter referred to as "payment codes"). This necessitates that the visual hardware wallet generate dynamic offline payment codes. In some cases, the visual hardware wallet requires a time factor (e.g., the hardware wallet's base time) when generating the dynamic offline payment code. To ensure the validity of the generated payment code, the hardware wallet's time factor needs to be synchronized with the background time factor. However, when the visual hardware wallet's battery is depleted, its internal clock stops, causing a time discrepancy between the hardware wallet and the background. Even after the hardware wallet is recharged, the dynamic offline payment code generated by the hardware wallet may be invalidated during background verification, resulting in transaction anomalies and preventing normal transaction execution. Furthermore, in some scenarios, it is also necessary to adjust the background time based on the hardware wallet's time factor, but a satisfactory solution has not yet been found.

[0046] At least one embodiment of this disclosure provides a time factor calibration method, system, electronic device, and computer storage medium for digital currency transactions, enabling timely calibration when, for example, a discrepancy is detected between the base time of a hardware wallet and the base time recorded in the backend. For example, the time factor can be automatically calibrated between the frontend and backend during payment code transactions or contactless transactions. Alternatively, during non-transaction periods, the hardware wallet can spontaneously calibrate the time factor between the wallet and the backend, ensuring time synchronization between the frontend and backend. This ensures that the generated dynamic offline payment code is always valid and usable, greatly reducing the occurrence of transaction anomalies.

[0047] Figure 1 shows a block diagram of a time factor calibration system 100 for digital currency transactions according to at least one embodiment of the present disclosure.

[0048] As shown in Figure 1, the transaction system 100 includes a visual hardware wallet 102, an acceptance terminal 104, a back-end server 105 (as an example shown in the figure, it may include a first server 106, a second server 110, and an interconnection platform 108).

[0049] In this embodiment, the hard wallet 102 can be an electronic device including an NFC card chip. For example, the hard wallet 102 can be a terminal capable of supporting one or more NFC functions (NFC payment functions) and having a display function, such as the visual card-type hard wallet shown in Figure 2. Generally, the hard wallet 102 can use NFC to perform payments or communications. When using NFC to perform payments or communications, a built-in digital currency application, such as a hard wallet application, can be driven and used. In this embodiment, the visual hard wallet also supports a QR code transaction mode, which can generate a dynamic offline payment code and display the payment code through a display module. The receiving terminal completes the digital currency transaction by scanning the payment code. Since the visual hard wallet needs to generate a payment code in the QR code transaction mode, and the generation of the payment code relies on the base time stored inside the hard wallet, it is very important to ensure the synchronization of the hard wallet base time and the hard wallet base time recorded by the backend server. If they are not synchronized, the payment code will fail the verification on the backend server, resulting in transaction failure.

[0050] Figure 2 shows a block diagram of an exemplary digital currency hard wallet according to at least one embodiment of the present disclosure. As shown in Figure 2, the hard wallet 102 is a visual card that 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.

[0051] For example, security unit 1021 includes a hardware wallet application 1021A and a data storage area 1021B. The hardware wallet application 1021A is primarily responsible for managing digital currency payment activities, and its functions include reading and writing personalized account information, wallet management, wallet transactions, and wallet query functions. Data storage area 1021B stores: wallet SEID, wallet ID, wallet control information, wallet transaction-related information, key and certificate information. The wallet ID can be a real wallet account ID or an association code for a wallet account. The association code is used to ensure wallet data security, and it corresponds one-to-one with each wallet account. Furthermore, the keys and authentication information include symmetric keys, asymmetric keys, and institution certificates. During wallet initialization (i.e., wallet account opening), the wallet issuer distributes the symmetric keys, asymmetric keys, and institution certificates to the hardware wallet, and this data is written into the data storage area 1021B of security unit 1021. Communication module 1026 is mainly connected to the receiving terminal 104, and its communication methods can include Bluetooth, near-field NFC, Wi-Fi, UWB, and mobile networks. The display module 1022 can be a standalone visualization device for the hardware wallet, or it can be a visualization device integrated into the medium that serves as the carrier of the hardware wallet application (such as a mobile phone screen, tablet screen, etc.). The visualization device can be in the form of a screen, such as an electronic screen (e.g., segment code screen, dot matrix screen, etc.) or an e-ink screen. The input element 1024 can include components such as a touchscreen or keypad to accept user-triggered input operations, such as displaying a payment code via a press-to-switch component. The power module 1023 can power the hardware wallet 102 and can be a lithium-ion battery or a metal-air battery, such as a zinc-air battery, aluminum-air battery, or lithium-air battery. The controller 1025 primarily generates a dynamic offline payment code based on user operations; specifically, it generates the payment code based on the key in the data storage area 1021B and the hardware wallet's base time. Furthermore, the controller 1025 can also call the display interface to display the payment code and transaction amount / balance information at the display module 1022. A timer (not shown) is either internally or independently located in the controller 1025. This timer continuously counts when the hard wallet 102 is powered to ensure that the base time of the hard wallet is basically consistent with the base time of the backend server. However, when the hard wallet 102 is depleted of power, the timer will stop counting. This will cause the base time after charging is started to differ from the base time of the backend server. Consequently, the generated payment code will be invalid during verification on the backend server, and the transaction cannot be completed successfully.

[0052] 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.

[0053] For example, messages between the receiving terminal 104 and the backend server 105 can be sent via the communication network 200 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.

[0054] 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.

[0055] As shown in Figure 1, 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 of the disclosure, the backend server also includes an interconnection system or server (such as the interconnection platform 108 in Figure 1) that is connected to the systems or servers corresponding to each operating institution.

[0056] For example, in this embodiment of the disclosure, when conducting a digital currency transaction based on the payer's institution identifier, the payee's institution identifier, and the transaction amount in the transaction information, if the operating institutions corresponding to the payer's institution identifier and the payee's institution identifier belong to the same operating institution, a transaction within this institution is conducted; if the operating institutions corresponding to the payer's institution identifier and the payee's institution identifier do not belong to the same operating institution, a transaction request is sent through the interconnection platform to conduct a cross-institutional transaction.

[0057] In addition to the above, the issuer (not shown) is also involved. When issuing certain hardware wallets, the issuer will write user information (including, for example, the key for generating payment codes), capability identifiers, and supported application scenarios into these hardware wallets according to the needs of the scenario. In this way, the hardware wallet has personalized configuration.

[0058] Figure 3 shows a flowchart of a time factor calibration method 300 for digital currency transactions according to at least one embodiment of the present disclosure. This method 300 is used to calibrate the time factor in the system shown in Figure 1. For example, the method 300 includes the following steps S310 to S314.

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

[0060] In step S312, in response to confirming that the authorization information is trustworthy, the receiving terminal 104 sends the authorization information to the backend server 105.

[0061] In step S314, the receiving terminal 104 forwards the time factor calibration instruction received from the backend server 105 to the hardware wallet 102 so that the hardware wallet 102 performs the time factor calibration operation, or receives the processing result of the backend server 105 performing the time factor calibration operation.

[0062] For example, in step S310, the hardware wallet 102 may send authorization information in response to a digital currency transaction initiated by the receiving terminal 104, simultaneously calibrating the time while conducting the transaction; alternatively, the hardware wallet 102 may initiate the calibration itself, such as by tapping a card with the receiving terminal to query information. In contactless transactions, for example, the hardware wallet 102 may simultaneously calibrate the hardware wallet's base time and / or the hardware wallet's base time on the backend server during the transaction execution. In the case of self-initiation, the hardware wallet 102 may calibrate the time factor on the hardware wallet or backend while querying information (such as balance information) after establishing communication with the receiving terminal 104, or it may directly send authorization information to the receiving terminal 104 after establishing communication interaction to calibrate the time factor on the hardware wallet or backend. This embodiment of the present disclosure does not limit this approach. After establishing communication with the hardware wallet, the receiving terminal 104 may send a time calibration authorization information request instruction to the hardware wallet 102, and the hardware wallet 102 will return authorization information after receiving the instruction. In other examples, the hard wallet 102 may also respond to an information query instruction or transaction instruction sent by the receiving terminal 104 and return content containing authorization information to the receiving terminal 104.

[0063] For example, in one instance, the authorization information may include a hard wallet identifier, a key dispersion factor (e.g., a counter), a terminal verification value (e.g., a random number generated by the terminal), an accepting terminal identifier, a first instruction identifier, and a backend verification value. The first instruction identifier may indicate a request to the backend server to issue a time factor calibration instruction to calibrate the hard wallet's base time stored on the hard wallet. The purpose of the hard wallet sending this instruction identifier is primarily to address the possibility that the hard wallet's base time may be inconsistent with the hard wallet's base time stored on the backend server due to power outages or other factors, thus requesting the backend server to synchronize the hard wallet's base time according to its own stored hard wallet base time. If the backend server 105 confirms that the authorization information is trustworthy, it will then execute the operation of generating a time factor calibration instruction based on the first instruction identifier in the authorization information.

[0064] For example, in another example, the authorization information may include information such as the hard wallet identifier, key dispersion factor (e.g., a counter), terminal verification value (e.g., a random number generated by the terminal), terminal identifier, the time of the receiving terminal (referred to as terminal time), a second instruction identifier, the hard wallet base time, and the backend verification value. The second instruction identifier may represent an instruction to the backend server to calibrate the locally stored hard wallet base time. If the backend server 105 confirms that the authorization information is trustworthy, it will perform a time factor calibration operation based on the second instruction identifier of the authorization information.

[0065] The statement "the authorized information is trustworthy" can be understood as the authorized information being verified to ensure its security and integrity, guaranteeing that it has not been tampered with or damaged during transmission or storage. For example, verification can be performed using MAC value checks or information value (such as random numbers) comparison checks; the specific method is not limited.

[0066] For example, in step S312, the receiving terminal 104 can verify the trustworthiness of the authorization information by checking 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 verifies the validity of the terminal verification value, it only needs to determine whether the terminal random number in the authorization information is consistent with the terminal random number stored in the receiving terminal 104. If they are consistent, the terminal verification value is confirmed to be valid, and thus the receiving terminal 104 can determine that the authorization information is trustworthy. Of course, in addition to the above method, other methods can also be used for verification. For example, the terminal verification value can also be a MAC value. The receiving terminal 104 confirms the validity by comparing whether the calculated MAC value is consistent with the terminal verification value. By executing step S312, the receiving terminal can confirm the reliability and security of the authorization information sent by the hardware wallet, effectively preventing security problems caused by information tampering or damage, and ensuring that information security problems occurring in the first link of transmitting authorization information (information transmission from hardware wallet to receiving terminal) are detected in a timely manner.

[0067] For example, in at least one embodiment of this disclosure, in method 300, the backend server 105 can verify the backend verification value (e.g., MAC value) based on the hard wallet identifier and key dispersion factor, thereby confirming whether the authorization information is trustworthy. In this example, the backend server 105 uses the MAC value verification method to compare whether the calculated MAC value is consistent with the MAC value in the authorization information. The specific steps include: obtaining the corresponding hard wallet key based on the hard wallet identifier; dispersing the hard wallet key using the key dispersion factor to obtain the authentication key, and using the authentication key to calculate the verification value for the information in the authorization information other than the backend verification value; comparing the calculated verification value with the backend verification value, and if they are consistent, determining that the backend verification value is valid, thereby confirming that the authorization information is trustworthy. Based on this, the backend server can confirm the reliability and security of the authorization information forwarded by the receiving terminal, effectively preventing security problems caused by information tampering or damage in the second stage of transmitting authorization information (information transmission from the receiving terminal to the backend).

[0068] For example, in at least one embodiment of this disclosure, in method 300, the authorization information includes a first instruction identifier, indicating a request for the backend server 105 to issue a time factor calibration instruction. In this case, the backend server 105 responds to the first instruction identifier by generating a time factor calibration instruction containing a time factor and a hard wallet verification value, 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 performs a time factor calibration operation according to the time factor calibration instruction. During this process, after receiving the time factor calibration instruction, the hard wallet 102 extracts the hard wallet verification value from the instruction, such as a MAC value. It compares the calculated MAC value with the MAC value extracted from the instruction to determine whether the hard wallet verification value is valid, thereby confirming the trustworthiness of the instruction and ensuring that the instruction forwarded by the receiving terminal 104 is trustworthy before proceeding with the subsequent time factor calibration operation. In this example, since information verification is performed in the last step, the receiving terminal 104 generally does not need to perform information trustworthiness verification. However, a verification step can be set as needed.

[0069] For example, in at least one embodiment of this disclosure, the step of the hardware wallet performing a time factor calibration operation according to the time factor calibration instruction includes a time difference judgment step: determining whether the time difference between the time factor in the time factor calibration instruction and the current hardware wallet reference time is greater than at least one set time step. If the judgment result is greater than at least one set time step, the hardware wallet reference time is updated to the time factor. In one example, the time step can be set to 60 seconds. The purpose of this setting is to prevent frequent time updates if the time difference does not meet at least one step, which would affect the storage life of the hardware wallet. Moreover, in this case, although the reference time stored in the background is not completely consistent with the reference time of the hardware wallet, it does not affect the validity of the generated payment code. Of course, if storage life is not considered, the time difference judgment step can be omitted, and the current hardware wallet reference time of hardware wallet 102 can be directly updated to the time factor in the time factor calibration instruction.

[0070] In this embodiment, "hard wallet base time" generally refers to UTC (Coordinated Universal Time), but it can also be other times, such as the start time agreed upon in advance by the front-end and back-end. This disclosure does not limit it in this way.

[0071] For example, in at least one embodiment of this disclosure, in method 300, when the receiving terminal 104 receives the time factor calibration instruction, it further determines whether the hardware wallet 102 is in communication with the receiving terminal 104. If it determines that the communication is abnormal, it issues a second prompt message to remind the user to maintain communication between the hardware wallet 102 and the receiving terminal 104. In order to achieve synchronization of the hardware wallet's base time, in the event of a communication disconnection, for example, if the hardware wallet 102 is not within the effective communication range with the receiving terminal 104, the receiving terminal 104 prompts the user to re-establish the communication connection between the hardware wallet 102 and the receiving terminal 104, for example, by re-attaching the card, until the instruction is completed or a timeout occurs. In the case of a timeout, the user is prompted to perform a new round of time factor operation.

[0072] For example, in at least one embodiment of this disclosure, in method 300, before the hard wallet performs a time factor calibration operation according to the time factor calibration instruction, the method further includes: determining whether the time difference between the time of sending authorization information to the receiving terminal and the current hard wallet reference time is less than a first preset time range; if the determination result is less than the first preset time range, then the time factor calibration operation is performed. When the hard wallet receives an instruction to return authorization information, it records the current local time of the hard wallet while generating the authorization information; when the hard wallet receives the time factor calibration instruction, it determines whether the current local time of the hard wallet and the local time recorded when returning the authorization information differ too much; if the difference is too much, it cannot be updated because of the information transmission delay; if it is updated, the time synchronization between the hard wallet and the backend cannot be guaranteed. The first preset time range can be set as needed, for example, 10 seconds; this disclosure does not limit this.

[0073] For example, in at least one embodiment of this disclosure, in method 300, if the hardware wallet sends authorization information in response to a digital currency transaction instruction sent by the receiving terminal 104, then after receiving the time factor calibration instruction, the hardware wallet 102 further determines 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; if the determination result is less than the second set time range, the hardware wallet 102 performs the above-mentioned time difference determination step, that is, determines whether the time difference between the time factor in the time factor calibration instruction and the current hardware wallet base time is greater than at least one set time step; if the determination result is greater than at least one set time step, then the hardware wallet base time is updated to the time factor. In one example, after the hard wallet 102 receives the echo instruction and time factor calibration instruction returned by the receiving terminal 104 after the transaction processing is completed, it can first perform a trustworthiness verification of the instructions. Then, it can determine whether the time difference between the received digital currency transaction instruction and the time factor calibration instruction sent by the receiving terminal 104 is within a set time range, such as 10 seconds. This can control the deviation between the hard wallet base time updated by the backend and the base time in the hard wallet to be within 10 seconds. If it is determined that the time is satisfied, it is determined that the time transmitted by the backend and the current base time of the hard wallet differ from each other by at least one fault tolerance step (e.g., 60 seconds). If it exceeds this, the base time of the hard wallet is updated; if it does not exceed this, no time change is required. This reduces the possibility of the payment code backend verification becoming invalid due to the hard wallet timer accumulating too large an offset.

[0074] For example, in at least one embodiment of this disclosure, method 300 further includes: the receiving terminal 104 scanning the payment code provided by the hard wallet 102 to obtain code information and sending it to the backend server 105; the backend server 105 confirming whether the code information is valid; if invalid, it sends a first prompt message to the receiving terminal 104 to prompt the user to perform a corresponding operation, so that the hard wallet and the receiving terminal 104 interact to send authorization information to the receiving terminal 104. Specifically, if the code information is invalid, the backend server 105 will send a first prompt message to the receiving terminal 104, such as "Please swipe card for inquiry" or "Please swipe card for transaction". The user will then place 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. The hard wallet 102 responds to the request instruction, inquiry instruction or transaction instruction of the receiving terminal 104 and sends authorization information for calibrating the time factor to the receiving terminal 104.

[0075] This embodiment can be applied to scenarios where digital currency transactions are conducted by scanning a payment code. The payment code is a visual code generated by the controller 1025 of the hard wallet 102 upon receiving a control signal triggered by the user-triggered input element 1024. In one example, the controller 1025 retrieves a key issued at the time of account opening from the data storage area 1021B, and generates an offline payment code using the key pair operation factors (such as account index, random number) and the hard wallet base time. This payment code includes code information containing an institution identifier, code type, user index, and verification code. In one example, the payment code can be a quick-response QR code. The hard wallet 102 sends the payment code to the display module 1022 for scanning by the acceptance terminal 104. The acceptance terminal 104 securely scans or captures the displayed payment code using, for example, a camera, and then retrieves the code information from the payment code.

[0076] For example, in at least one embodiment of this disclosure, in method 300, the backend server 105 performs at least one of the following to verify the code information. If the judgment result is negative, the code information is confirmed to be invalid: (1) determining whether the receiving time of the code information meets the set time range; (2) determining whether the organization identifier of the code information meets the requirements; (3) verifying whether the verification code in the code information is valid. By verifying item (1), it can be determined whether the receiving time of the code information is within the set fault tolerance time, such as within 60 seconds. If it exceeds the time limit, it is considered that the receiving time of the code information has expired, the code information is invalid, and the transaction is rejected. In one example, the code information contains the organization identifier, code type, user index, and verification code. By verifying item (2), the operating organization to which the hard wallet belongs can be confirmed based on the organization identifier. Only when it is determined that the organization conforms to the corresponding organization identifier or the corresponding code number is the code information considered valid. Otherwise, the transaction is rejected. By verifying item (3), it is mainly to determine whether the payment code generated by the hard wallet is valid, which indirectly reflects whether the base time of the hard wallet is consistent with the base time of the hard wallet stored in the backend. The specific verification method is described in detail later. For these three verifications, at least one can be selected for execution. If any one of them fails to meet the requirements, the confirmation code information is invalid, and subsequent transaction processing is rejected. Additionally, it can be determined whether the code type is offline or online. In this embodiment of QR code transactions, offline codes are considered compliant; if it is not an offline code, the online code execution process begins.

[0077] For example, in at least one embodiment of this disclosure, in method 300, the step of determining whether the verification code in the verification code information is valid includes: determining an account index from the code information, searching for the corresponding hardware wallet data based on the account index; calculating a first estimated time for generating the payment code based on the hardware wallet data, and calculating a first verification code based on the first estimated time; determining whether the verification code in the verification code information is consistent with the calculated first verification code, and if they are consistent, confirming that the verification code is valid.

[0078] The backend server 105 stores hardware wallet data for different hardware wallets. This data is retrieved using a hardware wallet account index. The hardware wallet data includes at least a key, a payment code calculation factor, a hardware wallet base time, and a timestamp recording the hardware wallet base time. For example, in at least one embodiment of this disclosure, the backend server 105 obtains a first estimated time based on the hardware wallet base time stored on the backend server, the current time of the backend server, and the recording time of the hardware wallet base time. The first estimated time is the estimated time when the currently received payment code is generated on the hardware wallet side. Then, the calculated first estimated time and calculation factor are processed using the key in the hardware wallet data to obtain a first verification code. The first verification code is compared with the verification code in the code information to determine if the verification code is valid. If valid, the transaction is processed, indicating that the base time on the hardware wallet side and the base time on the backend server side are consistent. Therefore, a digital currency transaction is performed without triggering a time factor calibration operation.

[0079] For example, in at least one embodiment of this disclosure, in method 300, if the check code in the code information is inconsistent with the calculated first check code, the following steps are performed: the first estimated time is processed based on the set time step to obtain the second estimated time, and the second check code is calculated based on the second estimated time; whether the check code in the check code information is consistent with the calculated second check code, if they are consistent, then the check code is confirmed to be valid.

[0080] In this example, considering the delay in information transmission, a fault tolerance step length is set. For example, a time step of 60 seconds can be set as the fault tolerance step length. When the first checksum calculated using the first estimated time is different from the checksum in the code information, the first estimated time is increased or decreased by the set time step (e.g., 60 seconds) to obtain the second estimated time. Then, the consistency between the second checksum calculated using the second estimated time and the checksum in the code information is compared. If they match, the verification passes. If the verification still fails, the first estimated time is increased or decreased by twice the set step length (120 seconds) to obtain a new second estimated time. A new second checksum is then calculated using the new second estimated time. If the new second checksum matches the checksum in the code information, the verification is considered successful, and transaction processing is executed. Of course, the step length set above can be adjusted as needed, and in addition to the two processing steps of the first estimated time mentioned above, the number of processing steps can be increased as needed. This embodiment does not limit this.

[0081] For example, taking the first estimated time as 2024-05-15 14:33:46 as an example, the converted current calculation time is 1715754826 seconds. Dividing this by a step size of 60 seconds gives 28595913 minutes. Adding or subtracting one step size gives 28595914 minutes and 28595912 minutes, and adding or subtracting two step sizes gives 28595915 minutes and 28595911 minutes. First, a checksum is calculated using 28595913 minutes, and then compared. If they don't match, checksums are calculated using 28595914 minutes and 28595912 minutes respectively, and compared. If they still don't match, checksums are calculated using 28595915 minutes and 28595911 minutes respectively.

[0082] For example, in at least one embodiment of this disclosure, method 300 further includes: the backend server 105 updating the hardware wallet reference time recorded by the backend server 105 to the time when the verification code is confirmed as valid. In this example, if the verification passes, and there is a step size deviation between the hardware wallet reference time stored in the backend and the reference time on the wallet side, i.e., the verification only passes by adding or subtracting a set step size from the first estimated time, then the hardware wallet reference time recorded in the backend is adjusted to the time when the verification passes. If the verification code calculated based on the first estimated time (or the second estimated time) passes the verification of the verification code in the code information, then the hardware wallet reference time recorded in the backend is updated to the first estimated time (or the second estimated time). In this way, the reference times of the backend and the hardware wallet can be synchronized, without the need to trigger a separate calibration operation for the backend reference time.

[0083] For example, in at least one embodiment of this disclosure, in method 300, the authorization information includes a second instruction identifier, the time of the receiving terminal, and the hardware wallet reference time. The second instruction identifier indicates an instruction to calibrate the hardware wallet reference time of the backend server 105. In response to the second instruction identifier, the backend server 105 calculates the time factor to be calibrated based on the time of the receiving terminal, the hardware wallet reference time, and the current time of the backend server 105. It then updates the hardware wallet reference time stored in the backend server 105 using the time factor to be calibrated and sends the 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 during transactions, the hardware wallet 102 can also initiate time factor calibration of the backend server 105. The backend server 105 calculates a time value based on the terminal time, the hardware wallet reference time, and the current time of the backend server 105, adjusts the stored hardware wallet reference time to the calculated time value, completes the backend time factor calibration operation, and then sends the processing result information to the receiving terminal 104 so that the hardware wallet user can understand the execution result of the backend.

[0084] In summary, the time factor calibration scheme for digital currency transactions disclosed in this embodiment can ensure time synchronization between the hardware wallet and the backend server, thereby maintaining the validity of the dynamic offline payment code generated based on the time factor. Furthermore, during the calibration process, the trustworthiness of the verified information ensures the security of information transmission and prevents problems caused by malicious tampering or data loss.

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

[0086] Scene 1

[0087] Figure 4 shows a flowchart of an example of a time factor calibration method for digital currency transactions according to at least one embodiment of the present disclosure. In this example, the hardware wallet spontaneously verifies the locally stored hardware wallet base time, which involves the interaction of the visual hardware wallet 102, the receiving terminal 104, and the backend server 105. The steps are described below with reference to Figure 4.

[0088] S401: The hardware wallet 102 calibrates the time factor on the hardware wallet side while querying information by tapping the card. The receiving terminal 104 and the visual hardware wallet 102 establish a communication connection and select each other's hardware wallet application.

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

[0090] S403: The receiving terminal 104 sends an authorization information request instruction to the visual hardware wallet 102. The instruction may include a terminal random number and a terminal identifier.

[0091] S404: After receiving the request instruction, the hard wallet 102 increments the counter value, uses the new counter value to disperse the hard wallet key to generate a process key, and uses the process key to perform MAC calculation on the setting information to obtain the MAC value. The setting information includes the hard wallet identifier, counter value, terminal random number, terminal identifier, and an identifier representing the instruction to be issued (generally the first instruction identifier).

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

[0093] S406: After receiving the authorization information, the receiving terminal 104 verifies the terminal random number in it and determines whether the terminal random number in the authorization information is consistent with the terminal random number stored locally. If they are consistent, the verification passes and S407 is executed; otherwise, an error message is displayed.

[0094] S407: The receiving terminal 104 sends authorization information to the back-end server 105.

[0095] S408: The backend server 105 verifies the MAC value in the authorization information. If the verification is successful, it identifies that the instruction to be issued is a time factor calibration instruction. Then, the organization generates an instruction with a time factor (the hard wallet reference time stored in the backend) and a MAC value, and then issues it to the corresponding receiving terminal 104 according to the terminal identifier.

[0096] S409: The backend server 105 requests the response from the receiving terminal 104, that is, requests the return of the authorization result and the APDU instruction to calibrate the hard wallet time.

[0097] S410: The receiving terminal 104 determines whether the hardware wallet 102 maintains normal communication. If the communication has been disconnected, it prompts the user to re-insert the card until the instruction is completed or the timeout occurs before disconnecting the communication connection.

[0098] S411: The receiving terminal 104 sends a time calibration command to the hardware wallet 102.

[0099] S412: After receiving the time calibration command, hardware wallet 102 distributes the process key based on the current counter value, calculates the MAC value of the time factor using the process key, and verifies that the calculated MAC value matches the MAC value in the command. If they match, the verification passes. After the MAC verification passes, the hardware wallet's base time is updated to the time factor in the command. Alternatively, after the MAC verification passes, it checks whether the time in the time calibration command exceeds the current visible hardware wallet's base time by more than the fault tolerance step time (e.g., 1 minute). If it does, the time is updated; if it does not, no time change is required.

[0100] S413: The hardware wallet 102 returns the instruction execution result to the receiving terminal 104.

[0101] S414: The receiving terminal 104 sends the instruction execution result to the backend server 105. Once the backend server confirms the successful update based on the execution result, the original hardware wallet base time can be discontinued.

[0102] The above steps completed the calibration of the base time on the hardware wallet.

[0103] Scene 2

[0104] Figure 5 shows a flowchart of a time factor calibration method for digital currency transactions according to at least one embodiment of the present disclosure, Example 2. In this example, the hard wallet spontaneously verifies the hard wallet base time stored in the background, which involves the interaction between the visual hard wallet 102, the receiving terminal 104, and the backend server 105. The steps are described below with reference to Figure 5.

[0105] S401 to S402, S406, and S407 are similar to those in Scenario 1, and will not be described in detail here.

[0106] S403': The receiving terminal 104 sends an authorization information request instruction to the visual hardware wallet 102. The instruction may include a terminal random number, a terminal identifier, and a terminal time.

[0107] S504: After receiving the request instruction, the hard wallet 102 increments the counter value, uses the new counter value to disperse the hard wallet key to generate the process key, and uses the process key to perform MAC calculation on the setting information to obtain the MAC value. The setting information includes the hard wallet identifier, counter value, terminal random number, terminal identifier, terminal time, instruction identifier for calibrating the background time factor (generally the second instruction identifier), and hard wallet base time.

[0108] S505: The hardware wallet 102 sends authorization information to the receiving terminal 104. The authorization information includes the hardware wallet identifier, counter value, terminal random number, terminal identifier, terminal time, instruction identifier for calibrating the background time factor, hardware wallet base time, and MAC value calculated based on the above information.

[0109] S508: The backend server 105 verifies the MAC value in the authorization information. If the verification is successful, the identification instruction indicates that it is to calibrate the backend server time factor. Then, based on the terminal time T in the authorization information... T Hard wallet base time T w and the current time T in the background b Calculate the calibration time T (e.g., T = T). b -T T +T w After completing the time factor calibration on the backend, the calibration result is sent to the corresponding receiving terminal 104 according to the terminal identifier.

[0110] S509: The backend server 105 requests the response from the receiving terminal 104.

[0111] S510: The receiving terminal 104 receives the calibration processing results and displays the synchronization results to prompt the user.

[0112] The above steps completed the calibration of the base time on the backend server.

[0113] Scene 3

[0114] Figure 6 illustrates an operation flowchart of a time factor calibration method in a payment code transaction scenario according to Example 3 of at least one embodiment of the present disclosure. In this example, time factor calibration is performed simultaneously with scanning the payment code for a digital currency transaction, involving the interaction of the hardware wallet 102, the receiving terminal 104, and the backend server 105. The steps are described below with reference to Figure 6.

[0115] S601: The acceptance terminal 104 obtains the corresponding code information by scanning the payment code displayed on the visual hard wallet 102.

[0116] Specifically, the hardware wallet 102 pre-generates an offline payment code using the current local UTC time and key information. During a transaction, the user scans the payment code using the camera of the receiving terminal 104 to obtain the corresponding payment code information. The receiving terminal 104 then uses the scanned payment code information to initiate a payment request.

[0117] S603: The acceptance terminal 104 sends transaction information (including coded information) to the back-end of the acceptance agency.

[0118] The receiving institution's backend identifies the paying institution based on the institution identifier in the payment code information, thus determining that the transaction is not from their institution. The transaction can then be forwarded to the paying institution's backend through the interconnection platform. For simplicity, this example assumes the transaction is an internal institution transaction, and subsequent processing is directly handled by backend server 105.

[0119] S605: The backend server 105 verifies the correctness of the payment code based on the code information. If the verification passes and there is a step size deviation, the backend base time is updated and the transaction is processed. If the verification fails, an error code is returned to the receiving terminal 104, and the transaction is rejected.

[0120] Specifically, the backend server 105 first checks if the message (containing code information and transaction information) was uploaded within 60 seconds. If it times out, the transaction is rejected; otherwise, the following operations are performed to verify the payment code information:

[0121] (1) Verify that the institution identifier in the payment code is correct;

[0122] (2) Determine whether it is an online code or an offline code based on the code type;

[0123] (3) If it is determined to be an offline code, first derive the account index based on the payment code, then find the corresponding hardware wallet data based on the account index, and finally determine the payment code generation time T based on the hardware wallet data and the expected time T. QR The verification code information is calculated, and then compared with the verification code information in the payment code.

[0124] 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.

[0125] The timestamp (estimated time of payment code generation) T corresponding to the payment code is calculated using the following expression. QR 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 represents the timestamp at the time 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] The following is a detailed description of the S61 operation process shown in the dashed box in Figure 6—synchronizing the hardware wallet base time after payment code verification failure. This process 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 receiving terminal 104 sends a transaction instruction to the hard wallet 102, which contains a random number generated by the terminal.

[0133] S614: After receiving a transaction instruction, the hard wallet 102 increments the counter value, distributes the process key, and uses the process key to calculate the MAC value based on the setting information. The setting information includes the hard wallet identifier, counter, terminal random number, terminal identifier, and identifier representing the instruction to be issued.

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

[0135] S616: The receiving terminal 104 verifies whether the terminal random number is valid. If it is valid, proceed to step S617.

[0136] S617: The receiving terminal 104 sends transaction information to the receiving institution's backend. The receiving institution's backend identifies the hard wallet operator based on the hard wallet identifier and forwards the transaction information to the operator's backend server 105 through interconnection. The transaction information includes authorization information.

[0137] S618: The back-end server 105 of the operating institution finds the corresponding wallet data and key based on the wallet identifier, obtains the process key by distributing the key according to the counter in the authorization information, calculates the MAC using the process key, and identifies the instruction that needs to be issued after the MAC is verified. The operating institution organizes the issuance of APDU instruction. The instruction content may include the back-end current UTC timestamp (in seconds), echo information and MAC value, and forwards it to the back-end of the receiving institution through interconnection.

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

[0139] S6110: There may be a card disconnection error before or during the sending of the command. Therefore, it is necessary to determine whether the hardware wallet 102 maintains communication with the terminal 104. If a communication error occurs, the user needs to be reminded to re-insert the card.

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

[0141] S6112: The hardware wallet distributes the process key based on the current counter and calculates the MAC. It verifies the correctness of the MAC in the instruction. If correct, it checks whether the difference between the previously recorded timestamp and the current local timestamp is within the set time (e.g., 10 seconds). If so, it updates the internal time factor to the time factor in the message. Alternatively, after the MAC verification passes, it checks whether the time in the time calibration instruction exceeds the fault tolerance step time (e.g., 1 minute) compared to the current visible hardware wallet's base time. If it exceeds, the time is updated; if not, no time change is needed.

[0142] S6113: The hardware wallet 102 returns the instruction execution result to the receiving terminal 104.

[0143] Scene 4

[0144] In this example, time factor calibration is performed while conducting digital currency transactions contactlessly, which mainly includes the following steps.

[0145] Step 1: The visual hardware wallet 102 initiates a tap-to-transaction with the receiving terminal 104, establishing a communication connection and selecting hardware wallet applications for each other. The receiving terminal 104 then sends the transaction information to the receiving institution's backend.

[0146] Step 2: The receiving institution's back-end (such as the first server) identifies the paying institution based on the payment information. If the transaction is not made by this institution, it can be forwarded to the paying institution's back-end (such as the second server) through the interconnection platform.

[0147] Step 3: The payment institution verifies the transaction information in the background. If the verification is successful and the payment is deducted successfully, and the payment terminal is identified as a visual hardware wallet, the balance display operation is performed and the current time factor is returned. When returning the display instruction and time factor, the above information is encrypted and protected for integrity with a key before being sent to the acceptance terminal 104.

[0148] Step 4: After receiving the echo instruction and time factor from the receiving terminal 104, the visual hardware wallet 102 first performs key and integrity verification. If successful, it first checks whether the transmission and reception time of the instruction (the time difference between receiving the transaction instruction and receiving the echo instruction and time factor) is within the set time (e.g., 10 seconds). If successful, it then checks whether the time transmitted by the payment institution's backend exceeds the fault tolerance step time (e.g., 1 minute) compared to the current visual hardware wallet's base time. If it exceeds, the time is updated; if it does not exceed, no time change is needed. Alternatively, the hardware wallet's base information can be directly updated to the time factor.

[0149] It should be noted that the above application scenarios are merely exemplary in order to describe one or more aspects of the present invention in specific scenarios. However, these aspects are not essential, and various modifications can be made to the application scenario. The embodiments of this disclosure are not limited.

[0150] For example, at least one embodiment of this disclosure also provides a time factor calibration system for digital currency transactions. As shown in FIG1, the system includes a hardware wallet 102, a receiving terminal 104, and a back-end server 105.

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

[0152] For example, the receiving terminal 104 is configured to: receive authorization information for calibrating the time factor from the hardware wallet 102 in the interaction; send the authorization information to the backend server 105 in response to confirming that the authorization information is trustworthy; forward the time factor calibration instruction received from the backend server 105 to the hardware wallet 102, or receive the processing result of the backend server 105 performing the time factor calibration operation from the backend server.

[0153] For example, the backend server 105 is configured to perform the operation of generating a time factor calibration instruction or performing a time factor calibration operation based on the authorization information if the authorization information is confirmed to be trustworthy.

[0154] Since the details of the operation of the time factor calibration system 100 have already been introduced in the above description of the time factor calibration method for digital currency transactions, as shown in Figure 3, and the four application scenarios, they will not be repeated here for the sake of brevity. For relevant details, please refer to the above description of the method.

[0155] At least some embodiments of this disclosure also provide an electronic device. FIG7 shows a schematic diagram of an electronic device 800 according to at least one embodiment of this disclosure.

[0156] As shown in Figure 7, 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. These computer program modules 821 include instructions for executing a time factor calibration method 300 for digital currency transactions according to at least one embodiment of the present disclosure and its additional aspects. When executed by the processor 810, they can perform one or more steps of the time factor calibration method 300 for digital currency transactions according to at least one embodiment of the present disclosure. The memory 820 and the processor 810 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a Peripheral Component Interconnect Standard (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.

[0157] For example, processor 810 may be a central processing unit (CPU), a digital signal processor (DSP), or other processing unit with data processing and / or program execution capabilities, such as a field-programmable gate array (FPGA). Processor 810 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 800 to perform desired functions.

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

[0159] For example, electronic device 800 may also include input devices such as touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, and gyroscopes; output devices such as liquid crystal displays, speakers, and vibrators; storage devices such as magnetic tapes and hard disks (HDDs or SDDs); and communication devices such as network interface cards like LAN cards and modems. The communication devices allow electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via networks such as the Internet. A drive is connected to the I / O interface as needed. Removable storage media, such as disks, optical disks, magneto-optical disks, and semiconductor memories, are installed on the drive as needed so that computer programs read from them can be installed into the storage device as required.

[0160] For example, the electronic device 800 may further include a peripheral interface (not shown in the figure). This peripheral interface can be of various types, such as a USB interface, a Lightning interface, etc. The communication device can communicate wirelessly with networks and other devices, such as the Internet, intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). Wireless communication can use any of a variety 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.

[0161] The electronic device 800 may be, for example, a system-on-a-chip (SOC) or a device including the SOC. For instance, it can be any device such as a mobile phone, tablet, laptop, e-reader, game console, television, digital photo frame, navigator, home appliance, communication base station, industrial controller, server, etc., or any combination of data processing devices and hardware. The embodiments of this disclosure do not limit this. The specific functions and technical effects of the electronic device 800 can be found in the above description of the time factor calibration method 300 for digital currency transactions and its additional aspects according to at least one embodiment of this disclosure, and will not be repeated here.

[0162] Figure 8 shows a schematic diagram of a computer-readable medium 900 according to at least one embodiment of the present disclosure.

[0163] As shown in Figure 8, a computer-readable medium 900 stores computer instructions 910, which, when executed by a processor, perform one or more steps of the time factor calibration method 300 for digital currency transactions and its additional aspects as described above.

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

[0165] For example, the computer-readable medium may include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, and other computer-readable media or any combination thereof.

[0166] At least some of the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0167] It should be noted that, in this document, relational terms such as "first," "second," etc., are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0168] The following points should be noted regarding this disclosure:

[0169] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0170] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0171] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit the scope of protection of this disclosure, which is determined by the appended claims.

Claims

1. A time factor calibration method for digital currency transactions, the method comprising: The backend server receives authorization information for calibrating the time factor from the hardware wallet forwarded by the receiving terminal; In response to confirming that the authorization information is trustworthy, the backend server performs an operation to generate a time factor calibration instruction or to perform a time factor calibration operation based on the authorization information. as well as The backend server forwards the time factor calibration instruction to the hardware wallet via the receiving terminal so that the hardware wallet can perform the time factor calibration operation, or sends the processing result of the time factor calibration operation performed by the backend server to the receiving terminal.

2. The time factor calibration method according to claim 1, wherein, The authorization information includes a first instruction identifier. The backend server responds to the first instruction identifier by generating the time factor calibration instruction, which includes a time factor and a hard wallet verification value.

3. The time factor calibration method according to claim 1 or 2 further includes: The backend server receives the code information obtained by the acceptance terminal scanning the payment code provided by the hardware wallet, and confirms whether the code information is valid. as well as When the backend server confirms that the code information is invalid, it sends a first prompt message to the receiving terminal to prompt the user to perform the corresponding operation, so that the hardware wallet and the receiving terminal can interact to send the authorization information to the receiving terminal.

4. The time factor calibration method according to claim 3, wherein, The backend server performs at least one of the following operations to verify the code information in order to obtain a judgment result: Determine whether the reception time of the code information meets the set time range; Determine whether the organization identifier of the code information meets the requirements; as well as Verify whether the checksum in the code information is valid. If the judgment result is negative, the backend server confirms that the code information is invalid.

5. The time factor calibration method according to claim 4, wherein, The step of verifying whether the check code in the code information is valid includes: The account index is determined from the code information, and the corresponding hardware wallet data is found based on the account index; Calculate a first estimated time for generating the payment code based on the hard wallet data, and calculate a first verification code based on the first estimated time; and Verify whether the check code in the code information is consistent with the calculated first check code. If they are consistent, confirm that the check code is valid.

6. The time factor calibration method according to claim 5, wherein, The first estimated time is obtained based on the hardware wallet reference time stored on the backend server, the current time of the backend server, and the recording time of the hardware wallet reference time.

7. The time factor calibration method according to claim 6, wherein, When the check code in the code information is inconsistent with the calculated first check code, the following steps are performed: The first estimated time is processed based on the set time step to obtain the second estimated time, and the second check code is calculated based on the second estimated time. as well as Verify whether the check code in the code information is consistent with the calculated second check code. If they are consistent, confirm that the check code is valid.

8. The time factor calibration method according to claim 5 or 7, further comprising: The backend server updates the hardware wallet base time stored on the backend server to the time when the verification code is confirmed to be valid.

9. The time factor calibration method according to claim 1 or 2, wherein, The authorization information includes the second instruction identifier, the time of the receiving terminal, and the hardware wallet reference time; In response to the second instruction identifier, the backend server calculates the time factor to be calibrated based on the time of the receiving terminal, the reference time of the hard wallet, and the current time of the backend server. It then updates the reference time of the hard wallet stored on the backend server using the time factor to be calibrated and sends the processing result of the time factor calibration operation to the receiving terminal.

10. A time factor calibration method for digital currency transactions, the method comprising: The receiving terminal receives authorization information for calibrating the time factor from the hardware wallet in the interaction; If the receiving terminal confirms that the authorization information is trustworthy, it sends the authorization information to the backend server so that the backend server responds to the confirmation that the authorization information is trustworthy and performs the operation of generating the time factor calibration instruction or performing the time factor calibration operation based on the authorization information. The receiving terminal can forward the time factor calibration instruction received from the backend server to the hardware wallet so that the hardware wallet can perform a time factor calibration operation, or receive the processing result of the backend server performing the time factor calibration operation.

11. The time factor calibration method according to claim 10, wherein, When the receiving terminal receives the time factor calibration instruction, it determines whether the hardware wallet is in communication with the receiving terminal. If the communication is abnormal, it generates a second prompt message to remind the user to maintain communication between the hardware wallet and the receiving terminal.

12. The time factor calibration method according to claim 10 or 11, further comprising: The receiving terminal scans the payment code provided by the hardware wallet to obtain code information and sends it to the backend server to confirm whether the code information is valid. as well as The receiving terminal receives a first prompt message sent by the backend server to prompt the user to perform a corresponding operation, so that the hardware wallet and the receiving terminal interact to send the authorization information to the receiving terminal; The first notification message is sent by the backend server to the receiving terminal when it confirms that the code information is invalid.

13. A time factor calibration method for digital currency transactions, the method comprising: The hardware wallet sends authorization information for calibrating the time factor to the receiving terminal in the interaction; The hardware wallet receives a time factor calibration instruction generated by the backend server and forwarded by the receiving terminal. as well as Perform time factor calibration operation according to the time factor calibration instruction.

14. The time factor calibration method according to claim 13, wherein, The steps of the hardware wallet performing time factor calibration according to the time factor calibration instruction include a time difference determination step: Determine whether the time difference between the time factor in the time factor calibration instruction and the current hardware wallet reference time is greater than at least one set time step. If the determination result is greater than at least one set time step, update the hardware wallet reference time to the time factor.

15. The time factor calibration method according to claim 14, wherein, Before the hard wallet performs a time factor calibration operation according to the time factor calibration instruction, it also includes: Determine whether the time difference between sending the authorization information to the receiving terminal and the current hardware wallet reference time is less than a first set time range. If the determination result is less than the first set time range, then perform a time factor calibration operation.

16. The time factor calibration method according to claim 14, further comprising: The hardware wallet sends the authorization information in response to the digital currency transaction instruction sent by the acceptance terminal; The step of the hardware wallet performing time factor calibration operation according to the time factor calibration instruction further includes: Determine whether the time difference between receiving the time factor calibration instruction and receiving the digital currency transaction instruction is less than a second preset time range. If the determination result is less than the second preset time range, then execute the time difference determination step.

17. A time factor calibration system for digital currency transactions, the system comprising a hardware wallet, a receiving terminal, and a back-end server. The hardware wallet is configured to send authorization information for calibrating the time factor to the receiving terminal, and to receive a time factor calibration instruction from the receiving terminal to perform a time factor calibration operation. The receiving terminal is configured as follows: Receive authorization information for calibrating the time factor from the hardware wallet in the interaction; In response to confirming that the authorization information is trustworthy, the authorization information is sent to the backend server; as well as The time factor calibration instruction received from the backend server is forwarded to the hardware wallet, or the processing result of the time factor calibration operation performed by the backend server is received from the backend server. The backend server is configured to, in response to confirmation that the authorization information is trustworthy, perform an operation to generate a time factor calibration instruction or perform a time factor calibration operation based on the authorization information.

18. An electronic device comprising: One or more processors; as well as Memory, which stores one or more computer program modules. 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, When executed by one or more processors, computer-executable instructions are used to implement the method according to any one of claims 1-16.

Images