Intelligent card compatible system based on multi-standard near field communication

Abstract

The invention relates to the technical field of intelligent cards, in particular to an intelligent card compatible system based on multi-standard near field communication, which comprises a multi-protocol card identification and feature anchoring module, a multi-protocol card identification and feature anchoring module, a multi-protocol card identification and feature anchoring module and a multi-protocol card identification and feature anchoring module, the heterogeneous data layering virtualization module is used for mapping the identified original data frame to a physical layer presentation layer, uniformly converting protocol layer data and realizing dynamic semantic adaptation adjustment; traditional static instruction matching logic is abandoned, characteristic anchor points are used for replacing protocol instruction set dependence, a characteristic vector clustering algorithm is combined, distortion data frames with deviation can be accurately recognized, meanwhile, protocol and security characteristic two dimensions are fused, a standard and an unknown protocol are compatible, protocol fragmentation is avoided, and the pain point of recognition failure under weak interference is solved. The protocol identification accuracy and compatibility in a complex environment are improved, dependence on a fixed instruction set is not needed, and the method is more suitable for a heterogeneous communication scene.

Description

Technical Field

[0001] This invention relates to the field of smart card technology, and more specifically to a smart card compatible system based on multi-standard near-field communication. Background Technology

[0002] Smart cards based on multi-standard near-field communication are smart card carriers that integrate multi-protocol recognition, dynamic adaptation and edge computing capabilities. They can be compatible with and adapt to multiple mainstream near-field communication protocols, enabling efficient and secure interaction with different terminal devices.

[0003] Existing technologies rely on fixed protocol instruction sets for matching. When faced with scenarios involving protocol fragmentation, weak signal interference, or distortion of data frames, the recognition accuracy drops significantly or even fails completely. Traditional methods can only identify predefined standard protocols and cannot be compatible with unknown protocols. They are also difficult to adapt to the complex needs of heterogeneous communication scenarios. The data formats and business semantics of different protocols are not consistent, resulting in cross-protocol data being only able to achieve simple translation at the format level, unable to achieve interoperability of application layer semantics, and inefficient cross-scenario data interaction. Summary of the Invention

[0004] This invention addresses the technical problems existing in the prior art by providing a smart card compatible system based on multi-standard near-field communication.

[0005] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A smart card compatible system based on multi-standard near-field communication, comprising: Multi-protocol card identification and feature anchoring module: Receives the original communication frames sent by the smart card, performs noise reduction processing on the frame signal, and extracts and matches feature anchor points; Heterogeneous data layered virtualization module: maps the identified raw data frames to the physical layer representation layer, uniformly converts protocol layer data, and realizes dynamic semantic adaptation and adjustment; Dual-modal storage carrier dynamic adaptation module: The smart card has a built-in protocol detection sensor that identifies the terminal protocol and automatically switches the access protocol of the storage area according to the terminal protocol type; Carrier-side edge computing dynamic data processing module: The smart card has a built-in edge computing chip, which performs noise reduction, distortion correction and feature extraction on the data to generate pre-processed effective data. According to the protocol type, it automatically adjusts the data processing logic to realize a collaborative mode of local processing on the carrier side and interaction with the terminal.

[0006] In a preferred embodiment, the multi-protocol card identification and feature anchoring module performs noise reduction optimization on the received original frame signal, uses an adaptive filtering algorithm to remove electromagnetic interference, environmental noise and signal distortion caused by card aging, converts the noise-reduced frame data into a unified digital signal format, classifies and marks the frame fields according to the protocol type, and generates standardized preprocessed frame data. A multi-protocol feature anchor library is established based on the received data. The multi-protocol feature anchor library pre-stores the core feature anchors of each mainstream protocol. The core feature anchors include: protocol type anchors, structural feature anchors, and security feature anchors. Feature anchors are extracted from standardized preprocessed frame data. The frame synchronization code anchor is located, and the check bit anchor, data segment length anchor, and security feature anchor are extracted in sequence. The extracted feature anchors are converted into feature vectors. Each feature vector contains three dimensions: protocol type feature value, structural feature value, and security feature value. The feature vectors in the temporary feature buffer are compared with the feature vectors in the feature anchor library. The cosine similarity algorithm is used to calculate the matching degree. A preset matching degree threshold is set. When the calculation result exceeds the preset matching degree threshold, the frame data is determined to match the corresponding protocol type. If the matching degree does not exceed the preset matching degree threshold, it is determined to be an unknown protocol frame and enters the unknown protocol identification mode. When a match is successful, the protocol type is determined directly based on the feature vector matching result, and the security verification rules of the corresponding protocol are invoked to evaluate the security level of the card. When a match fails, the unknown protocol identification mode is activated. The carrier edge computing dynamic data processing module analyzes the modulation method, encoding rules and frame structure of the unknown frame, generates new feature anchors and updates them to the feature anchor library.

[0007] In a preferred embodiment, the heterogeneous data layered virtualization module receives a preprocessed frame whose protocol type has been determined in the multi-protocol card identification and feature anchoring module, and synchronously parses and records the physical attributes of the frame, including: transmission parameters, frame structure parameters and protocol identifier. The original preprocessed frame is fully mapped to the physical layer representation layer, using the storage structure of the original frame and attribute tags: Raw frame binary data: The preprocessed frame bitstream is completely preserved without any format conversion; Physical attribute tags: Store the parsed transmission parameters, frame structure parameters, and protocol identifiers in key-value pairs; Mapping rules: Ensure that the physical characteristics of the original data are intact, providing a traceable original basis for subsequent protocol layer conversion; Based on the protocol identifier mapped by the physical layer, the corresponding protocol conversion driver is automatically loaded. The driver predefines the frame field format and conversion rules for the determined protocol type, decomposes the original frame of the physical layer mapping, extracts the core data fields of each protocol, and converts the decomposed protocol fields into a standardized PDDU format. The valid data of the PDDU is mapped into scenario-based business semantic units, including: financial payment scenario, access control and attendance scenario, and industrial traceability scenario. Based on scenario priority and real-time requirements, the semantic identification rules are dynamically adjusted, including: high-priority scenarios, low-latency scenarios, and; Conflict detection is performed on semantic units from multiple protocol sources. When semantic fields from different protocols overlap, the conflict is resolved using rules based on scenario priority and timestamp.

[0008] In a preferred embodiment, in the dual-modal storage carrier dynamic adaptation module, after the smart card is powered on, the built-in protocol detection sensor is automatically woken up, completes the initialization configuration, and enters a low-power standby mode to monitor the radio frequency interaction status between the smart card and the terminal in real time. When the terminal is detected to be close, the wake-up mechanism is automatically triggered to start the protocol identification process. The sensor receives the radio frequency signal transmitted by the terminal and extracts the core features of the terminal's radio frequency signal, including: protocol feature extraction, communication parameter feature extraction, and protocol identifier feature extraction. Protocol feature extraction: Perform frame structure analysis on radio frequency signals, locate frame synchronization codes and instruction set features in the signals, and identify the modulation methods and coding rules of the signals to extract protocol-specific signal modulation and coding features; Communication parameter feature extraction: Through the signal detection module, the communication rate, radio frequency field strength and signal transmission duration of the radio frequency signal are collected and extracted in real time. At the same time, the stable transmission parameters of the signal are recorded to form the basic parameter feature set of terminal communication. Protocol identifier feature extraction: The extracted protocol features are compared one by one with the mainstream protocol features in the sensor's built-in protocol type library, and the unique identifier features of the protocol corresponding to the protocol type library are matched and extracted. The sensor compares the extracted radio frequency signal features with a protocol type library, calculates the matching degree using a feature vector matching algorithm, and determines the terminal's protocol type. If a match is successful, output the terminal protocol type directly; When matching fails, the unknown protocol identification mode is activated. The edge computing module analyzes the frame structure and encoding rules of the terminal radio frequency signal, generates new protocol features and updates them to the protocol type library, and outputs the unknown protocol identifier. After receiving the terminal protocol type report, confirm the status of the smart card's dual-modal storage area: the protocol adaptation area and the application encryption storage area; Based on the terminal protocol type, the access protocol of the storage area is automatically matched and switched. When the terminal protocol type is an unknown protocol, the compatibility mode is started and the general protocol instruction set is used to interact with the terminal. After switching the access protocol, the control module confirms the terminal's permissions through a security verification mechanism and uses the SM2 algorithm for two-way authentication to verify whether the terminal has the permission to access the corresponding storage area. If the authentication is successful, the terminal is allowed to read the data in the corresponding storage area. If the authentication fails, access is denied and an exception log is recorded. The SM2 algorithm is used for two-way authentication. Specifically, the smart card and the terminal each load their legitimate SM2 public keys and generate a one-time random number to ensure that the authentication is not replayable. The terminal sends the device identifier, storage area access request and random number to the smart card after signing it with its own private key. The smart card verifies the signature with the pre-stored terminal public key to confirm the terminal's legitimacy. The smart card then sends its own identifier, storage area permission information and terminal random number to the terminal after signing it with its own private key. The terminal verifies the signature with the pre-stored smart card public key to confirm the smart card's legitimacy. When both verifications pass, the two-way authentication is successful, and the smart card grants the terminal access to the storage area. If either step fails, access is denied, and an exception log is recorded. The terminal interacts with the smart card with data according to the switched access protocol, including: read scenarios and write scenarios; If the interaction between the terminal and the smart card ends, the sensor and control module automatically return to low-power standby mode, waiting for the next terminal wake-up; The sensor compares the extracted radio frequency signal features with a protocol type library. Specifically, the extracted three types of radio frequency signal features are normalized according to the feature dimensions, order, and expression specifications pre-stored in the protocol type library to generate a feature set to be matched that is consistent with the features in the library. This eliminates format and dimension differences and ensures comparability. Based on the normalized feature set to be matched, a full-domain feature search is performed in the protocol type library. A coarse match is first performed, and then a candidate protocol set that is consistent with the core protocol identifier features in the feature set to be matched is selected. Protocol types that do not match obviously are eliminated to narrow the comparison range. For the candidate protocols obtained from the coarse match, their corresponding complete feature sets in the library are extracted and compared with the feature set to be matched dimension by dimension. The matching results of each dimension are marked.

[0009] In a preferred embodiment, in the carrier-side edge computing dynamic data processing module, after the smart card is powered on, the built-in edge computing chip automatically wakes up, completes initialization configuration, enters a low-power standby mode, and monitors the radio frequency interaction status between the smart card and the terminal in real time. When a data interaction request is detected from the terminal, the wake-up mechanism is automatically triggered, the data processing flow is started, and the edge computing chip receives the raw data sent by the terminal and parses the basic format and transmission parameters of the data. Data source: Multi-protocol data sent by the terminal via the NFC radio frequency module; Data format: Parse the frame structure, encoding method, and transmission rate of the data; An adaptive filtering algorithm is used to optimize noise reduction in the received data, eliminating electromagnetic interference, environmental noise, and signal distortion caused by card aging. To correct distortions in the data frame structure, a distortion correction algorithm is used. Frame length correction: Adjust the length of the data frame to the standard range according to the protocol feature anchor point; Data bit correction: Corrects the offset of data bits to ensure the accuracy of data fields; After noise reduction and distortion correction, preprocessed valid data is generated; The chip calls the corresponding feature extraction algorithm based on the data protocol type to extract the core features of the data, including protocol feature extraction and security feature extraction. Protocol feature extraction: Extracting protocol features such as frame synchronization code, instruction code, and data segment length from the data; Security Feature Extraction: Extracting encryption algorithm features and permission identification features from the data; The extracted features are converted into feature vectors, each of which contains two dimensions: protocol feature values ​​and security feature values. The chip determines the protocol type of the data based on its feature vector. The protocol type is output by the multi-protocol card recognition module, which automatically matches and adjusts the data processing logic according to the protocol type. When the protocol type is a financial payment protocol, the processing logic is adjusted to encryption and security verification, the data is encrypted using the SM4 algorithm, and the integrity of the data is verified. When the protocol type is a public transportation protocol, the processing logic is adjusted to fast verification and data extraction, prioritizing the extraction of core information such as the number of rides and the balance from the data. When the protocol type is an industrial traceability protocol, the processing logic is adjusted to parameter parsing and feature matching, extracting the equipment SN and inspection time parameters from the data and comparing them with the protocol feature library; The chip processes the preprocessed valid data according to the adjusted processing logic and generates the processing result: Financial payment scenarios: Generating core data such as transaction amount, transaction time, and merchant ID; Access control and attendance scenarios: Generating core data such as user ID, access permissions, and attendance time; Industrial traceability scenarios: generating core data on equipment parameters, status, and location; The chip sends the processing results to the terminal, realizing a collaborative mode of local processing on the carrier and interaction with the terminal: Data transmission: The processing results are sent to the terminal using a communication protocol supported by the terminal. Feedback confirmation: Receive feedback information from the terminal to confirm whether the data transmission was successful. If the transmission fails, resend the data. If the interaction between the terminal and the chip ends, the chip automatically returns to low-power standby mode, waiting for the next time the terminal wakes it up.

[0010] In a preferred embodiment, the multi-protocol card identification and feature anchoring module generates standardized preprocessed frame data. Specifically, this involves: quantizing the denoised analog frame signal into a system-recognizable binary digital signal; standardizing the data bit width and transmission timing; eliminating format differences between original frames of different protocols; precisely dividing the core fields of the binary frame data according to the multi-protocol common frame structure; adding three types of tags to each field: protocol type, field function, and field position; reorganizing the binary fields with classification tags according to the common frame structure of frame header identifier, synchronization code, data segment, check bit, and frame tail; removing invalid blank fields; and finally generating standardized preprocessed frame data with unified format, traceable fields, and protocol classification tags.

[0011] In a preferred embodiment, the multi-protocol card identification and feature anchoring module establishes a multi-protocol feature anchor library based on the received data. Specifically, it collects a large amount of raw communication frame data from different protocols, classifies them according to protocol type, retains complete raw frames and corresponding physical attributes for each protocol, extracts common features from the frame data of each protocol, and forms three types of core anchors, including: protocol type anchors, structural feature anchors, and security feature anchors. Protocol type anchor: Extract the unique instruction code or frame synchronization code of the protocol as a unique identifier for the protocol; Structural feature anchor points: Extract fixed structural features of the protocol frame; Security feature anchors: Extract security-related features of the protocol; The three types of feature anchors extracted are standardized and organized, and then stored in the feature anchor library after being formatted in a unified format. Each anchor record includes the protocol name, anchor type, anchor feature value and attribute description.

[0012] In a preferred embodiment, the multi-protocol card identification and feature anchoring module sequentially extracts the check bit anchor, the data segment length anchor, and the security feature anchor, specifically as follows: Check bit anchor: The check bit anchor is a fixed-format field in frame data used to verify the integrity of the frame. Its characteristics are fixed position, fixed length and specific check algorithm identifier. According to the protocol type of the preprocessed frame, the frame structure specification of the protocol is retrieved to determine the fixed position of the check bit in the frame. The binary data of the field is extracted and compared with the check algorithm identifier pre-stored in the protocol feature anchor library to confirm that it is the check bit anchor of the protocol. Data segment length anchor: The data segment length anchor is a fixed field in the frame data used to identify the length of subsequent data segments. Its characteristics are fixed position, value range and association with the data segment. According to the protocol frame structure specification, the fixed position of the data segment length anchor in the frame is determined and its value range is defined. The value of this field is extracted and verified to be consistent with the actual length of the subsequent data segment. It is confirmed to be the data segment length anchor. The protocol type, length anchor position, value range and data segment association are used as the core information of the data segment length anchor and stored in the feature anchor library. Security Feature Anchor: A security feature anchor is a field in frame data used to identify security attributes. Its characteristics include a fixed position, an encryption algorithm identifier, and an authorization verification field. Based on the protocol type, the fixed position of the security feature anchor in the frame is determined, and the encryption algorithm identifier of the field is extracted. The value of this field is compared with the authorization identifiers pre-stored in the protocol feature anchor library to confirm that it is a security feature anchor. The protocol type, security anchor position, encryption algorithm identifier, and authorization verification field are stored as the core information of the security feature anchor in the feature anchor library.

[0013] In a preferred embodiment, the multi-protocol card identification and feature anchoring module compares the feature vectors in the temporary feature cache with the feature vectors in the feature anchor library. Specifically, it reads the feature vector to be matched from the temporary feature cache. The feature vector contains feature values ​​in three dimensions: protocol type, structure, and security. At the same time, it reads all the pre-stored protocol feature vectors from the feature anchor library to ensure that the number and order of the two dimensions are aligned. For each vector to be matched and a vector in the library, calculate the similarity using the following steps: Calculate the sum of the products of the corresponding dimensions of two vectors; Calculate the sum of squares of the values ​​of each dimension of the two vectors and take the square root to obtain the length of the vectors; Divide the sum of the products by the product of the lengths of the two vectors to obtain the cosine similarity value; The calculated similarity value is compared with a preset threshold: If the similarity is greater than or equal to the threshold: determine that the frame data matches the corresponding protocol type, and output the protocol type result; If the similarity is less than the threshold, it is determined to be an unknown protocol frame, and the unknown protocol identification mode is triggered.

[0014] In a preferred embodiment, the heterogeneous data layering virtualization module extracts the core data fields of each protocol and converts the disassembled protocol fields into a standardized PDDU format. Specifically, it loads the corresponding protocol conversion driver, accurately locates the core areas of the instructions, unique card identifiers, and business-related data segments in the original frame according to the predefined frame field structure in the driver, extracts the core area data, removes redundant identifiers specific to the protocol and non-core content of empty fields, maps and converts the extracted core fields according to a unified rule, converts the protocol instruction code into a general operation code, the card identifier into a unified address identifier, and the business data as valid data, and then supplements the unified verification information and the original protocol source identifier, integrating them into a standardized PDDU format.

[0015] The beneficial effects of this invention are as follows: It abandons the traditional static instruction matching logic, replaces protocol instruction set dependency with feature anchors, and combines feature vector clustering algorithms to accurately identify distorted data frames with biases. Simultaneously, it integrates both protocol and security features, is compatible with standard and unknown protocols, solves the pain points of protocol fragmentation and identification failure under weak interference, improves the accuracy and compatibility of protocol identification in complex environments, does not rely on fixed instruction sets, is more adaptable to heterogeneous communication scenarios, and constructs a three-layer virtualization architecture of physical layer, protocol layer, and application layer. It converts multi-standard raw data into protocol-independent data units, and then maps them to scenario-based business semantic units, achieving dual alignment across protocol formats and semantics. This solves the problems of incompatibility between multi-standard data and the inability of application layer semantics to communicate, not only unifying the format but also achieving direct mapping of business semantics. This design enables more efficient cross-scenario data interaction. It features a dual-modal storage structure with a protocol adaptation area and an application encryption storage area. Combined with a built-in protocol detection sensor, it can automatically switch access protocols based on the terminal's radio frequency environment. Partition encryption ensures data security, breaking the limitations of traditional single-protocol storage. A single card can adapt to high-frequency full protocols and multiple application scenarios, improving cross-scenario adaptability. The partition encryption mechanism enhances data security. An edge computing chip is built into the smart card to achieve local noise reduction, distortion correction, protocol adaptation, and security verification, building a collaborative mode of local processing on the carrier side and terminal interaction. Coupled with a dynamic low-power sleep and wake-up mechanism, it breaks through the traditional centralized terminal processing mode, reducing processing latency and terminal computing power dependence, improving data processing efficiency. The low-power design also extends the card's battery life. Attached Figure Description

[0016] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0019] In the description of this application, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0020] like Figure 1 This embodiment provides: a smart card compatible system based on multi-standard near-field communication, comprising: Multi-protocol card identification and feature anchoring module: Receives the original communication frames sent by the smart card, performs noise reduction processing on the frame signal, and extracts and matches feature anchor points; Heterogeneous data layered virtualization module: maps the identified raw data frames to the physical layer representation layer, uniformly converts protocol layer data, and realizes dynamic semantic adaptation and adjustment; Dual-modal storage carrier dynamic adaptation module: The smart card has a built-in protocol detection sensor that identifies the terminal protocol and automatically switches the access protocol of the storage area according to the terminal protocol type; Carrier-side edge computing dynamic data processing module: The smart card has a built-in edge computing chip, which performs noise reduction, distortion correction and feature extraction on the data to generate pre-processed effective data. According to the protocol type, it automatically adjusts the data processing logic to realize a collaborative mode of local processing on the carrier side and interaction with the terminal.

[0021] In the multi-protocol card identification and feature anchoring module, the received original frame signal is denoised and optimized. An adaptive filtering algorithm is used to remove electromagnetic interference, environmental noise and signal distortion caused by card aging. The denoised frame data is converted into a unified digital signal format, and the frame fields are classified and marked according to the protocol type to generate standardized preprocessed frame data. A multi-protocol feature anchor library is established based on the received data. The multi-protocol feature anchor library pre-stores the core feature anchors of each mainstream protocol. The core feature anchors include: protocol type anchors, structural feature anchors, and security feature anchors. Feature anchors are extracted from standardized preprocessed frame data. The frame synchronization code anchor is located, and the check bit anchor, data segment length anchor, and security feature anchor are extracted in sequence. The extracted feature anchors are converted into feature vectors. Each feature vector contains three dimensions: protocol type feature value, structural feature value, and security feature value. The feature vectors in the temporary feature buffer are compared with the feature vectors in the feature anchor library. The cosine similarity algorithm is used to calculate the matching degree. A preset matching degree threshold is set. When the calculation result exceeds the preset matching degree threshold, the frame data is determined to match the corresponding protocol type. If the matching degree does not exceed the preset matching degree threshold, it is determined to be an unknown protocol frame and enters the unknown protocol identification mode. The preset matching threshold is specifically defined as follows: The preset matching threshold is the core benchmark value for determining whether feature vectors match. It is a fixed judgment boundary calibrated by combining the actual needs of multi-protocol feature matching and historical recognition accuracy. It is used to define the numerical boundary between valid and invalid matches and serves as the basis for judging the cosine similarity calculation results. The matching results are filtered using this fixed boundary. If the calculated similarity exceeds the threshold, it is determined that the frame to be matched is highly consistent with the protocol features in the library, which is a valid match. If it does not exceed the threshold, it is determined that the feature consistency is insufficient, which is an invalid match. This achieves automated and standardized determination of protocol types, while accurately triggering the unknown protocol recognition mode, avoiding mismatches with low consistency, and ensuring the accuracy and uniqueness of protocol recognition. When a match is successful, the protocol type is determined directly based on the feature vector matching result, and the security verification rules of the corresponding protocol are invoked to evaluate the security level of the card. When a match fails, the unknown protocol identification mode is activated. The carrier edge computing dynamic data processing module analyzes the modulation method, encoding rules and frame structure of the unknown frame, generates new feature anchors and updates them to the feature anchor library.

[0022] In the heterogeneous data layered virtualization module, the preprocessed frame whose protocol type has been determined in the multi-protocol card identification and feature anchoring module is received, and the physical attributes of the frame are parsed and recorded synchronously, including: transmission parameters, frame structure parameters and protocol identifier. Among them, transmission parameters include: communication rate, modulation method, and coding rules; Frame structure parameters: frame synchronization code, data segment length, parity bit type, and frame tail identifier; Protocol identifier: The identified protocol type; The original preprocessed frame is fully mapped to the physical layer representation layer, using the storage structure of the original frame and attribute tags: Raw frame binary data: The preprocessed frame bitstream is completely preserved without any format conversion; Physical attribute tags: Store the parsed transmission parameters, frame structure parameters, and protocol identifiers in key-value pairs; Mapping rules: Ensure that the physical characteristics of the original data are intact, providing a traceable original basis for subsequent protocol layer conversion; Based on the protocol identifier mapped by the physical layer, the corresponding protocol conversion driver is automatically loaded. The driver predefines the frame field format and conversion rules for the determined protocol type, decomposes the original frame of the physical layer mapping, extracts the core data fields of each protocol, and converts the decomposed protocol fields into a standardized PDDU format. The valid data of the PDDU is mapped into scenario-based business semantic units, including: financial payment scenario, access control and attendance scenario, and industrial traceability scenario. In the financial payment scenario, the effective data of PDDU is mapped to semantic fields such as transaction amount, transaction time, merchant ID, and card balance. Access control and attendance scenarios: mapped to semantic fields such as user ID, access control permissions, attendance time, and device number; Industrial traceability scenario: mapped to semantic fields such as device serial number (SN), inspection time, parameter values, and location information; Based on scenario priority and real-time requirements, the semantic identification rules are dynamically adjusted, including: high-priority scenarios, low-latency scenarios, and; Among them, high-priority scenarios prioritize ensuring the accuracy and completeness of transaction amounts and core semantic fields of verification information; Low-latency scenarios: Simplify non-core semantic fields to improve semantic conversion efficiency; Complex scenarios: Add extended semantic fields to retain more original data details; Conflict detection is performed on semantic units from multiple protocol sources. When semantic fields from different protocols overlap, the conflict is resolved using rules based on scenario priority and timestamp.

[0023] In the dual-modal storage carrier dynamic adaptation module, after the smart card is powered on, the built-in protocol detection sensor is automatically woken up, completes the initialization configuration, and enters a low-power standby mode to monitor the radio frequency interaction status between the smart card and the terminal in real time. When the terminal is detected to be close, the wake-up mechanism is automatically triggered to start the protocol identification process. The sensor receives the radio frequency signal transmitted by the terminal and extracts the core features of the terminal radio frequency signal, including: protocol feature extraction, communication parameter feature extraction and protocol identifier feature extraction. Protocol feature extraction: Perform frame structure analysis on radio frequency signals, locate frame synchronization codes and instruction set features in the signals, and identify the modulation methods and coding rules of the signals to extract protocol-specific signal modulation and coding features; Communication parameter feature extraction: Through the signal detection module, the communication rate, radio frequency field strength and signal transmission duration of the radio frequency signal are collected and extracted in real time. At the same time, the stable transmission parameters of the signal are recorded to form the basic parameter feature set of terminal communication. Protocol identifier feature extraction: The extracted protocol features are compared one by one with the mainstream protocol features in the sensor's built-in protocol type library, and the unique identifier features of the protocol corresponding to the protocol type library are matched and extracted. The process involves comparing the extracted protocol features with the mainstream protocol features in the sensor's built-in protocol type library one by one. Specifically, the extracted protocol features are standardized according to the dimensions, order, and expression specifications of the pre-stored features in the protocol type library to eliminate format differences and ensure that single-dimensional comparisons are direct. The complete feature set of the first mainstream protocol is retrieved from the protocol type library and compared with the standardized protocol features to be matched dimension by dimension. The matching results are marked. After completion, the next protocol feature set is retrieved, and the dimension-by-dimensional comparison is repeated until all mainstream protocols in the library are traversed. During the comparison process, core exclusive features are verified first. If the core features do not match, the comparison of the remaining features of the protocol is skipped, and the comparison process of the next protocol is started, thereby improving the comparison efficiency. The sensor compares the extracted radio frequency signal features with a protocol type library, calculates the matching degree using a feature vector matching algorithm, and determines the terminal's protocol type. If a match is successful, output the terminal protocol type directly; When matching fails, the unknown protocol identification mode is activated. The edge computing module analyzes the frame structure and encoding rules of the terminal radio frequency signal, generates new protocol features and updates them to the protocol type library, and outputs the unknown protocol identifier. After receiving the terminal protocol type report, confirm the status of the smart card's dual-modal storage area: the protocol adaptation area and the application encryption storage area; The protocol adaptation area stores basic data such as card UID, protocol characteristics, and security keys, supporting high-frequency access to all protocols. Encrypted storage area: It adopts the national cryptographic SM4 algorithm for encryption, and is divided into independent partitions for finance, transportation and access control areas. Each partition corresponds to a unique access key and supports high-frequency protocol access. Based on the terminal protocol type, the access protocol of the storage area is automatically matched and switched. When the terminal protocol type is an unknown protocol, the compatibility mode is started and the general protocol instruction set is used to interact with the terminal. After switching the access protocol, the control module confirms the terminal's permissions through a security verification mechanism and uses the SM2 algorithm for two-way authentication to verify whether the terminal has the permission to access the corresponding storage area. If the authentication is successful, the terminal is allowed to read the data in the corresponding storage area. If the authentication fails, access is denied and an exception log is recorded. The SM2 algorithm is used for two-way authentication. Specifically, the smart card and the terminal each load their legitimate SM2 public keys and generate a one-time random number to ensure that the authentication is not replayable. The terminal sends the device identifier, storage area access request and random number to the smart card after signing it with its own private key. The smart card verifies the signature with the pre-stored terminal public key to confirm the terminal's legitimacy. The smart card then sends its own identifier, storage area permission information and terminal random number to the terminal after signing it with its own private key. The terminal verifies the signature with the pre-stored smart card public key to confirm the smart card's legitimacy. When both verifications pass, the two-way authentication is successful, and the smart card grants the terminal access to the storage area. If either step fails, access is denied, and an exception log is recorded. The terminal interacts with the smart card with data according to the switched access protocol, including: read scenarios and write scenarios; In the reading scenario: the terminal sends a reading command according to the corresponding protocol, and the smart card returns the data from the storage area through the switched access protocol; Write scenario: The terminal sends a write command according to the corresponding protocol, and the smart card writes the data to the specified storage partition through the switched access protocol; If the interaction between the terminal and the smart card ends, the sensor and control module automatically return to low-power standby mode, waiting for the next terminal wake-up; The sensor compares the extracted radio frequency signal features with a protocol type library. Specifically, the extracted three types of radio frequency signal features are normalized according to the feature dimensions, order, and expression specifications pre-stored in the protocol type library to generate a feature set to be matched that is consistent with the features in the library. This eliminates format and dimension differences and ensures comparability. Based on the normalized feature set to be matched, a full-domain feature search is performed in the protocol type library. A coarse match is first performed, and then a candidate protocol set that is consistent with the core protocol identifier features in the feature set to be matched is selected. Protocol types that do not match obviously are eliminated to narrow the comparison range. For the candidate protocols obtained from the coarse match, their corresponding complete feature sets in the library are extracted and compared with the feature set to be matched dimension by dimension. The matching results of each dimension are marked.

[0024] In the aforementioned carrier-side edge computing dynamic data processing module, after the smart card is powered on, the built-in edge computing chip automatically wakes up, completes initialization configuration, and enters a low-power standby mode. It monitors the radio frequency interaction status between the smart card and the terminal in real time. When a data interaction request is detected from the terminal, the wake-up mechanism is automatically triggered, initiating the data processing flow. The edge computing chip receives the raw data sent by the terminal and parses the basic data format and transmission parameters. Data source: Multi-protocol data sent by the terminal via the NFC radio frequency module; Data format: Parse the frame structure, encoding method, and transmission rate of the data; An adaptive filtering algorithm is used to optimize noise reduction in the received data, eliminating electromagnetic interference, environmental noise, and signal distortion caused by card aging. To correct distortions in the data frame structure, a distortion correction algorithm is used. Frame length correction: Adjust the length of the data frame to the standard range according to the protocol feature anchor point; Data bit correction: Corrects the offset of data bits to ensure the accuracy of data fields; After noise reduction and distortion correction, preprocessed valid data is generated; The method employs an adaptive filtering algorithm to optimize noise reduction in the received data. Specifically, it monitors noise characteristics in the received data in real time, extracts the time-domain and frequency-domain variation patterns of noise through a built-in noise feature recognition module, automatically adjusts the core parameters of the filtering algorithm based on the captured noise characteristics, achieves dynamic adaptation of filtering characteristics, ensures accurate suppression of different types of noise, and performs real-time filtering on the received data based on the adjusted filtering parameters to remove noise interference and signal distortion, retain the core effective information of the original data, and finally outputs clean data after noise reduction optimization, providing a high-quality data foundation for subsequent feature extraction. The chip calls the corresponding feature extraction algorithm based on the data protocol type to extract the core features of the data, including protocol feature extraction and security feature extraction. Protocol feature extraction: Extracting protocol features such as frame synchronization code, instruction code, and data segment length from the data; Security Feature Extraction: Extracting encryption algorithm features and permission identification features from the data; The extracted features are converted into feature vectors, each of which contains two dimensions: protocol feature values ​​and security feature values. The chip determines the protocol type of the data based on its feature vector. The protocol type is output by the multi-protocol card recognition module, which automatically matches and adjusts the data processing logic according to the protocol type. When the protocol type is a financial payment protocol, the processing logic is adjusted to encryption and security verification, the data is encrypted using the SM4 algorithm, and the integrity of the data is verified. When the protocol type is a public transportation protocol, the processing logic is adjusted to fast verification and data extraction, prioritizing the extraction of core information such as the number of rides and the balance from the data. When the protocol type is an industrial traceability protocol, the processing logic is adjusted to parameter parsing and feature matching, extracting the equipment SN and inspection time parameters from the data and comparing them with the protocol feature library; The chip processes the preprocessed valid data according to the adjusted processing logic and generates the processing result: Financial payment scenarios: Generating core data such as transaction amount, transaction time, and merchant ID; Access control and attendance scenarios: Generating core data such as user ID, access permissions, and attendance time; Industrial traceability scenarios: generating core data on equipment parameters, status, and location; The chip sends the processing results to the terminal, realizing a collaborative mode of local processing on the carrier and interaction with the terminal: Data transmission: The processing results are sent to the terminal using a communication protocol supported by the terminal. Feedback confirmation: Receive feedback information from the terminal to confirm whether the data transmission was successful. If the transmission fails, resend the data. If the interaction between the terminal and the chip ends, the chip automatically returns to low-power standby mode, waiting for the next time the terminal wakes it up.

[0025] In the multi-protocol card identification and feature anchoring module, standardized preprocessed frame data is generated. Specifically, the denoised analog frame signal is quantized and converted into a binary digital signal that the system can recognize. The bit width and transmission timing specifications of the data are standardized, the format differences of the original frames of different protocols are eliminated, and the core fields of the binary frame data are accurately divided according to the multi-protocol general frame structure. Three types of tags are added to each field: protocol type, field function, and field position. The binary fields with classification tags are reorganized according to the general frame structure of frame header identifier, synchronization code, data segment, check bit, and frame tail. Invalid blank fields are removed, and finally standardized preprocessed frame data with uniform format, traceable fields, and protocol classification tags are generated.

[0026] In the multi-protocol card identification and feature anchoring module, a multi-protocol feature anchor point library is established based on the received data. Specifically, a large amount of raw communication frame data from different protocols is collected, classified according to protocol type, and each protocol retains the complete raw frame and corresponding physical attributes. Common features are extracted from the frame data of each protocol to form three types of core anchor points, including: protocol type anchor points, structural feature anchor points, and security feature anchor points. Protocol type anchor: Extract the unique instruction code or frame synchronization code of the protocol as a unique identifier for the protocol; Structural feature anchor points: Extract fixed structural features of the protocol frame; Security feature anchors: Extract security-related features of the protocol; The three types of feature anchors extracted are standardized and organized, and then stored in the feature anchor library after being formatted in a unified format. Each anchor record includes the protocol name, anchor type, anchor feature value and attribute description.

[0027] In the multi-protocol card identification and feature anchoring module, the check bit anchor, data segment length anchor, and security feature anchor are extracted sequentially, specifically as follows: Check bit anchor: The check bit anchor is a fixed-format field in frame data used to verify the integrity of the frame. Its characteristics are fixed position, fixed length and specific check algorithm identifier. According to the protocol type of the preprocessed frame, the frame structure specification of the protocol is retrieved to determine the fixed position of the check bit in the frame. The binary data of the field is extracted and compared with the check algorithm identifier pre-stored in the protocol feature anchor library to confirm that it is the check bit anchor of the protocol. Data segment length anchor: The data segment length anchor is a fixed field in the frame data used to identify the length of subsequent data segments. Its characteristics are fixed position, value range and association with the data segment. According to the protocol frame structure specification, the fixed position of the data segment length anchor in the frame is determined and its value range is defined. The value of this field is extracted and verified to be consistent with the actual length of the subsequent data segment. It is confirmed to be the data segment length anchor. The protocol type, length anchor position, value range and data segment association are used as the core information of the data segment length anchor and stored in the feature anchor library. Security Feature Anchor: A security feature anchor is a field in frame data used to identify security attributes. Its characteristics include a fixed position, an encryption algorithm identifier, and an authorization verification field. Based on the protocol type, the fixed position of the security feature anchor in the frame is determined, and the encryption algorithm identifier of the field is extracted. The value of this field is compared with the authorization identifiers pre-stored in the protocol feature anchor library to confirm that it is a security feature anchor. The protocol type, security anchor position, encryption algorithm identifier, and authorization verification field are stored as the core information of the security feature anchor in the feature anchor library.

[0028] In the multi-protocol card identification and feature anchoring module, the feature vectors in the temporary feature cache are compared with the feature vectors in the feature anchor library. Specifically, the feature vector to be matched is read from the temporary feature cache. The feature vector contains feature values ​​of three dimensions: protocol type, structure, and security. At the same time, all pre-stored protocol feature vectors are read from the feature anchor library to ensure that the number and order of the two dimensions are aligned. For each vector to be matched and a vector in the library, calculate the similarity using the following steps: Calculate the sum of the products of the corresponding dimensions of two vectors; Calculate the sum of squares of the values ​​of each dimension of the two vectors and take the square root to obtain the length of the vectors; Divide the sum of the products by the product of the lengths of the two vectors to obtain the cosine similarity value; The calculated similarity value is compared with a preset threshold: If the similarity is greater than or equal to the threshold: determine that the frame data matches the corresponding protocol type, and output the protocol type result; If the similarity is less than the threshold, it is determined to be an unknown protocol frame, and the unknown protocol identification mode is triggered.

[0029] In the heterogeneous data layered virtualization module, the core data fields of each protocol are extracted, and the disassembled protocol fields are uniformly converted into a standardized PDDU format. Specifically, the corresponding protocol conversion driver is loaded, and the core areas of the instructions, card unique identifiers, and business-related data segments in the original frame are accurately located according to the predefined frame field structure in the driver. The core area data is extracted, and the non-core content of protocol-specific redundant identifiers and empty fields is removed. The extracted core fields are mapped and converted according to a unified rule. The protocol instruction code is converted into a general operation code, the card identifier is converted into a unified address identifier, and the business data is used as valid data. Then, unified verification information and the original protocol source identifier are added and integrated into a standardized PDDU format.

[0030] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0031] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0032] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0033] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0034] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0035] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0036] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A smart card compatible system based on multi-standard near-field communication, characterized in that, include: Multi-protocol card identification and feature anchoring module: Receives the original communication frames sent by the smart card, performs noise reduction processing on the frame signal, and extracts and matches feature anchor points; Heterogeneous data layered virtualization module: maps the identified raw data frames to the physical layer representation layer, uniformly converts protocol layer data, and realizes dynamic semantic adaptation and adjustment; Dual-modal storage carrier dynamic adaptation module: The smart card has a built-in protocol detection sensor that identifies the terminal protocol and automatically switches the access protocol of the storage area according to the terminal protocol type; Carrier-side edge computing dynamic data processing module: The smart card has a built-in edge computing chip, which performs noise reduction, distortion correction and feature extraction on the data to generate pre-processed effective data. According to the protocol type, it automatically adjusts the data processing logic to realize a collaborative mode of local processing on the carrier side and interaction with the terminal.

2. The smart card compatible system based on multi-standard near-field communication according to claim 1, characterized in that, In the multi-protocol card identification and feature anchoring module, the received original frame signal is denoised and optimized. An adaptive filtering algorithm is used to remove electromagnetic interference, environmental noise and signal distortion caused by card aging. The denoised frame data is converted into a unified digital signal format, and the frame fields are classified and marked according to the protocol type to generate standardized preprocessed frame data. A multi-protocol feature anchor library is established based on the received data. The multi-protocol feature anchor library pre-stores the core feature anchors of each mainstream protocol. The core feature anchors include: protocol type anchors, structural feature anchors, and security feature anchors. Feature anchors are extracted from standardized preprocessed frame data. The frame synchronization code anchor is located, and the check bit anchor, data segment length anchor, and security feature anchor are extracted in sequence. The extracted feature anchors are converted into feature vectors. Each feature vector contains three dimensions: protocol type feature value, structural feature value, and security feature value. The feature vectors in the temporary feature buffer are compared with the feature vectors in the feature anchor library. The cosine similarity algorithm is used to calculate the matching degree. A preset matching degree threshold is set. When the calculation result exceeds the preset matching degree threshold, the frame data is determined to match the corresponding protocol type. If the matching degree does not exceed the preset matching degree threshold, it is determined to be an unknown protocol frame and enters the unknown protocol identification mode. When a match is successful, the protocol type is determined directly based on the feature vector matching result, and the security verification rules of the corresponding protocol are invoked to evaluate the security level of the card. When a match fails, the unknown protocol identification mode is activated. The carrier edge computing dynamic data processing module analyzes the modulation method, encoding rules and frame structure of the unknown frame, generates new feature anchors and updates them to the feature anchor library.

3. A smart card compatible system based on multi-standard near-field communication according to claim 1, characterized in that, In the heterogeneous data layered virtualization module, the preprocessed frame whose protocol type has been determined in the multi-protocol card identification and feature anchoring module is received, and the physical attributes of the frame are parsed and recorded synchronously, including: transmission parameters, frame structure parameters and protocol identifier. The original preprocessed frame is fully mapped to the physical layer representation layer, using the storage structure of the original frame and attribute tags: Raw frame binary data: The preprocessed frame bitstream is completely preserved without any format conversion; Physical attribute tags: Store the parsed transmission parameters, frame structure parameters, and protocol identifiers in key-value pairs; Mapping rules: Ensure that the physical characteristics of the original data are intact, providing a traceable original basis for subsequent protocol layer conversion; Based on the protocol identifier mapped by the physical layer, the corresponding protocol conversion driver is automatically loaded. The driver predefines the frame field format and conversion rules for the determined protocol type, decomposes the original frame of the physical layer mapping, extracts the core data fields of each protocol, and converts the decomposed protocol fields into a standardized PDDU format. The valid data of the PDDU is mapped into scenario-based business semantic units, including: financial payment scenario, access control and attendance scenario, and industrial traceability scenario. Based on scenario priority and real-time requirements, the semantic identification rules are dynamically adjusted, including: high-priority scenarios, low-latency scenarios, and; Conflict detection is performed on semantic units from multiple protocol sources. When semantic fields from different protocols overlap, the conflict is resolved using rules based on scenario priority and timestamp.

4. A smart card compatible system based on multi-standard near-field communication according to claim 1, characterized in that, In the dual-modal storage carrier dynamic adaptation module, after the smart card is powered on, the built-in protocol detection sensor is automatically woken up, completes the initialization configuration, and enters a low-power standby mode to monitor the radio frequency interaction status between the smart card and the terminal in real time. When the terminal is detected to be close, the wake-up mechanism is automatically triggered to start the protocol identification process. The sensor receives the radio frequency signal transmitted by the terminal and extracts the core features of the terminal radio frequency signal, including: protocol feature extraction, communication parameter feature extraction and protocol identifier feature extraction. Protocol feature extraction: Perform frame structure analysis on radio frequency signals, locate frame synchronization codes and instruction set features in the signals, and identify the modulation methods and coding rules of the signals to extract protocol-specific signal modulation and coding features; Communication parameter feature extraction: Through the signal detection module, the communication rate, radio frequency field strength and signal transmission duration of the radio frequency signal are collected and extracted in real time. At the same time, the stable transmission parameters of the signal are recorded to form the basic parameter feature set of terminal communication. Protocol identifier feature extraction: The extracted protocol features are compared one by one with the mainstream protocol features in the sensor's built-in protocol type library, and the unique identifier features of the protocol corresponding to the protocol type library are matched and extracted. The sensor compares the extracted radio frequency signal features with a protocol type library, calculates the matching degree using a feature vector matching algorithm, and determines the terminal's protocol type. If a match is successful, output the terminal protocol type directly; When matching fails, the unknown protocol identification mode is activated. The edge computing module analyzes the frame structure and encoding rules of the terminal radio frequency signal, generates new protocol features and updates them to the protocol type library, and outputs the unknown protocol identifier. After receiving the terminal protocol type report, confirm the status of the smart card's dual-modal storage area: the protocol adaptation area and the application encryption storage area; Based on the terminal protocol type, the access protocol of the storage area is automatically matched and switched. When the terminal protocol type is an unknown protocol, the compatibility mode is started and the general protocol instruction set is used to interact with the terminal. After switching the access protocol, the control module confirms the terminal's permissions through a security verification mechanism and uses the SM2 algorithm for two-way authentication to verify whether the terminal has the permission to access the corresponding storage area. If the authentication is successful, the terminal is allowed to read the data in the corresponding storage area. If the authentication fails, access is denied and an exception log is recorded. The SM2 algorithm is used for two-way authentication. Specifically, the smart card and the terminal each load their legitimate SM2 public keys and generate a one-time random number to ensure that the authentication is not replayable. The terminal sends the device identifier, storage area access request and random number to the smart card after signing it with its own private key. The smart card verifies the signature with the pre-stored terminal public key to confirm the terminal's legitimacy. The smart card then sends its own identifier, storage area permission information and terminal random number to the terminal after signing it with its own private key. The terminal verifies the signature with the pre-stored smart card public key to confirm the smart card's legitimacy. When both verifications pass, the two-way authentication is successful, and the smart card grants the terminal access to the storage area. If either step fails, access is denied, and an exception log is recorded. The terminal interacts with the smart card with data according to the switched access protocol, including: read scenarios and write scenarios; If the interaction between the terminal and the smart card ends, the sensor and control module automatically return to low-power standby mode, waiting for the next terminal wake-up; The sensor compares the extracted radio frequency signal features with a protocol type library. Specifically, the extracted three types of radio frequency signal features are normalized according to the feature dimensions, order, and expression specifications pre-stored in the protocol type library to generate a feature set to be matched that is consistent with the features in the library. This eliminates format and dimension differences and ensures comparability. Based on the normalized feature set to be matched, a full-domain feature search is performed in the protocol type library. A coarse match is first performed, and then a candidate protocol set that is consistent with the core protocol identifier features in the feature set to be matched is selected. Protocol types that do not match obviously are eliminated to narrow the comparison range. For the candidate protocols obtained from the coarse match, their corresponding complete feature sets in the library are extracted and compared with the feature set to be matched dimension by dimension. The matching results of each dimension are marked.

5. A smart card compatible system based on multi-standard near-field communication according to claim 1, characterized in that, In the aforementioned carrier-side edge computing dynamic data processing module, after the smart card is powered on, the built-in edge computing chip automatically wakes up, completes initialization configuration, and enters a low-power standby mode. It monitors the radio frequency interaction status between the smart card and the terminal in real time. When a data interaction request is detected from the terminal, the wake-up mechanism is automatically triggered, initiating the data processing flow. The edge computing chip receives the raw data sent by the terminal and parses the basic data format and transmission parameters. Data source: Multi-protocol data sent by the terminal via the NFC radio frequency module; Data format: Parse the frame structure, encoding method, and transmission rate of the data; An adaptive filtering algorithm is used to optimize noise reduction in the received data, eliminating electromagnetic interference, environmental noise, and signal distortion caused by card aging. To correct distortions in the data frame structure, a distortion correction algorithm is used. Frame length correction: Adjust the length of the data frame to the standard range according to the protocol feature anchor point; Data bit correction: Corrects the offset of data bits to ensure the accuracy of data fields; After noise reduction and distortion correction, preprocessed valid data is generated; The chip calls the corresponding feature extraction algorithm based on the data protocol type to extract the core features of the data, including protocol feature extraction and security feature extraction. Protocol feature extraction: Extracting protocol features such as frame synchronization code, instruction code, and data segment length from the data; Security Feature Extraction: Extracting encryption algorithm features and permission identification features from the data; The extracted features are converted into feature vectors, each of which contains two dimensions: protocol feature values ​​and security feature values. The chip determines the protocol type of the data based on its feature vector. The protocol type is output by the multi-protocol card recognition module, which automatically matches and adjusts the data processing logic according to the protocol type. When the protocol type is a financial payment protocol, the processing logic is adjusted to encryption and security verification, the data is encrypted using the SM4 algorithm, and the integrity of the data is verified. When the protocol type is a public transportation protocol, the processing logic is adjusted to fast verification and data extraction, prioritizing the extraction of core information such as the number of rides and the balance from the data. When the protocol type is an industrial traceability protocol, the processing logic is adjusted to parameter parsing and feature matching, extracting the equipment SN and inspection time parameters from the data and comparing them with the protocol feature library; The chip processes the preprocessed valid data according to the adjusted processing logic and generates the processing result: Financial payment scenarios: Generating core data such as transaction amount, transaction time, and merchant ID; Access control and attendance scenarios: Generating core data such as user ID, access permissions, and attendance time; Industrial traceability scenarios: generating core data on equipment parameters, status, and location; The chip sends the processing results to the terminal, realizing a collaborative mode of local processing on the carrier and interaction with the terminal: Data transmission: The processing results are sent to the terminal using a communication protocol supported by the terminal. Feedback confirmation: Receive feedback information from the terminal to confirm whether the data transmission was successful. If the transmission fails, resend the data. If the interaction between the terminal and the chip ends, the chip automatically returns to low-power standby mode, waiting for the next time the terminal wakes it up.

6. A smart card compatible system based on multi-standard near-field communication according to claim 2, characterized in that, In the multi-protocol card identification and feature anchoring module, standardized preprocessed frame data is generated. Specifically, the denoised analog frame signal is quantized and converted into a binary digital signal that the system can recognize. The bit width and transmission timing specifications of the data are standardized, the format differences of the original frames of different protocols are eliminated, and the core fields of the binary frame data are accurately divided according to the multi-protocol general frame structure. Three types of tags are added to each field: protocol type, field function, and field position. The binary fields with classification tags are reorganized according to the general frame structure of frame header identifier, synchronization code, data segment, check bit, and frame tail. Invalid blank fields are removed, and finally standardized preprocessed frame data with uniform format, traceable fields, and protocol classification tags are generated.

7. A smart card compatible system based on multi-standard near-field communication according to claim 2, characterized in that, In the multi-protocol card identification and feature anchoring module, a multi-protocol feature anchor point library is established based on the received data. Specifically, a large amount of raw communication frame data from different protocols is collected, classified according to protocol type, and each protocol retains the complete raw frame and corresponding physical attributes. Common features are extracted from the frame data of each protocol to form three types of core anchor points, including: protocol type anchor points, structural feature anchor points, and security feature anchor points. Protocol type anchor: Extract the unique instruction code or frame synchronization code of the protocol as a unique identifier for the protocol; Structural feature anchor points: Extract fixed structural features of the protocol frame; Security feature anchors: Extract security-related features of the protocol; The three types of feature anchors extracted are standardized and organized, and then stored in the feature anchor library after being formatted in a unified format. Each anchor record includes the protocol name, anchor type, anchor feature value and attribute description.

8. A smart card compatible system based on multi-standard near-field communication according to claim 2, characterized in that, In the multi-protocol card identification and feature anchoring module, the check bit anchor, data segment length anchor, and security feature anchor are extracted sequentially, specifically as follows: Check bit anchor: The check bit anchor is a fixed-format field in frame data used to verify the integrity of the frame. Its characteristics are fixed position, fixed length and specific check algorithm identifier. According to the protocol type of the preprocessed frame, the frame structure specification of the protocol is retrieved to determine the fixed position of the check bit in the frame. The binary data of the field is extracted and compared with the check algorithm identifier pre-stored in the protocol feature anchor library to confirm that it is the check bit anchor of the protocol. Data segment length anchor: The data segment length anchor is a fixed field in the frame data used to identify the length of subsequent data segments. Its characteristics include fixed position, numerical range and association with data segment. According to the protocol frame structure specification, the fixed position of the data segment length anchor point in the frame is determined and its numerical range is defined. The value of this field is extracted and verified to be consistent with the actual length of the subsequent data segment. It is confirmed as the data segment length anchor point. The protocol type, length anchor point position, numerical range and data segment association are used as the core information of the data segment length anchor point and stored in the feature anchor point library. Security feature anchors: Security feature anchors are fields in frame data used to identify security attributes. Its features include a fixed position, an encryption algorithm identifier, and an authorization verification field. Based on the protocol type, the fixed position of the security feature anchor in the frame is determined, and the encryption algorithm identifier of the field is extracted. The value of the field is compared with the authorization identifiers pre-stored in the protocol feature anchor library to confirm that it is a security feature anchor. The protocol type, security anchor position, encryption algorithm identifier, and authorization verification field are used as the core information of the security feature anchor and stored in the feature anchor library.

9. A smart card compatible system based on multi-standard near-field communication according to claim 2, characterized in that, In the multi-protocol card identification and feature anchoring module, the feature vectors in the temporary feature cache are compared with the feature vectors in the feature anchor library. Specifically, the feature vector to be matched is read from the temporary feature cache. The feature vector contains feature values ​​of three dimensions: protocol type, structure, and security. At the same time, all pre-stored protocol feature vectors are read from the feature anchor library to ensure that the number and order of the two dimensions are aligned. For each vector to be matched and a vector in the library, calculate the similarity using the following steps: Calculate the sum of the products of the corresponding dimensions of two vectors; Calculate the sum of squares of the values ​​of each dimension of the two vectors and take the square root to obtain the length of the vectors; Divide the sum of the products by the product of the lengths of the two vectors to obtain the cosine similarity value; The calculated similarity value is compared with a preset threshold: If the similarity is greater than or equal to the threshold: determine that the frame data matches the corresponding protocol type, and output the protocol type result; If the similarity is less than the threshold, it is determined to be an unknown protocol frame, and the unknown protocol identification mode is triggered.

10. A smart card compatible system based on multi-standard near-field communication according to claim 3, characterized in that, In the heterogeneous data layered virtualization module, the core data fields of each protocol are extracted, and the disassembled protocol fields are uniformly converted into a standardized PDDU format. Specifically, the corresponding protocol conversion driver is loaded, and the core areas of the instructions, card unique identifiers, and business-related data segments in the original frame are accurately located according to the predefined frame field structure in the driver. The core area data is extracted, and the non-core content of protocol-specific redundant identifiers and empty fields is removed. The extracted core fields are mapped and converted according to a unified rule. The protocol instruction code is converted into a general operation code, the card identifier is converted into a unified address identifier, and the business data is used as valid data. Then, unified verification information and the original protocol source identifier are added and integrated into a standardized PDDU format.

Images