Conference sign-in method and device based on near field communication

Abstract

This application relates to a meeting check-in method and device based on near-field communication (NFC). The check-in terminal no longer presets fixed card types and communication protocols. Instead, after establishing an RF connection with the participant's NFC card, it sends a probe command to obtain the card's response information. From this response information, it dynamically parses the communication protocol information and the length parameter of the unique identifier, thereby inferring the card type. Then, it calls the communication protocol stack and parsing rules corresponding to that card type to read the unique identifier information from the card. Finally, it matches this unique identifier information with the stored participant information to complete the check-in. The key to this process is that the terminal actively detects and adaptively identifies the card type, without requiring the card to conform to a fixed specification, thus achieving universal compatibility with various different cards.

Description

Technical Field

[0001] This application relates to the field of conference check-in technology, and in particular to a conference check-in method and device based on near-field communication. Background Technology

[0002] Meeting check-in is an indispensable and crucial part of meeting management, directly affecting attendee identity verification, attendance data statistics, and the effective maintenance of order at the meeting. With the development of information technology, meeting check-in has gradually evolved from traditional manual operation to intelligent methods. Currently, commonly used check-in methods include paper signature check-in, facial recognition check-in, and Near Field Communication (NFC) card check-in. NFC card check-in relies on the sensory interaction between the card and the reader; attendees simply hold their card close to the check-in terminal to quickly complete the check-in process. It has significant advantages in simplifying the check-in process and increasing speed, and has been gradually adopted in some meeting scenarios in recent years.

[0003] However, existing near-field communication card check-in solutions have revealed significant technical shortcomings in practical applications: the compatibility of existing check-in devices and supporting identification systems is very limited, only able to recognize and read a single type of communication card with preset specifications and formats, and unable to adapt to various access cards with different chip specifications, communication protocols, and physical shapes circulating in the market. This means that attendees cannot flexibly use their own compliant cards, such as transportation cards, access cards, and work cards, to complete check-in. Conference organizers also need to specially customize matching check-in cards during the preparation phase, which not only significantly increases the material costs and organizational workload of conference preparation but also greatly limits the practical applicability of the card check-in mode in different conference scenarios, severely lacking in practicality and flexible scalability. Summary of the Invention

[0004] Therefore, the purpose of this application is to provide a meeting check-in method and device based on near-field communication, which can automatically adapt to different types of near-field communication cards for check-in.

[0005] The conference check-in method based on near-field communication described in this application embodiment is applied to a check-in terminal, and the method includes the following steps:

[0006] The system sends detection commands to the near-field communication cards of the participants via the near-field communication radio frequency field and receives response information returned by the near-field communication cards. Based on the response information, the length parameters of the communication protocol information and the unique identifier information are determined; according to the communication protocol information and the length parameters, the card type of the near-field communication card is determined; Based on the communication protocol stack and parsing rules corresponding to the card type, read the unique identification information of the near-field communication card; When the unique identifier matches any stored unique identifier, the identity information corresponding to the unique identifier is obtained; and a check-in record is generated based on the identity information.

[0007] This application also provides a computer device, including a processor, a memory, and a computer-readable program stored in the memory, wherein the computer-readable program, when executed by the processor, implements the steps of the method described in any one of the embodiments of this application.

[0008] This application embodiment sends a detection command to a near-field communication card via a check-in terminal and receives the response information. The length parameters of the communication protocol information and unique identifier information are then dynamically determined from the response information. This allows for the inference of the card type, loading the corresponding communication protocol stack and parsing rules to read the unique identifier information, ultimately completing identity matching and check-in record generation. The check-in terminal is no longer limited to recognizing only one preset card specification. Instead, after interacting with any near-field communication card, it can automatically perceive the card's communication protocol and data structure characteristics through the response information returned by the card itself, thus adaptively calling the appropriate parsing method to complete the reading. Therefore, cards with different chip specifications, communication protocols, and physical shapes, such as transportation cards, access cards, and work cards held by attendees, can all be correctly recognized by the terminal. Event organizers no longer need to specially customize matching check-in cards, directly eliminating the material costs and preparation workload associated with custom-made cards. Meanwhile, since the entire identification process relies entirely on the radio frequency interaction between the terminal and the card to complete the check-in in a very short time, participants only need to hold the card close to the terminal. The operation steps are not increased or the check-in speed is reduced due to the need to adapt to various cards. Therefore, while greatly improving the universality of the check-in method and the flexibility of the applicable scenarios, it still maintains the fast and convenient advantages of near-field communication card check-in itself, and truly achieves an effective balance between low cost, high efficiency and strong universality in the conference check-in process.

[0009] To better understand and implement this application, the following detailed description is provided in conjunction with the accompanying drawings. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a meeting check-in method based on near-field communication, according to an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a computer device according to an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. Wherein, when the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0012] It should be understood that the embodiments described below do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0013] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application are also intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, in the description of this application, unless otherwise stated, “a plurality” means two or more. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items, for example, A and / or B, which can represent: A alone, A and B together, and B alone; the character “ / ” generally indicates that the preceding and following objects are in an “or” relationship.

[0014] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, this information should not be limited to these terms, and these terms are only used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Depending on the context, the word "if" as used in this application can be interpreted as "when," "when," or "in response to determination."

[0015] Please refer to Figure 1 The meeting check-in method based on near-field communication described in this application embodiment is applied to a check-in terminal, and the method includes the following steps: S101: Send a detection command to the near-field communication card of the participant via the near-field communication radio frequency field, and receive the response information returned by the near-field communication card; S102: Based on the response information, determine the length parameters of the communication protocol information and the unique identifier information; determine the card type of the near-field communication card according to the communication protocol information and the length parameters; S103: Read the unique identification information of the near-field communication card according to the communication protocol stack and parsing rules corresponding to the card type; S104: When the unique identifier information matches any of the stored unique identifier information, obtain the identity information corresponding to the unique identifier information; generate a check-in record based on the identity information.

[0016] This application embodiment sends a detection command to a near-field communication card via a check-in terminal and receives the response information. The length parameters of the communication protocol information and unique identifier information are then dynamically determined from the response information. This allows for the inference of the card type, loading the corresponding communication protocol stack and parsing rules to read the unique identifier information, ultimately completing identity matching and check-in record generation. The check-in terminal is no longer limited to recognizing only one preset card specification. Instead, after interacting with any near-field communication card, it can automatically perceive the card's communication protocol and data structure characteristics through the response information returned by the card itself, thus adaptively calling the appropriate parsing method to complete the reading. Therefore, cards with different chip specifications, communication protocols, and physical shapes, such as transportation cards, access cards, and work cards held by attendees, can all be correctly recognized by the terminal. Event organizers no longer need to specially customize matching check-in cards, directly eliminating the material costs and preparation workload associated with custom-made cards. Meanwhile, since the entire identification process relies entirely on the radio frequency interaction between the terminal and the card to complete the check-in in a very short time, participants only need to hold the card close to the terminal. The operation steps are not increased or the check-in speed is reduced due to the need to adapt to various cards. Therefore, while greatly improving the universality of the check-in method and the flexibility of the applicable scenarios, it still maintains the fast and convenient advantages of near-field communication card check-in itself, and truly achieves an effective balance between low cost, high efficiency and strong universality in the conference check-in process.

[0017] The meeting check-in method based on near-field communication described in this application uses a computer device as the execution entity. The following provides a detailed description of each step.

[0018] For step S101, a detection command is sent to the near-field communication card of the participant through the near-field communication radio frequency field, and the response information returned by the near-field communication card is received.

[0019] The near-field communication (NFC) radio frequency field refers to the electromagnetic induction field generated by the NFC antenna inside the sign-in terminal when it is powered on. This NFC field has a relatively short effective range (typically within a few centimeters). When a participant holding a NFC card enters the range of this NFC field, the antenna inside the card is induced to power and activated, thereby establishing a wireless communication link between the card and the terminal. In this embodiment, the NFC field serves as both the power source for the card and the communication medium for the terminal to send detection commands to the card and receive response information from the card.

[0020] A detection command is a wake-up and query command sent by the check-in terminal to a card entering its sensing range via near-field communication (NFC) radio frequency field. Its function is to activate the card and request it to provide its basic characteristic information. This detection command can be implemented using polling or anti-collision commands defined in near-field communication standards such as ISO / IEC 14443 or ISO / IEC 15693, with the specific form depending on the actual communication protocol used.

[0021] Response information refers to the data response that a near-field communication (NFC) card sends back to the terminal after receiving a probe command, according to its own communication protocol. The response information typically includes at least information about the communication protocol type used by the card and the data length parameter of the card's unique identifier. This information is crucial for the terminal to subsequently determine the card type and perform corresponding parsing operations.

[0022] This step is the starting point of the entire check-in process, and its core lies in the terminal actively initiating communication with the card to obtain the card's basic characteristic information. Specifically, after detecting a participant approaching with a card (detectable through changes in radio frequency field strength or external trigger signals), the check-in terminal controls its near-field communication antenna to transmit a detection command. This command is wirelessly transmitted to the card via the radio frequency field. Upon receiving the command, the card is activated and generates a response according to its own communication protocol, then sends this response back to the terminal via the radio frequency field. In one feasible implementation, the terminal can send a Type A or Type B REQA / WUPA polling command according to the ISO / IEC 14443 standard, and the card returns the corresponding ATQA / SAK response data based on its own protocol type. In another feasible implementation, the terminal can also send an inventory command under the ISO / IEC 15693 standard, and the card returns response data containing DSFID and UID. Regardless of the specific command form used, the terminal can successfully receive the response information returned by the card in this step. This response information carries the communication protocol information and length parameters necessary for subsequent card classification.

[0023] In one embodiment, step S101, which involves sending a detection command to the near-field communication card of a participant via a near-field communication radio frequency field and receiving response information returned by the near-field communication card, includes: Step S1011: At least two different communication protocol types of detection commands are sequentially sent through the near-field communication radio frequency field.

[0024] At least two different communication protocol types of probe commands refer to multiple probe commands sent sequentially by the check-in terminal during the same check-in process via the near-field communication radio frequency field, each following a different near-field communication protocol standard. For example, the terminal can first send a REQA probe command following the ISO / IEC 14443 Type A protocol, and then send an inventory probe command following the ISO / IEC 15693 protocol. Although both commands aim to wake up the card and obtain its basic characteristic information, they follow different communication protocol standards, enabling them to activate and obtain response information from cards of different protocol types.

[0025] This step is the initial action of the entire check-in process. Instead of sending only one fixed protocol probe command, the terminal actively and sequentially sends probe commands of at least two different communication protocol types into the radio frequency field. This ensures that regardless of the type of near-field communication card held by the attendee, the terminal receives at least one valid response. Specifically, after detecting an attendee approaching with a card, the terminal controls the radio frequency field to first send a probe command according to the first communication protocol type (e.g., ISO / IEC 14443 Type A). If no response is received after a preset short period, a second probe command is immediately sent according to the second communication protocol type (e.g., ISO / IEC 15693). If no response is received again, a third probe command can be sent, and so on.

[0026] Step S1012: Receive the response information returned by the near-field communication card in response to any detection command.

[0027] After sending the first probe command, the terminal begins to listen for a response signal from the card in the radio frequency field. If a response is received within the preset timeout period, the terminal proceeds directly to step S102 for further processing and does not send any more probe commands. If no response is received within the timeout period, the terminal automatically sends the second probe command and continues to listen, and so on, until a response is received for any probe command.

[0028] In this embodiment, the check-in terminal sequentially sends at least two different communication protocol types of probe commands and receives the response information returned by the card in response to any of the probe commands. This allows the terminal to be no longer limited to a single fixed probe protocol when facing various near-field communication cards held by attendees. Instead, it actively sends probe commands of multiple protocol types to ensure that regardless of whether the card follows Type A, Type B, 15693, or any other near-field communication protocol, the terminal can successfully obtain the card's response information through the matching probe command.

[0029] For step S102, based on the response information, the length parameters of the communication protocol information and the unique identifier information are determined; according to the communication protocol information and the length parameters, the card type of the near-field communication card is determined.

[0030] Communication protocol information refers to the data content used to characterize the type of communication protocol followed by the near-field communication card. Near-field communication cards from different manufacturers and in different application scenarios may follow different communication protocol standards such as ISO / IEC 14443 Type A, ISO / IEC 14443 Type B, ISO / IEC 15693, Felica, and MIFARE. This communication protocol information is used to identify which specific protocol standard the card currently follows.

[0031] The length parameter refers to the number of bytes or bits occupied by the unique identification information in the card as indicated in the response information. Different types of near-field communication cards have different data lengths for their unique identification information. For example, some cards have a unique identification of 4 bytes, some have 7 bytes, and some have 10 bytes. This length parameter is the key information required for the terminal to accurately read the complete unique identification information.

[0032] Card type category refers to the classification of card types determined based on a comprehensive judgment of communication protocol information and length parameters. Each card type category corresponds to a specific set of communication protocol stacks and a dedicated set of data parsing rules. After determining the card type category, the terminal knows which protocol stack and parsing rules to call for subsequent data interaction with the card.

[0033] This step is the core judgment process of the entire solution. After receiving the response information, the terminal does not interpret it according to any preset fixed protocol. Instead, it first extracts two key pieces of information from the response information: communication protocol information and length parameters. Then, it combines these two to deduce the card type. Specifically, the terminal first performs preliminary decoding of the received response information using a common data parsing method to identify the communication protocol information (e.g., determining whether the card follows Type A, Type B, or 15693 protocol by identifying specific byte segments in the response information) and the length parameter of the unique identifier (e.g., determining whether the UID length is 4 bytes or 7 bytes by identifying the byte count field in the response information). Subsequently, the terminal maintains a mapping table or judgment logic internally. This logic takes the communication protocol information and length parameters as input conditions and outputs the corresponding card type. Through this judgment process, the terminal automatically determines the card type based solely on the response information returned by the card itself, without knowing the specific specifications of the card in advance.

[0034] In one embodiment, the response information includes communication protocol information and a length parameter of unique identification information; or, the response information includes a length parameter of unique identification information but does not include communication protocol information. When the response information includes the length parameters of communication protocol information and unique identification information, step S102, based on the response information, determines the length parameters of the communication protocol information and unique identification information, including: Step S10201: Extract the length parameters of the communication protocol information and the unique identifier information from the response information.

[0035] This step applies to situations where the response information simultaneously contains both communication protocol information and a length parameter for unique identification information. Its core lies in the terminal directly parsing and extracting these two data items from the received response information. Specifically, after receiving the response information, the terminal parses it field by field according to the data format followed by the response information. In one feasible implementation, the terminal can locate the field containing the communication protocol information based on the starting byte of the response information. For example, it can read the ATQA or DSFID value from the first or second byte of the response information as the communication protocol information, and then read the number of bytes of the unique identification information from a specific length indication field in the response information as the length parameter.

[0036] When the response information includes a length parameter of unique identifier information but does not include communication protocol information, step S102, which involves determining the length parameters of the communication protocol information and the unique identifier information based on the response information, includes: Step S10202: Determine the communication protocol information according to the communication protocol type corresponding to the probe command responded to by the response information, and extract the length parameter of the unique identifier information from the response information.

[0037] This step applies to situations where the response information only contains the length parameter of the unique identifier and not the communication protocol information. The core of this approach is that the terminal cannot directly obtain the communication protocol information from the response information itself, but rather infers it by reverse engineering based on the fact that "the card responded to which probe command." Specifically, in step S1011, the terminal sequentially sends multiple probe commands of different protocol types, and internally records the protocol type of each sent probe command. When the terminal receives the response information returned by the card in step S1012, it first determines after which probe command the response information was received. Since the card only responds to the probe command that matches its own protocol, the protocol type of the probe command responded to by the response information is the communication protocol type followed by the card, and the terminal determines the communication protocol information accordingly. Simultaneously, the terminal still parses and extracts the length parameter of the unique identifier from the response information according to a preset data format. In another feasible implementation, although the response information does not contain an explicit protocol type field, it contains some implicit command response identifier. The terminal parses this implicit identifier to determine which probe command was responded to, and thus determines the communication protocol information.

[0038] In this embodiment, because cards of different protocol standards have inherent differences in the data format of their response information, some protocol cards actively carry protocol type information in their responses, while others only return length parameters. This embodiment distinguishes between these two situations and uses two methods, direct extraction and reverse derivation, respectively, to ensure that regardless of the protocol standard followed by the card or the fields contained in its response information, the terminal can completely obtain the two required data items, thus preventing card type determination failure due to inconsistent response information formats.

[0039] In one embodiment, step S102, which determines the card type of the near-field communication card based on the communication protocol information and the length parameter, includes: Step S1021: Obtain the protocol type identifier from the communication protocol information.

[0040] The protocol type identifier refers to the unique identifier code in the communication protocol information used to identify the specific communication protocol standard followed by the near-field communication card. Different near-field communication protocol standards include unique identifier fields in their response information. For example, ISO / IEC 14443 Type A cards will carry a specific ATQA field in their response information, ISO / IEC 14443 Type B cards will carry an ATQB field, and ISO / IEC 15693 cards will carry a DSFID field, etc. This protocol type identifier is the specific data content extracted from the response information used to distinguish the above different protocol types.

[0041] Step S1022: Based on the protocol type identifier and the length parameter, determine the card type determination result through a preset card type determination rule.

[0042] The preset card type determination rule refers to a set of determination logic pre-stored within the terminal. This logic takes the protocol type identifier and length parameter as two input conditions and outputs the corresponding card type category determination result through preset matching rules. This determination rule can exist in the terminal's processing module in the form of lookup tables, decision trees, conditional statements, etc. Its essence is to map and match the combination of "protocol type identifier + length parameter" with the known feature parameters of various near-field communication cards, thereby determining which category the current card belongs to.

[0043] The card type determination result refers to the determination conclusion output by the preset card type determination rule after performing calculations with the protocol type identifier and length parameter as input. This determination result directly corresponds to a specific near-field communication card type and is the direct basis for the terminal to subsequently call the corresponding communication protocol stack and parsing rules.

[0044] Step S1023: Based on the card type determination result, the card type category of the near-field communication card is obtained.

[0045] This embodiment first accurately extracts the protocol type identifier from the communication protocol information during the process of determining the card type. Then, the protocol type identifier and the length parameter are used as input conditions and substituted into the preset card type determination rules for matching calculation to obtain the card type determination result. Finally, the card type is confirmed based on the determination result. This allows the check-in terminal to automatically and accurately infer the card type when facing any near-field communication card by using the characteristic parameters of "protocol type identifier + length parameter" fed back from the card's own response information and the internal preset determination rules.

[0046] In one embodiment, step S1022, which involves determining the card type determination result based on the protocol type identifier and the length parameter using a preset card type determination rule, includes: Step S10221: Using the protocol type identifier and the length parameter as query conditions, and based on the query conditions, searching for matching card type groups in a preset card type mapping table; wherein, the preset card type mapping table stores the correspondence between the protocol type identifier, the length parameter and the card type group.

[0047] The preset card type mapping table refers to a structured data table pre-stored within the terminal. This table records the corresponding mapping relationships between various combinations of "protocol type identifier + length parameter" and "card type group". Each row of this mapping table is equivalent to a mapping record, containing three fields: protocol type identifier, length parameter, and card type group. It serves as the direct basis for the terminal to perform queries and matching when determining the card type. This table can be preset at the terminal's factory or added to and maintained through subsequent system updates.

[0048] The query criteria refer to the input parameters used by the terminal when performing a search operation in the preset card type mapping table. In this embodiment, it is a combination of the protocol type identifier and the length parameter. The terminal uses these two items as a set of joint query criteria to search for a record that exactly matches it in the mapping table.

[0049] Card type grouping refers to intermediate group identifiers used in a pre-defined card type mapping table to categorize near-field communication (NFC) cards. Its granularity lies between broad protocol types and specific communication protocol stacks. One card type group can correspond to a group of card categories with the same communication protocol stack and parsing rules. After finding a matching card type group, the terminal can perform subsequent operations based on the communication protocol stack and parsing rules associated with that group. Therefore, card type grouping serves as a bridge between the mapping table query result and the final invocation of the communication protocol stack.

[0050] Step S10222: Determine the card type determination result of the near-field communication card according to the matched card type group.

[0051] This embodiment enables the check-in terminal to quickly and accurately locate the card type group of any near-field communication (NFC) card by utilizing the protocol type identifier and length parameter fed back by the card in its response information and performing a precise query and matching operation in the mapping table, thus clarifying the card type determination result. In this embodiment, the terminal does not need to pre-assume or limit the specific specifications and protocol type of the card. Instead, it uses multiple combinations of "protocol type identifier + length parameter" already covered in the mapping table to cover various NFC cards with different chip specifications, communication protocols, and form factors on the market. Therefore, the terminal can automatically adapt to and identify any compliant NFC card held by the attendee. This not only ensures the accuracy and efficiency of card type determination but also, through the structured storage method of the mapping table, allows the terminal to expand its support capabilities by simply updating the mapping table when encountering new types of cards, without modifying the core identification logic. Thus, while achieving universal adaptation to multiple cards, it also possesses good maintainability and scalability.

[0052] In one embodiment, step S10221, which involves searching for a matching card type group in a preset card type mapping table based on the query conditions, includes: Step S102211: When the protocol type identifier is the first protocol type and the length parameter is the first number of bytes, match the first card type group.

[0053] The first protocol type refers to the first type of communication protocol type identifier defined in the preset card type mapping table. In this embodiment, it usually corresponds to the ISO / IEC 14443 Type A protocol. This protocol is widely used in various access control cards, transportation cards, identity cards and other near-field communication cards. It is one of the most widely circulated near-field communication protocol standards on the market.

[0054] In this embodiment, the first quantity is 4, and the first card type group includes access control cards. Access control cards refer to near-field communication cards used in access control management systems. They typically follow the ISO / IEC 14443 Type A protocol, and their unique identification information is 4 bytes long. They are one of the most common card types in places such as corporate parks and residential communities.

[0055] Step S102212: When the protocol type identifier is the first protocol type and the length parameter is the second number of bytes, match the second card type group.

[0056] The second protocol type refers to the second type of communication protocol type identifier defined in the preset card type mapping table. In this embodiment, it usually corresponds to the ISO / IEC 14443 Type B protocol. This protocol is also widely used in various near-field communication cards. It belongs to the ISO / IEC 14443 standard system as well as the first protocol type, but there are differences in the underlying communication mechanism.

[0057] In this embodiment, the second quantity is 7, and the second card type group includes integrated circuit cards and near-field communication (NFC) tag cards. An integrated circuit card refers to a card with an integrated circuit chip integrated inside. In the context of this embodiment, it specifically refers to a NFC card that conforms to the ISO / IEC 14443 Type A or Type B protocol and has a unique identification information length of 7 bytes. This type of card is widely used in public transportation, campus card systems, and other scenarios. A NFC tag card refers to a special type of NFC card, whose unique identification information length is also 7 bytes. It typically does not have complex data storage functions and is mainly used for simple identification and rapid sensor interaction.

[0058] Step S102213: When the protocol type identifier is the second protocol type and the length parameter is the second number of bytes, match the third card type group.

[0059] In this embodiment, the third card type group includes financial cards. Financial cards refer to near-field communication cards used in the financial payment field, with a unique identifier length of 7 bytes and a communication protocol of type second.

[0060] Step S102214: When the protocol type identifier is the second protocol type and the length parameter is the first number of bytes, match the fourth card type group.

[0061] In this embodiment, the fourth card type group includes identity recognition cards. Identity recognition cards refer to near-field communication cards specifically used for identity verification, such as NFC ID cards. In this embodiment, it specifically refers to cards that conform to the second protocol type (i.e., ISO / IEC 14443 Type B) and have a unique identifier length of 4 bytes, commonly used in personnel identity verification scenarios for government agencies and enterprises.

[0062] This embodiment sets four specific matching rules in a preset card type mapping table. This allows the check-in terminal to quickly and accurately categorize cards into their corresponding card type groups when faced with various near-field communication (NFC) cards held by attendees, using these four rules that cover different protocol and length combinations. These four rules cover five of the most common NFC card types on the market: access cards, integrated circuit cards, NFC tag cards, financial cards, and identity verification cards. Each rule's conditions perfectly match the actual protocol and data length characteristics of the corresponding card type. Therefore, the terminal does not need to know the card's specific specifications in advance; it can accurately match the corresponding card type group in the mapping table based solely on the protocol type identifier and length parameters provided by the card itself. For cases like integrated circuit cards and NFC tag cards, which are identical in protocol type identifier and length parameters but have different actual protocol stacks, the terminal can further distinguish them using a second detection command after matching the second card type group, ensuring that the final communication protocol stack used perfectly matches the actual card type. Therefore, regardless of whether attendees hold access cards, transportation cards, financial cards, or identity cards, the terminal can quickly classify them into the correct card type group and complete subsequent identification through the above four matching rules. The event organizer does not need to customize special check-in cards. Attendees can directly use any compliant near-field communication card they own to complete the check-in, achieving a balance between low cost and strong versatility while fully ensuring the accuracy of check-in.

[0063] In one embodiment, the same card type group includes one or more card type categories with the same communication protocol stack and parsing rules, or the same card type group includes multiple card type categories with multiple communication protocol stacks and parsing rules; step S10222, the step of determining the card type determination result of the near-field communication card based on the matched card type group, includes: Step S102221: When any matched card group includes multiple card types with various communication protocol stacks and parsing rules, determine at least one second detection command corresponding to a card type based on the protocol feature fields of the multiple card types; and send the second detection command to the near-field communication card in sequence.

[0064] Card type grouping refers to the intermediate grouping identifiers used in the preset card type mapping table to classify near-field communication (NFC) cards. A card type group can contain one or more specific card type categories. This embodiment further distinguishes two grouping forms: one is where all card type categories within the same card type group share the same communication protocol stack and parsing rules, meaning that the communication methods and data formats of all cards within the group are completely consistent; the other is where the same card type group contains multiple card type categories corresponding to multiple communication protocol stacks and parsing rules, meaning that although different cards within the group may have some overlap in protocol type identifiers or length parameters, the actual communication protocols and data parsing methods they follow are not completely the same, and it is impossible to further distinguish them within the group based solely on the protocol type identifier and length parameters in the response information. In this embodiment, when the matched card type group includes one or more card type categories with the same communication protocol stack and parsing rules, any one of the card type categories can be used to determine the card type determination result of the NFC card. Ultimately, the matching communication protocol stack and parsing rules will be obtained, completing the subsequent reading and verification process.

[0065] Protocol feature fields refer to specific data fields or command response characteristics that are unique to different card types within their communication protocols and can be used to distinguish them from each other. Even if different card types are similar in protocol type identifiers and length parameters, they will return distinctive response data to specific commands during actual communication interactions. The commands or fields corresponding to these distinctive response data are the protocol feature fields. For example, although cards from different chip manufacturers all comply with the ISO / IEC 14443 Type A protocol and have a UID length of 4 bytes, they will return different manufacturer identification codes when receiving commands from specific manufacturers. This manufacturer identification code is a protocol feature field.

[0066] The second detection command refers to a detection command specifically constructed and sent to the card by the terminal after initially determining that the card falls into a card type group containing multiple card types and parsing rules, in order to further and accurately distinguish which specific card type it belongs to. This second detection command differs from the initial detection command in step S101. Its purpose is no longer to obtain general response information, but to perform targeted queries on the differences between candidate card types within the card type group in order to obtain response information that can distinguish the specific card type.

[0067] The response information refers to the data response returned by the near-field communication card after receiving the second probe command sent by the terminal, according to its own communication protocol. Since different card types respond differently to the same second probe command, the terminal can determine which card type within that card group it belongs to by analyzing the response information.

[0068] This step is a further precise differentiation operation performed after the terminal finds a matching card group through a preset card type mapping table and discovers that the card group contains multiple card types with different communication protocol stacks and parsing rules. Since different card types within this card group correspond to different communication protocol stacks and parsing rules, the terminal cannot uniquely determine which card type it belongs to based solely on the protocol type identifier and length parameter obtained from the response information. Therefore, it needs to send targeted second probing commands to obtain more differentiation information. Specifically, the terminal first analyzes the differences between these card types based on the protocol feature fields of each card type contained within the card group, and then constructs one or more second probing commands based on these differences.

[0069] Step S102222: When the response information of the near-field communication card is received, the corresponding card type is determined as the card type determination result according to the second detection instruction corresponding to the response information; when the response information of the near-field communication card is not received, the card type determination result is determined according to the card type other than at least one of the multiple card types.

[0070] This step utilizes the differences in card responses to different second probe commands to accurately pinpoint the specific card category. In practice, after sending the second probe commands sequentially, the terminal monitors the card's response information in real time. When the terminal receives a response from a card to a particular second probe command, it indicates that the card correctly understands and responds to that command. Since this command is specifically designed for a particular card category, the terminal can use the response information to determine the card category corresponding to that second probe command and output that as the final card category determination result. Conversely, if the terminal sends a second probe command but receives no response from the card, it means the card does not belong to the card category targeted by that command. In this case, the terminal can exclude that card category and instead determine the card category from the remaining card categories within that card category group, excluding the categories targeted by the previously sent commands.

[0071] In this embodiment, when the card type group contains multiple card types with various communication protocol stacks and parsing rules, it further constructs and sends targeted second detection commands in sequence based on the protocol feature fields of each card type in the group. Then, it accurately determines the specific type of the card based on the card's response to each second detection command, thereby accurately calling the matching communication protocol stack and parsing rules.

[0072] For step S103, the unique identification information of the near-field communication card is read according to the communication protocol stack and parsing rules corresponding to the card type.

[0073] The communication protocol stack and parsing rules refer to the communication protocol processing programs and data parsing methods pre-stored within the check-in terminal, configured for different card types. The communication protocol stack is responsible for exchanging instructions and transmitting data with the card according to the corresponding protocol standard, while the parsing rules are responsible for accurately extracting unique identification information from the raw byte stream according to the data format conventions of the corresponding card. For example, for MIFARE Classic type cards, the terminal needs to load the corresponding authentication process and data block reading rules; for ISO / IEC 15693 type cards, the terminal needs to load the corresponding inventory and readsingle block processes.

[0074] Unique identification information refers to the data stored in the near-field communication card that can uniquely identify the card. It is usually the card number (UID or CSN, etc.). This information is written when the card is manufactured and cannot be changed. It is equivalent to the "ID number" of each card.

[0075] This step, after the card type is determined, involves the terminal calling the matching communication protocol stack and parsing rules to accurately read the card's unique identification information. Because different card types differ in data storage structure, read command format, and authentication process, the terminal must use the protocol stack and parsing rules corresponding to the current card type to correctly complete data reading. Specifically, after determining the card type in the previous step, the terminal selects the communication protocol stack matching the card type from multiple local or cloud storage sets and loads it for execution, while simultaneously calling the corresponding parsing rules to guide data extraction. Through this "determine the type first, then call as needed" approach, the terminal can accurately read the unique identification information from any near-field communication card without reading failures or errors due to protocol mismatches.

[0076] In one embodiment, step S103, which involves reading the unique identifier information of the near-field communication card according to the communication protocol stack and parsing rules corresponding to the card type, includes: Step S1031: Obtain the communication protocol stack and parsing rules bound to the card type.

[0077] The check-in terminal is pre-configured with communication programs and data interpretation methods for each card type to achieve complete data interaction with that type of card. The communication protocol stack is responsible for constructing instructions, managing the communication process, and processing response data according to the communication protocol standards followed by that card type. The parsing rules are responsible for accurately extracting unique identification information from the raw data byte stream obtained during communication, according to the data format conventions specific to that card type. Because different card types differ in instruction format, authentication process, and data storage structure, each card type requires a corresponding, independent communication protocol stack and parsing rules. Once the card type is determined, the terminal can directly retrieve the protocol stack and parsing rules bound to it.

[0078] Step S1032: Generate an interactive instruction sequence based on the communication protocol stack; the interactive instruction sequence includes verification instructions and data reading instructions.

[0079] An interactive instruction sequence refers to an ordered set of instructions automatically generated by the terminal based on the invoked communication protocol stack. These instructions are arranged in a logical order as defined by the communication protocol and are used to complete the entire interactive process with the card, from authentication to data retrieval. The instructions in the interactive instruction sequence are divided into two main categories: verification instructions and data retrieval instructions. Verification instructions are used for identity authentication and authorization confirmation with the card, while data retrieval instructions are used to read target data from the card after successful authentication.

[0080] Verification commands are instructions used in the interactive command sequence to authenticate the identity and verify access permissions of near-field communication (NFC) cards. The verification commands differ depending on the card type. The purpose of verification commands is to ensure that only legitimately authenticated card readers can access the data on the card; they are a security checkpoint in the entire reading process.

[0081] Data read commands are those within the interactive command sequence used to actually read data from the near-field communication card after successful authentication via verification commands. The data read commands vary depending on the card type; they are the execution commands that truly retrieve the unique identification information from the card.

[0082] This step involves the terminal automatically generating an ordered sequence of interactive instructions using the communication protocol stack loaded in the previous step, following the communication flow defined by that stack. This sequence of instructions is not arbitrary but strictly adheres to the instruction execution order defined in the loaded communication protocol stack. It includes two main parts: verification instructions for authorization and data reading instructions for data retrieval. Specifically, the communication protocol stack contains a complete communication flowchart corresponding to this card type, and the terminal generates each instruction sequentially according to the node order of this flowchart.

[0083] Step S1033: Send the verification commands to the near-field communication card in sequence, receive and verify the verification response information returned by the near-field communication card; if the verification is successful, send the data reading commands to the near-field communication card in sequence, and receive the valid data returned by the near-field communication card.

[0084] Verification response information refers to the authentication result data returned by the near-field communication card according to its own communication protocol after receiving a verification command sent by the terminal. This response information includes the card's response to the terminal's authentication request, such as a status code indicating successful or failed authentication, a random number returned by the card, or encrypted response data. The terminal needs to verify this response information to confirm whether the authentication was successful.

[0085] Valid data refers to the response data containing the target data content returned by the near-field communication card after the terminal sends a data read command. This valid data is the original data source that the terminal ultimately needs to interpret according to the parsing rules to extract unique identification information.

[0086] In this step, the terminal first sends the verification commands in the interaction command sequence to the card sequentially via near-field communication (NFC). After sending each verification command, it waits for the card to return the corresponding verification response. The terminal verifies the received verification response according to the verification rules defined in the communication protocol stack to determine whether the authentication was successful. If the response information for all verification commands passes verification, the terminal considers the card authentication successful and then sequentially sends the data reading commands in the interaction command sequence to the card. After successful authentication, the card returns valid data containing the target data according to the protocol. The terminal receives and temporarily stores this valid data.

[0087] Step S1034: Parse all the valid data according to the parsing rules to obtain the unique identification information of the near-field communication card.

[0088] Because different card types use different data encoding formats, byte order, and field positions when returning valid data, the terminal must use parsing rules corresponding to that card type to correctly locate and extract unique identification information from the valid data. In practice, the terminal analyzes all received valid data byte-by-byte or field-by-field according to the data structure defined in the parsing rules.

[0089] This embodiment dynamically generates a complete sequence of interactive instructions matching the determined card type and executes an authentication-before-reading process. Since different card types have fundamental differences in authentication mechanisms and data formats, the terminal generates the instruction sequence by calling a communication protocol stack uniquely bound to each card type. This ensures that every instruction sent to the card, whether a verification instruction or a data reading instruction, conforms to the communication protocol specifications followed by that card, thus enabling the card to receive and respond correctly. Furthermore, by interpreting valid data according to the parsing rules corresponding to the card type, the terminal can accurately extract unique identification information from valid data in different data formats, preventing reading errors due to differences in card data storage structures.

[0090] In this embodiment of the application, when the card type is an access control card, the verification instructions include: an anti-collision card selection instruction, used to select the currently interacting access control card; a three-factor authentication instruction, used to verify the access control card's access permissions; the data reading instructions include: a sector reading instruction, used to read sector data storing the card number; the parsing rule is to extract the card number as a unique identifier from the valid data returned by the sector reading instruction. When the card type is an integrated circuit card, the verification instructions include: a card selection instruction for selecting the currently interacting integrated circuit card; a key verification instruction for verifying the legality of the access key; the data reading instructions include: a data block reading instruction for reading the data block storing the card number; the parsing rule is: extract the card number as a unique identifier from the valid data returned by the data block reading instruction; When the card type is a near-field communication tag card, the verification instruction set is empty (meaning no verification is required and data can be read directly); the data reading instruction set includes: page reading instruction, used to read the tag card's stored page data; the parsing rule is: extract the unique identifier as unique identification information from the valid data returned by the page reading instruction; When the card type is a financial card, the verification instructions include: a reset activation instruction for activating the card and establishing communication; a parameter negotiation instruction for negotiating data transmission parameters; an application selection instruction for selecting a payment application; and a data authentication instruction for verifying the integrity of application data. The data reading instructions include: a record reading instruction for reading application record data. The parsing rule is: the card number is parsed from the valid data returned by the record reading instruction as a unique identifier. When the card type is an identity card, the verification instructions include: a selection instruction for selecting a machine-readable application; the data reading instructions include: a binary reading instruction for reading the chip's machine-readable information; the parsing rule is: extract the machine-readable identifier as a unique identifier from the valid data returned by the binary reading instruction.

[0091] For step S104, when the unique identifier information matches any of the stored unique identifier information, the identity information corresponding to the unique identifier information is obtained; and a check-in record is generated based on the identity information.

[0092] Identity information refers to the information pre-stored in the local database of the check-in terminal and associated with each participant. This information includes at least the participant's name, organization, and other basic identity information, and is bound to the unique identifier of a near-field communication card held by the participant.

[0093] This step is the final confirmation and recording stage of the check-in process. After successfully reading the unique identifier information of the card, the terminal compares it one by one with the unique identifier information of all participants pre-stored in the check-in system. This pre-stored data can be entered into the system during the conference preparation stage by participants submitting the unique identifier information of their cards and binding it with their identity information, or it can be a mapping relationship established in advance through other means. When the comparison finds that the currently read unique identifier information is completely consistent with the unique identifier information of a record in the system, it indicates that the participant has successfully checked in. The terminal then retrieves the corresponding identity information from that record and generates a complete check-in record based on it, including the check-in time, participant identity information, etc., and stores it in the check-in database for subsequent statistics and management. If no match is found, the terminal may prompt that the check-in failed or require the participant to try again.

[0094] In one embodiment, step S104, which generates a check-in record based on the identity information, includes: Step S1041: Obtain the current time information.

[0095] Current time information refers to the current time data obtained by the check-in terminal when it generates a check-in record after matching the unique identifier information with the stored identity information.

[0096] Step S1042: Bind the identity information and the current time information to generate a check-in record.

[0097] The check-in record refers to the check-in data entry generated by the check-in terminal after identity matching is completed. This record contains at least the identity information of the participants and the check-in time information, which is used by the conference management system to count and manage the attendance of the participants.

[0098] This embodiment obtains the current time information and binds it with identity information when generating the check-in record. This allows the check-in terminal to automatically and accurately record the check-in time and associate it with the participant's identity information to generate a complete check-in record after completing the participant identification. Each check-in record contains both the participant's identity and arrival time, enabling the event organizer to not only accurately know which participants have arrived but also precisely track the arrival time of each participant. This provides complete and reliable data support for subsequent tasks such as venue management, agenda arrangement, and attendance statistics.

[0099] Please refer to Figure 2 This application also provides a computer device 301, including: a processor 302, a memory 303, and a computer program 304 stored in the memory 303 and executable on the processor 302. When the processor 302 executes the computer program 304, it implements the steps of the method as described in any one of the embodiments of this application.

[0100] The processor 302 may include one or more processing cores. The processor 302 connects to various parts within the computer device 301 via various interfaces and lines. It executes various functions of the computer device 301 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 303, and by accessing data stored in the memory 303. Optionally, the processor 302 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 302 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required to be displayed on the touch screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 302 and may be implemented as a separate chip.

[0101] The memory 303 may include random access memory (RAM) or read-only memory. Optionally, the memory 303 may include a non-transitory computer-readable storage medium. The memory 303 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 303 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch instructions), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 303 may also be at least one storage device located remotely from the aforementioned processor 302.

[0102] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the method described in any one of the embodiments of this application. That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The computer program may include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The aforementioned storage medium includes: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in computer-readable media may be appropriately added to or subtracted from the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, computer-readable media may not include electrical carrier signals and telecommunication signals, in accordance with legislation and patent practice.

[0103] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application, and this application also intends to include these modifications and variations.

Claims

1. A meeting check-in method based on near-field communication, characterized in that, Applied to check-in terminals, the method includes the following steps: The system sends detection commands to the near-field communication cards of the participants via the near-field communication radio frequency field and receives response information returned by the near-field communication cards. Based on the response information, the length parameters of the communication protocol information and the unique identifier information are determined; according to the communication protocol information and the length parameters, the card type of the near-field communication card is determined; Based on the communication protocol stack and parsing rules corresponding to the card type, read the unique identification information of the near-field communication card; When the unique identifier matches any stored unique identifier, the identity information corresponding to the unique identifier is obtained; and a check-in record is generated based on the identity information.

2. The conference check-in method based on near-field communication according to claim 1, characterized in that, The step of determining the card type of the near-field communication card based on the communication protocol information and the length parameter includes: Obtain the protocol type identifier from the communication protocol information; Based on the protocol type identifier and the length parameter, the card type determination result is determined by a preset card type determination rule; Based on the card type determination result, the card type category of the near-field communication card is obtained.

3. The conference check-in method based on near-field communication according to claim 2, characterized in that, The steps for determining the card type determination result based on the protocol type identifier and the length parameter using preset card type determination rules include: Using the protocol type identifier and the length parameter as query conditions, a matching card type group is searched in a preset card type mapping table based on the query conditions; Based on the matched card type grouping, the card type determination result of the near-field communication card is determined.

4. The conference check-in method based on near-field communication according to claim 3, characterized in that, The step of searching for matching card type groups in a preset card type mapping table based on the query conditions includes: When the protocol type is identified as the first protocol type and the length parameter is the first number of bytes, the first card type group is matched; When the protocol type is identified as the first protocol type and the length parameter is the second number of bytes, the second card type group is matched; When the protocol type is identified as the second protocol type and the length parameter is the second number of bytes, it matches the third card type group; When the protocol type is identified as the second protocol type and the length parameter is the first number of bytes, it matches the fourth card type group.

5. The conference check-in method based on near-field communication according to claim 3 or 4, characterized in that, The same card type group includes one or more card types with the same communication protocol stack and parsing rules, or the same card type group includes multiple card types with multiple communication protocol stacks and parsing rules; The step of determining the card type of the near-field communication card based on the matched card type grouping includes: When any matched card group includes multiple card categories with various communication protocol stacks and parsing rules, a second detection command corresponding to at least one card category is determined based on the protocol feature fields of the multiple card categories; the second detection command is sent to the near-field communication card in sequence. When a response message from the near-field communication card is received, the corresponding card type is determined as the card type determination result based on the second detection command corresponding to the response message; when no response message from the near-field communication card is received, the card type determination result is determined based on a card type other than at least one of the multiple card types.

6. The conference check-in method based on near-field communication according to claim 1, characterized in that, The step of reading the unique identifier information of the near-field communication card according to the communication protocol stack and parsing rules corresponding to the card type includes: Obtain the communication protocol stack and parsing rules bound to the card type; An interactive instruction sequence is generated based on the communication protocol stack; the interactive instruction sequence includes verification instructions and data reading instructions. The verification commands are sent sequentially to the near-field communication card, and the verification response information returned by the near-field communication card is received and verified. If the verification is successful, the data reading commands are sent sequentially to the near-field communication card, and the valid data returned by the near-field communication card is received. All the valid data are parsed according to the parsing rules to obtain the unique identification information of the near-field communication card.

7. The conference check-in method based on near-field communication according to any one of claims 1 to 4, characterized in that, The steps of sending a detection command to the near-field communication card of the participants via the near-field communication radio frequency field and receiving the response information returned by the near-field communication card include: At least two different communication protocol types of detection commands are sequentially transmitted through the near-field communication radio frequency field; Receive the response information returned by the near-field communication card in response to any detection command.

8. The conference check-in method based on near-field communication according to claim 7, characterized in that, The response information includes communication protocol information and a length parameter of unique identification information; or, the response information includes a length parameter of unique identification information but does not include communication protocol information. When the response information includes the length parameters of communication protocol information and unique identifier information, the step of determining the length parameters of communication protocol information and unique identifier information based on the response information includes: Extract the length parameters of the communication protocol information and the unique identifier information from the response information; When the response information includes a length parameter of unique identifier information but does not include communication protocol information, the steps for determining the communication protocol information and the length parameter of unique identifier information based on the response information include: Based on the communication protocol type corresponding to the probe command responded to by the response information, the communication protocol information is determined, and the length parameter of the unique identifier information is extracted from the response information.

9. The conference check-in method based on near-field communication according to any one of claims 1 to 4, characterized in that, The steps for generating a check-in record based on the identity information include: Get the current time information; The identity information and the current time information are bound together to generate a check-in record.

10. A computer device, characterized in that, It includes a processor, a memory, and a computer-readable program stored in the memory, which, when executed by the processor, implements the steps of the method as described in any one of claims 1-9.

Images