Digital-currency hardware wallet, transaction method, apparatus and system, and storage medium

Abstract

A digital-currency hardware wallet, a transaction method, apparatus and system, and a storage medium. The transaction method comprises: detecting a user input and acquiring detected user input information; on the basis of the current hardware-wallet time factor, a pre-stored key factor and an operation factor, calculating and generating an offline payment code that needs to be displayed in a first payment mode, so as to respond to a first instruction, and enabling or maintaining a second payment mode; alternatively, activating a transaction instruction of the second payment mode so as to respond to a second instruction, and enabling the first payment mode; displaying the offline payment code for an acceptance terminal to scan, so as to initiate a digital currency transaction in the first payment mode; and during the enabling of the second payment mode, checking the acceptance terminal, and sending a transaction instruction to the acceptance terminal by means of near-field communication, so as to initiate a digital currency transaction in the second payment mode.

Description

Digital currency hard wallets, transaction methods, devices, systems and storage media

[0001] This application claims priority to Chinese Patent Application No. 202410917960.8, filed on July 9, 2024, entitled "Transaction Method and Transaction System Based on Digital Currency Hard Wallet", and also claims priority to Chinese Patent Application No. 202510406403.4, filed on April 1, 2025, entitled "Transaction Method and Transaction System Based on Digital Currency Hard Wallet", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of digital currency technology, and in particular to a digital currency hard wallet, a digital currency back-end system, a transaction method, apparatus and system based on a digital currency hard wallet, and a non-transitory computer-readable storage medium. Background Technology

[0003] With the continuous development of computer technology and information security technology, digital currency wallets are being used in increasingly wider and more diverse scenarios.

[0004] Typically, cryptocurrency wallets include both soft wallets and hard wallets.

[0005] Hardware wallets typically facilitate cryptocurrency transactions in various scenarios via contactless transactions. However, current hardware wallet transaction models are relatively limited, necessitating the development of a new hardware wallet-based cryptocurrency transaction method. Summary of the Invention

[0006] In view of this, embodiments of the present disclosure provide a digital currency hard wallet, a digital currency back-end system, a transaction method, apparatus and system based on the digital currency hard wallet, and a non-transitory computer-readable storage medium that supports dual-channel payment modes, allowing users to select the appropriate payment mode as needed.

[0007] In a first aspect, at least one embodiment of this disclosure provides a digital currency hardware wallet, comprising: an input element configured to detect user input and acquire detected user input information, the user input information including a first instruction for initiating a first payment mode or a second instruction for initiating a second payment mode; a security element configured to: calculate and generate an offline payment code to be displayed for the first payment mode in response to the first instruction, based on a current hardware wallet time factor, a pre-stored key factor, and a computation factor, and initiate the second payment mode; or, activate a transaction instruction for the second payment mode in response to the second instruction, and initiate or maintain the first payment mode; a controller configured to control a display to show the offline payment code for scanning by an acceptance terminal to initiate a digital currency transaction in the first payment mode; and a near-field communication circuit configured to, during the initiation of the second payment mode, detect the acceptance terminal and send a transaction instruction to the acceptance terminal via near-field communication to initiate a digital currency transaction in the second payment mode; wherein the key factor and computation factor are information received in advance from the digital currency backend system and stored in the security element through a secure channel between the digital currency backend system and the hardware wallet, and are identical to the information stored in the digital currency backend system.

[0008] Secondly, at least one embodiment of this disclosure provides a digital currency backend system, comprising: a key generation module configured to generate key factors for calculating offline payment codes and associated with and stored in association with the hard wallet data corresponding to the hard wallet; a calculation factor generation module configured to generate calculation factors for calculating offline payment codes and associated with and stored in association with the hard wallet data; a communication module configured to establish a secure channel with the hard wallet and send key factors and calculation factors to the corresponding hard wallet through the secure channel based on the hard wallet data; and a business management module configured to maintain the mapping relationship between key factors, calculation factors, and hard wallet data, and to use the mapping relationship to verify the code information of the offline payment code in the received digital currency transaction information of the first payment mode, and to execute digital currency transaction processing after the verification is passed.

[0009] Thirdly, at least one embodiment of this disclosure provides a transaction system based on a digital currency hard wallet, including: a digital currency hard wallet provided according to at least one embodiment of this disclosure, and a digital currency back-end system provided according to at least one embodiment of this disclosure.

[0010] Fourthly, at least one embodiment of this disclosure provides a transaction method based on a digital currency hard wallet, executed by the digital currency hard wallet. The method includes: detecting user input and acquiring the detected user input information, the user input information including a first instruction for initiating a first payment mode or a second instruction for initiating a second payment mode; calculating and generating an offline payment code required for display in the first payment mode in response to the first instruction based on the current hard wallet time factor, a pre-stored key factor, and a calculation factor, and initiating or maintaining the second payment mode; or, activating a transaction instruction for the second payment mode in response to the second instruction and initiating the first payment mode; the hard wallet controls a display to show the offline payment code for scanning by an acceptance terminal to initiate a digital currency transaction in the first payment mode; and, during the initiation of the second payment mode, detecting the acceptance terminal and sending a transaction instruction to the acceptance terminal via near-field communication to initiate a digital currency transaction in the second payment mode; wherein the key factor and the calculation factor are information received in advance from the digital currency backend system and stored in a secure element through a secure channel between the digital currency backend system and the hard wallet, and are identical to the information stored in the digital currency backend system.

[0011] Fifthly, at least one embodiment of this disclosure provides a transaction method based on a digital currency hard wallet, executed by a digital currency backend system. The method includes: receiving digital currency transaction information sent by an acceptance terminal; determining whether the digital currency transaction information was obtained through a first payment mode; and, if the determination result is that the digital currency transaction information was obtained through the first payment mode, determining hard wallet data based on the digital currency transaction information, verifying the code information of the offline payment code in the digital currency transaction information using the mapping relationship corresponding to the hard wallet data, and executing digital currency transaction processing after the verification is passed; wherein, the digital currency backend system pre-generates a key factor and a calculation factor for calculating the offline payment code, and associates and stores the key factor and the calculation factor with the hard wallet data corresponding to the hard wallet to form a mapping relationship.

[0012] In a sixth aspect, at least one embodiment of this disclosure provides a transaction device based on a digital currency hard wallet, comprising: 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 the transaction method provided according to at least one embodiment of this disclosure.

[0013] In a seventh aspect, at least one embodiment of the present disclosure provides a non-transitory computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by one or more processors, implement a transaction method provided according to at least one embodiment of the present disclosure.

[0014] The digital currency hard wallet, digital currency back-end system, transaction method, apparatus and system based on the digital currency hard wallet, and non-transitory computer-readable storage medium disclosed herein, compared with the contactless transactions of existing hard wallets, support a dual-channel payment mode using NFC and payment code. Users can select the appropriate payment mode as needed, realizing a new type of digital currency transaction mode based on hard wallet. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the prior art and the embodiments of this disclosure, the accompanying drawings used in the description of the prior art and the embodiments of this disclosure will be briefly introduced below. Of course, the accompanying drawings described below with reference to the embodiments of this disclosure are only a part of the embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort, and the obtained other drawings also fall within the protection scope of this disclosure. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure.

[0016] Figure 1 shows a block diagram of a transaction system based on a digital currency hard wallet according to an embodiment of the present disclosure;

[0017] Figure 2 shows a block diagram of an exemplary visual card hard wallet according to an embodiment of the present disclosure;

[0018] Figure 3 shows a block diagram of an exemplary digital currency back-end system according to an embodiment of the present disclosure;

[0019] Figure 4 shows a flowchart of a transaction method based on a digital currency hard wallet according to an embodiment of the present disclosure;

[0020] Figure 5 illustrates a schematic diagram of an exemplary visual card hard wallet display content switching according to an embodiment of the present disclosure;

[0021] Figure 6 illustrates a flowchart of an exemplary method for switching the display content of a visual card hard wallet according to an embodiment of the present disclosure;

[0022] Figure 7 shows a flowchart of a time factor calibration method for digital currency transactions according to an embodiment of the present disclosure;

[0023] Figure 8 shows a flowchart illustrating an exemplary transaction method based on a digital currency hard wallet according to an embodiment of the present disclosure;

[0024] Figure 9 shows a schematic diagram of a transaction device based on a digital currency hard wallet according to an embodiment of the present disclosure;

[0025] Figure 10 shows a schematic diagram of a non-transitory computer-readable storage medium according to an embodiment of the present disclosure. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0027] Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms “first,” “second,” and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, terms such as “comprising” or “including” mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as “connected” or “linked” are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as “upper,” “lower,” “left,” and “right” are used only to indicate relative positional relationships, which may change accordingly when the absolute position of the described objects changes.

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

[0029] Digital currency wallets can be categorized into software wallets and hardware wallets. Software wallets refer to wallet services provided through smart applications that support digital currencies; they can be understood as existing in the form of an application (App). Examples include digital wallets within digital currency apps and digital wallets within bank apps. Hardware wallets, on the other hand, are physical media for storing digital currencies, opened through over-the-counter or electronic channels. They are digital currency carriers with a secure element (SE) and also possess basic functions such as withdrawal, redemption, top-up, withdrawal, spending, transfer, and inquiry. Examples include mobile phones, NFC-SIM cards, IC cards, and wearable devices with secure elements. This disclosure primarily focuses on IC cards with secure elements.

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

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

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

[0033] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution 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.

[0034] Currently, cryptocurrency hardware wallets generally use contactless transactions, such as completing a cryptocurrency transaction by simply tapping the wallet against a terminal, which is very convenient. However, the current transaction model is relatively simple, and there is a need to provide a new type of transaction method based on hardware wallets.

[0035] This disclosure provides a digital currency hard wallet, a digital currency back-end system, a transaction method, apparatus and system based on the digital currency hard wallet, and a non-transitory computer-readable storage medium, which supports a dual-channel payment mode using NFC and payment code. Users can select the appropriate payment mode as needed, realizing a new type of digital currency transaction mode based on a hard wallet.

[0036] The embodiments and some examples of this disclosure will now be described in detail with reference to the accompanying drawings.

[0037] Figure 1 shows a block diagram of a transaction system 100 based on a digital currency hard wallet (hereinafter referred to as a hard wallet) according to an embodiment of the present disclosure. As shown in Figure 1, the transaction system 100 mainly includes a hard wallet 102, an acceptance terminal 104, and a digital currency back-end system 108.

[0038] In this embodiment, the hard wallet 102 can be a visual card hard wallet (hereinafter referred to as a "visual card") with display capabilities, including a secure element (SE chip) and a near field communication (NFC) card chip. For example, the hard wallet 102 can be a portable terminal capable of supporting NFC payment functionality, using 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 hard wallet also supports a QR code transaction mode, which can generate a dynamic offline payment code. The receiving terminal completes the digital currency transaction by scanning the payment code; the specific implementation method is detailed below.

[0039] Figure 2 shows a block diagram of an exemplary visual card hard wallet according to an embodiment of the present disclosure. As shown in Figure 2, the hard wallet 102 is a visual card that includes a security element 1021, a display 1022, a power module 1023, an input element 1024, a controller 1025, and a communication module 1026.

[0040] For example, input element 1024 may include components such as a touchscreen or keypad, configured to detect user input and acquire the detected user input information, and send the acquired user input information to security element 1021 or controller 1025. For example, input element 1024 may be a "soft switch," with an identifier bit recorded in the software program of the security element as a "switch," which is used to identify or control the opening or closing of a certain function or operation. The functions involved in this embodiment may include: (1) control of the full NFC function (e.g., transaction function and management function); (2) control of the NFC transaction function, but not control of the management function. These functions are controlled by security element 1021. After receiving the control command from controller 1025, security element 1021 performs the corresponding function opening / closing, such as closing the NFC transaction function. Operationally, it may include balance information display operation, balance information and payment code content switching operation, etc.

[0041] For example, in at least one embodiment of this disclosure, the input element 1024 detects user input including detecting long-press input or short-press input. "Long-press input" refers to a situation where the switch needs to be pressed continuously for a period of time (e.g., 3 seconds) to trigger the circuit to open or close. A corresponding signal is output only when the long-press voltage reaches a set value. This allows operation according to the user's intention, preventing accidental operation. For example, a user can long-press the button to send a signal to the device to initiate a digital currency transaction (e.g., scanning a QR code or NFC payment), or to open or close a visual card. "Short-press input" is a situation where a short press triggers the circuit to open or close, thereby triggering a corresponding signal. This allows for rapid response and convenient execution. For example, a short press can send a signal to the device to switch between displaying offline payment codes and balance-like information (e.g., wallet balance, transaction amount, transaction time, a prompt to check balance, transaction time, etc.).

[0042] As shown in Figure 2, the security element 1021 includes a hardware wallet application 1021A, a data storage area 1021B, and a code generation module 1021C. 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. The data storage area 1021B stores: wallet SEID, wallet ID, wallet control information, wallet transaction-related information, key authority certificates, and computation factors. The wallet ID can be a real wallet account ID or an associated code for a wallet account. The associated code ensures wallet data security and corresponds one-to-one with the wallet account. Keys include symmetric keys (e.g., key factors used to generate offline payment codes) and asymmetric keys. The code generation module 1021C is mainly configured to calculate and generate the offline payment code required for the QR code payment mode based on pre-stored key factors, computation factors, and the current hardware wallet time factor. In one example, the offline payment code includes code information containing the issuer identifier (institution identifier), code type, user index, and verification code. It may also include issuer extension bits for self-defined or subsequent expansion by the institution.

[0043] For example, an offline payment code can include any image or symbol generated offline that can be read, parsed, and manipulated by an electronic device. Some examples of payment codes include barcodes, Quick Response (QR) codes, military-grade UID codes, and any other suitable codes. This code is displayed to the receiving terminal for scanning when a user makes a digital currency payment. Furthermore, the offline payment code can be a dynamic QR code or barcode, which can be dynamically updated at set intervals during the transaction to protect fund security. When transmitted to the digital currency backend system 108, the code information of the offline payment code can be used as part of the transaction information to enable the backend system 108 to perform security verification of the transaction information.

[0044] For example, in some embodiments of this disclosure, the key factor and the operation factor are information transmitted by the digital currency backend system 108 through a secure channel with the hard wallet 102 and stored in the data storage area 1021B of the secure element 1021. The hard wallet time factor generally refers to the time stored inside the hard wallet (data storage area 1021B or other storage areas), such as UTC (Coordinated Universal Time), which is basically synchronized with the hard wallet time factor stored in the digital currency backend system 108. Of course, it can also be other times, such as the start time agreed upon in advance by the front end and the back end, which is not limited in this disclosure. In addition, considering the delay in information transmission, the UTC time will also be processed, for example, a 60-second time window is set, and the result of dividing the current UTC time by 60 seconds is used as the time factor for subsequent calculations.

[0045] The communication module 1026 is primarily connected to the receiving terminal 104, and its communication methods can include Bluetooth, near-field NFC, Wi-Fi, UWB, and mobile networks. In some examples, the communication module 1026 also communicates with the digital currency back-end system 108 through a secure channel, receiving the same keys and calculation factors stored in the back-end system 108.

[0046] In some examples, the communication module 1026 includes a near-field communication (NFC) circuit (not shown) configured to detect the accepting terminal 104 and send a transaction instruction to it via NFC during NFC payment mode activation. Specifically, when a user makes a payment transaction, if the user selects NFC payment mode, they bring their hard wallet close to the accepting terminal with the NFC sensing area tagged with the NFC tag. This allows the accepting terminal to be detected, and the NFC circuit then sends a transaction instruction to it via NFC, enabling contactless transactions at close range. Furthermore, the NFC circuit can also be configured to transmit information query instructions to the accepting terminal 104 via NFC even when NFC payment mode is disabled, allowing for operations such as querying balance information.

[0047] The "secure channel" mentioned above can be a network channel between two entities (such as a backend and a hardware wallet). It allows the two entities to communicate with each other securely without being eavesdropped on by a third entity or impersonated by a third entity as one of the two intended entities participating in the secure communication. By establishing a secure channel, sensitive information, such as keys and computation factors, can be securely transmitted between the two entities.

[0048] In some examples, the "secure channel" between the digital currency backend system 108 and the hard wallet 102 (communication module 1026) can be a communication channel using the receiving terminal 104 as the transmission medium, which implements integrity protection for key factors and operation factors during information transmission. In other examples, the communication module 1026 of the hard wallet 102 can also include modules supporting multiple communication network standards, such as 2G (GSM / GPRS), 3G (WCDMA / CDMA2000 / TD-SCDMA), 4G (LTE), and 5G, etc., so that the hard wallet 102 can directly establish a communication channel with the digital currency backend system 108, and also perform integrity protection processing on key factors and operation factors during transmission. Of course, other "secure channel" methods can also be used, and this disclosure does not limit them. "Integrity protection" can be achieved by signing or calculating the transmitted data using a communication key agreed upon by both parties, such as using an SM4 communication key to perform MAC protection on the data to be transmitted, thus ensuring the security of the transmitted data. Of course, other methods can also be used to implement integrity protection, and the embodiments of this disclosure do not limit them.

[0049] For example, the power module 1023 can power the hard wallet 102 and can be a lithium-ion battery or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc.

[0050] For example, controller 1025 can be a microcontroller unit (MCU) or a processor, configured to generate corresponding control instructions according to its internal control logic based on information sent by security element 1021 or input element 1024. Controller 1025 can call the display interface to display payment code and transaction amount / balance information on display 1022 through control instructions. For example, the control logic of the MCU controller may include: (1) receiving a signal to turn off the visual card NFC payment mode, generating corresponding control instructions and sending them to security element 1021, so that security element 1021 controls the use of NFC transaction instructions to ensure that NFC transaction instructions are not transmitted by NFC, but management information (such as a request to query the balance) can still be sent to prevent the use of unauthorized mobile terminals with digital currency applications installed to steal money by sticking cards everywhere. (2) receiving a signal to switch the display content, and completing the switching display of, for example, QR code and balance information.

[0051] In some examples, the display 1022 can be a visualization device specifically equipped for the hard wallet, or it can be a visualization device that is integrated into the medium that carries the hard 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., a segment code screen, a dot matrix screen, etc.), an e-ink screen, etc., as part of the hard wallet.

[0052] For example, in at least one embodiment of this disclosure, the display 1022 is further configured to display offline payment code, balance, transaction amount, transaction time, and remaining battery power, etc., according to control signals sent by the controller 1025.

[0053] For example, in at least one embodiment of this disclosure, user input information includes a first instruction for initiating a QR code payment mode (an example of a first payment mode) or a second instruction for initiating an NFC payment mode (an example of a second payment mode). The secure element 1021 is configured to calculate and generate an offline payment code required for display in the QR code payment mode based on the current hard wallet time factor, a pre-stored key factor, and a computation factor in response to the first instruction, and to initiate or maintain the NFC payment mode; or, to activate a transaction instruction for the NFC payment mode in response to the second instruction, and to initiate the QR code payment mode. The controller 1025 is configured to receive the offline payment code sent by the secure element 1021, generate, and send a control instruction to the display 1022 to control the display of the offline payment code. The display 1022 is configured to display the offline payment code for scanning by the acceptance terminal to initiate a digital currency transaction in the QR code payment mode in response to the control instruction from the controller 1025. The near-field communication circuit is configured to detect the acceptance terminal and send a transaction instruction to the acceptance terminal via near-field communication during the initiation of the NFC payment mode to initiate a digital currency transaction in the NFC payment mode. Thus, the hard wallet possesses at least two payment modes: QR code payment and NFC payment. After activation, it offers users a dual-channel payment option. The information displayed on the monitor (1022) allows users to intuitively understand the hard wallet's status, confirming its dual-channel capability. Users can then choose the appropriate payment mode, proposing a novel digital currency transaction model. Furthermore, choosing the QR code payment mode can reduce the risk of the hard wallet being fraudulently used.

[0054] In one example, when a user opens the hardware wallet by long-pressing the button, if the hardware wallet's default intention is to enable QR code payment mode, then the hardware wallet activates NFC payment mode while displaying the offline payment code on the display 1025. In other examples, when a user opens the hardware wallet by long-pressing the button, if the hardware wallet's default intention is to enable NFC payment mode, then the hardware wallet generates an offline payment code and displays it on the display 1025 to provide QR code payment mode while enabling NFC payment. In other examples, when a user opens the hardware wallet by long-pressing the button, the hardware wallet first enables NFC payment mode, and then when the user switches to displaying the offline payment code by short-pressing the button, since the offline payment code is generated and displayed on the display 1025 while maintaining NFC payment function, the effect of providing a dual-channel payment mode is also achieved. Of course, the above three examples can be designed according to actual needs, and this disclosure embodiment does not limit them.

[0055] In related technologies, unauthorized payment terminals (e.g., unauthorized mobile terminals with payment functions) can easily steal digital currency from hard wallets via contactless means simply by enabling the payment function, posing a transaction risk. The following embodiments of this disclosure provide a method to effectively prevent the theft of digital currency from hard wallets via contactless means, greatly improving transaction security.

[0056] For example, in at least one embodiment of this disclosure, user input information includes a third instruction for disabling the NFC payment mode. The controller 1025 is configured to send the third instruction to the secure element 1021. The secure element 1021 is also configured to disable the NFC payment mode in response to the third instruction, preventing transaction instructions in the NFC payment mode from being transmitted externally via near-field communication. It should be noted that this only disables or puts the transaction instructions in the NFC payment mode into a dormant state; it does not close the NFC communication channel and does not affect requests to send information queries externally. Moreover, since the user has disabled the NFC payment mode, i.e., there is no intention to execute a digital currency transaction, even if there is malicious fraudulent activity, the transaction will fail because the transaction instructions cannot be transmitted externally, thus improving transaction effectiveness. For example, when the visual card is powered off by pressing and holding a button, the controller 1025 sends a third instruction to the secure element 1021, and the secure element 1021 disables the NFC payment mode, causing the NFC payment instructions to change from an active state to an inactive state, such as a disabled or dormant state.

[0057] For example, in at least one embodiment of this disclosure, the user input information further includes a fourth instruction for switching the displayed content. The controller 1025 is also configured to, in response to the fourth instruction, control the display 1022 to display the switched first set content to prompt the user to establish communication between the hard wallet 102 and the receiving terminal 104; and control the display 1022 to display query information forwarded by the receiving terminal. The communication module 1026 is also configured to send an information query request to the receiving terminal 104 via near-field communication (NFC) and receive query information returned by the digital currency back-end system in response to the information query request, forwarded by the receiving terminal 104.

[0058] In one example, the query information includes cryptocurrency balance information. After the visual card is powered on, an offline payment code can be displayed by default, as shown by the QR code displayed on the display 1022 of the hard wallet 102 in the left image of Figure 5. Then, when the user triggers a balance information query operation by briefly pressing button 1024, text such as "Please tap your card to query your balance" will be displayed on the display 1022 to prompt the user to establish a communication connection between the hard wallet 102 and the receiving terminal 104, and send an information query request to the receiving terminal 104. Subsequently, the receiving terminal 104 forwards the information query request to the cryptocurrency backend system 108, which responds by returning query information to the receiving terminal 104. The receiving terminal 104 then sends the query information to the hard wallet 102 via near-field communication, and the hard wallet 102 displays the query information on the display 1022, as shown by the text "Balance: XXXXX" displayed on the display 1022 of the hard wallet 102 in the right image of Figure 5. The balance information displayed at this time is the one synchronized with the backend system 108.

[0059] For example, in at least one embodiment of this disclosure, the user input information further includes a fifth instruction for switching the display of the offline payment code. The security element 1021 is configured to, in response to the fifth instruction, recalculate and generate a new offline payment code based on the current hard wallet time factor, a pre-stored key, and a calculation factor; the controller 1025 is configured to control the display 1022 to display the new offline payment code.

[0060] In one example, as shown in the right image of Figure 5, if the current display shows balance information and the user wants to switch to offline payment code information, they can briefly press button 1024. The controller 1025 will then clear the balance information and display the newly generated payment code information, as shown on display 1022 in the left image of Figure 5. Furthermore, if the current display shows the offline payment code, a brief press of button 1024 will also clear the offline payment code and then display the balance information. In other words, the display of payment code and balance information can be switched by pressing a button, meeting the user's needs for different display content.

[0061] In some related solutions, visual cards lack convenient interactivity when displaying information. Too much interaction causes user confusion, while too little interaction only enables single-function display. Furthermore, if balance information and payment code information are displayed simultaneously on the visual card's screen, the currently displayed balance may not be synchronized with the backend, leading to inaccurate balance display. In this embodiment, by switching the content displayed separately on the monitor (as shown in Figure 5), the user is prompted to tap the card to retrieve accurate data, providing a better user experience.

[0062] The following example illustrates how a single button can be used to turn a visual card on / off, switch displays to show information (such as hard wallet balance and payment code), and update the display of information such as balance information by tapping the card with a payment terminal via NFC.

[0063] Figure 6 illustrates a flowchart of an exemplary method for switching the display content of a visual card hard wallet according to an embodiment of the present disclosure.

[0064] (1) Basic information display of the visual card: The visual screen can display the balance, offline payment code, transaction amount, and transaction time, and supports multiple languages. For example, if the user needs to know the wallet balance, they can press the button briefly to switch to the secondary screen, and then, according to the "Check Balance by Tapping Card" prompt information displayed on the visual card (S606), establish a connection between the visual card and the POS terminal or mobile APP via NFC card tapping, and update the balance information on the visual screen (S608). It supports updating the balance information when, for example, making a "tap-to-pay" payment on the POS terminal, checking the balance on the POS terminal, or reading the card by tapping on the mobile APP. If the information display or balance update fails, the visual screen will prompt the user to tap the card again to update.

[0065] (2) Press and hold the button to control the on / off state, and press the button briefly to control the screen switching. Pressing and holding the button activates the visual card (S602), triggering the first screen to display the offline payment code (S604). While activated, pressing the button briefly switches between displaying the payment code and balance information. NFC can also be used for transactions while activated, and query functions are not controlled by NFC on / off. For example, the visual screen displays "Press and hold the button to turn on," prompting the user to operate the buttons on the visual card accordingly. After activating the visual card, responding to the user's short button press, it displays information such as "Transaction Balance xxxx," "Wallet Balance xxxx," "Red Packet Balance xxxx," and time information in a preset style. This information can be displayed in a pre-set style (e.g., list format), and the font can be set for different content, such as Chinese font: bold, font size X; English font: Arial, font size X, etc.

[0066] (3) On / off display interaction of the visual card hard wallet: When the visual screen is off, it displays "On use". Press and hold the power button to turn on the visual screen (S602). After turning on, the first screen displays the offline payment code (S604). Press it again to switch to the second screen, which displays "Please stick the card to check the balance" (S606). Press and hold the power button again to turn off the visual screen (S610).

[0067] (4) Payment code display interaction: A new offline payment code is generated each time the video screen is opened, and it is refreshed once after being closed and reopened. To ensure the security of user funds, if the user remains on the payment code page without any operation, the offline payment code will be automatically erased after 60 seconds, but the video screen will not be closed (S605). The screen will display "Please press the button to display the QR code". The user can display the new offline payment code by pressing the button briefly (S604).

[0068] (5) Balance Display Interaction: After the video screen is turned on, the card is connected to the POS terminal or mobile APP via NFC card tapping. During the update, the video screen automatically displays "Transaction in progress, please do not move." After the update is completed, the video screen automatically displays the updated balance and the transaction information. Automatic closing interaction is not required on the balance display page. If there is no balance information on the video screen, or the balance information update fails, the video screen prompts the user to tap the card to update.

[0069] In addition, after the transaction is completed, the message "Transaction Completed" will be displayed on the screen to notify the user that the transaction is finished. When the SIM card's battery is low, different messages will be displayed on the screen depending on the situation. For example, during a transaction, the screen may display "Low battery, please replace the card," while outside of a transaction, it may display "Low battery, please charge." This effectively reminds users of the specific scenario and improves the user experience.

[0070] For example, in at least some embodiments of this disclosure, a display control method for a visual hardware wallet is also proposed. The method includes: receiving a display operation instruction, wherein the display operation instruction includes a display style modification instruction or a echo instruction, and the echo instruction is an instruction generated by the background based on transaction information after the transaction is completed to control the display hardware wallet to display transaction information; calling the corresponding control interface according to the display operation instruction, performing an operation corresponding to the display style modification instruction to modify the currently set display style, or performing an operation corresponding to the echo instruction to generate a control instruction to display transaction information according to the currently set display style, and driving the corresponding display area of ​​the hardware wallet's visual screen to display transaction information according to the currently set display style according to the control instruction; wherein the display style is a set composed of a display area style and a display content style.

[0071] For example, according to at least one embodiment of the display control method of this disclosure, the step of executing an operation corresponding to an echo instruction to generate a control instruction for displaying transaction information according to a currently set display style includes: calling a display control interface in response to an echo instruction; determining a corresponding display area number and display content number according to a currently set display style number; searching for display content corresponding to the display content number; determining a display area to be driven according to the display area number; and generating a control instruction based on the display content and the display area.

[0072] For example, according to at least one embodiment of the display control method of this disclosure, the display area style is a first display area style of horizontally dividing display units, a second display area style of vertically dividing display units, or a third display area style of grid-dividing display units, and each display area is provided with a display area number; the display content style consists of at least one display content selected from a set pattern, a text template, and a QR code, and each display content is provided with a display content number; the text template is further provided with a character library, a number library, and a symbol library, and the elements in each library are provided with element numbers; the display style is provided with a display style number, and each display style number corresponds to a set composed of the display area number and the display content number.

[0073] For example, in the display control method according to at least one embodiment of the present disclosure, the text template includes text content for representing transaction amount and balance, and according to different stages of the transaction process, the digital element corresponding to the transaction amount or balance of the current stage is determined, and control instructions are generated according to the digital element and display style to drive the display area for displaying transaction amount or the display area for displaying balance separately.

[0074] For example, according to at least one embodiment of the display control method of this disclosure, the method further includes: generating transaction information according to a transaction instruction; determining whether the currently set display style contains a text template related to the transaction information; if the determination is yes, extracting the relevant elements from the transaction information, and generating a control instruction based on the extracted elements and the display style.

[0075] For example, in the display control method according to at least one embodiment of the present disclosure, the text template includes text content for representing transaction amount and balance, and according to different stages of the transaction process, the digital element corresponding to the transaction amount or balance of the current stage is determined, and control instructions are generated according to the digital element and display style to drive the display area for displaying transaction amount or the display area for displaying balance separately.

[0076] The display control method in some embodiments of this disclosure can flexibly control the displayed content and display area, and in particular solves the problem that hard wallets cannot change the displayed pattern, content format and position after issuance.

[0077] For example, in at least one embodiment of this disclosure, the hardware wallet further includes a timer (not shown), configured to start timing when an information query request is sent; the controller 1025 is further configured to, if the timer reaches a first preset time and no query information is received, control the display 1022 to display second preset content to prompt the user to re-establish communication between the hardware wallet 102 and the receiving terminal 104 and send an information query request. For example, the first preset time can be set to 60 seconds. If no query information is received, the display 1022 will display text such as "Query failed, please tap the card again to query," prompting the user to re-establish communication between the hardware wallet 102 and the receiving terminal 104 and send an information query request to the receiving terminal 104 for another information query.

[0078] For example, in at least one embodiment of this disclosure, the timer is further configured to start timing when the display 1022 shows the offline payment code. When the timer reaches a second preset time, the controller 1025 controls the display to clear the offline payment code or display preset content. For example, if the timer reaches a preset time (e.g., 60 seconds), the controller 1025 controls the display 1022 to clear the offline payment code or display preset content. The payment code can be automatically erased from the display after, for example, 60 seconds, or updated with text prompts such as "Please press the button to display the payment code" to indicate that the user can display a new payment code by briefly pressing a button. This ensures the security of the user's funds.

[0079] 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 (e.g., a mobile phone) with a hardware wallet application (APP) for transactions with the hardware wallet. DC / EP transactions refer to digital currency / electronic payment transactions, which are the technological ecosystem used to support the operation of the digital RMB. In addition to 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 the user's settings or the situation of the counterparty. In this embodiment of the disclosure, the acceptance terminal 104 can communicate with the hardware wallet 102 in a contactless manner via NFC. By using NFC, the acceptance terminal 104 can perform the following functions with the hardware wallet 102: contactless mobile payment, security authentication, and data exchange. Moreover, the acceptance terminal 104 also includes sensors (such as cameras and / or vision sensors) to scan the payment code generated by the hardware wallet 102 and transmit it to the back-end system 108 for processing to complete the digital currency transaction.

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

[0081] In this embodiment, the digital currency back-end system 108 is a back-end system supporting digital currency payment functions. It may include a back-end server of the payment and collection operation institution and an interconnection platform, supporting digital currency transactions within the institution and across institutions. The digital currency back-end system 108 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 digital currency back-end system 108 may be composed of server computer hardware, the specifics of which will not be elaborated further.

[0082] In most cases, the digital currency back-end system 108 may include an acceptance institution back-end and a payment institution back-end, both of which can process digital currency transactions within their respective institutions and generate echo instructions based on the display capabilities of the hardware wallet. To facilitate information exchange among multiple operating institutions, in this embodiment of the disclosure, the digital currency back-end system 108 also includes an interconnection system or server that communicates with the systems or servers corresponding to each operating institution.

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

[0084] In addition to the above, the issuer (not shown) is also involved. When issuing certain hardware wallets, the issuer will write user information, 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.

[0085] Figure 3 shows a block diagram of an exemplary digital currency back-end system according to an embodiment of the present disclosure. Since the digital currency back-end system is either an acquiring institution back-end or a payment institution back-end, the functional modules comprising the digital currency back-end system will be described below with reference to Figure 3.

[0086] As shown in Figure 3, the digital currency backend system 108 includes a key generation module 108A, a computation factor generation module 108B, a business management module 108C, and a communication module 108D. The key generation module 108A is configured to generate key factors for calculating offline payment codes and stores them in association with the corresponding hardware wallet data. The computation factor generation module 108B is configured to generate computation factors for calculating offline payment codes and stores them in association with the hardware wallet data. The communication module 108D is configured to establish a secure channel with the hardware wallet and send key factors and computation factors to the corresponding hardware wallet through the secure channel based on the hardware wallet data. The business management module 108C is configured to maintain the mapping relationship between key factors, computation factors, and hardware wallet data, and use this mapping relationship to verify the code information of the offline payment code in the received digital currency transaction data of the QR code payment mode. After successful verification, the digital currency transaction is processed.

[0087] For example, in at least one embodiment of this disclosure, the code information of the offline payment code may include an organization identifier, code type, user (account) index, and verification code. The business management module 108C 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) Determine whether the reception time of the code information meets the set time range; (2) Determine whether the organization identifier of the code information meets the requirements; (3) Verify whether the verification code in the code information is valid. By verifying item (1), it can be determined whether the reception 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 reception time of the code information has expired, the code information is invalid, and the transaction is rejected. By verifying item (2), the operating institution to which the hard wallet belongs can be confirmed according to the organization identifier. Only when it is determined that the institution or the corresponding code number conforms to the corresponding organization identifier 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 time factor of the hard wallet is consistent with the time factor of the hard wallet stored in the background. 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.

[0088] For example, in at least one embodiment of this disclosure, the step of determining whether the verification code in the verification code information is valid includes: determining the user index from the code information, searching for the corresponding hardware wallet data based on the user index; calculating the first estimated time for generating the payment code based on the hardware wallet data, and searching for the corresponding key and operation factor using the mapping relationship; calculating the first verification code based on the key, operation factor, and the first estimated time; checking whether the verification code in the verification code information is consistent with the calculated first verification code; if they are consistent, confirming that the verification code is valid, performing digital currency transaction processing, and returning the transaction execution result to the acceptance terminal.

[0089] The backend system 108 stores hardware wallet data for different hardware wallets. This data is retrieved using a hardware wallet account index. In one example, the hardware wallet data includes at least a wallet ID, wallet name, and wallet validity period, and may also include hardware wallet time factors and timestamps recording these time factors. This hardware wallet data can be stored in association with keys and payment code operation factors, forming a mapping relationship. For example, in at least one embodiment of this disclosure, the backend system 108 (business management module 108C) obtains a first estimated time based on the hardware wallet time factors stored in the backend system, the current time of the backend system, and the recording time of the hardware wallet time factors. The first estimated time is the estimated time when the currently received payment code is generated on the hardware wallet side. Then, the mapping relationship is used to find the key factor and operation factor corresponding to the hardware wallet account. A first verification code is obtained by calculating the key factor, operation factor, and the calculated first estimated time. The first verification code is compared with the verification code in the code information to determine its validity. If valid, the transaction is processed, indicating that the time factor on the hardware wallet side and the time factor on the backend system side are consistent. Therefore, a digital currency transaction is performed without triggering a time factor calibration operation.

[0090] For example, in at least one embodiment of this disclosure, 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.

[0091] 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. If 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 are consistent, 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 the new second estimated time. The new second estimated time is then used to calculate the new second checksum. If the new second checksum is consistent with 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.

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

[0093] For example, in at least one embodiment of this disclosure, the backend system 108 (business management module 108C) updates the locally recorded hardware wallet time factor 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 time factor stored in the backend and the time factor on the wallet side—that is, the verification only passes by adding or subtracting a set step size from the first estimated time—then the hardware wallet time factor recorded in the backend is adjusted to the time when the verification passed. 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 time factor recorded in the backend is updated to the first estimated time (or the second estimated time). In this way, the time factors of the backend and the hardware wallet can be synchronized, and there is no need to trigger a separate calibration operation for the backend time factor.

[0094] In QR code transactions, the visual hardware wallet needs to generate an offline payment code. This generation relies on the time factor stored internally within the hardware wallet. Therefore, ensuring the synchronization of the hardware wallet's time factor with the time factor recorded by the backend system is crucial. If they are not synchronized, the payment code will fail verification in the backend system, resulting in transaction failure.

[0095] For example, in one embodiment of this disclosure, if the backend system 108 (business management module 108C) verifies the payment code as invalid, it transmits a prompt message to the acceptance terminal 104 to prompt the user to perform the corresponding operation, causing the hard wallet 102 (secure element 1021) and the acceptance terminal 104 to interact and transmit authorization information to the acceptance terminal 104. Specifically, if the code information is invalid, the backend system 108 will send a prompt message such as "Please swipe card for inquiry" or "Please swipe card for transaction" to the acceptance terminal 104. The user will then place the hard wallet 102 close to the acceptance terminal 104, enabling the hard wallet 102 and the acceptance terminal 104 to establish near-field communication. The hard wallet 102 responds to the request instruction, inquiry instruction, or transaction instruction of the acceptance terminal 104 and sends authorization information for calibrating the time factor to the acceptance terminal 104.

[0096] Figure 7 shows a flowchart of a time factor calibration method 300 for digital currency transactions according to an 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.

[0097] In step S310, the receiving terminal 104 receives authorization information for calibrating the time factor from the hardware wallet 102 (secure element 1021) in the interaction.

[0098] In step S312, if the acceptance terminal 104 confirms that the authorization information is trustworthy, it transmits the authorization information to the backend system 108 (business management module 108C).

[0099] In step S314, the time factor calibration instruction received by the receiving terminal 104 from the back-end system 108 (business management module 108C) is forwarded to the hard wallet 102 so that the hard wallet 102v performs the time factor calibration operation.

[0100] For example, in step S310, the hardware wallet 102 (secure element 1021) 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 time factor on the hardware wallet side and / or the hardware wallet time factor on the backend system side during the transaction execution. In the case of self-initiation, the hardware wallet 102 may calibrate the time factor on the hardware wallet side or the backend side by establishing communication with the receiving terminal 104 and querying information (such as balance information) in a manner similar to tapping a card. Alternatively, it may directly send authorization information to the receiving terminal 104 after establishing communication interaction to calibrate the time factor on the hardware wallet side or the backend side. 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.

[0101] 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 system to issue a time factor calibration instruction to calibrate the hard wallet time factor 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 time factor may be inconsistent with the hard wallet time factor stored in the backend system due to power outages or other factors, thus requesting the backend system to synchronize the hard wallet's time factor according to its own stored hard wallet time factor. The backend system 108 (business management module 108C) confirms that the authorization information is trustworthy and then executes the operation of generating a time factor calibration instruction based on the first instruction identifier in the authorization information.

[0102] The statement that "the authorized information is trustworthy" can be understood as meaning that the authorized information has been 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 check or information value (such as random number) comparison; the specific method is not limited.

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

[0104] For example, in at least one embodiment of this disclosure, in method 300, the backend system 108 (business management module 108C) 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 system 108 (business management module 108C) 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 system 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).

[0105] For example, in at least one embodiment of this disclosure, in method 300, the authorization information includes a first instruction identifier, indicating that when the backend system 108 (business management module 108C) is requested to issue a time factor calibration instruction, the backend system 108 (business management module 108C) responds to the first instruction identifier by generating a time factor calibration instruction containing a time factor and a hard wallet verification value, and transmits the time factor calibration instruction to the receiving terminal corresponding to the terminal identifier; then, the receiving terminal 104 transmits the time factor calibration instruction to the hard wallet 102; the hard wallet 102 confirms that the hard wallet verification value is valid, and then performs a time factor calibration operation according to the time factor calibration instruction. In this process, after the hard wallet 102 receives the time factor calibration instruction, it extracts the hard wallet verification value from the instruction, such as the MAC value, and determines whether the hard wallet verification value is valid by comparing the calculated MAC value with the MAC value extracted from the instruction, 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 the last step involves information verification, the trustworthiness verification of the information is generally not required at the acceptance terminal 104. Of course, a verification step can be set up as needed.

[0106] 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 time factor is greater than at least one set time step; if the judgment result is greater than at least one set time step, then the hardware wallet time factor is updated to the correct 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 time factor stored in the background and the time factor of the hardware wallet are not completely consistent, 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 time factor of hardware wallet 102 can be directly updated to the time factor in the time factor calibration instruction.

[0107] 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 interaction with the receiving terminal 104. If it is determined that the communication is abnormal, a prompt message is provided to ensure that the hardware wallet 102 maintains communication with the receiving terminal 104. To achieve synchronization of the hardware wallet's time factor, 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.

[0108] For example, in at least one embodiment of this disclosure, in method 300, before the hardware wallet (controller 1025) 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 hardware wallet time factor 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 hardware wallet receives an instruction to return authorization information, it records the current local time of the hardware wallet while generating the authorization information; when the hardware wallet receives the time factor calibration instruction, it determines whether the current local time of the hardware 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 hardware 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.

[0109] 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 further 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 time factor 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 time factor is updated to the time factor. In one example, after the hardware wallet 102 (controller 1025) 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 instruction. 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 time factor of the hardware wallet updated by the background instruction to deviate from the time factor in the hardware wallet to within 10 seconds. If it is determined that the time is satisfied, it is determined that the time transmitted by the background and the current time factor of the hardware wallet differ from each other by at least one fault tolerance step (e.g., 60 seconds). If it exceeds this, the time factor of the hardware wallet is updated; if it does not exceed this, no time change is required. This reduces the possibility of the payment code background verification becoming invalid due to the hardware wallet timer continuously accumulating a large offset.

[0110] When opening a wallet account, a user index and a random number are typically issued for each hardware wallet account. The user index is generally composed of 8 digits, and there are approximately 100 million hardware wallet accounts available. Considering the increase in new users, the number of user indexes cannot meet the demand. This disclosure proposes a new method that can retain the 8-digit user index while accommodating the addition of new users.

[0111] For example, in at least one embodiment of this disclosure, the operation factor includes a random number and a user index. The business management module 108C is also configured to determine whether a hard wallet account has expired based on the hard wallet data; if expired, it will then transfer the hard wallet account to the appropriate location.

[0112] For example, in at least one embodiment of this disclosure, the business management module 108C is further configured to verify the received digital currency transaction information of the second payment mode, execute the digital currency transaction processing after the verification is successful, and return the transaction execution result and optionally the echo instruction to the acceptance terminal. The echo instruction is forwarded by the acceptance terminal to the hardware wallet to display the balance information after the transaction. The business management module 108C only organizes and generates the echo instruction when the NFC transaction mode is in effect and the hardware wallet has display capabilities, and then sends it to the acceptance terminal together with the transaction execution result. If the NFC transaction mode is in effect but the hardware wallet does not have display capabilities, no echo instruction is sent, and only the transaction execution result is sent to the acceptance terminal.

[0113] For example, in one instance, NFC-mode digital currency transaction information is encrypted information containing a MAC value. The business management module 108C of the digital currency back-end system 108 performs MAC value verification and decryption processing on the received NFC-mode digital currency transaction information, executes the digital currency transaction processing based on the decrypted transaction information, generates the transaction execution result, and if the hardware wallet is detected to have display capabilities, also generates an echo instruction, and sends the generated transaction execution result and echo instruction together to the receiving terminal.

[0114] For example, in at least one embodiment of this disclosure, the business management module 108C is further configured to determine whether the current digital currency transaction is a password-free transaction or a small-amount transaction based on the digital currency transaction data. Specifically, the business management module 108C can determine whether the hardware wallet defaults to password-free transactions or small-amount transactions based on the hardware wallet identifier in the digital currency transaction data. If it does, the corresponding transaction processing is executed; otherwise, a transaction failure result is returned. This allows for transaction risk control.

[0115] Figure 4 shows a schematic flowchart of a transaction method based on a digital currency hard wallet according to an embodiment of the present disclosure. The various steps of the method will be described below with reference to Figure 4.

[0116] In step S401, the hard wallet 102 detects user input and obtains the detected user input information, wherein the user input information includes a first instruction for initiating a first payment mode or a second instruction for initiating a second payment mode.

[0117] In step S403, if the hard wallet 102 detects the first instruction, it calculates and generates the offline payment code required to be displayed in the first payment mode in response to the first instruction based on the current hard wallet time factor, the pre-stored key factor and the operation factor, and starts or maintains the second payment mode.

[0118] In step S403', if the hard wallet 102 detects the second instruction, it activates the transaction instruction of the second payment mode in response to the second instruction and starts the first payment mode.

[0119] By following the steps above, the Hard Wallet 102 offers a choice of dual-channel payment modes.

[0120] In step S405, the hardware wallet 102 generates a control instruction to control the display of the offline payment code, and displays the offline payment code according to the control instruction for the acceptance terminal to scan in order to initiate a digital currency transaction in the first payment mode.

[0121] In step S405', during the second payment mode activation, the hardware wallet 102 detects the acceptance terminal 104 and sends a transaction instruction to the acceptance terminal 104 via near-field communication to initiate a digital currency transaction in the second payment mode.

[0122] It should be noted that the digital currency back-end system 108 pre-generates the key and operation factor for calculating the offline payment code, and stores them in association with the hard wallet data corresponding to the hard wallet 102; the digital currency back-end system 108 establishes a secure channel with the hard wallet 102, and sends the key factor and operation factor to the corresponding hard wallet 102 through the secure channel according to the hard wallet data, and the hard wallet 102 stores the key and operation factor into the secure element.

[0123] In the digital currency back-end system, if digital currency transaction data for the first payment mode is received, the system verifies the offline payment code information in the transaction data using the relationship between the key factor, operation factor, and hardware wallet data maintained by the system. Once the verification is successful, the digital currency transaction is completed, and the transaction execution result is returned to the receiving terminal. If digital currency transaction information for the second payment mode is received, it is verified (e.g., data integrity verification). Once the verification is successful, the digital currency transaction is processed, and the transaction execution result and optionally an echo instruction are returned to the receiving terminal. The echo instruction is forwarded by the receiving terminal to the hardware wallet to display the post-transaction balance information.

[0124] The embodiment of the method shown in Figure 4 is basically similar to the aforementioned embodiment of the transaction system based on digital currency hard wallets, so it will not be repeated here. For relevant details, please refer to the description in the system embodiment section.

[0125] Figure 8 shows a flowchart illustrating an exemplary transaction method based on a digital currency hard wallet according to an embodiment of the present disclosure.

[0126] As shown in Figure 8, the digital currency backend system 108 generates and stores a symmetric key and a computation factor. It then encrypts the symmetric key, computation factor, and hard wallet data through a secure channel and transmits them with integrity protection to the secure element SE 1021 of the visual card hard wallet 102 for activation. Simultaneously, the backend system 108 maintains the mapping relationship between the key, computation factor, and hard wallet data.

[0127] After the user triggers the visual card input element 1024, the SE 1021 of the visual card hard wallet 102 receives the request, generates an offline QR code through the time factor, symmetric key, and operation factor, and returns it to the visual card controller 1025 and displays it on the display 1022. At the same time, the visual card activates the payment command to enable NFC payment, ensuring that dual-channel payment is available.

[0128] When the user switches between offline QR code and balance display by triggering the visual card input element 1024, the visual card controller 1025 displays the offline QR code or balance on the display 1022.

[0129] Users can disable the visual card by triggering the visual card-input element 1024, thus making payment instructions unavailable and ensuring that NFC transaction instructions are not transmitted via NFC.

[0130] If a user taps the NFC device after activation, the digital currency backend system 108 verifies the NFC payment information. If the verification confirms that it is an NFC mode (tap-to-pay) transaction and the hard wallet has display capability, it organizes a balance display instruction, returns the display instruction and payment result to the acceptance terminal 104, and updates the visual card display. The displayed content must include at least the current balance.

[0131] If a user makes a payment using an offline QR code, the card will be cleared or other content will be displayed after the expiration date, according to the validity period set by the card's internal clock. The user can refresh the offline QR code by triggering the input element 1024 again.

[0132] The receiving terminal 104 sends the payment information, i.e., offline QR code or NFC payment information, to the payee's backend through a secure channel. If it determines that the payment is from the same institution, it performs relevant verification and deductions. If it determines that the payment is from a different institution, it forwards the information to the paying institution for verification and deduction through the interoperability platform. If it is a QR code payment method, the deduction result is sent to the receiving terminal 104.

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

[0134] At least some embodiments of this disclosure also provide a transaction device based on a digital currency hard wallet. Figure 9 shows a schematic diagram of a transaction device 900 according to an embodiment of this disclosure.

[0135] As shown in Figure 9, the trading device 900 includes one or more processors 910 and a memory 920. The memory 920 includes one or more computer program modules 921. The one or more computer program modules 921 are stored in the memory 920 and configured to be executed by the processor 910. These computer program modules 921 include instructions for performing a method and additional aspects thereof according to at least one embodiment of the present disclosure. When executed by the processor 910, they can perform one or more steps of the method and additional aspects thereof according to at least one embodiment of the present disclosure. The memory 920 and the processor 910 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus may 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.

[0136] For example, processor 910 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 910 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in trading device 900 to perform desired functions.

[0137] Exemplarily, memory 920 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 921 may be stored on the computer-readable storage medium, and processor 910 may run one or more computer program modules 921 to implement various functions of transaction device 900. 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.

[0138] For example, the transaction device 900 may also include input devices such as a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, and gyroscope; output devices such as a liquid crystal display, speaker, and vibrator; storage devices such as magnetic tape and hard disk (HDD or SSD); and communication devices such as network interface cards such as LAN cards and modems. The communication devices allow the transaction device 900 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via a network 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.

[0139] For example, the transaction device 900 may further include a peripheral interface (not shown in the figure). This peripheral interface can be various types of interfaces, 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.

[0140] The transaction device 900 can 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 computer, laptop computer, 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 transaction device 900 can be found in the foregoing description of the method and its additional aspects according to at least one embodiment of this disclosure, and will not be repeated here.

[0141] Figure 10 shows a schematic diagram of a non-transitory computer-readable storage medium 1000 according to an embodiment of the present disclosure.

[0142] As shown in Figure 10, a non-transitory computer-readable storage medium 1000 stores computer-readable instructions 1010, which, when executed by a processor, perform one or more steps of the method and its additional aspects as described above.

[0143] 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 the method and its additional aspects according to at least one embodiment of the present disclosure.

[0144] For example, the computer-readable storage 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.

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

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

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

[0148] (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.

[0149] (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.

[0150] 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 digital currency hardware wallet, comprising: An input element is configured to detect user input and acquire detected user input information, wherein the user input information includes a first instruction for initiating a first payment mode or a second instruction for initiating a second payment mode. The security element is configured to: calculate and generate the offline payment code required for the first payment mode to be displayed in response to the first instruction based on the current hardware wallet time factor, the pre-stored key factor and the operation factor, and start or maintain the second payment mode; or, activate the transaction instruction of the second payment mode in response to the second instruction and start the first payment mode. The controller is configured to control the display to show the offline payment code for scanning by the acceptance terminal to initiate a digital currency transaction of the first payment mode; and A near-field communication circuit is configured to detect the acceptance terminal and send the transaction instruction to the acceptance terminal via near-field communication during the activation of the second payment mode to initiate a digital currency transaction in the second payment mode; The key factor and the operation factor are information received from the digital currency back-end system and stored in the secure element in advance through a secure channel between the digital currency back-end system and the hard wallet, and are the same as the information stored in the digital currency back-end system.

2. The digital currency hardware wallet according to claim 1, wherein, The user input information includes a third instruction for disabling the second payment mode; The security element is also configured to close the second payment mode in response to the third instruction, so as to prevent the transaction instruction from being transmitted to the outside via the near-field communication method.

3. The digital currency hardware wallet according to claim 1 or 2, wherein, The user input information also includes a fourth instruction for switching the displayed content; The controller is further configured to: respond to the fourth instruction, control the display to display the first set content after the switch to prompt the user to establish communication between the hardware wallet and the receiving terminal; and control the display to display the query information forwarded by the receiving terminal; and The near-field communication circuit is further configured to: send an information query request to the acceptance terminal via the near-field communication method, and receive query information returned by the digital currency back-end system in response to the information query request, which is forwarded by the acceptance terminal.

4. The digital currency hard wallet according to claim 3, wherein, The user input information also includes a fifth instruction for switching the display of the offline payment code; The security element is configured to, in response to the fifth instruction, recalculate and generate a new offline payment code based on the current hardware wallet time factor, the pre-stored key, and the operation factor. and The controller is configured to control the display to show the new offline payment code.

5. The digital currency hard wallet according to claim 3, wherein, Also includes: The timer is configured to start counting when the information query request is sent. The controller is further configured to: if the query information is not received after the first set time has elapsed, control the display to show the second set content to prompt the user to re-establish communication between the hardware wallet and the receiving terminal, and control the near-field communication circuit to send the information query request.

6. The digital currency hard wallet according to claim 1 or 4, wherein, A timer is configured to start counting when the offline payment code is displayed on the display. The controller is also configured to, if the timer reaches a second preset time, control the display to clear the offline payment code or display preset content.

7. The digital currency hardware wallet according to claim 1, wherein, The detection of user input includes detecting long press input or short press input.

8. A digital currency back-end system, comprising: The key generation module is configured to generate key factors for calculating offline payment codes and store them in association with the hardware wallet data corresponding to the hardware wallet. The operation factor generation module is configured to generate operation factors for calculating offline payment codes and store them in association with the hardware wallet data. The communication module is configured to: establish a secure channel with the hardware wallet, and send key factors and operation factors to the corresponding hardware wallet through the secure channel based on the hardware wallet data; and The business management module is configured to: maintain the mapping relationship between the key factor, the operation factor and the hardware wallet data; use the mapping relationship to verify the code information of the offline payment code in the received digital currency transaction information of the first payment mode; and execute digital currency transaction processing after the verification is successful.

9. The digital currency back-end system according to claim 8, wherein, The operation factor includes random numbers and user indexes; The business management module is further configured to: determine whether the hard wallet account has expired based on the hard wallet data; if expired, allocate the user index corresponding to the hard wallet account and a new random number to a new hard wallet account.

10. The digital currency back-end system according to claim 9, wherein, The business management module is further configured to: determine the user index from the code information, and search for the corresponding hardware wallet data based on the user index; calculate the first estimated time for generating the payment code based on the hardware wallet data, and use the mapping relationship to search for the corresponding key factor and operation factor; calculate the first verification code based on the key, operation factor and the first estimated time; check whether the verification code in the verification code information is consistent with the calculated first verification code; if they are consistent, confirm that the verification code is valid, perform digital currency transaction processing, and return the transaction execution result to the acceptance terminal.

11. The digital currency back-end system according to claim 10, wherein, The business management module is further configured to: if the check code in the code information is inconsistent with the calculated first check code, then perform the following steps: process the first estimated time based on the set time step to obtain the second estimated time, and calculate the second check code based on the second estimated time; verify whether the check code in the code information is consistent with the calculated second check code, and if they are consistent, confirm that the check code is valid.

12. The digital currency back-end system according to claim 8, wherein, The business management module is further configured to: verify the received digital currency transaction information of the second payment mode; after the verification is passed, execute the digital currency transaction processing; return the transaction execution result and optionally return an echo instruction to the acceptance terminal; the echo instruction is forwarded by the acceptance terminal to the hardware wallet to display the balance information after the transaction.

13. The digital currency back-end system according to claim 8, wherein, The business management module is also configured to determine whether the current digital currency transaction is a password-free transaction or a small-amount transaction based on the digital currency transaction information.

14. A transaction system based on a digital currency hardware wallet, comprising: The digital currency hardware wallet as described in any one of claims 1-7, and The digital currency back-end system as described in any one of claims 8-13.

15. A transaction method based on a digital currency hard wallet, executed by the digital currency hard wallet, the method comprising: Detect user input and acquire the detected user input information, wherein the user input information includes a first instruction for initiating a first payment mode or a second instruction for initiating a second payment mode; The offline payment code required for the first payment mode is calculated and generated based on the current hardware wallet time factor, pre-stored key factor, and operation factor to respond to the first instruction, and the second payment mode is started or maintained; or, the transaction instruction of the second payment mode is activated to respond to the second instruction and the first payment mode is started. The control display shows the offline payment code for the acceptance terminal to scan in order to initiate a digital currency transaction using the first payment mode; and During the activation of the second payment mode, the detection terminal sends the transaction instruction to the acceptance terminal via near-field communication to initiate a digital currency transaction under the second payment mode; The key factor and the operation factor are information received from the digital currency back-end system and stored in the secure element in advance through a secure channel between the digital currency back-end system and the hard wallet, and are the same as the information stored in the digital currency back-end system.

16. The transaction method according to claim 15, wherein, The user input information includes a third instruction for disabling the second payment mode; The hardware wallet responds to the third instruction by closing the second payment mode to prevent the transaction instruction from being transmitted to the outside via the near-field communication method.

17. The transaction method according to claim 15 or 16, wherein, The user input information also includes a fourth instruction for switching the displayed content; In response to the fourth instruction, the hardware wallet controls the display to show the first set content after the switch to prompt the user to establish communication between the hardware wallet and the receiving terminal. The hardware wallet sends an information query request to the receiving terminal via the near-field communication method, and receives query information returned by the digital currency back-end system in response to the information query request, forwarded by the receiving terminal. It also controls the display of query information forwarded by the receiving terminal.

18. The transaction method according to claim 17, wherein, The user input information also includes a fifth instruction for switching the display of the offline payment code; In response to the fifth instruction, the hardware wallet recalculates and generates a new offline payment code based on the current hardware wallet time factor, the pre-stored key, and the operation factor. And control the display to show the new offline payment code.

19. The transaction method according to claim 17, wherein, Also includes: The hardware wallet starts timing when the information query request is sent; If the hardware wallet fails to receive the query information after the first preset time, it controls the display to show the second preset content to prompt the user to re-establish communication between the hardware wallet and the receiving terminal and send the information query request.

20. The transaction method according to claim 15 or 18, wherein, The hardware wallet starts timing when the offline payment code is displayed; If the hardware wallet reaches the second preset time, it controls the display to clear the offline payment code or display preset content.

21. A transaction method based on a digital currency hardware wallet, executed by a digital currency backend system, the method comprising: Receive digital currency transaction information sent by the acceptance terminal, and determine whether the digital currency transaction information was obtained through the first payment mode; and If the determination result is that the digital currency transaction information is obtained through the first payment mode, then the hardware wallet data is determined according to the digital currency transaction information, and the code information of the offline payment code in the digital currency transaction information is verified by using the mapping relationship corresponding to the hardware wallet data. After the verification is passed, the digital currency transaction processing is executed. The digital currency backend system pre-generates key factors and operation factors for calculating offline payment codes, and associates and stores the key factors and operation factors with the corresponding hardware wallet data to form the mapping relationship.

22. The transaction method according to claim 21, wherein, The operation factor includes random numbers and user indexes; The digital currency backend system determines whether the hard wallet account has expired based on the hard wallet data. If it has expired, the system assigns the user index corresponding to the hard wallet account and a new random number to a new hard wallet account.

23. The transaction method according to claim 22, wherein, The digital currency backend system determines the user index from the code information, and searches for the corresponding hardware wallet data based on the user index; it calculates the first estimated time for generating the payment code based on the hardware wallet data, and uses the mapping relationship to find the corresponding key factor and operation factor; it calculates the first verification code based on the key, operation factor and the first estimated time; it checks whether the verification code in the verification code information is consistent with the calculated first verification code. If they are consistent, the verification code is confirmed to be valid, the digital currency transaction is processed, and the transaction execution result is returned to the acceptance terminal.

24. The transaction method according to claim 23, wherein, If the verification code in the code information is inconsistent with the calculated first verification code, the digital currency backend system performs the following steps: processes the first estimated time based on the set time step to obtain a second estimated time, and calculates a second verification code based on the second estimated time; verifies whether the verification code in the code information is consistent with the calculated second verification code, and if they are consistent, confirms that the verification code is valid.

25. The transaction method according to claim 21, wherein, If the digital currency transaction information is obtained through the second payment mode, the digital currency backend system verifies the digital currency transaction information. After the verification is successful, the digital currency transaction is processed, and the transaction execution result and optionally a return echo instruction are returned to the acceptance terminal. The echo instruction is forwarded by the acceptance terminal to the hardware wallet to display the balance information after the transaction.

26. A transaction device based on a digital currency hard wallet, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 15-25.

27. A non-transitory computer-readable storage medium storing computer-executable instructions thereon, characterized in that, When the computer-executable instructions are executed by a processor, they implement the method as described in any one of claims 15-25.

Images