Ticket checking method and system, and related apparatus

Abstract

The present application relates to the technical field of communications. Disclosed are a ticket checking method and system, and a related apparatus. The method is applied to a first electronic device, wherein a first electronic device is logged in with a first account. The method comprises: after entering a radio-frequency field of a gate machine, receiving a first authentication request sent by the gate machine, wherein the first authentication request comprises a first random number and a first identifier of the gate machine; on the basis of the first identifier, determining a first order token; on the basis of the first order token and the first random number, determining first authentication information; and sending a first authentication response to the gate machine, wherein the first authentication response comprises the first authentication information and the first random number. In this way, a first electronic device can use a preset encryption algorithm model to encrypt a first order token on the basis of a first random number, and send to a gate machine first authentication information obtained after encryption, such that the security of a ticket checking process can be improved.

Description

A ticket checking method, system and related device

[0001] This application claims priority to Chinese Patent Application No. 202411987931.5, filed on December 28, 2024, entitled "A ticket checking method, system and related apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a ticket checking method, system and related apparatus. Background Technology

[0003] With the continuous development of communication technology, the connection between communication and daily life is becoming increasingly close.

[0004] Users can purchase electronic tickets such as attraction tickets through specific applications or mini-programs. When verification of electronic tickets is required, the electronic device can complete the ticket check by touching the gate. This simplifies the ticket checking process and makes it convenient for users to check their tickets and open the gate.

[0005] However, the above ticket checking method carries the risk of electronic tickets being stolen, resulting in poor security. Summary of the Invention

[0006] This application provides a ticket checking method, system, and related apparatus, which enables fast and secure verification of electronic tickets and improves the security of electronic tickets.

[0007] In a first aspect, this application provides a ticket checking method applied to a first electronic device, the first electronic device being logged into a first account; the method includes: after entering the radio frequency field of a gate, receiving a first authentication request sent by the gate, the first authentication request including a first random number and a first identifier of the gate; determining a first order token based on the first identifier; determining first authentication information based on the first order token and the first random number; and sending a first authentication response to the gate, the first authentication response including the first authentication information and the first random number.

[0008] Using the ticket checking method provided in this application, the first electronic device can encrypt the first order token based on a first random number using a preset encryption algorithm model, and send the encrypted first authentication information to the gate. In this way, even if the other end device is an unauthorized gate, it can only obtain the encrypted first authentication information and cannot directly steal the first order token.

[0009] In one possible implementation, the first authentication information is determined based on the first order token and the first random number, specifically including: determining the first authentication information based on the first order token, the first random number, and the first identifier.

[0010] In this way, the first electronic device can generate first authentication information related to the first identifier, which enhances the complexity and randomness of the first authentication information, thereby improving the security of the ticket checking process.

[0011] In one possible implementation, the first authentication information includes a first authentication code and a first credential index; the first authentication information is determined based on a first order token, a first random number, and a first identifier, specifically including: determining a first credential index based on the first order token; determining a first key based on the first order token and the first random number; and determining a first authentication code based on the first random number, the first key, the first credential index, and the first identifier.

[0012] In this way, a first authentication code and a first credential index can be generated based on the first order token, the first random number, and the first identifier using a preset encryption algorithm model. The first authentication code can be used to verify whether the preset encryption algorithm model in the first electronic device is consistent with the preset encryption algorithm model in the third-party scenic spot's backend.

[0013] In one possible implementation, the first authentication information further includes an authentication type; the first authentication code is determined based on the first random number, the first key, the first credential index, and the first identifier, specifically including: determining the first authentication code based on the first random number, the first key, the first credential index, the first identifier, and the authentication type.

[0014] In this way, a first authentication code can be generated based on the authentication type of the first electronic device, which enhances the complexity and randomness of the first authentication information, thereby improving the security of the ticket checking process.

[0015] In one possible implementation, the first identifier includes the first device identifier of the gate and / or the first item identifier corresponding to the gate.

[0016] In one possible implementation, determining the first order token based on the first identifier specifically includes: determining the first item identifier based on the first identifier; and determining the first order token in the first electronic device based on the first item identifier.

[0017] Wherein, if the first identifier includes the first project identifier, the first electronic device can determine the first project identifier based on the first identifier, and query the first order token corresponding to the first project identifier locally in the first electronic device according to the first project identifier; if the first identifier only includes the first device identifier, the first electronic device can query the corresponding first project identifier based on the first device identifier, and then query the first order token corresponding to the first project identifier locally in the first electronic device according to the first project identifier.

[0018] In this way, if the first electronic device has the first order token stored locally, the first order token can be queried locally based on the first identifier.

[0019] In one possible implementation, determining the first order token based on the first identifier specifically includes: determining the first project identifier based on the first identifier; sending a token acquisition request to the third-party scenic area's backend, the token acquisition request including the first project identifier; and receiving a token acquisition response sent by the third-party scenic area's backend, the token acquisition response including the first order token.

[0020] If the first identifier includes the first project identifier, the first electronic device can determine the first project identifier based on the first identifier and query the first order token corresponding to the first project identifier from the third-party scenic area backend based on the first project identifier; if the first identifier only includes the first device identifier, the first electronic device can query the corresponding first project identifier based on the first device identifier and then query the first order token corresponding to the first project identifier from the third-party scenic area backend based on the first project identifier.

[0021] In this way, even if the first electronic device does not store the first order token locally, the first order token can be retrieved from the third-party scenic spot's backend based on the first identifier.

[0022] In one possible implementation, the first identifier includes a first device identifier; determining the first project identifier corresponding to the first device identifier specifically includes: sending a project identifier acquisition request to the business system, the project identifier acquisition request including the first device identifier; and receiving a project identifier acquisition response sent by the business system, the project identifier acquisition response including the first project identifier.

[0023] In this way, if the first identifier does not include the first project identifier, the first electronic device can query the first project identifier corresponding to the first device identifier from the business system based on the first device identifier.

[0024] In one possible implementation, the method further includes: after logging into the first account, sending an account information retrieval request to the business system, the account information retrieval request including the first account; receiving the first account information sent by the business system, the first account information being used to identify the user identity of the first account; receiving and responding to the user's first ticket purchase operation, determining the first ticket purchase information, the first ticket purchase information including the first project identifier, the number of tickets, and the ticket type; sending a first ticket purchase request to the third-party scenic spot's backend, the first ticket purchase request including the first ticket purchase information and the first account information; and receiving a first ticket purchase response sent by the third-party scenic spot's backend, the first ticket purchase response including the first order token.

[0025] In this way, the first electronic device can purchase electronic tickets through the first account and obtain the first order token.

[0026] In one possible implementation, the method further includes: after logging into the first account, sending an account information retrieval request to the business system, the account information retrieval request including the first account; receiving the first account information sent by the business system, the first account information being used to identify the user identity of the first account; sending a token synchronization request to the third-party scenic spot backend, the token synchronization request including the first account information; and receiving a token synchronization response sent by the third-party scenic spot backend, the token synchronization response including the first order token.

[0027] In this way, when other electronic devices purchase tickets through the first account, the first electronic device can synchronize the first order token purchased by other electronic devices through the first account after logging into the first account, so as to shorten the ticket checking time and improve the ticket checking efficiency in the subsequent ticket checking process.

[0028] In one possible implementation, after entering the radio frequency field of the turnstile, the method further includes: receiving a probe frame sent by the turnstile, the probe frame indicating that the turnstile supports a specified NFC protocol; sending a probe ACK frame to the turnstile, the probe ACK frame indicating that a first electronic device supports the specified NFC protocol; receiving a notification frame sent by the turnstile, the notification frame carrying device characteristic information of the turnstile, the device characteristic information of the turnstile including a service identifier and a device organization identifier, wherein the service identifier indicates the type of NFC service supported by the turnstile, and the device organization identifier indicates the manufacturer using the turnstile to provide NFC services; sending a notification ACK frame to the turnstile, the notification ACK frame indicating that the first electronic device has received the notification frame; and determining, based on the device characteristic information of the turnstile, that the type of NFC service of the turnstile is electronic ticketing.

[0029] In this way, after the first electronic device enters the radio frequency field of the gate, it can complete the interaction through the pre-agreed NFC protocol to determine that the current scenario is an electronic ticket checking scenario, thereby triggering the first electronic device to activate the relevant electronic ticket services.

[0030] In one possible implementation, after sending a Notify ACK frame to the gate, the method further includes: receiving a parameter negotiation command sent by the gate; and sending a parameter negotiation response to the gate, wherein the parameter negotiation command and parameter negotiation instructions are used to negotiate the transmission parameters at the application protocol layer.

[0031] In this way, the first electronic device and the gate can negotiate the transmission parameters of the application protocol layer, so that the gate can interact with the application protocol layer of the first electronic device in the future.

[0032] In one possible implementation, the first electronic device includes an electronic ticketing service and a near-field communication (NFC) protocol stack; receiving a first authentication request sent by a gate, specifically including: receiving the first authentication request sent by the gate via the NFC protocol stack; receiving the first authentication request sent by the NFC protocol stack via the electronic ticketing service; determining a first order token based on a first identifier, specifically including: determining the first order token based on the first identifier via the electronic ticketing service; determining first authentication information based on the first order token and a first random number, specifically including: determining the first authentication information based on the first order token and the first random number via the electronic ticketing service; sending a first authentication response to the gate, specifically including: sending the first authentication response to the NFC protocol stack via the electronic ticketing service; and sending the first authentication response to the gate via the NFC protocol stack.

[0033] In this way, the first electronic device can interact with the gate through the NFC protocol stack, and query the order token and generate authentication information through the electronic ticket service to complete the ticket check.

[0034] Secondly, this application provides a ticket checking method applied to a turnstile. The method includes: detecting the entry of a first electronic device into the radio frequency field of the turnstile, generating and storing a first random number; sending a first authentication request to the first electronic device, the first authentication request including the first random number and a first identifier of the turnstile; receiving a first authentication response sent by the first electronic device, the first authentication response including first authentication information and the first random number; detecting that the first authentication response carries the first random number; sending a second authentication request to a third-party scenic area backend, the second authentication request including the first authentication information, the first random number and the first identifier; receiving a second authentication response sent by the third-party scenic area backend; and opening the turnstile in response to the second authentication response.

[0035] In this way, the turnstile can determine whether the electronic devices interacting before and after the authentication process are the same by comparing the random number carried in the first authentication response with the random number generated by the turnstile. This improves the security of the ticket checking process and prevents unauthorized devices from stealing electronic tickets. Furthermore, the turnstile can also determine whether to open the gate based on the authentication response sent by the third-party scenic area's backend system.

[0036] In one possible implementation, the method further includes: after sending a second authentication request to the third-party scenic spot's backend, deleting the first random number.

[0037] This ensures that the random number is generated randomly each time a ticket is checked, thereby improving the security of the ticket checking process.

[0038] In one possible implementation, the method further includes: when generating the first random number, setting a timer with a duration of the first duration; and deleting the first random number when the timer countdown ends.

[0039] Setting a timer simultaneously with the generation of the first random number ensures that the first random number is only valid until the timer's countdown ends. If an authentication response carrying the first random number is received after this validity period, the ticket check is considered to have failed. This effectively sets a check period for each ticket check; exceeding this period results in the check being considered a failure, preventing unauthorized transactions by other devices and improving ticket check security.

[0040] In one possible implementation, the method includes: detecting that a second electronic device has entered the radio frequency field of the gate, generating and storing a second random number; sending a third authentication request to the second electronic device, the third authentication request including the second random number and a first identifier of the gate; receiving a third authentication response sent by the second electronic device, the third authentication response including second authentication information and a third random number; detecting that the second random number and the third random number are inconsistent, outputting an error message, the error message being used to indicate to the user that the authentication information is incorrect.

[0041] In this way, when the gate detects that the random number it generates is inconsistent with the random number sent by the electronic device, it can determine that the authentication information is incorrect and end the ticket checking process.

[0042] Thirdly, this application provides a ticket checking method applied to the backend of a third-party scenic area. The method includes: receiving a second authentication request sent by a gate, the second authentication request including first authentication information, a first random number, and a first identifier, the first authentication information including a first voucher index and a first authentication code; determining a second authentication code and a first order token based on the first authentication information, the first random number, and the first identifier; detecting that the first authentication code and the second authentication code are the same; determining first account information based on the first order token; sending a first query request to a ticketing system, the first query request including the first account information; receiving a first query response sent by the ticketing system, the first query response including a first order; and responding to the first query response by sending a second authentication response to the gate, the second authentication response being used to instruct the gate to open and allow passage.

[0043] In this way, the third-party scenic area's backend can determine whether the first authentication information can pass authentication by comparing the second authentication code it generates with the first authentication code sent by the gate. If the first authentication code matches the second authentication code, it means that the encryption algorithm model used by the first electronic device is the same as the encryption algorithm model used by the third-party scenic area's backend. At this point, it can be determined that the first authentication information can pass authentication.

[0044] Fourthly, this application provides a ticket checking system, including a first electronic device, a turnstile, and a third-party scenic area backend; wherein the first electronic device is used to implement any possible implementation method in the first aspect, the turnstile is used to implement any possible implementation method in the second aspect, and the third-party scenic area backend is used to implement any possible implementation method in the third aspect.

[0045] Fifthly, this application provides an electronic device including one or more processors and one or more memories; wherein the one or more memories are coupled to one or more processors, and the one or more memories are used to store computer instructions, which, when the one or more processors execute the computer instructions, implement any one of the possible ticket checking methods in the first to third aspects.

[0046] In a sixth aspect, this application provides a chip system, including: a processing circuit and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processing circuit, and the processing circuit is used to execute the code instructions to perform any of the possible ticket checking methods in the first to third aspects.

[0047] In a seventh aspect, this application provides a readable storage medium storing computer instructions that, when executed by a processor, implement any one of the possible ticket checking methods in the first to third aspects.

[0048] Eighthly, this application provides a computer program product including computer instructions, which, when executed by a processor, implements any one of the possible ticket checking methods of the first to third aspects.

[0049] The beneficial effects of aspects four through eight can be referenced from the beneficial effects of aspects one through three above. Attached Figure Description

[0050] Figure 1 is a schematic diagram of the working principle of NFC provided in an embodiment of this application;

[0051] Figure 2A is a schematic diagram of the system architecture of a ticket checking system provided in an embodiment of this application;

[0052] Figure 2B is a schematic diagram of the device configuration of a gate provided in an embodiment of this application;

[0053] Figure 3A is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0054] Figure 3B is a schematic diagram of the layered architecture of an electronic device provided in an embodiment of this application;

[0055] Figure 3C is a schematic diagram of the framework of an NFC protocol stack provided in an embodiment of this application;

[0056] Figure 3D is a schematic diagram of the interaction between an electronic device, a gate, and various servers in a cloud server provided in an embodiment of this application;

[0057] Figure 3E is a schematic diagram of the functional modules of a business system provided in an embodiment of this application;

[0058] Figure 4A is a schematic diagram of a ticket purchase process provided in an embodiment of this application;

[0059] Figure 4B is a schematic diagram of a ticket checking process provided in an embodiment of this application;

[0060] Figure 5 is a schematic diagram of a ticket purchase process provided in an embodiment of this application;

[0061] Figure 6 is a schematic diagram of another ticket purchase process provided in an embodiment of this application;

[0062] Figure 7 is a flowchart illustrating a ticket checking method provided in an embodiment of this application;

[0063] Figure 8 is a schematic diagram of a process for determining whether an order token exists, provided in an embodiment of this application;

[0064] Figure 9 is a schematic diagram of a process provided in an embodiment of this application for a third-party scenic spot backend to determine whether an order token can be found based on account information;

[0065] Figure 10 is a schematic diagram of a process for determining authentication information based on an order token T0 and a random number r according to an embodiment of this application;

[0066] Figure 11 is a schematic diagram of a process provided in an embodiment of this application for a third-party scenic spot backend to determine whether the authentication information can pass the authentication;

[0067] Figure 12 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0068] Figures 13-16 are schematic diagrams of a set of communication devices provided in the embodiments of this application;

[0069] Figure 17 is a schematic diagram of the hardware structure of a server provided in an embodiment of this application;

[0070] Figure 18 is a flowchart illustrating a ticket checking method provided in an embodiment of this application;

[0071] Figure 19 is a flowchart illustrating a ticket checking method provided in an embodiment of this application;

[0072] Figure 20 is a flowchart illustrating a ticket checking method provided in an embodiment of this application. Detailed Implementation

[0073] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

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

[0075] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0076] The working principle of near field communication (NFC) technology in the embodiments of this application is described below.

[0077] Figure 1 shows a schematic diagram of the working principle of NFC provided in an embodiment of this application.

[0078] As shown in Figure 1, the two parties communicating using NFC technology can include a proximity coupling device (PCD) (also known as an NFC reader) and a proximity integrated circuit card (PICC). The PCD can achieve contactless communication with the PICC in close proximity. The PCD and PICC can allow near-field communication at specific data rates (e.g., 106, 212, 424, or 848 kilobits per second, kbps) and specific frequencies (e.g., 13.56 MHz). Communication between the PCD and PICC can occur at close range, for example, within a range of approximately 2 to 4 centimeters.

[0079] The PCD (Polymer Capacitor) can generate high-frequency alternating current to produce a radio frequency (RF) field of a specified frequency (e.g., 13.56 MHz), and transmit data to the PICC (Peripherally Input Cell) via this RF field. When the PICC is near the PCD, it can sense the RF field emitted by the PCD. Upon entering the RF field, the PICC can obtain energy from the PCD's RF field through electromagnetic induction, and use this energy to generate electricity to drive the internal circuitry of the PICC, thus enabling data transmission from the PCD to the PICC. Alternatively, the PICC can also transmit data to the PCD by modulating the RF field with a load, achieving data transmission from the PICC to the PCD.

[0080] In the embodiments of this application, the PICC can be a physical NFC tag card. Some NFC devices (e.g., mobile phones, tablets, smartwatches, and other electronic devices) can also simulate themselves as PICCs that conform to NFC-related standards through the data of NFC emulation cards to realize the functions of PICCs and communicate with the PCD based on NFC technology.

[0081] The following describes the system architecture of a ticket checking system 10 provided in an embodiment of this application.

[0082] Figure 2A shows a schematic diagram of the system architecture of a ticket checking system 10 provided in an embodiment of this application.

[0083] As shown in Figure 2A, the ticket checking system 10 may include an electronic device 100, a turnstile 200, and a cloud server 300. Optionally, the ticket checking system 10 may also include an electronic device 400, etc. The electronic device 100 can simulate itself as a PICC conforming to NFC standards by using data information from an NFC emulation card to achieve PICC functionality. The turnstile 200 can act as a PCD and communicate with the electronic device 100 in PICC mode based on NFC technology.

[0084] In one possible implementation, the electronic device 100 can support both PICC mode and PCD mode. In PCD mode, the electronic device 100 can act as the PCD transmitter to communicate with the PICC. In PICC mode, the electronic device 100 can act as the PICC passive receiver of the PCD's transmitted radio frequency field, communicating with the PCD based on NFC technology via load modulation.

[0085] In this embodiment, after the electronic device 100 enables the NFC function, the electronic device 100 can be in PICC mode. If the electronic device 100 supports both PCD mode and PICC mode, after enabling the NFC function, the electronic device 100 can switch between PICC mode and PCD mode in a time-sharing manner.

[0086] In the ticket checking system 10, the gate 200 can establish a communication connection with the cloud server 300. In some embodiments, the electronic device 100 can also establish a wireless communication connection with the cloud server 300.

[0087] When electronic device 100 enters the radio frequency field of gate 200, it can communicate with gate 200 based on NFC technology. Electronic device 100 can receive authentication request 1 sent by gate 200. Authentication request 1 may include gate 200's device identifier (ID) and a random number r generated by gate 200. Authentication request 1 is used to request the order token corresponding to gate 200's ID. Electronic device 100 can then determine whether it can find the order token based on gate 200's ID. If the order token cannot be found, electronic device 100 can output a ticket purchase prompt, suggesting the user purchase an electronic ticket that can be verified by gate 200. If the order token T0 corresponding to gate 200's ID is found, electronic device 100 can encrypt the order token T0 based on the random number r using a preset encryption algorithm model F0 to obtain authentication information. Subsequently, electronic device 100 can send authentication response 1 to gate 200. Authentication response 2 may include authentication information and a random number r. Authentication response 1 can be used to trigger gate 200 to determine whether to open the gate based on the authentication result of the authentication information. If authentication is successful, electronic device 100 can receive a ticket check success notification from gate 200 and delete the locally stored order token T0. If authentication fails, electronic device 100 can receive a ticket check failure notification from gate 200 and output an authentication failure message to inform the user that authentication failed and passage through the gate is impossible.

[0088] When electronic device 100 enters the radio frequency field of gate 200, gate 200 can communicate with electronic device 100 based on NFC technology. Gate 200 can generate a random number r and send an authentication request 1 to electronic device 100. Authentication request 1 can include the ID of gate 200 and the random number r. Then, gate 200 can receive an authentication response 1 sent by electronic device 100. Authentication response 1 can include authentication information and the random number r. Gate 200 can first determine whether the random number r carried in authentication response 1 matches the random number generated by gate 200. If the two random numbers match, gate 200 can send the authentication information and the random number r to cloud server 300 for authentication, and determine whether to open the gate based on the authentication result sent by cloud server 300. If the authentication result is successful, gate 200 can open the gate and send a ticket check success notification to electronic device 100; if the authentication result is unsuccessful, gate 200 can send a ticket check failure notification to electronic device 100. If the two random numbers are inconsistent, the gate 200 can send a ticket check failure notification to the electronic device 100. The ticket check failure notification is used to notify the electronic device 100 that the ticket check has failed.

[0089] The cloud server 300 can be a server cluster, which may include one or more servers (or server modules), and these servers may belong to different operators. The specific architecture of the cloud server 300 can be referred to the relevant description in the embodiment shown in Figure 3D below, which will not be detailed here. In some embodiments, during the purchase of electronic tickets, the cloud server 300 can interact with the electronic device 100 to generate an order and an order token, and send the order token to the electronic device 100. During ticket checking, the cloud server 300 can provide authentication services to the gate 200, i.e., verifying whether the authentication information can find the corresponding order, and sending the authentication result to the gate 200. The authentication result may include authentication successful or authentication failed. In some embodiments, the cloud server 300 can also provide the electronic device 100 with order token query and / or synchronization services, i.e., when the electronic device 100 logs into account 1, it can obtain the order tokens corresponding to orders purchased by other electronic devices through account 1 from the cloud server 300.

[0090] The functional description of electronic device 400 can also refer to the relevant functional description of electronic device 100 described above. Furthermore, in some embodiments, electronic device 400 can also log in to account 1 and obtain order tokens previously purchased by the user through electronic device 100 logged in to account 1 from the cloud server 300. In other embodiments, electronic device 100 can also log in to account 1 and obtain order tokens previously purchased by the user through electronic device 400 logged in to account 1 from the cloud server 300.

[0091] In this embodiment of the application, the device type of electronic device 100 can be any of the following: mobile phone, tablet computer, handheld computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), as well as smart home devices such as smart screens and smart speakers, wearable devices such as smart bracelets, smartwatches, and smart glasses, extended reality (XR) devices such as augmented reality (AR), virtual reality (VR), and mixed reality (MR), in-vehicle devices, or smart city devices.

[0092] It is understood that the embodiment shown in Figure 2A above is only an example. In the embodiments of this application, the ticket checking system 10 may also include more, fewer or different electronic devices than the above embodiments. In other embodiments, the electronic device for purchasing tickets may also be an electronic device different from the electronic device 100 (e.g., other electronic devices that have the same account logged in with the electronic device). This application does not limit this.

[0093] The following describes the device configuration of a gate 200 provided in the embodiments of this application, as well as the positional relationship between the electronic device 100 and the gate 200 when conducting NFC communication.

[0094] Figure 2B shows a schematic diagram of the device configuration of a gate 200 provided in an embodiment of this application.

[0095] As shown in Figure 2B, the turnstile 200 may include one or more posts 201 and one or more barriers 202. The posts 201 may be fixed to the ground or other flat surfaces, and the barriers 202 may be mounted on the posts 201 and are rotatable. The barriers 202 may have two states: open and closed. When the barrier 202 is closed, the angle between the barrier 202 and the posts 201 is approximately 90°, preventing users from passing through the passage between the posts 201. When the barrier 202 is open, the angle between the barrier 202 and the posts 201 is approximately 0° (or 180°), allowing users to pass through the passage between the posts 201. The posts 201 may also have a card-swiping area 203, which can be used to contact the electronic device 100 for communication based on NFC technology. As shown in Figure 2B, when the electronic device 100 contacts the card swiping area 203 and the gate 200 successfully checks the ticket, the barrier 202 can change from a closed state to an open state to facilitate the passage of the user.

[0096] It is understood that the embodiment shown in Figure 2B is only an example. In the embodiments of this application, the gate 200 may also adopt a different equipment form than the embodiment shown in Figure 2B, such as having more, fewer, or different forms of posts and baffles than the embodiment shown in Figure 2B. In addition, the card swiping area 203 may also be set in a different position than the above embodiments. This application does not limit these aspects.

[0097] The following is a schematic diagram of the structure of an electronic device 100 provided in the embodiments of this application.

[0098] Figure 3A shows a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application.

[0099] As shown in Figure 3A, the electronic device 100 may include a processor 101 and an NFC module 102. The processor 101 may run one or more applications. These applications may include one or more of the following: a wallet application, one or more host-based card emulation (HCE) applications, etc. Optionally, the electronic device 100 may also include a secure element (SE) 103 and / or a subscriber identity module (SIM) card. The processor 101 may be connected to the NFC module 102, the SE 103, and the SIM card 104, respectively. The NFC module 102 may also be connected to the SE 103 and the SIM card 104.

[0100] The NFC module 102 may include an NFC controller (not shown in Figure 3A), an NFC transceiver (not shown in Figure 3A), and an NFC memory (not shown in Figure 3A). The NFC controller may be connected to the processor 101, and may also be connected to the NFC transceiver and the NFC memory, respectively.

[0101] The NFC controller is primarily used for modulation and demodulation of contactless communication signals, controlling the input and output of data in the NFC memory, and interacting with the processor 101. The NFC transceiver is used to transmit and receive NFC signals (e.g., 13.56MHz radio frequency signals), and may include an electromagnetic compatibility (EMC) filter circuit, a matching circuit, a receiving circuit, and an NFC antenna, where the NFC antenna may be a loop antenna, used to enable the proximity-based contactless communication capability of the NFC module 102. The NFC memory can be used to store data sent by the NFC module 102 to the gate 200, as well as data received from the gate 200. In some embodiments, the NFC memory can be a shared memory that can be used by the various components in the NFC module 102; for example, some data in the NFC memory can be accessed by the NFC controller, while other data can be accessed by the SE 103.

[0102] In other embodiments, the NFC memory may be a collection of multiple memories. For example, the NFC controller may include a first memory among these multiple memories. The first memory may include instructions or data that the NFC controller has used or reused. If the NFC controller needs to use the instruction or data again, it can directly retrieve it from the first memory, thus reducing the waiting time of the NFC controller. SE103 may include a second memory among these multiple memories. The second memory may include card information such as that of the NFC emulator based on the secure element. Thus, if SE103 needs to read the card information of the NFC emulator, it can read the card information of the NFC emulator from the second memory in SE103. SIM card 104 may include a third memory among these multiple memories. The third memory may include card information such as that of the NFC emulator based on the SIM card. Thus, if SIM card 104 needs to read the card information of the NFC emulator, it can read the card information of the NFC emulator from the third memory in SIM card 104.

[0103] In some embodiments, the NFC memory described above can also store routing information. In some embodiments, this routing information can be controlled or managed by the NFC controller, and can include a routing table consisting of a list of routing rules. Each routing rule contains an Application Identifier (AID) and a destination; the destination is the location where the applet used to implement the business logic of the NFC emulator card runs. The destination can include an HCE application running in the processor 101 of the electronic device 100, or an SE 103 or SIM card 104 connected to the NFC controller.

[0104] The SE103 and NFC module 102 can be two separate chips. Alternatively, the SE103 and NFC module 102 can be packaged into a single chip.

[0105] Electronic device 100 can activate one or more NFC emulator cards in an application based on user input, thereby enabling electronic device 100 to support one or more NFC services. The specific business processing logic of the NFC emulator card in electronic device 100 is implemented by an applet. The applet can be stored and run in the corresponding hardware device or software module (e.g., HCE application, SIM card, SE, etc.) of the NFC emulator card.

[0106] The card emulation modes of electronic device 100 can be divided into hardware-based virtual card mode and software-based HCE mode. Among them,

[0107] 1. In hardware-based virtual card mode, electronic device 100 can provide the operating environment for the Applet corresponding to the NFC emulator card, as well as the storage and processing of the NFC emulator card's business data, through SE103 or SIM card 104. NFC module 102, as the front end of contactless communication, receives commands from the external PCD and forwards them to SE103 or SIM card 104. The Applet in SE103 or SIM card 104 then processes the commands and sends response data to the external PCD via NFC module 102. Users can activate one or more NFC emulator cards in a wallet application, which can write the Applets and card data of one or more NFC emulator cards into SE103. Alternatively, users can activate one or more NFC emulator cards in a SIM card application, which can write the Applets and card data of one or more NFC emulator cards into SIM card 104 for storage.

[0108] 2. In software-based HCE mode, the HCE application running in processor 101 can provide the operating environment for the Applet corresponding to the NFC emulator card, as well as the storage and processing of the NFC emulator card's business data. After receiving a command from an external PCD, NFC module 102 can send the command to the HCE application. The HCE application can process the command received by the NFC module through the Applet running in the HCE application or a cloud server, and generate response data for the PCD. The HCE application can then send the response data to NFC module 102. NFC module 102 can then send the response data to the external PCD. Users can activate one or more NFC emulator cards in the HCE application. The HCE application can run one or more NFC emulator card Applets and store the NFC emulator card data on the local memory of electronic device 100 or on a cloud server.

[0109] Optionally, the processor 101 can also run an NFC basic service module. The NFC basic service module can be used to provide common management functions for one or more NFC services. These common management functions may include file management, card activation, security management, service routing management, and other functions.

[0110] For example, in the card emulation scenario described above, the electronic device 100 has a native NFC-related application installed, and users can also download and install third-party applications from app stores. Generally, the native application can use a hardware-based virtual card solution, while the third-party application can use an HCE solution. The native application can be a wallet application, etc., and the third-party application can be, for example, a ticketing application, a payment application, etc. The above examples are merely for explaining this application and should not be construed as limiting it.

[0111] The following describes a layered architecture of an electronic device 100 provided in an embodiment of this application.

[0112] Figure 3B shows a schematic diagram of the layered architecture of an electronic device 100 provided in an embodiment of this application.

[0113] As shown in Figure 3B, the electronic device 100 may include an application layer, a system layer, and a hardware layer.

[0114] The application layer may include a ticketing application 12 and / or a wallet application 13. The ticketing application 12 (or wallet application 13) can be used to purchase electronic tickets, such as attraction tickets, exhibition tickets, performance tickets, and competition tickets. The ticketing application 12 (or wallet application 13) can also be used to manage the electronic tickets purchased by users.

[0115] The system layer may include an electronic ticketing service 11, an NFC protocol stack 14, and an NFC security module 16. The specific architecture of the NFC protocol stack 14 can be referred to the relevant description in the embodiment shown in Figure 3C below, and will not be detailed here. The electronic ticketing service 11 can be used to communicate with the cloud server 300 based on an account logged in through the electronic device 100 (e.g., account 1). In some embodiments, the electronic ticketing service 11 can also interact with applications such as ticketing application 12 and wallet application 13, receiving order tokens obtained by these applications after purchasing tickets. In some embodiments, after receiving the order token, the electronic ticketing service 11 can store the order token in the NFC security module 16. It should be noted that the NFC security module 16 can be used to store order tokens; the electronic ticketing service 11 can both store order tokens in the NFC security module 16 and query and read order tokens stored in the NFC security module 16.

[0116] The hardware layer may include an NFC device 15, such as NFC firmware 15a. The NFC device 15 can be used to communicate with other electronic devices equipped with NFC based on the NFC protocol stored in the NFC protocol stack 14.

[0117] It is understood that the embodiment shown in FIG3B is only an example. In the embodiments of this application, the electronic device 100 may include more, fewer, or different hierarchical structures than the above embodiments, and each level may also include more, fewer, or different modules than the above embodiments. This application does not limit this.

[0118] The following describes an NFC protocol stack 14 provided in an embodiment of this application.

[0119] Figure 3C shows a schematic diagram of the framework of an NFC protocol stack 14 provided in an embodiment of this application.

[0120] As shown in Figure 3C, the NFC protocol stack may include a physical layer, a radio frequency layer, an access layer, a transport layer, and an application protocol layer.

[0121] The physical layer can be used to implement the physical characteristics of NFC communication.

[0122] The radio frequency (RF) layer can be used to implement RF specifications for NFC communication, such as data rate and RF signal frequency.

[0123] The access layer can be used to implement functions such as polling and device discovery, service result notification, card conflict management, transmission protocol negotiation, timeout and retransmission mechanism, PICC / PCD mode switching, and converged card selection.

[0124] The transport layer includes a high-speed data transmission protocol, which enables data transmission between the PCD and PICC at the application layer.

[0125] The application protocol layer can be used to implement one or more NFC services and one or more service management policies. The one or more NFC services may include codeless payment, electronic tickets, access control, digital ID cards, all-scenario contactless payment, and short-range data transmission. The one or more service management policies may include any one or more of file management, card long-term activation, security management, and service routing management. The processing logic of the NFC services can be executed by an Applet. In one possible implementation, the processing logic of the service management policies can be executed by the NFC basic service module.

[0126] In this embodiment of the application, the NFC protocol stack shown in Figure 3C above can be referred to as the first protocol stack.

[0127] The following describes the architecture of a cloud server 300 provided in an embodiment of this application.

[0128] Figure 3D shows a schematic diagram of the interaction between an electronic device 100, a gate 200, and various servers in a cloud server 300 provided in an embodiment of this application.

[0129] As shown in Figure 3D, the cloud server 300 may include one or more servers (or server modules), such as the business system 310, the ticketing system 320, and the third-party scenic area backend 330. These one or more servers can be located in different places and operated by one or more operators. This application does not limit the physical location of the various modules in the cloud server 300. Wherein:

[0130] The business system 310 can store the correspondence between project identifiers (such as identifiers for scenic spots, performances, competitions, gatherings, etc.) and gate device identifiers. The business system 310 can manage the stored device identifiers and project identifiers. In some embodiments, the business system 310 can also provide validity verification services for project identifiers and / or device identifiers. In some embodiments, the business system 310 can also provide account management services such as account registration, authentication, and cancellation. In some embodiments, when electronic device 100 logs into account 1, the business system 310 can receive and respond to an account information retrieval request sent by electronic device 100, and send account information 1 of account 1 to electronic device 100. In some embodiments, such as during ticket checking, the business system 310 can also establish a communication connection with electronic device 100 (or other electronic devices), receive the device identifier of gate 200 (or other gates) sent by electronic device 100, query the project identifier 1 corresponding to the device identifier of gate 200, and then send the project identifier 1 to electronic device 100.

[0131] The ticketing system 320 can provide electronic ticket purchase and verification services. In some embodiments, during the ticket purchase process, the ticketing system 320 can receive a purchase request sent by the third-party scenic spot backend 330, generate an order, and send the order to the third-party scenic spot backend 330. In some embodiments, during the ticket inspection process, the ticketing system 320 can receive a query request carrying account information 1 sent by the third-party scenic spot backend 330, query the order corresponding to account information 1, and send the query result to the third-party scenic spot backend 330.

[0132] The third-party scenic area backend 330 can correspond to one or more project identifiers. In some embodiments, the third-party scenic area backend 330 can be a server providing services for a single project (e.g., scenic area A1, performance B1, or competition C1, etc.), in which case the third-party scenic area backend 330 can correspond to a unique project identifier. In other embodiments, the third-party scenic area backend 330 can be a server providing services for multiple projects (e.g., multiple scenic areas, multiple performance projects, multiple projects within a specified scenic area, etc.), in which case the third-party scenic area backend 330 can correspond to multiple project identifiers.

[0133] During the ticket purchase process, the third-party scenic area backend 330 can establish a communication connection with electronic device 100 (or electronic device 400, etc.) and also with ticketing system 320. In some embodiments, the third-party scenic area backend 330 can forward the ticket purchase request sent by electronic device 100 to ticketing system 320, generate an order token based on the order returned by ticketing system 320, and send the order token to electronic device 100.

[0134] During the ticket checking process, the third-party scenic area backend 330 can establish a communication connection with the gate 200 and the ticketing system 320, and optionally, it can also establish a communication connection with the electronic device 100. In some embodiments, the third-party scenic area backend 330 can receive authentication information and a random number r sent by the gate 200, and authenticate the authentication information based on a preset encryption algorithm model F1 and the random number r, determining whether the authentication code carried in the authentication information is consistent with the authentication code calculated by the third-party scenic area backend 330. If the authentication codes are inconsistent, the authentication is deemed to have failed. If the authentication codes are consistent, the third-party scenic area backend 330 can determine account information 1 based on the authentication information and send an order query request carrying account information 1 to the ticketing system 320, requesting to query the order corresponding to account information 1. If the order sent by the ticketing system 320 is received, the authentication is deemed to have passed; if the order sent by the ticketing system 320 is not received, the authentication is deemed to have failed. The three-party scenic area backend 330 can also send different authentication responses to the gate 200 based on the authentication result. For example, when the authentication is successful, it sends an authentication response to the gate 200 indicating that the gate is open and allowing passage; when the authentication fails, it sends an authentication response to the gate 200 indicating that the authentication has failed.

[0135] It is understood that the embodiment shown in Figure 3D above is only an example. In the embodiments of this application, any one server in the above embodiments can also be split into multiple servers, and any two or more servers can also be merged into one server. This application does not make any limitations here. In addition, the cloud server 300 may also include more or fewer servers (or server modules) than the above embodiments, or different from the above embodiments. Each server may also have more or fewer functions than the above embodiments, or different from the above embodiments. This application does not make any limitations here either.

[0136] In some embodiments, the business system 310 may also be subdivided into different functional modules.

[0137] For example, Figure 3E shows a schematic diagram of the functional modules of a business system 310 provided in an embodiment of this application.

[0138] As shown in Figure 3E, the business system 310 may include an account cloud 311, a scenario linkage cloud 312, and an electronic invoice business cloud 313.

[0139] Account Cloud 311 can store account information for different accounts and generate corresponding OpenIDs based on accounts and project identifiers. Account Cloud 311 can receive and respond to account information retrieval requests sent by electronic device 100, query the corresponding account information, and send it back to electronic device 100. Account Cloud 311 can also provide account management services such as account registration, authentication, and account cancellation.

[0140] The scene linkage cloud 312 can be considered as the general interface of the business system 310. In some embodiments, after receiving a project identifier query request from the electronic device 100 carrying a gate device identifier (e.g., the ID of the gate 200), the scene linkage cloud 312 can determine that the current scene is an electronic ticket scene and trigger the electronic ticket business cloud 313 to query the corresponding project identifier based on the gate device identifier. In other embodiments, after receiving an account information retrieval request from the electronic device 100, the scene linkage cloud 312 can also trigger the account cloud 311 to query the corresponding account information and send the account information to the electronic device 100.

[0141] The Electronic Ticketing Service Cloud 313 can register project identifiers (such as identifiers for scenic spots, performances, competitions, gatherings, etc.), gate device identifiers, and the correspondence between project identifiers and gate device identifiers. In some embodiments, the Electronic Ticketing Service Cloud 313 can also provide validity verification services for project identifiers and / or device identifiers.

[0142] It is understood that the embodiment shown in Figure 3E is only an example. In the embodiments of this application, the business system 310 may also include more, fewer or different functional modules than the above embodiments. Alternatively, any one functional module in the above embodiments may be split into multiple functional modules, or any multiple functional modules may be merged into one functional module. This application does not limit these possibilities.

[0143] The following describes a ticket purchase process and a ticket inspection process provided by an embodiment of this application.

[0144] Figure 4A shows a schematic diagram of a ticket purchase process provided by an embodiment of this application.

[0145] As shown in Figure 4A, a ticket purchase process may include the following steps:

[0146] S401. Electronic device 100 Login account 1.

[0147] S402. Electronic device 100 receives the user's ticket purchase operation and determines the ticket purchase information 1, which includes the ticket item identifier 1, type, quantity, validity period, etc.

[0148] S403. Electronic device 100 determines the gate opening identifier 1 (OpenID_1).

[0149] OpenID_1 can be generated based on account 1 and project ID 1.

[0150] In some embodiments, after receiving a ticket purchase operation and determining the project identifier 1, the electronic device 100 can send the account 1 and the project identifier 1 to the business system 310. The business system 310 can generate an OpenID_1 based on the account 1 and the project identifier 1, and send the OpenID_1 to the electronic device 100.

[0151] S404. Electronic device 100 sends a ticket purchase request 1 to the backend of the third-party scenic spot 330. The ticket purchase request 1 includes ticket information 1 and OpenID_1.

[0152] Purchase Request 1 is used to request the purchase of the electronic ticket specified in Purchase Information 1.

[0153] S405. The back-end system 330 of the three scenic spots sends a ticket purchase request 1 to the ticketing system 320.

[0154] S406. Ticketing system 320 generates ticket information 1 based on ticket purchase request 1, and ticket information 1 is bound to OpenID_1.

[0155] Ticket information 1 may include the ticket item identifier 1, type, quantity, validity period, etc., and optionally, it may also include the frequency of ticket use, etc.

[0156] After generating ticket information 1, the ticketing system 320 can bind ticket information 1 with OpenID_1, that is, store the correspondence between ticket information 1 and OpenID_1.

[0157] S407. Ticketing system 320 sends ticket information 1 to the back-end system 330 of the third-party scenic area.

[0158] S408. The back-end system of the three scenic spots 330 sends ticket information 1 to the electronic device 100.

[0159] S409. The correspondence between the storage item identifier 1, ticket information 1 and OpenID_1 of electronic device 100.

[0160] In this way, electronic device 100 can complete the purchase of electronic tickets and store the OpenID_1 corresponding to the electronic tickets.

[0161] Figure 4B shows a schematic diagram of a ticket checking process provided in an embodiment of this application.

[0162] As shown in Figure 4B, the electronic device 100 is in PICC mode and the gate 200 is in PCD mode. After the electronic device 100 purchases a ticket using the method shown in Figure 4A, the ticket checking process may include the following steps:

[0163] S410. Electronic device 100 enters the radio frequency field of gate 200.

[0164] S411. The gate 200 sends an opening identifier acquisition request to the electronic device 100. The opening identifier acquisition request includes the ID of the gate 200 and / or the item identifier 1.

[0165] The Open ID Acquisition Request is used to request the Open ID (OpenID) corresponding to the electronic ticket that can be verified by the gate 200.

[0166] The gate opening identifier retrieval request includes the ID of gate 200 and / or item identifier 1. Item identifier 1 is used to indicate the item identifier of the electronic ticket verified by gate 200.

[0167] S412. Electronic device 100 determines OpenID_1 based on the ID of gate 200 and / or item identifier 1.

[0168] In some embodiments, the gate opening identifier acquisition request includes item identifier 1. In this case, the electronic device 100 can determine OpenID_1 based on item identifier 1.

[0169] In other embodiments, the gate opening identifier acquisition request includes the ID of gate 200. In this case, electronic device 100 can determine the item identifier 1 corresponding to the ID of gate 200 from business system 310 based on the ID of gate 200. Then, electronic device 100 can determine OpenID_1 based on item identifier 1.

[0170] S413. Electronic device 100 sends an opening identifier acquisition response to gate 200, the opening identifier acquisition response including OpenID_1.

[0171] S414. The gate 200 sends a verification request to the ticketing system 320, which includes OpenID_1.

[0172] The verification request is used to request the ticketing system to verify whether OpenID_1 is bound to ticket information.

[0173] S415. Ticketing system 320 retrieves the corresponding ticket information based on OpenID_1.

[0174] S416. Ticketing system 320 sends verification response 1 to gate 200. Verification response 1 is used to instruct gate 200 to open the gate and allow passage.

[0175] S417. Gate 200 opens to allow passage.

[0176] The gate 200 can receive and respond to the verification response 1, and open the gate to allow passage.

[0177] Purchasing tickets using the method shown in Figure 4A and checking tickets using the method described in Figure 4B can improve ticket checking efficiency. However, if an unauthorized device impersonates the gate and touches electronic device 100, it can steal OpenID_1 and pass through gate 200 using the stolen OpenID_1. This results in poor security during the ticket checking process, making it easy for users' purchased electronic tickets to be fraudulently used, leading to a poor user experience.

[0178] This application provides a ticket verification method. An electronic device 100 can communicate with a turnstile 200 based on NFC technology, receiving a random number *r* and the device identifier (ID) of the turnstile 200. The electronic device 100 can determine whether an order token corresponding to the turnstile 200's ID exists based on the turnstile 200's ID. If an order token T0 corresponding to the turnstile 200's ID exists, the electronic device 100 can encrypt the order token T0 based on an encryption algorithm model F1 and the random number *r* to obtain authentication information. This authentication information and the random number *r* are then sent to the turnstile 200, which verifies whether the random number *r* sent by the electronic device 100 matches the random number generated by the turnstile 200. If the two random numbers do not match, authentication is considered failed; if they match, the authentication information can be verified through a third-party scenic area backend 330 and a ticketing system 320. Upon successful authentication, the electronic device 100 receives a ticket verification success notification from the turnstile 200, indicating that the electronic ticket has been successfully verified. In the event of authentication failure, electronic device 100 can receive a ticket failure notification sent by gate 200, which indicates that the ticket check has failed.

[0179] Using the ticket checking method provided in this application, even if an unauthorized device impersonates the gate and touches electronic device 100, it can only obtain encrypted authentication information; however, due to the lack of a corresponding encryption / decryption algorithm, the unauthorized device cannot steal the order token. Furthermore, since the random number r is temporarily generated by gate 200 each time a ticket is checked, gate 200 can also determine whether the electronic device has changed during the interaction process based on the consistency of the random number. This improves the security of the ticket checking process and protects the user's ticket security.

[0180] The following describes a ticket purchasing process provided by an embodiment of this application.

[0181] Figure 5 shows a schematic diagram of a ticket purchase process provided in an embodiment of this application.

[0182] As shown in Figure 5, the electronic device 100 may include an electronic ticketing service 11, which can be used to purchase electronic tickets. During the process of a user purchasing tickets through the electronic device 100, the interaction between the electronic ticketing service 11 and the business system 310, the third-party scenic area backend 330, and the ticketing system 320 may include the following steps:

[0183] S501. Electronic Ticketing Service 11 Login Account 1.

[0184] In some embodiments, account 1 may be the account used by electronic device 100 to log in. When electronic device 100 logs in to account 1, the login account for multiple applications and / or mini-programs in electronic device 100 is account 1.

[0185] S502. Electronic ticketing service 11 sends an account information retrieval request to business system 310. The account information retrieval request includes account 1.

[0186] The account information retrieval request is used to request the business system 310 to send account information 1 of account 1 to the electronic device 100. The specific content of account information 1 can be found in the relevant description in step S503 below.

[0187] In some embodiments, after logging into account 1 in the electronic ticketing service 11, the electronic ticketing service 11 may send an account information retrieval request to the business system 310. In other embodiments, the electronic ticketing service 11 may also send an account information retrieval request to the business system 310 after logging into account 1 and receiving the ticket purchase operation in step S504 below. That is, steps S502-S503 may be executed before or after step S504.

[0188] In some embodiments, an account information retrieval request may include account 1.

[0189] In some other embodiments, if step S502 is executed after step S504, the account information acquisition request may also include item identifier 1 in addition to account 1. The specific description of item identifier 1 can be referred to the relevant description in step S504 below.

[0190] S503. The business system 310 sends account information 1 of account 1 to the electronic ticket service 11. Account information 1 includes gate opening identifier 1 (OpenID_1).

[0191] In some embodiments, account information may include an OpenID, and optionally, may also include any one or more of the following: a mobile phone number, an ID card number, etc. The mobile phone number may be the one provided when registering the account; the ID card number may be the one entered by the user when registering the account or when performing real-name authentication for account 1; the OpenID may be generated based on the account and the project identifier, or... It should be noted that the project identifier can be used to identify the project corresponding to the electronic ticket (e.g., scenic spot, concert, museum, event, etc.).

[0192] Account information 1 may include gate opening identifier 1 (OpenID_1).

[0193] In one possible implementation, OpenID_1 may be generated before receiving the user's ticket purchase request. In this case, after receiving the account information retrieval request, the business system 310 may generate one or more OpenIDs based on the item identifier and account 1 corresponding to one or more electronic tickets available for purchase by the electronic ticketing service 11, and send the one or more OpenIDs to the electronic ticketing service 11. The one or more OpenIDs may include OpenID_1.

[0194] In another possible implementation, OpenID_1 can be generated after receiving a user's ticket purchase request. In this case, the business system 310 can generate OpenID_1 based on the project identifier 1 and account 1 after receiving an account information retrieval request carrying project identifier 1, and send OpenID_1 to the electronic ticketing service 11.

[0195] S504. Electronic ticketing service 11 receives the user's ticket purchase operation and confirms the ticket purchase information 1, which includes the ticket item identifier 1, type, quantity, validity period, etc.

[0196] In some embodiments, the electronic ticketing service 11 in the electronic device 100 can provide electronic ticket purchase services. In this case, the electronic device 100 can use the electronic ticketing service 11 to interact with the ticketing system 320 through the third-party scenic spot backend 330 to purchase electronic tickets.

[0197] It should be noted that in some other embodiments, the electronic device 100 may also include a ticketing application 12. The ticketing application 12 may include a self-developed application and / or mini-program for purchasing electronic tickets, or it may include an application and / or mini-program provided by a third party for purchasing electronic tickets. The electronic device 100 may also use the ticketing application 12 to interact with the ticketing system 320 through the third-party scenic spot backend 330 to purchase electronic tickets. In the case of purchasing tickets through the ticketing application 12, in the embodiment shown in FIG. 5, the steps S501-S505 performed by the electronic ticketing service 11 may also be performed by the ticketing application 12, which is not limited here.

[0198] The electronic ticketing service 11 can determine the ticket purchase information 1 based on the user's ticket purchase operation. In some embodiments, the ticket purchase information 1 may include, but is not limited to, the item identifier 1, type, quantity, and validity period of the tickets purchased by the user. Optionally, the ticket purchase information 1 may also include the frequency of ticket use (e.g., single-entry pass, annual pass, monthly pass, etc.). The item identifier 1 can be used to identify the item corresponding to the electronic ticket (e.g., zoo, concert, museum, etc.); the number of tickets indicates the number of tickets purchased in this ticket purchase operation; the type of ticket may include any one or more of the following: adult ticket, student ticket, child ticket, senior ticket, family ticket, etc.; the validity period indicates the usage period of the electronic ticket. It should be noted that when a user purchases multiple electronic tickets in a single transaction, the ticket type may include one or more types. In this case, the number of tickets can also be used to indicate the quantity of each type of ticket, such as 2 adult tickets and 1 student ticket.

[0199] S505. Electronic ticketing service 11 sends a ticket purchase request 2 to the back-end of the third-party scenic spot 330. The ticket purchase request 2 includes ticket purchase information 1 and account information 1.

[0200] In some embodiments, the ticket purchase request 2 may include ticket purchase information 1 and account information 1. Optionally, the ticket purchase request 1 may also include an item identifier 1.

[0201] Purchase request 2 can be used to request the purchase of the electronic ticket indicated by purchase information 1 for the account indicated by account information 1.

[0202] S506. The back-end system 330 of the three scenic spots sends a ticket purchase request to the ticketing system 320.

[0203] S507. Ticketing system 320 generates order 1 based on ticket purchase request 2. Order 1 includes order number, account information 1, and ticket purchase information 1.

[0204] After generating order 1, ticketing system 320 can also store order 1.

[0205] For example, Table 1 shows one or more orders stored in a ticketing system 320 provided in an embodiment of this application.

[0206] Table 1

[0207] As shown in Table 1, the ticketing system 320 can store one or more orders, where each order may include an order number, ticket purchase information, and account information. For example, order 1 with order number D1 includes ticket purchase information 1 and account information 1; order 2 with order number D2 includes ticket purchase information 2 and account information 2.

[0208] It is understood that the embodiments shown in Table 1 are merely exemplary. In the embodiments of this application, the ticketing system 320 may store more, fewer, or different orders than those shown in Table 1 above, and this application does not limit the scope of the embodiments.

[0209] It should be noted that, since order 1 includes account information 1, in some embodiments, the ticketing system 320 can use any one or more of the account information 1 (such as OpenID_1, mobile phone number, ID card number, etc.) as an index to query the order 1 corresponding to account information 1.

[0210] S508. Ticketing system 320 sends order 1 to the back-end system 330 of the third-party scenic spot.

[0211] S509. The three-party scenic area backend 330 generates an order token T0 based on order 1 and the preset encryption algorithm model F0.

[0212] The encryption algorithm model F0 can be a preset encryption algorithm model in the third-party scenic spot backend 330. The input of the encryption algorithm model F0 can be an order, and the output can be the order token corresponding to that order.

[0213] In one possible implementation, the encryption algorithm model F0 may include a public-private key pair, and the third-party scenic spot backend 330 can encrypt order 1 based on the public-private key pair to obtain order token T0.

[0214] In another possible implementation, the encryption algorithm model F0 may include a PKI certificate, and the third-party scenic spot backend 330 can encrypt order 1 based on the PKI certificate to obtain order token T0.

[0215] The following is an example of the structure format of an order token.

[0216] For example, the order token can be in the format of a JSON Web Token, with the following structure:

[0217] {

[0218] "alg":"" / / Algorithm

[0219] "kid": Key number

[0220] "typ": "JWT" ​​ / / type

[0221] }

[0222] {

[0223] "iss": Ticketing System XXXX;

[0224] “sub”: “Scenic Area Name XXXXXX”;

[0225] Order number: "...";

[0226] Ticket Type: "Individual / Group..."

[0227] "Number of uses": Single use / Monthly pass / Annual pass...

[0228] “iat”: Date of Issuance

[0229] “nbf”: “Activation Date”;

[0230] "exp": "Expiration date";

[0231] "telephone number":"";

[0232] "openID": ";

[0233] "UnionId": "; / / Optional

[0234] }

[0235] {

[0236] "sign"

[0237] }

[0238] As can be seen from the above embodiments, the order token may include the name of the encryption algorithm (e.g., public / private key, PKI certificate, etc.), key number, format type (e.g., JSON Web Token format, etc.), order number, ticketing information (e.g., ticketing system identifier, scenic spot name, ticket type, number of uses, issuance date, activation date, expiration date, etc.), account information (e.g., OpenID, phone number, etc.).

[0239] It is understood that the embodiments described herein are merely illustrative of a structural format for an order token. In the embodiments of this application, the order token may also adopt a different structural format than the above embodiments, or may include more, less, or different content than the above embodiments. This application does not impose any limitations on this.

[0240] S510. The back-end system of the three scenic spots 330 sends an order token T0 to the electronic ticketing service 11.

[0241] S511. Electronic Ticketing Service 11 stores the correspondence between order token T0 and project identifier 1.

[0242] The electronic ticketing service 11 can store the order token T0 and the corresponding item identifier 1 for this transaction. Item identifier 1 is the item identifier corresponding to the electronic ticket purchased this time. In some embodiments, the electronic ticketing service 11 storing the correspondence between the order token T0 and the item identifier 1 may mean that the electronic ticketing service 11 stores the correspondence between the order token T0 and the item identifier 1 in the NFC security module 16. This can improve the storage security of the order token T0.

[0243] In one possible implementation, the electronic ticket service 11 can determine the item identifier 1 corresponding to the electronic ticket purchased this time based on the ticket purchase operation in step S504 above.

[0244] In another possible implementation, the ticket purchase response that is not in S507 can also carry item identifier 1. In this case, the electronic ticket service 11 can also determine the item identifier 1 corresponding to the electronic ticket purchased this time based on the ticket purchase response.

[0245] For example, Table 2 shows the correspondence between order tokens and project identifiers stored in an electronic ticketing service 11 (or NFC security module 16) provided in an embodiment of this application.

[0246] Table 2

[0247] As shown in Table 2, the electronic ticketing service 11 can store the correspondence between order tokens and item identifiers. For example, the item identifier corresponding to order token T0 is PID1; the item identifier corresponding to order token T1 is PID2.

[0248] It is understood that the embodiments shown in Table 2 are merely illustrative examples illustrating that the electronic ticketing service 11 can store the correspondence between order tokens and item identifiers. In the embodiments of this application, the electronic ticketing service 11 may store more, fewer, or different order tokens, item identifiers, and correspondences between order tokens and item identifiers than the embodiments shown in Table 2 above. This application does not impose any limitations on these.

[0249] Using the ticketing method provided in this application embodiment, the electronic device 100 can interact with the third-party scenic spot backend 330 and the ticketing system 320 through the electronic ticketing service 11 to complete the ticket purchase, obtain the order token T0, and store the order token T0 locally on the electronic device 100.

[0250] In some application scenarios, when electronic device 100 purchases tickets through some ticketing applications provided by third parties, electronic device 100 can also interact with ticketing system 320 through third-party server 500 of the ticketing application to complete the ticket purchase without going through the third-party scenic spot backend 330.

[0251] For example, Figure 6 shows another ticket purchase process diagram provided by an embodiment of this application.

[0252] As shown in Figure 6, the electronic device 100 includes a ticketing application 12. The specific process of the electronic device 100 purchasing tickets from the ticketing system 320 through a third-party server 500 may include the following steps:

[0253] S601. Ticketing Application 12 Login Account 1.

[0254] In the embodiment shown in Figure 6, ticketing application 12 refers to a ticketing application provided by a third party.

[0255] In some embodiments, the login account 1 of the ticketing application 12 may refer to the login account 1 of the electronic device 100. In this case, multiple applications / mini-programs installed on the electronic device 100 can all be regarded as login account 1.

[0256] In other embodiments, the ticketing application 12 can log in to account 1, or the ticketing application 12 can log in to account 1.

[0257] S602. Ticketing application 12 obtains account information 1 for account 1.

[0258] In some embodiments, after logging into account 1, the ticketing application 12 can obtain account information 1 corresponding to account 1 from the business system 310. The specific content and acquisition method of account information 1 can be referred to by analogy with the relevant description in the embodiment shown in Figure 5 above, and will not be repeated here.

[0259] S603. Ticketing application 12 receives the user's ticket purchase operation and confirms the ticket purchase information 2, which includes the ticket item identifier 1, type, quantity, validity period, etc.

[0260] The details of step S603 can be found in step S504 shown in Figure 5 above, and will not be repeated here.

[0261] S604. Ticketing application 12 sends a ticket purchase request 3 to a third-party server 500. The ticket purchase request 3 includes ticket purchase information 2 and account information 1.

[0262] In the embodiment shown in Figure 6, the third-party server 500 refers to the server corresponding to the ticketing application 12, that is, the server provided by the third party that provides the ticketing application 12.

[0263] S605. Third-party server 500 sends a ticket purchase request to ticketing system 320.

[0264] S606. Ticketing system 320 generates order 2 based on ticket purchase request 3.

[0265] S607. Ticketing system 320 sends order 2 to third-party server 500.

[0266] The specific details of steps S605-S607 can be found in the relevant content of steps S506-S508 shown in Figure 5 above, and will not be repeated here.

[0267] S608. Third-party server 500 sends a ticket purchase success notification to ticketing application 12.

[0268] After receiving order 2, the third-party server 500 can send a ticket purchase success notification to the ticketing application 12. The ticket purchase success notification is used to notify the electronic device 100 that the ticket purchase was successful.

[0269] S609. Ticketing Application 12 outputs a ticket purchase success message, which is used to notify the user that the ticket purchase was successful.

[0270] The ticketing application 12 can output a successful ticket purchase notification through one or more methods, such as display screen, voice broadcast, vibration, and indicator light flashing.

[0271] It is understood that the embodiment shown in Figure 6 is only an example. In the embodiments of this application, the electronic device 100 may also purchase tickets in a different manner than that shown in Figure 6. This application does not limit this.

[0272] It should be noted that if tickets are purchased using the method described in Figure 6 above, the corresponding order token is not stored in the third-party scenic area's backend 330 after the purchase is completed. The third-party scenic area's backend 330 can obtain the corresponding order from the ticketing system 320 during the ticket checking process of the electronic device 100, generate the corresponding order token based on the order, and then send the order token to the electronic device 100. For details, please refer to the relevant description in the ticket checking process below, which will not be elaborated here.

[0273] The method shown in Figure 6 allows for ticket purchases through third-party ticketing applications and third-party servers 500 and ticketing systems 320, providing a wider range of ticketing options and making the process more convenient.

[0274] The following describes the flow of the ticket checking method provided in the embodiments of this application.

[0275] Figure 7 shows a schematic flowchart of a ticket checking method provided in an embodiment of this application.

[0276] As shown in Figure 7, the electronic device 100 may include an electronic ticketing service 11 and an NFC protocol stack 14. When the electronic device 100 enters the radio frequency field of the gate 200, the electronic device 100 may be in PICC mode and the gate 200 may be in PCD mode. During the ticket checking process, the interaction between the electronic device 100, the gate 200, and the ticketing system 320 may include the following steps:

[0277] S701. Electronic device 100 enters the radio frequency field of gate 200.

[0278] In some embodiments, electronic device 100 entering the radio frequency field of gate 200 may mean that electronic device 100 approaches or touches the card swiping area 203 of gate 200.

[0279] S702. The gate 200 sends a probe frame.

[0280] The Probe frame can be used to indicate that the gate 200 supports a specified NFC protocol, such as the first protocol. The gate 200 can send Probe frames periodically.

[0281] After receiving a probe frame, the S703.NFC protocol stack 14 sends a probe ACK frame.

[0282] The Probe ACK can be used to indicate that the electronic device 100 supports the specified NFC protocol (e.g., the first protocol) indicated by the Probe frame.

[0283] If the electronic device 100 does not support the specified NFC protocol indicated by the Probe frame (e.g., the first protocol), the electronic device 100 may not send a Probe ACK frame.

[0284] NFC protocol stack 14 may refer to the NFC protocol stack 14 in the embodiments shown in Figures 3B and 3C above. It should be noted that in some embodiments, step S703, as well as steps S705 and S706 below, can be executed by the access layer in NFC protocol stack 14, that is, the access layer processes the received data and controls the data to be sent.

[0285] S704. After receiving the Probe ACK frame, the gate 200 sends a Notify frame, which carries the device characteristic information of the gate 200.

[0286] The device feature information may include the device service identifier (SID) and the device organization identifier (also known as the NFC device organization unique identifier (ND_OUI)).

[0287] Optionally, device characteristic information may include Service Identifier (SID), Device Organization Identifier (ND_OUI), and Device Group Identifier (also known as NFC Device Group Identifier (ND_GID)).

[0288] 1. The Service Identifier (SID) can be used to indicate the type of NFC service supported by the gate 200 on the basis of NFC functionality.

[0289] In one possible implementation, the NFC service type may include a primary service type and a sub-service type. Therefore, the service identifier may include a primary service identifier and a sub-service identifier. The primary service identifier can be used to indicate the primary service type supported by the gate 200, and the sub-service identifier can be used to indicate the sub-service types supported by the gate 200 under a certain primary service type. The primary service type may include electronic tickets; optionally, the primary service type may also include one or more of the following: access control, keys, transportation, banking, digital currency, digital certificates, codeless payment, wireless charging, contactless payment, multi-functional cards, etc. The sub-service type corresponding to electronic tickets may include electronic ticketing for park entry services.

[0290] The main service identifier can occupy 1 byte, and the sub-service identifier can occupy 1 byte. For example, Table 3 shows the correspondence between the device main service identifier, the device sub-service identifier, and the sub-service type when the main service type is electronic ticket, according to an embodiment of this application.

[0291] Table 3

[0292]

[0293] As shown in Table 3, when the main service type is electronic ticketing, the main service identifier of the device can be 0x08; if the sub-service type is electronic ticketing for park access, the sub-identifier of the device can be 0x01; if a new sub-service type needs to be added, an unused identifier can be selected from the reserved identifiers, namely 0x00, 0x02 to 0xFF, as the device sub-service identifier corresponding to the new sub-service type.

[0294] It is understood that the embodiments shown in Table 3 are only examples. In the embodiments of this application, the device service identifier may also adopt a different identifier than that in the above embodiments. In addition, the electronic ticket may also include more, fewer or different sub-service types and device sub-service identifiers than those in the above embodiments. This application does not limit this.

[0295] 2. The Device Organization Identifier (ND_OUI) can be used to indicate the manufacturer providing NFC services using the turnstile 200, such as scenic spot A, theater B, or museum C. The Device Organization Identifier can be managed by a unified standard organization, and different manufacturers and commercial organizations can apply for and use it according to their own needs.

[0296] 3. The Device Group Identifier (ND_GID) can be used to indicate the group to which the NFC services provided by the gate 200 belong. The Device Group Identifier can be assigned according to the purpose and location of the gate 200. Different NFC services can be assigned to different groups.

[0297] The S705.NFC protocol stack 14 determines that the service type of the gate 200 is electronic ticket based on the device feature information.

[0298] In some embodiments, after the access layer of the NFC protocol stack 14 determines that the service type of the gate 200 is electronic ticket, the access layer can report the service type of the gate 200 to the application protocol layer.

[0299] The S706 NFC protocol stack 14 sends a Notify ACK frame to the gate 200.

[0300] After receiving the Notify frame, the NFC protocol stack 14 can send a Notify ACK frame to the gate 200. The Notify ACK frame is used to notify the gate 200 that the electronic device 100 has received the Notify frame.

[0301] It should be noted that step S706 can be executed after step S704. Step S706 can be executed synchronously with step S705, or step S705 can be executed first and then step S706, or step S706 can be executed first and then step S705. This application does not limit the execution order of steps S705 and S706.

[0302] S707. Turnstile 200 generates a random number r.

[0303] The gate 200 can store one or more random number generation algorithms. After receiving a Notify ACK frame, the gate 200 can generate a random number r using the random number generation algorithm.

[0304] After generating a random number r, the gate 200 can temporarily store the random number r.

[0305] In some embodiments, after receiving a Notify ACK frame, the gate 200 can negotiate application layer transmission parameters with the electronic device 100. For example, after receiving a Notify ACK frame, the gate 200 can send a parameter negotiation command to the NFC protocol stack 14; after receiving the parameter negotiation command, the NFC protocol stack 14 sends a parameter negotiation response to the gate 200. The parameter negotiation command can be a command frame, and the parameter negotiation response can be a response frame. These parameter negotiation commands and responses can be used by the gate 200 and the electronic device 100 to negotiate data transmission parameters at the application layer. These data transmission parameters can include one or more of the following: maximum transmission rate and maximum data transmission length during application layer data transmission. In this way, the gate 200 and the electronic device 100 can negotiate application layer transmission parameters, and the gate 200 can interact with the electronic ticketing service 11 through the NFC protocol stack 14 based on the negotiated transmission parameters.

[0306] It should be noted that the gate 200 may negotiate the transmission parameters of the application protocol layer with the electronic device 100 while executing S707; or, the gate 200 may negotiate the transmission parameters of the application protocol layer with the electronic device 100 after executing S707; or, the gate 200 may negotiate the transmission parameters of the application protocol layer with the electronic device 100 before executing S707.

[0307] In other embodiments, the gate 200 and the electronic device 100 may also have preset transmission parameters for the application protocol layer. In this case, the gate 200 and the electronic device 100 may not negotiate the transmission parameters for the application protocol layer.

[0308] S708. The gate 200 sends an authentication request 1 to the electronic ticketing service 11 via the NFC protocol stack 14. The authentication request 1 includes a random number r.

[0309] In some embodiments, authentication request 1 may include a random number r. Furthermore, the authentication request may also include the device identifier (ID) of the gate 200 and / or include an item identifier 1. The item identifier 1 indicates the item (e.g., scenic area A1, scenic area A2, event C1, etc.) corresponding to the electronic ticket used by the gate 200 for verification.

[0310] S709. Electronic Ticketing Service 11 determines whether an order token can be found based on authentication request 1.

[0311] In some embodiments, the authentication request 1 may carry an item identifier 1. In this case, the electronic ticketing service 11 can query the order token corresponding to the item identifier 1 based on the item identifier 1.

[0312] In some embodiments, the authentication request 1 does not carry item identifier 1. In this case, the electronic ticketing service 11 can query the business system 310 for the item identifier 1 corresponding to the gate 200 based on the gate 200's ID, and then query the order token corresponding to the item identifier 1 based on the item identifier 1. The specific method by which the electronic ticketing service 11 queries the business system 310 for the item identifier 1 corresponding to the gate 200 based on the gate 200's ID can be found in the relevant description in the embodiment shown in Figure 8 below, and will not be detailed here.

[0313] In one possible implementation, the electronic ticketing service 11 can query locally whether there is an order token corresponding to the project identifier 1.

[0314] In another possible implementation, the electronic ticketing service 11 can also query whether there is an order token corresponding to the project identifier 1 in the ticketing system 320 and / or the third-party scenic spot backend 330.

[0315] In another possible implementation, the electronic ticketing service 11 can first check locally whether there is an order token corresponding to project identifier 1; if there is no order token corresponding to project identifier 1 locally, the electronic ticketing service 11 can check in the third-party scenic spot backend 330 whether there is an order token corresponding to project identifier 1.

[0316] For example, one specific way for the electronic ticketing service 11 to determine whether an order token can be found based on the project identifier 1 can be referred to the relevant description in the embodiments shown in Figures 8-9 below, which will not be detailed here.

[0317] If the electronic ticketing service 11 cannot find the order token, the electronic ticketing service 11 can perform the following step S710.

[0318] If the electronic ticketing service 11 can find the order token, the electronic ticketing service 11 can perform the following step S711.

[0319] S710. Electronic ticketing service 11 outputs a ticket purchase prompt, which is used to prompt the user to purchase an electronic ticket that can be verified by the gate 200.

[0320] If an order token cannot be found based on project identifier 1, it is determined that electronic device 100 has not purchased an electronic ticket that can be verified by gate 200. At this time, a ticket purchase prompt can be output to remind the user to purchase a ticket.

[0321] In some embodiments, the ticket purchase prompts output by the electronic ticketing service 11 may also include a ticket purchase interface, which can be used to purchase electronic tickets that can be verified by the gate 200.

[0322] S711. Electronic Ticketing Service 11 generates authentication information based on the order token T0 and the random number r using a preset encryption algorithm model F1.

[0323] The encryption algorithm model F1 can be a preset encryption algorithm model. In some embodiments, the encryption algorithm model F1 can be obtained by coupling one or more functions, which may include, but are not limited to, any one or more of the following: hash function, SM3 function, HKDF function, HMAC-SHA256 function, etc.

[0324] In some embodiments, the authentication information may include credential index H0 and authentication code Mac0. Optionally, the authentication information may also include the ID of the gate 200 and / or the authentication type.

[0325] For example, one specific method by which the electronic ticketing service 11 generates authentication information based on the order token T0 and the random number r using a preset encryption algorithm model F1 can be referred to the relevant description in the embodiment shown in Figure 10 below, which will not be detailed here.

[0326] S712. Electronic ticketing service 11 sends authentication response 1 to gate 200 via NFC protocol stack 14. Authentication response 1 includes authentication information and random number r.

[0327] S713. The gate 200 determines whether it has stored the random number r carried in the authentication response 1 before receiving the authentication response 1.

[0328] After receiving authentication response 1, gate 200 can determine whether it has stored the random number r carried in authentication response 1 locally.

[0329] If the gate 200 has already stored a random number r locally before receiving the authentication response 1, it means that the random number r carried in the authentication response 1 is consistent with the random number r generated by the gate 200 in step S707 above. That is, the electronic device that interacts with the electronic device 100 in steps S701-S712 is the gate 200. In this case, the gate 200 can execute the following step S714.

[0330] If the gate 200 does not have a random number r locally before receiving the authentication response 1, it means that the random number r carried in the authentication response 1 is different from the random number generated by the gate 200 in step S707 above. That is, the electronic device that interacts with the electronic device 100 in steps S701-S712 is not the gate 200. In this case, the gate 200 can execute the following step S723.

[0331] S714. The gate 200 sends authentication request 2 to the backend of the third-party scenic area 330. Authentication request 2 includes authentication information and a random number r.

[0332] In some embodiments, the authentication request 2 may also include the ID of the gate 200.

[0333] In some embodiments, the authentication information may include credential index H0 and authentication code Mac0. Optionally, the authentication information may also include the ID of the gate 200 and / or the authentication type.

[0334] S715.Turret 200 deleter.

[0335] In some embodiments, after performing step S714, the gate 200 may delete r. This ensures that the value of the random number r used for each ticket check is different.

[0336] In other embodiments, after generating the random number r, the gate 200 can set a timer with a preset duration (e.g., 3 minutes, 5 minutes, or 10 minutes); when the timer countdown ends, the gate 200 can delete the random number r. This ensures the timeliness of the random number r.

[0337] S716. The backend of the three scenic spots 330 determines whether the authentication information can pass the authentication based on the preset encryption algorithm model F1 and the random number r.

[0338] In some embodiments, the third-party scenic area backend 330 may also pre-store an encryption algorithm model F1. This encryption algorithm model F1 is the same as the encryption algorithm model F1 pre-stored by the electronic device 100.

[0339] For example, the specific method by which the backend of the third-party scenic spot 330 determines whether the authentication information can pass the authentication can be referred to the relevant description in the embodiment shown in Figure 11 below, which will not be detailed here.

[0340] If the backend system of the three scenic spots confirms that the authentication information can pass the authentication, then the following step S717 can be executed.

[0341] If the backend system of the three scenic spots determines that the authentication information cannot pass the authentication, then the following step S722 can be executed.

[0342] S717. The backend of the three scenic area 330 sends authentication response 2 to the gate 200. Authentication response 2 is used to instruct the gate 200 to open the gate and allow passage.

[0343] S718. Gate 200 opens.

[0344] After receiving authentication response 2, the gate 200 can determine that the authentication information has been authenticated. In response to authentication response 2, the gate 200 can open the gate to allow passage.

[0345] S719. The turnstile 200 sends a ticket check success notification to the electronic ticketing service 11 via the NFC protocol stack 14.

[0346] The ticket check success notification can be used to notify users of successful ticket check for electronic tickets.

[0347] S720. Electronic ticketing service 11 outputs a ticket check success message, which is used to notify the user that the ticket check was successful.

[0348] It should be noted that the electronic ticket service 11 can execute steps S720 and S721 simultaneously, or it can execute step S720 first and then step S721, or it can execute step S721 first and then step S720. This application does not limit the specific execution order of steps S720 and S721.

[0349] S721. Electronic Ticketing Service 11 Delete Order Token T0.

[0350] In one possible implementation, after receiving a successful ticket check notification, the electronic ticket service 11 can delete the locally stored order token T0.

[0351] In another possible implementation, after receiving a successful ticket check notification, the electronic ticket service 11 can also add a verified mark to the order token T0. The verified mark is used to indicate that the electronic ticket corresponding to the order token T0 has been verified.

[0352] S722. The backend of the three scenic area 330 sends authentication response 3 to the gate 200. Authentication response 3 is used to indicate authentication failure.

[0353] S723. The gate 200 sends a ticket check failure notification to the electronic ticket service 11 via the NFC protocol stack 14.

[0354] S724. Electronic Ticketing Service 11 outputs an authentication failure message. The authentication failure message is used to inform the user that authentication has failed and the user cannot pass through the gate.

[0355] It is understood that the embodiment shown in Figure 7 is only an example. In the embodiments of this application, the ticket checking method may also include more, fewer, or different steps than the above embodiments. For example, before sending authentication information to the gate 200, the electronic device 100 and the gate 200 perform security authentication, or before sending authentication information to the gate 200, the electronic device 100 verifies whether the ID of the gate 200 is valid, etc. This application does not limit it here.

[0356] Using the ticket checking method provided in this application, when the electronic device 100 enters the radio frequency field of the gate 200, the electronic device 100 can encrypt the order token based on a random number randomly generated by the gate 200 to obtain authentication information, and send the authentication information and the random number to the gate 200. The gate 200 can determine whether to authenticate the authentication information based on whether the random number sent by the electronic device 100 matches the random number it generates. If the random number sent by the electronic device 100 matches the random number it generates, the gate 200 can authenticate the authentication information through the third-party scenic area backend 330, and determine whether to open the gate based on the authentication response sent by the third-party scenic area backend 330. In this way, during the interaction between the electronic device 100 and the gate 200, the electronic device 100 sends encrypted authentication information. Even if an unauthorized device impersonates the gate and obtains the authentication information, it cannot reconstruct the order token based on the authentication information, and therefore cannot steal the order token, thus improving the security of electronic tickets.

[0357] The following describes the specific process of determining whether an order token corresponding to the ID of the gate 200 exists in an electronic ticketing service 11 provided in an embodiment of this application.

[0358] Figure 8 shows a flowchart illustrating the process of determining whether an order token corresponding to the ID of the gate 200 exists in an electronic ticketing service 11 provided in an embodiment of this application.

[0359] As shown in Figure 8, the electronic device 100 is in PICC mode. The electronic device 100 may include an electronic ticketing service 11. The specific process by which the electronic ticketing service 11 determines whether there is an order token corresponding to the ID of the gate 200 may include the following steps:

[0360] S801. Electronic Ticketing Service 11 determines that the ID of the gate 200 corresponds to the project identifier 1.

[0361] In some embodiments, the authentication request 1 in step S808 shown in FIG8 above may carry the item identifier 1 corresponding to the ID of the gate 200. In this case, the electronic ticketing service 11 may determine the item identifier corresponding to the ID of the gate 200 as item identifier 1 based on the received authentication request 1.

[0362] In other embodiments, after receiving the authentication request 1 carrying the ID of the gate 200, the electronic ticketing service 11 can obtain the item identifier corresponding to the ID of the gate 200 from the business system 310. It should be noted that the business system 310 may register the correspondence between the item identifier and the gate ID.

[0363] For example, Table 4 shows the correspondence between project identifiers and gate IDs stored in a business system 310 provided in an embodiment of this application.

[0364] Table 4

[0365] As shown in Table 4, the business system 310 can store the correspondence between project identifiers and gate IDs, where each project identifier can correspond to one or more gate IDs. For example, the gate IDs corresponding to project identifier PID1 can include ID1, ID2, and ID3; the gate IDs corresponding to project identifier PID2 can include ID4.

[0366] It is understood that the embodiments shown in Table 4 are only examples. In the embodiments of this application, the business system 310 may store more or fewer project identifiers, gate IDs, and correspondences between project identifiers and gate IDs than the above embodiments. This application does not limit this.

[0367] Thus, after receiving authentication request 1 carrying the ID of gate 200, electronic ticketing service 11 can send an item identifier query request to business system 310. The item identifier query request can include the ID of gate 200 and can be used to query the item identifier corresponding to the ID of gate 200. Then, electronic ticketing service 11 can determine the item identifier 1 corresponding to the ID of gate 200 based on the item identifier query response sent by business system 310.

[0368] S802. Electronic Ticketing Service 11 Determines whether an order token corresponding to project identifier 1 exists locally.

[0369] After determining that the ID of the gate 200 corresponds to the item identifier 1, the electronic ticketing service 11 can query whether an order token corresponding to item identifier 1 exists locally. In some embodiments, the order token is stored in the NFC security module 16. In this case, the electronic ticketing service 11 can query and read the corresponding order token from the NFC security module 16 based on item identifier 1.

[0370] If the electronic ticketing service 11 determines that an order token corresponding to item identifier 1 exists locally, the electronic ticketing service 11 can perform the following step S808.

[0371] If the electronic ticketing service 11 determines that there is no order token corresponding to item identifier 1 locally, the electronic ticketing service 11 can perform the following step S803.

[0372] S803. Electronic ticketing service 11 sends a token acquisition request to the backend of the third-party scenic spot 330. The token acquisition request includes account information 1.

[0373] If the order token corresponding to project identifier 1 does not exist locally, the electronic ticketing service 11 can determine whether it can obtain the order token corresponding to the account logged in by the electronic ticketing service 11 from the third-party scenic spot backend 330 based on project identifier 1.

[0374] In some embodiments, the electronic ticketing service 11 may send a token acquisition request to the third-party scenic spot backend 330. The token acquisition request may include account information 1, which is the account information of the account currently logged into by the electronic ticketing service 11. Optionally, the token acquisition request may also include project identifier 1.

[0375] It should be noted that, in some embodiments, the third-party scenic area backend 330 may only manage the purchase and verification of electronic tickets for one project, and the project identifier for that project may be project identifier 1. In this case, the electronic ticket service 11 may send a token acquisition request carrying account information 1 to the third-party scenic area backend 330 based on project identifier 1. The token acquisition request is used to request the order token corresponding to account information 1.

[0376] In other embodiments, the third-party scenic area backend 330 can manage the purchase and verification of electronic tickets for multiple projects, and the project identifiers for these multiple projects may include project identifier 1. In this case, the electronic ticket service 11 can send a token acquisition request carrying account information 1 and project identifier 1 to the third-party scenic area backend 330 based on project identifier 1. The token acquisition request is used to request the acquisition of the order token corresponding to account information 1 and project identifier 1.

[0377] S804. The backend of the three scenic spots determines whether the order token can be found based on account information 1.

[0378] In some embodiments, the third-party scenic spot backend 330 can query locally whether there is an order token corresponding to account information 1.

[0379] In other embodiments, if the third-party scenic area backend 330 determines that there is no order token corresponding to account information 1 locally, the third-party scenic area backend 330 can also query the ticketing system 320 to see if there is an order corresponding to account information 1. If there is an order corresponding to account information 1 in the ticketing system 320, the third-party scenic area backend 330 can generate an order token based on the order; if there is no order corresponding to account information 1 in the ticketing system 320, the third-party scenic area backend 330 can determine that there is no order token corresponding to account information 1.

[0380] In some application scenarios, if any electronic device (such as electronic device 100 or electronic device 400) has purchased an electronic ticket corresponding to project identifier 1 through the third-party scenic spot backend 330 using account 1 currently logged in on electronic device 100, then the third-party scenic spot backend 330 can store the order token corresponding to account information 1. The third-party scenic spot backend 330 can query the corresponding order token locally based on account information 1.

[0381] In other application scenarios, if any electronic device (e.g., electronic device 100 or electronic device 400) has purchased an electronic ticket corresponding to project identifier 1 using the currently logged-in account 1 of electronic device 100, and the purchase was made using a third-party ticketing application, the third-party scenic spot backend 330 may not have stored the corresponding order token. In this case, it is necessary to further query the order corresponding to account information 1 from the ticketing system 320, and determine whether there is an order token corresponding to account information 1 based on the query results.

[0382] In one possible implementation, the specific process by which the backend of the third-party scenic spot 330 determines whether the order token can be found based on account information 1 can also be referred to the relevant description in the embodiment shown in Figure 9 below.

[0383] If the third-party scenic spot backend 330 can find the order token based on account information 1, then the third-party scenic spot backend 330 can execute the following step S807.

[0384] If the third-party scenic spot backend 330 cannot find the order token based on account information 1, the third-party scenic spot backend 330 can perform the following step S805.

[0385] S805. The backend of the three scenic spots 330 sends a token acquisition response 1 to the electronic ticketing service 11. The token acquisition response 1 is used to indicate that there is no token corresponding to account information 1.

[0386] S806. Electronic Ticketing Service 11 confirms that the order token corresponding to the ID of gate 200 cannot be found.

[0387] Electronic ticketing service 11 can receive and respond to token acquisition response 1, confirming that the order token corresponding to the ID of gate 200 cannot be found.

[0388] S807. The backend of the three scenic spots 330 sends a token acquisition response 2 to the electronic ticketing service 11. The token acquisition response 2 includes the order token T0.

[0389] If the third-party scenic spot backend 330 can find the order token based on the account information 1, and the order token is the order token T0, then the third-party scenic spot backend 330 can send a token acquisition response 2 carrying the order token T0 to the electronic ticket service 11. The token acquisition response 2 is used to indicate that the order token corresponding to the account information 1 is the order token T0.

[0390] S808. Electronic Ticketing Service 11 determines that the order token corresponding to the ID of gate 200 is order token T0.

[0391] In some embodiments, the electronic ticketing service 11 may receive and respond to the token acquisition response 2 to determine that the order token corresponding to the ID of the gate 200 is the order token T0.

[0392] In some embodiments, after the electronic ticketing service 11 queries the order token T0 locally based on the project identifier 1, it can also determine that the order token corresponding to the ID of the gate 200 is the order token T0.

[0393] Using the process shown in the embodiment of Figure 8, the electronic device 100 can query the local or third-party scenic area backend 330 to see if there is an order token corresponding to the ID of the gate 200 purchased by the account currently logged into the electronic device 100. In this way, even if the electronic device 100 checking the ticket is different from the electronic device that purchased the ticket, the electronic device 100 can still obtain the order token from the third-party scenic area backend 330 to complete the ticket checking.

[0394] Figure 9 shows a schematic diagram of the process by which a third-party scenic spot backend 330 determines whether an order token can be found based on account information, according to an embodiment of this application.

[0395] As shown in Figure 9, a specific process for a third-party scenic spot backend 330 to determine whether an order token can be found based on account information may include the following steps:

[0396] S901. The backend of the three scenic spots determines whether the order token can be found locally based on account information 1.

[0397] If the order token can be found locally based on account information 1, the third-party scenic spot backend 330 can execute the following steps S906.

[0398] If the order token cannot be found locally based on account information 1, the third-party scenic spot backend 330 can perform the following steps S902.

[0399] S902. The back-end system 330 of the three scenic spots sends an order query request to the ticketing system 320. The order query request includes account information 1.

[0400] The order query request is used to request the ticketing system 320 to query the orders corresponding to account information 1, that is, to query the orders containing account information 1.

[0401] S903. Ticketing system 320 determines whether the order corresponding to account information 1 can be found.

[0402] If the order corresponding to account information 1 can be found, the ticketing system 320 can execute the following step S904.

[0403] If the order corresponding to account information 1 cannot be found, the ticketing system 320 can perform the following step S907.

[0404] S904. The ticketing system 320 sends an order query response 1 to the back-end system 330 of the third-party scenic spot. The order query response 1 includes order 1.

[0405] Order 1 is the order corresponding to account information 1 found in the ticketing system 320.

[0406] S905. The three-party scenic area backend 330 generates an order token T0 based on order 1 and the preset encryption algorithm model F0.

[0407] After receiving the order query response 1, the third-party scenic spot backend 330 can generate an order token T0 based on order 1 and the preset encryption algorithm model F0.

[0408] The specific method for generating the order token T0 in the background of the three scenic spots can be found in the relevant description in step S509 of Figure 5 above, and will not be repeated here.

[0409] S906. The backend system of the three scenic spots can confirm that the order token can be found based on the account information.

[0410] If the order token corresponding to account information 1 can be found locally, or if order query response 1 is received, the third-party scenic spot backend 330 can determine that the order token can be found based on account information 1.

[0411] S907. The ticketing system 320 sends an order query response 2 to the third-party scenic spot backend 330. The order query response 2 is used to indicate that there is no order corresponding to account information 1.

[0412] S908. The backend system of the three scenic spots has determined that the order token cannot be found based on account information 1.

[0413] Upon receiving and responding to order query response 2, the third-party scenic area backend 330 can confirm that it is unable to query the order token based on account information 1.

[0414] In this way, electronic device 100 can not only query the order token through the third-party scenic spot backend 330, but also query the order corresponding to account information 1 through the ticketing system 320. Even if the electronic device 100 used for ticket checking is different from the electronic device used for ticket purchase, electronic device 100 can download the order token again from the third-party scenic spot backend 330 to complete the ticket checking.

[0415] The following describes a specific process for determining authentication information based on an order token T0 and a random number r, as provided in an embodiment of this application.

[0416] Figure 10 illustrates a flowchart of a process for determining authentication information based on an order token T0 and a random number r, according to an embodiment of this application.

[0417] As shown in Figure 10, a specific process for determining authentication information based on order token T0 and random number r may include the following steps:

[0418] S1001. Electronic Ticketing Service 11 determines the voucher index H0 based on the order token T0.

[0419] It should be noted that step S1001 can be executed after receiving authentication request 1 in step S808 shown in Figure 8 above. In some other embodiments, step S1001 can also be executed when purchasing an electronic ticket and storing the order token T0. In this case,

[0420] In some embodiments, the credential index H0 can be the hash value of the order token T0. The electronic ticketing service 11 can calculate the hash value of the order token T0 using a hash function to obtain the credential index H0.

[0421] In other embodiments, the electronic ticketing service 11 may also determine the voucher index H0 based on the SM3 function and the order token T0. In this case, the specific calculation method of the voucher index H0 can be referred to the following formula (1). H0 = SM3(T0) Formula (1)

[0422] In formula (1), H0 can represent voucher index H0, T0 can represent order token T0, and SM3(·) can represent SM3 function.

[0423] It is understood that the embodiments described here are just two examples. In the embodiments of this application, the electronic ticket service 11 may also obtain the voucher index H0 based on the order token T0 in a different manner than the above embodiments. This application does not limit this.

[0424] S1002. Electronic ticketing service 11 determines the key IK0 based on the order token T0 and the random number r.

[0425] In some embodiments, the electronic ticketing service 11 can determine the key IK0 based on the order token T0 and the random number r using the HKDF function. For example, refer to the following formula (2): IK0 = HKDF("integrity"||T0||r) Formula (2)

[0426] In formula (2), IK0 can represent key IK0, HKDF(·) can represent HKDF function, "integrity"||·|| can represent floor function, T0 can represent order token T0, and r can represent random number r.

[0427] S1003. Electronic ticketing service 11 determines the authentication code Mac0 based on the random number r, the voucher index H0, the key IK0, and the ID of the gate 200.

[0428] In some embodiments, the electronic ticketing service 11 can determine the authentication code Mac0 based on the random number r, the credential index H0, the key IK0, and the gate ID 200 using the HMAC-SHA256 function. It should be noted that the HMAC-SHA256 function requires the authentication type to be specified.

[0429] In some embodiments, authentication request 1 may also carry an authentication type, which indicates the authentication type preset by the gate 200. In other embodiments, electronic device 100 may have a unique authentication type preset. In this case, authentication request 1 may not carry an authentication type. In this case, electronic ticketing service 11 may determine the authentication type used when determining authentication code Mac0 using the HMAC-SHA256 function based on the preset authentication type.

[0430] For example, the authentication code Mac0 can be calculated using the following formula (3). Mac0 = HMAC - SHA256(H0||ID||Authentication Type||r, IK0) Formula (3)

[0431] In formula (3), Mac0 can represent the authentication code Mac0, HMAC-SHA256(·) can represent the HMAC-SHA256 function, ID can represent the ID of gate 200, r can represent the random number r, and IK0 can represent the key IK0.

[0432] It is understood that formula (3) is only an example. In the embodiments of this application, the electronic ticketing service 11 may also determine the authentication code Mac0 in a different way than formula (3). For example, the ID of the gate 200 in formula (3) may be replaced with the item identifier 1 (i.e., the item identifier corresponding to the gate 200), or the ID of the gate 200 in formula (3) may be deleted. This application does not limit this. In some other embodiments, the electronic ticketing service 11 may also use a different function than formula (3) to calculate the authentication code Mac0. This application does not limit this either.

[0433] S1004. Electronic Ticketing Service 11 Determines authentication information, which includes authentication code Mac0 and voucher index H0.

[0434] In some embodiments, the authentication information may include authentication code Mac0 and credential index H0. Optionally, the authentication information may also include the ID of the gate 200 and / or the authentication type.

[0435] It is understood that the embodiment shown in Figure 10 is only an example. In the embodiments of this application, the electronic ticket service 11 may also use more, fewer, or different steps than the above embodiments to complete the encryption of the order token T0. This application does not limit it here.

[0436] Using the encryption method shown in Figure 10, the order token T0 can be encrypted based on a random number r and a preset encryption algorithm to obtain authentication information. In this way, even if the authentication information is sent to a device that impersonates the gate, the other end device cannot crack the order token T0, thus ensuring the security of the order token T0.

[0437] The following describes the specific process by which the backend of the three scenic spots determines whether the authentication information can pass the authentication.

[0438] Figure 11 shows a schematic diagram of the process by which a third-party scenic area backend 330 determines whether authentication information can pass authentication, according to an embodiment of this application.

[0439] As shown in Figure 11, a specific process for a third-party scenic spot backend 330 to determine whether authentication information can pass authentication may include the following steps:

[0440] S1101. The backend of the three scenic spots determines the order token T0 based on the voucher index H0.

[0441] The backend 330 of the three-party scenic area can receive the authentication request 2 sent by the gate 200. The authentication request 2 carries authentication information and a random number r. In some embodiments, the authentication information may include a credential index H0 and an authentication code Mac0. Optionally, the authentication information may also include the ID of the gate 200 and / or the authentication type.

[0442] The backend of the three-party scenic area 330 can be pre-configured with a decoding algorithm for the voucher index H0.

[0443] In some embodiments, the credential index H0 is the hash value of the order token T0, and the decoding algorithm can be a reverse hash algorithm. In this case, the third-party scenic spot backend 330 can determine the order token T0 based on the credential index H0 using a reverse hash algorithm.

[0444] In other embodiments, the voucher index H0 can also be determined by the order token T0 through the SM3 function (the specific determination method can be referred to the above formula (1)). In this case, the decoding algorithm can be the inverse function of the SM3 function. In this case, the third-party scenic spot backend 330 can determine the order token T0 based on the voucher index H0 through the decoding algorithm.

[0445] S1102. The backend of the three scenic spots 330 determines the key IK0 based on the order token T0 and the random number r.

[0446] The backend system of the three-party scenic spot 330 can determine the key IK0 based on the order token T0 and the random number r using the HKDF function. The specific calculation method of the key IK0 can be referred to the above formula (2), which will not be repeated here.

[0447] S1103. The backend of the three-party scenic area 330 determines the authentication code Mac0' based on the random number r, the credential index H0, the key IK0, and the ID of the gate 200.

[0448] In some embodiments, the third-party scenic area backend 330 can determine the authentication code Mac0' based on the random number r, credential index H0, key IK0, and gate ID 200 using the HMAC-SHA256 function. The HMAC-SHA256 function requires specifying the authentication type. In some embodiments, the authentication information may carry the authentication type; in this case, the third-party scenic area backend 330 can determine the authentication type based on the authentication information. In other embodiments,

[0449] In some embodiments, the authentication request 1 may also carry an authentication type, which indicates the authentication type preset by the gate 200. In other embodiments, the third-party scenic area backend 330 may preset a unique authentication type. In this case, the authentication information may not carry the authentication type. In this case, the third-party scenic area backend 330 may determine the authentication type used when determining the authentication code Mac0' using the HMAC-SHA256 function based on the preset authentication type.

[0450] For example, the authentication code Mac0' can be calculated using the following formula (4). Mac0' = HMAC - SHA256(H0||ID||Authentication Type||r, IK0) Formula (4)

[0451] In formula (4), Mac0' can represent the authentication code Mac0', HMAC-SHA256(·) can represent the HMAC-SHA256 function, ID can represent the ID of gate 200, r can represent the random number r, and IK0 can represent the key IK0. As can be seen from the above formulas (3) and (4), the calculation method of the authentication code Mac0' is exactly the same as the calculation method of the authentication code Mac0.

[0452] S1104. The backend of the three scenic spots determines whether the authentication code Mac0 and the authentication code Mac0' are the same.

[0453] If the authentication code Mac0 is the same as the authentication code Mac0', the third-party scenic spot backend 330 can execute the following step S1105.

[0454] If the authentication code Mac0 is different from the authentication code Mac0', the third-party scenic spot backend 330 can perform the following steps S1111.

[0455] S1105. The backend of the three scenic spots determines the account information 1 based on the order token T0.

[0456] Account information 1 is used to indicate the account that purchased the electronic ticket corresponding to order token T0.

[0457] S1106. The back-end system 330 of the three scenic spots sends a query request to the ticketing system 320. The query request includes account information 1.

[0458] A query request can be used to request the ticketing system to query the order corresponding to account information 1.

[0459] In some embodiments, account information 1 may include one or more of the following: the phone number, ID number, and OpenID of account 1.

[0460] S1107. Ticketing system 320 determines whether the order corresponding to account information 1 can be found.

[0461] If the order corresponding to account information 1 can be found, the ticketing system 320 can execute the following step S1108.

[0462] If the order corresponding to account information 1 cannot be found, the ticketing system 320 can perform the following step S1110.

[0463] S1108. The ticketing system 320 sends query response 1 to the back-end of the third-party scenic spot 330. Query response 1 includes order 1 corresponding to account information 1.

[0464] S1109. The three scenic spots' backend system has successfully confirmed the authentication (330).

[0465] After successful authentication, the third-party scenic area backend 330 can send authentication response 2 to the gate 200. Authentication response 2 is used to instruct the gate 200 to open the gate and allow passage.

[0466] S1110. The ticketing system 320 sends a query response 2 to the back-end system 330 of the third-party scenic spot. The query response 2 is used to indicate that no order corresponding to account information 1 was found.

[0467] S1111. The three scenic spots' backend system confirmed that the authentication failed (330).

[0468] In some embodiments, if no order corresponding to account information 1 is found, the third-party scenic spot backend 330 can determine that the authentication has failed.

[0469] In other embodiments, if the authentication code Mac0 and the authentication code Mac0' are different, the third-party scenic spot backend 330 can determine that the authentication has failed.

[0470] After confirming the authentication failure, the third-party scenic area backend 330 can send authentication response 3 to the gate 200. Authentication response 3 is used to indicate the authentication failure.

[0471] It is understood that the embodiment shown in Figure 11 is only an example. In the embodiments of this application, the third-party scenic spot backend 330 and ticketing system 320 may also use more, fewer or different steps than the above embodiments to authenticate the authentication information. This application does not limit this.

[0472] Using the authentication process shown in Figure 11, the authentication information can be authenticated based on the authentication information, a random number r, and a preset encryption algorithm model F1 to obtain the authentication code Mac0'. In this way, even if the device sending the authentication information is an illegitimate device, the third-party scenic area backend 330 can determine whether to further request the ticketing system 320 to query the corresponding order by comparing its own calculated authentication code Mac0' with the authentication code Mac0 carried in the authentication information. This provides better security for the user's ticket checking process.

[0473] The following describes another hardware structure of an electronic device 100 provided in the embodiments of this application.

[0474] Figure 12 shows a schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of this application.

[0475] The following description uses electronic device 100 as an example to illustrate the embodiment. It should be understood that the electronic device 100 shown in FIG12 is merely an example, and the electronic device 100 may have more or fewer components than shown in FIG12, may combine two or more components, or may have different component configurations. The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0476] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include one or more of the following: pressure sensor 180A, gyroscope sensor 180B, barometric pressure sensor 180C, magnetic sensor 180D, accelerometer sensor 180E, distance sensor 180F, proximity sensor 180G, fingerprint sensor 180H, temperature sensor 180J, touch sensor 180K, ambient light sensor 180L, bone conduction sensor 180M, etc.

[0477] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0478] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or is recurring. If processor 110 needs to reuse the instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0479] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0480] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0481] The charging management module 140 receives charging input from the charger. The power management module 141 connects to the battery 142, and the charging management module 140 connects to the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0482] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0483] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0484] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0485] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0486] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0487] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD). The display panel can also be manufactured using organic light-emitting diodes (OLEDs), active-matrix organic light-emitting diodes (AMOLEDs), flexible light-emitting diodes (FLEDs), miniled, microled, micro-OLEDs, quantum dot light-emitting diodes (QLEDs), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0488] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0489] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The internal memory 121 can be used to store computer-executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Furthermore, the internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0490] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0491] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. Gyroscope sensor 180B can be used to determine the motion posture of electronic device 100. Barometric pressure sensor 180C is used to measure air pressure. Magnetic sensor 180D includes a Hall sensor. Accelerometer sensor 180E can detect the magnitude of acceleration of electronic device 100 in various directions (generally three axes). Distance sensor 180F is used to measure distance. Proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. Ambient light sensor 180L is used to sense ambient light intensity. Fingerprint sensor 180H is used to collect fingerprints. Temperature sensor 180J is used to detect temperature. Touch sensor 180K, also called a "touch panel". Touch sensor 180K can be set on display screen 194, and touch sensor 180K and display screen 194 form a touch screen, also called a "touch screen". Touch sensor 180K is used to detect touch operations applied to or near it. A touch sensor can transmit detected touch operations to an application processor to determine the type of touch event. Visual output related to the touch operation can be provided via display screen 194. In some embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194. Bone conduction sensor 180M can acquire vibration signals. Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration cues. Indicator 192 may be an indicator light, used to indicate charging status, battery level changes, or to indicate messages, missed calls, notifications, etc.

[0492] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0493] In some embodiments, the wireless communication module 160 can specifically be used to establish a short-range wireless communication link with the NFC reader 102, so that the two can perform short-range wireless data transmission with each other. Exemplarily, the aforementioned short-range wireless communication link can be a Bluetooth link, a Wi-Fi link, an NFC link, etc. Therefore, the wireless communication module 160 can specifically include a Bluetooth communication module, a Wi-Fi communication module, or an NFC module. The NFC module can include any suitable component for enabling proximity-based contactless communication between the electronic device 100 and the gate 200, thereby providing NFC functionality to the electronic device 100. A description of the NFC module can be found in the embodiment shown in FIG3A above, and will not be repeated here.

[0494] The foregoing details the method provided in this application. In order to facilitate better implementation of the above-described solutions in the embodiments of this application, the embodiments of this application also provide corresponding devices or equipment.

[0495] This application embodiment can divide the electronic device 100 and the gate 200 into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0496] The communication device of the present application embodiment will now be described in detail with reference to Figures 13 to 16.

[0497] Referring to FIG13, which is a schematic diagram of the structure of a communication device 1100 provided in an embodiment of this application, the communication device 1100 can be the electronic device 100 in the above embodiments. Optionally, the communication device 1100 can be a chip / chip system, such as an NFC chip. As shown in FIG13, the communication device 1100 may include a transceiver unit 1110 and a processing unit 1120.

[0498] The transceiver unit 1110 can also be used to perform NFC sending and NFC receiving functions performed by the electronic device 100 in the above embodiments of this application.

[0499] Optionally, the processing unit 1120 can also be used to perform the functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow, and display performed by the electronic device 100 in the above embodiments of this application.

[0500] It should be understood that the communication device 1100 in this design can perform the method steps performed by the electronic device 100 in the aforementioned embodiments, and for the sake of brevity, it will not be described again here.

[0501] Referring to FIG14, which is a schematic diagram of the structure of a communication device 1200 provided in an embodiment of this application, the communication device 1200 can be the gate 200 in the above embodiment. Optionally, the communication device 1200 can be the gate 200. As shown in FIG14, the communication device 1200 may include a transceiver unit 1210 and a processing unit 1220.

[0502] Optionally, the transceiver unit 1210 can also be used to perform NFC sending and NFC receiving functions performed by the gate 200 in the above embodiments of this application.

[0503] Optionally, the processing unit 1220 can also be used to execute the functional steps related to NFC protocol parsing and encapsulation and NFC service processing flow executed by the gate 200 in the above embodiments of this application.

[0504] It should be understood that the communication device 1200 in this design can perform the method steps executed by the gate 200 in the aforementioned embodiment, and for the sake of brevity, it will not be described again here.

[0505] The above describes the electronic device 100 and the gate 200 of the embodiments of this application. It should be understood that any product with the functions of the electronic device 100 described in FIG13 above, or any product with the functions of the gate 200 described in FIG14 above, falls within the protection scope of the embodiments of this application.

[0506] As one possible product form, the electronic device 100 described in this application embodiment can be implemented using a general bus architecture.

[0507] Referring to Figure 15, Figure 15 is a schematic diagram of the structure of a communication device 1300 provided in an embodiment of this application. The communication device 1300 can be an electronic device 100, or a device therein. As shown in Figure 15, the communication device 1300 includes a processor 1301 and a transceiver 1302 internally connected and communicating with the processor 1301. The processor 1301 can be a general-purpose processor or a dedicated processor, etc. For example, it can be a central processing unit and / or an NFC controller, etc. The transceiver 1302 can be referred to as a transceiver unit, transceiver, or transceiver circuit, etc., and is used to implement transceiver functions. The transceiver 1302 can include a receiver and a transmitter. The receiver can be referred to as a receiver or receiving circuit, etc., and is used to implement a receiving function, such as an NFC receiving function; the transmitter can be referred to as a transmitter or transmitting circuit, etc., and is used to implement a transmitting function, such as an NFC transmitting function. Optionally, the communication device 1300 may also include an antenna 1303 and / or a radio frequency unit (not shown in Figure 15), for example, an NFC antenna, wherein the NFC antenna can be a coil-type antenna. The antenna 1303 and / or radio frequency unit may be located inside the communication device 1300 or separate from the communication device 1300, that is, the antenna 1303 and / or radio frequency unit may be deployed remotely or in a distributed manner.

[0508] Optionally, the communication device 1300 may include one or more memories 1304, which may store instructions, which may be computer programs, that can be executed on the communication device 1300 to cause the communication device 1300 to perform the method steps described in the above embodiments of this application. Optionally, the memory 1304 may also store data. The communication device 1300 and the memory 1304 may be provided separately or integrated together.

[0509] The processor 1301, transceiver 1302, and memory 1304 can be connected via a communication bus.

[0510] In one design, the communication device 1300 can be used to perform the functions of the electronic device 100 in the foregoing embodiments: the processor 1301 can be used to perform the functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow and display performed by the electronic device 100 in the foregoing embodiments of this application and / or other processes used in the technology described herein; the transceiver 1302 can be used to perform the functional steps related to NFC sending and NFC receiving performed by the electronic device 100 in the foregoing embodiments of this application and / or other processes used in the technology described herein.

[0511] In any of the above designs, the processor 1301 may include a transceiver for implementing receive and transmit functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing receive and transmit functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0512] In any of the above designs, the processor 1301 may store instructions, which may be computer programs. These computer programs, running on the processor 1301, cause the communication device 1300 to execute the method steps performed by the electronic device 100 in the above embodiments of this application. The computer program may be embedded in the processor 1301; in this case, the processor 1301 may be implemented in hardware.

[0513] In one implementation, the communication device 1300 may include circuitry capable of performing the functions of transmitting, receiving, or communicating as described in the foregoing method embodiments. The processor and transceiver described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal-oxide-semiconductor (CMOS), n-metal-oxide-semiconductor (NMOS), p-type metal-oxide-semiconductor (PMOS), bipolar junction transistors (BJTs), bipolar CMOS (BiCMOS), silicon-germanium (SiGe), gallium arsenide (GaAs), etc.

[0514] The scope of the communication device described in this application is not limited thereto, and the structure of the communication device is not limited to that shown in Figure 15. The communication device 1300 can be a standalone device or part of a larger device. For example, the communication device 1300 can be:

[0515] (1) A standalone integrated circuit IC, or chip, or chip system or subsystem; (2) A collection of one or more ICs, optionally including storage components for storing data or computer programs; (3) An ASIC, such as an NFC chip; (4) A module that can be embedded in other devices; (5) A receiver, terminal, smart terminal, cellular phone, wireless device, handheld device, mobile unit, vehicle device, network device, cloud device, artificial intelligence device, etc.; (6) Others, etc.

[0516] As one possible product form, the gate 200 described in this application embodiment can be implemented using a general bus architecture.

[0517] Referring to Figure 16, Figure 16 is a schematic diagram of the structure of the communication device 1400 provided in an embodiment of this application. The communication device 1400 can be a gate 200, or a device therein. As shown in Figure 16, the communication device 1400 includes a processor 1401 and a transceiver 1402 internally connected and communicating with the processor 1401. The processor 1401 can be a general-purpose processor or a dedicated processor, etc. For example, it can be an NFC controller. The transceiver 1402 can be referred to as a transceiver unit, transceiver, or transceiver circuit, etc., and is used to implement transceiver functions. The transceiver 1402 can include a receiver and a transmitter. The receiver can be referred to as a receiver or receiving circuit, etc., and is used to implement a receiving function; the transmitter can be referred to as a transmitter or transmitting circuit, etc., and is used to implement a transmitting function. Optionally, the communication device 1400 may also include an antenna 1403 and / or a radio frequency unit (not shown in the figure). The antenna 1403 and / or radio frequency unit may be located inside the communication device 1400 or separate from the communication device 1400, that is, the antenna 1403 and / or radio frequency unit may be deployed remotely or in a distributed manner.

[0518] Optionally, the communication device 1400 may include one or more memories 1404, which may store instructions, which may be computer programs, that can be executed on the communication device 1400 to cause the communication device 1400 to perform the method steps described in the above embodiments of this application. Optionally, the memory 1404 may also store data. The communication device 1400 and the memory 1404 may be provided separately or integrated together.

[0519] The processor 1401, transceiver 1402, and memory 1404 can be connected via a communication bus.

[0520] In one design, the communication device 1400 can be used to perform the functions of the gate 200 in the foregoing embodiments: the processor 1401 can be used to perform the functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow and / or other processes used in the technology described herein, performed by the gate 200 in the embodiment shown in FIG16; the transceiver 1402 can be used to perform the functional steps related to NFC sending and NFC receiving performed by the gate 200 in the embodiment shown in FIG16 and / or other processes used in the technology described herein.

[0521] In any of the above designs, the processor 1401 may include a transceiver for implementing receive and transmit functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing receive and transmit functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0522] In any of the above designs, the processor 1401 may store instructions, which may be computer programs. These computer programs, running on the processor 1401, cause the communication device 1400 to execute the method steps performed by the gate 200 in the above method embodiments. The computer program may be embedded in the processor 1401; in this case, the processor 1401 may be implemented in hardware.

[0523] The hardware structure of a server 1500 provided in the embodiments of this application is described below.

[0524] Figure 17 shows a schematic diagram of the hardware structure of a server 1500 provided in an embodiment of this application.

[0525] As shown in Figure 17, server 1500 may include: one or more network device processors 1501, memory 1502, communication interface 1503, transmitter 1505, receiver 1506, coupler 1507, and antenna 1508. These components can be connected via bus 1504 or other means; Figure 17 illustrates a bus connection as an example.

[0526] The communication interface 1503 can be used by the server 1500 to communicate with other communication devices, such as electronic devices used by consumers in the project. Specifically, the communication interface 1503 can be a 3G communication interface, a Long Term Evolution (LTE) (4G) communication interface, a 5G communication interface, a WLAN communication interface, a WAN communication interface, etc. Not limited to wireless communication interfaces, the server 1500 can also be configured with a wired communication interface 1503 to support wired communication.

[0527] In some embodiments of this application, transmitter 1505 and receiver 1506 can be considered as a wireless modem. Transmitter 1505 can be used to transmit signals output by network device processor 1501. Receiver 1506 can be used to receive signals. In server 1500, the number of transmitters 1505 and receivers 1506 can be one or more. Antenna 1508 can be used to convert electromagnetic energy in a transmission line into electromagnetic waves in free space, or to convert electromagnetic waves in free space into electromagnetic energy in a transmission line. Coupler 1507 can be used to split mobile communication signals into multiple paths and distribute them to multiple receivers 1506. Understandably, the antenna 1508 of the network device can be implemented as a massive MIMO (Massively Multi-Size Antenna Array).

[0528] The memory 1502 is coupled to the network device processor 1501 and is used to store various software programs and / or multiple sets of instructions. Specifically, the memory 1502 may include high-speed random access memory and may also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

[0529] The memory 1502 can store an operating system (hereinafter referred to as the system), such as uCOS, VxWorks, RTLinux, and other embedded operating systems. The memory 1502 can also store a network communication program, which can be used to communicate with other communication devices.

[0530] In this embodiment, the network device processor 1501 can be used to read and execute computer-readable instructions. Specifically, the network device processor 1501 can be used to call a program stored in the memory 1502, such as an implementation program of the ticket checking method provided in one or more embodiments of this application, and execute the instructions contained in the program. Optionally, it may also include an implementation program of the ticket purchasing method provided in one or more embodiments of this application, and execute the instructions contained in the program.

[0531] It should be noted that, in the embodiments of this application, the hardware structure of any server in the cloud server 300 (such as the business system 310, the ticketing system 320, the third-party scenic spot backend 330, etc.) and the third-party server 500 can refer to the hardware structure of the server 1500 shown in Figure 17 above.

[0532] It is understood that the server 1500 shown in Figure 17 is only one implementation of the present application. In actual applications, the server 1500 may include more or fewer components, which is not limited here.

[0533] Figure 18 shows a flowchart of a ticket checking method provided in an embodiment of this application.

[0534] As shown in Figure 18, the specific process of a ticket checking method may include the following steps:

[0535] S1801. The first electronic device is logged in with a first account. After entering the radio frequency field of the gate, the first electronic device receives a first authentication request sent by the gate. The first authentication request includes a first random number and the first identifier of the gate.

[0536] In some embodiments, the first electronic device may be the electronic device 100 in the above embodiments, and the gate may be the gate 200 in the above embodiments.

[0537] The first authentication request can be authentication request 1 in the embodiment shown in Figure 7 above, and the first random number can be random number r in the embodiment above. The first identifier can be the device identifier of the gate 200 in the embodiment above, or it can be the item identifier 1 of the gate 200.

[0538] For example, the first account can be account 1 in the above-described embodiment.

[0539] S1802. The first electronic device determines the first order token based on the first identifier.

[0540] For example, the first order token may be the order token T0 in the above embodiments.

[0541] The specific steps by which the first electronic device determines the first order token based on the first identifier can also be referred to the relevant descriptions in the embodiments shown in Figures 8-9 above, and will not be repeated here.

[0542] S1803. The first electronic device determines the first authentication information based on the first order token and the first random number.

[0543] For example, the first authentication information may be the authentication information in the embodiment shown in Figure 7 above.

[0544] For example, the specific steps for the first electronic device to generate the first authentication information can also be referred to the relevant description in the embodiment shown in Figure 10 above, and will not be repeated here.

[0545] S1804. The first electronic device sends a first authentication response to the gate, the first authentication response including first authentication information and a first random number.

[0546] For example, the first authentication response may be authentication response 1 in the embodiment shown in FIG7.

[0547] Using the ticket checking method provided in this application, the first electronic device can encrypt the first order token based on a first random number using a preset encryption algorithm model, and send the encrypted first authentication information to the gate. In this way, even if the other end device is an unauthorized gate, it can only obtain the encrypted first authentication information and cannot directly steal the first order token.

[0548] In one possible implementation, the first authentication information is determined based on the first order token and the first random number, specifically including: determining the first authentication information based on the first order token, the first random number, and the first identifier.

[0549] In this way, the first electronic device can generate first authentication information related to the first identifier, which enhances the complexity and randomness of the first authentication information, thereby improving the security of the ticket checking process.

[0550] In one possible implementation, the first authentication information includes a first authentication code and a first credential index; the first authentication information is determined based on a first order token, a first random number, and a first identifier, specifically including: determining a first credential index based on the first order token; determining a first key based on the first order token and the first random number; and determining a first authentication code based on the first random number, the first key, the first credential index, and the first identifier.

[0551] For example, the first credential index may be the credential index H0 in the embodiments shown in Figures 10-11 above; the first key may be the key IK0 in the embodiments shown in Figures 10-11 above; and the first authentication code may be the authentication code Mac0 in the embodiments shown in Figures 10-11 above.

[0552] In this way, a first authentication code and a first credential index can be generated based on the first order token, the first random number, and the first identifier using a preset encryption algorithm model. The first authentication code can be used to verify whether the preset encryption algorithm model in the first electronic device is consistent with the preset encryption algorithm model in the third-party scenic spot's backend.

[0553] In one possible implementation, the first authentication information further includes an authentication type; the first authentication code is determined based on the first random number, the first key, the first credential index, and the first identifier, specifically including: determining the first authentication code based on the first random number, the first key, the first credential index, the first identifier, and the authentication type.

[0554] In this way, a first authentication code can be generated based on the authentication type of the first electronic device, which enhances the complexity and randomness of the first authentication information, thereby improving the security of the ticket checking process.

[0555] In one possible implementation, the first identifier includes the first device identifier of the gate and / or the first item identifier corresponding to the gate.

[0556] The first device identifier can be the device identifier of the gate 200 in the above embodiment, also known as the ID of the gate 200; the first item identifier can be the item identifier 1 of the gate 200 in the above embodiment.

[0557] In one possible implementation, determining the first order token based on the first identifier specifically includes: determining the first item identifier based on the first identifier; and determining the first order token in the first electronic device based on the first item identifier.

[0558] Wherein, if the first identifier includes the first project identifier, the first electronic device can determine the first project identifier based on the first identifier, and query the first order token corresponding to the first project identifier locally in the first electronic device according to the first project identifier; if the first identifier only includes the first device identifier, the first electronic device can query the corresponding first project identifier based on the first device identifier, and then query the first order token corresponding to the first project identifier locally in the first electronic device according to the first project identifier.

[0559] In this way, if the first electronic device has the first order token stored locally, the first order token can be queried locally based on the first identifier.

[0560] In one possible implementation, determining the first order token based on the first identifier specifically includes: determining the first project identifier based on the first identifier; sending a token acquisition request to the third-party scenic area's backend, the token acquisition request including the first project identifier; and receiving a token acquisition response sent by the third-party scenic area's backend, the token acquisition response including the first order token.

[0561] If the first identifier includes the first project identifier, the first electronic device can determine the first project identifier based on the first identifier and query the first order token corresponding to the first project identifier from the third-party scenic area backend based on the first project identifier; if the first identifier only includes the first device identifier, the first electronic device can query the corresponding first project identifier based on the first device identifier and then query the first order token corresponding to the first project identifier from the third-party scenic area backend based on the first project identifier.

[0562] For example, the third-party scenic area backend can refer to the third-party scenic area backend 330 in the above embodiment.

[0563] In this way, even if the first electronic device does not store the first order token locally, the first order token can be retrieved from the third-party scenic spot's backend based on the first identifier.

[0564] In one possible implementation, the first identifier includes a first device identifier; determining the first project identifier corresponding to the first device identifier specifically includes: sending a project identifier acquisition request to the business system, the project identifier acquisition request including the first device identifier; and receiving a project identifier acquisition response sent by the business system, the project identifier acquisition response including the first project identifier.

[0565] For example, the business system may be the business system 310 in the above embodiments.

[0566] In this way, if the first identifier does not include the first project identifier, the first electronic device can query the first project identifier corresponding to the first device identifier from the business system based on the first device identifier.

[0567] In one possible implementation, the method further includes: after logging into the first account, sending an account information retrieval request to the business system, the account information retrieval request including the first account; receiving the first account information sent by the business system, the first account information being used to identify the user identity of the first account; receiving and responding to the user's first ticket purchase operation, determining the first ticket purchase information, the first ticket purchase information including the first project identifier, the number of tickets, and the ticket type; sending a first ticket purchase request to the third-party scenic spot's backend, the first ticket purchase request including the first ticket purchase information and the first account information; and receiving a first ticket purchase response sent by the third-party scenic spot's backend, the first ticket purchase response including the first order token.

[0568] In this way, the first electronic device can purchase electronic tickets through the first account and obtain the first order token.

[0569] In one possible implementation, the method further includes: after logging into the first account, sending an account information retrieval request to the business system, the account information retrieval request including the first account; receiving the first account information sent by the business system, the first account information being used to identify the user identity of the first account; sending a token synchronization request to the third-party scenic spot backend, the token synchronization request including the first account information; and receiving a token synchronization response sent by the third-party scenic spot backend, the token synchronization response including the first order token.

[0570] For example, the ticket purchase process of the first electronic device can also refer to the relevant description in the embodiments shown in Figures 5-6 above, and will not be repeated here.

[0571] In this way, when other electronic devices purchase tickets through the first account, the first electronic device can synchronize the first order token purchased by other electronic devices through the first account after logging into the first account, so as to shorten the ticket checking time and improve the ticket checking efficiency in the subsequent ticket checking process.

[0572] In one possible implementation, after entering the radio frequency field of the turnstile, the method further includes: receiving a probe frame sent by the turnstile, the probe frame indicating that the turnstile supports a specified NFC protocol; sending a probe ACK frame to the turnstile, the probe ACK frame indicating that a first electronic device supports the specified NFC protocol; receiving a notification frame sent by the turnstile, the notification frame carrying device characteristic information of the turnstile, the device characteristic information of the turnstile including a service identifier and a device organization identifier, wherein the service identifier indicates the type of NFC service supported by the turnstile, and the device organization identifier indicates the manufacturer using the turnstile to provide NFC services; sending a notification ACK frame to the turnstile, the notification ACK frame indicating that the first electronic device has received the notification frame; and determining, based on the device characteristic information of the turnstile, that the type of NFC service of the turnstile is electronic ticketing.

[0573] In this way, after the first electronic device enters the radio frequency field of the gate, it can complete the interaction through the pre-agreed NFC protocol to determine that the current scenario is an electronic ticket checking scenario, thereby triggering the first electronic device to activate the relevant electronic ticket services.

[0574] In one possible implementation, after sending a Notify ACK frame to the gate, the method further includes: receiving a parameter negotiation command sent by the gate; and sending a parameter negotiation response to the gate, wherein the parameter negotiation command and parameter negotiation instructions are used to negotiate the transmission parameters at the application protocol layer.

[0575] In this way, the first electronic device and the gate can negotiate the transmission parameters of the application protocol layer, so that the gate can interact with the application protocol layer of the first electronic device in the future.

[0576] In one possible implementation, the first electronic device includes an electronic ticketing service and a near-field communication (NFC) protocol stack; receiving a first authentication request sent by a gate, specifically including: receiving the first authentication request sent by the gate via the NFC protocol stack; receiving the first authentication request sent by the NFC protocol stack via the electronic ticketing service; determining a first order token based on a first identifier, specifically including: determining the first order token based on the first identifier via the electronic ticketing service; determining first authentication information based on the first order token and a first random number, specifically including: determining the first authentication information based on the first order token and the first random number via the electronic ticketing service; sending a first authentication response to the gate, specifically including: sending the first authentication response to the NFC protocol stack via the electronic ticketing service; and sending the first authentication response to the gate via the NFC protocol stack.

[0577] For example, the electronic ticketing service can be the electronic ticketing service 11 in the above embodiments, and the NFC protocol stack can be the NFC protocol stack 14 in the above embodiments.

[0578] In this way, the first electronic device can interact with the gate through the NFC protocol stack, and query the order token and generate authentication information through the electronic ticket service to complete the ticket check.

[0579] Figure 19 shows a schematic flowchart of a ticket checking method provided in an embodiment of this application.

[0580] As shown in Figure 19, the specific process of a ticket checking method may include the following steps:

[0581] S1901. The gate detects that the first electronic device has entered the radio frequency field of the gate, and generates and stores the first random number.

[0582] For example, the gate can be the gate 200 in the above embodiment, and the first random number can be the random number r in the above embodiment.

[0583] S1902. The turnstile sends a first authentication request to the first electronic device. The first authentication request includes a first random number and a first identifier of the turnstile.

[0584] For example, the first authentication request may be authentication request 1 in the embodiment shown in FIG7 above, and the first identifier may include the device identifier of the gate 200 and / or the item identifier 1 of the gate 200.

[0585] S1903. The gate receives a first authentication response sent by a first electronic device. The first authentication response includes first authentication information and a first random number.

[0586] For example, the first authentication response may be authentication response 1 as shown in Figure 7 above, and the first authentication information may be the authentication information in the embodiment shown in Figure 7 above.

[0587] S1904. The gate detected that the first authentication response carried a first random number.

[0588] S1905. The gate sends a second authentication request to the back-end of the three scenic area. The second authentication request includes the first authentication information, the first random number, and the first identifier.

[0589] For example, the second authentication request may be authentication request 2 in the embodiment shown in Figure 7 above.

[0590] S1906. The gate receives the second authentication response sent by the third-party scenic area's backend.

[0591] For example, the second authentication response may be authentication response 2 in the embodiment shown in Figure 7 above.

[0592] S1907. The gate responds to the second authentication response and opens the gate to allow passage.

[0593] In this way, the turnstile can determine whether the electronic devices interacting before and after the authentication process are the same by comparing the random number carried in the first authentication response with the random number generated by the turnstile. This improves the security of the ticket checking process and prevents unauthorized devices from stealing electronic tickets. Furthermore, the turnstile can also determine whether to open the gate based on the authentication response sent by the third-party scenic area's backend system.

[0594] In one possible implementation, the method further includes: after sending a second authentication request to the third-party scenic spot's backend, deleting the first random number.

[0595] This ensures that the random number is generated randomly each time a ticket is checked, thereby improving the security of the ticket checking process.

[0596] In one possible implementation, the method further includes: when generating the first random number, setting a timer with a duration of the first duration; and deleting the first random number when the timer countdown ends.

[0597] Setting a timer simultaneously with the generation of the first random number ensures that the first random number is only valid until the timer's countdown ends. If an authentication response carrying the first random number is received after this validity period, the ticket check is considered to have failed. This effectively sets a check period for each ticket check; exceeding this period results in the check being considered a failure, preventing unauthorized transactions by other devices and improving ticket check security.

[0598] In one possible implementation, the method includes: detecting that a second electronic device has entered the radio frequency field of the gate, generating and storing a second random number; sending a third authentication request to the second electronic device, the third authentication request including the second random number and a first identifier of the gate; receiving a third authentication response sent by the second electronic device, the third authentication response including second authentication information and a third random number; detecting that the second random number and the third random number are inconsistent, outputting an error message, the error message being used to indicate to the user that the authentication information is incorrect.

[0599] In this way, when the gate detects that the random number it generates is inconsistent with the random number sent by the electronic device, it can determine that the authentication information is incorrect and end the ticket checking process.

[0600] Figure 20 shows a flowchart of a ticket checking method provided in an embodiment of this application.

[0601] As shown in Figure 20, the specific process of a ticket checking method may include the following steps:

[0602] S2001. The back-end of the three scenic area receives the second authentication request sent by the gate. The second authentication request includes the first authentication information, the first random number and the first identifier. The first authentication information includes the first credential index and the first authentication code.

[0603] For example, the third-party scenic spot backend can be the third-party scenic spot backend 330 in the above embodiment.

[0604] S2002. The three scenic area backend determines the second authentication code and the first order token based on the first authentication information, the first random number and the first identifier.

[0605] For example, the second authentication code can be the authentication code Mac0' in the embodiment shown in Figure 11 above. The specific method for the third-party scenic spot backend to generate the second authentication code can also be referred to the relevant description in the embodiment shown in Figure 11, which will not be repeated here.

[0606] S2003. The backend system of the three scenic spots detected that the first authentication code and the second authentication code are the same.

[0607] S2004. The back-end system of the three scenic spots determines the first account information based on the first order token.

[0608] For example, the first account information can be account information 1 in the above embodiments.

[0609] S2005. The back-end of the three scenic spots sends the first query request to the ticketing system. The first query request includes the first account information.

[0610] For example, the first query request may be the query request in the embodiment shown in Figure 11 above.

[0611] S2006. The back-end system of the three scenic spots receives the first query response sent by the ticketing system. The first query response includes the first order.

[0612] For example, the first query response can be query response 1 in the embodiment shown in Figure 11 above, and the first order can be order 1.

[0613] S2007. The three-party scenic area's backend responds to the first query response and sends a second authentication response to the gate. The second authentication response is used to instruct the gate to open and allow passage.

[0614] The specific details of each step in the embodiment shown in Figure 20 can also be found in the relevant descriptions in the embodiments shown in Figures 7 and 11 above, and will not be repeated here.

[0615] In this way, the third-party scenic area's backend can determine whether the first authentication information can pass authentication by comparing the second authentication code it generates with the first authentication code sent by the gate. If the first authentication code matches the second authentication code, it means that the encryption algorithm model used by the first electronic device is the same as the encryption algorithm model used by the third-party scenic area's backend. At this point, it can be determined that the first authentication information can pass authentication.

[0616] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the electronic device 100 in the above-described method embodiments.

[0617] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the gate 200 in the above-described method embodiments.

[0618] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the electronic device 100 in the above-described method embodiments.

[0619] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the gate 200 in the above-described method embodiments.

[0620] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the electronic device 100 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0621] This application also provides a chip system, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the gate 200 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0622] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A ticket checking method, applied to a first electronic device, characterized in that, The first electronic device is logged into with a first account; the method includes: Upon entering the radio frequency field of the gate, a first authentication request is received from the gate, the first authentication request including a first random number and a first identifier of the gate; The first order token is determined based on the first identifier; The first authentication information is determined based on the first order token and the first random number; Send a first authentication response to the gate, the first authentication response including the first authentication information and the first random number.

2. The method of claim 1, wherein, The step of determining the first authentication information based on the first order token and the first random number specifically includes: determining the first authentication information based on the first order token, the first random number, and the first identifier.

3. The method of claim 2, wherein, The first authentication information includes a first authentication code and a first credential index; The determination of the first authentication information based on the first order token, the first random number, and the first identifier specifically includes: The first voucher index is determined based on the first order token; The first key is determined based on the first order token and the first random number; The first authentication code is determined based on the first random number, the first key, the first credential index, and the first identifier.

4. The method of claim 3, wherein, The first authentication information also includes the authentication type; The determination of the first authentication code based on the first random number, the first key, the first credential index, and the first identifier specifically includes: The first authentication code is determined based on the first random number, the first key, the first credential index, the first identifier, and the authentication type.

5. The method according to any one of claims 1-4, characterized in that, The first identifier includes the first device identifier of the gate and / or the first item identifier corresponding to the gate.

6. The method according to any one of claims 1-5, characterized in that, The step of determining the first order token based on the first identifier specifically includes: The first project identifier is determined based on the first identifier; The first order token is determined in the first electronic device based on the first project identifier.

7. The method according to any one of claims 1-5, characterized in that, The step of determining the first order token based on the first identifier specifically includes: The first project identifier is determined based on the first identifier; Send a token acquisition request to the backend of the third-party scenic area, wherein the token acquisition request includes the first project identifier; Receive a token acquisition response sent by the backend of the third-party scenic spot, the token acquisition response including the first order token.

8. The method according to claim 6 or 7, characterized in that, The first identifier includes a first device identifier; determining the first item identifier corresponding to the first device identifier specifically includes: Send a project identifier acquisition request to the business system, wherein the project identifier acquisition request includes the first device identifier; The system receives a project identifier retrieval response from the business system, the project identifier retrieval response including the first project identifier.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: After logging into the first account, an account information retrieval request is sent to the business system, and the account information retrieval request includes the first account; Receive first account information sent by the business system, the first account information being used to identify the user identity of the first account; Receive and respond to the user's first ticket purchase operation, and determine the first ticket purchase information, which includes the first item identifier, the number of tickets, and the ticket type; Send the first ticket purchase request to the back-end of the three scenic spots. The first ticket purchase request includes the first ticket purchase information and the first account information. Receive the first ticket purchase response sent by the backend of the three scenic spots, the first ticket purchase response including the first order token.

10. The method according to any one of claims 1-8, further comprising: After logging into the first account, an account information retrieval request is sent to the business system, and the account information retrieval request includes the first account; Receive first account information sent by the business system, the first account information being used to identify the user identity of the first account; Send a token synchronization request to the backend of the third-party scenic area, the token synchronization request including the first account information; Receive the token synchronization response sent by the backend of the three scenic spots, the token synchronization response including the first order token.

11. The method according to any one of claims 1-10, characterized in that, After entering the radio frequency field of the gate, the method further includes: The gate receives a probe frame, which indicates that the gate supports a specified NFC protocol. Send a Probe ACK frame to the gate, the Probe ACK frame being used to indicate that the first electronic device supports the specified NFC protocol; The gate receives a Notify frame, which carries the device characteristic information of the gate, including a service identifier and a device organization identifier. The service identifier indicates the type of NFC service supported by the gate, and the device organization identifier indicates the manufacturer that provides NFC services using the gate. Send a Notify ACK frame to the gate, the Notify ACK frame being used to indicate that the first electronic device has received the Notify frame; Based on the device feature information of the gate, the type of NFC service of the gate is determined to be electronic ticket.

12. The method of claim 11, wherein, After sending a Notify ACK frame to the gate, the method further includes: Receive the parameter negotiation command sent by the gate; Send a parameter negotiation response to the gate. The parameter negotiation command and the parameter negotiation instruction are used to negotiate the transmission parameters at the application protocol layer.

13. The method according to any one of claims 1 to 12, characterized in that, The first electronic device includes an electronic ticketing service and a near-field communication (NFC) protocol stack; Receiving the first authentication request sent by the gate specifically includes: The first authentication request sent by the gate is received through the NFC protocol stack; The electronic ticketing service receives the first authentication request sent by the NFC protocol stack. The step of determining the first order token based on the first identifier specifically includes: The first order token is determined based on the first identifier through the electronic ticketing service; The determination of the first authentication information based on the first order token and the first random number specifically includes: The electronic ticketing service determines the first authentication information based on the first order token and the first random number. Sending the first authentication response to the gate specifically includes: The first authentication response is sent to the NFC protocol stack via the electronic ticketing service; The first authentication response is sent to the gate via the NFC protocol stack.

14. A ticket checking method applied to a gate, characterized by, The method includes: Upon detecting that the first electronic device has entered the radio frequency field of the gate, a first random number is generated and stored; Send a first authentication request to the first electronic device, the first authentication request including the first random number and the first identifier of the gate; Receive a first authentication response sent by the first electronic device, wherein the first authentication response includes the first authentication information and the first random number; The first random number was detected to be carried in the first authentication response; A second authentication request is sent to the backend of the third-party scenic area. The second authentication request includes the first authentication information, the first random number, and the first identifier. Receive the second authentication response sent by the backend of the three-party scenic area; In response to the second authentication response, the gate is opened and passage is permitted.

15. The method of claim 14, wherein, The method further includes: after sending the second authentication request to the backend of the third-party scenic spot, deleting the first random number.

16. The method of claim 14, wherein, The method further includes: When generating the first random number, a timer is set, and the duration of the timer is a first duration; Once the countdown of the timer is detected to have ended, the first random number is deleted.

17. The method of claim 14 or 15, wherein, The method includes: Upon detecting that a second electronic device has entered the radio frequency field of the gate, a second random number is generated and stored; Send a third authentication request to the second electronic device, the third authentication request including the second random number and the first identifier of the gate; Receive a third authentication response sent by a second electronic device, the third authentication response including the second authentication information and the third random number; If the second random number is found to be inconsistent with the third random number, an error message is output, which is used to indicate that the user authentication information is incorrect.

18. A ticket checking method applied to a three-party scenic spot background, characterized in that, The method includes: The gate receives a second authentication request, which includes the first authentication information, the first random number, and the first identifier. The first authentication information includes a first credential index and a first authentication code. The second authentication code and the first order token are determined based on the first authentication information, the first random number, and the first identifier; The first authentication code and the second authentication code are detected to be the same; The first account information is determined based on the first order token; Send a first query request to the ticketing system, the first query request including the first account information; Receive a first query response sent by the ticketing system, wherein the first query response includes a first order; In response to the first query response, a second authentication response is sent to the gate, which instructs the gate to open and allow passage.

19. A ticket checking system characterized by comprising: The system includes a first electronic device, a turnstile, and a third-party scenic area backend; wherein the first electronic device is used to implement the method of any one of claims 1-13, the turnstile is used to implement the method of any one of claims 14-17, and the third-party scenic area backend is used to implement the method of claim 18.

20. An electronic device, comprising: It includes one or more processors and one or more memories; wherein the one or more memories are coupled to one or more processors, and the one or more memories are used to store computer instructions that, when the one or more processors execute the computer instructions, implement the ticket checking method according to any one of claims 1-19.

21. A chip system, characterized by include: The processing circuit and the interface circuit are provided, wherein the interface circuit is used to receive code instructions and transmit them to the processing circuit, and the processing circuit is used to execute the code instructions to perform the ticket checking method according to any one of claims 1-19.

22. A readable storage medium, characterized by, The device stores computer instructions that, when executed by a processor, implement the ticket checking method according to any one of claims 1-19.

23. A computer program product, characterised in that, Includes computer instructions, which, when executed by a processor, implement the ticket checking method according to any one of claims 1-19.

Images