Ticket checking method and system, and related apparatus

Abstract

Disclosed in the present application are a ticket checking method and system, and a related apparatus. The method is applied to a first electronic device, on which a first account has been logged in to. The method comprises: after entering a radio-frequency field of a gate, receiving a first item identifier sent by the gate; on the basis of the first item identifier, determining a first opening identifier (OpenID), wherein the first OpenID is generated on the basis of the first item identifier and the first account, and the first OpenID is used for the gate to verify whether the first account logged in to on the first electronic device has a permission to open the gate; and sending a first response to the gate, wherein the first response comprises the first OpenID. In this way, the first electronic device can complete ticket checking by means of touching the gate, thereby simplifying steps of ticket checking, improving the efficiency of ticket checking, and bringing a better experience for users.

Description

Ticket checking method, system and related device

[0001] The present application claims priority to the Chinese patent application No. 202411108434.3, filed on August 12, 2024, entitled "A ticket checking method, system and related device", the Chinese patent application No. 202411877853.3, filed on December 17, 2024, entitled "A ticket checking method, system and related device", the Chinese patent application No. 202510623741.3, filed on May 14, 2025, entitled "A ticket checking method, system and related device", the contents of which are incorporated herein by reference in their entirety. TECHNICAL FIELD

[0002] The present application relates to the field of communication technology, and in particular to a ticket checking method, system and related device. BACKGROUND

[0003] With the continuous development of communication technology, the relationship between communication and daily life is becoming closer and closer.

[0004] A user can purchase an electronic ticket such as a scenic spot ticket in a specific application software or applet. When checking the ticket, the user can open the application software or applet, find the corresponding order, open the two-dimensional code, and after being checked by a human or a gate machine, can enter the park for visit.

[0005] However, the above-mentioned ticket checking method is cumbersome and inefficient. SUMMARY

[0006] The present application provides a ticket checking method, system and related device, which realizes ticket checking through the interaction between the first electronic device and the gate machine, simplifies the ticket checking steps, and improves the ticket checking efficiency.

[0007] In a first aspect, the present application provides a ticket checking method applied to a first electronic device, the first electronic device being logged in with a first account; the method comprising: receiving a first project identifier sent by a gate machine after entering a radio frequency field of the gate machine; determining a first gate opening identifier OpenID based on the first project identifier, the first OpenID being generated from the first project identifier and the first account, the first OpenID being used for the gate machine to verify whether the first account logged in on the first electronic device has the right to open the gate; and sending a first response to the gate machine, the first response comprising the first OpenID.

[0008] In this way, the first electronic device can complete ticket checking by touching the gate, simplifies the ticket checking steps, improves the ticket checking efficiency, and brings better experience to the user.

[0009] In a possible implementation, the first OpenID is determined based on the first item identifier, specifically including: determining the first OpenID corresponding to the first item identifier from one or more OpenIDs stored by the first electronic device based on the first item identifier.

[0010] By using the ticket checking method provided in the application, the first electronic device can obtain the first OpenID from the locally stored OpenIDs, thereby completing ticket checking. In this way, even if the first electronic device is in an offline state, ticket checking can also be completed.

[0011] In a possible implementation, the first OpenID is determined based on the first item identifier, specifically including: sending the first item identifier and the first account of the first electronic device to the account cloud; and receiving the first OpenID sent by the account cloud.

[0012] By using the ticket checking method provided in the application, the first electronic device can obtain the first OpenID corresponding to the first account and the first item identifier through the account cloud. In this way, the first electronic device does not need to store the first OpenID locally, thereby saving storage space.

[0013] In a possible implementation, the first item identifier and the first account of the first electronic device are sent to the account cloud, specifically including: sending the first item identifier and the first account to the account cloud through the electronic ticket business cloud.

[0014] In this way, the first electronic device can interact with the account cloud through the electronic ticket business cloud.

[0015] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: receiving a first request sent by the gate, the first request including a first device identifier of the first electronic device; sending a verification request to the electronic ticket business cloud, the verification request including the first device identifier, the verification request being used to request the electronic ticket business cloud to verify whether the first device identifier is valid; and receiving a first verification response sent by the electronic ticket business cloud, the first verification response being used to inform the first electronic device that the first device identifier is valid.

[0016] By using the ticket checking method provided in the application, the first electronic device can verify the first device identifier of the gate through the electronic ticket business cloud in the ticket checking process, to determine whether the first device identifier is valid. In this way, the security of the ticket checking process can be improved, and the user can be prevented from interacting with an invalid gate and suffering losses.

[0017] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: generating a first digest based on a preset first random number through a first hash algorithm; receiving a second digest sent by the gate; and determining that the gate is a trusted device if the first digest is the same as the second digest.

[0018] In this way, whether the gate is a trusted device can be verified through security verification, thereby improving the security of the ticket checking process.

[0019] In a possible implementation, the method further includes: receiving a second random number sent by the gate; generating a third digest based on the first random number and the second random number through the first hash algorithm; and sending the third digest to the gate, where the third digest is used by the gate to determine whether the first electronic device is a trusted device.

[0020] In this way, whether the gate is a trusted device can be verified through security verification, thereby improving the security of the ticket checking process.

[0021] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: receiving a probe frame sent by the gate, where the probe frame is used to indicate that the gate supports a specified NFC protocol; sending a probe acknowledgement (Probe ACK) frame to the gate, where the Probe ACK frame is used to indicate that the first electronic device supports the specified NFC protocol; receiving a notification (Notify) frame sent by the gate, where the Notify frame carries device characteristic information of the gate, and the device characteristic information of the gate includes a service identifier and a device organization identifier, the service identifier is used to indicate a type of NFC service supported by the gate, and the device organization identifier is used to indicate a manufacturer that provides the NFC service using the gate; determining, based on the device characteristic information of the gate, that the type of the NFC service of the gate is an electronic ticket; and sending a notification acknowledgement (Notify ACK) frame to the gate, where the Notify ACK frame is used to indicate that the first electronic device has determined the type of the NFC service of the gate.

[0022] In this way, interaction can be completed through the pre-agreed NFC protocol, and ticket checking can be implemented.

[0023] In a possible implementation, before entering the radio frequency field of the gate, the method includes: receiving and corresponding to an operation of purchasing a first ticket by a user, obtaining a first project identifier corresponding to the first ticket; sending the first project identifier and a first account to an account cloud; receiving a first OpenID sent by the account cloud; sending a ticket purchase request to a ticket system server, where the ticket purchase request includes the first OpenID and a first purchase number of the first ticket; receiving first ticket information sent by the ticket system server, where the first ticket information includes a first ticket identifier of the first ticket and the first purchase number; and displaying the first ticket information.

[0024] In this way, the first electronic device can purchase the specified electronic ticket, and complete ticket checking by using the purchased electronic ticket.

[0025] In a possible implementation, the ticket purchase request further includes any one or more of the following: the first item identifier, the ticket type, and the validity period of the first ticket; and the first ticket information further includes any one or more of the following: the ticket type, the validity period of the first ticket, and the verification status of the first ticket, the verification status of the first ticket being used to indicate whether the first ticket is verified.

[0026] In this way, the type, validity period, and verification status of the electronic ticket purchased by the user can be indicated by the first ticket information.

[0027] In a possible implementation, before entering the radio frequency field of the gate, the method further includes: after logging in the first account, sending an information synchronization request to the electronic ticket business cloud, the information synchronization request including the first account; and receiving second ticket information sent by the electronic ticket business cloud, the second ticket information including information of one or more electronic tickets purchased by the first account, the one or more electronic tickets including the first ticket, and the first ticket being bound to the first OpenID.

[0028] In this way, when the user purchases the first ticket corresponding to the first item identifier by using an electronic device other than the first electronic device based on the first account, the user can log in the first account on the first electronic device, obtain the related information of the first ticket from the electronic ticket business cloud, and complete ticket checking.

[0029] In a possible implementation, before entering the radio frequency field of the gate, the method further includes: receiving a ticket sharing request sent by a second electronic device, the ticket sharing request including a first transfer identifier of the second OpenID and the first item identifier, and the ticket sharing request being used to request sharing, to the first electronic device, the first ticket bound to the second OpenID; sending, to the account cloud, the first account of the first electronic device and the first item identifier; receiving the first OpenID generated based on the first account and the first item identifier and sent by the account cloud; sending, to the ticketing system server, a ticket transfer confirmation, the ticket transfer confirmation including the first transfer identifier and the first OpenID; receiving a transfer success confirmation sent by the ticketing system server, the transfer success confirmation being used to notify the first electronic device that the first OpenID is bound to the first ticket; and sending, to the second electronic device, a transfer success notification, the transfer success notification being used to notify the second electronic device that the first ticket is successfully transferred.

[0030] In this way, the first electronic device can receive the first ticket purchased by the second electronic device by ticket sharing, and complete ticket checking.

[0031] In a possible implementation, the first OpenID is bound to one or more electronic tickets.

[0032] In this way, the ticket checking of one or more electronic tickets can be performed through the first OpenID, that is, the user can realize the entry of multiple people into the park by touching the gate with the first electronic device.

[0033] In a possible implementation, the first electronic device includes an electronic ticket service and a near field communication (NFC) protocol stack; the first project identifier sent by the gate is received, specifically including: receiving the first routing information through the NFC protocol stack, the first routing information including the first project identifier; after receiving the first project identifier sent by the gate, the method further includes: sending the first routing confirmation to the gate through the NFC protocol stack, the first routing confirmation being used to notify the gate that the first electronic device successfully receives the first routing information; determining the first OpenID based on the first project identifier, specifically including: sending the first project identifier to the electronic ticket service based on the first routing information through the NFC protocol stack; determining the first OpenID based on the first project identifier through the electronic ticket service; sending the first response to the gate, specifically including: sending the first response to the gate based on the NFC protocol stack through the electronic ticket service.

[0034] In this way, the first electronic device can pull up the electronic ticket service based on the first project identifier, and obtain the first OpenID through the electronic ticket service, to complete the ticket checking.

[0035] In a second aspect, the present application provides a ticket checking method, applied to a gate, and the method includes: after a first electronic device enters a radio frequency field of the gate, sending a first project identifier to the first electronic device; receiving a first response sent by the first electronic device, the first response including a first gate opening identifier (OpenID); and opening the gate based on the first OpenID.

[0036] In this way, the gate can complete the ticket checking through the interaction with the first electronic device, and the ticket checking process is simplified.

[0037] In a possible implementation, the gate is opened based on the first OpenID, specifically including: sending a first verification request to a ticketing system server, the first verification request including the first OpenID; receiving a first verification response sent by the ticketing system server; and in response to the first verification response, the gate is opened.

[0038] In this way, the gate can be opened when it is determined that the first OpenID is verified to be valid.

[0039] In a third aspect, the present application provides a ticket checking system, including a first electronic device and a gate; wherein the first electronic device is configured to implement the ticket checking method in any of the possible implementation manners of the first aspect, and the gate is configured to implement the ticket checking method in any of the possible implementation manners of the second aspect. In this way, the gate can be opened when it is determined that the first OpenID is verified to be valid.

[0040] In a fourth aspect, the present application provides a ticket checking method applied to a first electronic device, the method comprising: receiving a first ticket service selection request sent by a gate machine, the first ticket service selection request being used to request selection of an electronic ticket service; sending a first ticket service selection response to the gate machine, the first ticket service selection response being used to indicate that the first electronic device has successfully selected the electronic ticket service; receiving a first ticket checking request sent by the gate machine, the first ticket checking request comprising a third random number and a second device identifier of the gate machine; sending a first ticket checking response to the gate machine, the first ticket checking response comprising the third random number and the second device identifier; and sending verification information to a background server, the verification information comprising a first gate opening identifier OpenID and the second device identifier.

[0041] In this way, the first electronic device can send the random number and the second device identifier of the gate machine (i.e., the device identifier of the gate machine, also referred to as the ID of the gate machine) to the gate machine, and send the first OpenID and the second device identifier to the background server, so that the background server can determine whether to instruct the gate machine to open the gate based on the first OpenID, which can avoid the first OpenID being leaked or tampered with during the interaction between the first electronic device and the gate machine, and improve the security of the ticket checking process.

[0042] In a possible implementation, before sending the verification information to the background server, the method further comprises: determining a first project identifier based on a mapping relationship between the second device identifier and the project identifier; and determining the first OpenID based on the first project identifier, the first OpenID being generated by the first project identifier and the first account, and the first OpenID being used by the background server to verify whether the gate machine is opened.

[0043] In this way, the first project identifier can be obtained based on the second device identifier of the gate machine, and then the first OpenID can be obtained according to the first project identifier and provided to the background server, so that the background server can verify the first OpenID to determine whether to instruct the gate machine to open the gate.

[0044] In a possible implementation, the first ticket checking request further comprises the first project identifier; and before sending the verification information to the background server, the method further comprises: determining the first OpenID based on the first project identifier, the first OpenID being generated by the first project identifier and the first account, and the first OpenID being used by the background server to verify whether the gate machine is opened.

[0045] In this way, the first project identifier can be carried in the first ticket checking request, the first OpenID can be obtained according to the first project identifier and provided to the background server, so that the background server can verify the first OpenID to determine whether to instruct the gate machine to open the gate.

[0046] In a possible implementation, the first OpenID is determined based on the first item identifier, specifically including: sending, to the account cloud, the first item identifier and the first account of the first electronic device; and receiving the first OpenID sent by the account cloud.

[0047] In this way, the account cloud can generate the first OpenID based on the first item identifier and the first account sent by the first electronic device, and return the first OpenID to the first electronic device. The first electronic device does not need to store the first OpenID, and can avoid local data leakage.

[0048] In a possible implementation, the verification information further includes a first ticket identifier, the first ticket identifier being used to indicate an electronic ticket to be verified; and before the verification information is sent to the background server, the method further includes: displaying a verification selection prompt, the verification selection prompt being used to prompt a user to select the electronic ticket to be verified; and receiving a selection operation of the user to determine the first ticket identifier.

[0049] In this way, the user can select the electronic ticket to be verified according to the verification selection prompt, so that the ticket checking manner is more flexible and variable, and a better use experience is provided for the user.

[0050] In a possible implementation, the first ticket service selection request is used to request selection of an online electronic ticket service, and the first ticket service selection response is used to indicate that the first electronic device has successfully selected the online electronic ticket service.

[0051] In this way, in a case where the online electronic ticket service is successfully selected, the first electronic device can complete ticket checking by using the ticket checking method in any of the possible implementation manners.

[0052] In a possible implementation, before the first ticket service selection request sent by the gate is received, the method further includes: receiving a second ticket service selection request sent by the gate, the second ticket service selection request being used to request selection of an offline electronic ticket service; and sending, to the gate, a second ticket service selection response, the second ticket service selection response being used to indicate that the first electronic device fails to select the offline electronic ticket service.

[0053] In this way, the offline electronic ticket service can be selected preferentially, and in a case where the offline electronic ticket service fails to be selected, the online electronic ticket service can be selected.

[0054] In a possible implementation, the method further includes: receiving a first result notification sent by the gate, the first result notification being used to indicate a ticket checking result.

[0055] In this way, the first electronic device can be informed of the ticket checking result through the first result notification.

[0056] In a possible implementation, the method further includes: sending, to the gate, a first notification response, the first notification response being used to indicate that the first result notification has been successfully received.

[0057] In this way, the first electronic device can inform the gate that the first electronic device has received the first result notification through the first notification response.

[0058] In a possible implementation, before receiving the first ticket service selection request sent by the gate, the method further includes: negotiating data transmission parameters with the gate after entering a radio frequency field of the gate.

[0059] In this way, the transmission parameters of the application protocol layer (or the application layer) can be negotiated with the gate before the electronic ticket service is selected.

[0060] In a possible implementation, the negotiating the data transmission parameters specifically includes: receiving a probe frame sent by the gate, the probe frame being used to indicate that the gate supports a specified NFC protocol; sending, to the gate, a probe acknowledgement frame, the probe acknowledgement frame being used to indicate that the first electronic device supports the specified NFC protocol; receiving a notification frame sent by the gate, the notification frame carrying device characteristic information of the gate, the device characteristic information of the gate including a service identifier and a device organization identifier, the service identifier being used to indicate a type of the NFC service supported by the gate, and the device organization identifier being used to indicate a manufacturer that provides the NFC service by using the gate; determining, based on the device characteristic information of the gate, that the type of the NFC service of the gate is an electronic ticket; sending, to the gate, a notification acknowledgement frame, the notification acknowledgement frame being used to indicate that the first electronic device has received the notification frame; receiving a parameter negotiation command sent by the gate; and sending, to the gate, a parameter negotiation response in response to the parameter negotiation command, the parameter negotiation command and the parameter negotiation response being used to negotiate the data transmission parameters between the application layer of the gate and the first electronic device.

[0061] In this way, the interaction can be completed through the pre-agreed NFC protocol, and the transmission parameters of the application protocol layer are negotiated.

[0062] In a fifth aspect, the application provides a ticket checking method applied to a gate, the method comprising: sending a first ticket service selection request to a first electronic device, the first ticket service selection request being used to request selection of an electronic ticket service; receiving a first ticket service selection response sent by the first electronic device, the first ticket service selection response being used to indicate that the first electronic device has successfully selected the electronic ticket service; sending a first ticket checking request to the first electronic device, the first ticket checking request comprising a third random number and a second device identifier of the gate; receiving a first ticket checking response sent by the first electronic device, the first ticket checking response comprising the third random number and the second device identifier; when detecting that the third random number carried in the first ticket checking response is stored locally, sending a first verification request to a background server, the first verification request comprising the second device identifier; and receiving a first verification response sent by the background server, the first verification response being used to indicate whether the gate is opened or not. In this way, the gate can send the first verification request carrying the second device identifier to the background server after receiving the first ticket checking response sent by the first electronic device, and the first verification request is used to request the background server to determine whether to instruct the gate to open based on the verification information carrying the second device identifier.

[0063] In a possible implementation, the first ticket service selection request is used to request selection of an online electronic ticket service, and the first ticket service selection response is used to indicate that the first electronic device has successfully selected the online electronic ticket service.

[0064] In this way, in the case where the selection of the online electronic ticket service is successful, the gate can complete ticket checking by using the ticket checking method in any of the possible implementation manners described above.

[0065] In a possible implementation, before sending the first ticket service selection request to the first electronic device, the method further comprises: sending a second ticket service selection request to the first electronic device, the second ticket service selection request being used to request selection of an offline electronic ticket service; and receiving a second ticket service selection response sent by the first electronic device, the second ticket service selection response being used to indicate that the first electronic device fails to select the offline electronic ticket service.

[0066] In this way, the offline electronic ticket service can be selected preferentially, and in the case where the selection of the offline electronic ticket service fails, the online electronic ticket service can be selected.

[0067] In a possible implementation, the method further comprises: sending a first result notification to the first electronic device, the first result notification being used to indicate a ticket checking result.

[0068] In this way, the first electronic device can be informed of the ticket checking result through the first result notification.

[0069] In a possible implementation, the method further includes: receiving a first notification response sent by the first electronic device, the first notification response being used to indicate that the first result notification has been successfully received.

[0070] In this way, the first notification response can be used to inform the gate that the first electronic device has received the first result notification.

[0071] In a possible implementation, the method further includes: after detecting that the first electronic device enters the radio frequency field, negotiating data transmission parameters with the first electronic device.

[0072] In this way, before selecting the electronic ticket service, the gate can first negotiate the transmission parameters of the application protocol layer (or the application layer) with the first electronic device.

[0073] In a possible implementation, the method further includes: sending a probe frame to the first electronic device, the probe frame being used to indicate that the gate supports a specified NFC protocol; receiving a probe acknowledgement (Probe ACK) frame sent by the first electronic device, the Probe ACK frame being used to indicate that the first electronic device supports the specified NFC protocol; sending a notification (Notify) frame to the first electronic device, the Notify frame carrying device characteristic information of the gate, the device characteristic information of the gate including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of the NFC service supported by the gate, and the device organization identifier is used to indicate a manufacturer that provides the NFC service by using the gate; receiving a notification acknowledgement (Notify ACK) frame sent by the first electronic device, the Notify ACK frame being used to indicate that the first electronic device has received the Notify frame; sending a parameter negotiation command to the first electronic device; and receiving a parameter negotiation response sent by the first electronic device, the parameter negotiation command and the parameter negotiation response being used to negotiate the data transmission parameters between the gate and the first electronic device at the application layer.

[0074] In this way, the interaction can be completed by using the pre-agreed NFC protocol, and the transmission parameters of the application protocol layer can be negotiated.

[0075] In a sixth aspect, the present application provides a ticket checking method, applied to a background server, and the method includes: receiving verification information sent by a first electronic device, the verification information including a first gate opening identifier (OpenID) and a second device identifier of a gate; receiving a first verification request sent by the gate, the first verification request including the second device identifier; determining a first account of the first electronic device based on the first OpenID; obtaining first order information corresponding to the first account based on the first account; and sending a first verification response to the gate based on the first order information and the second device identifier, the first verification response being used to indicate whether the gate is opened or not.

[0076] In this way, the background server can determine the first verification response (i.e., whether to indicate opening the gate) based on the first OpenID in the verification information, and send the first verification response to the gate based on the second device identifier in the verification information.

[0077] In a possible implementation, the verification information further includes a first ticket identifier, the ticket identifier being used to indicate an electronic ticket to be verified; and the sending of the first verification response to the gate based on the first order information and the second device identifier specifically includes: sending the first verification response to the gate based on the first order information, the second device identifier, and the first ticket identifier.

[0078] In this way, the background server can also determine the electronic ticket to be cancelled based on the first ticket identifier, and send the first verification response to the gate in combination with the validity period and the verification state of the electronic ticket to be cancelled in the first order information.

[0079] In a seventh aspect, the present application provides a ticket checking system, including a first electronic device, a gate, and a background server; wherein the first electronic device is configured to implement the ticket checking method in any of the possible implementation manners of the fourth aspect, the gate is configured to implement the ticket checking method in any of the possible implementation manners of the fifth aspect, and the background server is configured to implement the ticket checking method in any of the possible implementation manners of the sixth aspect.

[0080] In an eighth aspect, the present application provides an electronic device, including one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are configured to store computer instructions, and when the one or more processors execute the computer instructions, implement the ticket checking method in any of the possible implementation manners of any of the aspects.

[0081] In a ninth aspect, the present application provides a chip system, including: a processing circuit and an interface circuit, the interface circuit being configured to receive code instructions and transmit the code instructions to the processing circuit, and the processing circuit being configured to run the code instructions to execute the ticket checking method in any of the possible implementation manners of any of the aspects.

[0082] In a tenth aspect, the present application provides a readable storage medium, storing computer instructions, and when the computer instructions are executed by a processor, implement the ticket checking method in any of the possible implementation manners of any of the aspects.

[0083] In an eleventh aspect, the present application provides a computer program product, including computer instructions, and when the computer program is executed by a processor, implement the ticket checking method in any of the possible implementation manners of any of the aspects.

[0084] The beneficial effects of the third aspect can refer to the beneficial effects of the first and second aspects described above, the beneficial effects of the seventh aspect can refer to the beneficial effects of the fourth to sixth aspects described above, and the beneficial effects of the eighth to eleventh aspects can refer to the beneficial effects of the first to second aspects or the fourth to sixth aspects described above. BRIEF DESCRIPTION OF DRAWINGS

[0085] FIG. 1 is a schematic diagram of an NFC working principle provided in an embodiment of the present application;

[0086] FIG. 2A is a schematic diagram of a system architecture of a ticket checking system provided in an embodiment of the present application;

[0087] FIG. 2B is a schematic diagram of a device form of a gate provided in an embodiment of the present application;

[0088] FIG. 2C is a schematic diagram of an architecture of a cloud server provided in an embodiment of the present application;

[0089] FIG. 3A is a schematic diagram of a structure of an electronic device provided in an embodiment of the present application;

[0090] FIG. 3B is a schematic diagram of a layered architecture of an electronic device provided in an embodiment of the present application;

[0091] FIG. 3C is a schematic diagram of a framework of an NFC protocol stack provided in an embodiment of the present application;

[0092] FIGS. 4A-4G are a set of schematic diagrams of ticket purchase interfaces provided in an embodiment of the present application;

[0093] FIGS. 5A-5D are schematic diagrams of interfaces of a ticket checking method provided in an embodiment of the present application;

[0094] FIG. 6A is a schematic diagram of a ticket purchase process provided in an embodiment of the present application;

[0095] FIG. 6B is a schematic diagram of a process of synchronizing ticket information based on the same account provided in an embodiment of the present application;

[0096] FIG. 7 is a schematic diagram of a ticket checking method provided in an embodiment of the present application;

[0097] FIG. 8 is a schematic diagram of a process in which a gate verifies an OpenID through a ticketing system provided in an embodiment of the present application;

[0098] FIG. 9 is a schematic diagram of a process in which an electronic device determines an OpenID based on a project identifier provided in an embodiment of the present application;

[0099] FIG. 10 is a schematic diagram of a registration process of registering a project identifier and a device identifier of a gate on an electronic ticket business cloud provided in an embodiment of the present application;

[0100] FIG. 11 is a flow diagram of a process of sharing an electronic ticket with another electronic device according to an embodiment of the present application;

[0101] FIG. 12 is a diagram of a hardware structure of an electronic device according to an embodiment of the present application;

[0102] FIGS. 13-16 are diagrams of a set of communication devices according to embodiments of the present application;

[0103] FIG. 17 is a diagram of a hardware structure of a server according to an embodiment of the present application;

[0104] FIG. 18 is a flow diagram of a ticket checking method according to an embodiment of the present application;

[0105] FIG. 19 is a flow diagram of a ticket checking method according to an embodiment of the present application;

[0106] FIG. 20 is a diagram of interactions between an electronic device, a gate, and a cloud server during a ticket checking process according to an embodiment of the present application;

[0107] FIG. 21 is a flow diagram of a ticket purchasing process according to an embodiment of the present application;

[0108] FIG. 22A is a flow diagram of a ticket checking method according to an embodiment of the present application;

[0109] FIG. 22B is a flow diagram of a process in which a gate and an electronic device select offline electronic ticket services or online electronic ticket services through one or more rounds of ticket service selection requests and ticket service selection responses according to an embodiment of the present application;

[0110] FIG. 23 is a flow diagram of a ticket checking method according to an embodiment of the present application;

[0111] FIG. 24 is a flow diagram of a process in which a meta-service and an account cloud interact to obtain a gate opening identifier corresponding to a target identifier 1 according to an embodiment of the present application;

[0112] FIG. 25 is a flow diagram of a process in which a scenic spot background determines whether a gate opening identifier is valid according to an embodiment of the present application;

[0113] FIG. 26 is a flow diagram of a ticket checking method according to an embodiment of the present application;

[0114] FIGS. 27A-27C are diagrams of interfaces in which an electronic device outputs a verification selection prompt according to embodiments of the present application;

[0115] FIG. 28 is a flow diagram of a process in which an electronic device and a gate interact to complete ticket checking when offline electronic ticket services are selected according to an embodiment of the present application. DETAILED DESCRIPTION

[0116] The technical solutions in the embodiments of the present application will be described clearly and thoroughly below with reference to the drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; the "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0117] Hereinafter, the terms "first" and "second" are used for descriptive purposes only, and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two.

[0118] The term "user interface (UI)" in the following embodiments of the present application is a medium interface for interaction and information exchange between an application program or an operating system and a user, which 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, extensible markup language (XML), etc. The interface source code is parsed, rendered and finally presented as content that can be recognized by the user on the electronic device. The commonly used form of user interface is graphic user interface (GUI), which refers to a user interface related to computer operation displayed in a graphical manner. It can be a visual interface element such as text, icon, button, menu, tab, text box, dialog box, status bar, navigation bar, Widget, etc. displayed in the display screen of the electronic device.

[0119] The working principle of near field communication (NFC) technology in the embodiments of the present application will be introduced below.

[0120] FIG. 1 shows a schematic diagram of the working principle of NFC provided in the embodiments of the present application.

[0121] As shown in FIG. 1, the two parties that communicate using NFC technology can include a proximity coupling device (PCD) (also referred to as an NFC card reader) and a proximity integrated circuit card (PICC). The PCD can achieve proximity contactless communication with the PICC. The PCD and the PICC can allow near field communication at a specific data rate (for example, 106, 212, 424, or 848 kilobit per second (kbps)) and a specific frequency (for example, 13.56 MHz). The communication between the PCD and the PICC can occur within a close distance, for example, within a range of about 2 to 4 centimeters, between the PCD and the PICC.

[0122] The PCD can generate high-frequency alternating current to generate a radio frequency field at a specified frequency (for example, 13.56 MHz) and transmit data to the PICC through the radio frequency field. After the PICC is close to the PCD, the PICC can induct the radio frequency field emitted by the PCD. The PICC can obtain energy from the radio frequency field of the PCD through electromagnetic induction after entering the radio frequency field emitted by the PCD, and generate power by the obtained energy to drive the circuit inside the PICC, analyze the data transmitted by the PCD through the radio frequency field, and thus achieve data transmission from the PCD to the PICC. The PICC can also send data to the PCD in a manner of load modulating the radio frequency field, and thus achieve data transmission from the PICC to the PCD.

[0123] In the embodiments of the present application, the PICC can be a physical NFC tag card, and some NFC devices (for example, mobile phones, tablets, smart watches, and other electronic devices) can also simulate themselves into a PICC that conforms to NFC related standards by using the data of an NFC simulation card, to achieve the function of the PICC and communicate with the PCD based on NFC technology.

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

[0125] FIG. 2A shows a system architecture diagram of a ticket checking system 10 provided in an embodiment of the present application.

[0126] As shown in FIG. 2A, the ticket checking system 10 can include an electronic device 100, a gate 200, and a cloud server 300. Optionally, the ticket checking system 10 can also include an electronic device 400, and the like. The electronic device 100 can simulate itself into a PICC that conforms to NFC related standards by using the data information of an NFC simulation card, to achieve the function of the PICC. The gate 200 can communicate with the electronic device 100 in the PICC mode based on NFC technology as a PCD.

[0127] In a possible implementation, the electronic device 100 can support both the PICC mode and the PCD mode. In the PCD mode, the electronic device 100 can transmit a radio frequency field as a PCD to communicate with a PICC. In the PICC mode, the electronic device 100 can passively receive a radio frequency field transmitted by a PCD, and communicate with the PCD based on the NFC technology through the load modulation technology.

[0128] In the embodiments of the present application, after the NFC function is turned on, the electronic device 100 can be in the PICC mode. If the electronic device 100 supports both the PCD mode and the PICC mode, after the NFC function is turned on, the electronic device 100 can switch between the PICC mode and the PCD mode.

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

[0130] When the electronic device 100 enters the radio frequency field of the gate 200, the electronic device 100 can communicate with the gate 200 based on the NFC technology. The electronic device 100 can receive the project identifier 1 and the device identifier of the gate 200 sent by the gate 200. The electronic device 100 can obtain an open gate identifier (OpenID) based on the project identifier 1 and the account logged in by the electronic device 100, and the OpenID can be used to indicate whether the account logged in by the electronic device 100 purchases the electronic ticket corresponding to the project identifier 1. The electronic device 100 can also verify whether the device identifier of the gate 200 is valid through the cloud server 300. In the case that the device identifier of the gate 200 is valid, the electronic device 100 can send the OpenID to the gate 200. In the case that the account of the electronic device 100 purchases the electronic ticket corresponding to the project identifier 1 (i.e., the OpenID is bound with the electronic ticket corresponding to the project identifier 1), the electronic device 100 can receive the ticket checking success notification sent by the gate 200, and the ticket checking success notification can be used to notify the electronic device 100 that the ticket checking is successful. After receiving the ticket checking success notification sent by the gate 200, the electronic device 100 can also output the ticket checking success prompt, and the ticket checking success prompt is used to prompt the user that the ticket checking is successful. In the case that the account of the electronic device 100 does not purchase the electronic ticket corresponding to the project identifier 1 (i.e., the OpenID is not bound with the electronic ticket corresponding to the project identifier 1), the electronic device 100 can receive the ticket checking failure notification sent by the gate 200, and the ticket checking failure notification is used to notify the electronic device 100 that the ticket checking fails. Optionally, the ticket checking failure notification can also trigger the electronic device 100 to start the ticket purchasing process, or trigger the electronic device 100 to display the ticket purchasing interface, and the ticket purchasing interface can be used to purchase the electronic ticket corresponding to the project identifier 1.

[0131] When the electronic device 100 enters the radio frequency field of the gate 200, the gate 200 can communicate with the electronic device 100 based on the NFC technology. The gate 200 can send a device identifier of the gate 200 to the electronic device 100, and the device identifier of the gate 200 can be used to verify whether the gate 200 is valid. The gate 200 can receive the gate opening identifier sent by the electronic device 100 and verify whether the gate opening identifier is valid. The validity of the gate opening identifier means that the electronic ticket bound to the gate opening identifier is a valid electronic ticket that can be verified by the gate 200. In some embodiments, the determination criteria of the validity of the gate opening identifier can include any one or more of the following: the electronic ticket bound to the gate opening identifier belongs to the electronic ticket corresponding to the gate 200, the gate opening identifier has not been verified, and the gate opening identifier is still within the validity period. When verifying the validity of the gate opening identifier, the gate 200 can perform any one or more of the following verification steps: querying whether there is a ticket purchase record corresponding to the gate opening identifier; determining whether the gate opening identifier has been verified; determining whether the validity period of the gate opening identifier includes the ticket checking time, etc. After confirming the validity of the gate opening identifier, the gate 200 can open and release. In the case where the gate opening identifier is determined to be invalid, in some embodiments, the gate 200 can send a ticket checking failure notification to the electronic device 100, and the ticket checking failure notification is used to notify the electronic device 100 of the ticket checking failure.

[0132] The cloud server 300 can be a server cluster, which can include one or more servers (or server modules) that can belong to different operators. The specific architecture of the cloud server 300 can refer to the related description in the following embodiment shown in FIG. 2C, which is not described in detail here. In some embodiments, in the process of purchasing a specified electronic ticket, the cloud server 300 can interact with the electronic device 100 to generate a gate opening identifier corresponding to the electronic ticket. Optionally, the cloud server 300 can send the gate opening identifier to the electronic device 100. The cloud server 300 can also store the correspondence between the account of the electronic device 100 and the gate opening identifier corresponding to the electronic ticket. In the ticket checking process, the cloud server 300 can provide verification services for the gate 200, i.e., verifying whether the gate opening identifier is valid, and sending the verification result to the gate 200. In some embodiments, the cloud server 300 can also provide the gate opening identifier for the electronic device 100, i.e., the electronic device 100 can obtain the corresponding gate opening identifier from the cloud server 300 based on the device identifier of the gate 200 and the account of the electronic device 100.

[0133] The function description of the electronic device 400 can also refer to the related function description of the electronic device 100 described above. In addition, in some embodiments, the electronic device 400 can also log in the account of the electronic device 100, and obtain the ticket information of the electronic ticket purchased by the user through the account of the electronic device 100 from the cloud server 300. In other embodiments, the electronic device 400 can also receive the ticket sharing request of the electronic device 100, and obtain the ticket information of the electronic ticket specified in the ticket sharing request.

[0134] In the embodiments of the present application, the device type of the electronic device 100 can be any one of a mobile phone, a tablet computer, a handheld computer, a desktop computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), a smart large screen, a smart speaker, a wearable device such as a smart bracelet or a smart watch, an augmented reality (AR), a virtual reality (VR), a mixed reality (MR), an extended reality (XR) device, a vehicle-mounted device or a smart city device, and the like.

[0135] It can be understood that the above-mentioned embodiment shown in FIG. 2A is only an example, and in the embodiments of the present application, the ticket checking system 10 can also include more, less or different electronic devices than the above-mentioned embodiment. In other embodiments, the electronic device for purchasing tickets can also be an electronic device different from the electronic device 100 (for example, other electronic devices logged in the same account as the electronic device, etc.), which is not limited in the present application.

[0136] The device form of the gate machine 200 and the positional relationship between the electronic device 100 and the gate machine 200 when performing NFC communication will be introduced below.

[0137] FIG. 2B shows a device form diagram of a gate machine 200 according to an embodiment of the present application.

[0138] As shown in FIG. 2B, the gate machine 200 can include one or more upright posts 201 and one or more flaps 202, wherein the upright posts 201 can be fixed on the ground or other plane, and the flaps 202 can be arranged on the upright posts 201 and rotatable. The flaps 202 can include two states of opening and closing, when the flaps 202 are in the closing state, the included angle between the flaps 202 and the upright posts 201 can be approximately equal to 90°, at this time, the flaps 202 can block the user from passing through the channel between the upright posts 201; when the flaps 202 are in the opening state, the included angle between the flaps 202 and the upright posts 201 can be approximately equal to 0° (or 180°), at this time, the user can pass through the channel between the upright posts 201. The upright posts 201 can also be provided with a card swiping area 203, the card swiping area 203 can be used to contact the electronic device 100, so as to communicate with the electronic device 100 based on the NFC technology. As shown in FIG. 2B, when the electronic device 100 contacts the card swiping area 203, and the gate machine 200 checks the ticket successfully, the flaps 202 can change from the closing state to the opening state, so as to facilitate the user to pass through.

[0139] It can be understood that the embodiment shown in FIG. 2B is only an example, in the embodiments of the present application, the gate machine 200 can also adopt different device forms from the embodiment shown in FIG. 2B, for example, having more, less or different forms of upright posts and flaps from the embodiment shown in FIG. 2B, in addition, the card swiping area 203 can also be arranged at different positions from the above-mentioned embodiments, which are not limited herein.

[0140] The following introduces the architecture of a cloud server 300 provided by the embodiments of the present application.

[0141] FIG. 2C shows an interaction schematic diagram of the electronic device 100, the gate machine 200 and each server in the cloud server 300 according to the embodiments of the present application.

[0142] As shown in FIG. 2C, the cloud server 300 can include one or more servers (or server modules), for example, an electronic ticket service cloud 310 (also referred to as an electronic ticket service cloud 310), an account cloud 320, a ticket system 330, etc. The one or more servers can be respectively arranged at different positions and operated by one or more operators. The physical positions of the modules in the cloud server 300 are not limited herein. Among them:

[0143] The electronic ticket service cloud 310 can store the device identifiers of one or more gate machines (e.g., the gate machine 200, etc.), and can also store one or more item identifiers (e.g., the identifiers of attractions, performances, competitions, and gatherings, etc.). The electronic ticket service cloud 310 can also store the correspondence between the item identifiers and the gate machine identifiers. The electronic ticket service cloud 310 can manage the stored device identifiers and item identifiers, and can also provide validity verification services for the device identifiers and item identifiers. In some embodiments, for example, in the process of purchasing a ticket by the electronic device 100, the electronic ticket service cloud 310 can establish a communication connection with the electronic device 100 and the account cloud 320, receive an item identifier sent by the electronic device 100, verify whether the item identifier is valid, and send the account of the electronic device 100 and the item identifier to the account cloud 320 after determining that the item identifier is valid. In some embodiments, for example, in the process of checking a ticket, the electronic ticket service cloud 310 can also establish a communication connection with the electronic device 100 (or other electronic devices), receive a device identifier of the gate machine 200 (or other gate machines) sent by the electronic device 100, verify the validity of the device identifier, and return the verification result to the electronic device 100. In some embodiments, the electronic ticket service cloud 310 can also store the correspondence between the account of the electronic device 100 and the ticket information purchased by the electronic device 100, and optionally, can also store the open gate identifier (OpenID) corresponding to the ticket information.

[0144] The account cloud 320 can provide account registration, authentication, and de-registration, and other account management services. The account cloud 320 can establish a communication connection with the electronic device 100. When a user purchases a ticket using the electronic device 100, the account cloud 320 can obtain the item identifier corresponding to the electronic ticket purchased by the user based on the communication connection with the electronic device 100. The account cloud 320 can also establish a communication connection with the electronic ticket service cloud 310. In some embodiments, the account cloud 320 can generate an open gate identifier (OpenID) based on the account of the electronic device 100 and the item identifier. After generating the open gate identifier (OpenID), the account cloud 320 can send the open gate identifier (OpenID) to the electronic device 100 (e.g., by returning the open gate identifier (OpenID) to the electronic device 100 through the electronic ticket service cloud 310). In some embodiments, when the user checks a ticket, the account cloud 320 can also return the corresponding open gate identifier to the electronic device 100 based on the account of the electronic device 100 and the item identifier sent by the electronic device 100.

[0145] In some embodiments, the electronic ticket service cloud 310 and the account cloud 320 in the cloud server 300 can also constitute a service system, which can interact with the electronic device 100 (or other electronic devices) to complete the purchase of an electronic ticket.

[0146] The ticket system 330 can correspond to one or more project identifiers. In some embodiments, the ticket system 330 can be a server providing services for a single project (e.g., a scenic spot A, a show B, or a game C, etc.), in which case the ticket system 330 can correspond to a unique project identifier, and the ticket system 330 can provide services such as purchase and verification of electronic tickets for the project indicated by the project identifier. In other embodiments, the ticket system 330 can be a server providing services for multiple projects (e.g., multiple scenic spots, multiple show projects, multiple projects in a designated scenic spot, etc.), in which case the ticket system 330 can correspond to multiple project identifiers, and the ticket system 330 can provide services such as purchase and verification of electronic tickets for multiple projects corresponding to the multiple project identifiers.

[0147] The ticket system 330 can establish a communication connection with a terminal device used by a user such as the electronic device 100. The ticket system 330 can have one or more client applications and / or applets (e.g., the ticket application 12, the wallet application 13, etc. in the embodiment shown in FIG. 3B described below) that are matched. The ticket system 330 can communicate and interact with an electronic device (e.g., the electronic device 100) that installs any of the above-mentioned client applications or applets. The ticket system 330 can provide online ticket purchase services for the electronic device 100, and the user can purchase tickets through any of the above-mentioned client applications or applets. After the user purchases tickets using the electronic device 100, the ticket system 330 can obtain and store ticket information of electronic tickets purchased by the user through the electronic device 100 and corresponding gate opening identifiers, and bind the gate opening identifiers and the ticket information. When storing the gate opening identifiers, the ticket system 330 can also store the verification status of the gate opening identifiers, which can include unverified and verified, and the verification status is used to indicate whether the electronic ticket corresponding to the gate opening identifier has been used. The ticket system 330 can also establish a communication connection with a gate machine (e.g., the gate machine 200). When the user checks tickets through the electronic device 100, the ticket system 330 can receive the gate opening identifier reported by the gate machine 200 (i.e., the gate opening identifier obtained by the gate machine 200 from the electronic device 100). The ticket system 330 can determine whether the gate opening identifier is valid. If the gate opening identifier is valid, the ticket system 330 can update the verification status of the gate opening identifier stored by it, and notify the gate machine 200 to open the gate. If the gate opening identifier is invalid, the ticket system 330 can notify the gate machine 200 that the gate opening identifier is invalid.

[0148] It can be understood that the above-mentioned embodiment shown in FIG. 2C is only an example, and in the embodiments of the present application, any one of the above-mentioned servers can also be split into multiple servers, and any two or more servers can also be combined into one server, which is not limited herein. In addition, the cloud server 300 can further include more, less or different servers (or server modules) than the above-mentioned embodiments, and each server can have more, less or different functions than the above-mentioned embodiments, which is not limited herein.

[0149] The structure of an electronic device 100 provided in an embodiment of the present application is introduced below.

[0150] FIG. 3A shows a structure of an electronic device 100 provided in an embodiment of the present application.

[0151] As shown in FIG. 3A, the electronic device 100 can include a processor 101 and an NFC module 102. One or more applications can be run in the processor 101. The one or more applications can include one or more of a wallet application, one or more host-based card emulation (HCE) applications, and the like. Optionally, the electronic device 100 can further include a secure element (SE) 103 and / or a subscriber identity module (SIM) card. The processor 101 can be connected with the NFC module 102, the SE 103, and the SIM card 104, respectively. The NFC module 102 can also be connected with the SE 103 and the SIM card 104.

[0152] The NFC module 102 can include an NFC controller (not shown in FIG. 3A), an NFC transceiver (not shown in FIG. 3A), and an NFC memory (not shown in FIG. 3A). The NFC controller can be connected with the processor 101, and the NFC controller can also be connected with the NFC transceiver and the NFC memory, respectively.

[0153] The NFC controller is mainly used for modulating and demodulating non-contact 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 realize the transmission and reception of NFC signals (for example, 13.56 MHz radio frequency signals), which can include an electromagnetic compatibility (EMC) filter circuit, a matching circuit, a receiving circuit, and an NFC antenna, etc., wherein the NFC antenna can be a loop antenna, which is used to realize the proximity-based non-contact communication capability of the NFC module 102. The NFC memory can be used to store data transmitted by the NFC module 102 to the gate 200, and data received from the gate 200. In some embodiments, the NFC memory can be one memory that can be shared by the above components in the NFC module 102, for example, some data in the NFC memory can be called by the NFC controller, and other data can be called by the SE 103.

[0154] In other embodiments, the NFC memory can also be a collection of multiple memories, for example, the NFC controller can include a first memory of the multiple memories, the first memory can include instructions or data used or recycled by the NFC controller, and if the NFC controller needs to use the instructions or data again, the instructions or data can be directly called from the first memory, so as to reduce the waiting time of the NFC controller. The SE 103 can include a second memory of the multiple memories. The second memory can include card information of a NFC emulation card based on the secure element, etc., so that if the SE 103 needs to read the card information of the NFC emulation card, the card information of the NFC emulation card can be read from the second memory in the SE 103. The SIM card 104 can include a third memory of the multiple memories. The third memory can include card information of a NFC emulation card based on the SIM card, etc., so that if the SIM card 104 needs to read the card information of the NFC emulation card, the card information of the NFC emulation card can be read from the third memory in the SIM card 104.

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

[0156] The SE 103 and the NFC module 102 can be two independent chips. Alternatively, the SE 103 and the NFC module 102 can be packaged in one chip.

[0157] The electronic device 100 can open one or more NFC emulation cards in the application according to the user's input, so as to enable the electronic device 100 to support one or more NFC services. The business processing logic of the NFC emulation card in the electronic device 100 is implemented by an Applet. The Applet can be stored and run in the hardware device or software module (for example, HCE application, SIM card, SE, etc.) corresponding to the NFC emulation card.

[0158] The card emulation mode on the electronic device 100 can be divided into a hardware-based virtual card mode and a software-based HCE mode. In the hardware-based virtual card mode,

[0159] 1. In the hardware-based virtual card mode, the electronic device 100 can provide the running environment of the Applet of the NFC emulation card and the storage and processing of the business data of the NFC emulation card through the SE 103 or the SIM card 104. The NFC module 102 as the front end of the contactless communication forwards the command received from the external PCD to the SE 103 or the SIM card 104, and then the Applet in the SE 103 or the SIM card 104 processes it and sends the response data to the external PCD through the NFC module 102. The user can open one or more NFC emulation cards in the wallet application, and the wallet application can write the Applet and card data of the one or more NFC emulation cards into the SE 103. Alternatively, the user can open one or more NFC emulation cards in the SIM card application. The SIM card application can write the Applet and card data of the one or more NFC emulation cards into the SIM card 104 for storage.

[0160] 2. In the software-based HCE mode, the HCE application running in the processor 101 can provide a running environment of the Applet corresponding to the NFC emulation card and storage and processing of the service data of the NFC emulation card. After receiving a command sent by an external PCD, the 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 send the response data to the NFC module 102. The NFC module 102 can send the response data to the external PCD. The user can open one or more NFC emulation cards in the HCE application, and the HCE application can run the Applet of the one or more NFC emulation cards and save the card data of the NFC emulation card on the local storage of the electronic device 100 or on the cloud server.

[0161] 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. The common management functions can include file management, card long activation, security management, service routing management, and the like.

[0162] Exemplarily, in the above-mentioned card emulation scenario, the electronic device 100 is installed with a native application related to NFC, and the user can also download and install a third-party application in the electronic device 100 through an application store. Generally, the native application can adopt a hardware-based virtual card scheme, and the third-party application can adopt an HCE scheme. The native application can be a wallet application, and the third-party application can be, for example, a ticket application, a payment application, and the like. The above examples are only used to explain the present application and should not be construed as limiting.

[0163] The layered architecture of the electronic device 100 provided by an embodiment of the present application is introduced below.

[0164] FIG. 3B shows a schematic diagram of the layered architecture of the electronic device 100 provided by an embodiment of the present application.

[0165] As shown in FIG. 3B, the electronic device 100 can include an application layer, a system layer, and a hardware layer.

[0166] The ticket application 12 and / or the wallet application 13 can be included in the application layer. The ticket application 12 (or the wallet application 13) can be used to purchase electronic tickets, such as scenic spot tickets, exhibition tickets, show tickets, and game tickets. The ticket application 12 (or the wallet application 13) can also be used to manage the electronic tickets purchased by the user.

[0167] The system layer can include an electronic ticket service 11 and an NFC protocol stack 14. The specific architecture of the NFC protocol stack 14 can refer to the description of the embodiment shown in FIG. 3C below, and will not be described in detail here. The electronic ticket service 11 can be used to communicate with the servers such as the account cloud 320 and the electronic ticket business cloud 310 based on the account logged in by the electronic device 100. In some embodiments, the electronic ticket service 11 can also interact with the ticket application 12, the wallet application 13 and the like to obtain the opening gate identifier stored in the above applications.

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

[0169] It can be understood that the embodiment shown in FIG. 3B is only an example, and in the embodiments of the present application, the electronic device 100 can include more, less or different hierarchical structures than the above embodiments, and each hierarchy can also include more, less or different modules than the above embodiments, which are not limited in the present application.

[0170] Next, an NFC protocol stack 14 provided in the embodiments of the present application is introduced.

[0171] FIG. 3C shows a schematic diagram of the framework of an NFC protocol stack 14 provided in the embodiments of the present application.

[0172] As shown in FIG. 3C, the NFC protocol stack can include a physical layer, a radio frequency layer, an access layer, a transport layer and an application protocol layer, etc.

[0173] The physical layer can be used to implement the physical characteristics during NFC communication.

[0174] The radio frequency layer can be used to implement the radio frequency specifications during NFC communication, such as data rate, frequency of radio frequency signals, etc.

[0175] The access layer can be used to implement the functions of polling and device discovery, service result notification, card conflict management, transmission protocol negotiation, timeout and retransmission mechanism, PICC / PCD mode switching, fusion card selection, etc.

[0176] The transport layer includes a high-speed data transmission protocol, through which the data transmission between the PCD and the PICC in the application layer can be realized.

[0177] The application protocol layer can be used to implement one or more NFC services and one or more service management strategies. The one or more NFC services can include codeless payment, electronic ticket, access control, digital ID card, full-scene tap-to-tap, near field data transmission, etc. The one or more service management strategies can include any one or more of file management, card long activation, security management, and service routing management, etc. The processing logic of the NFC service can be executed by the Applet. In a possible implementation, the processing logic of the service management strategy can be executed by the NFC base service module.

[0178] In the embodiments of the present application, the NFC protocol stack shown in FIG. 3C can be referred to as a first protocol stack.

[0179] The present application provides a ticket checking method. The electronic device 100 can communicate with the gate 200 based on the NFC technology, and determine the gate opening identifier 1 (OpenID_1) based on the project identifier 1 and the account of the electronic device 100 (i.e. the account logged in by the electronic device 100). The electronic device 100 can send the OpenID_1 to the gate 200, and the gate 200 verifies whether the OpenID_1 is valid, i.e. whether the OpenID_1 is bound with the electronic ticket corresponding to the project identifier 1. In the case that the OpenID_1 is bound with the electronic ticket corresponding to the project identifier 1, the electronic device 100 can receive the ticket checking success notification sent by the gate 200, which can be used to notify the electronic device 100 that the ticket checking is successful, and the gate 200 has opened the gate to release.

[0180] In this way, when checking the ticket, the user can complete the ticket checking through the touch between the electronic device 100 and the gate 200, which simplifies the ticket checking steps and improves the ticket checking efficiency.

[0181] FIGS. 4A-4G show a set of ticket purchase interface schematic diagrams provided by the embodiments of the present application.

[0182] As shown in FIG. 4A, the electronic device 100 can display a desktop 400 having a page with application icons displayed thereon, which includes a plurality of application icons (e.g., a reading application icon, a settings application icon, a ticket application icon 404, a browser application icon, etc.). Optionally, the page with application icons can further include a page indicator 402 below the page with application icons, which indicates the total number of pages on the desktop and the position of the currently displayed page relative to other pages. For example, the desktop 400 can include three pages, and the black dot in the page indicator can indicate that the currently displayed page is the first page from the left among the three pages. Optionally, the page with application icons can further include a status bar 401 above the page with application icons, which can include an indicator of the strength of a communication signal, a power level, a time, etc. Further optionally, the page indicator can further include a dock area 403 below the page indicator, which can include one or more dock icons (e.g., a dialer application icon, an information application icon, a contacts application icon, a camera application icon, etc.), which can remain displayed when the page is switched.

[0183] The electronic device 100 can receive and respond to a user’s click operation on the ticket application icon 404 to display a ticket application interface 410 as shown in FIG. 4B.

[0184] As shown in FIG. 4B, the ticket application interface 410 can include one or more items, each of which can correspond to an item, such as a scenic spot, a performance, an exhibition, etc. In some embodiments, the one or more items can include items in a city where the electronic device 100 is located, or can include items in a city searched by the user. For example, the one or more items can include a zoo item 411, a museum item, a flower art exhibition item, etc. Each item can include one or more of the following information: an item name, an item picture, a ticket price, a rating, a ticket purchase control (or a ticket purchase link), etc. For example, the zoo item 411 can include an item name “zoo”, a picture 411b, a ticket price “50 yuan for adults, 25 yuan for students”, a rating “4.8 stars”, and a ticket purchase control 411a. The ticket purchase control 411a can be used to trigger the electronic device 100 to display a ticket purchase interface of the zoo. In some embodiments, the ticket application interface 410 can further include a search box 412 and a search control 413, the search box 412 can be used to display an item name input by the user, and the search control 413 can be used to trigger the electronic device 100 to search for and display search results for the item displayed in the search box 412.

[0185] The electronic device 100 can receive and respond to a click operation of the user on the ticket purchase control 411a in the zoo item 411 to display a ticket purchase interface 420 as shown in FIG. 4C.

[0186] As shown in FIG. 4C, the ticket purchase interface 420 can include one or more ticket purchase items, such as an adult ticket purchase item 422, a student ticket purchase item 423, a child ticket purchase item, a family package ticket item, etc. Each ticket purchase item can include a ticket type and a ticket price, respectively indicating the ticket type and the price of the ticket purchase item. In addition, the ticket purchase item can further include a reservation control for triggering the electronic device 100 to display an order submission interface corresponding to the ticket purchase item. For example, the adult ticket purchase item 422 can display the price of the adult ticket, i.e. 50 yuan, and the adult ticket purchase item 422 can further include a reservation control 422a for triggering the electronic device 100 to display an order submission interface of the adult ticket; for another example, the student ticket purchase item 423 can display the price of the student ticket, i.e. 25 yuan, and the student ticket purchase item 423 can further include a reservation control 423a for triggering the electronic device 100 to display an order submission interface of the student ticket, etc. Optionally, the ticket purchase interface 420 can further include one or more pictures 421, which can be pictures of the zoo item corresponding to the current ticket purchase interface 420. In some embodiments, the one or more pictures 421 can also be replaced by a video, which is not limited herein.

[0187] The electronic device 100 can receive and respond to a click operation of the user on the reservation control 422a in the adult ticket purchase item 422 to display an order submission interface 430 as shown in FIG. 4D.

[0188] As shown in FIG. 4D, the order submission interface 430 can include one or more order parameter setting bars, such as a date setting bar 431, a quantity setting bar 432, and the like. The date setting bar 431 can be used to select the use date of the electronic ticket. For example, the date setting bar 431 can include one or more dates, and can further include a selected identifier 431a, which can be used to prompt the user of the currently selected date, i.e., 05-21 (tomorrow). Alternatively, the date setting bar 431 can further display a text prompt, such as "slide to select date", which can be used to prompt the user to select the use date of the electronic ticket. The quantity setting bar 432 can include an increase control 432a, a decrease control 432b, a quantity prompt 432c, and the like. Among them, the quantity prompt 432c can be used to prompt the user of the number of tickets corresponding to the current order, the increase control 432a can be used to increase the number of tickets corresponding to the current order, and the decrease control 432b can be used to trigger the electronic device 100 to decrease the number of tickets corresponding to the current order. Alternatively, the quantity setting bar 432 can further include a text prompt, such as "X tickets per order", which can be used to prompt the user of the maximum number of tickets that can be purchased per order. The order submission interface 430 can further include a total price prompt 434 and a submit order control 433. The total price prompt can be used to prompt the user of the total price of all electronic tickets in the current order, and the submit order control 433 can be used to trigger the electronic device 100 to submit the current order and display a payment window or a payment interface.

[0189] The electronic device 100 can receive and respond to the user's click operation on the submit order control 433, and display a payment window 440 as shown in FIG. 4E.

[0190] As shown in FIG. 4E, the payment window 440 can include a payee, a payment amount, a payment method, and a payment verification prompt 441, which can be used to prompt the user to verify the payment identity. For example, the payment verification prompt 441 can be the fingerprint verification prompt shown in FIG. 4E, which can be used to prompt the user to verify the fingerprint before payment. In some other embodiments, the payment verification prompt 441 can also be used to instruct the user to verify the payment password, verify the face, and the like, which are not limited in the present application.

[0191] The electronic device 100 can receive and respond to the user's operation of completing the payment verification (such as verifying the fingerprint, etc.), and display a ticket purchase success interface 450 as shown in FIG. 4F. In some other embodiments, if the electronic device 100 enables small amount payment without password, and the payment amount in the order is not greater than a preset payment amount without password, the electronic device 100 can also receive and respond to the user's click operation on the submit order control 433, and display the ticket purchase success interface 450 as shown in FIG. 4F.

[0192] As shown in FIG. 4F, the ticket purchase success interface 450 can include a ticket purchase success prompt 451, which can be used to prompt the user that the ticket purchase is successful. The ticket purchase success prompt 451 can include basic information of the electronic ticket purchased, such as the corresponding project, the ticket type, and the number of tickets, etc. As shown in the ticket purchase success prompt 451 in FIG. 4F, the electronic ticket purchased this time is an adult ticket for the zoo, and the number of tickets purchased is one. Optionally, the ticket purchase success interface 450 can further include any one or more of the following controls, such as a view ticket folder control 452 and a continue to purchase control 453. The view ticket folder control 452 can be used to trigger the electronic device 100 to display the purchased electronic ticket, and the continue to purchase control 453 can be used to trigger the electronic device 100 to return to the ticketing application interface 410 shown in FIG. 4B.

[0193] The electronic device 100 can receive and respond to the user's click operation on the view ticket folder control 452 to display an electronic ticket folder interface 460 as shown in FIG. 4G.

[0194] As shown in FIG. 4G, the electronic ticket folder interface 460 can include one or more ticket entries, each of which can correspond to one or more electronic tickets that have been purchased by the user of the electronic device 100. The one or more ticket entries can include a zoo ticket 461 and a flower art exhibition ticket 462, etc. Each ticket entry can include basic information of the electronic ticket corresponding to the ticket entry, such as the project name, the ticket type, the number of tickets, the ticket validity period, and the verification status, etc., wherein the verification status of the ticket can be used to indicate whether the corresponding electronic ticket has been verified. As shown in the zoo ticket 461 and the flower art exhibition ticket 462 in FIG. 4G, the user has purchased one adult ticket for the zoo, the validity period of the adult ticket is 05-21, and the adult ticket has not been verified; the user has purchased two adult tickets for the flower art exhibition, and the validity period of the two adult tickets is before 05-23, and the two adult tickets have not been verified. Optionally, the electronic ticket folder interface 460 can further include one or more sorting and filtering controls 463, which can be used to trigger the electronic device 100 to display the purchased electronic tickets after sorting based on any one or more of the validity date of the ticket, the purchase order, and the verification status. Further optionally, the electronic device 100 can further include any one or more of the following: a continue to purchase control 464, a close ticket folder control 465, etc. The continue to purchase control 464 can be used to trigger the electronic device 100 to return to the ticketing application interface 410 shown in FIG. 4B, and the close ticket folder control 465 can be used to trigger the electronic device 100 to close the electronic ticket folder.

[0195] It can be understood that the above-mentioned embodiments shown in FIGS. 4A-4G are only examples, and in the embodiments of the present application, the electronic device 100 can also purchase electronic tickets through other applications or applets, and the purchased electronic tickets can also be electronic tickets of different items, different types or different quantities from the above-mentioned embodiments, which are not limited herein.

[0196] In this way, ticket purchase can be completed through the application or applet installed on the electronic device 100, which is convenient to operate.

[0197] The interface schematic diagram of a set of ticket checking methods provided by the embodiments of the present application is introduced below.

[0198] For example, as shown in FIG. 5A, the electronic device 100 is in a screen-off state. When the user needs to check the ticket, the electronic device 100 can touch the card swiping area 203 of the gate machine 200. The gate machine 200 can be used to verify the electronic ticket of the zoo.

[0199] If the electronic device 100 has already purchased the electronic ticket of the zoo, after the electronic device 100 touches the gate machine 200, the electronic device 100 can display the ticket checking success interface 500 as shown in FIG. 5B.

[0200] As shown in FIG. 5B, the ticket checking success interface 500 can include a ticket checking success prompt 501, and can optionally include a close prompt control 502 and / or a view ticket folder control 503. The ticket checking success prompt 501 can be used to prompt the user that the ticket checking is successful. In some embodiments, the ticket checking success prompt 501 can include any one or more of the following contents: ticket item, ticket type, ticket number, ticket checking time, etc. The close prompt control 502 can be used to trigger the electronic device 100 to close the display of the ticket checking success interface 500. The view ticket folder control 503 can be used to trigger the electronic device 100 to display the purchased electronic ticket.

[0201] The electronic device 100 can receive and respond to the user's click operation on the view ticket folder control 503 to display the electronic ticket folder interface 510 as shown in FIG. 5C.

[0202] As shown in FIG. 5C, the electronic ticket folder interface 510 can include a zoo ticket 511, a flower art exhibition ticket 512, a sorting and filtering control 513, a continue to purchase ticket control 514, a close ticket folder control 515, etc. The verification state of the zoo ticket 511 is already verified, which is used to prompt the user that the zoo ticket 511 has been verified. In some embodiments, the zoo ticket 511 can also use a different display color from the unverified ticket such as the flower art exhibition ticket 512, which is used to prompt the user that the zoo ticket 511 has been verified. Other specific contents of the electronic ticket folder interface 510 can refer to the related description of the electronic ticket folder interface 460 shown in FIG. 4G, which will not be repeated here.

[0203] If the electronic device 100 has not purchased the electronic ticket of the zoo, the electronic device 100 can display a ticket check failure interface 520 as shown in FIG. 5D after touching the gate machine 200.

[0204] As shown in FIG. 5D, the ticket check failure interface 520 can include a ticket check failure prompt 521, and optionally, a close prompt control 522 and / or a view ticket folder control 523. The ticket check failure prompt 521 is used to prompt the user that the electronic device 100 has not purchased the electronic ticket corresponding to the gate machine 200. The ticket check failure prompt 521 can include text, for example, “No ticket information is found. Please purchase the ticket before entering the zoo!” The close prompt control 522 can be used to trigger the electronic device 100 to close the ticket check failure prompt 521. The view ticket folder control 523 can be used to trigger the electronic device 100 to display the purchased electronic ticket.

[0205] It can be understood that the embodiments shown in FIGS. 5A-5D are only examples. In the embodiments of the present application, the electronic device 100 can also communicate with the gate machine 200 based on the NFC technology in the bright screen state, and the interface displayed by the electronic device 100 in the bright screen state can be any interface, which is not limited in the present application. In addition, in the embodiments of the present application, the ticket check success prompt and the ticket check failure prompt output by the electronic device 100 can include more, less or different content than the above-mentioned embodiments, and the electronic device 100 can also output the ticket check success prompt or the ticket check failure prompt in different output modes than the above-mentioned embodiments, which is not limited in the present application.

[0206] In this way, the electronic device 100 can prompt the user with the ticket check result through the ticket check success prompt and the ticket check failure prompt.

[0207] The following describes a ticket purchase process provided by an embodiment of the present application.

[0208] FIG. 6A shows a ticket purchase process provided by an embodiment of the present application.

[0209] As shown in FIG. 6A, the electronic device 100 can include a ticket application 12, which can be used to purchase a ticket. In the process of purchasing a ticket by the user through the electronic device 100, the interaction process of the electronic device 100 with the ticket system 330, the account cloud 320, the electronic ticket business cloud 310 and other servers can include the following steps:

[0210] S601. The ticket application 12 receives a ticket purchase operation 1 of the user, which is used to trigger the electronic device 100 to purchase an electronic ticket 1.

[0211] The ticket application 12 can be used to purchase one or more electronic tickets of one or more items, which can include the electronic ticket 1. In some embodiments, the ticket application 12 in the embodiment shown in FIG. 6A can also be replaced by the wallet application in the embodiment shown in FIG. 3B or other HCE application with ticket purchasing function, etc.

[0212] The electronic ticket 1 can include one or more tickets. When the electronic ticket 1 includes multiple tickets, the multiple tickets can be tickets of the same item. In the embodiments of the present application, the item can include any one or more of the following: a scenic spot, a show, an exhibition, a meeting, a competition, etc.

[0213] The ticket application 12 can determine the item identifier 1 corresponding to the electronic ticket 1, the number of tickets, and optionally the type of ticket when receiving the ticket purchasing operation 1. The item identifier 1 can be used to identify the item (e.g., a zoo, a concert, a museum, etc.) corresponding to the electronic ticket 1; the number of tickets is used to indicate the number of tickets in the electronic ticket 1; and the type of ticket can include any one or more of the following: adult ticket, student ticket, child ticket, senior ticket, family ticket, etc.

[0214] It should be noted that when the electronic ticket 1 includes multiple tickets, the type of the electronic ticket 1 can include one or more types, and in this case, the number of tickets can also be used to indicate the number of each type of ticket, such as 2 adult tickets and 1 student ticket, etc.

[0215] For example, the ticket purchasing operation 1 can include the click operation on the submit order control 433 in the embodiment shown in FIG. 4D, etc.

[0216] S602. The ticket application 12 sends the account of the electronic device 100 and the item identifier 1 to the account cloud 320, and the item identifier 1 is the item identifier corresponding to the electronic ticket 1.

[0217] In some embodiments, the ticket application 12 can perform step S602 in response to the ticket purchasing operation 1.

[0218] The account of the electronic device 100 can be used to identify the identity of the user of the current electronic device 100. In the embodiments of the present application, the account of the electronic device 100 refers to the account currently logged in by the electronic device 100, and the user can also use the account to log in to other electronic devices and communicate with the account cloud 320.

[0219] The item identifier 1 can be used to indicate the item corresponding to the electronic ticket 1.

[0220] In a possible implementation, the electronic device 100 can send the account of the electronic device 100 and the project identifier 1 to the account cloud 320 through the electronic ticket service cloud 310. Specifically, the electronic device 100 can send the account of the electronic device 100 and the project identifier 1 to the electronic ticket service cloud 310. After verifying that the project identifier 1 is valid, the electronic ticket service cloud 310 can send the account of the electronic device 100 and the project identifier 1 to the account cloud 320.

[0221] S603. The account cloud 320 generates an open identification 1 (OpenID_1) based on the account of the electronic device 100 and the project identifier 1.

[0222] In some embodiments, after receiving the account and the project identifier 1 sent by the electronic device 100, the account cloud 320 can generate the OpenID_1 based on the project identifier 1 and the account of the electronic device 100. The OpenID_1 can have a corresponding relationship with the account of the electronic device 100 and the project identifier 1.

[0223] For example, the account cloud 320 can store an OpenID generation algorithm, such as a hash algorithm. The input of the OpenID generation algorithm can include a project identifier and an account of an electronic device (such as the electronic device 100), and the output can include an OpenID. When the input of the OpenID generation algorithm is the account of the electronic device 100 and the project identifier 1, the output can be the OpenID_1.

[0224] S604. The account cloud 320 sends the OpenID_1 to the ticket application 12.

[0225] S605. The ticket application 12 sends a ticket purchase request to the ticket system 330, the ticket purchase request including the number of the ticket 1 and the OpenID_1, and optionally including the project identifier 1.

[0226] In some embodiments, the ticket system 330 can be a ticket system that provides services for only one project (such as the scenic area A), in which case the ticket purchase request can or can not carry the project identifier 1.

[0227] In other embodiments, the ticket system 330 can also provide services for multiple projects (such as the scenic area A, the scenic area B, the show C, etc.), in which case the ticket purchase request can carry the project identifier 1, which indicates the project to which the electronic ticket 1 purchased by the user corresponds.

[0228] Further optionally, the ticket purchase request can further include any one or more of the following: a ticket type, a validity period.

[0229] The ticket type can include any one or more of the following: adult ticket, student ticket, senior citizen ticket, child ticket, family ticket, other preferential ticket, and the like. The ticket type is used to indicate the type of ticket purchased by the user.

[0230] The validity period can be used to indicate the validity period of the electronic ticket 1. For example, if the validity period includes July 10, 2024, the electronic ticket 1 can be used on July 10, 2024.

[0231] S606. The ticketing system 330 generates ticket information 1 based on the ticket purchase request, the ticket information 1 is bound to OpenID_1, and the ticket information 1 includes the identification of the electronic ticket 1, the number of tickets, the validity period, and optionally, the verification status and the ticket purchase time.

[0232] The ticketing system 330 can generate the ticket information 1 corresponding to the electronic ticket 1 based on the ticket purchase request, and bind the ticket information 1 to OpenID_1.

[0233] The ticket information 1 includes the identification of the electronic ticket 1, the number of tickets, the validity period, and optionally, the verification status and the ticket purchase time.

[0234] The identification of the electronic ticket 1 can be used to identify the electronic ticket 1 purchased by the user. For example, the identification of the electronic ticket 1 can be the ticket number of the electronic ticket 1.

[0235] The verification status can be used to indicate whether the electronic ticket 1 has been verified. The verification status can include verified and unverified.

[0236] The ticket purchase time can be used to indicate the time at which the electronic device 100 purchases the electronic ticket 1. In some embodiments, the ticket purchase time can be the time at which the ticketing system 330 generates the ticket information 1 based on the ticket purchase request. In other embodiments, the ticket purchase time can also be the time at which the ticketing system 330 receives the ticket purchase request, which is not limited in the present application.

[0237] S607. The ticketing system 330 sends the ticket information 1 to the ticketing application 12.

[0238] S608. The ticketing application 12 stores and displays the ticket information 1.

[0239] It should be noted that steps S608 and S609 can be executed in parallel, or in a certain order, for example, step S608 is executed first, then step S609 is executed, or step S609 is executed first, then step S608 is executed, and the specific execution order of steps S608 and S609 is not limited in the present application.

[0240] In a possible implementation, the ticket application 12 can only store the ticket information 1 when storing the ticket information 1.

[0241] In another possible implementation, the ticket application 12 can store the correspondence among the ticket information 1, the OpenID_1, and the project identifier 1.

[0242] S609. The ticket application 12 sends the ticket information 1 and the account of the electronic device 100 to the electronic ticket business cloud 310.

[0243] Optionally, the ticket application 12 can also send the OpenID_1 to the electronic ticket business cloud 310.

[0244] S610. The electronic ticket business cloud 310 stores the correspondence between the ticket information 1 and the account of the electronic device 100.

[0245] In some embodiments, if the ticket application 12 sends the OpenID_1 to the electronic ticket business cloud 310, the electronic ticket business cloud 310 can also store the correspondence among the ticket information 1, the OpenID_1, and the account of the electronic device 100.

[0246] It can be understood that the embodiment shown in FIG. 6A only exemplarily illustrates a ticket purchasing process, and in the embodiments of the present application, the process in which the electronic device 100 interacts with the ticket system 330, the account cloud 320, and other servers in the ticket purchasing process can further include more, less, or different steps from the above-described embodiments, which are not limited herein.

[0247] By using the ticket purchasing method provided in the embodiments of the present application, the electronic device 100 can complete ticket purchasing by interacting with the ticket system 330, the account cloud 320, and other servers.

[0248] In some application scenarios, after the user purchases the electronic ticket 1 through the electronic device 100, the user can log in to the same account on another electronic device (for example, the electronic device 400) to obtain the ticket information 1 corresponding to the electronic ticket 1 from the electronic ticket business cloud 310. In this way, after the user changes the electronic device used, the user can still view or use the electronic ticket purchased through the old electronic device.

[0249] For example, FIG. 6B shows a flowchart of a process in which the electronic device 400 obtains the ticket information 1 of the electronic ticket 1 purchased by the electronic device 100 from the electronic ticket business cloud 310.

[0250] As shown in FIG. 6B, the electronic device 400 can include the ticket application 41, and after the electronic device 100 purchases the electronic ticket 1 based on the embodiment shown in FIG. 6A, the specific process in which the electronic device 400 obtains the ticket information 1 of the electronic ticket 1 purchased by the electronic device 100 from the electronic ticket business cloud 310 can include the following steps:

[0251] S611. The ticket application 41 logs in the account of the electronic device 100.

[0252] It should be noted that in some embodiments, the electronic device 400 can also include the wallet application, and in the embodiment shown in FIG. 6B, the execution subject of each step can be the ticket application 41 or the wallet application, and the embodiment of the present application does not limit the execution subject of each step in the embodiment shown in FIG. 6B. The ticket application 41 / wallet application can view the electronic ticket purchased by the user. In some embodiments, the ticket application 41 / wallet application can also purchase the electronic ticket 1.

[0253] After the user purchases the electronic ticket 1 through the electronic device 100, the user can log in the account of the electronic device 100 in the ticket application 41 of the electronic device 400.

[0254] S612. The ticket application 41 sends an information synchronization request to the electronic ticket business cloud 310, and the information synchronization request includes the account of the electronic device 100.

[0255] After logging in the account of the electronic device 100, the ticket application 41 can send an information synchronization request to the electronic ticket business cloud 310, and the information synchronization request includes the account of the electronic device 100. The information synchronization request can be used to request to obtain the ticket information corresponding to the account of the electronic device 100.

[0256] S613. The electronic ticket business cloud 310 sends an information synchronization response to the ticket application 41, and the information synchronization response includes the ticket information 1 and optionally includes the OpenID_1.

[0257] After receiving the information synchronization request, the electronic ticket business cloud 310 can determine the ticket information 1 corresponding to the account of the electronic device 100 based on the correspondence between the account and the ticket information, and send an information synchronization response to the ticket application 41, and the information synchronization response can include the ticket information 1.

[0258] In some embodiments, the electronic ticket business cloud 310 can also determine the ticket information 1 and the OpenID_1 corresponding to the ticket information 1 based on the account of the electronic device 100, and send an information synchronization response carrying the ticket information 1 and the OpenID_1 to the ticket application 41.

[0259] S614. The ticket application 41 stores and displays the ticket information 1.

[0260] The specific content of step S614 can refer to the description of step S608 shown in FIG. 6A, which will not be repeated here.

[0261] It can be understood that the embodiment shown in FIG. 6B only exemplarily introduces a non-ticket purchasing device to obtain the information of the electronic tickets purchased by the same account from the electronic ticket service cloud 310 in the past. In the embodiment of the present application, the electronic device 400 can also obtain the ticket information from the electronic ticket service cloud 310 in a different manner from the above-mentioned embodiment, which is not limited in the present application.

[0262] By using the ticket information obtaining manner provided in the embodiment of the present application, the ticket information synchronization between different electronic devices based on the same account can be realized.

[0263] The flow of a ticket checking method provided in an embodiment of the present application will be introduced below.

[0264] Exemplarily, FIG. 7 shows a flow diagram of a ticket checking method provided in an embodiment of the present application.

[0265] As shown in FIG. 7, the electronic device 100 can include an electronic ticket 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 can be in the PICC mode, and the gate 200 can be in the PCD mode. The specific flow of the ticket checking method provided in the embodiment of the present application performed by the electronic device 100, the gate 200 and the ticket service system 330 can include the following steps:

[0266] S701. The electronic device 100 enters the radio frequency field of the gate 200.

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

[0268] S702. The gate 200 sends a probe (Probe) frame.

[0269] The Probe frame can be used to indicate that the gate 200 supports a specified NFC protocol, for example, a first protocol. The gate 200 can periodically send the Probe frame.

[0270] S703. After receiving the probe (Probe) frame, the NFC protocol stack 14 sends a probe acknowledgement (Probe ACK) frame.

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

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

[0273] The NFC protocol stack 14 can refer to the NFC protocol stack 14 in the embodiments shown in FIG. 3B and FIG. 3C. It should be noted that in some embodiments, the step S703, and the following steps S705 and S706 can be performed by the access layer in the NFC protocol stack 14, i.e., the received data is processed by the access layer, and the data to be sent is controlled by the access layer.

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

[0275] The device characteristic information can include a device service identifier (SID) and a device organization identifier (also referred to as a NFC device organization unique identifier (ND_OUI)).

[0276] Optionally, the device characteristic information can include a device service identifier (SID), a device organization identifier (ND_OUI), and a device group identifier (also referred to as a NFC device group identifier (ND_GID)).

[0277] 1. The device service identifier (SID) can be used to indicate the type of NFC service supported by the gate machine 200 on the basis of NFC function.

[0278] In a possible implementation, the type of NFC service can include a main service type and a sub-service type. Therefore, the device service identifier can include a main service identifier and a sub-service identifier. The main service identifier can be used to indicate the main service type supported by the gate machine 200, and the sub-service identifier can be used to indicate the sub-service type supported by the gate machine 200 under a certain main service type. The main service type can include electronic ticket, and optionally, the main service type can also include one or more of the following: access control, key, transportation, bank, digital currency, digital certificate, no-code payment, wireless charging, tap-to-tap, multi-functional card, etc. The sub-service type corresponding to the electronic ticket can include electronic ticket purchase and park access service.

[0279] The main service identifier can occupy 1 byte (Byte), and the sub-service identifier can occupy 1 byte (Byte). For example, Table 1 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 the present application.

[0280] Table 1

[0281] As shown in Table 1, when the main service type is electronic ticket, the device main service identifier can be 0x08; if the sub-service type is electronic ticket purchase and park access service, the device sub-identifier can be 0x01; if a new sub-service type needs to be added, an unused identifier in the reserved multiple identifiers, i.e., 0x00, 0x02-0xFF, can be selected as the device sub-service identifier corresponding to the new sub-service type.

[0282] It can be understood that the embodiment shown in Table 1 is only an example. In the embodiments of the present application, the device service identifier can also use different identifiers from the above-mentioned embodiments. In addition, the electronic ticket can include more, fewer, or different sub-service types and device sub-service identifiers than the above-mentioned embodiments, which are not limited in the present application.

[0283] 2. The device organization identifier (ND_OUI) can be used to indicate the manufacturer that uses the gate 200 to provide NFC services, such as scenic spot A, theater B, or museum C, etc. The device organization identifier can be managed by a unified standard organization, and different manufacturers and commercial organizations can apply for use according to their own needs.

[0284] 3. The device group identifier (ND_GID) can be used to indicate the group to which the NFC service provided by the gate 200 belongs. The device group identifier can be allocated according to the purpose and location of the gate 200. Different NFC services can have different group divisions.

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

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

[0287] S706. The NFC protocol stack 14 sends a notification confirmation (Notify ACK) frame.

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

[0289] It should be noted that the NFC protocol stack 14 can perform the step S705 and the step S706 synchronously, or can perform the step S705 first and then perform the step S706, or can perform the step S706 first and then perform the step S705. The application does not limit the execution order of the step S705 and the step S706.

[0290] S707. The gate 200 and the electronic device 100 perform security verification.

[0291] The step S707 is an optional step.

[0292] In some embodiments, after receiving the Notify ACK frame, the gate 200 can perform security verification with the electronic device 100.

[0293] The security verification can be used to verify whether the gate 200 and the electronic device 100 are both trusted devices, so as to improve the security of the communication between the gate 200 and the electronic device 100.

[0294] The following exemplary introduces a security verification method provided by the embodiments of the application.

[0295] When the ticket system 330 registers the project identifier and the device identifier of the gate 200 to the electronic ticket business cloud 310, the ticket system 330 can provide an initial random number r1 to the electronic ticket business cloud 310, and negotiate with the electronic ticket business cloud 310 to determine a hash algorithm sha256. Then, the gate 200 and / or the ticket system 330 can obtain the initial random number r1 and the hash algorithm sha256 through the ticket system 330; the electronic device 100 can obtain the initial random number r1 and the hash algorithm sha256 through the electronic ticket business cloud 310.

[0296] When the gate 200 starts to perform the step S709, the gate 200 can generate a digest d1 through the hash algorithm sha256 based on the initial random number r1, and generate a random number r2; then, the gate 200 can send the digest d1 and the random number r2 to the electronic device 100. The gate 200 can also generate a digest d2 through the hash algorithm sha256 based on the initial random number r1 and the random number r2.

[0297] The electronic device 100 can generate the digest D1 based on the random number r1 by using the hash algorithm sha256 when starting to perform step S709. The electronic device 100 can receive the digest d1 and the random number r2 sent by the gate machine 200. The electronic device 100 can compare the digest d1 and the digest D1, and if the digest d1 and the digest D1 are the same, the electronic device 100 can determine that the gate machine 200 is a trusted device; if the digest d1 and the digest D1 are different, the electronic device 100 can determine that the gate machine 200 is not a trusted device.

[0298] After the electronic device 100 determines that the gate machine 200 is a trusted device, the electronic device 100 can generate the digest D2 based on the initial random number r1 and the received random number r2 by using the hash algorithm sha256. Then, the electronic device 100 can send the digest D2 to the gate machine 200.

[0299] After receiving the digest D2 sent by the electronic device 100, the gate machine 200 can compare the digest D2 and the digest d2, and if the digest d2 and the digest D2 are the same, the gate machine 200 can determine that the electronic device 100 is a trusted device; if the digest d2 and the digest D2 are different, the gate machine 200 can determine that the electronic device 100 is not a trusted device.

[0300] If the electronic device 100 and the gate machine 200 determine each other to be trusted devices, the security verification is passed.

[0301] If the electronic device 100 determines that the gate machine 200 is not a trusted device, and / or the gate machine 200 determines that the electronic device 100 is not a trusted device, the security verification is not passed, and the ticket checking fails.

[0302] In this way, whether the electronic device 100 and the gate machine 200 are trusted devices can be verified, and the security of the communication between the gate machine 200 and the electronic device 100 is improved.

[0303] It can be understood that the above embodiment is only an example, and in the embodiments of the present application, the gate machine 200 and the electronic device 100 can also use different ways from the above embodiment for security verification, which is not limited herein.

[0304] S708. The gate machine 200 sends an electronic ticket service route, and the electronic ticket service route includes a project identifier 1.

[0305] The electronic ticket service route can be used to instruct the electronic device 100 to pull up the electronic ticket service 11. The project identifier 1 is a project identifier corresponding to the gate machine 200.

[0306] In some embodiments, after receiving the Notify ACK frame, the gate 200 can negotiate transmission parameters of the application protocol layer with the electronic device 100. For example, after receiving the 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. In this embodiment, the frame type of the parameter negotiation command can be a command (Command) frame, and the frame type of the parameter negotiation response can be a response (Response) frame. The parameter negotiation command and the parameter negotiation response can be used to negotiate the transmission parameters of the application protocol layer between the gate 200 and the electronic device 100. The transmission parameters can include any one or more of the maximum transmission rate and the maximum data transmission length when transmitting data at the application layer. In this way, the gate 200 and the electronic device 100 can negotiate the transmission parameters of the application layer, and the gate 200 can interact with the electronic ticket service 11 through the NFC protocol stack 14 based on the negotiated transmission parameters.

[0307] It should be noted that in some embodiments, the gate 200 can negotiate the transmission parameters of the application protocol layer with the electronic device 100 after step S706; in other embodiments, the gate 200 can also negotiate the transmission parameters of the application layer with the electronic device 100 after completing the security verification (i.e., performing step S707).

[0308] In other embodiments, the gate 200 and the electronic device 100 can also be preconfigured with transmission parameters of the application protocol layer, in which case the gate 200 and the electronic device 100 can not negotiate the transmission parameters of the application protocol layer.

[0309] S709. The NFC protocol stack 14 sends a route acknowledgment (ACK) to the gate 200, and the route acknowledgment is used to indicate that the electronic device 100 successfully processes the electronic ticket service route.

[0310] In other embodiments, if the NFC protocol stack 14 does not successfully process the electronic ticket service route, the NFC protocol stack 14 can also send a failure acknowledgment to the gate 200, and the failure acknowledgment is used to indicate that the electronic device 100 does not successfully process the electronic ticket service route.

[0311] It should be noted that the NFC protocol stack 14 can execute step S709 and step S710 in parallel after receiving the electronic ticket service route, or can execute step S709 first and then execute step S710, or can execute step S710 first and then execute step S709. The specific execution order of step S709 and step S710 is not limited in the present application.

[0312] S710. The NFC protocol stack 14 routes the electronic ticket service 11 based on the electronic ticket service.

[0313] S711. The gate machine 200 sends a service request to the electronic ticket service 11 through the NFC protocol stack 14, and the service request includes the device identifier of the gate machine 200.

[0314] The service request can be used to request to obtain an OpenID (for example, OpenID_1) corresponding to the electronic ticket that can be verified by the gate machine 200.

[0315] S712. The electronic ticket service 11 determines whether the device identifier of the gate machine 200 is valid based on the interaction with the electronic ticket service cloud 310.

[0316] For example, FIG. 8 shows a flowchart of the electronic ticket service 11 determining whether the device identifier of the gate machine 200 is valid based on the interaction with the electronic ticket service cloud 310 according to an embodiment of the present application.

[0317] As shown in FIG. 8, the specific process of the electronic ticket service 11 determining whether the device identifier of the gate machine 200 is valid based on the interaction with the electronic ticket service cloud 310 can include the following steps:

[0318] S801. The electronic ticket service 11 sends a validity verification request to the electronic ticket service cloud 310, and the validity verification request includes the device identifier of the gate machine 200.

[0319] S802. The electronic ticket service cloud 310 determines whether the device identifier of the gate machine 200 is registered.

[0320] One or more device identifiers of gate machines can be registered on the electronic ticket service cloud 310. The specific process of registering the device identifier of the gate machine on the electronic ticket service cloud 310 can refer to the related description in the embodiment shown in FIG. 10 below.

[0321] The electronic ticket service cloud 310 can determine whether the device identifier of the gate machine 200 is valid based on whether the device identifier of the gate machine 200 is registered.

[0322] If the electronic ticket service cloud 310 detects that the device identifier of the gate machine 200 is registered, it can be determined that the device identifier of the gate machine 200 is valid, and at this time, the following step S803 can be performed.

[0323] If the electronic ticket service cloud 310 detects that the device identifier of the gate machine 200 is not registered, it can be determined that the device identifier of the gate machine 200 is invalid, and at this time, the following step S806 can be performed.

[0324] S803. The electronic ticket business cloud 310 determines the project identifier 1 corresponding to the device identifier of the gate 200 based on the correspondence between the device identifier and the project identifier.

[0325] One or more project identifiers can be registered in the electronic ticket business cloud 310, and each project identifier can correspond to one or more device identifiers of the gate. The electronic ticket business cloud 310 can store the correspondence between the project identifier and the device identifier of the gate.

[0326] For example, Table 2 shows the correspondence between the project identifier and the device identifier stored by the electronic ticket business cloud 310 according to an embodiment of the present application.

[0327] Table 2

[0328] As shown in Table 2, the electronic ticket business cloud 310 can store the correspondence between one or more project identifiers and the device identifier of the gate, for example, the project identifier PID1 can correspond to the device identifier of the gate including ID1 and ID2; the project identifier PID2 can correspond to the device identifier of the gate including ID3, and so on.

[0329] It can be understood that the embodiment shown in Table 2 is only an example, and in the embodiments of the present application, the electronic ticket business cloud 310 can also store more, less or different project identifiers and device identifiers of the gate than the above-mentioned embodiments, or store different correspondence than the above-mentioned embodiments, which are not limited herein.

[0330] In some embodiments, after the electronic ticket business cloud 310 determines that the device identifier of the gate 200 has been registered, the electronic ticket business cloud 310 can determine the project identifier 1 corresponding to the device identifier of the gate 200 based on the correspondence between the project identifier and the device identifier of the gate.

[0331] In other embodiments, after the electronic ticket business cloud 310 receives the validity verification request carrying the device identifier of the gate 200, the electronic ticket business cloud 310 can also determine the project identifier 1 corresponding to the device identifier of the gate 200 based on the correspondence between the project identifier and the device identifier of the gate. That is, in this case, step S802 and step S803 can be executed in parallel.

[0332] S804. The electronic ticket business cloud 310 sends a validity verification response 1 to the electronic ticket service 11, which is used to indicate that the device identifier of the gate 200 is valid.

[0333] The validity verification response 1 can be used to indicate that the device identifier of the gate 200 is valid. Optionally, the validity verification response 1 can also carry the project identifier 1.

[0334] S805. The electronic ticket service 11 receives and responds to the validity verification response 1, and determines that the device identifier of the gate 200 is valid.

[0335] In some embodiments, the validity verification response 1 can also carry the item identifier 1. In this case, the electronic ticket service 11 can determine whether the item identifier carried in the validity verification response 1 is consistent with the item identifier sent by the gate 200. If the two item identifiers are consistent, the electronic ticket service 11 can perform the following step S806; if the two item identifiers are inconsistent, the electronic ticket service 11 can output an error prompt to prompt the user that the item identifier sent by the gate 200 is incorrect.

[0336] S806. The electronic ticket service 11 sends a validity verification response 2 to the electronic ticket service 11 to indicate that the device identifier of the gate 200 is invalid.

[0337] S807. The electronic ticket service 11 receives and responds to the validity verification response 2, and determines that the device identifier of the gate 200 is invalid.

[0338] In this way, the electronic ticket service 11 can determine whether the device identifier of the gate 200 is valid through the electronic ticket service cloud 310, and determine whether to continue performing the ticket checking process based on the validity verification result.

[0339] It can be understood that the above-mentioned embodiment shown in FIG. 8 is only an example, and in the embodiments of the present application, the electronic ticket service 11 can also verify whether the device identifier of the gate 200 is valid in a manner different from the above-mentioned embodiment, which is not limited herein.

[0340] If the electronic ticket service 11 determines that the device identifier of the gate 200 is valid, the electronic ticket service 11 can perform the following step S714.

[0341] If the electronic ticket service 11 determines that the device identifier of the gate 200 is invalid, the electronic ticket service 11 can perform the following step S713 and stop the ticket checking process.

[0342] S713. The electronic ticket service 11 outputs an invalid prompt, and the invalid prompt is used to prompt the user that the device identifier of the gate 200 is invalid.

[0343] After determining that the device identifier of the gate 200 is invalid, the electronic device 100 can stop performing the subsequent ticket checking process.

[0344] S714. The electronic ticket service 11 acquires OpenID_1 based on the item identifier 1.

[0345] In a possible implementation, after the electronic device 100 purchases the electronic ticket 1, the electronic ticket 1 corresponding ticket information 1 and the corresponding OpenID_1 can be stored in the application (for example, the ticket application 12, the wallet application 13, etc.) for purchasing tickets. In this case, the electronic ticket service 11 can determine whether the OpenID_1 corresponding to the item identifier 1 exists in the locally stored one or more open gate identifiers based on the interaction between the electronic device 100 and one or more applications (for example, the ticket application 12, etc.) installed on the electronic device 100 and having the function of purchasing tickets. In this case, the electronic device 100 can also complete the ticket checking in the offline state.

[0346] In another possible implementation, the electronic ticket service 11 can also obtain the OpenID_1 based on the item identifier 1 and the account of the electronic device 100 based on the interaction between the account cloud 320.

[0347] For example, the specific process in which the electronic ticket service 11 obtains the OpenID_1 based on the item identifier 1 can refer to the related content in the embodiment shown in FIG. 9, which will not be described here in detail.

[0348] S715. The electronic ticket service 11 sends a service response to the gate 200 through the NFC protocol stack 14, and the service response includes the OpenID_1.

[0349] In some embodiments, the electronic ticket service 11 can send the OpenID_1 to the gate 200 through the NFC protocol stack 14.

[0350] S716. The gate 200 sends a verification request to the ticket system 330, and the verification request includes the OpenID_1.

[0351] After receiving the OpenID_1 sent by the electronic device 100, the gate 200 can request the ticket system 330 to verify whether the OpenID_1 is valid.

[0352] S717. The ticket system 330 determines whether the OpenID_1 is valid.

[0353] In some embodiments, only the unverified open gate identifiers can be stored in the ticket system 330. In this case, the ticket system 330 can determine whether the OpenID_1 is valid based on whether the OpenID_1 is included in the plurality of open gate identifiers. If the OpenID_1 is stored in the ticket system 330, it is determined that the OpenID_1 is valid. If the OpenID_1 is not stored in the ticket system 330, it is determined that the OpenID_1 is invalid.

[0354] In some embodiments, the ticket system 330 can store a plurality of gate opening identifications, and a verification status of each gate opening identification. In this case, the ticket system 330 can first determine whether the OpenID_1 is stored, and then determine whether the verification status of the OpenID_1 is verified, in the case that the OpenID_1 is stored. If the ticket system 330 stores the OpenID_1 and the verification status of the OpenID_1 is not verified, it is determined that the OpenID_1 is valid. If the ticket system 330 stores the OpenID_1 and the verification status of the OpenID_1 is verified, it is determined that the OpenID_1 is invalid. If the ticket system 330 does not store the OpenID_1, it is determined that the OpenID_1 is invalid.

[0355] If the ticket system 330 determines that the OpenID_1 is valid, the ticket system 330 can perform the following steps S718 and S719.

[0356] If the ticket system 330 determines that the OpenID_1 is invalid, the ticket system 330 can perform the following step S724.

[0357] S718. The ticket system 330 sets the verification status of the OpenID_1 as verified.

[0358] The steps S718 and S719 can be performed synchronously or in a sequence, for example, the step S718 is performed first and then the step S719 is performed, or the step S719 is performed first and then the step S718 is performed, etc. The execution sequence of the steps S718 and S719 is not limited in the present application.

[0359] In some embodiments, when it is determined that the OpenID_1 is valid, the ticket system 330 can set the verification status of the OpenID_1 stored in the ticket system 330 as verified.

[0360] In some embodiments, when it is determined that the OpenID_1 is valid, the ticket system 330 can delete the OpenID_1 stored in the ticket system 330.

[0361] S719. The ticket system 330 sends a verification result 1 to the gate 200, and the verification result 1 is used to indicate that the OpenID_1 is valid.

[0362] The verification result 1 is used to inform the gate 200 that the OpenID_1 is valid, and the verification result 1 can also be used to instruct the gate 200 to open the gate.

[0363] In some embodiments, the verification result 1 can also include the number of tickets indicated by the OpenID_1.

[0364] S720. The gate machine 200 opens the gate.

[0365] After receiving the verification result 1, the gate machine 200 can perform step S720 and step S721. It should be noted that step S720 and step S721 can be steps performed synchronously, or steps performed in a sequence, for example, step S720 is performed first and then step S721 is performed, or step S720 is performed first and then step S721 is performed, etc. The application does not limit the execution order of step S720 and step S721.

[0366] For example, taking the gate machine 200 in the embodiment shown in FIG. 3B as an example, after receiving the verification result 1, the gate machine 200 can rotate the baffle 202 so that the user can pass between the upright posts 201. After detecting that the user passes, the gate machine 200 can close the gate.

[0367] It should be noted that in some embodiments, if the verification result 1 includes the number of tickets indicated by OpenID_1, and the number of tickets is greater than 1, the gate machine 200 can also determine that the number of people passing is consistent with the number of tickets in the verification result 1 after receiving the verification result 1. Then close the gate.

[0368] S721. The gate machine 200 sends a ticket checking success notification to the electronic ticket service 11.

[0369] In some embodiments, the gate machine 200 can send the ticket checking success notification to the electronic ticket service 11 through the NFC protocol stack 14.

[0370] The ticket checking success notification can be used to notify the electronic ticket service 11 of the ticket checking success.

[0371] S722. The electronic ticket service 11 outputs a ticket checking success prompt.

[0372] The electronic ticket service 11 can output the ticket checking success prompt in any one or more of the following ways: display, voice, vibration, and indicator light flashing.

[0373] The ticket checking success prompt can be used to prompt the user of the ticket checking success.

[0374] For example, the ticket checking success prompt can be the ticket checking success prompt 501 in the embodiment shown in FIG. 5B.

[0375] S723. The electronic ticket service 11 sets the verification state of OpenID_1 to verified.

[0376] In some embodiments, the electronic ticket service 11 can set the verification state of OpenID_1 stored locally to verified.

[0377] In some embodiments, the electronic ticket service 11 can further send a verification result 2 to the gate 200, the verification result 2 being used to indicate that the OpenID_1 is invalid.

[0378] S724. The ticket system 330 sends the verification result 2 to the gate 200, the verification result 2 being used to indicate that the OpenID_1 is invalid.

[0379] S725. The gate 200 sends a ticket check failure notification to the electronic ticket service 11 through the NFC protocol stack 14.

[0380] After receiving the verification result 2, the gate 200 can perform step S725.

[0381] The ticket check failure notification can be used to notify the electronic ticket service 11 that the OpenID_1 provided by the electronic ticket service 11 is invalid.

[0382] In some embodiments, the ticket check failure notification can also be used to trigger the electronic device 100 to purchase the electronic ticket corresponding to the item identifier 1, or be used to trigger the electronic device 100 to display a ticket purchase interface, the ticket purchase interface being used to purchase the electronic ticket corresponding to the item identifier 1.

[0383] S726. The electronic ticket service 11 outputs a ticket check failure prompt.

[0384] The electronic ticket service 11 can output the ticket check failure prompt in any one or more of the following manners: display on a display screen, voice, vibration, and flashing of an indicator light.

[0385] The ticket check failure prompt is used to prompt the user that the current ticket check fails.

[0386] For example, the ticket check failure prompt can be the ticket check failure prompt 521 in the embodiment shown in FIG. 5D.

[0387] In some embodiments, after receiving the ticket check failure notification, the electronic device 100 can start a ticket purchase process, and the specific steps of the ticket purchase process can refer to the related description in the embodiment shown in FIG. 6A, which will not be repeated here.

[0388] In some embodiments, after receiving the ticket check failure notification, the electronic device 100 can also display a ticket purchase interface, and the electronic device 100 can receive and respond to a ticket purchase operation of the user on the ticket purchase interface to purchase the electronic ticket corresponding to the item identifier 1.

[0389] It can be understood that the embodiment shown in FIG. 7 is only an example, and in the embodiments of the present application, the ticket checking method can further include more, fewer or different steps than the above-described embodiments, which are not limited in the present application.

[0390] By using the ticket checking method provided in the application, the ticket checking can be realized by touching the gate 200 by the electronic device 100, the ticket checking steps are simplified, and the ticket checking efficiency is improved.

[0391] It should be noted that in some embodiments, part or all of the steps of the electronic ticket service 11 in the embodiments described in FIGS. 6A-7 can also be performed by the wallet application 13 (or the ticketing application 12), for example, the wallet application 13 (or the ticketing application 12) can output a ticket checking success prompt, a ticket checking failure prompt, etc. In some other embodiments, after the ticketing application 12 (or the wallet application 13) purchases the electronic ticket, the ticket information of the purchased electronic ticket can also be stored in the electronic ticket service 11, that is, the electronic ticket service 11 can also store the correspondence between the purchased electronic ticket opening gate identifier, the project identifier, and the ticket information, and the like, which is not limited in the application.

[0392] FIG. 9 shows a flowchart of an electronic ticket service 11 judging whether the opening gate identifier 1 can be obtained based on the project identifier 1 according to an embodiment of the application.

[0393] For example, as shown in FIG. 9, the specific process of the electronic ticket service 11 judging whether the opening gate identifier 1 can be obtained based on the project identifier 1 can include the following steps:

[0394] S901. The electronic ticket service 11 sends a query request 1 to the ticketing application 12, and the query request 1 includes the project identifier 1.

[0395] The electronic ticket service 11 can send the query request 1 to one or more applications (or mini-programs) with ticket purchasing function installed in the electronic device 100, and the query request 1 is used to query whether the application or the mini-program stores the OpenID_1 corresponding to the project identifier 1. The one or more applications (or mini-programs) with ticket purchasing function installed in the electronic device 100 can include the ticketing application 12 and / or the wallet application 13, etc. The embodiment shown in FIG. 9 is only described by taking the ticketing application 12 as an example, and in the embodiments of the application, the steps performed by the ticketing application 12 can also be performed by other applications or mini-programs with ticket purchasing function, for example, by the wallet application 13, which is not limited in the application.

[0396] S902. The ticketing application 12 judges whether the OpenID_1 corresponding to the project identifier 1 can be determined in one or more opening gate identifiers stored locally.

[0397] In some embodiments, the ticketing application 12 can store one or more opening gate identifiers with an unverified verification state. In this case, the electronic ticket service 11 can judge whether the OpenID_1 corresponding to the project identifier 1 exists in the one or more opening gate identifiers.

[0398] If the OpenID_1 corresponding to the project identification 1 is stored in the ticketing application 12, the ticketing application 12 can perform the following step S904.

[0399] If the OpenID_1 corresponding to the project identification 1 is not stored in the ticketing application 12, the ticketing application 12 can perform the following step S905.

[0400] In some other embodiments, the ticketing application 12 can store one or more gate opening identifications, and a verification status of each gate opening identification. In this case, the ticketing application 12 can determine whether the OpenID_1 corresponding to the project identification 1 exists in the one or more gate opening identifications.

[0401] If the OpenID_1 corresponding to the project identification 1 is stored in the ticketing application 12, the electronic ticket service 11 can perform the following step S903.

[0402] If the OpenID_1 corresponding to the project identification 1 is not stored in the ticketing application 12, the electronic ticket service 11 can perform the following step S905.

[0403] S903. The ticketing application 12 determines whether the verification status of the OpenID_1 is verified.

[0404] Step S903 is an optional step.

[0405] If the verification status of the OpenID_1 is verified, the ticketing application 12 can perform the following step S905.

[0406] If the verification status of the OpenID_1 is not verified, the ticketing application 12 can perform the following step S904.

[0407] S904. The ticketing application 12 sends a query response 1 to the electronic ticket service 11, carrying the OpenID_1.

[0408] The query response 1 can be used to indicate that the OpenID_1 corresponding to the project identification 1 exists in the ticketing application 12 (or other applications).

[0409] S905. The ticketing application 12 sends a query response 2 to the electronic ticket service 11, indicating that the OpenID_1 corresponding to the project identification 1 is not stored locally.

[0410] The query response 2 can be used to indicate that the ticketing application 12 of the electronic device 100 does not store the OpenID_1 corresponding to the project identification 1 locally in the electronic device 100.

[0411] S906. The electronic ticket service 11 determines whether the query response 1 is received.

[0412] The electronic coupon service 11 can determine whether the query response 1 carrying the OpenID_1 sent by any application is received.

[0413] If the electronic coupon service 11 receives the query response 1, the electronic coupon service 11 can perform the following step S909 to determine that the OpenID_1 corresponding to the item identifier 1 is obtained.

[0414] If the electronic coupon service 11 does not receive the query response 1, the electronic coupon service 11 can perform the following step S907 to determine whether the corresponding OpenID_1 is stored in the account cloud 320.

[0415] S907. The electronic coupon service 11 sends a query request 2 to the account cloud 320, and the query request 2 includes the item identifier 1 and the account of the electronic device 100.

[0416] In some embodiments, the query request 2 can be used to query whether the account of the electronic device 100, the OpenID_1 corresponding to the item identifier 1, and the verification status of the OpenID_1 are stored in the account cloud 320, and the verification status of the OpenID_1 should be unverified.

[0417] S908. The account cloud 320 sends a query response 3 carrying the OpenID_1 to the electronic coupon service 11.

[0418] In some embodiments, after receiving the query request 2, the account cloud 320 can query whether the account of the electronic device 100 and the OpenID_1 corresponding to the item identifier 1 are stored locally based on the account of the electronic device 100 and the item identifier 1. In other embodiments, after receiving the query request 2, the account cloud 320 can generate the corresponding OpenID_1 based on the account of the electronic device 100 and the item identifier 1.

[0419] In some embodiments, optionally, after receiving the query request 2 sent by the electronic coupon service 11, the account cloud 320 can verify whether the account of the electronic device 100 carried in the query request 2 is the same as the currently logged-in account of the electronic device 100. If the account of the electronic device 100 carried in the query request 2 is the same as the currently logged-in account of the electronic device 100, the account cloud 320 can determine the corresponding OpenID_1 based on the account of the electronic device 100 and the item identifier 1, and perform step S908 and subsequent steps; if the account of the electronic device 100 carried in the query request 2 is different from the currently logged-in account of the electronic device 100, the account cloud 320 can return an error notification, and the error notification can be used to notify the electronic device 100 that the account sent is incorrect.

[0420] For example, the account cloud 320 can verify whether the account of the electronic device 100 is the account currently logged in by the electronic device 100 based on the Session_id. It can be understood that the embodiment herein is only an example, and in the embodiments of the present application, the account cloud 320 can also verify whether the login account of the electronic device 100 is the same as the account carried in the query request 2 in a manner different from the above-described embodiment, which is not limited herein.

[0421] In this way, the security of the ticket checking process can be improved, and the account can be prevented from being stolen by other electronic devices.

[0422] S909. The electronic ticket service 11 determines that the OpenID_1 corresponding to the project identifier 1 is obtained.

[0423] If the OpenID_1 is stored in any application of the electronic device 100 having a ticket purchase function or the account cloud 320, the electronic ticket service 11 can determine that the OpenID_1 exists.

[0424] In this way, in the case that the opening gate identifier is not stored locally in the electronic device 100, the electronic device 100 can also obtain the corresponding opening gate identifier from the account cloud 320 and complete the ticket checking.

[0425] In another possible implementation, the opening gate identifier (for example, OpenID_1, etc.) in the above-described embodiment can also be replaced by the account currently logged in by the electronic device 100, or the mobile phone number of the electronic device 100, or other types of pre-agreed identifiers.

[0426] Exemplarily, taking the account currently logged in by the electronic device 100 (hereinafter referred to as the account of the electronic device 100) as an example, in this case, after receiving the pick confirmation (Pick ACK) frame sent by the electronic device 100 (i.e., step S706 or step S707 shown in FIG. 7), the gate machine 200 can send an account acquisition request to the electronic device 100, requesting to acquire the account of the electronic device 100. The electronic device 100 can receive and respond to the account acquisition request, and send the account of the electronic device 100 to the gate machine 200. After receiving the account of the electronic device 100 sent by the electronic device 100, the gate machine 200 can query, through the cloud server 300, whether the account of the electronic device 100 has purchased the electronic ticket corresponding to the gate machine 200 by using the account of the electronic device 100. If it is found that the account of the electronic device 100 has purchased the electronic ticket corresponding to the gate machine 200, and the electronic ticket is valid (for example, not verified, the validity period of the electronic ticket includes the ticket checking time, etc.), the gate machine 200 can open the gate to release the electronic device 100; if it is found that the account of the electronic device 100 has not purchased the electronic ticket corresponding to the gate machine 200, or the found electronic ticket is invalid, the gate machine 200 can send a ticket checking failure notification to the electronic device 100, notifying the electronic device 100 of the ticket checking failure.

[0427] It can be understood that the embodiment herein is only exemplary, and the gate machine 200 can also verify whether the user of the electronic device 100 has purchased a ticket by using the account of the electronic device 100, a mobile phone number or other types of identifiers, which are not limited herein.

[0428] The specific process of registering the project identifier and the device identifier of the gate machine on the electronic ticket business cloud 310 provided by the embodiment is introduced below.

[0429] FIG. 10 shows a flowchart of the process of registering the project identifier and the device identifier of the gate machine on the electronic ticket business cloud 310 provided by the embodiment.

[0430] Exemplarily, as shown in FIG. 10, the specific process of registering the project identifier and the device identifier of the gate machine on the electronic ticket business cloud 310 can include the following steps:

[0431] S1001. The ticketing system 330 acquires a project identifier and the identifier of one or more gate machines corresponding to the project identifier.

[0432] Exemplarily, taking the project identifier 1 in the above embodiment as an example, the ticketing system 330 can acquire the project identifier 1 and the device identifier of one or more gate machines corresponding to the project identifier 1, such as the device identifier of the gate machine 200, based on the input operation of the manager.

[0433] Further, the ticketing system 330 can also receive the registration information sent by the gate 200 before the gate 200 corresponding to the project identifier 1 is put into use, and the registration information carries the device identifier of the gate 200 and the corresponding project identifier. In this way, the ticketing system 330 can determine the device identifiers of the gates corresponding to the project identifier 1 based on the registration information sent by one or more gates corresponding to the project identifier 1, that is, obtain the correspondence between the project identifier and the device identifier of the gate.

[0434] It can be understood that the above embodiment is only an example, and in the embodiment of the present application, the ticketing system 330 can also obtain the project identifier and the device identifier of one or more gates corresponding to each project identifier in a manner different from the above embodiment, which is not limited herein.

[0435] S1002. The ticketing system 330 sends a registration request to the electronic ticket business cloud 310, and the registration request includes a project identifier and the identifier of one or more gates corresponding to the project identifier.

[0436] S1003. The electronic ticket business cloud 310 stores the correspondence between the project identifier and the device identifier of the gate based on the registration request, and completes the registration.

[0437] After receiving the registration request, the electronic ticket business cloud 310 can store the correspondence between the project identifier and the device identifier of the gate based on the registration request, and complete the registration. For example, the correspondence between the project identifier and the device identifier of the gate stored by the electronic ticket business cloud 310 can refer to the related description in the above embodiment shown in Table 2, which will not be described here.

[0438] S1004. The electronic ticket business cloud 310 sends a registration response to the ticketing system 330, and the registration response is used to notify the ticketing system that the registration is successful.

[0439] By using the above registration process shown in FIG. 10, the project identifier and the device identifier of the gate can be registered on the electronic ticket business cloud 310, which facilitates the management of each project and gate in the subsequent ticket purchase and ticket checking process.

[0440] In some application scenarios, the electronic device 100 can also share the electronic ticket purchased by the user with other users (such as friends and relatives).

[0441] For example, FIG. 11 shows a flowchart of a sharing process of an electronic ticket according to an embodiment of the present application.

[0442] As shown in FIG. 11, the electronic device 100 can include a ticketing application 12, and the electronic device 400 can include a ticketing application 41. The specific process in which the electronic device 100 shares the electronic ticket 1 with the electronic device 400 can include the following steps:

[0443] S1101. The ticket application 12 receives an operation of sharing the electronic ticket 1 by the user to the electronic device 400.

[0444] It should be noted that in some embodiments, the electronic device 100 can also include a wallet application 13, and the electronic device 400 can also include a wallet application, and in the embodiment shown in FIG. 11, the steps performed by the ticket application 12 can also be performed by the wallet application 13; similarly, the steps performed by the ticket application 41 can also be performed by the wallet application, which is not limited herein.

[0445] S1102. The ticket application 12 sends a ticket transfer request to the ticket system 330, carrying the account number of the electronic device 100 and the identifier of the electronic ticket 1.

[0446] The ticket transfer request can be used to request to transfer the electronic ticket 1 purchased by the electronic device 100.

[0447] S1103. The ticket system 330 determines the transfer identifier of OpenID_1 based on the ticket transfer request.

[0448] The transfer identifier of OpenID_1 can be used to identify the receiver of the electronic ticket 1 corresponding to OpenID_1. The transfer identifier of OpenID_1 can be a one-time temporary identifier, and optionally, the transfer identifier can also have a validity period (e.g., 5 minutes, 10 minutes, etc.).

[0449] S1104. The ticket system 330 sends a ticket transfer response to the ticket application 12, and the ticket transfer response includes the transfer identifier of OpenID_1.

[0450] S1105. The ticket application 12 sends a ticket sharing request to the ticket application 41, and the ticket sharing request includes the transfer identifier of OpenID_1 and the item identifier 1 of the electronic ticket 1.

[0451] The ticket sharing request is used to request to share the electronic ticket 1 to the receiver.

[0452] S1106. The ticket application 41 sends the account number of the electronic device 400 and the item identifier 1 to the account cloud 320.

[0453] After receiving the ticket sharing request, the ticket application 41 can optionally output a sharing prompt, which can be used to prompt the user to select whether to accept the sharing. If an operation of accepting the sharing by the user is received, the ticket application 41 can perform step S1106.

[0454] S1107. The account cloud 320 generates OpenID_2 based on the account number of the electronic device 400 and the item identifier 1.

[0455] The account cloud 320 can also store a correspondence between the account of the electronic device 400 and the OpenID_2 after generating the OpenID_2.

[0456] S1108. The account cloud 320 sends the OpenID_2 to the ticket application 41.

[0457] S1109. The ticket application 41 sends a ticket transfer confirmation to the ticket system 330, the ticket transfer confirmation including the transfer identifier of the OpenID_1 and the OpenID_2.

[0458] The ticket transfer confirmation is used to inform the ticket system 330 of the OpenID_2 corresponding to the receiver of the electronic ticket 1, so as to facilitate the ticket system 330 to rebind the OpenID_1 corresponding to the ticket information 1 of the electronic ticket 1.

[0459] S1110. The ticket system 330 replaces the OpenID_1 bound to the ticket information 1 with the OpenID_2.

[0460] The ticket system 330 can replace the OpenID_1 bound to the ticket information 1 with the OpenID_2 after identifying the transfer identifier of the OpenID_1 carried in the ticket transfer confirmation.

[0461] After the rebind succeeds, the ticket system 330 can perform the following step S1111.

[0462] S1111. The ticket system 330 sends a transfer success confirmation to the ticket application 41, the transfer success confirmation including the ticket information 1.

[0463] S1112. The ticket application 41 stores and displays the ticket information 1.

[0464] The steps S1112 and S1113 can be steps executed in parallel, or steps executed in a sequence, for example, the step S1112 is executed first and then the step S1113 is executed, or the step S1113 is executed first and then the step S1112 is executed, and the application does not limit the execution order of the two steps.

[0465] The specific content of the step S1112 can refer to the related content of the step S608 shown in the above FIG. 6A, which will not be described here again.

[0466] S1113. The ticket application 41 sends a transfer success notification to the ticket application 12.

[0467] The transfer success notification is used to inform the ticket application 12 that the electronic ticket 1 has been successfully transferred to the electronic device 400.

[0468] S1114. The ticketing application 12 outputs a transfer success prompt.

[0469] The transfer success prompt is used to prompt the user of the electronic device 100 that the electronic ticket 1 has been successfully transferred.

[0470] The electronic device 100 can output the transfer success prompt in any one or more of the following manners: display on a display screen, voice broadcast, vibration, and indicator light flickering.

[0471] The purchased electronic ticket can be shared with the electronic device of another user by using the sharing process shown in FIG. 11, so that the other user can use the electronic ticket to check in to the park. It can be understood that after the sharing process is completed, the user of the electronic device 400 can use the check-in method shown in FIG. 7 to check in to the park.

[0472] It can be understood that the embodiment shown in FIG. 11 is only an example, and in the embodiments of the present application, the electronic device 100 can share the electronic ticket with other electronic devices in a manner different from the above-described embodiment, which is not limited herein.

[0473] Another hardware structure of the electronic device 100 provided in the embodiments of the present application is described below.

[0474] FIG. 12 shows a hardware structure of an electronic device 100 according to an embodiment of the present application.

[0475] The embodiments are described below with the electronic device 100 as an example. It should be understood that the electronic device 100 shown in FIG. 12 is only an example, and the electronic device 100 can have more or fewer components than those shown in FIG. 12, can combine two or more components, or can have a different component configuration. 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] The electronic device 100 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 can include one or more of a pressure sensor 180A, a gyro sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0477] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0478] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices or integrated in one or more processors. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions. The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory can save instructions or data that have just been used or are repeatedly used by the processor 110. If the processor 110 needs to use the instructions or data again, it can directly call from the memory. This avoids repeated access and reduces the waiting time of the processor 110, thereby improving the efficiency of the system.

[0479] In some embodiments, the processor 110 can include one or more interfaces. The interfaces can 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 can be understood that the interface connection relationship between the modules shown in the embodiments of the present application is only illustrative and does not constitute a structural limitation of the electronic device 100. In some other embodiments of the present application, the electronic device 100 can also use different interface connection modes or a combination of multiple interface connection modes in the above embodiments.

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

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

[0483] The mobile communication module 150 can provide a solution for wireless communication including 2G / 3G / 4G / 5G, etc. applied to the electronic device 100. The mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1 and perform filtering, amplification, etc. on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can also amplify the signals modulated by the modem processor and convert them into electromagnetic waves radiated through the antenna 1. In some embodiments, at least part of the functional modules of the mobile communication module 150 can be arranged in the processor 110. In some embodiments, at least part of the functional modules of the mobile communication module 150 and at least part of the modules of the processor 110 can be arranged in the same device.

[0484] The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc. applied to the electronic device 100. The wireless communication module 160 can be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives an electromagnetic wave via the antenna 2, frequency-modulates and filters the electromagnetic wave signal, and transmits the processed signal to the processor 110. The wireless communication module 160 can also receive a signal to be transmitted from the processor 110, frequency-modulate it, amplify it, and radiate it as an electromagnetic wave via the antenna 2.

[0485] In some embodiments, the antenna 1 and the mobile communication module 150 of the electronic device 100 are coupled, and the antenna 2 and the wireless communication module 160 are coupled, so that the electronic device 100 can communicate with a network and other devices through wireless communication technology. The wireless communication technology can 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 technology, etc. The GNSS can include a global positioning system (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and / or a satellite based augmentation systems (SBAS).

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

[0487] The display 194 is configured to display images, videos, and the like. The display 194 includes a display panel. The display panel can be implemented by a liquid crystal display (LCD). The display panel can also be implemented by an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flex light-emitting diode (FLED), a miniled, a microled, a micro-oled, a quantum dot light emitting diodes (QLED), or the like. In some embodiments, the electronic device 100 can include one or N displays 194, where N is a positive integer greater than 1.

[0488] The electronic device 100 can implement a photographing function through an ISP, the camera 193, a video codec, a GPU, the display 194, and an application processor.

[0489] The external memory interface 120 can be configured to connect with 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 configured to store computer-executable program codes including instructions. The processor 110 can execute 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 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required for at least one function (such as a sound play function, an image play function, and the like), and the like. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phonebook, and the like), and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory such as at least one of a magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like.

[0490] The electronic device 100 can implement an audio function through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and an application processor. For example, music play, recording, and the like.

[0491] The pressure sensor 180A is configured to sense a pressure signal and convert the pressure signal into an electrical signal. The gyro sensor 180B is configured to determine a motion posture of the electronic device 100. The barometric sensor 180C is configured to measure a barometric pressure. The magnetic sensor 180D includes a Hall sensor. The acceleration sensor 180E is configured to detect an acceleration of the electronic device 100 in various directions (typically, three axes). The distance sensor 180F is configured to measure a distance. The proximity light sensor 180G can include, for example, a light emitting diode (LED) and a photo detector, such as a photodiode. The ambient light sensor 180L is configured to sense an ambient light brightness. The fingerprint sensor 180H is configured to acquire a fingerprint. The temperature sensor 180J is configured to detect a temperature. The touch sensor 180K, also referred to as a "touch panel," can be disposed on the display screen 194. The touch sensor 180K and the display screen 194 can form a touch screen, also referred to as a "touch screen panel." The touch sensor 180K is configured to detect a touch operation applied thereto or in the vicinity thereof. The touch sensor 180K can transmit a detected touch operation to the application processor to determine a touch event type. A visual output related to the touch operation can be provided via the display screen 194. In other embodiments, the touch sensor 180K can be disposed on a surface of the electronic device 100, which is different from a location where the display screen 194 is disposed. The bone conduction sensor 180M can acquire a vibration signal. The keys 190 include a power key, a volume key, and the like. The motor 191 can generate a vibration alert. The indicator 192 can be an indicator light configured to indicate a charging state, a power level change, and the like, and can also be configured to indicate a message, a missed call, a notification, and the like.

[0492] The SIM card interface 195 is configured to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than one. The SIM card interface 195 can support a Nano SIM card, a Micro SIM card, a SIM card, and the like. The same SIM card interface 195 can simultaneously insert multiple cards. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external storage cards. The electronic device 100 interacts with a network through the SIM card to achieve functions such as calling 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 be specifically configured to establish a short-range wireless communication link with the NFC card reader 102, so as to perform short-range wireless data transmission between the two. Exemplarily, the 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 appropriate components for implementing proximity-based non-contact communication between the electronic device 100 and the gate 200, thereby providing the electronic device 100 with NFC functionality. The description of the NFC module can refer to the embodiment shown in FIG. 3A, which will not be repeated here.

[0494] The above describes the method provided by the present application in detail. In order to facilitate better implementation of the above-mentioned scheme of the embodiments of the present application, the embodiments of the present application also provide corresponding devices or equipment.

[0495] The embodiments of the present application can divide the functional modules of the electronic device 100 and the gate 200 according to the above-mentioned method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be realized in the form of hardware or in the form of a software functional module. It should be noted that the division of the modules in the embodiments of the present application is illustrative, and is only a logical functional division. Actual implementation can have another division manner.

[0496] The communication device of the embodiments of the present application will be described in detail below with reference to FIGS. 13 to 16.

[0497] In the case of using an integrated unit, referring to FIG. 13, FIG. 13 is a structural schematic diagram of a communication device 1100 provided by the embodiments of the present application. The communication device 1100 can be the electronic device 100 in the above-mentioned embodiments. Alternatively, the communication device 1100 can be a chip / chip system, for example, an NFC chip. As shown in FIG. 13, the communication device 1100 can include a transceiver unit 1110 and a processing unit 1120.

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

[0499] Alternatively, the processing unit 1120 can also be used to perform the functions of NFC protocol analysis and packaging, NFC service processing flow, and display performed by the electronic device 100 in the above-mentioned embodiments of the present application.

[0500] It should be understood that the communication apparatus 1100 in this design can correspondingly perform the method steps performed by the electronic device 100 in the foregoing embodiments, which will not be repeated here for brevity.

[0501] In the case of using an integrated unit, referring to FIG. 14, which is a structural schematic diagram of a communication apparatus 1200 provided by an embodiment of the present application. The communication apparatus 1200 can be the gate 200 in the foregoing embodiments. Alternatively, the communication apparatus 1200 can be the gate 200. As shown in FIG. 14, the communication apparatus 1200 can include a transceiver unit 1210 and a processing unit 1220.

[0502] Alternatively, the transceiver unit 1210 can also be configured to perform the NFC sending and NFC receiving function steps performed by the gate 200 in the foregoing embodiments of the present application.

[0503] Alternatively, the processing unit 1220 can also be configured to perform the NFC protocol analysis and packaging, and NFC service processing flow function steps performed by the gate 200 in the foregoing embodiments of the present application.

[0504] It should be understood that the communication apparatus 1200 in this design can correspondingly perform the method steps performed by the gate 200 in the foregoing embodiments, which will not be repeated here for brevity.

[0505] The electronic device 100 and the gate 200 of the embodiments of the present application are introduced above. It should be understood that any product with the functions of the electronic device 100 described in FIG. 13 and any product with the functions of the gate 200 described in FIG. 14 fall within the protection scope of the embodiments of the present application.

[0506] As a possible product form, the electronic device 100 described in the embodiments of the present application can be implemented by a general bus architecture.

[0507] Referring to FIG. 15, FIG. 15 is a structural schematic diagram of a communication apparatus 1300 provided by the embodiments of the present application. The communication apparatus 1300 can be the electronic device 100, or an apparatus therein. As shown in FIG. 15, the communication apparatus 1300 includes a processor 1301 and a transceiver 1302 connected with the processor 1301 internally. The processor 1301 can be a general processor or a special purpose 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 transceiving unit, a transceiver, or a transceiving circuit, etc., and is configured to implement a transceiving function. The transceiver 1302 can include a receiver and a transmitter. The receiver can be referred to as a receiver or a receiving circuit, etc., and is configured to implement a receiving function, for example, an NFC receiving function. The transmitter can be referred to as a transmitter or a transmitting circuit, etc., and is configured to implement a transmitting function, for example, an NFC transmitting function. Optionally, the communication apparatus 1300 can further include an antenna 1303 and / or a radio frequency unit (not shown in FIG. 15), for example, an NFC antenna, wherein the NFC antenna can be a coil-shaped antenna. The antenna 1303 and / or the radio frequency unit can be located internally in the communication apparatus 1300, or can be separated from the communication apparatus 1300, i.e., the antenna 1303 and / or the radio frequency unit can be remotely located or distributedly deployed.

[0508] Optionally, one or more memories 1304 can be included in the communication apparatus 1300, and instructions can be stored in the memories 1304. The instructions can be computer programs, which can be run on the communication apparatus 1300, so that the communication apparatus 1300 performs the method steps described in the above embodiments of the present application. Optionally, data can also be stored in the memories 1304. The communication apparatus 1300 and the memories 1304 can be separately arranged, or can be integrated together.

[0509] The processor 1301, the transceiver 1302, and the memories 1304 can be connected through a communication bus.

[0510] In one design, the communication apparatus 1300 can be configured to perform the functions of the electronic device 100 in the above embodiments. The processor 1301 can be configured to perform the function steps related to NFC protocol analysis and packaging, NFC service processing flow, and display, etc., performed by the electronic device 100 in the above embodiments of the present application and / or other processes for the techniques described herein. The transceiver 1302 can be configured to perform the function steps related to NFC transmitting and NFC receiving, etc., performed by the electronic device 100 in the above embodiments of the present application and / or other processes for the techniques described herein.

[0511] In any of the above designs, the processor 1301 can include a transceiver for implementing the receiving and transmitting functions. For example, the transceiver can be a transceiver circuit, or an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing the receiving and transmitting functions can be separate or integrated together. The above transceiver circuit, interface, or interface circuit can be used for reading and writing of code / data, or the above transceiver circuit, interface, or interface circuit can be used for transmission or transfer of signals.

[0512] In any of the above designs, the processor 1301 can store instructions, which can be a computer program, running on the processor 1301, to cause the communication apparatus 1300 to perform the method steps performed by the electronic device 100 in the above embodiments. The computer program can be fixed in the processor 1301, in which case the processor 1301 can be implemented by hardware.

[0513] In an implementation manner, the communication apparatus 1300 can include a circuit, which can implement the functions of sending or receiving or communication in the above method embodiments. The processor and the transceiver described in the present application can be implemented on an integrated circuit (IC), an analog IC, a radio frequency integrated circuit (RFIC), a mixed signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, etc. The processor and the transceiver can also be manufactured by various IC process technologies, such as complementary metal oxide semiconductor (CMOS), N-type metal oxide semiconductor (NMOS), P-type metal oxide semiconductor (PMOS), bipolar junction transistor (BJT), bipolar CMOS (BiCMOS), silicon germanium (SiGe), gallium arsenide (GaAs), etc.

[0514] The scope of the communication apparatus described in the present application is not limited thereto, and the structure of the communication apparatus can not be limited by FIG. 15. The communication apparatus 1300 can be a standalone device or can be part of a larger device. For example, the communication apparatus 1300 can be:

[0515] (1) an independent integrated circuit (IC), or chip, or chip system or subsystem; (2) a set of one or more ICs, optionally including storage for data, computer programs, etc.; (3) an ASIC, such as a NFC chip; (4) a module that can be embedded within other devices; (5) a receiver, terminal, smart terminal, cellular telephone, wireless device, handset, mobile unit, fixed or mobile subscriber unit, pager, computer, laptop computer, PDA, wireless terminal, wireless modem, wireless communication device, portable computer, desktop computer, server, router, gateway, or network node, etc.; (6) other devices, etc.

[0516] As a possible product form, the gate machine 200 described in the embodiments of the present application can be implemented by a general bus architecture.

[0517] Referring to FIG. 16, FIG. 16 is a structural schematic diagram of a communication apparatus 1400 provided by the embodiments of the present application. The communication apparatus 1400 can be the gate machine 200, or an apparatus therein. As shown in FIG. 16, the communication apparatus 1400 includes a processor 1401 and a transceiver 1402 in communication with the processor 1401. The processor 1401 can be a general processor or a special purpose processor, etc. For example, it can be a NFC controller. The transceiver 1402 can be referred to as a transceiving unit, a transceiver, or a transceiving circuit, etc., and is configured to implement a transceiving function. The transceiver 1402 can include a receiver and a transmitter. The receiver can be referred to as a receiver or a receiving circuit, etc., and is configured to implement a receiving function. The transmitter can be referred to as a transmitter or a transmitting circuit, etc., and is configured to implement a transmitting function. Optionally, the communication apparatus 1400 can further include an antenna 1403 and / or a radio frequency unit (not shown in the figure). The antenna 1403 and / or the radio frequency unit can be located inside the communication apparatus 1400, or can be separate from the communication apparatus 1400, i.e., the antenna 1403 and / or the radio frequency unit can be remotely located or distributed.

[0518] Optionally, the communication apparatus 1400 can include one or more memories 1404, which can store instructions, e.g., a computer program, that can be run on the communication apparatus 1400, so that the communication apparatus 1400 performs the method steps described in the embodiments of the present application. Optionally, the memory 1404 can also store data. The communication apparatus 1400 and the memory 1404 can be separately arranged, or can be integrated together.

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

[0520] In one design, the communication apparatus 1400 can be configured to perform the functions of the gatekeeper 200 in the preceding embodiments: the processor 1401 can be configured to perform the functional steps of the gatekeeper 200 in the preceding embodiments shown in FIG. 16 and / or other procedures for the techniques described herein related to NFC protocol parsing and packaging, NFC service processing flow; the transceiver 1402 can be configured to perform the functional steps of the gatekeeper 200 in the preceding embodiments shown in FIG. 16 and / or other procedures for the techniques described herein related to NFC transmission and NFC reception, etc.

[0521] In any of the above designs, the processor 1401 can include a transceiver for implementing the receiving and transmitting functions. For example, the transceiver can be a transceiver circuit, or an interface, or an interface circuit. The transceiver circuit, interface or interface circuit for implementing the receiving and transmitting functions can be separate or integrated together. The above transceiver circuit, interface or interface circuit can be used for code / data reading and writing, or the above transceiver circuit, interface or interface circuit can be used for signal transmission or transfer.

[0522] In any of the above designs, the processor 1401 can store instructions, which can be a computer program, running on the processor 1401, to make the communication apparatus 1400 perform the method steps of the gatekeeper 200 in the above method embodiments. The computer program can be fixed in the processor 1401, in which case the processor 1401 can be implemented by hardware.

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

[0524] FIG. 17 shows a hardware structure diagram of a server 1500 provided by the embodiments of the present application.

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

[0526] The communication interface 1503 can be used for the server 1500 to communicate with other communication devices, for example, to communicate with electronic devices used by consumers of 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 the present application, the transmitter 1505 and the receiver 1506 can be regarded as a wireless modem. The transmitter 1505 can be used for transmitting processing of signals output by the network device processor 1501. The receiver 1506 can be used for receiving signals. In the server 1500, the number of the transmitter 1505 and the receiver 1506 can be one or more. The antenna 1508 can be used for converting electromagnetic energy in a transmission line into electromagnetic waves in free space, or converting electromagnetic waves in free space into electromagnetic energy in a transmission line. The coupler 1507 can be used for dividing a mobile communication signal into multiple paths and distributing to multiple receivers 1506. It can be understood that the antenna 1508 of the network device can be implemented as a large-scale antenna array.

[0528] The memory 1502 is coupled to the network device processor 1501 and is used for storing various software programs and / or sets of instructions. Specifically, the memory 1502 can include a high-speed random access memory, and can also include a 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 a system), such as an embedded operating system, uCOS, VxWorks, RTLinux, etc. The memory 1502 can also store a network communication program, which can be used for communication with other communication devices.

[0530] In the embodiments of the present application, 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 programs stored in the memory 1502, such as an implementation program of the ticket checking method provided by one or more embodiments of the present application, and execute instructions contained in the program. Optionally, an implementation program of the ticket purchasing method provided by one or more embodiments of the present application can also be included, and instructions contained in the program can be executed.

[0531] It should be noted that in the embodiments of the present application, the hardware structure of any one of the servers in the cloud server 300 (such as the electronic ticket business cloud 310, the account cloud 320, the ticketing system 330, etc.) can refer to the hardware structure of the server 1500 shown in FIG. 17.

[0532] It can be understood that the server 1500 shown in FIG. 17 is only one implementation manner of the embodiments of the present application, and the server 1500 can also include more or fewer components in actual application, which is not limited here.

[0533] FIG. 18 shows a flow diagram of a ticket checking method provided by an embodiment of the present application.

[0534] As shown in FIG. 18, a specific flow of a ticket checking method provided by the embodiment of the present application can include the following steps.

[0535] S1801. The first electronic device logs in a first account, and after entering the radio frequency field of the gate, the first electronic device receives a first project identifier sent by the gate.

[0536] For example, the first electronic device can be the electronic device 100 in the above embodiment, or the electronic device 400 in the above embodiment.

[0537] The gate can be the gate 200 in the above embodiment.

[0538] For example, the first project identifier can be the project identifier 1 in the above embodiment.

[0539] S1802. The first electronic device determines a first gate opening identifier OpenID based on the first project identifier, the first OpenID is generated by the first project identifier and the first account, and the first OpenID is used for the gate to verify whether the first account logged in the first electronic device has the right to open the gate.

[0540] For example, the first gate opening identifier OpenID can be the OpenID_1 in the above embodiment.

[0541] The first account can be the account logged in by the electronic device 100 in the above embodiment.

[0542] S1803. The first electronic device sends a first response to the gate, and the first response includes the first OpenID.

[0543] For example, the first response can be the service response in the embodiment shown in FIG. 7.

[0544] It can be understood that the specific content of the steps in the embodiment shown in FIG. 18 can also refer to the related description in the embodiment shown in FIG. 7, which will not be repeated here.

[0545] In this way, the first electronic device can complete ticket checking by touching the gate, simplifying the ticket checking steps, improving the ticket checking efficiency, and bringing a better experience to the user.

[0546] In a possible implementation, the first OpenID is determined based on the first project identifier, and specifically includes: determining the first OpenID corresponding to the first project identifier from one or more OpenIDs stored in the first electronic device.

[0547] The specific way in which the first electronic device determines the first OpenID from one or more OpenIDs stored locally can refer to steps S901 to S904 in the embodiment shown in FIG. 9.

[0548] By using the ticket checking method provided in the application, the first electronic device can obtain the first OpenID from the locally stored OpenID, thereby completing ticket checking. In this way, even if the first electronic device is in an offline state, ticket checking can be completed.

[0549] In a possible implementation, the first OpenID is determined based on the first item identifier, and specifically includes: sending the first item identifier and a first account of the first electronic device to an account cloud; and receiving the first OpenID sent by the account cloud.

[0550] The specific manner in which the first electronic device obtains the first OpenID from the account cloud can refer to the related description in steps S907 and S908 in the embodiment shown in FIG. 9, and will not be described here again. The account cloud can be the account cloud 320 in the above embodiment.

[0551] By using the ticket checking method provided in the application, the first electronic device can obtain the first OpenID corresponding to the first account and the first item identifier through the account cloud. In this way, the first electronic device does not need to store the first OpenID locally, thereby saving storage space.

[0552] In a possible implementation, the first item identifier and the first account of the first electronic device are sent to the account cloud, and specifically includes: sending the first item identifier and the first account to the account cloud through an electronic ticket business cloud.

[0553] The electronic ticket business cloud can be the electronic ticket business cloud 310 in the above embodiment.

[0554] In this way, the first electronic device can interact with the account cloud through the electronic ticket business cloud.

[0555] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: receiving a first request sent by the gate, the first request including a first device identifier of the first electronic device; sending a verification request to the electronic ticket business cloud, the verification request including the first device identifier, the verification request being used to request the electronic ticket business cloud to verify whether the first device identifier is valid; and receiving a first verification response sent by the electronic ticket business cloud, the first verification response being used to inform the first electronic device that the first device identifier is valid.

[0556] For example, the first request can be the service request in the embodiment shown in FIG. 7, the first device identifier can be the device identifier of the gate 200 in the above embodiment, the first verification request can be the validity verification request in the embodiment shown in FIG. 8, and the first verification response can be the validity verification response 1 in the embodiment shown in FIG. 8. The specific manner in which the first electronic device verifies whether the first device identifier is valid through the electronic ticket service cloud can refer to the related description in the embodiment shown in FIG. 8, which will not be repeated here.

[0557] By using the ticket checking method provided in this application, the first electronic device can verify the first device identifier of the gate through the electronic ticket service cloud in the ticket checking process, to determine whether the first device identifier is valid. In this way, the security of the ticket checking process can be improved, and the user can be prevented from being damaged by interacting with an invalid gate.

[0558] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: generating a first digest based on a preset first random number through a first hash algorithm; receiving a second digest sent by the gate; and determining that the gate is a trusted device if the first digest is the same as the second digest.

[0559] In this way, the gate can be verified to be a trusted device through security verification, thereby improving the security of the ticket checking process.

[0560] In a possible implementation, the method further includes: receiving a second random number sent by the gate; generating a third digest based on the first random number and the second random number through the first hash algorithm; and sending the third digest to the gate, where the third digest is used by the gate to determine whether the first electronic device is a trusted device.

[0561] In this way, the gate can verify whether the first electronic device is a trusted device through security verification, thereby improving the security of the ticket checking process.

[0562] For example, the specific manner in which the first electronic device and the gate verify each other to be trusted devices can refer to the related description in step S707 shown in FIG. 7, which will not be repeated here.

[0563] In a possible implementation, after entering the radio frequency field of the gate, the method further includes: receiving a probe frame sent by the gate, the probe frame being used to indicate that the gate supports a specified NFC protocol; sending a probe acknowledgement frame to the gate, the probe acknowledgement frame being used to indicate that the first electronic device supports the specified NFC protocol; receiving a notification frame sent by the gate, the notification frame carrying device characteristic information of the gate, the device characteristic information of the gate including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of NFC service supported by the gate, and the device organization identifier is used to indicate a manufacturer that provides the NFC service using the gate; determining, based on the device characteristic information of the gate, that the type of the NFC service of the gate is an electronic ticket; and sending a notification acknowledgement frame to the gate, the notification acknowledgement frame being used to indicate that the first electronic device has received the notification frame.

[0564] In this way, the interaction can be completed through the pre-agreed NFC protocol, and ticket checking can be implemented.

[0565] In a possible implementation, before entering the radio frequency field of the gate, the method includes: receiving and corresponding to an operation of purchasing a first ticket by a user, obtaining a first project identifier corresponding to the first ticket; sending the first project identifier and a first account to an account cloud; receiving a first OpenID sent by the account cloud; sending a ticket purchase request to a ticket system server, the ticket purchase request including the first OpenID and a first purchase number of the first ticket; receiving first ticket information sent by the ticket system server, the first ticket information including a first ticket identifier of the first ticket and the first purchase number; and displaying the first ticket information.

[0566] The ticket system server can be the ticket system 330 in the above embodiments.

[0567] For example, the first ticket can be the electronic ticket 1 in the above embodiments such as FIG. 6A; the ticket purchase request can be the ticket purchase request in the above embodiment shown in FIG. 6A; and the first ticket information can be the ticket information 1 in the above embodiment shown in FIG. 6A.

[0568] The specific manner in which the first electronic ticket purchases the first ticket can refer to the related description in the above embodiment shown in FIG. 6A, which will not be described here again.

[0569] In this way, the first electronic device can purchase a specified electronic ticket, and complete ticket checking through the purchased electronic ticket.

[0570] In a possible implementation, the ticket purchase request further includes any one or more of the following: the first item identifier, the ticket type, and the validity period of the first ticket; and the first ticket information further includes any one or more of the following: the ticket type, the validity period of the first ticket, and the verification status of the first ticket, the verification status of the first ticket being used to indicate whether the first ticket is verified.

[0571] In this way, the type, validity period, and verification status of the electronic ticket purchased by the user can be indicated by the first ticket information.

[0572] In a possible implementation, before entering the radio frequency field of the gate, the method further includes: after logging in the first account, sending an information synchronization request to the electronic ticket business cloud, the information synchronization request including the first account; and receiving second ticket information sent by the electronic ticket business cloud, the second ticket information including information of one or more electronic tickets purchased by the first account, the one or more electronic tickets including the first ticket, and the first ticket being bound to the first OpenID.

[0573] It can be understood that the specific process in which the first electronic device synchronizes ticket information based on the first account can refer to the related description in the embodiment of FIG. 6B, which will not be described here again.

[0574] In this way, when the user purchases the first ticket corresponding to the first item identifier through an electronic device other than the first electronic device based on the first account, the user can log in the first account on the first electronic device, obtain the related information of the first ticket from the electronic ticket business cloud, and complete ticket checking.

[0575] In a possible implementation, before entering the radio frequency field of the gate, the method further includes: receiving a ticket sharing request sent by the second electronic device, the ticket sharing request including the first transfer identifier of the second OpenID and the first item identifier, and the ticket sharing request being used to request sharing the first ticket bound to the first OpenID to the first electronic device; sending the first account of the first electronic device and the first item identifier to the account cloud; receiving the first OpenID generated based on the first account and the first item identifier and sent by the account cloud; sending a ticket transfer confirmation to the ticketing system server, the ticket transfer confirmation including the first transfer identifier and the first OpenID; receiving a transfer success confirmation sent by the ticketing system server, the transfer success confirmation being used to notify the first electronic device that the first OpenID is bound to the first ticket; and sending a transfer success notification to the second electronic device, the transfer success notification being used to notify the second electronic device that the first ticket transfer is successful.

[0576] Exemplarily, in the possible implementation manner, the first electronic device can be the electronic device 400 in the embodiment shown in FIG. 11, and the second electronic device can be the electronic device 100 in the embodiment shown in FIG. 11; the second OpenID can be OpenID_1 in the embodiment shown in FIG. 11, the first transfer identifier can be the transfer identifier of OpenID_1 in the embodiment shown in FIG. 11; the first ticket can be the electronic ticket 1 shown in FIG. 11; and the first OpenID can be OpenID_2 in the embodiment shown in FIG. 11.

[0577] It can be understood that the specific process in which the first electronic device receives the first ticket shared by the second electronic device can also refer to the related description in the embodiment shown in FIG. 11, which will not be described here again.

[0578] In this way, the first electronic device can receive the first ticket purchased by the second electronic device through ticket sharing, and complete ticket checking.

[0579] In a possible implementation manner, the first OpenID is bound to one or more electronic tickets.

[0580] In this way, the first OpenID can be used to check one or more electronic tickets, that is, the user can realize multi-person park entry by touching the gate with the first electronic device.

[0581] In a possible implementation manner, the first electronic device includes an electronic ticket service and a near field communication (NFC) protocol stack; the method of receiving the first project identifier sent by the gate machine specifically includes: receiving the first routing information through the NFC protocol stack, the first routing information including the first project identifier; after receiving the first project identifier sent by the gate machine, the method further includes: sending the first routing confirmation to the gate machine through the NFC protocol stack, the first routing confirmation being used to notify the gate machine that the first electronic device successfully receives the first routing information; determining the first OpenID based on the first project identifier, specifically including: sending the first project identifier to the electronic ticket service based on the first routing information through the NFC protocol stack; determining the first OpenID based on the first project identifier through the electronic ticket service; and sending the first response to the gate machine, specifically including: sending the first response to the gate machine based on the NFC protocol stack through the electronic ticket service.

[0582] Exemplarily, the electronic ticket service can be the electronic ticket service 11 in the above embodiment, and the NFC protocol stack can be the NFC protocol stack 14 in the above embodiment.

[0583] In this way, the first electronic device can pull up the electronic ticket service based on the first project identifier, and obtain the first OpenID through the electronic ticket service to complete ticket checking.

[0584] FIG. 19 shows a flowchart of a ticket checking method according to an embodiment of the present application.

[0585] As shown in FIG. 19, the specific process of the ticket checking method according to an embodiment of the present application can include the following steps.

[0586] S1901. The gate sends a first project identification to the first electronic device after the first electronic device enters the radio frequency field of the gate.

[0587] For example, the gate can be the gate 200 in the above embodiment; the first electronic device can be the electronic device 100 in the above embodiment; and the first project identification can be the project identification 1 in the above embodiment.

[0588] S1902. The gate receives a first response sent by the first electronic device, and the first response includes a first gate opening identification OpenID.

[0589] For example, the first response can be the service response in the embodiment shown in FIG. 7; and the first OpenID can be the OpenID_1 in the above embodiment.

[0590] S1903. The gate opens and releases based on the first OpenID.

[0591] It can be understood that the specific content of the steps in the embodiment shown in FIG. 19 can also refer to the related steps in the embodiment shown in FIG. 7, which will not be described here.

[0592] In this way, the gate can complete ticket checking through interaction with the first electronic device, and simplify the ticket checking process.

[0593] In a possible implementation, opening and releasing based on the first OpenID specifically includes: sending a first verification request to a ticketing system server, the first verification request including the first OpenID; receiving a first verification response sent by the ticketing system server; and opening and releasing the gate in response to the first verification response.

[0594] The specific process of the gate verifying the first OpenID through interaction with the ticketing system server can refer to the related description of steps S716 to S724 shown in FIG. 7, which will not be described here.

[0595] In this way, the gate can open and release the gate in the case where it is determined that the first OpenID is verified to be valid.

[0596] In some application scenarios, such as the electronic ticket purchase and ticket checking scenarios of scenic spots, the cloud server 300 can further include a scenic spot background 350. The scenic spot background 350 can correspond to one or more scenic spots (for example, a scenic spot A), and the scenic spot background 350 can interact with the gate machine of the scenic spot A, and based on the verification request sent by the gate machine, determine whether to instruct the gate machine to open the gate by interacting with the ticket system 330. It can be understood that in other application scenarios, such as ticket purchase and ticket checking scenarios of events, or ticket checking scenarios of large-scale gatherings, the scenic spot background 350 can also be replaced by other types of background servers, which are not limited in the present application.

[0597] For example, FIG. 20 shows an interaction schematic diagram between the electronic device 100, the gate machine 200, the cloud server 500, and the cloud server 600 in a ticket checking process according to an embodiment of the present application.

[0598] As shown in FIG. 20, the cloud server 500 can include one or more servers (or server modules), such as the account cloud 320, etc. The cloud server 600 can include one or more servers (or server modules), such as the ticket system 330, the scenic spot background 350 (also referred to as a background server), etc. The one or more servers can be respectively arranged at different locations and operated by one or more operators. The physical locations of the modules in the cloud server 500 and the cloud server 600 are not limited in the present application.

[0599] Among them:

[0600] The account cloud 320 can provide account registration, authentication, and account management services such as account cancellation. The account cloud 320 can establish a communication connection with the electronic device 100. In some embodiments, the account cloud 320 can generate an open gate identifier (OpenID) based on the account (also referred to as a first account) of the electronic device 100 and the project identifier. After generating the open gate identifier (OpenID), the account cloud 320 can send the open gate identifier (OpenID) to the electronic device 100. In some embodiments, when the user checks the ticket, the account cloud 320 can also return the corresponding open gate identifier to the electronic device 100 based on the account of the electronic device 100 and the project identifier sent by the electronic device 100.

[0601] The scenic spot background 350 can correspond to one or more scenic spots, such as scenic spot A, etc. In some embodiments, the scenic spot background 350 can be a server providing services for a single scenic spot (such as scenic spot A), in which case the scenic spot background 350 can correspond to a unique project identifier, and the scenic spot background 350 can provide electronic ticket purchase, verification, etc. services for the project indicated by the project identifier. In other embodiments, the scenic spot background 350 can be a server providing services for multiple projects (such as multiple scenic spots, etc.), in which case the scenic spot background 350 can correspond to multiple project identifiers, and the scenic spot background 350 can provide electronic ticket purchase, verification, etc. services for the multiple projects corresponding to the multiple project identifiers.

[0602] In some embodiments, the scenic spot background 350 can exist independently of the ticketing system 330. In other embodiments, the scenic spot background 350 can also be integrated inside the ticketing system 330. It should be noted that in the ticket purchase and ticket inspection scenarios of the scenic spot, the cloud server 300 can include the scenic spot background 350, and in other scenarios, the scenic spot background 350 can be replaced by other types of background servers, which are not limited by the present application.

[0603] The scenic spot background 350 can have one or more client applications and / or applets (such as the ticketing application 12, the wallet application 13 in the above-mentioned embodiment of FIG. 3B, or the meta-service 17 in the following embodiment, etc.) The scenic spot background 350 can communicate and interact with electronic devices (such as the electronic device 100) installed with any of the above-mentioned client applications or applets. The scenic spot background 350 can provide online ticket purchase services for the electronic device 100, and the user can purchase tickets through any of the above-mentioned client applications or applets. During the user's purchase of tickets using the electronic device 100, the scenic spot background 350 can obtain the account and gate opening identifier of the electronic device 100, and complete the purchase of the electronic ticket through interaction with the ticketing system 330. After the ticket purchase is successful, the scenic spot background 350 can send the order information sent by the ticketing system 330 to the electronic device 100, and store the correspondence between the account and the gate opening identifier of the electronic device 100.

[0604] In some embodiments, during the ticket checking process of the user using the electronic device 100, for example, in the scenario that the electronic device 100 and the gate 200 select the online electronic ticket service, the scenic area background 350 can receive the opening gate identifier and the device identifier of the gate 200 (hereinafter referred to as the ID of the gate 200) sent by the electronic device 100. Then, the scenic area background 350 can verify whether the opening gate identifier is valid through interaction with the ticketing system 330. After receiving the verification request sent by the gate 200 and determining that the opening gate identifier is valid, the scenic area background 350 can instruct the gate 200 to open. After receiving the verification request sent by the gate 200 and determining that the opening gate identifier is invalid, the scenic area background 350 can instruct the gate 200 not to open.

[0605] In some embodiments, during the ticket checking process of the user using the electronic device 100, for example, in the scenario that the electronic device 100 and the gate 200 select the offline electronic ticket service, the scenic area background 350 can receive the authentication information such as the token certificate index, the random number, the ID of the gate 200, and the verification value sent by the electronic device 100 through the gate 200, and authenticate the authentication information through a preset verification algorithm. After the authentication is passed, the order information is determined through the token certificate index, and then it is judged whether to instruct the gate 200 to open based on the order information.

[0606] The ticketing system 330 can interact with the scenic area background 350 to provide services such as purchase of electronic tickets and verification of opening gate identifiers. During the ticket purchase process, after receiving the ticket purchase information sent by the electronic device 100, the scenic area background 350 can send the account number of the electronic device 100 and the ticket purchase information to the ticketing system 330. The ticketing system 330 can generate order information based on the ticket purchase information and store the correspondence between the account number of the electronic device 100 and the order information. Then, the ticketing system 330 can return the order information to the scenic area background 350. During the ticket checking process, after receiving the opening gate identifier sent by the electronic device 100, the scenic area background 350 can determine the account number of the electronic device 100 based on the correspondence between the opening gate identifier and the account number of the electronic device 100, and send the account number of the electronic device 100 to the ticketing system 330. The ticketing system 330 can query the order information corresponding to the account number based on the account number of the electronic device 100, and send the order information to the scenic area background 350. The scenic area background 350 can determine whether the opening gate identifier is valid based on the electronic ticket indicated by the order information.

[0607] It can be understood that the above-mentioned embodiment shown in FIG. 20 is only an example, and in the embodiments of the present application, any one of the above-mentioned servers can also be split into multiple servers, and any two or more servers can also be combined into one server, which is not limited herein. In addition, the cloud server 300 can also include more, fewer or different servers (or server modules) than the above-mentioned embodiments, and each server can also have more, fewer or different functions than the above-mentioned embodiments, which is also not limited herein.

[0608] Next, another ticket purchasing method and ticket checking method provided by the present application are introduced.

[0609] FIG. 21 shows a ticket purchasing flowchart provided by an embodiment of the present application.

[0610] As shown in FIG. 21, the electronic device 100 can include a meta-service 17, which can be used to purchase a ticket. In the process of purchasing a ticket by the user through the electronic device 100, the interaction flow of the electronic device 100 with the ticketing system 330, the account cloud 320, the scenic spot background 350 and other servers can include the following steps:

[0611] S2101. The meta-service 17 receives a ticket purchasing operation 1 of the user, and the ticket purchasing operation 1 is used to trigger the electronic device 100 to purchase an electronic ticket 1.

[0612] In some embodiments, the meta-service 17 can include any one or more of the electronic ticket service 11 and the ticketing application 12 in the above-mentioned embodiments.

[0613] S2102. The meta-service 17 sends the account of the electronic device 100 and the project identifier 1 to the account cloud 320, and the project identifier 1 is the project identifier corresponding to the electronic ticket 1.

[0614] The account of the electronic device 100 can be used to identify the identity of the user of the current electronic device 100. In the embodiments of the present application, the account of the electronic device 100 refers to the account currently logged in by the electronic device 100, and the user can also use this account to log in to other electronic devices and communicate with the account cloud 320. In some embodiments, the account of the electronic device 100 can also be the mobile phone number of the electronic device 100, etc.

[0615] S2103. The account cloud 320 generates an open identifier 1 (OpenID_1) based on the account of the electronic device 100 and the project identifier 1.

[0616] S2104. The account cloud 320 sends the OpenID_1 to the meta-service 17.

[0617] ​The specific content of steps S2101-S2104 can also refer to the related content in steps S601-S604 shown in FIG. 6A described above, and will not be described here again.

[0618] S2105. The meta-service 17 sends a ticket purchase request to the scenic spot background 350, the ticket purchase request including the account of the electronic device 100, the ticket number of the ticket 1, and the OpenID_1, and optionally further including the project identifier 1.

[0619] In some embodiments, the scenic spot background 350 can be a ticketing system that only serves one scenic spot (for example, scenic spot A), in which case the ticket purchase request can or can not carry the project identifier 1.

[0620] In other embodiments, the scenic spot background 350 can also serve multiple scenic spots, in which case the ticket purchase request can carry the project identifier 1, which indicates the project to which the electronic ticket 1 purchased by the user corresponds.

[0621] Further optionally, the ticket purchase request can further include any one or more of the following: ticket type, validity period, ticket purchaser information, etc. The ticket type can include any one or more of the following: adult ticket, student ticket, senior citizen ticket, child ticket, family ticket, other types of preferential ticket, etc. The ticket type is used to indicate the type of ticket purchased by the user. The validity period can be used to indicate the validity period of the electronic ticket 1, for example, if the validity period includes July 10, 2024, the electronic ticket 1 can be used on July 10, 2024. The ticket purchaser information can be used to indicate the identity information of the purchaser of each electronic ticket, such as name and / or ID number, etc.

[0622] S2106. The scenic spot background 350 stores the correspondence between the account of the electronic device 100 and the OpenID_1.

[0623] In some embodiments, the scenic spot background 350 can store the account of the electronic device 100 and the OpenID_1 based on the correspondence between the account of the electronic device 100 and the OpenID_1 after receiving the ticket purchase request.

[0624] In other embodiments, the scenic spot background 350 can also store the account of the electronic device 100 and the OpenID_1 based on the correspondence between the account of the electronic device 100 and the OpenID_1 after receiving the order response sent by the ticketing system 330, i.e., after step S2109 described below.

[0625] S2107. The scenic spot background 350 sends an order request to the ticketing system 330, the order request including the account of the electronic device 100, the ticket number of the ticket 1, and the project identifier 1.

[0626] In some embodiments, the order request is used to request the ticket system 330 to generate corresponding order information based on the order request, and bind the order information with the account of the electronic device 100.

[0627] Optionally, the order request further includes any one or more of the following: ticket type, validity period, ticket purchaser information, etc. The specific content of the ticket type, validity period, and ticket purchaser information can refer to the related description in the above step S2105.

[0628] S2108. The ticket system 330 generates order information 1 based on the order request, the order information 1 is bound with the account of the electronic device 100, and the order information 1 includes the identification of the electronic ticket 1, the number of tickets, the validity period, and optionally the verification status and the ticket purchase time.

[0629] In some embodiments, the ticket system 330 can generate order 1 bound with the account of the electronic device 100 based on the order request, and the order 1 carries the order information 1. The order information 1 includes the identification of the electronic ticket 1, the number of tickets, the validity period, and optionally the verification status and the ticket purchase time. Further optionally, the order information 1 can further include any one or more of the following: ticket type, validity period, ticket purchaser information, etc.

[0630] S2109. The ticket system 330 sends an order response to the scenic spot background 350, and the order response carries the order information 1.

[0631] S2110. The scenic spot background 350 sends a ticket purchase response to the electronic device 100, and the ticket purchase response carries the order information 1.

[0632] S2111. The meta-service 17 stores and displays the order information 1.

[0633] S2112. The meta-service 17 generates and stores an order token based on the order information 1.

[0634] Step S2112 is an optional step.

[0635] In some embodiments, after receiving the ticket purchase response, the meta-service 17 can generate an order token based on the order information 1 through a preset encryption algorithm. If the electronic device 100 is in an offline state in the subsequent ticket checking process, the electronic device 100 can send the order token to the gate 200 through NFC for verification. It should be noted that in this case, the electronic device 100 can also generate an order token based on the order information 1 and the preset encryption algorithm in the ticket checking process, and send the order token to the gate 200. The specific execution time of step S2112 is not limited in the present application. In addition, if the electronic device 100 is in an online state in the subsequent ticket checking process, the order token is not needed.

[0636] It can be understood that the ticket purchasing flow shown in FIG. 21 is only an example, and in some embodiments, the electronic device 100 can also purchase tickets in a manner different from the above-described embodiments, or in the ticket purchasing process, adopt different steps to interact with the server such as the scenic spot background 350 and the ticketing system 330 to complete ticket purchasing, which is not limited herein.

[0637] In this way, the purchase of the electronic ticket can be implemented, and the correspondence between the OpenID_1 and the account of the electronic device 100 is stored in the scenic spot background 350, facilitating fast verification in subsequent ticket checking.

[0638] FIG. 22A shows a flowchart of a ticket checking method according to an embodiment of the present application.

[0639] As shown in FIG. 22A, the specific flow of the ticket checking completed by the electronic device 100 through interaction with the gate machine 200 includes the following steps.

[0640] S2201. The gate machine 200 sends a probe frame.

[0641] S2202. The electronic device 100 sends a probe acknowledgement (Probe ACK) frame.

[0642] S2203. The gate machine 200 sends a notification (Notify) frame, and the Notify frame carries the device feature information of the gate machine 200.

[0643] S2204. The electronic device 100 sends a notification acknowledgement (Notify ACK) frame.

[0644] The specific content of steps S2201-S2204 can refer to the related description in steps S702-S706 shown in FIG. 7 described above, and will not be repeated here.

[0645] S2205. The gate machine 200 sends a parameter negotiation command.

[0646] In some embodiments, after receiving the Notify ACK frame, the gate machine 200 can send a parameter negotiation command to the electronic device 100 through NFC, and the parameter negotiation command is used to negotiate the transmission parameters of the application protocol layer with the electronic device 100.

[0647] In some embodiments, the frame type of the parameter negotiation command can be a command (Command) frame.

[0648] In some embodiments, the data transmission parameters can include any one or more of the maximum transmission rate and the maximum data transmission length when performing data transmission of the application protocol layer.

[0649] S2206. The electronic device 100 sends a parameter negotiation response.

[0650] In some embodiments, the electronic device 100 can send a parameter negotiation response to the gate machine 200 through NFC in response to the parameter negotiation command. The parameter negotiation response can be used to negotiate data transmission parameters at the application protocol layer with the payment device 200. The specific content of the data transmission parameters can refer to the related description of step S2205 above.

[0651] In some embodiments, the frame type of the parameter negotiation response can be a response (Response) frame.

[0652] It should be noted that after step S2205-step S2206, the gate machine 200 can interact with the application protocol layer of the electronic device 100. That is, in steps S2201-S2206, the gate machine 200 interacts with the NFC protocol stack 14 of the electronic device 100; in step S2207 and the following steps, the gate machine 200 interacts with the application protocol layer of the electronic device 100.

[0653] S2207. The gate machine 200 sends a ticket service selection request.

[0654] In some embodiments, after the transmission parameters at the application protocol layer are negotiated, the gate machine 200 can send a ticket service selection request to the electronic device 100 through NFC, and the ticket service selection request is used to request to select an electronic ticket service.

[0655] In one possible implementation, the ticket service selection request can be a Select ticket AID instruction.

[0656] For example, Table 3 shows the format of a Select ticket AID instruction provided by an embodiment of the present application.

[0657] Table 3

[0658] As shown in Table 3, an Application Protocol data unit (APDU) is a unit of information transmitted between a smart card and a smart card reader. An instruction generally has a specification definition, i.e., includes CLA, INS, P1, P2, Lc, Data, and Le in sequence. Among them, CLA is an instruction category, INS is an instruction code, P1 and P2 are parameters, Lc is the length of Data, and Le is the number of data bytes to be answered when a response is expected. In the embodiment shown in Table 3, the value of CLA of the Select Ticket AID instruction can be '00', the value of INS can be 'A4', the value of P1 can be '04', the value of P2 can be '00', the value of Lc can be '10', the value of Data can be the electronic ticket service AID, and the value of Le can be '00'. For example, if the electronic ticket service AID is "F0695441500601808080000000000004", the Select Ticket AID instruction can be "00A4 0400 10F0695441500601808080000000000004 00".

[0659] It can be understood that the embodiment shown in Table 3 is only an example. In the embodiments of the present application, the Select Ticket AID instruction can also have a format different from the embodiment described in Table 3, or include more, less, or different content than the above-described embodiment, which is not limited herein.

[0660] In a possible implementation, the ticket service selection request can also be used to indicate selection of an offline electronic ticket service or an online electronic ticket service. For example, the value of Data in the ticket service selection request can be the offline electronic ticket service AID and the online electronic ticket service AID, respectively. In some embodiments, the gate 200 can send one or more ticket service selection requests, for example, first sends an offline ticket service selection request 1, and determines whether to send an online ticket service selection request 2 again according to the offline ticket service selection request 1 replied by the electronic device 100. For example, the specific process of selecting an offline electronic ticket service or an online electronic ticket service by the gate 200 and the electronic device 100 through one or more rounds of ticket service selection requests and ticket service selection responses provided in the embodiments of the present application can refer to the related description in the embodiment shown in the following FIG. 22B. At this time, the step S2207 and the step S2208 can be replaced by the process shown in FIG. 22B.

[0661] S2208. The electronic device 100 sends a ticket service selection response.

[0662] In some embodiments, after receiving the ticket service selection request, the electronic device 100 can trigger to enable the electronic ticket service. After enabling the electronic ticket service, the electronic device 100 can send a ticket service selection response to the gate machine 200 through NFC, the ticket service selection response being used to indicate whether the electronic ticket service is successfully selected.

[0663] In a possible implementation, the ticket service selection response can be a Select Ticket AID Response.

[0664] For example, Table 4 shows the content structure of a data field of a Select Ticket AID Response provided by an embodiment of the present application.

[0665] Table 4

[0666] As shown in Table 4, the data field of the Select Ticket AID Response can include the following contents in the order: tag and content description. When the value of the tag is '6F', the length of the data field can be variable (Variable), the content description can be the message length and the FCI template, and the existence mode can be M (i.e. mandatory). When the value of the tag is '9F08', the length of the data field can be 0x02, the content description can be the application version number and 2 bytes, and the existence mode can be M (i.e. mandatory).

[0667] It can be understood that the embodiment shown in Table 4 is only an example, and in the embodiments of the present application, the data field of the Select Ticket AID Response can also adopt a format different from the embodiment described in Table 4, or include more, less or different contents than the above-described embodiment, which is not limited in the present application.

[0668] S2209. The gate machine 200 sends a ticket verification request.

[0669] In some embodiments, after receiving the Select Ticket AID Response, the gate machine 200 can send a ticket verification request to the electronic device 100 through NFC after determining that the electronic ticket service is successfully selected, the ticket verification request can carry the device ID of the gate machine 200 (hereinafter referred to as the ID of the gate machine 200), the project identifier 1 corresponding to the gate machine 200, the random number r generated by the gate machine 200, etc.

[0670] For example, Table 5 shows a format of a ticket verification request provided by an embodiment of the present application.

[0671] Table 5

[0672] As shown in Table 5, the value of CLA of the ticket verification request can be '80', the value of INS can be 'CA', the value of P1 can be 'C0', the value of P2 can be '00', the value of Lc can be variable, the Data can adopt the TLV data structure, and the value of Le can be '00'.

[0673] It can be understood that the embodiment shown in Table 5 is only an example, and in the embodiments of the present application, the ticket verification request can also adopt a format different from the embodiment described in Table 5, or include more, less or different content than the above-described embodiment, which is not limited herein.

[0674] Exemplarily, Table 6 shows the data field content of Data in a ticket verification request provided by an embodiment of the present application.

[0675] Table 6

[0676] As shown in Table 6, the data field of Data in the ticket verification request can include a tag and a content description. When the value of the tag is '9F11', the length of the data field can be 12, the content description can be a gate device ID, including OUI (3) + GID (6) + PID (3), and the existence mode can be M (i.e., mandatory). When the value of the tag is '9F12', the length of the data field can be 4, the content description can be a random number, and the existence mode can be M (i.e., mandatory).

[0677] It can be understood that the embodiment shown in Table 6 is only an example, and in the embodiments of the present application, the data field of Data in the ticket verification request can also adopt a format different from the embodiment described in Table 6, or include more, less or different content than the above-described embodiment, which is not limited herein.

[0678] S2210. The electronic device 100 sends a ticket verification response.

[0679] In the embodiments of the present application, after receiving the ticket verification request, the electronic device 100 can send a ticket verification response to the gate 200 through NFC. The ticket verification response can include a random number r and the ID of the gate 200. It should be noted that the ticket verification response can include the random number r and the ID of the gate 200, and specifically can include any one of the following forms: in one possible implementation, the ticket verification response can carry the hash value of both the random number r and the ID of the gate 200, and the random number r; in another possible implementation, the ticket verification response can carry the hash value of the ID of the gate 200 and the random number r; in another possible implementation, the ticket verification response can carry the ID of the gate 200 and the random number r, which is not limited herein.

[0680] In some embodiments, the ticket verification response can also be used to indicate whether the electronic device 100 selects an online electronic ticket service or an offline electronic ticket service. In the case of selecting an online electronic ticket service, the electronic device 100 can directly communicate with a server such as the scenic spot background 350 through wireless communication (such as cellular network, wireless local area network, etc.), and in the case of selecting an offline electronic ticket service, the electronic device 100 can communicate with the gate 200 through NFC, and cannot directly communicate with the server such as the scenic spot background 350 through wireless communication.

[0681] In a possible implementation, when the electronic ticket service selected by the electronic device 100 is different, the content carried by the ticket verification response is different.

[0682] The data field content of Data in the case of online electronic ticket service and the data field content of Data in the case of offline electronic ticket service will be introduced respectively below.

[0683] For example, Table 7 shows the data field content of Data in the ticket verification response in the case of online electronic ticket service selected by the electronic device 100 according to an embodiment of the present application.

[0684] Table 7

[0685] As shown in Table 7, the data field of Data in the ticket verification response can include a tag and a content description. When the value of the tag is '6F', the length of the data field can be variable (Variable). When the value of the tag is '9F13', the length of the data field can be 1, and the content description can be a cancellation type identifier (used to indicate an online state or an offline state), wherein 0x02 represents online cancellation, and the existence mode can be M (i.e. mandatory); when the value of the tag is '9F14', the length of the data field can be 4, and the content description can be a random number, and the existence mode can be M (i.e. mandatory); when the value of the tag is '9F15', the length of the data field can be 1, and the content description can be the number of valid credentials, and the existence mode can be O (i.e. optional); when the value of the tag is '9F18', the length of the data field can be 32, and the content description can be a hash value of the gate device ID and the random number, and the existence mode can be M (i.e. mandatory).

[0686] It can be understood that the embodiment shown in Table 7 is only an example, and in the embodiments of the present application, the data field of Data in the ticket verification response can also adopt a format different from the embodiment described in Table 7, or include more, less or different content than the above-described embodiment, which is not limited herein.

[0687] It should be noted that when the electronic device 100 selects the online electronic ticket service, the electronic device 100 can interact with the gate 200, the scenic spot background 350, and the like to complete ticket checking. The specific interaction process can refer to the related description in the embodiments shown in FIG. 23 or FIG. 26.

[0688] For example, Table 8 shows the data field content of Data in the ticket checking response when the electronic device 100 selects the online electronic ticket service.

[0689] Table 8

[0690] As shown in Table 8, the data field of Data in the ticket checking response can include a tag and a content description. When the value of the tag is ‘6F’, the length of the data field can be variable (Variable). When the value of the tag is ‘9F13’, the length of the data field can be 1, and the content description can be a cancellation type identifier (used to indicate an online state or an offline state), where 0x01 represents offline cancellation, and the existence mode can be M (i.e., mandatory). When the value of the tag is ‘9F14’, the length of the data field can be 4, and the content description can be a random number, and the existence mode can be M (i.e., mandatory). When the value of the tag is ‘9F15’, the length of the data field can be 1, and the content description can be the number of valid vouchers, and the existence mode can be M (i.e., mandatory). When the value of the tag is ‘9F16’, the length of the data field can be 8, and the content description can be a token voucher index, which can be used to determine an order token (i.e., the order token in the embodiment shown in FIG. 21), and the existence mode can be M (i.e., mandatory). When the value of the tag is ‘9F17’, the length of the data field can be 16, and the content description can be a check value (i.e., Mac0), and the existence mode can be M (i.e., mandatory). When the value of the tag is ‘9F18’, the length of the data field can be 32, and the content description can be a hash value of the gate device ID and the random number, and the existence mode can be O (i.e., optional). It should be noted that in some embodiments, the token voucher index can be generated by a preset voucher generation algorithm (such as a hash algorithm, etc.) from the order token.

[0691] It can be understood that the embodiment shown in Table 8 is only an example. In the embodiments of the present application, the data field of Data in the ticket checking response can also use a format different from the embodiment described in Table 8, or include more, less, or different content than the above-described embodiment, which is not limited in the present application.

[0692] It should be noted that in the case that the electronic device 100 selects the offline electronic ticket service, the electronic device 100 cannot directly interact with the scenic spot background 350 through wireless communication, and can only communicate with the gate machine 200 through the NFC mode. In this case, the electronic device 100 can obtain a check value (i.e., Mac0) based on the random number r sent by the gate machine 200 through a preset check algorithm, and the check value can be used to check the two devices. Then, the electronic device 100 can send a verification response carrying the device ID and the hash value of the random number r of the gate machine 200, the token certificate index (the token certificate index is generated based on the order token), the check value (i.e., Mac0), and the like to the gate machine 200. After receiving the verification response, the gate machine 200 can send the random number r, the token certificate index, and the check value and the like to the scenic spot background 350 for verification. After completing the verification of the check value through the preset check algorithm, the scenic spot background 350 can obtain the order information 1 from the token certificate index through a preset decryption algorithm, and then determine whether to instruct the gate machine 200 to open the gate based on the order information 1. For example, in the case of selecting the offline electronic ticket service, the specific process of the electronic device 100 interacting with the gate machine 200 to complete the ticket checking can refer to the related description in the embodiment shown in the following FIG. 28, which will not be described here in detail.

[0693] S2211. The gate machine 200 sends a result notification.

[0694] In some embodiments, the gate machine 200 can send a result notification to the electronic device 100 through the NFC based on the verification results of the scenic spot background 350 and the ticket system 330. The result notification carries information such as a ticket checking result code, and the ticket checking result code is used to indicate whether the ticket checking is successful.

[0695] Optionally, the result notification can also carry any one or more of the following: the ID of the gate machine 200, the ticket type, the ticket quantity, and the like.

[0696] For example, Table 8 shows a format of a result notification provided by an embodiment of the present application.

[0697] Table 9

[0698] As shown in Table 9, the value of CLA of the ticket checking request can be ‘80’, the value of INS can be ‘CA’, the value of P1 can be ‘C0’, the value of P2 can be ‘10’, the value of Lc can be variable (Variable), the Data can adopt a TLV data structure, and the value of Le can be ‘00’.

[0699] It can be understood that the embodiment shown in Table 9 is only an example, and in the embodiments of the present application, the result notification can also adopt a format different from the embodiment described in Table 9, or include more, less or different content than the above-described embodiment, which is not limited herein.

[0700] For another example, Table 10 shows the data field content of Data in a result notification provided by an embodiment of the present application.

[0701] Table 10

[0702] As shown in Table 10, the data field of Data in the result notification can include a tag and a content description. When the value of the tag is '9F19', the length of the data field can be 1, and the content description can be a ticket checking result code. In the embodiments of the present application, the ticket checking result code can include the following three cases: 0x01, all ticket checking is successful; 0x02, part of the ticket checking is successful; and 0x0F, all ticket checking fails. The presence mode of the ticket checking result code can be M (i.e., mandatory).

[0703] When the value of the tag is '9F1A', the length of the data field can be 1, and the content description can be a ticket type of ticket checking. The presence mode can be M (i.e., mandatory). In the embodiments of the present application, the ticket type can include but is not limited to any one or more of the following cases: 0x01, adult ticket; 0x02, child ticket; 0x03, adult & child ticket; 0x04, student ticket; 0x05, adult & student ticket; 0x06, student & child ticket; 0x07, adult & child & student ticket; 0x08, preferential group ticket; 0x09, adult & preferential group ticket; 0x0A, preferential group & child ticket; 0x0B, adult & child & preferential group ticket; 0x0C, student & preferential group ticket; 0x0D, adult & student & preferential group ticket; 0x0E, student & child & preferential group ticket; 0x0F, adult & child & student & preferential group ticket; and 0x10, other ticket.

[0704] When the value of the tag is '9F1B', the length of the data field can be 2, the first byte of the content description is the number of tickets successfully checked, and the second byte is the number of tickets failed to be checked. The presence mode can be O (i.e., optional).

[0705] When the value of the tag is '9F1C', the length of the data field can be 1, the content description can be a failure reason, and the presence mode can be O (i.e., optional). It can be understood that when all ticket checking is successful, the failure reason does not need to be sent. Common failure reasons can include the following cases: parameter exception 0x01, ticket has been used 0x02, and other 0x03.

[0706] It can be understood that the embodiment shown in Table 10 is only an example, and in the embodiments of the present application, the data field of Data in the result notification can also adopt a format different from the embodiment described in Table 10, or include more, less or different content than the above embodiment, which is not limited herein.

[0707] S2212. The electronic device 100 sends a notification response.

[0708] In some embodiments, the electronic device 100 can send a notification response to the gate machine 200 through NFC, the notification response being used to indicate whether the electronic device 100 receives the result notification.

[0709] For example, Table 10 shows the data field content of Data in the notification response provided by the embodiments of the present application.

[0710] Table 11

[0711] As shown in Table 11, the data field of Data in the notification response can include a tag and a content description. Wherein, when the value of the tag is '6F', the length of the data field is variable (Variable), and the content description can be an application data element. When the value of the tag is '9F1D', the length of the data field can be 1, and the content description can be used to indicate whether the result notification is received, for example, 0x01: the result notification is received, 0x0: the result notification is not received.

[0712] It can be understood that the embodiment shown in Table 11 is only an example, and in the embodiments of the present application, the data field of Data in the notification response can also adopt a format different from the embodiment described in Table 11, or include more, less or different content than the above embodiment, which is not limited herein.

[0713] In this way, the electronic ticket can be quickly and efficiently checked, the user's operation in the ticket checking process can be simplified, and the ticket checking efficiency can be improved.

[0714] For example, Figure 22B shows a flowchart of selecting offline electronic ticket service or online electronic ticket service by one or more rounds of ticket service selection request and ticket service selection response between the gate machine 200 and the electronic device 100 according to an embodiment of the present application.

[0715] As shown in Figure 22B, the specific process of selecting offline electronic ticket service or online electronic ticket service by one or more rounds of ticket service selection request and ticket service selection response between the gate machine 200 and the electronic device 100 can include the following steps:

[0716] S2207a. The gate machine 200 sends an offline ticket service selection request 1.

[0717] In the embodiment of the present application, the offline ticket service selection request 1 (also referred to as the second ticket service selection request) can be used to request the electronic device 100 to select an offline electronic ticket service.

[0718] In some embodiments, the format of the offline ticket service selection request 1 can be analogously described with reference to the related description in the embodiment shown in Table 3 described above. It should be noted that in the offline ticket service selection request 1, the value of Data is the offline electronic ticket service AID.

[0719] S2208a. The electronic device 100 sends an offline ticket service selection response 1.

[0720] In the embodiment of the present application, after receiving the offline ticket service selection request 1, the electronic device 100 can send an offline ticket service selection response 1 (also referred to as the second ticket service selection response) to the gate 200, which is used to indicate whether the offline electronic ticket service is successfully selected.

[0721] In some embodiments, the electronic device 100 can judge whether the offline electronic ticket service can be successfully selected based on one or more factors, which include but are not limited to any one or more of the following: whether the electronic device 100 supports the offline electronic ticket service, the state of the electronic device 100 (i.e. online state or offline state), whether the electronic device 100 stores an order token, etc.

[0722] For example, in the case that the electronic device 100 does not support the offline electronic ticket service, the electronic device 100 cannot successfully select the offline electronic ticket service, and at this time, the offline ticket service selection response 1 is used to indicate that the selection of the offline electronic ticket service fails. For another example, in the case that the electronic device 100 supports the offline electronic ticket service and the electronic device 100 stores an order token, the electronic device 100 can successfully select the offline electronic ticket service, and at this time, the offline ticket service selection response 1 is used to indicate that the selection of the offline electronic ticket service succeeds, etc.

[0723] It can be understood that the above embodiments are only some examples, and in the embodiments of the present application, the factors for judging whether the offline electronic ticket service can be successfully selected can also include more, fewer or different factors than the above embodiments, which are not limited herein.

[0724] S2207b. The gate 200 sends an online ticket service selection request 2 based on the offline ticket service selection response 1.

[0725] Steps S2207b-S2208b are optional steps.

[0726] In the embodiment of the present application, the gate machine 200 can determine whether to perform step S2207b based on the offline ticket service response 1.

[0727] After receiving the offline ticket service selection response 1, the gate machine 200 can determine whether the offline electronic ticket service is successfully selected based on the offline ticket service selection response 1. In the case that the offline electronic ticket service is successfully selected, the gate machine 200 does not need to perform step S2207b. In the case that the offline electronic ticket service is unsuccessfully selected, the gate machine 200 can perform step S2207b.

[0728] The online ticket service selection request 2 (also referred to as the first ticket service selection request) can be used to request the electronic device 100 to select an online electronic ticket service.

[0729] In some embodiments, the format of the online ticket service selection request 2 can be analogously described with reference to the related description in the embodiment shown in Table 3. It should be noted that in the online ticket service selection request 2, the value of Data is the online electronic ticket service AID.

[0730] S2208b. The electronic device 100 sends an online ticket service selection response 2.

[0731] In the embodiment of the present application, after receiving the online ticket service selection request 2, the electronic device 100 can send an online ticket service selection response 2 (also referred to as the first ticket service selection response) to the gate machine 200, the online ticket service selection response 2 being used to indicate whether the online electronic ticket service is successfully selected.

[0732] In some embodiments, the electronic device 100 can determine whether the online electronic ticket service can be successfully selected based on one or more factors, which include but are not limited to any one or more of the following: whether the electronic device 100 supports the online electronic ticket service, the state of the electronic device 100 (i.e. online state or offline state), etc.

[0733] For example, in the case that the electronic device 100 does not support the online electronic ticket service, the electronic device 100 cannot successfully select the online electronic ticket service, and in this case, the online ticket service selection response 2 is used to indicate that the online electronic ticket service is unsuccessfully selected. For another example, in the case that the electronic device 100 supports the online electronic ticket service and the electronic device 100 is in the offline state, the electronic device 100 cannot successfully select the online electronic ticket service, and in this case, the online ticket service selection response 2 is used to indicate that the online electronic ticket service is unsuccessfully selected. For another example, in the case that the electronic device 100 supports the online electronic ticket service and the electronic device 100 is in the online state, the electronic device 100 can successfully select the online electronic ticket service, and in this case, the online ticket service selection response 2 is used to indicate that the online electronic ticket service is successfully selected, etc.

[0734] It can be understood that the above embodiments are only some examples, in the embodiments of the present application, factors for judging whether the online electronic ticket service can be successfully selected can also include more, less or different factors from the above embodiments, which are not limited herein.

[0735] In this way, the gate machine 200 can select the offline electronic ticket service or the online electronic ticket service through one or more rounds of interaction with the electronic device 100, so as to facilitate subsequent different ticket checking processes. By using the scheme shown in FIG. 22B, the offline electronic ticket service can be preferentially selected, the interaction of the electronic device 100 can be reduced, the ticket checking lag caused by poor network of the electronic device 100 can be avoided, and better experience can be provided for the user.

[0736] It can be understood that the embodiment shown in FIG. 22B is only an example, in the embodiments of the present application, the gate machine 200 can also interact with the electronic device 100 in a manner different from the above-mentioned embodiment shown in FIG. 22B to determine to select the online electronic ticket service or the offline electronic ticket service, or the gate machine 200 can first send the online ticket service selection request and then send the offline ticket service selection request, which is not limited herein.

[0737] FIG. 23 shows a flowchart of a ticket checking method according to an embodiment of the present application.

[0738] As shown in FIG. 23, the electronic device 100 can include the meta service 17, the scene linkage 16 and the NFC protocol stack 14, in the ticket checking process, the electronic device 100 is in the PICC mode, and the interaction process between the electronic device 100 and the gate machine 200, the server such as the scenic area background 350 can include the following steps.

[0739] S2301. The electronic device 100 enters the radio frequency field of the gate machine 200.

[0740] S2302. The NFC protocol stack 14 negotiates transmission parameters with the gate machine 200.

[0741] The specific content of step S2302 can refer to the specific content in steps S2201-S2206 shown in FIG. 22A, which will not be repeated here.

[0742] It should be noted that after the transmission parameters of the application protocol layer are negotiated, the electronic device 100 can complete the selection of the electronic ticket service through steps S2207-S2208 shown in FIG. 22A.

[0743] S2303. The gate machine 200 generates a random number r.

[0744] In some embodiments, the gate machine 200 can generate the random number r when detecting that the electronic device 100 enters the radio frequency field of the gate machine 200.

[0745] In some other embodiments, the gate machine 200 can also generate the random number r during the execution of step S2302, or after the execution of step S2302, which is not limited herein.

[0746] S2304. The gate machine 200 sends a ticket verification request to the scene linkage 16 through the NFC protocol stack 14, the ticket verification request carrying the ID of the gate machine 200 and the random number r, and optionally carrying the project identifier 1.

[0747] In a possible implementation, the ticket verification request can carry the ID of the gate machine 200 and the random number r (also referred to as the third random number), wherein the electronic device 100 can obtain the project identifier 1 (also referred to as the first project identifier) based on the mapping relationship between the ID of the gate machine 200 and the project identifier after receiving the ticket verification request. For example, as shown in Table 6, the ID of the gate machine 200 can include OUI (3) + GID (6) + PID (3), and the electronic device 100 can determine the manufacturer (for example, the scenic area A, etc.) of the gate machine 200 providing the NFC service based on the OUI, and then determine the project identifier 1. For another example, the electronic device 100 can determine the group (for example, the scenic area A, etc.) to which the NFC service provided by the gate machine 200 belongs based on the GID, and then determine the project identifier 1. Specifically, the specific content of the OUI, the GID and the PID can refer to the related content in the above-mentioned embodiment shown in FIG. 7, which will not be described here again.

[0748] In another possible implementation, the ticket verification request can carry the ID of the gate machine 200 and the random number r, and in addition, the ticket verification request can also carry the project identifier 1.

[0749] In some embodiments, the ID of the gate machine 200 can be used to identify the gate machine 200, the project identifier 1 can be used to indicate the project (for example, the scenic area A, etc.) to which the electronic ticket verified by the gate machine 200 corresponds, and the random number r can be used for identity verification in the subsequent interaction process.

[0750] S2305. The scene linkage 16 determines to call the meta-service 17 based on the ID of the gate machine 200 and / or the project identifier 1.

[0751] In some embodiments, the scene linkage 16 can determine to call the meta-service 17 corresponding to the project identifier 1 (or the ID of the gate machine 200) based on the ID of the gate machine 200 and / or the project identifier 1.

[0752] S2306. The scene linkage 16 sends a credential request to the meta-service 17, the credential request carrying the project identifier 1.

[0753] In some embodiments, the scene linkage 16 sends a credential request to the meta-service 17, the credential request carrying the project identifier 1, and the credential request can be used to request the meta-service 17 to query the opening gate identifier corresponding to the project identifier 1.

[0754] S2307. The meta-service 17 determines the opening gate identifier 1 (OpenID_1) corresponding to the project identifier 1 based on the project identifier 1.

[0755] In some embodiments, after receiving the credential request, the meta-service 17 can interact with the account cloud 320 to obtain the account of the electronic device 100 and the OpenID_1 corresponding to the project identifier 1. For example, the specific process in which the meta-service 17 interacts with the account cloud 320 to obtain the OpenID_1 can refer to the related description in the embodiment shown in FIG. 24 below, which will not be described here in detail.

[0756] S2308. The meta-service 17 sends verification information to the scenic area background 350, and the verification information includes the OpenID_1 corresponding to the project identifier 1 and the ID of the gate 200.

[0757] In the case where it is determined that there is an OpenID corresponding to the project identifier 1, the meta-service 17 sends verification information to the scenic area background 350. In some embodiments, the verification information includes the OpenID_1 corresponding to the project identifier 1 and the ID of the gate 200.

[0758] It should be noted that the execution order of step S2308 is after step S2307 and before step S2314, that is, step S2308 can be executed synchronously with step S2309, or can be executed before step S2309, or can be executed in the execution process of step S2309-step S2313, or can be executed after step S2313, which is not limited in the present application.

[0759] S2309. The meta-service 17 sends a credential response to the scene linkage 16, and the credential response is used to indicate that the OpenID corresponding to the project identifier 1 is queried.

[0760] In the case where it is determined that there is an OpenID corresponding to the project identifier 1, the meta-service 17 sends a credential response to the scene linkage 16, and at this time, the credential response is used to indicate that the OpenID corresponding to the project identifier 1 is queried.

[0761] In other embodiments, in the case where it is determined that there is no OpenID corresponding to the project identifier 1, the meta-service 17 can also send a credential response to the scene linkage 16, and at this time, the credential response is used to indicate that the OpenID corresponding to the project identifier 1 is not queried.

[0762] S2310. The scenario linkage 16 sends a ticket verification response to the gate 200 through the NFC protocol stack 14, and the ticket verification response carries the ID and the random number r of the gate 200.

[0763] In some embodiments, after determining that there is the OpenID corresponding to the project ID 1, the scenario linkage 16 can send a ticket verification response to the gate 200, and the ticket verification response carries the ID and the random number r of the gate 200.

[0764] In a possible implementation, the ticket verification response carrying the ID and the random number r of the gate 200 can be a hash value carrying both the random number r and the ID of the gate 200, and the random number r.

[0765] In a possible implementation, the ticket verification response carrying the ID and the random number r of the gate 200 can also be a hash value carrying the ID of the gate 200, and the random number r.

[0766] In a possible implementation, the ticket verification response carrying the ID and the random number r of the gate 200 can also be carrying the ID of the gate 200, and the random number r.

[0767] It can be understood that the above embodiments are only three examples, and in the embodiments of the present application, the ticket verification response can also carry the ID and the random number r of the gate 200 in a manner different from the above embodiments, which is not limited herein.

[0768] S2311. The gate 200 determines whether the local device has the random number r carried in the ticket verification response.

[0769] In some embodiments, the gate 200 can determine whether the peer device has changed in the execution process of steps S2303-S2311 by determining whether the local device has the random number r carried in the ticket verification response.

[0770] If the local device has the random number r carried in the ticket verification response, it indicates that the peer device has not changed, and at this time, the gate 200 can execute the following step S2312 and subsequent steps.

[0771] If the local device does not have the random number r carried in the ticket verification response, it indicates that the peer device has changed, and at this time, the gate 200 can execute the following step S2320.

[0772] S2312. The gate 200 deletes the random number r.

[0773] After determining the random number r carried in the local ticket verification response, the gate 200 can perform step S2312 and step S2313. The gate 200 can perform step S2312 and step S2313 synchronously, perform step S2312 first and then perform step S2313, or perform step S2313 first and then perform step S2312, which is not limited in the present application.

[0774] S2313. The gate 200 sends a verification request to the scenic spot background 350, and the verification request carries the ID of the gate 200.

[0775] After determining the random number r carried in the local ticket verification response, the gate 200 can send a verification request to the scenic spot background 350, and the verification request carries the ID of the gate 200. The verification request can be used to request the scenic spot background 350 to verify whether the OpenID_1 corresponding to the ID of the gate 200 is valid.

[0776] S2314. The scenic spot background 350 judges whether the OpenID_1 is valid.

[0777] In some embodiments, the scenic spot background 350 can judge whether the OpenID_1 is valid immediately after receiving the verification information generated by the electronic device 100.

[0778] In other embodiments, the scenic spot background 350 can judge whether the OpenID_1 is valid after receiving the verification information generated by the electronic device 100 and receiving the verification request sent by the gate 200.

[0779] The scenic spot background 350 can judge the validity of the OpenID_1 based on the interaction with the ticketing system 330. For example, the specific process of the scenic spot background 350 judging the validity of the OpenID_1 can refer to the content in the embodiment shown in FIG. 25, which is not described here in detail.

[0780] If it is determined that the OpenID_1 is valid, the scenic spot background 350 can perform the following step S2315.

[0781] If it is determined that the OpenID_1 is invalid, the scenic spot background 350 can perform the following step S2320.

[0782] S2315. The scenic spot background 350 sends a verification response 1 to the gate 200, and the verification response 1 carries the gate opening times and the ticket verification result code.

[0783] In the embodiments of the present application, the ticket checking result code is used to indicate the ticket checking result. In the embodiments of the present application, the ticket checking result can include that the ticket checking is totally successful, the ticket checking is partially successful, and the ticket checking is totally failed. For example, the ticket checking result code corresponding to each of the above ticket checking results can be 0x01: the ticket checking is totally successful; 0x02: the ticket checking is partially successful; and 0x0F: the ticket checking is totally failed. In the embodiments of the present application, the ticket checking result corresponding to the ticket checking result code carried in the verification response 1 can be that the ticket checking is totally successful or the ticket checking is partially successful. Optionally, in the case that the ticket checking is partially successful, the verification response 1 can further carry the ticket checking failure reason.

[0784] In the embodiments of the present application, the OpenID_1 can correspond to one order information, and the order information can include one or more electronic tickets.

[0785] In some embodiments, in the case that the OpenID_1 corresponds to multiple electronic tickets, the verification response 1 can verify one or more electronic tickets, and determine the number of times of opening the gate based on the number of electronic tickets verified this time. For example, if one electronic ticket is verified this time, the number of times of opening the gate is 1; if N electronic tickets are verified this time, the number of times of opening the gate is N (N is an integer greater than 1).

[0786] It should be noted that, in the embodiments shown in FIG. 23, in the case that the OpenID_1 corresponds to a single electronic ticket, the single electronic ticket is verified by default; in the case that the OpenID_1 corresponds to multiple electronic tickets, the number of electronic tickets verified can be determined by the scenic spot background 350 based on a preset number of tickets to be verified (for example, 1 ticket, N tickets (N is an integer greater than 1), or M tickets (M is the number of all electronic tickets corresponding to the OpenID_1)).

[0787] In another possible implementation, the number of electronic tickets to be verified can be determined by the user. The user can select the electronic ticket to be verified in the electronic device 100, and send the identifier of the electronic ticket to be verified to the scenic spot background 350 for verification. The specific ticket checking process can refer to the related description in the embodiments shown in FIG. 26 below, which will not be described here in detail.

[0788] S2316. The gate 200 opens the gate based on the verification response 1.

[0789] In the embodiments of the present application, the gate 200 can open the gate based on the number of times of opening the gate in the verification response 1.

[0790] In some embodiments, if the number of times of opening the gate is greater than 1, the gate 200 can open the gate for multiple times in succession, and one person is released at a time, or the gate 200 can open the gate once, and the same number of people as the number of times of opening the gate are released in succession.

[0791] S2317. The gate machine 200 sends a result notification 1 to the meta-service 17, the result notification 1 carrying the ticket verification result code and the ID of the gate machine 200.

[0792] After receiving the verification response 1, the gate machine 200 can perform step S2317.

[0793] It should be noted that step S2317 and step S2316 can be executed synchronously, or step S2316 can be executed first and then step S2317, or step S2317 can be executed first and then step S2316, which is not limited in the present application.

[0794] S2318. The meta-service 17 outputs a ticket verification success notification.

[0795] After receiving the result notification 1, the meta-service 17 can output a ticket verification success notification, which is used to indicate that the ticket verification is successful (including that the ticket verification is completely successful and that the ticket verification is partially successful).

[0796] The meta-service 17 can output the ticket verification success notification in any one or more of the following manners: display on a display screen, voice broadcast, vibration, and flashing of an indicator light.

[0797] S2319. The scenic spot background 350 sends a verification response 2 to the gate machine 200, the verification response 2 being used to indicate that the gate is not to be opened.

[0798] In the case that the OpenID_1 is invalid, the scenic spot background 350 sends a verification response 2 to the gate machine 200, the verification response 2 being used to indicate that the gate is not to be opened. In some embodiments, the verification response 2 can also carry a ticket verification result code, and the ticket verification result corresponding to the ticket verification result code can be that the ticket verification is completely failed. Optionally, the verification response 2 can also carry a ticket verification failure reason.

[0799] S2320. The gate machine 200 sends a result notification 2 to the meta-service 17, the result notification 2 being used to indicate that the ticket verification is failed.

[0800] In some embodiments, after receiving the verification response 2, the gate machine 200 can perform step S2321.

[0801] In another embodiment, in the case that the gate machine 200 determines that the random number r carried in the ticket verification response does not exist locally, i.e., the peer device is changed, step S2320 can be performed.

[0802] S2321. The meta-service 17 outputs a ticket verification failure notification.

[0803] After receiving the result notification 2, the meta-service 17 can output a ticket verification failure notification, which is used to indicate that the ticket verification is failed.

[0804] The meta-service 17 can output the ticket verification failure notification in any one or more of the following manners: display on a display screen, voice broadcast, vibration, and indicator light flashing.

[0805] In this way, the electronic ticket can be quickly and efficiently checked, the operation of the user in the ticket checking process is simplified, and the ticket checking efficiency is improved.

[0806] FIG. 24 shows a flowchart of a process in which the meta-service 17 interacts with the account cloud 320 to obtain the gate opening identifier corresponding to the project identifier 1.

[0807] As shown in FIG. 24, the electronic device 100 can include the meta-service 17, which can obtain the gate opening identifier corresponding to the project identifier 1 by interacting with the account cloud 320. The specific process in which the meta-service 17 obtains the gate opening identifier corresponding to the project identifier 1 can include the following steps:

[0808] S2401. The meta-service 17 sends a request 1 to the account cloud 320, and the request 1 carries the project identifier 1 and the account of the electronic device 100.

[0809] S2402. The account cloud 320 generates OpenID_1 based on the account of the electronic device 100 and the project identifier 1.

[0810] S2403. The account cloud 320 sends a response to the meta-service 17, and the response carries the OpenID_1 corresponding to the project identifier 1.

[0811] S2404. The meta-service 17 determines the OpenID_1 corresponding to the project identifier 1.

[0812] It can be understood that the embodiment shown in FIG. 24 is only an example. In the embodiments of the present application, the meta-service 17 can also determine whether the gate opening identifier corresponding to the project identifier 1 exists in a manner different from the above-described embodiments, which is not limited herein.

[0813] In this way, the meta-service 17 can obtain the specified gate opening identifier by interacting with the account cloud 320. The gate opening identifier does not need to be stored locally, which reduces the memory pressure of the electronic device 100 and facilitates the obtaining of the gate opening identifier for ticket checking in the non-device ticket purchase scenario.

[0814] FIG. 25 shows a flowchart of a process in which the scenic area background 350 determines whether the gate opening identifier is valid.

[0815] As shown in FIG. 25, the specific process in which the scenic area background 350 determines whether the OpenID_1 is valid can include the following steps:

[0816] S2501. The scenic spot background 350 determines the account of the electronic device 100 corresponding to the OpenID_1 based on the correspondence between the OpenID and the account of the electronic device.

[0817] In the embodiment of the present application, the scenic spot background 350 can store the correspondence between the OpenID and the account of the electronic device.

[0818] After the scenic spot background 350 receives the verification information sent by the electronic device 100, the scenic spot background 350 can determine the account of the electronic device 100 corresponding to the OpenID_1 based on the correspondence between the OpenID and the account of the electronic device.

[0819] It should be noted that the execution order of steps S2501-S2505 can be after receiving the verification information sent by the electronic device 100, or after receiving the verification request sent by the gate machine 200, which is not limited in the present application.

[0820] S2502. The scenic spot background 350 sends a query request to the ticket system 330, and the query request carries the account of the electronic device 100.

[0821] In the embodiment, the query request can be used to request the ticket system 330 to query the order information corresponding to the account of the electronic device 100.

[0822] S2503. The ticket system 330 determines the order information 1 based on the account of the electronic device 100.

[0823] In the embodiment, the ticket system 330 can store the correspondence between the account of the electronic device and the order, and each order can include order information.

[0824] After receiving the query request, the ticket system 330 can determine the order 1 corresponding to the account of the electronic device 100 based on the correspondence between the account of the electronic device and the order, and obtain the order information 1 of the order 1.

[0825] In some embodiments, the order information 1 can include the number, type, verification status and validity period of the electronic ticket, and optionally, the order information 1 can also include any one or more of the following: ticket purchase time, ticket purchaser information of each electronic ticket, etc.

[0826] S2504. The ticket system 330 sends a query response to the scenic spot background 350, and the query response carries the order information 1.

[0827] S2505. The scenic spot background 350 determines the ticket checking result code and the number of gate opening times based on the order information 1.

[0828] After receiving the query response, the scenic spot background 350 can determine the ticket checking result code and the number of times of opening the gate based on the order information 1. The specific content of the ticket checking result code and the number of times of opening the gate can refer to the related description in the embodiment shown in FIG. 23, and will not be described here.

[0829] The scenic spot background 350 can determine the number of electronic tickets in the order 1 that are within the valid period and have not been checked in. Then, in a possible implementation manner, the scenic spot background 350 can determine the number of times of opening the gate based on the maximum number of times of opening the gate threshold preset by the scenic spot background and the number of electronic tickets in the order 1 that are within the valid period and have not been checked in. For example, if the number of electronic tickets in the order 1 that are within the valid period and have not been checked in is 3, and the maximum number of times of opening the gate threshold preset by the scenic spot background is 5, the number of times of opening the gate can be 3. For another example, if the number of electronic tickets in the order 1 that are within the valid period and have not been checked in is 5, and the maximum number of times of opening the gate threshold preset by the scenic spot background is 1, the number of times of opening the gate can be 1.

[0830] In another possible implementation manner, the checking information can also carry the identification of the electronic ticket to be checked specified by the user. The scenic spot background 350 can determine whether the electronic tickets specified by the user in the order information 1 are all within the valid period and have not been checked in based on the identification of the electronic ticket to be checked and the order information 1. If the electronic tickets specified by the user are all within the valid period and have not been checked in, the ticket checking result code can be that the ticket checking is all successful, and the number of times of opening the gate can be the number of electronic tickets indicated by the identification of the electronic ticket to be checked. If only part of the electronic tickets specified by the user are within the valid period and have not been checked in, the ticket checking result code can be that the ticket checking is partially successful, and the number of times of opening the gate can be the number of electronic tickets within the valid period and have not been checked in. If none of the electronic tickets specified by the user is within the valid period and has not been checked in, the ticket checking result code can be that the ticket checking is all failed, and the number of times of opening the gate can be 0.

[0831] S2506. The scenic spot background 350 determines that the gate machine receiving the checking response is the gate machine 200 based on the device ID of the gate machine 200 in the checking information.

[0832] After determining the ticket checking result code and the number of times of opening the gate, and receiving the checking request sent by the gate machine 200, the scenic spot background 350 can determine the gate machine receiving the checking response based on the OpenID_1. Specifically, the scenic spot background 350 can determine that the gate machine corresponding to the number of times of opening the gate indicated by the validity verification result of the OpenID_1 is the gate machine 200 based on the checking information carrying the OpenID_1 and the ID of the gate machine 200 at the same time.

[0833] S2507. The scenic area background 350 sends an order update request to the ticketing system 330, and the order update request carries the ticket identification of the current verification and the account of the electronic device 100.

[0834] Step S2507 can be performed after step S2505, and the application does not limit the specific execution order of step S2506 and step S2507.

[0835] In this embodiment, the order update request can be used to request to update the order information 1.

[0836] S2508. The ticketing system 330 updates the order information 1 based on the order update request.

[0837] The ticketing system 330 can determine the order information 1 based on the account of the electronic device 100, and update the order information 1 based on the ticket identification of the current verification, that is, change the verification state of the ticket of the current verification to verified.

[0838] S2509. The ticketing system 330 sends an order update response to the scenic area background 350, and the order update response is used to indicate that the order information 1 has been updated.

[0839] It can be understood that the embodiment shown in FIG. 25 is only an example, and in the embodiments of the application, the scenic area background 350 can also determine the validity of the gate opening identifier in a manner different from the above-described embodiments, which is not limited herein.

[0840] In this way, the scenic area background 350 can verify the validity of the verification information sent by the electronic device 100 based on the verification request sent by the gate machine 200, and return a verification response to the gate machine 200 according to the verification result, instructing the gate machine 200 to open or not to open the gate.

[0841] In some application scenarios, the electronic device 100 can display a verification selection prompt after interacting with the gate machine 200, and the verification selection prompt is used to prompt the user to select the electronic ticket to be verified. After the user selects the electronic ticket to be verified, the electronic device 100 can send the identification of the electronic ticket to be verified to the scenic area background 350 for subsequent verification.

[0842] In this way, the user can select the electronic ticket to be verified according to his own needs, providing better user experience.

[0843] For example, FIG. 26 shows a flowchart of a ticket checking method according to an embodiment of the application.

[0844] As shown in FIG. 26, the electronic device 100 can include the meta-service 17, the scene linkage 16 and the NFC protocol stack 14, in the ticket checking process, the electronic device 100 is in the PICC mode, the interaction process of the electronic device 100 with the gate machine 200, the scenic area background 350 and the like server can include the following steps:

[0845] S2601. The electronic device 100 enters the radio frequency field of the gate machine 200.

[0846] S2602. The NFC protocol stack 14 negotiates the transmission parameters with the gate machine 200.

[0847] S2603. The gate machine 200 generates a random number r.

[0848] S2604. The gate machine 200 sends a ticket checking request to the scene linkage 16 through the NFC protocol stack 14, the ticket checking request carries the ID of the gate machine 200 and the random number r, and optionally carries the project identifier 1.

[0849] S2605. The scene linkage 16 determines to call the meta-service 17 based on the ID of the gate machine 200 and / or the project identifier 1.

[0850] S2606. The scene linkage 16 sends a credential request to the meta-service 17, the credential request carries the project identifier 1.

[0851] S2607. The meta-service 17 determines the opening gate identifier 1 (OpenID_1) corresponding to the project identifier 1 based on the project identifier 1.

[0852] The specific content of steps S2601-S2607 can refer to the specific content of steps S2301-S2307 shown in the above FIG. 23, which will not be repeated here.

[0853] S2608. The meta-service 17 sends a credential response to the scene linkage 16, the credential response is used to indicate that the OpenID corresponding to the project identifier 1 is queried.

[0854] S2609. The scene linkage 16 sends a ticket checking response to the gate machine 200 through the NFC protocol stack 14, the ticket checking response carries the ID of the gate machine 200 and the random number r.

[0855] The specific content of steps S2608-S2609 can refer to the specific content of steps S2309-S2310 shown in the above FIG. 23, which will not be repeated here.

[0856] S2610. The meta-service 17 outputs a verification selection prompt, the verification selection prompt is used to prompt the user to select the electronic ticket to be verified.

[0857] In a possible implementation, as long as the number of electronic tickets corresponding to OpenID_1 is a positive integer, the meta-service 17 can output a verification selection prompt to prompt the user to select the electronic ticket to be verified. In this way, the user can be facilitated to select whether to verify the electronic ticket and which electronic ticket to verify.

[0858] In a possible implementation, in the case that the number of electronic tickets corresponding to OpenID_1 is greater than 1, the meta-service 17 can output a verification selection prompt to prompt the user to select the electronic ticket to be verified. In the case that the number of electronic tickets corresponding to OpenID_1 is 1, the meta-service 17 can not output the verification selection prompt. In this way, in the case of a single electronic ticket, the operation steps can be simplified, and in the case of multiple electronic tickets, the electronic ticket can be verified according to the selection of the user.

[0859] It should be noted that, in this embodiment, the meta-service 17 can output the verification selection prompt in the form of display screen display, voice broadcast, vibration, indicator light flickering, etc.

[0860] For example, the interface in which the meta-service 17 displays the verification selection prompt can refer to the related description in the embodiments shown in FIGS. 27A-27C, which will not be described here again.

[0861] It should be noted that, the step S2610 can be executed synchronously with the step S2609, or can be executed after the step S2609.

[0862] S2611. The meta-service 17 determines the electronic ticket to be verified based on the selection operation of the user.

[0863] The selection operation of the user can be a click operation on the display screen, a pressing operation on a specified key, a specific gesture operation, etc., which will not be limited in the present application.

[0864] It should be noted that, the execution sequence of the step S2611 is...

Claims

A ticket checking method applied to a first electronic device, characterized in that, The first electronic device logs in a first account; the method comprises: After entering the radio frequency field of the gate, receiving the first project identification sent by the gate; Based on the first project identification, determining a first gate opening identification OpenID, the first OpenID is generated by the first project identification and the first account, and the first OpenID is used for the gate to verify whether the first account logged in the first electronic device has the right to open the gate; Send the first response to the gate, the first response includes the first OpenID. The method of claim 1, wherein The first OpenID is determined based on the first project identification, specifically including: Based on the first project identification, the first OpenID corresponding to the first project identification is determined from one or more OpenIDs stored in the first electronic device. The method of claim 1, wherein The first OpenID is determined based on the first project identification, specifically including: Send the first project identification and the first account of the first electronic device to the account cloud; Receive the first OpenID sent by the account cloud. The method according to claim 3, characterized in that The first project identification and the first account of the first electronic device are sent to the account cloud, specifically including: Send the first project identification and the first account to the account cloud through the electronic ticket business cloud. The method according to any one of claims 1-4, characterized in that After entering the radio frequency field of the gate, the method further comprises: After entering the radio frequency field of the gate, the method further comprises: Receive the first request sent by the gate, the first request includes the first device identification of the first electronic device; Send the verification request to the electronic ticket business cloud, the verification request includes the first device identification, and the verification request is used to request the electronic ticket business cloud to verify whether the first device identification is valid; The method according to any one of claims 1-5, characterized in that Receive the first verification response sent by the electronic ticket business cloud, the first verification response is used to inform the first electronic device that the first device identification is valid. After entering the radio frequency field of the gate, the method further comprises: Based on the first random number, a first digest is generated by a first hash algorithm; Receive the second digest sent by the gate; The method according to claim 6, characterized in that If the first digest is the same as the second digest, it is determined that the gate is a trusted device. The method further comprises: Receive the second random number sent by the gate; Based on the first random number and the second random number, a third digest is generated by the first hash algorithm; The method according to any one of claims 1-7, characterized in that Send the third digest to the gate, the third digest is used for the gate to judge whether the first electronic device is a trusted device. After entering the radio frequency field of the gate, the method further comprises: Receive the probe frame sent by the gate, the probe frame is used to indicate that the gate supports the specified NFC protocol; Send the probe acknowledgment Probe ACK frame to the gate, the Probe ACK frame is used to indicate that the first electronic device supports the specified NFC protocol; receive a notification Notify frame sent by the gate, the Notify frame carrying device characteristic information of the gate, the device characteristic information of the gate including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of NFC service supported by the gate, and the device organization identifier is used to indicate a manufacturer that provides the NFC service using the gate; determine, based on the device characteristic information of the gate, that the type of NFC service of the gate is an electronic ticket; send a notification confirmation Notify ACK frame to the gate, the Notify ACK frame being used to indicate that the first electronic device has received the Notify frame. The method according to any one of claims 1-8, characterized in that Before entering a radio frequency field of the gate, the method comprises: receiving and corresponding to an operation of a user purchasing a first ticket, obtaining a first project identifier corresponding to the first ticket; sending the first project identifier and the first account number to an account cloud; receiving the first OpenID sent by the account cloud; sending a ticket purchase request to a ticket system server, the ticket purchase request including the first OpenID, a first purchase number of the first ticket; receiving first ticket information sent by the ticket system server, the first ticket information including a first ticket identifier of the first ticket and the first purchase number; displaying the first ticket information. The method of claim 9, wherein The ticket purchase request further includes any one or more of the following: the first project identifier, a ticket type, and a validity period of the first ticket. The first ticket information further includes any one or more of the following: the ticket type, the validity period of the first ticket, and a verification status of the first ticket, the verification status of the first ticket being used to indicate whether the first ticket is verified. The method according to any one of claims 1-8, characterized in that Before entering the radio frequency field of the gate, the method further comprises: after logging in the first account number, sending an information synchronization request to an electronic ticket business cloud, the information synchronization request including the first account number; receiving second ticket information sent by the electronic ticket business cloud, the second ticket information including information of one or more electronic tickets purchased by the first account number, the one or more electronic tickets including a first ticket, the first ticket being bound to the first OpenID. The method according to any one of claims 1-8, characterized in that Before entering the radio frequency field of the gate, the method further comprises: receiving a ticket sharing request sent by a second electronic device, the ticket sharing request including a first transfer identifier of a second OpenID and the first project identifier, the ticket sharing request being used to request sharing a first ticket bound to the second OpenID to the first electronic device; sending the first account number of the first electronic device and the first project identifier to an account cloud; receiving the first OpenID generated based on the first account number and the first project identifier and sent by the account cloud; sending a ticket transfer confirmation to a ticket system server, the ticket transfer confirmation including the first transfer identifier and the first OpenID; receive a transfer success confirmation sent by the ticket system server, the transfer success confirmation being used to notify the first electronic device that the first OpenID has been bound with the first ticket; send a transfer success notification to the second electronic device, the transfer success notification being used to notify the second electronic device that the first ticket transfer is successful. The method according to any one of claims 1-12, characterized in that The first OpenID is bound with one or more electronic tickets. The method according to any one of claims 1-13, characterized in that The first electronic device includes an electronic ticket service and a near field communication (NFC) protocol stack. The first project identifier sent by the gate is received, specifically including: The first routing information is received through the NFC protocol stack, and the first routing information includes the first project identifier. After receiving the first project identifier sent by the gate, the method further includes: The first routing confirmation is sent to the gate through the NFC protocol stack, and the first routing confirmation is used to notify the gate that the first electronic device successfully receives the first routing information. The first OpenID is determined based on the first project identifier, specifically including: The first project identifier is sent to the electronic ticket service based on the first routing information through the NFC protocol stack; The first OpenID is determined based on the first project identifier through the electronic ticket service; The first response is sent to the gate, specifically including: The first response is sent to the gate based on the NFC protocol stack through the electronic ticket service. A ticket checking method applied to a gate machine, characterized in that, The method includes: After the first electronic device enters the radio frequency field of the gate, the first project identifier is sent to the first electronic device; The first response sent by the first electronic device is received, and the first response includes the first gate identifier (OpenID); The gate is opened and released based on the first OpenID. The method of claim 15, wherein The gate is opened and released based on the first OpenID, specifically including: A first verification request is sent to a ticket system server, and the first verification request includes the first OpenID; A first verification response sent by the ticket system server is received; In response to the first verification response, the gate is opened and released. A ticket inspection system characterized by comprising: The first electronic device and the gate are included, wherein the first electronic device is used to implement the method of any one of claims 1-14, and the gate is used to implement the method of any one of claims 15-16. A ticket checking method applied to a first electronic device, characterized in that, The method includes: A first ticket service selection request sent by the gate is received, and the first ticket service selection request is used to request to select an electronic ticket service; A first ticket service selection response is sent to the gate, and the first ticket service selection response is used to indicate that the first electronic device has successfully selected an electronic ticket service; A first ticket verification request sent by the gate is received, and the first ticket verification request includes a third random number and a second device identifier of the gate; A first ticket verification response is sent to the gate, and the first ticket verification response includes the third random number and the second device identifier; Verification information including a first gate identifier (OpenID) and the second device identifier is sent to the background server. The method of claim 18, wherein Before sending the verification information to the background server, the method further comprises: determining a first project identifier based on a mapping relationship between the second device identifier and the project identifier; determining the first OpenID based on the first project identifier, the first OpenID being generated by the first project identifier and a first account, the first OpenID being used by the background server to verify whether the gate is opened. The method of claim 18, wherein The first ticket checking request further comprises a first project identifier. Before sending the verification information to the background server, the method further comprises: determining the first OpenID based on the first project identifier, the first OpenID being generated by the first project identifier and a first account, the first OpenID being used by the background server to verify whether the gate is opened. The method according to claim 19 or 20, characterized in that The determining the first OpenID based on the first project identifier specifically comprises: sending the first project identifier and the first account of the first electronic device to an account cloud; receiving the first OpenID sent by the account cloud. The method according to any one of claims 18-21, characterized in that The verification information further comprises a first ticket identifier, the first ticket identifier being used to indicate an electronic ticket to be checked; Before sending the verification information to the background server, the method further comprises: displaying a verification selection prompt, the verification selection prompt being used to prompt a user to select an electronic ticket to be checked; receiving a selection operation of the user to determine the first ticket identifier. The method according to any one of claims 18-22, characterized in that The first ticket service selection request is used to request to select an online electronic ticket service, and the first ticket service selection response is used to indicate that the first electronic device has successfully selected the online electronic ticket service. The method of claim 23, wherein Before the receiving the first ticket service selection request sent by the gate, the method further comprises: receiving a second ticket service selection request sent by the gate, the second ticket service selection request being used to request to select an offline electronic ticket service; sending a second ticket service selection response to the gate, the second ticket service selection response being used to indicate that the first electronic device fails to select the offline electronic ticket service. The method according to any one of claims 18-24, characterized in that The method further comprises: receiving a first result notification sent by the gate, the first result notification being used to indicate a ticket checking result. The method of claim 25, wherein The method further comprises: sending a first notification response to the gate, the first notification response being used to indicate that the first result notification has been successfully received. The method according to any one of claims 18-26, characterized in that Before the receiving the first ticket service selection request sent by the gate, the method further comprises: negotiating data transmission parameters with the gate after entering a radio frequency field of the gate. The method of claim 27, wherein The negotiating data transmission parameters with the gate specifically comprises: receiving a probe frame sent by the gate, the probe frame being used to indicate that the gate supports a specified NFC protocol; sending a probe acknowledgement frame to the gate, the probe acknowledgement frame being used to indicate that the first electronic device supports the specified NFC protocol; receiving a notification Notify frame sent by the gate machine, the Notify frame carrying device characteristic information of the gate machine, the device characteristic information of the gate machine including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of NFC service supported by the gate machine, and the device organization identifier is used to indicate a manufacturer that provides the NFC service using the gate machine; determining, based on the device characteristic information of the gate machine, that the type of NFC service of the gate machine is electronic ticket; sending a notification confirmation Notify ACK frame to the gate machine, the Notify ACK frame being used to indicate that the first electronic device has received the Notify frame; receiving a parameter negotiation command sent by the gate machine; sending a parameter negotiation response to the gate machine in response to the parameter negotiation command, the parameter negotiation command and the parameter negotiation response being used to negotiate data transmission parameters between an application layer of the gate machine and the first electronic device. A ticket checking method applied to a gate machine, characterized in that, The method comprises: sending a first ticket service selection request to the first electronic device, the first ticket service selection request being used to request selection of an electronic ticket service; receiving a first ticket service selection response sent by the first electronic device, the first ticket service selection response being used to indicate that the first electronic device has successfully selected an electronic ticket service; sending a first ticket verification request to the first electronic device, the first ticket verification request including a third random number and a second device identifier of the gate machine; receiving a first ticket verification response sent by the first electronic device, the first ticket verification response including the third random number and the second device identifier; when detecting that the third random number carried in the first ticket verification response is locally stored, sending a first verification request to a background server, the first verification request including the second device identifier; receiving a first verification response sent by the background server, the first verification response being used to indicate whether the gate machine is opened or not. The method of claim 29, wherein The first ticket service selection request is used to request selection of an online electronic ticket service, and the first ticket service selection response is used to indicate that the first electronic device has successfully selected an online electronic ticket service. The method of claim 30, wherein Before the first ticket service selection request is sent to the first electronic device, the method further comprises: sending a second ticket service selection request to the first electronic device, the second ticket service selection request being used to request selection of an offline electronic ticket service; receiving a second ticket service selection response sent by the first electronic device, the second ticket service selection response being used to indicate that the first electronic device fails to select an offline electronic ticket service. The method according to any one of claims 29-31, characterized in that The method further comprises: sending a first result notification to the first electronic device, the first result notification being used to indicate a ticket verification result. The method of claim 32, wherein The method further comprises: receiving a first notification response sent by the first electronic device, the first notification response being used to indicate that the first result notification has been successfully received. The method according to any one of claims 28-33, characterized in that The method further comprises: after detecting that the first electronic device enters a radio frequency field, negotiating data transmission parameters with the first electronic device. The method of claim 34, wherein The gate machine negotiates data transmission parameters, specifically including: sending a probe frame to the first electronic device, the probe frame being used to indicate that the gate machine supports a specified NFC protocol; receiving a probe acknowledgment (Probe ACK) frame sent by the first electronic device, the Probe ACK frame being used to indicate that the first electronic device supports the specified NFC protocol; sending a notification (Notify) frame to the first electronic device, the Notify frame carrying device feature information of the gate machine, the device feature information of the gate machine including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of NFC service supported by the gate machine, and the device organization identifier is used to indicate a manufacturer that provides NFC service using the gate machine; receiving a notification acknowledgment (Notify ACK) frame sent by the first electronic device, the Notify ACK frame being used to indicate that the first electronic device has received the Notify frame; sending a parameter negotiation command to the first electronic device; receiving a parameter negotiation response sent by the first electronic device, the parameter negotiation command and the parameter negotiation response being used to negotiate data transmission parameters between an application layer of the gate machine and the first electronic device. A ticket checking method applied to a background server, characterized in that, The method comprises: receiving verification information sent by a first electronic device, the verification information including a first gate opening identifier (OpenID) and a second device identifier of the gate machine; receiving a first verification request sent by the gate machine, the first verification request including the second device identifier; determining a first account of the first electronic device based on the first OpenID; obtaining first order information corresponding to the first account based on the first account; based on the first order information and the second device identifier, sending a first verification response to the gate machine, the first verification response being used to indicate whether the gate machine is opened or not. The method of claim 36, wherein The verification information further includes a first ticket identifier, the ticket identifier being used to indicate an electronic ticket to be verified. Based on the first order information and the second device identifier, sending a first verification response to the gate machine, specifically including: based on the first order information, the second device identifier, and the first ticket identifier, sending a first verification response to the gate machine. An electronic device, characterized by comprising: comprising one or more processors, one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories are used to store computer instructions, when the one or more processors execute the computer instructions, the ticket checking method of any one of claims 1-16 or 18-37 is implemented. A chip system, characterized by comprising: a processing circuit and an interface circuit, the interface circuit being used to receive code instructions and transmit to the processing circuit, the processing circuit being used to run the code instructions to execute the ticket checking method of any one of claims 1-16 or 18-37. A readable storage medium characterized by, a computer instruction is stored, when the computer instruction is executed by a processor, the ticket checking method of any one of claims 1-16 or 18-37 is implemented. A computer program product, characterized by Computer program comprising computer instructions which, when executed by a processor, implement the ticket checking method of any one of claims 1-16, or claims 18-37.

Images