NFC-based smart hardware interaction method, device and storage medium

Abstract

This application discloses an NFC-based smart hardware interaction method, device, and storage medium, relating to the field of data processing technology. The method includes: when the NFC chip receives a radio frequency signal sent by a mobile terminal, decoding the radio frequency signal to obtain a data packet corresponding to the radio frequency signal; sending the data packet to a preset target applet program, where the target applet program parses the data packet to obtain interactive data; and, based on the control unit, sending the interactive data to a service execution module to control the service execution module to execute the target action corresponding to the interactive data. This achieves bidirectional interaction with the terminal device.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to an intelligent hardware interaction method based on NFC, a device and a storage medium. BACKGROUND

[0002] Generally, an NFC device (such as a POS machine) only bears the function of an information carrier, and its core information, such as a merchant ID, a collection account, an order number, a fixed collection amount template, etc., are all fixed data pre-configured by a background system and written into a storage module of the device, without the ability of dynamic updating, real-time data processing or active communication triggering; only when a mobile phone is close to the NFC device and initiates a reading request, the NFC device can respond passively, and cannot actively initiate communication, receive any instructions from the mobile phone, or dynamically update information or feed back real-time status.

[0003] The above content is only used to assist in understanding the technical solutions of the present application, and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide an intelligent hardware interaction method based on NFC, a device and a storage medium, aiming to solve the technical problem that a traditional NFC device can only transmit fixed information in one direction and cannot realize real-time bidirectional interaction with a mobile terminal.

[0005] In order to solve the above problem, the present application provides an intelligent hardware interaction method based on NFC, applied to an NFC interaction device end, which includes an NFC chip, an Applet program and a control unit, and the method includes the following steps:

[0006] When the NFC chip receives a radio frequency signal sent by a mobile terminal, the radio frequency signal is decoded and processed to obtain a data packet corresponding to the radio frequency signal;

[0007] The data packet is sent to a preset target Applet program, and the target Applet program analyzes the data packet to obtain interaction data;

[0008] Based on the control unit, the interaction data is sent to a business execution module to control the business execution module to execute a target action corresponding to the interaction data.

[0009] In an embodiment, before the step of receiving a radio frequency signal sent by a mobile terminal by the NFC chip, decoding and processing the radio frequency signal to obtain a data packet corresponding to the radio frequency signal, the intelligent hardware interaction method based on NFC further includes the following steps:

[0010] When the control unit receives the Applet program data, integrity check is performed on the Applet program data;

[0011] The Applet program data with the successful check is stored to a secure chip, and the Applet program data is initialized and activated to obtain an Applet program.

[0012] In an embodiment, before the step of sending the data packet to a preset target Applet program, the target Applet program parses the data packet to obtain interaction data, the NFC-based smart hardware interaction method further comprises:

[0013] Obtaining an Applet selection instruction in the data packet, and determining a target application identifier based on the Applet selection instruction;

[0014] Comparing each preset application identifier and the target application identifier to determine a matched target Applet program.

[0015] In an embodiment, the NFC interaction device is a POS machine, the data packet is a payment data packet, and the interaction data is payment data and health data. The step of sending the data packet to a preset target Applet program, and the target Applet program parsing the data packet to obtain interaction data comprises:

[0016] When the target Applet program receives the payment data packet, a preset encryption algorithm is called to decrypt the payment data packet to obtain a payment token, a user authorization identifier, and a payment amount identifier;

[0017] A POS machine terminal identifier associated with the target Applet program is called, and based on the POS machine terminal identifier and a settlement timestamp, an order data call request is generated and sent to the control unit to trigger the control unit to obtain corresponding order data. The order data includes initial health data and an order amount;

[0018] When the target Applet program receives the order data, health reminder data is generated based on a preset health rule and the initial health data;

[0019] The health reminder data, the payment token, the user authorization identifier, and the order amount are sent to the control unit.

[0020] In an embodiment, the step of sending the interaction data to a business execution module based on the control unit to control the business execution module to perform a target action corresponding to the interaction data comprises:

[0021] When the control unit receives the health reminder data, it generates a display instruction based on the preset display rules and the health reminder data, and sends the display instruction to the display module of the POS machine;

[0022] The display module determines display parameters based on the display instructions, converts the display parameters into pixel data, and displays the pixel data on the display screen.

[0023] In one embodiment, the NFC-based smart hardware interaction method further includes:

[0024] The control unit encapsulates the health reminder data and payment status into a data frame and sends the data frame to the NFC chip through the HCI interface;

[0025] The NFC chip receives and modulates the data frame into a radio frequency signal, and then sends the radio frequency signal to a mobile terminal within the sensing range.

[0026] This application also provides an NFC-based smart hardware interaction method applied to a mobile terminal, the NFC-based smart hardware interaction method comprising:

[0027] The received radio frequency signal is converted and decoded to obtain the interactive data in the radio frequency signal;

[0028] Based on the data type identifier of the interactive data, the associated target APP is determined;

[0029] Send a launch command containing the interactive data to the target APP.

[0030] In one embodiment, the interaction data is health data. After the step of sending a launch command containing the interaction data to the target APP, the NFC-based smart hardware interaction method further includes:

[0031] Acquire health data from the radio frequency signal, and determine the target storage location based on the health data and preset data storage rules;

[0032] The health data is stored at the target location.

[0033] In addition, to achieve the above objectives, this application also proposes an NFC-based smart hardware interaction device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the NFC-based smart hardware interaction method described above.

[0034] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the NFC-based smart hardware interaction method described above.

[0035] This application provides an NFC-based smart hardware interaction method. When the NFC chip receives a radio frequency signal sent by a mobile terminal, it demodulates and decodes the signal to extract standardized data packets. These data packets are then transmitted to a pre-defined target Applet program. The Applet program, through its built-in dedicated parsing logic and data processing rules, parses and standardizes the data packets, outputting interactive data. The control unit of the NFC device analyzes and makes decisions on this structured interactive data in real time according to pre-defined interaction rules, determines the corresponding target action, and generates control commands to drive the execution of relevant functional modules. This method overcomes the technical limitations of traditional NFC devices, which can only be read as passive tags. It enables real-time, bidirectional data interaction and command response between NFC devices and mobile terminals, expanding the application boundaries of NFC devices in scenarios such as payment settlement, health management, and smart control, significantly improving the device's practicality and scenario adaptability. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a first flowchart illustrating the NFC-based smart hardware interaction method of this application.

[0039] Figure 2 A second flowchart illustrating the NFC-based smart hardware interaction method of this application;

[0040] Figure 3 A schematic diagram of the system architecture provided for the NFC-based smart hardware interaction method of this application;

[0041] Figure 4 A third flowchart illustrating the NFC-based smart hardware interaction method of this application;

[0042] Figure 5A fourth flowchart illustrating the NFC-based smart hardware interaction method of this application;

[0043] Figure 6 This is a schematic diagram of the hardware operating environment involved in the NFC-based smart hardware interaction method in this application embodiment.

[0044] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0046] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0047] To achieve the above objectives, this application proposes an NFC-based smart hardware interaction method, applied to an NFC interaction device. The NFC interaction device includes an NFC chip, an Applet program, and a control unit. The NFC-based smart hardware interaction method includes: when the NFC chip receives a radio frequency signal sent by a mobile terminal, decoding the radio frequency signal to obtain a data packet corresponding to the radio frequency signal; sending the data packet to a preset target Applet program, where the target Applet program parses the data packet to obtain interaction data; and, based on the control unit, sending the interaction data to a service execution module to control the service execution module to execute the target action corresponding to the interaction data.

[0048] Typically, NFC devices (such as POS machines) only function as information carriers. Their core information, such as merchant ID, payment account, order number, and fixed payment amount template, is fixed data that is pre-configured by the backend system and written into the device's storage module. They have no ability to dynamically update, process data in real time, or initiate communication. They can only passively respond when a mobile phone approaches and initiates a read request. They cannot initiate communication, receive any instructions from the mobile phone, or dynamically update information or provide real-time status feedback.

[0049] This application provides an NFC-based smart hardware interaction method. When the NFC chip receives a radio frequency signal sent by a mobile terminal, it demodulates and decodes the signal to extract standardized data packets. These data packets are then transmitted to a pre-defined target Applet program. The Applet program, through its built-in dedicated parsing logic and data processing rules, parses and standardizes the data packets, outputting interactive data. The control unit of the NFC device analyzes and makes decisions on this structured interactive data in real time according to pre-defined interaction rules, determines the corresponding target action, and generates control commands to drive the execution of relevant functional modules. This method overcomes the technical limitations of traditional NFC devices, which can only be read as passive tags. It enables real-time, bidirectional data interaction and command response between NFC devices and mobile terminals, expanding the application boundaries of NFC devices in scenarios such as payment settlement, health management, and smart control, significantly improving the device's practicality and scenario adaptability.

[0050] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses an NFC-based smart hardware interaction device as an example to illustrate this embodiment and the subsequent embodiments.

[0051] Based on this, embodiments of this application provide an NFC-based smart hardware interaction method, applied to an NFC device, as described above. Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the NFC-based smart hardware interaction method of this application.

[0052] In this embodiment, the NFC-based smart hardware interaction method is applied to an NFC-based smart hardware interaction device, and the method includes steps S10 to S30:

[0053] Step S10: When the NFC chip receives the radio frequency signal sent by the mobile terminal, it decodes the radio frequency signal to obtain the data packet corresponding to the radio frequency signal.

[0054] In this embodiment, the NFC chip (CLF, contactless front-end chip) is continuously in signal receiving state through its built-in NFC antenna. When the mobile terminal is close to the sensing area, the radio frequency signal sent by the mobile terminal's NFC module forms an electromagnetic coupling with the CLF antenna. The CLF chip obtains weak energy through coupling and activates the signal receiving link. The radio frequency front-end circuit inside the CLF chip starts up, introducing the analog radio frequency signal sensed by the antenna into the internal processing channel, while filtering out environmental electromagnetic interference.

[0055] The CLF chip's decoding module decodes the stabilized baseband signal according to the Manchester encoding rules of the ISO 14443 protocol. There is a transition within each bit cycle, with a high-low transition indicating logic 1 and a low-high transition indicating logic 0. The decoding module locks the bit cycle of the baseband signal through a clock synchronization circuit, identifies the transition direction bit by bit, and converts the baseband signal into a standard binary data stream. It extracts the frame synchronization identifier from the binary data stream, such as the ISO 14443 Type A SOF start frame identifier 0x50, to confirm the start position of the data frame.

[0056] The CLF chip's frame processing module splits the binary data stream into frames according to the ISO 14443 protocol's frame format, sequentially extracting the frame header (Start of SOF), valid data segment, frame trailer (End of EOF), and checksum field. The extracted valid data segment's CRC16 checksum is recalculated and compared with the checksum field in the frame trailer. If the checksums match, it is determined that the data transmission has not been tampered with or lost, and subsequent processing is performed. If the checksums do not match, the current data frame is discarded, and a data retransmission request is sent to the mobile terminal via the antenna, waiting for the mobile terminal to retransmit.

[0057] After successful verification, the CLF chip encapsulates the valid data segment into a standardized data packet according to a preset format, adds a data type identifier and a data length field to form a complete data packet. The CLF chip actively pushes the encapsulated data packet to the MCU through a preset communication interface with the MCU, such as the SPI interface. At the same time, it sends a data ready interrupt signal to notify the MCU to read the data in time. After receiving the interrupt signal, the MCU reads the data packet pushed by the CLF through the SPI interface and performs business processing such as decryption and verification on the Applet passed to the eSE security chip.

[0058] Optionally, if the CLF chip fails to verify data frames three times consecutively, or fails to receive a valid response from the mobile terminal within one second, it automatically terminates the current receiving process and sends a communication error signal to the MCU. The MCU then triggers the NFC terminal screen to display a message indicating NFC communication failure and requesting a retry. If the data is successfully forwarded to the security chip, the CLF chip remains in receiving mode, waiting for any subsequent supplementary data from the mobile terminal, or automatically switches to standby mode after three seconds of no further signal to save power.

[0059] Step S20: The data packet is sent to a preset target Applet program, which parses the data packet to obtain interactive data.

[0060] In this embodiment, the target applet is deployed within the eSE security chip and receives data through a dedicated interface between the eSE and the NFC chip. The applet receives standardized binary data packets, which include a frame header identifier, total data length, authentication field, service data, checksum, and frame trailer identifier. The system checks whether the frame header and frame trailer of the received data match; if they do not match, the data is discarded, and a frame format error response is returned. The total data length field is read to verify whether the total length of the actual received authentication field + service data + checksum is consistent; if they are inconsistent, it is determined that the data has been truncated, and processing is terminated.

[0061] After length verification, the authentication field and business data in the data packet are extracted. The eSE's built-in hardware CRC calculation engine is then used to calculate the checksum using the CRC32 standard polynomial. The calculation result is compared with the checksum in the data packet. If they do not match, an invalid data response is generated and sent back to the mobile terminal, an error log is logged, and the current processing is terminated. If they match, authentication is initiated to prevent unauthorized app access. The applet and the legitimate mobile app share a pre-shared pairing key, such as an AES-256 symmetric key or an RSA-2048 asymmetric key pair. This key is stored in the eSE's encrypted storage area and can only be accessed by the applet.

[0062] In one optional implementation, AES symmetric encryption authentication is used. The mobile terminal APP concatenates the device's unique identifier, timestamp, and random number, encrypts them using a paired AES key in ECB / CBC mode, and generates an authentication field. The Applet calls the eSE hardware encryption engine to decrypt the received authentication field using the built-in paired AES key. After decryption, the device identifier, timestamp, and random number are extracted. The system verifies whether the device identifier is in the Applet's pre-stored whitelist of legitimate devices and verifies the validity of the timestamp. If the difference between the current eSE internal time and the timestamp in the authentication field is less than or equal to a preset timestamp difference (e.g., less than or equal to 30 seconds), the timestamp is considered valid to prevent replay attacks.

[0063] The process also verifies the uniqueness of the random number by checking if it exists in the transaction log for the most recent preset duration. If it does not exist, it is considered valid. If all sub-items pass verification, the process proceeds to business data parsing. If any sub-item fails, such as the device not being on the whitelist, the timestamp expires, or the random number is duplicated, an authentication failure response is generated, sent back to the mobile terminal, and logged, terminating the processing.

[0064] In one optional implementation, RSA asymmetric signature authentication is used. The mobile terminal APP signs the business data digest and timestamp with its own private key to generate signature data (i.e., the authentication field). At the same time, the APP's public key certificate is embedded in the data packet, or the Applet pre-stores a valid public key. If the Applet does not pre-store a public key, the APP's public key certificate is extracted from the data packet, and its legality is verified by the CA root certificate built into eSE. The eSE hardware encryption engine is called to perform signature verification on the authentication field using the valid public key. The digest of the received business data is recalculated and compared with the business data digest extracted after signature verification. The timestamp difference is verified to be less than or equal to a preset timestamp difference threshold. If the signature verification, digest comparison, and timestamp verification pass, the business data parsing begins. If any step fails, an authentication failure response is returned, and the process terminates.

[0065] The applet parses business data field by field according to a preset format, identifies field types using tags, determines the value length using the Length field, and extracts the value for each field. It converts the binary value into a business-recognizable format, such as converting order amount 0x0012 to decimal 18 yuan, and order number from binary to ASCII string. It verifies the completeness of required fields based on the business type, such as ensuring that the order number and amount for payment orders are not empty, and that field values ​​are within a reasonable range. When parsing is successful, all required fields are present, and field values ​​are valid, structured business data is obtained. A success response is then returned to the mobile terminal. Upon receiving the response, the mobile app parses the response code to 0x00, confirming successful secure interaction and triggering subsequent operations, such as displaying the payment confirmation page.

[0066] The Applet application built into the eSE security chip processes the data from NFC tap-to-tap interactions, and then sends the processed / interactive information to the MCU main control system via HCI for further processing.

[0067] Optionally, the Applet application processes interactive data. For example, when a user brings their phone close to the access control NFC module, the CLF chip sends an radio frequency signal. The phone system identifies the access control payment protocol type, and an access control app pops up. The app reads the user's pre-stored access control authentication information, such as employee ID, department, and permission level, and encapsulates the data packet according to the corresponding encryption rules. The CLF chip demodulates and decodes the data before forwarding it to the Applet. The Applet verifies the frame format and length, extracts the APP identifier from the extended fields, calculates the CRC32 values ​​of the authentication fields and business data, and compares them with the checksum. Based on the APP identifier, it calls the pre-stored public key and uses it to verify the RSA signature of the authentication fields. If the verification is successful, it extracts the employee ID, permission level, and timestamp. It queries the company's employee whitelist stored in the Applet, confirms that the employee ID exists and the permission level is ≥ ordinary access, generates a processing result indicating legitimate identity, permission level = ordinary access, and control command = open door. The Applet generates an authentication success response data packet, pushes it back to the mobile app, and the app pops up a window displaying successful access control authentication and indicating that the door will open soon.

[0068] Optionally, the Applet application processes interactive data. When a store clerk enters an order on the POS terminal, the user touches the POS machine with their mobile phone, and the POS terminal pushes the order and calorie data to the mobile phone via NFC. The mobile phone then launches a payment app to complete the payment. The Applet deployed on the eSE security chip of the POS terminal synchronously parses the product's calorie data and pushes a health trigger command back to the mobile phone, launching a health management app to generate a health reminder.

[0069] The applet encapsulates structured business data according to the predefined HCI message specifications of eSE and MCU, calls the HCI protocol processing module inside eSE, automatically fills the message header fields, embeds the structured business data into the message body, calculates and adds BCC check bits, and forms a complete HCI message frame. The applet sends a data reporting trigger command to the HCI transmission module inside the eSE, carrying a complete HCI message frame. The eSE sends a data ready interrupt signal to the MCU through the HCI interface, notifying the MCU to receive data. The MCU reads the HCI message frame sent by the eSE byte by byte through the HCI interface, verifies whether the message type identifier is for business data reporting, and whether the total message length matches the actual received length. It checks whether the applet AID is in the MCU's pre-stored list of valid applets, extracts the business data from the message body, and verifies whether the required fields exist. If all verifications pass, a successful reception response frame is generated and sent back to the eSE through the HCI interface. If verification fails, a failed reception response frame is generated, sent back to the eSE, and an error log is recorded. If the applet receives a successful reception response, it confirms that the data has been safely reported and enters standby mode, waiting for the next NFC interaction request. If a failed reception response or no response is received after a timeout, the applet retryes reporting twice. If it still fails, a reporting failure log is recorded, triggering the MCU's active query mechanism. The MCU periodically queries the eSE for data that has not been reported.

[0070] Optionally, users can purchase virtual goods via a mobile app. After touching the AI ​​pet hardware module, the hardware, based on its personalized settings (e.g., currently on a diet), engages in fun interactions with the user. The user places their phone near the AI ​​pet hardware's NFC sensing area. The module's CLF chip continuously emits a radio frequency field. Upon sensing this, the phone's NFC module launches the installed AI pet raising app. The app reads the user's purchased virtual goods data, encapsulates it into a standardized data packet according to a predefined format, and reads the AI ​​pet's personalized data stored in the applet: current status = dieting, forbidden = high-calorie foods. Based on the personalized rules, a processing result is generated; for example, it might display "feeding successful" but trigger a diet warning.

[0071] Step S30: Based on the control unit, the interaction data is sent to the business execution module to control the business execution module to execute the target action corresponding to the interaction data.

[0072] In this embodiment, the control unit (MCU) of the NFC device receives and parses the valid data after the mobile terminal interacts with the Applet, then compares it with the pre-stored local interaction rule base to determine the target action to be performed, and finally sends control commands to hardware functional modules, such as voice, light, and door lock, to drive the module to complete the action execution.

[0073] The MCU receives processed interactive data reported by the Applet within the eSE chip via the HCI interface. Example data: Business type = pet feeding, product calories = 500, pet status = dieting; Business type = access control, employee ID = 001, permission level = normal. The MCU parses the received standardized data and filters out decision factors affecting the target action. These factors include business requirements (e.g., feeding milk tea, door opening request), status parameters (e.g., pet dieting, employee permission valid), and trigger conditions (e.g., calories ≥ 300, authentication successful). The MCU retrieves a pre-stored interaction rule base from its local Flash / ROM. Rules are stored as a mapping between conditions and actions. The MCU matches each decision factor with a rule to determine the target action; the rule base is hierarchically matched according to business type and status parameters.

[0074] The MCU encapsulates the target action into control instructions that can be recognized by the functional modules. The instruction format includes: module identifier, action parameters (such as the voice module's dialogue ID, the light module's color and flashing frequency, and the door lock module's unlocking duration), and checksum. The MCU sends the control instructions to the corresponding functional modules through a hardware interface; after the functional modules execute the action, they return an execution result response to the MCU.

[0075] In this embodiment, when the NFC chip receives a radio frequency signal sent by a mobile terminal, it demodulates and decodes the signal to extract standardized data packets. These data packets are then transmitted to a pre-defined target Applet program. The Applet program, through its built-in dedicated parsing logic and data processing rules, parses and complies with the data packets, outputting interactive data. The control unit of the NFC device analyzes and makes decisions on this structured interactive data in real time according to pre-defined interaction rules, determines the corresponding target action, and generates control commands to drive the relevant functional modules to execute. This overcomes the technical limitation of traditional NFC devices being read only as passive tags, enabling real-time, bidirectional data interaction and command response between the NFC device and the mobile terminal. It expands the application boundaries of NFC devices in scenarios such as payment settlement, health management, and intelligent control, significantly improving the device's practicality and scenario adaptability.

[0076] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, steps S01 to S02 may be included before step S10:

[0077] Step S01: When the control unit receives Applet program data, it performs an integrity check on the Applet program data.

[0078] In this embodiment, the developed Applet application is transmitted to the NFC device via OTA or a wired interface in the form of a standardized bytecode file (.cap format). Upon receiving the bytecode, the NFC device's MCU performs integrity verification on the bytecode data, such as CRC32 checksum, to ensure no data loss or tampering occurs during transmission. The NFC device's MCU sends a card emulation mode configuration command to the NFC chip. This command contains preset configuration data, such as the emulation card type, communication rate, data routing rules, and RF field response parameters. Upon receiving the command, the NFC chip performs format and validity verification on the configuration data. After successful verification, the NFC chip writes the configuration data into its internal register, completing the mode switch, disabling the reader mode and enabling the passive card emulation mode. Simultaneously, it initializes the RF module parameters based on the configuration data, such as modulation method and carrier frequency calibration, and pre-sets a data routing table, specifying the interface protocol and channel for forwarding received external NFC data to the eSE security chip. After completing the switch, the NFC chip generates status feedback data and sends it back to the MCU, completing the NFC chip's switch to card emulation mode.

[0079] Step S02: Store the successfully verified Applet program data in the security chip, initialize and activate the Applet program data to obtain the Applet program.

[0080] In this embodiment, the security chip can be an eSE security chip. After successful verification, the MCU pushes the Applet bytecode data to the eSE security chip via the HCI interface. Upon receiving the data, the eSE security chip reads the stored Applet bytecode file and parses its built-in metadata, including the Applet's class structure, method list, dependent Java Card API, required resource declarations, AID (Application Identifier), etc. It confirms that the dependent APIs are compatible with the eSE firmware, such as whether they support AES / RSA encryption algorithms, ISO7816 protocol interfaces, and whether the required resources exceed the eSE hardware limit. After successful verification, the eSE allocates an independent secure operating environment for the Applet, allocating non-volatile memory for storing the Applet's static data, configuration parameters, pairing keys, etc., and volatile memory for runtime data caching.

[0081] It divides the instruction execution area into an independent area, isolating it from other installed applets to prevent data leakage or mutual interference; and binds a dedicated hardware encryption engine channel.

[0082] eSE converts the Applet bytecode into executable machine instructions based on the class structure in the metadata, loads core classes such as the Applet base class and custom business processing classes; locates the Applet's entry method, namely the install() method, which contains the Applet's initialization logic, such as key generation / import, default configuration parameter settings, and preset interaction rules; unlocks the install() method's execution permissions and configures the permission control list, such as allowing only legitimate data packets forwarded via the NFC chip to trigger the Applet, and prohibiting unauthorized calls from other internal modules; completes initialization according to the Applet's preset logic, such as generating a session key paired with the mobile device and storing it in the eSE encrypted storage area; presets data interaction protocol rules, such as supported APDU instruction sets, data encapsulation formats, and verification methods; and initializes the interaction state machine.

[0083] The eSE registers the Applet's AID (Application Identifier) ​​to its own Applet management list, which contains the AIDs, status (ready / not ready), and resource usage of all loaded and activated Applets. Internally, the eSE configures the mapping relationship between data packets, AIDs, and Applets. When a data packet forwarded by the NFC chip contains the AID, the eSE automatically routes the data packet to the corresponding Applet. The eSE sends an Applet activation success notification to the NFC device's MCU via the HCI interface, including the Applet's AID, status flag, and supported service types. The eSE updates the Applet's status flag, changing it from "not activated" to "ready," and writes this information to the Applet's dedicated status register; it also releases temporary resources used during initialization, reserving the core resources required for operation.

[0084] Initialize the data receiving buffer, allocate a fixed-size buffer to store subsequent data packets received from the NFC chip, and configure the buffer's read and write rules, such as FIFO (First In First Out), and trigger overflow handling when the buffer is full; return the final activation result to the MCU, including the activation status (success / failure), failure reason code (such as insufficient resources, abnormal permissions), and Applet ready flag, thus completing the initialization activation.

[0085] Before step S20, steps S40 to S50 may also be included:

[0086] Step S40: Obtain the Applet selection instruction in the data packet, and determine the target application identifier based on the Applet selection instruction;

[0087] Step S50: Compare each preset application identifier with the target application identifier to determine the matching target Applet program.

[0088] In this embodiment, the eSE security chip pre-stores multiple applet programs, each applet corresponding to a unique application identifier (AID); a preset AID list is stored in the MCU's local Flash / ROM. The data packet sent by the mobile terminal APP via NFC contains an applet selection instruction to determine the target applet to interact with.

[0089] The NFC chip receives radio frequency signals sent by the mobile terminal, demodulates and decodes them to obtain binary data packets, and pushes them to the MCU via the SPI / I2C interface. Upon receiving the data packets, the MCU first verifies the frame format and CRC32 checksum to confirm that the data has not been tampered with or lost. It then parses the data packets according to a preset instruction format to extract the core instruction fields. Based on the parsed field values, it extracts binary data of the corresponding length to obtain the target AID. The binary target AID is then converted to a standardized string format. A pre-stored list of preset AIDs is read from the local Flash / ROM, including an index identifier, AID string, and corresponding Applet function. Using a full-character matching algorithm, the extracted target AID string is compared one by one with each AID string in the preset AID list. The preset AID that matches the target AID is found, and its corresponding index identifier is recorded. The MCU sends an activation command to the eSE security chip via the HCI interface, simultaneously sending a command-ready interrupt signal. Upon receiving the command, the eSE parses the index identifier and locates the corresponding target Applet program in its internal storage; for example, index 01 corresponds to the payment service Applet. The eSE activates the target Applet, switching it from a dormant state to a ready state, preparing it to receive subsequent business data.

[0090] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S20 may include steps S21 to S24:

[0091] Step S21: When the target Applet program receives the payment data packet, it calls a preset encryption algorithm to decrypt the payment data packet to obtain the payment token, user authorization identifier, and payment amount identifier.

[0092] In this embodiment, the target Applet program pre-stores encryption algorithms and decryption keys; it is associated with a POS terminal identifier and has built-in preset health rules, such as: triggering a reminder when the calories of a single product are ≥300, and total calories = Σ calories of a single product, etc. The POS terminal control unit (MCU) pre-stores unsettled order data, including order number, product list, calories of a single product, order amount, and settlement timestamp.

[0093] The POS terminal MCU retrieves order information from its local cache, including order number, amount, merchant ID, and product calorie summary, and encapsulates it into a wake-up data packet according to the NFC payment protocol. The CLF chip modulates this data packet into a radio frequency signal and sends it to the mobile phone via the NFC antenna. After receiving the data, the mobile phone's NFC module parses the payment protocol type and order amount, automatically launches the corresponding payment app, and synchronizes the order information to the payment app. After verifying the amount in the payment app, the user confirms payment via fingerprint / facial recognition. The payment app generates a payment data packet, including a payment token, user authorization identifier, payment amount verification value, and settlement timestamp. After encrypting the payment data packet, the mobile phone's NFC module modulates the encrypted data packet into a radio frequency signal and sends it back to the POS terminal's CLF chip. The CLF chip demodulates and decodes the signal and forwards it to the target applet through the CLF-eSE communication interface.

[0094] The applet calls the eSE's built-in hardware encryption engine, loads the pre-stored decryption key, decrypts it according to the preset encryption mode, and obtains the payment token, user authorization identifier, payment amount identifier, and settlement timestamp after decryption.

[0095] Step S22: Invoke the POS terminal identifier associated with the target Applet program, generate an order data retrieval request based on the POS terminal identifier and the settlement timestamp, and send the order data retrieval request to the control unit to trigger the control unit to obtain the corresponding order data. The order data includes initial health data and order amount.

[0096] In this embodiment, the Applet reads the pre-frozen POS terminal identifier from the eSE encrypted storage area. This identifier matches the terminal identifier in the MCU's cached orders and is used to confirm local orders. The Applet encapsulates the order data retrieval request according to the message format agreed upon by the Applet and the MCU, and sends a data ready signal through the HCI interface between the eSE and the MCU to notify the MCU to receive data. After the MCU responds to the interrupt, it reads the complete request frame byte by byte through the HCI interface. The POS terminal identifier and settlement timestamp are extracted, and the unsettled order data in the local Flash cache is traversed, matched according to the terminal identifier and timestamp to locate the target order.

[0097] Extract core fields from the order data, including initial health data, order amount, and order number, encapsulate them into an HCI response frame in TLV format, and send it back to the target Applet via the HCI interface.

[0098] Step S23: When the target Applet program receives the order data, it generates health reminder data based on preset health rules and the initial health data.

[0099] Step S24: Send the health reminder data, the payment token, the user authorization identifier, and the order amount to the control unit.

[0100] In this embodiment, the target applet receives the HCI response frame returned by the MCU and parses it to obtain initial health data, such as "full sugar milk tea = 500" and "fries = 380". The applet retrieves a preset health rule library from the eSE encrypted storage area. The health rule library stores rule IDs, trigger conditions, reminder types, and reminder content templates. The health data is compared with the trigger conditions in the health rule library to determine the matching reminder rule.

[0101] For example, the health rules are as follows: Rule ID is R001, the trigger condition is that the calories of a single product are ≥300, the reminder type is that the single product exceeds the limit, and the reminder content template is "{product name} ({calories}) exceeds the limit, it is recommended to control sugar and oil intake"; Rule ID is R002, the trigger condition is that the total calories are ≥1500, the reminder type is that the total calories are warning, and the reminder content template is "The total calories consumed this time are {total calories}, which has exceeded the daily recommended threshold"; Rule ID is R003, the trigger condition is that there are no items exceeding the limit, the reminder type is a regular reminder, and the reminder content template is "The total calories consumed this time are {total calories}, the diet is balanced".

[0102] The payment token, user authorization identifier, order amount, and health reminder data are encapsulated into a business data reporting frame according to the HCI protocol format. A data ready signal is then sent again, and the MCU responds by reading the complete HCI reporting frame. After verifying the received data, the MCU returns a successful reception response frame to the Applet.

[0103] Step S30 may include steps S31 to S34:

[0104] Step S31: When the control unit receives the health reminder data, it generates a display instruction based on the preset display rules and the health reminder data, and sends the display instruction to the display module of the POS machine;

[0105] In step S32, the display module determines display parameters based on the display instruction, converts the display parameters into pixel data, and displays the pixel data on the display screen.

[0106] In this embodiment, the MCU receives health reminder data reported by the Applet, generates standardized display instructions according to display rules, including initialization instructions, area configuration, content data, and check bits, and sends them to the display module through the SPI / I2C interface; the display module parses the instructions, converts the string into dot matrix data, maps it into pixel data, and writes it into the display screen memory.

[0107] The MCU receives data, first verifying that the format of the raw data conforms to the preset protocol, then verifying that the data has not been tampered with or lost during transmission using the original checksum, and finally filtering invalid data, such as indicator values ​​exceeding reasonable ranges or timestamps deviating too much from the system time, to obtain valid health reminder data. The format is a structured data identifier + valid indicator value + valid timestamp. The display rule configuration pre-stored in the MCU includes region division rules, instruction format specifications, and verification algorithms. The MCU parses the type of health data according to the display rules, matches the corresponding display screen display mode, and assembles standardized display instructions according to the instruction format specifications. Specifically, this includes: initialization instructions: specifying the display screen operating mode, such as refresh rate and brightness level; region configuration: defining the coordinate range, font size, and alignment of the displayed data; content data: converting valid health indicator values ​​into a readable string format; and generating checksums based on the initialization instructions, region configuration, and content data using the preset verification algorithm to ensure instruction integrity. The output is a standardized display instruction stream containing the initialization instructions, region configuration, content data, and checksums. The communication link is initialized according to the SPI / I2C interface protocol. The standardized instruction stream is split into interface data frame formats and the instructions are sent to the display module frame by frame. At the same time, the response signal from the display module is received. If no response is received, the instruction is retransmitted to ensure successful transmission.

[0108] The control chip of the display module first reassembles the instruction frame according to the corresponding interface protocol to restore the standardized instruction stream; then it uses the same verification algorithm as the MCU to verify the check bits in the instruction to confirm that the instruction has not been erroneous or lost during transmission; after the verification is passed, the initialization instruction, region configuration, and content data in the instruction stream are split and stored in the corresponding registers of the display module respectively.

[0109] Extract each character from the string to be displayed in character order, and then search for the corresponding dot matrix data in the character library according to the character's encoding format. For example, for a 16×16 dot matrix character, each character uses 2 bytes to represent one line, for a total of 32 bytes of binary data, where "1" indicates that the corresponding pixel is lit, and "0" indicates that it is off. Concatenate the dot matrix data of all characters in the string in character order to form a continuous dot matrix data stream. Convert the string into pixel-level control data, establish a one-to-one mapping relationship between characters and dot matrices, and output a continuous dot matrix data stream corresponding to the string to be displayed.

[0110] Based on the coordinate range configured for the region, the absolute pixel position of each character dot matrix on the display screen is determined. Then, the "1" and "0" in the dot matrix data stream are mapped to the pixel states supported by the display screen. For example, in a monochrome screen, "1" corresponds to white on and "0" corresponds to black off, while in a color screen, "1" corresponds to a specified RGB color value and "0" corresponds to transparent or black. The data is reorganized according to the pixel arrangement order of the display screen, such as row priority or column priority, to generate a pixel data frame containing the coordinate information and corresponding color value of each pixel, and the format conforms to the storage requirements of the video memory.

[0111] The display module configures the display's operating state according to the initialization parameters, opens the video memory write channel, and writes the coordinates and color value of each pixel to the display's video memory in the order of pixel data frames. After the video memory write is complete, the display's refresh mechanism is triggered. The display reads the pixel data in the video memory and drives the corresponding pixels to light up or turn off. This step completes the final mapping from pixel data to physical display. The final effect is that the display shows the corresponding health reminder content, realizing the visualization output of the original health data.

[0112] Step S33: The control unit encapsulates the health reminder data and payment status into a data frame and sends the data frame to the NFC chip through the HCI interface;

[0113] In step S34, the NFC chip receives and modulates the data frame into a radio frequency signal, and sends the radio frequency signal to a mobile terminal within the sensing range.

[0114] In this embodiment, the health reminder data is encapsulated into a data frame. The NFC chip's built-in radio frequency front-end module initializes the radio frequency circuit according to the NFC communication standard, converts the binary stream of the data frame into a baseband signal, and then the baseband signal is superimposed on the 13.56MHz carrier signal through the modulation circuit to output the modulated radio frequency signal, thus completing the conversion from electrical signal to radio frequency signal.

[0115] The NFC chip radiates radio frequency signals as electromagnetic waves into the surrounding space through a built-in antenna coil or an external antenna. When a mobile phone enters the sensing range, the phone's NFC antenna couples to the 13.56MHz radio frequency signal, which is then converted into an electrical signal and transmitted to the NFC module inside the phone, completing the wireless transmission of data from the NFC chip to the mobile terminal.

[0116] Please refer to Figure 3 , Figure 3This document provides an architecture diagram for an NFC-based interactive system. The NFC device includes an eSE security chip (embedded security chip), an NFC chip (CLF), and an MCU (master control unit). The eSE security chip runs multiple Applet applications. Applets are the core carriers of business logic, and multiple instances can be loaded according to different business scenarios to process interactive data with the mobile terminal. The NFC chip (CLF, RF front-end) is responsible for transmitting and receiving RF signals, establishing an NFC communication link with the mobile terminal (such as a mobile phone), converting RF signals into processable digital signals, or modulating digital signals into RF signals for transmission. The MCU (master control unit) interacts with the NFC chip and eSE via I2C or SPI interfaces, responsible for receiving data processed by the Applets and executing subsequent business actions, such as device control and data reporting. The mobile terminal establishes a connection with the module's CLF via NFC to send or receive data. The CLF forwards the received RF data to the Applet within the eSE (such as Applet1), and the Applet performs business logic processing on the data, such as authentication, parsing, and rule matching. After processing the data, the applet reports the result to the MCU via the I2C or SPI interface. The MCU then performs specific actions based on the data, such as controlling the device or triggering prompts.

[0117] The fourth embodiment of this application provides an NFC-based smart hardware interaction method applied to a mobile terminal, including steps A10-A30:

[0118] Step A10: Perform signal conversion and decoding on the received radio frequency signal to obtain the interactive data in the radio frequency signal.

[0119] Step A20: Based on the data type identifier of the interactive data, determine the associated target APP.

[0120] Step A30: Send a launch command containing the interactive data to the target APP.

[0121] In this embodiment, after the NFC antenna built into the mobile phone enters the sensing range of the NFC chip, it couples to a radio frequency signal via electromagnetic induction. The coupled high-frequency radio frequency electromagnetic wave is converted into a weak electrical signal and transmitted to the radio frequency front-end circuit of the mobile phone's NFC module. The radio frequency front-end circuit amplifies the electrical signal to a processable amplitude using a low-noise amplifier, and then filters out noise signals of non-target frequencies using a bandpass filter, retaining the pure target electrical signal. The NFC module processes the filtered electrical signal according to a preset demodulation protocol, and converts the amplitude changes into high and low level baseband signals by detecting changes in the electrical signal amplitude.

[0122] The NFC module parses the baseband signal according to the NFC Forum specification, identifies the start and stop bits of the data frame, and extracts the complete data frame. Simultaneously, it verifies the data frame against tampering or transmission loss using an intra-frame check bit; if verification fails, the frame is discarded and re-received. After acquiring a successfully verified data frame, it splits it into a record header, type field, payload, and record trailer according to the specification. It extracts the data type identifier from the type field, parses the core interactive data in the payload (such as health alerts and payment status), and finally outputs the data type identifier and structured interactive data.

[0123] The target app declares the supported data type identifiers in its configuration file, informing the system which types of interactive data the app can handle. From the parsed interactive data, the format of the data type identifier is determined. The system application mapping table is traversed, and all apps registered with NFC data type identifiers in the application management database are searched. The identifier registered by the app is compared with the currently extracted identifier. If a unique matching app exists, its package name or Bundle ID is directly obtained. If multiple matching apps exist, a selection pop-up window appears, allowing the user to manually select the target app. If no matching app exists, the system will indicate that no application can process the data. The system-level wake-up mechanism (Intent / URLScheme) packages the launch command and interactive data and sends them to the target app to wake it up.

[0124] After step A30, steps A40 to A50 may also be included:

[0125] Step A40: Obtain health data from the radio frequency signal, and determine the target storage location based on the health data and preset data storage rules.

[0126] Step A50: Store the health data at the target location.

[0127] In this embodiment, the protocol header and checksum are stripped from the data frame to extract the core payload data; the payload data is parsed according to the preset JSON field mapping rules and converted into a standardized health data model within the APP, including: consumption time, merchant, total calories, and a list of products exceeding the standard; thus obtaining structured health data.

[0128] The storage rule base configuration is loaded. Rules are stored in key-value pairs and conditional statements. Data storage rules include time-dimensional rules, data type rules, and deduplication rules. Time-dimensional rules convert consumption time to the current date to match daily dietary records, with the target storage location being the `daily_diet_record` table in the database, partitioned by date. Data type rules associate total calories with daily calorie statistics; products exceeding the limit are associated with risk alerts. Deduplication rules classify health data from the same merchant with the same total calorie intake within a preset timeframe, such as 10 minutes, as duplicate data. Health data is then matched against the data storage rules to determine the multi-dimensional target storage location.

[0129] Complete, standardized health data is written into the database, assigning each data point a unique identifier and associating it with user IDs, consumption timestamps, etc. Based on the main storage data, the storage of related functional modules is synchronously updated. Total calories are included in the daily diet record module and merged with data from other dietary scenarios. Details of products exceeding the recommended daily intake are written into the dietary risk alert module, creating targeted risk records. After storage, relevant statistical indicators are updated, transforming the raw data into usable functional support. Existing statistical data from related storage modules is read and added to the imported data for cumulative calculation. For example, daily total calories = original cumulative value + current total calories; number of times exceeding the recommended daily intake = original number of times + number of times corresponding to the products exceeding the recommended daily intake. If the updated indicators reach preset thresholds, the corresponding status is marked. For example, if the daily total calories exceed the recommended daily intake for adults, it is marked as exceeding the recommended daily intake. Simultaneously, the updated indicators are synchronized to the APP's memory cache to ensure that the homepage, diet record page, and other UI interfaces can display the latest data in real time.

[0130] Based on the first embodiment of this application, in the fifth embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0131] In this embodiment, a specific data interaction process is provided in a scenario where a user's mobile phone touches an NFC interactive device to launch an APP, the APP interacts with the Applet through the NFC contactless channel to exchange user authentication information, the Applet authenticates the data as valid and performs corresponding business or logic processing, and then pushes the processed data to the MCU. The MCU confirms the user's identity as valid and then controls the opening of the door / gate.

[0132] Please refer to Figure 4In step 101, the mobile terminal and the NFC interactive device physically touch, the mobile terminal activates its radio frequency field, and sends a data read request to the NFC interactive device according to the preset NFC communication protocol. After responding to the request, the NFC interactive device reads the complete data from the pre-stored NDEF record, including structured fields such as application identifier, service type, and security parameter metadata. In step 102, after receiving the terminal's read request and completing the data retrieval, the NFC interactive device transmits the complete NDEF record information back to the mobile terminal through the NFC radio frequency channel according to the NDEF data exchange specification, ensuring that the terminal obtains the same and complete basic interactive data as stored in the module. In step 103, after receiving the returned NDEF record data, the mobile terminal's NFC system service parses the data, extracts the application identifier field (such as the AAR application package name for Android and the associated domain name for iOS), and matches it with the list of locally installed applications on the terminal. If a corresponding target APP exists, it is automatically launched through a system-level startup mechanism, such as Android's Intent wake-up or iOS's deep link wake-up. If it is not installed, a download guide is triggered. In step 104, the launched APP initializes its NFC communication module. Based on the service type parsed from the NDEF record, such as access control verification, it generates a data packet containing an Applet selection command and sends it to the NFC interactive device via the mobile terminal, requesting to establish a dedicated communication link with a specific Applet application preset in the NFC interactive device. In step 105, after receiving the Applet selection command sent by the APP, the NFC interactive device matches and activates the corresponding Applet application. The Applet retrieves initial data related to the current service from its own storage unit, such as a random number seed, service configuration parameters, and permission verification template, encapsulates it into a response data packet according to a preset communication format, and returns it to the launched APP via the NFC link, providing basic parameters for subsequent security authentication and service data interaction. In step 106, the APP, based on the initial data obtained from the Applet, such as the random number RND1, and combined with locally stored keys, user IDs, and other user security credentials, processes the data according to a preset security algorithm to generate authentication data, such as encrypted user permission information and MAC checksums, and sends it to the Applet. Upon receiving the data, the Applet uses its own stored key and algorithm to decrypt and verify the authentication data. After confirming the user's legitimacy, it exchanges core business data bidirectionally with the APP, such as user access control permission details and payment order information. In step 107, after completing the security authentication and business data interaction, the Applet integrates the interaction results and, according to the data format specified by the HCI protocol, sends the business data, including execution instructions, user information digests, and business result identifiers, to the main control unit of the access control / turnstile through a hardware interface (such as UART or SPI).After receiving the business data sent by the Applet, the main control unit of the access control / turnsaw parses and verifies the gate opening command and the business result identifier of the authorized access in the data. After confirming that the data is legal and valid, it sends a control signal to the actuator of the turnsaw (such as a motor or electromagnetic lock) to drive the turnsaw to complete the gate opening action, and at the same time triggers the matching voice broadcast module or indicator light prompt.

[0133] Please refer to Figure 5In step 106a, the APP, triggered by the NDEF data, generates a security authentication request data packet based on the security parameters in the parsed NDEF data. This packet contains a user identity digest and authentication algorithm version information. The packet is then sent to the specified Applet application on the NFC interactive device via the mobile terminal. In step 106b, after verifying the validity of the request data packet format, the Applet activates its built-in random number generator to generate a unique and unpredictable random number RND1. This random number is then encapsulated into a data packet according to the response format specified in the protocol and returned to the APP on the mobile terminal via the NFC radio frequency channel. In step 106c, after receiving the random number returned by the Applet, the APP uses locally stored security credentials, such as a user-pre-stored shared key or a device-bound private key. Following the encryption algorithm specified in the NDEF data, the APP combines the random number with the user identity, current timestamp, and other data to generate a unique MAC (Message Authentication Code). Simultaneously, the MAC and the digest information of the original random number are encapsulated into a response data packet, which is then sent back to the Applet via the NFC channel. In step 106d, after receiving the MAC and related data sent by the APP, the Applet retrieves the corresponding shared key stored in its own memory, recalculates the MAC on the original random number according to the same encryption algorithm and data combination rules, and compares the calculated result with the MAC sent by the APP. If the comparison is consistent, the APP's identity is deemed legitimate, and an authentication success result is returned; if the comparison fails, an authentication failure result is returned and the process terminates. In step 106e, after receiving the authentication success result and basic business data, the APP extracts the core business data stored locally, such as the access control permission ID, according to the current access control permission verification business scenario. It then performs structured encapsulation according to the interaction format specifications returned by the Applet and sends it to the Applet through the established secure channel. After receiving the data, the Applet parses the business data, performs preliminary verification based on its own stored rules, such as the access control permission whitelist and health data judgment standards, and simultaneously returns a data reception confirmation receipt to the APP. The Applet performs deep validation on the business data sent by the App, such as checking if the access control ID is on the whitelist. It then generates the final business processing result (i.e., successful permission verification), encapsulates the result identifier and the processed structured business data into a final response data packet, and returns it to the App via the NFC channel. Upon receiving the packet, the App can display the interaction result to the user, such as a pop-up window indicating successful authentication. In step 107, while returning the final result to the App, the Applet simultaneously sends the validated and standardized core business data, according to the hardware communication format specified by the HCI protocol, to the main control unit of the access control / gate through the module's hardware interface. This ensures that the business data can be accurately recognized by the hardware device, achieving data transfer from the Applet to the hardware execution device.Finally, in step 108, after receiving the business data sent by the Applet, the main control unit of the access control / turnsaw parses and verifies the execution of the gate opening command and the result identifier of the permission pass in the data. After confirming that the data format is legal and the business result is valid, it sends a control signal to the gate's execution mechanism, such as the motor drive module and the electromagnetic lock control module, to drive the gate to complete the gate opening action.

[0134] This application provides an NFC-based smart hardware interaction device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the NFC-based smart hardware interaction method described in Embodiment 1 above.

[0135] The following is for reference. Figure 6 This document illustrates a structural diagram of an NFC-based smart hardware interaction device suitable for implementing embodiments of this application. The NFC-based smart hardware interaction device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), tablet computers (PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The NFC-based smart hardware interaction device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0136] like Figure 6As shown, an NFC-based smart hardware interaction device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the NFC-based smart hardware interaction device. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows NFC-based smart hardware interaction devices to exchange data wirelessly or via wired communication with other devices. Although NFC-based smart hardware interaction devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0137] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0138] The NFC-based smart hardware interaction device provided in this application, employing the NFC-based smart hardware interaction method described in the above embodiments, solves the technical problem that traditional NFC devices can only transmit fixed information unidirectionally and cannot achieve real-time bidirectional interaction with mobile terminals. Compared with the prior art, the beneficial effects of the NFC-based smart hardware interaction device provided in this application are the same as those of the NFC-based smart hardware interaction method provided in the above embodiments, and other technical features of this NFC-based smart hardware interaction device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0139] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0141] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the NFC-based smart hardware interaction method in the above embodiments.

[0142] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0143] The aforementioned computer-readable storage medium may be included in an NFC-based smart hardware interaction device; or it may exist independently and not assembled into an NFC-based smart hardware interaction device. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the NFC-based smart hardware interaction device, the NFC-based smart hardware interaction device: when the NFC chip receives a radio frequency signal sent by a mobile terminal, decodes the radio frequency signal to obtain a data packet corresponding to the radio frequency signal; sends the data packet to a preset target Applet program, the target Applet program parses the data packet to obtain interactive data; and, based on the control unit, sends the interactive data to a service execution module to control the service execution module to execute the target action corresponding to the interactive data.

[0144] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the client computer, partially on the client computer, as a standalone software package, partially on the client computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the client computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0146] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0147] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described NFC-based smart hardware interaction method. This solves the technical problem that traditional NFC devices can only transmit fixed information unidirectionally and cannot achieve real-time bidirectional interaction with mobile terminals. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the NFC-based smart hardware interaction method provided in the above embodiments, and will not be repeated here.

[0148] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A smart hardware interaction method based on NFC, applied to an NFC interaction device, characterized in that, The NFC interactive device includes an NFC chip, an Applet program, and a control unit. The NFC-based smart hardware interaction method includes: When the NFC chip receives a radio frequency signal sent by the mobile terminal, it decodes the radio frequency signal to obtain the data packet corresponding to the radio frequency signal; The data packet is sent to a preset target applet program, which parses the data packet to obtain interactive data. Based on the control unit, the interactive data is sent to the business execution module to control the business execution module to execute the target action corresponding to the interactive data; The NFC interactive device is a POS machine, the data packet is a payment data packet, and the interactive data includes payment data and health data. The step of sending the data packet to a preset target Applet program, and the target Applet program parsing the data packet to obtain the interactive data includes: When the target Applet program receives the payment data packet, it calls a preset encryption algorithm to decrypt the payment data packet and obtains the payment token, user authorization identifier, and payment amount identifier; The system calls the POS terminal identifier associated with the target Applet program, generates an order data retrieval request based on the POS terminal identifier and the settlement timestamp, and sends the order data retrieval request to the control unit to trigger the control unit to obtain the corresponding order data, which includes initial health data and order amount. When the target Applet program receives the order data, it generates health reminder data based on preset health rules and the initial health data; The health reminder data, the payment token, the user authorization identifier, and the order amount are sent to the control unit.

2. The NFC-based smart hardware interaction method as described in claim 1, characterized in that, Before the step of decoding the radio frequency signal sent by the mobile terminal when the NFC chip receives the radio frequency signal, and obtaining the data packet corresponding to the radio frequency signal, the NFC-based smart hardware interaction method further includes: When the control unit receives Applet program data, it performs an integrity check on the Applet program data; The successfully verified Applet program data is stored in the security chip, and the Applet program data is initialized and activated to obtain the Applet program.

3. The NFC-based smart hardware interaction method as described in claim 1, characterized in that, Before the step of sending the data packet to a preset target applet program, and the target applet program parsing the data packet to obtain interactive data, the NFC-based smart hardware interaction method further includes: Obtain the Applet selection instruction from the data packet, and determine the target application identifier based on the Applet selection instruction; The target application identifier is compared with each preset application identifier to determine the matching target applet program.

4. The NFC-based smart hardware interaction method as described in claim 1, characterized in that, The step of sending the interaction data to the service execution module based on the control unit, so as to control the service execution module to execute the target action corresponding to the interaction data, includes: When the control unit receives the health reminder data, it generates a display instruction based on the preset display rules and the health reminder data, and sends the display instruction to the display module of the POS machine; The display module determines display parameters based on the display instructions, converts the display parameters into pixel data, and displays the pixel data on the display screen.

5. The NFC-based smart hardware interaction method as described in claim 1, characterized in that, The NFC-based smart hardware interaction method further includes: The control unit encapsulates the health reminder data and payment status into a data frame and sends the data frame to the NFC chip through the HCI interface; The NFC chip receives and modulates the data frame into a radio frequency signal, and then sends the radio frequency signal to a mobile terminal within the sensing range.

6. A smart hardware interaction method based on NFC, applied to a mobile terminal, characterized in that, The NFC-based smart hardware interaction method, based on any one of claims 1-5, comprises: The received radio frequency signal is converted and decoded to obtain the interactive data in the radio frequency signal; Based on the data type identifier of the interactive data, the associated target APP is determined; Send a launch command containing the interactive data to the target APP.

7. The NFC-based smart hardware interaction method as described in claim 6, characterized in that, The interactive data is health data. After the step of sending a launch command containing the interactive data to the target APP, the NFC-based smart hardware interaction method further includes: Acquire health data from the radio frequency signal, and determine the target storage location based on the health data and preset data storage rules; The health data is stored at the target location.

8. An NFC-based smart hardware interaction device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the NFC-based smart hardware interaction method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the NFC-based smart hardware interaction method as described in any one of claims 1 to 7.

Images