Ticket checking method and device

Abstract

Embodiments of the present specification provide a ticket checking processing method and device, wherein the ticket checking processing method comprises: in a ticket checking processing process for a user, a user terminal reads a static link from a device component of a ticket checking device, accesses a service program based on a checking service link obtained by link analysis, and in a case where it is detected that the checking service link carries a checking broadcast identifier, broadcasts an encoding field to the ticket checking device, the ticket checking device collects a checking image based on the encoding field in cooperation with an edge server, and finally calls a ticket checking interface of a server to perform ticket checking processing and identity checking processing, so as to realize ticket checking processing in a user's entry process after ticket purchase on the basis of near field communication between the user terminal and the device component and broadcast communication with the ticket checking device.

Description

Technical Field

[0001] This document relates to the field of identity verification technology, and in particular to a ticket identity verification method and apparatus. Background Technology

[0002] With the continuous development and promotion of the Internet and smart hardware, the application scope of various online services provided by the Internet is becoming wider and wider. In this context, many online services are combined with offline scenarios. For example, after purchasing electronic tickets for concerts and other events online, users can verify their entry by collecting and recognizing their credentials when entering the venue offline. However, with the expansion of the application scope and popularization of services, higher requirements are placed on the combination of online services and offline scenarios. Summary of the Invention

[0003] This specification provides one or more embodiments of a ticket verification processing method applied to a user terminal. The method includes: parsing a static link read from a device component of a ticket verification device via near-field communication to obtain a component identifier and a verification service link; accessing a service program based on the verification service link and detecting whether the verification service link carries a verification broadcast identifier; if so, encoding the component identifier and the user identifier of the ticket purchaser to obtain an encoded field; broadcasting the encoded field to the ticket verification device to enable the ticket verification device to cooperate with an edge server to collect verification images and call the server's ticket verification interface for ticket verification and identity verification processing.

[0004] This specification provides one or more embodiments of another ticket verification method applied to a server. The method includes: obtaining a user identifier sent by the ticketing service provider's edge server calling the ticket verification interface, and a verification image collected by a ticket verification device; the verification image is collected after the ticket verification device receives an encoded field broadcast by the user terminal, the encoded field being obtained based on a static link read from a device component through link parsing and encoding transformation. A ticket entry record is queried based on the user identifier, ticket item information, and verification scheme type. If a matching ticket entry record is found, identity verification processing is performed based on the verification image to obtain the ticket verification result.

[0005] This specification provides one or more embodiments of a ticket verification processing device, operating on a user terminal. The device includes: a link parsing module configured to parse static links read from device components of a ticket verification device via near-field communication to obtain a component identifier and a verification service link; an access encoding module configured to access a service program based on the verification service link and detect whether the verification service link carries a verification broadcast identifier; if so, encoding transformation is performed on the component identifier and the user identifier of the ticket purchaser to obtain an encoded field; and a field broadcasting module configured to broadcast the encoded field to the ticket verification device, enabling the ticket verification device to cooperate with an edge server to collect verification images and call the server's ticket verification interface for ticket verification and identity verification processing.

[0006] This specification provides one or more embodiments of another ticket verification processing device, running on a server side. The device includes: an acquisition module configured to acquire a user identifier sent by the ticketing service provider's edge server calling the ticket verification interface, and a verification image collected by a ticket verification device; the verification image is collected after the ticket verification device receives an encoded field broadcast by the user terminal, the encoded field being obtained based on link parsing and encoding transformation of a static link read from a device component; a record query module configured to query ticket entry records based on the user identifier, ticket item information, and verification scheme type; and a verification processing module configured to, if a matching ticket entry record is found, perform identity verification processing based on the verification image to obtain a ticket verification result.

[0007] This specification provides one or more embodiments of a ticket verification processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: parse a static link read from a device component of the ticket verification device via near-field communication to obtain a component identifier and a verification service link; access a service program based on the verification service link and detect whether the verification service link carries a verification broadcast identifier; if so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field; broadcast the encoded field to the ticket verification device to collect verification images in cooperation with an edge server, and call the server's ticket verification interface for ticket verification and identity verification processing.

[0008] This specification provides one or more embodiments of another ticket verification processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: acquire a user identifier sent by an edge server of a ticketing service provider calling a ticket verification interface and a verification image collected by a ticket verification device; the verification image is collected after the ticket verification device receives an encoded field broadcast by a user terminal, the encoded field being obtained based on a static link read from a device component through link parsing and encoding transformation; a ticket entry record is queried based on the user identifier, ticket item information, and verification scheme type; if a matching ticket entry record is found, identity verification processing is performed based on the verification image to obtain a ticket verification result.

[0009] This specification provides one or more embodiments of a computer-readable storage medium for storing computer-executable instructions. When executed, these instructions implement the following process: parsing a static link read from a device component of a ticketing verification device via near-field communication to obtain a component identifier and a verification service link; accessing a service program based on the verification service link and detecting whether the verification service link carries a verification broadcast identifier; if so, encoding the component identifier and the user identifier of the ticket purchaser to obtain an encoded field; broadcasting the encoded field to the ticketing verification device to enable the ticketing verification device to cooperate with an edge server to collect verification images and call the server's ticketing verification interface for ticket verification and identity verification processing.

[0010] This specification provides one or more embodiments of another computer-readable storage medium for storing computer-executable instructions that, when executed, implement the following process: obtaining a user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and a verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives an encoded field broadcast by the user terminal, the encoded field being obtained based on a static link read from a device component through link parsing and encoding transformation; a ticket entry record is queried based on the user identifier, ticket item information, and verification scheme type; if a matching ticket entry record is found, identity verification processing is performed based on the verification image to obtain the ticket verification result. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A schematic diagram illustrating the implementation environment of a ticket verification processing method provided in one or more embodiments of this specification; Figure 2 A flowchart illustrating a ticket verification method provided in one or more embodiments of this specification; Figure 3 A timing diagram illustrating a ticket verification processing method applied to a ticket verification scenario, provided for one or more embodiments of this specification; Figure 4 A flowchart illustrating another ticket verification method provided in one or more embodiments of this specification; Figure 5 A schematic diagram of an embodiment of a ticket verification processing device provided in one or more embodiments of this specification; Figure 6 A schematic diagram of another embodiment of a ticket verification processing device provided in one or more embodiments of this specification; Figure 7 A schematic diagram of the structure of a ticket verification processing device provided in one or more embodiments of this specification; Figure 8 This is a schematic diagram of another ticket verification processing device provided in one or more embodiments of this specification. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0013] The ticket verification processing method provided in one or more embodiments of this specification is applicable to the implementation environment of a ticket verification processing system. (Refer to...) Figure 1 The implementation environment includes at least: User terminal 101, server 102, ticket verification device 103, edge server 104, and device component 103-1 of ticket verification device 103; Among them, user terminal 101 refers to the terminal device used by ticket purchasers when purchasing tickets online and using the ticketing service provider for offline access. User terminal 101 can be a mobile phone, personal computer, tablet computer, e-book reader, wearable device, device for information interaction based on AR (Augmented Reality) / VR (Virtual Reality), and laptop computer, etc.; server 102 refers to the backend server that cooperates with user terminal 101 and edge server 104 of the ticketing service provider to perform ticket verification-related processing during the ticket verification process. Ticket verification device 103 refers to the verification device provided, deployed, or used by the ticketing service provider at offline locations for verifying user tickets; the ticket verification device 103 is configured with device component 103-1, which can perform near-field communication interaction with user terminal 101; edge server 104 refers to the server deployed or used locally by the ticketing service provider at offline locations for processing user ticket verification. In this implementation environment, during the ticket verification process for ticket purchasers, user terminal 101 reads a static link from device component 103-1 of ticket verification device 103, parses the static link to obtain the component identifier and the verification service link, accesses the service program based on the verification service link, and checks whether the verification service link carries a verification broadcast identifier. If it does, the component identifier and the ticket purchaser's user identifier are encoded according to the verification method corresponding to the verification broadcast identifier to obtain an encoded field, and the encoded field is sent to ticket verification device 103. After receiving the encoded field broadcast by the user terminal 101, the ticket verification device 103 cooperates with the edge server 104 to collect the verification image of the ticket purchaser. The edge server 104 then calls the ticket verification interface of the server 102 to perform ticket verification and identity verification. Based on the near-field communication between the user terminal 101 and the device component 103-1 and the broadcast communication with the ticket verification device 103, the ticket verification device 103, the edge server 104, and the server 102 work together to realize the ticket verification process for the ticket purchaser entering the venue.

[0014] It should be noted that, considering that the user identifiers, user identity information, identity credentials, and other related data involved in this specification may, to some extent, fall under the category of user privacy, authorization from the user must be obtained before collecting such data to ensure that the data collection operation complies with relevant data management regulations. For example, data authorization can be granted when a ticket purchaser makes a ticket purchase. The specific method of data authorization can be through signing a data authorization agreement or a service agreement, which is not limited in this embodiment.

[0015] Reference Figure 2 The ticket verification method provided in this embodiment can be applied to user terminals. The method specifically includes steps S202 to S206.

[0016] Step S202: Parse the static link read from the device component of the ticket verification device via near-field communication to obtain the component identifier and the verification service link.

[0017] The ticket verification equipment described in this embodiment refers to ticket verification equipment deployed in offline venues. Specifically, it refers to venue equipment that verifies the identity of ticket purchasers when they enter an offline venue after purchasing tickets, or venue equipment that verifies the identity of ticket purchasers within an offline venue after they have entered. Offline venues refer to the location, space, or building corresponding to the ticket or ticket voucher purchased by the ticket purchaser. Specifically, the ticket verification equipment can be a turnstile, such as a turnstile that verifies the identity of a ticket purchaser when they enter a concert venue after purchasing a concert ticket. In addition, the ticket verification equipment can also be other forms of equipment, such as mobile verification equipment or handheld verification equipment.

[0018] The equipment components of a ticket verification device refer to the equipment components configured in the ticket verification device, or those physically connected or otherwise connected to the ticket verification device. During the ticket verification process, these equipment components are used for near-field communication with the user terminal. Optionally, the equipment components include: an external near-field communication tag of the ticket verification device, or a near-field communication component built into the ticket verification device. Alternatively, the equipment components can be near-field communication materials that establish a physical connection with the ticket verification device; these near-field communication materials include near-field communication tags and / or near-field communication components, or they can be near-field communication materials that establish a wireless or broadcast connection with the ticket verification device.

[0019] In practice, during the ticket verification process, the ticket purchaser can bring their terminal close to the ticket verification device's components, or make close contact with the device's components. When the user's terminal is close to the device components, near-field communication can be established between the two. Based on the established near-field communication, the user terminal can obtain or read static links from the device components, or receive static links sent by the device components, and parse the static links to obtain the component identifier and the verification service link.

[0020] Here, the component identifier refers to the unique identifier of the device component. For example, the component identifier can be the tag number of the near-field communication tag or the component number of the near-field communication component; the component identifier can also be the material identifier of the near-field communication material; optionally, the component identifier includes the tag identifier of the near-field communication tag or the component identifier of the near-field communication component. In addition, when the device component is a near-field communication component or near-field communication tag built into the ticket verification device, the component identifier can also be replaced with the device identifier of the ticket verification device.

[0021] Static links refer to links stored in device components. Specifically, the component identifier field of the device component can be configured in the static link, as can the identity verification broadcast identifier field. The identity verification broadcast identifier is an identifier used to determine whether broadcast communication is used during the ticket identity verification process, specifically whether the user terminal uses broadcast communication to broadcast data to the ticket identity verification device. Optionally, the component identifier and / or identity verification broadcast identifier can be configured in the static link. The component identifier and / or identity verification broadcast identifier can be configured in the coded links included in the static link.

[0022] In addition, static links can also be links adapted to near-field communication materials, or fixed links adapted to the communication protocol of near-field communication materials. For example, static links can use the prefix alipay: / / nfc / app, and can further transmit information more securely through the three parameters id, t, and v in the link. Here, id can be the material number of the near-field communication material or other information, t can be a random value for timeliness, and v represents the encoded link after the service link is encoded. The encoded link is configured with the encoded field "deviceNo%253Ddm888888" corresponding to the material identifier of the near-field communication material and the encoded field "ble%253Dy" corresponding to the identity broadcast identifier.

[0023] The identity verification service link refers to the service link or access link used to access the identity verification service on a user terminal. It can be obtained by parsing a static link, specifically by decoding the encoded link contained in the static link. When the encoded link contained in the static link is configured with a component identifier and / or an identity verification broadcast identifier, decoding the encoded link contained in the static link can obtain the component identifier and / or the identity verification broadcast identifier. Specifically, decoding the encoded link contained in the static link can obtain the identity verification service link containing the component identifier and / or the identity verification broadcast identifier.

[0024] For example, if the encoded link configuration component identifier has the encoded field "deviceNo%253Ddm888888" and the identity broadcast identifier has the encoded field "ble%253Dy", then decoding the encoded link to obtain the service link will contain the fields "deviceNo=dm888888" and "ble=y", where dm888888 is the material identifier of the near-field communication material and y represents the identity broadcast identifier.

[0025] In the specific execution process, when the user terminal obtains the static links stored by the device component, it can be that the user terminal sends a link request or request field to the device component, and after receiving the link request or request field, the device component sends the static links stored by itself to the user terminal; it can also be that after the user terminal establishes near-field communication with the device component, the device component sends the static links stored by itself to the user terminal; or it can also be that after the user terminal establishes near-field communication with the device component, the user terminal reads the static links from the device component. Accordingly, after the user terminal receives or reads the static link, it parses the static link to obtain the identity verification service link. Specifically, it can decode the encoded link contained in the static link to obtain the identity verification service link. The identity verification service link contains the component identifier and / or the identity verification broadcast identifier, so the component identifier and / or the identity verification broadcast identifier can be obtained from the identity verification service link.

[0026] In this embodiment, the ticketing service provider can be configured with a corresponding ticketing verification scheme. The ticketing verification scheme refers to the specific verification scheme or strategy used when verifying the identity of a ticket purchaser. Optionally, static links are generated after the ticketing verification scheme is configured. The verification configuration includes verification link configuration and / or verification identity type configuration. Among these, the identity verification link configuration refers to configuring the identity verification link used in the ticketing identity verification process; optionally, the identity verification link includes a broadcast identity verification link / or a network identity verification link; the identity verification type configuration refers to configuring which identity type the ticket-purchasing user uses for ticketing identity verification during the ticketing identity verification process. The identity verification type can be an application identity type using an application account for verification, a communication identity type using a communication number for verification, and / or a credential identity type using identity credentials for verification. The identity verification broadcast identifier can be determined according to the identity verification link configured in the ticketing identity verification scheme.

[0027] For example, for a ticket verification scheme configured for a ticketing service provider's ticketing project, a verification link is configured to perform ticket verification processing based on broadcast communication. This verification link can be called a broadcast verification link. When the ticket verification scheme is configured with a broadcast verification link, the encoded link in the static link stored in the device component is configured with the field "ble=y", where "y" indicates that the broadcast verification link is configured, and the broadcast verification link can be used for ticket verification processing in the future. Conversely, if the ticket verification scheme is not configured with a broadcast verification link, the "y" in the encoded link "ble=y" field can be configured as "n" or empty.

[0028] In practical applications, during the configuration of the ticket verification scheme, verification configuration can be performed after establishing near-field communication between the configuration personnel's configuration terminal and the device component; static links can be written to the device component through the configuration terminal and stored by the device component; optionally, the component identifier can be read after the configuration personnel's configuration terminal establishes near-field communication with the device component; furthermore, the component identifier can be associated with the ticket verification scheme after verification configuration; subsequently, when querying or retrieving the ticket verification scheme during the ticket verification process, the associated ticket verification scheme can be queried or retrieved based on the component identifier.

[0029] In the specific execution process, after the configuration personnel enter the service program or the ticketing service provider's subprogram through the configuration terminal, the ticket verification scheme is configured through the service program or the ticketing service provider's subprogram. Specifically, during the verification configuration process, the configuration personnel read the component identifier of the ticketing verification device's device component through the configuration terminal. Based on the read component identifier, the service program or the ticketing service provider's subprogram generates a static link based on the component identifier, and the configuration personnel write the static link into the device component of the ticketing verification device for storage through the configuration terminal.

[0030] It should be noted that in actual scenarios, during the ticket verification process at offline venues, there may be situations where the network is poor or even offline. For example, the network may be poor or unstable due to the large number of ticket buyers attending the concert. There may also be situations where the network is good. Ticketing service providers can configure the corresponding verification links according to the actual needs of the scenario, combined with the network conditions or actual operation. For example, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can configure a broadcast verification link for their ticket verification solutions to improve the success rate of ticket verification. In this case, during the ticket verification process through the user's terminal, the user terminal may be offline or in a network abnormal state. Optionally, the user terminal may be offline or in a network abnormal state. Network abnormal states include weak network conditions, unstable network conditions, and / or network redundancy caused by too many accesses. In addition, the user terminal may also be in a normal network state, in which case a broadcast verification link can also be used for ticket verification. For example, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can improve the success rate of ticket verification and reduce the processing response time for ticket buyers. They can configure both broadcast verification links and network verification links simultaneously for the ticket verification solution, allowing both to execute in parallel to increase the success rate. In this scenario, the user terminal may be offline, experiencing network anomalies, or in a normal or good network state. In the case of a normal or good network state, both broadcast and network verification links are used for ticket verification. For example, ticketing service providers can configure network verification links for ticket verification solutions when the network is stable and in good condition, i.e., when the user terminal is in a normal network state. This can avoid deploying edge servers in offline locations, thereby saving costs.

[0031] Step S204: Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field.

[0032] In practice, after parsing the static links read from the device components to obtain the component identifier and the authentication service link, the service program is accessed based on the authentication service link. The service program then checks whether the authentication service link carries an authentication broadcast identifier. If so, it indicates that the current ticket authentication process requires the use of a broadcast authentication link for ticket authentication. In this case, the component identifier and the user identifier of the ticket purchaser are encoded and transformed to obtain an encoded field. If not, it indicates that the current ticket authentication process does not require the use of a broadcast authentication link for ticket authentication. The service program can be a ticket verification program provided by the service provider to the ticket service provider, or it can be a ticket verification program that works with the server to perform ticket verification. Specifically, the service program can be a service subroutine that runs within the host application installed on the user terminal to perform ticket verification, or an application that performs ticket verification installed on the user terminal. In addition, the service program can also be a service subroutine or application that works with the service provider to perform ticket verification.

[0033] In addition, if the identity verification service link does not carry an identity verification broadcast identifier, a network identity verification link can be used for ticket identity verification. The following sections will explain in detail the process of using a broadcast identity verification link and the process of using a network identity verification link for ticket identity verification.

[0034] (1) Ticket verification is performed using a broadcast verification link. If the detection result of whether the identity verification service link carries the identity verification broadcast identifier is yes, it indicates that the current ticketing identity verification process needs to use the broadcast identity verification link for ticketing identity verification processing. That is, the current ticketing identity verification scheme is configured with the broadcast identity verification link. In this case, during the ticketing identity verification process using the broadcast identity verification link, the component identifier and the user identifier of the ticket purchaser are first encoded and transformed to obtain the encoded field. Then, the following step S206 is executed to broadcast the encoded field to the ticketing identity verification device so that the ticketing identity verification device can cooperate with the edge server to collect the identity verification image and call the ticketing identity verification interface of the server to perform ticketing verification processing and identity verification processing. In one optional implementation of this embodiment, the ticket verification process is carried out using a broadcast verification link, including: encoding and transforming the component identifier and the user identifier of the ticket purchaser to obtain an encoded field and broadcasting the encoded field to the ticket verification device, so that the ticket verification device and the edge server can cooperate to collect the verification image, and call the ticket verification interface of the server to perform ticket verification and identity verification processing.

[0035] As mentioned above, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can improve the success rate of ticket verification and reduce the processing response time for ticket buyers. This can be achieved by configuring both broadcast verification and network verification links simultaneously. Furthermore, if the detection result for whether the verification service link carries a broadcast verification identifier is yes, in addition to executing the ticket verification process using the network verification link, the process can also be executed asynchronously or in parallel.

[0036] In practice, when using a broadcast verification link for ticket verification, to prevent data leakage during the broadcast process from the user terminal to the ticket verification device, the component identifier and the user identifier of the ticket purchaser are encoded to obtain an encoded field. This encoded field is then broadcast to the ticket verification device to prevent data leakage. Specifically, the encoding transformation of the component identifier and the user identifier can be performed using an obfuscation algorithm to obtain an obfuscated encoded field. For example, the component identifier and the user identifier can be rearranged using an obfuscation algorithm to obtain an encoded string. After the encoded string is broadcast to the ticket verification device, the ticket verification device parses the encoded string to obtain the component identifier and the user identifier.

[0037] In this embodiment, when the user terminal broadcasts an encoded field to the ticket verification device, it can do so by calling a wireless component or broadcast component configured on the user terminal. Specifically, the wireless component or broadcast component can be a Bluetooth component, a Wi-Fi component, or a UWB (Ultra Wide Band) component, or other wireless communication components capable of broadcasting encoded fields to the ticket verification device, such as an infrared communication component. Correspondingly, the ticket verification device is also configured with a wireless component or broadcast receiving component corresponding to the user terminal to receive the encoded field broadcast by the user terminal. It should be noted that, in addition to the above-mentioned implementation of broadcasting the encoded field to the ticket verification device, the user terminal can also broadcast the encoded field to the device component of the ticket verification device, and the device component will transmit the encoded field to the ticket verification device. In this case, the device component is configured with a wireless component, and the above-mentioned broadcasting of the encoded field to the ticket verification device can be replaced by broadcasting the encoded field to the device component of the ticket verification device.

[0038] (2) Use online identity verification link for ticket verification processing During the online identity verification process, the system can detect whether the user terminal's network status is a preset network status. If so, it queries the ticketing identity verification scheme associated with the component identifier. If the ticketing identity verification scheme includes an online identity verification link, it submits the user identifier to the server to be sent to the edge server through the server. Alternatively, it can also detect whether the user terminal's network status is a preset network status. If so, it submits the user identifier to the server to be sent to the edge server through the server. Or, it can also submit the user identifier to the server to be sent to the edge server through the server. Or, it can also query the ticketing identity verification scheme associated with the component identifier. If the ticketing identity verification scheme includes an online identity verification link, it submits the user identifier to the server to be sent to the edge server through the server. Based on this, after receiving the user identifier, the edge server cooperates with the ticket verification device to collect the verification image and calls the ticket verification interface on the server to perform ticket verification and identity verification. In the specific execution process, after receiving the user identifier, the edge server can cooperate with the ticket verification device bound to the component identifier to collect the verification image and call the ticket verification interface to send the user identifier and the collected verification image to the server for ticket verification and identity verification.

[0039] In one optional implementation method provided in this embodiment, a network-based identity verification link is used for ticket identity verification, including any one of the following four implementation methods: The system checks whether the user terminal's network status is the preset network status. If so, it queries the ticket verification scheme associated with the component identifier. If the ticket verification scheme includes a network verification link, it submits the user identifier to the server to send it to the edge server, so that the edge server and the ticket verification device can cooperate to collect the verification image. The system then calls the server's ticket verification interface to perform ticket verification processing. Ticket verification processing includes ticket verification processing and / or identity verification processing. The system checks whether the user terminal's network status is the preset network status. If so, it submits the user identifier to the server so that the server can send it to the edge server, enabling the edge server to cooperate with the ticket verification device to collect the verification image and call the server's ticket verification interface to perform ticket verification processing. Query the ticket verification scheme associated with the component identifier. If the ticket verification scheme includes a network verification link, submit the user identifier to the server so that it can be sent to the edge server through the server. This enables the edge server to cooperate with the ticket verification device to collect the verification image and call the ticket verification interface of the server to perform ticket verification processing. Submit the user identifier to the server so that it can be sent to the edge server, enabling the edge server to cooperate with the ticket verification device to collect the verification image and call the server's ticket verification interface to perform ticket verification processing.

[0040] It should be noted that the preset network state in any of the above implementation methods can be a normal network state, that is, the corresponding ticket verification operation of the subsequent network verification link is executed when the network state of the user terminal is detected to be normal; similarly, the preset network state in any of the above implementation methods can also be a network abnormal state, that is, the corresponding ticket verification operation of the subsequent network verification link is executed only when the network state of the user terminal is detected to be abnormal. Alternatively, the preset network state in any of the above implementation methods can be a normal network state or an abnormal network state, that is: when the network state of the user terminal is detected to be either a normal network state or an abnormal network state, the corresponding ticket verification processing operation of the subsequent network verification link is executed. In addition, the preset network state in any of the above implementation methods can also be any two or three of the network states, depending on the actual scenario. For example, the preset network state can also be offline or network normal.

[0041] In this embodiment, regardless of whether a broadcast verification link, a network verification link, or both are used in parallel for ticket verification, the edge server, upon receiving the user identifier, will cooperate with the ticket verification device to collect a verification image and call the server's ticket verification interface to perform ticket verification and identity verification. In this embodiment, the process of the edge server cooperating with the ticket verification device to collect a verification image is the same as the process of the ticket verification device cooperating with the edge server to collect a verification image. Therefore, the process of the edge server cooperating with the ticket verification device to collect a verification image can be interchanged with the process of the ticket verification device cooperating with the edge server to collect a verification image.

[0042] It should be noted that during the parallel use of broadcast verification link and network verification link for ticket verification processing, since there is no need to repeat the ticket verification and identity verification processes twice for the current ticket purchaser, in order to complete the ticket verification process faster and reduce the processing response time for ticket purchasers, the edge server will only process the user identifiers sent by the broadcast verification link and the network verification link respectively. The user identifiers received later will not be processed. That is, the process of ticket verification device and edge server (or edge server and ticket verification device) cooperating to collect verification images and call the server's ticket verification interface to perform ticket verification and identity verification processes will not be performed for the user identifiers received later. In one optional implementation of this embodiment, after receiving a user identifier sent by either the ticketing verification device or the server, the edge server performs the following operations: the ticketing verification device bound to the component identifier cooperates to collect a verification image, and calls the ticketing verification interface to send the received user identifier and the collected verification image to the server.

[0043] Here, if the received user identifier is not processed—that is, if the process of the ticket verification device and the edge server (or the edge server and the ticket verification device) cooperating to collect the verification image and calling the server's ticket verification interface for ticket verification and identity verification is not performed on the received user identifier—then in any of the above-mentioned implementations using a broadcast verification link for ticket verification, the process of the ticket verification device and the edge server cooperating to collect the verification image and calling the server's ticket verification interface for ticket verification and identity verification can be deleted. Alternatively, the process of the edge server and the ticket verification device cooperating to collect verification images and calling the server's ticket verification interface to perform ticket verification and identity verification can be deleted or not executed in any of the above-mentioned implementation methods for ticket verification processing using a network verification link. That is, in the process of ticket verification processing for a single ticket purchaser, the process of the ticket verification device and the edge server (or the edge server and the ticket verification device cooperating to collect verification images and calling the server's ticket verification interface to perform ticket verification and identity verification is executed only once.

[0044] The edge server mentioned in this embodiment refers to a server deployed or used by the ticketing service provider at offline locations for user ticket verification. It can also interact and communicate with the ticket verification device and the server during the ticket verification process. Specifically, the edge server can be a local server deployed at the offline location where the ticket verification device is located, or it can be a remote server that has established a connection with the ticket verification device, such as establishing a physical connection with the ticket verification device to ensure normal communication with the ticket verification device in the event of network anomalies or instability.

[0045] It should be noted that, in the process of ticket verification using a network-based verification link, the edge server that cooperates with the ticket verification device and interacts with the server can be replaced by a ticket server; or, a ticket server can be added to the edge server, with the ticket server responsible for interacting with the server and communicating with the edge server, and the edge server responsible for cooperating with the ticket verification device and communicating with the ticket server; similarly, in the process of ticket verification using a broadcast verification link, a ticket server can also be added to the edge server, with the ticket server responsible for interacting with the server and communicating with the edge server, and the edge server responsible for cooperating with the ticket verification device and communicating with the ticket server. In the specific execution process, after the user terminal submits the user identifier to the server, or after the service program submits the user identifier to the server, the server can send the user identifier to the ticketing server. After receiving the user identifier, the ticketing server calls the edge server to cooperate with the ticketing verification device to collect the verification image (or, the ticketing server sends an image collection instruction to the edge server, and the edge server cooperates with the ticketing verification device to collect the verification image according to the image collection instruction). After collecting the verification image, the ticketing verification interface is called to send the received user identifier and the collected verification image to the server.

[0046] Step S206: Broadcast the encoded field to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification processing.

[0047] In specific implementation, during the ticket verification process using the broadcast verification link, based on the encoding transformation of the component identifier and the user identifier of the ticket purchaser to obtain the encoded field, the encoded field is broadcast to the ticket verification device so that the ticket verification device can cooperate with the edge server to collect the verification image and call the ticket verification interface of the server to perform ticket verification processing; the ticket verification processing includes ticket verification processing and / or identity verification processing; After ticket verification and identity verification, a ticket verification result is obtained, which includes whether the ticket verification is successful or unsuccessful. After obtaining the ticket verification result, the server can send the ticket verification result to the edge server, and the edge server will issue a verification access instruction to the ticket verification device bound to the component identifier based on the ticket verification result. The verification access instruction includes a verification success instruction or a verification failure instruction.

[0048] In practice, instead of collecting verification images through the cooperation of the ticket verification device and the edge server, the process can be replaced by the cooperation of the edge server and the ticket verification device. Specifically, during the image collection process, the edge server can send an image collection command to the ticket verification device, which then collects the verification image according to the command and uploads it to the edge server. Alternatively, the ticket verification device can pre-collect and store the verification image, and then upload the stored image to the edge server after receiving the image collection command from the edge server. The pre-collection of the verification image by the ticket verification device can be performed after the user terminal reads the static link from the device component via near-field communication, or it can be performed after receiving the encoded field broadcast by the user terminal.

[0049] During the ticket verification and identity verification process, ticket entry records can be queried based on user identifier, ticket item information and / or identity verification scheme type. If a matching ticket entry record is found, identity verification is performed based on the identity verification image to obtain the ticket verification result. Alternatively, before querying ticket entry records based on user identifier, ticket item information and / or verification scheme type, identity information verification can be performed based on the user identity information corresponding to the user identifier. After the identity information verification is passed, the ticket entry records can be queried based on user identifier, ticket item information and / or verification scheme type. If a matching ticket entry record is found, identity verification processing can be performed based on the verification image to obtain the ticket verification result. The user identifier can be either the user program identifier of the ticket purchaser within the service program or the user application identifier of the host application within the service program. The service program obtains the user application identifier of the ticket purchaser from the host application. User identity information refers to identity-related information required to verify the authenticity of the ticket purchaser's identity. For example, the user identity information used for real-name verification of the ticket purchaser could be the credential information of the ticket purchaser's identity certificate.

[0050] In one optional implementation of this embodiment, ticket verification processing and identity verification processing are performed, including: Obtain the user identifier and verification image sent by the edge server when calling the ticket verification interface, and query the ticket entry records based on the user identifier, ticket item information and / or verification scheme type; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

[0051] In this embodiment, after a ticket purchaser makes a purchase through a ticketing service provider, the ticket purchaser's ticketing record will be stored in the database. Specifically, during the storage process, the ticketing service provider can send a ticket storage request or ticket storage information to the server. After receiving the ticket storage request or ticket storage information, the server will query the application account based on the identity field contained in the ticket storage request or ticket storage information. The server will then create a ticket storage record based on the queried application account and identity field and store it in the database. Alternatively, the server can create a ticket storage record based on the queried application account and the ticketing field contained in the ticket storage request or ticket storage information and store it in the database. In addition, after receiving a ticket entry request or ticket entry information, the server can also query whether a corresponding ticket verification scheme exists based on the ticket fields contained in the ticket entry request or ticket entry information. After finding a ticket verification scheme, the server can query the application account based on the identity field in the ticket fields, create a ticket entry record based on the queried application account and identity field, and perform entry storage processing. Alternatively, the server can also create a ticket entry record based on the queried application account and ticket fields and perform entry storage processing.

[0052] Here, the ticket entry request or ticket entry information contains at least one of the following fields: the project identifier of the ticket project, the link type of the verification link configured in the ticket verification scheme of the ticket project, the service provider identifier of the ticket service provider, the ticket application identifier of the ticket application of the ticket service provider on which the ticket purchaser made the purchase, the credential identifier (or encrypted credential identifier) ​​of the ticket purchaser's identity credential, the communication number (or encrypted communication number) of the ticket purchaser, and the ticket credential code (or encrypted ticket credential code) of the ticket purchased by the ticket purchaser. Correspondingly, the ticketing fields contained in the ticketing entry request or ticketing entry information can be composed of one or more fields contained in the ticketing entry request or ticketing entry information. For example, the ticketing fields can be composed of at least one of the following four fields: project identifier, service provider identifier, ticketing application identifier, and link type. The identity field can be a credential identifier, communication number, or ticket voucher code, or it can be a credential identifier, communication number, or ticket voucher code obtained after decrypting an encrypted credential identifier, encrypted communication number, or encrypted ticket voucher code; The application account can be the user application account (user application identifier) ​​of the ticket purchaser in the service program, or it can be the user application account (user application identifier) ​​of the host application of the ticket purchaser in the service program.

[0053] In one optional implementation of this embodiment, the ticket entry record is generated in the following way: based on the ticket fields sent by the ticket service provider, a query is performed to see if a corresponding ticket verification scheme exists; if so, an application account is queried based on the identity field in the ticket fields, and a ticket entry record is created and stored based on the queried application account and ticket fields.

[0054] In practical applications, there may be situations where a ticket-purchasing user has registered multiple program accounts or application accounts in the service program or host application. To address this, in order to enable ticket-purchasing users to use any program account or application account for ticket verification, during the process of creating and storing ticket entry records based on the queried application account and ticket fields, ticket entry records can be stored separately for each program account or application account. This ensures that subsequent ticket-purchasing users can perform ticket verification by logging in with any program account or application account. In one optional implementation of this embodiment, a ticket entry record is created and stored based on the queried application account and ticketing field. This includes: if multiple application accounts are queried, a ticket entry record is created based on the queried application account and ticketing field, and the ticket entry record is written into the ticket entry list mapped to each application account in the ticketing database.

[0055] Furthermore, in practical applications, there may be situations where ticket buyers cancel their tickets after purchase. To address this, a ticket release process can be performed after the refund to delete the ticket entry record; that is, the ticket entry record is deleted after the ticket release process. In one optional implementation of this embodiment, the ticket release process includes: decrypting the encrypted release field carried in the ticket release request to obtain the ticket release field; querying the corresponding ticket entry record based on the ticket release field and performing the release deletion process. The ticket release request is generated after detecting a ticket buyer's refund operation.

[0056] In summary, the ticket verification method provided in this embodiment, during the ticket verification process for ticket purchasers, involves the user terminal reading a static link from the device components of the ticket verification device, parsing the static link to obtain the component identifier and the verification service link, accessing the service program based on the verification service link, and detecting whether the verification service link carries a verification broadcast identifier. If it does, the component identifier and the user identifier of the ticket purchaser are encoded according to the verification method corresponding to the verification broadcast identifier to obtain an encoded field, which is then broadcast to the ticket verification device. After receiving the broadcast encoded field, the ticket verification device cooperates with the edge server to collect the verification image of the ticket purchaser, and the edge server calls the ticket verification interface of the server to perform ticket verification and identity verification. This method enables ticket verification in offline or abnormal network scenarios by enabling near-field communication between the user terminal and the device components and broadcast communication with the ticket verification device, thereby improving the success rate of ticket verification. In addition, when the user terminal's network status is normal or abnormal, the ticket verification scheme associated with the component identifier can be queried. If the ticket verification scheme includes a network verification link, the user identifier is submitted to the server to be sent to the edge server through the server. This allows the ticket verification device and the edge server to cooperate in calling the ticket verification interface of the verification server to process the ticket verification of the ticket purchaser, thereby reducing the processing response time of the ticket purchaser during the ticket verification process.

[0057] It should be noted that steps S202 to S206 provided in this embodiment can be executed by the user terminal. It should also be noted that steps S202 to S206 executed by the user terminal and steps S402 to S406 executed by the server in the following embodiment can cooperate with each other during execution. Therefore, when reading this embodiment, please refer to the corresponding content of steps S402 to S406 provided in the following method embodiment, and when reading the following method embodiment, please refer to the corresponding content of steps S202 to S206 provided in this embodiment.

[0058] The following example uses a ticket verification processing method provided in this embodiment to illustrate its application in a ticket project verification scenario. Figure 3 The ticket verification method provided in this embodiment will be further explained below. See [link to documentation]. Figure 3 The ticket verification processing method applied to ticketing project verification scenarios includes the following steps.

[0059] Step S302: Read the static link from the near-field communication material of the ticket verification device deployed in the ticketing project via near-field communication.

[0060] Step S304: Parse the static links to obtain the material identifier and identity verification service links.

[0061] Step S306: Access the service subroutine based on the identity verification service link.

[0062] Step S308: Check whether the identity verification service link carries an identity verification broadcast identifier through the service subroutine; if so, execute steps S310 and S312. Step S310: Encode the material identifier and the user identifier of the ticket purchaser to obtain the encoded field.

[0063] Step S312: Broadcast the encoded field to the ticket verification device.

[0064] After receiving the broadcast encoded field, the ticket verification device parses the encoded field to obtain the material identifier and the user identifier of the ticket purchaser. Further, it collects the verification image of the ticket purchaser and uploads the verification image to the edge server. The material identifier and the user identifier of the ticket purchaser are uploaded to the edge server together with the verification image, or they can be uploaded to the edge server before collecting the verification image of the ticket purchaser. After receiving the user identifier and the verification image, the edge server uses the user identifier and the verification image as input parameters to call the ticket verification interface of the verification server.

[0065] Step S314: Check whether the network status of the user terminal is normal. If so, proceed to step S316; If not, no action needs to be taken.

[0066] Step S316: Query the ticket verification scheme associated with the material identifier.

[0067] Step S318: If the ticket verification scheme includes an online verification link, submit the user identifier to the verification server.

[0068] After broadcasting the encoded field to the ticket verification device in step S312, the ticket verification device receives the broadcast encoded field and parses it to obtain the material identifier and the user identifier of the ticket purchaser. Further, the ticket verification device collects the verification image of the ticket purchaser and uploads the verification image to the edge server. After receiving the user identifier and the verification image, the edge server uses the user identifier and the verification image as input parameters to call the ticket verification interface of the verification server. The material identifier and the user identifier of the ticket purchaser are uploaded to the edge server together with the verification image; they can also be uploaded to the edge server before collecting the verification image of the ticket purchaser. It should be noted that steps S314 to S318 can be executed in parallel with steps S310 to S312, or steps S314 to S318 can be omitted.

[0069] It should be noted that any one or more steps in steps S302 to S318 can be combined with any one or more steps in steps S202 to S206 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features in steps S302 to S318 can be selected and combined with any one or more technical features provided in steps S202 to S206 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps S302 to S318 can be replaced with any one or more technical features provided in steps S202 to S206 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0070] Furthermore, it should be noted that steps S302 to S318 provided in this embodiment can be executed by the user terminal. It should also be noted that steps S302 to S318 executed by the user terminal and steps S320 to S330 executed by the identity verification server in the following embodiment can cooperate with each other during execution. Therefore, when reading this embodiment, please refer to the corresponding content of steps S320 to S330 provided in the following method embodiment, and when reading the following method embodiment, please refer to the corresponding content of steps S302 to S318 provided in this embodiment.

[0071] One or more embodiments of another ticket verification method provided in this specification are as follows: Reference Figure 4 The ticket verification processing method provided in this embodiment can be applied to the server (verification server), and the method specifically includes steps S402 to S406.

[0072] Step S402: Obtain the user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and the verification image collected by the ticketing verification device.

[0073] The edge server mentioned in this embodiment refers to a server deployed or used by the ticketing service provider at offline locations for user ticket verification. It can also interact and communicate with the ticket verification device and the server during the ticket verification process. Specifically, the edge server can be a local server deployed at the offline location where the ticket verification device is located, or it can be a remote server that has established a connection with the ticket verification device, such as establishing a physical connection with the ticket verification device to ensure normal communication with the ticket verification device in the event of network anomalies or instability.

[0074] Ticket verification equipment refers to ticket verification equipment deployed in offline venues. Specifically, it refers to the equipment used to verify the identity of ticket purchasers when entering an offline venue, or the equipment used to verify the identity of ticket purchasers within an offline venue after they have entered. Offline venues refer to the location, space, or building corresponding to the ticket or ticket voucher purchased by the ticket purchaser. Specifically, ticket verification equipment can be a turnstile, such as a turnstile used to verify the identity of a ticket purchaser when entering a concert venue. In addition, ticket verification equipment can also be other forms of equipment, such as mobile verification equipment or handheld verification equipment.

[0075] The equipment components of a ticket verification device refer to the equipment components configured in the ticket verification device, or those physically connected or otherwise connected to the ticket verification device. During the ticket verification process, these equipment components are used for near-field communication with the user terminal. Optionally, the equipment components include: an external near-field communication tag of the ticket verification device, or a near-field communication component built into the ticket verification device. Alternatively, the equipment components can be near-field communication materials that establish a physical connection with the ticket verification device; these near-field communication materials include near-field communication tags and / or near-field communication components, or they can be near-field communication materials that establish a wireless or broadcast connection with the ticket verification device.

[0076] In practice, during the ticket verification process, the ticket purchaser can bring their terminal close to the ticket verification device's components, or make close contact with the device's components. When the user's terminal is close to the device components, near-field communication can be established between the two. Based on the established near-field communication, the user terminal can obtain or read static links from the device components, or receive static links sent by the device components, and parse the static links to obtain the component identifier and the verification service link.

[0077] Here, the component identifier refers to the unique identifier of the device component. For example, the component identifier can be the tag number of the near-field communication tag or the component number of the near-field communication component; the component identifier can also be the material identifier of the near-field communication material; optionally, the component identifier includes the tag identifier of the near-field communication tag or the component identifier of the near-field communication component. In addition, when the device component is a near-field communication component or near-field communication tag built into the ticket verification device, the component identifier can also be replaced with the device identifier of the ticket verification device.

[0078] Static links refer to links stored in device components. Specifically, the component identifier field of the device component can be configured in the static link, as can the identity verification broadcast identifier field. The identity verification broadcast identifier is an identifier used to determine whether broadcast communication is used during the ticket identity verification process, specifically whether the user terminal uses broadcast communication to broadcast data to the ticket identity verification device. Optionally, the component identifier and / or identity verification broadcast identifier can be configured in the static link. The component identifier and / or identity verification broadcast identifier can be configured in the coded links included in the static link.

[0079] In addition, static links can also be links adapted to near-field communication materials, or fixed links adapted to the communication protocol of near-field communication materials. For example, static links can use the prefix alipay: / / nfc / app, and can further transmit information more securely through the three parameters id, t, and v in the link. Here, id can be the material number of the near-field communication material or other information, t can be a random value for timeliness, and v represents the encoded link after the service link is encoded. The encoded link is configured with the encoded field "deviceNo%253Ddm888888" corresponding to the material identifier of the near-field communication material and the encoded field "ble%253Dy" corresponding to the identity broadcast identifier.

[0080] The identity verification service link refers to the service link or access link used to access the identity verification service on a user terminal. It can be obtained by parsing a static link, specifically by decoding the encoded link contained in the static link. When the encoded link contained in the static link is configured with a component identifier and / or an identity verification broadcast identifier, decoding the encoded link contained in the static link can obtain the component identifier and / or the identity verification broadcast identifier. Specifically, decoding the encoded link contained in the static link can obtain the identity verification service link containing the component identifier and / or the identity verification broadcast identifier.

[0081] For example, if the encoded link configuration component identifier has the encoded field "deviceNo%253Ddm888888" and the identity broadcast identifier has the encoded field "ble%253Dy", then decoding the encoded link to obtain the service link will contain the fields "deviceNo=dm888888" and "ble=y", where dm888888 is the material identifier of the near-field communication material and y represents the identity broadcast identifier.

[0082] In the specific execution process, when the user terminal obtains the static links stored by the device component, it can be that the user terminal sends a link request or request field to the device component, and after receiving the link request or request field, the device component sends the static links stored by itself to the user terminal; it can also be that after the user terminal establishes near-field communication with the device component, the device component sends the static links stored by itself to the user terminal; or it can also be that after the user terminal establishes near-field communication with the device component, the user terminal reads the static links from the device component. Accordingly, after the user terminal receives or reads the static link, it parses the static link to obtain the identity verification service link. Specifically, it can decode the encoded link contained in the static link to obtain the identity verification service link. The identity verification service link contains the component identifier and / or the identity verification broadcast identifier, so the component identifier and / or the identity verification broadcast identifier can be obtained from the identity verification service link.

[0083] In this embodiment, the ticketing service provider can be configured with a corresponding ticketing verification scheme. The ticketing verification scheme refers to the specific verification scheme or strategy used when verifying the identity of a ticket purchaser. Optionally, static links are generated after the ticketing verification scheme is configured. The verification configuration includes verification link configuration and / or verification identity type configuration. Among these, the identity verification link configuration refers to configuring the identity verification link used in the ticketing identity verification process; optionally, the identity verification link includes a broadcast identity verification link / or a network identity verification link; the identity verification type configuration refers to configuring which identity type the ticket-purchasing user uses for ticketing identity verification during the ticketing identity verification process. The identity verification type can be an application identity type using an application account for verification, a communication identity type using a communication number for verification, and / or a credential identity type using identity credentials for verification. The identity verification broadcast identifier can be determined according to the identity verification link configured in the ticketing identity verification scheme.

[0084] For example, for a ticket verification scheme configured for a ticketing service provider's ticketing project, a verification link is configured to perform ticket verification processing based on broadcast communication. This verification link can be called a broadcast verification link. When the ticket verification scheme is configured with a broadcast verification link, the encoded link in the static link stored in the device component is configured with the field "ble=y", where "y" indicates that the broadcast verification link is configured, and the broadcast verification link can be used for ticket verification processing in the future. Conversely, if the ticket verification scheme is not configured with a broadcast verification link, the "y" in the encoded link "ble=y" field can be configured as "n" or empty.

[0085] In practical applications, during the configuration of the ticket verification scheme, verification configuration can be performed after establishing near-field communication between the configuration personnel's configuration terminal and the device component; static links can be written to the device component through the configuration terminal and stored by the device component; optionally, the component identifier can be read after the configuration personnel's configuration terminal establishes near-field communication with the device component; furthermore, the component identifier can be associated with the ticket verification scheme after verification configuration; subsequently, when querying or retrieving the ticket verification scheme during the ticket verification process, the associated ticket verification scheme can be queried or retrieved based on the component identifier.

[0086] In the specific execution process, after the configuration personnel enter the service program or the ticketing service provider's subprogram through the configuration terminal, the ticket verification scheme is configured through the service program or the ticketing service provider's subprogram. Specifically, during the verification configuration process, the configuration personnel read the component identifier of the ticketing verification device's device component through the configuration terminal. Based on the read component identifier, the service program or the ticketing service provider's subprogram generates a static link based on the component identifier, and the configuration personnel write the static link into the device component of the ticketing verification device for storage through the configuration terminal.

[0087] It should be noted that in actual scenarios, during the ticket verification process at offline venues, there may be situations where the network is poor or even offline. For example, the network may be poor or unstable due to the large number of ticket buyers attending the concert. There may also be situations where the network is good. Ticketing service providers can configure the corresponding verification links according to the actual needs of the scenario, combined with the network conditions or actual operation. For example, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can configure a broadcast verification link for their ticket verification solutions to improve the success rate of ticket verification. In this case, during the ticket verification process through the user's terminal, the user terminal may be offline or in a network abnormal state. Optionally, the user terminal may be offline or in a network abnormal state. Network abnormal states include weak network conditions, unstable network conditions, and / or network redundancy caused by too many accesses. In addition, the user terminal may also be in a normal network state, in which case a broadcast verification link can also be used for ticket verification. For example, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can improve the success rate of ticket verification and reduce the processing response time for ticket buyers. They can configure both broadcast verification links and network verification links simultaneously for the ticket verification solution, allowing both to execute in parallel to increase the success rate. In this scenario, the user terminal may be offline, experiencing network anomalies, or in a normal or good network state. In the case of a normal or good network state, both broadcast and network verification links are used for ticket verification. For example, ticketing service providers can configure network verification links for ticket verification solutions when the network is stable and in good condition, i.e., when the user terminal is in a normal network state. This can avoid deploying edge servers in offline locations, thereby saving costs.

[0088] In practice, after parsing the static links read from the device components to obtain the component identifier and the authentication service link, the service program is accessed based on the authentication service link. The service program then checks whether the authentication service link carries an authentication broadcast identifier. If so, it indicates that the current ticket authentication process requires the use of a broadcast authentication link for ticket authentication. In this case, the component identifier and the user identifier of the ticket purchaser are encoded and transformed to obtain an encoded field. If not, it indicates that the current ticket authentication process does not require the use of a broadcast authentication link for ticket authentication. The service program can be a ticket verification program provided by the service provider to the ticket service provider, or it can be a ticket verification program that works with the server to perform ticket verification. Specifically, the service program can be a service subroutine that runs within the host application installed on the user terminal to perform ticket verification, or an application that performs ticket verification installed on the user terminal. In addition, the service program can also be a service subroutine or application that works with the service provider to perform ticket verification.

[0089] In addition, if the identity verification service link does not carry an identity verification broadcast identifier, a network identity verification link can be used for ticket identity verification. The following sections will explain in detail the process of using a broadcast identity verification link and the process of using a network identity verification link for ticket identity verification.

[0090] (1) Ticket verification is performed using a broadcast verification link. If the detection result of whether the identity verification service link carries the identity verification broadcast identifier is yes, it indicates that the current ticketing identity verification process needs to use the broadcast identity verification link for ticketing identity verification processing. That is, the current ticketing identity verification scheme is configured with the broadcast identity verification link. In this case, during the ticketing identity verification process using the broadcast identity verification link, the component identifier and the user identifier of the ticket purchaser are first encoded and transformed to obtain the encoded field. Then, the following step S206 is executed to broadcast the encoded field to the ticketing identity verification device so that the ticketing identity verification device can cooperate with the edge server to collect the identity verification image and call the ticketing identity verification interface of the server to perform ticketing verification processing and identity verification processing. In one optional implementation of this embodiment, the ticket verification process is carried out using a broadcast verification link, including: encoding and transforming the component identifier and the user identifier of the ticket purchaser to obtain an encoded field and broadcasting the encoded field to the ticket verification device, so that the ticket verification device and the edge server can cooperate to collect the verification image, and call the ticket verification interface of the server to perform ticket verification and identity verification processing.

[0091] As mentioned above, to avoid slow or impossible ticket verification processing due to poor network conditions or even network outages, ticketing service providers can improve the success rate of ticket verification and reduce the processing response time for ticket buyers. This can be achieved by configuring both broadcast verification and network verification links simultaneously. Furthermore, if the detection result for whether the verification service link carries a broadcast verification identifier is yes, in addition to executing the ticket verification process using the network verification link, the process can also be executed asynchronously or in parallel.

[0092] In practice, when using a broadcast verification link for ticket verification, to prevent data leakage during the broadcast process from the user terminal to the ticket verification device, the component identifier and the user identifier of the ticket purchaser are encoded to obtain an encoded field. This encoded field is then broadcast to the ticket verification device to prevent data leakage. Specifically, the encoding transformation of the component identifier and the user identifier can be performed using an obfuscation algorithm to obtain an obfuscated encoded field. For example, the component identifier and the user identifier can be rearranged using an obfuscation algorithm to obtain an encoded string. After the encoded string is broadcast to the ticket verification device, the ticket verification device parses the encoded string to obtain the component identifier and the user identifier.

[0093] In this embodiment, when the user terminal broadcasts an encoded field to the ticket verification device, it can do so by calling a wireless component or broadcast component configured on the user terminal. Specifically, the wireless component or broadcast component can be a Bluetooth component, a Wi-Fi component, or a UWB (Ultra Wide Band) component, or other wireless communication components capable of broadcasting encoded fields to the ticket verification device, such as an infrared communication component. Correspondingly, the ticket verification device is also configured with a wireless component or broadcast receiving component corresponding to the user terminal to receive the encoded field broadcast by the user terminal. It should be noted that, in addition to the above-mentioned implementation of broadcasting the encoded field to the ticket verification device, the user terminal can also broadcast the encoded field to the device component of the ticket verification device, and the device component will transmit the encoded field to the ticket verification device. In this case, the device component is configured with a wireless component, and the above-mentioned broadcasting of the encoded field to the ticket verification device can be replaced by broadcasting the encoded field to the device component of the ticket verification device.

[0094] (2) Use online identity verification link for ticket verification processing During the online identity verification process, the system can detect whether the user terminal's network status is a preset network status. If so, it queries the ticketing identity verification scheme associated with the component identifier. If the ticketing identity verification scheme includes an online identity verification link, it submits the user identifier to the server to be sent to the edge server through the server. Alternatively, it can also detect whether the user terminal's network status is a preset network status. If so, it submits the user identifier to the server to be sent to the edge server through the server. Or, it can also submit the user identifier to the server to be sent to the edge server through the server. Or, it can also query the ticketing identity verification scheme associated with the component identifier. If the ticketing identity verification scheme includes an online identity verification link, it submits the user identifier to the server to be sent to the edge server through the server. Based on this, after receiving the user identifier, the edge server cooperates with the ticket verification device to collect the verification image and calls the ticket verification interface on the server to perform ticket verification and identity verification. In the specific execution process, after receiving the user identifier, the edge server can cooperate with the ticket verification device bound to the component identifier to collect the verification image and call the ticket verification interface to send the user identifier and the collected verification image to the server for ticket verification and identity verification.

[0095] In one optional implementation method provided in this embodiment, a network-based identity verification link is used for ticket identity verification, including any one of the following four implementation methods: The system checks whether the user terminal's network status is the preset network status. If so, it queries the ticket verification scheme associated with the component identifier. If the ticket verification scheme includes a network verification link, it submits the user identifier to the server to send it to the edge server, so that the edge server and the ticket verification device can cooperate to collect the verification image. The system then calls the server's ticket verification interface to perform ticket verification processing. Ticket verification processing includes ticket verification processing and / or identity verification processing. The system checks whether the user terminal's network status is the preset network status. If so, it submits the user identifier to the server so that the server can send it to the edge server, enabling the edge server to cooperate with the ticket verification device to collect the verification image and call the server's ticket verification interface to perform ticket verification processing. Query the ticket verification scheme associated with the component identifier. If the ticket verification scheme includes a network verification link, submit the user identifier to the server so that it can be sent to the edge server through the server. This enables the edge server to cooperate with the ticket verification device to collect the verification image and call the ticket verification interface of the server to perform ticket verification processing. Submit the user identifier to the server so that it can be sent to the edge server, enabling the edge server to cooperate with the ticket verification device to collect the verification image and call the server's ticket verification interface to perform ticket verification processing.

[0096] It should be noted that the preset network state in any of the above implementation methods can be a normal network state, that is, the corresponding ticket verification operation of the subsequent network verification link is executed when the network state of the user terminal is detected to be normal; similarly, the preset network state in any of the above implementation methods can also be a network abnormal state, that is, the corresponding ticket verification operation of the subsequent network verification link is executed only when the network state of the user terminal is detected to be abnormal. Alternatively, the preset network state in any of the above implementation methods can be a normal network state or an abnormal network state, that is: when the network state of the user terminal is detected to be either a normal network state or an abnormal network state, the corresponding ticket verification processing operation of the subsequent network verification link is executed. In addition, the preset network state in any of the above implementation methods can also be any two or three of the network states, depending on the actual scenario. For example, the preset network state can also be offline or network normal.

[0097] As mentioned above, when both broadcast verification link and network verification link are provided for ticket verification processing, obtaining the user identifier sent by the edge server of the ticketing service provider calling the ticket verification interface and the verification image collected by the ticket verification device can be either obtaining the user identifier and verification image sent during the ticket verification process using the broadcast verification link or obtaining the user identifier and verification image sent during the ticket verification process using the network verification link. In the process of ticket verification using broadcast verification link, the verification image can be collected after the ticket verification device receives the encoded field broadcast by the user terminal. The encoded field can be obtained by link parsing and encoding transformation based on the static link read from the device component. In the process of ticket verification using a network-based verification link, the verification image can be collected by the edge server in cooperation with the ticket verification device after receiving the user identifier submitted by the user terminal or service program; the user terminal or service program can submit the user identifier if it detects that the network status of the user terminal is a preset network status, or the user terminal or service program can also submit the user identifier if it detects that the network status of the user terminal is a preset network status and the ticket verification scheme associated with the component identifier includes a network-based verification link.

[0098] In this embodiment, based on the user identifier and verification image sent by the edge server calling the ticket verification interface using a broadcast verification link, in order to reduce the processing response time for ticket purchasers during the ticket verification process, a network verification link can also be used simultaneously for ticket verification. To this end, in an optional implementation of this embodiment, before obtaining the user identifier sent by the edge server of the ticket service provider calling the ticket verification interface and the verification image collected by the ticket verification device, the method further includes: receiving the user identifier submitted by the user terminal and sending the user identifier submitted by the user terminal to the edge server; wherein the user identifier is submitted when the network state of the user terminal is a preset network state, and / or when the ticket verification scheme associated with the component identifier of the device component includes a network verification link.

[0099] In this embodiment, regardless of whether a broadcast verification link, a network verification link, or both are used in parallel for ticket verification, the edge server, upon receiving the user identifier, will cooperate with the ticket verification device to collect a verification image and call the server's ticket verification interface to perform ticket verification and identity verification. In this embodiment, the process of the edge server cooperating with the ticket verification device to collect a verification image is the same as the process of the ticket verification device cooperating with the edge server to collect a verification image. Therefore, the process of the edge server cooperating with the ticket verification device to collect a verification image can be interchanged with the process of the ticket verification device cooperating with the edge server to collect a verification image.

[0100] It should be noted that during the parallel use of broadcast verification link and network verification link for ticket verification processing, since there is no need to repeat the ticket verification and identity verification processes twice for the current ticket purchaser, in order to complete the ticket verification process faster and reduce the processing response time for ticket purchasers, the edge server will only process the user identifiers sent by the broadcast verification link and the network verification link respectively. The user identifiers received later will not be processed. That is, the process of ticket verification device and edge server (or edge server and ticket verification device) cooperating to collect verification images and call the server's ticket verification interface to perform ticket verification and identity verification processes will not be performed for the user identifiers received later. In one optional implementation of this embodiment, after receiving a user identifier sent by either the ticketing verification device or the server, the edge server performs the following operations: the ticketing verification device bound to the component identifier cooperates to collect a verification image, and calls the ticketing verification interface to send the received user identifier and the collected verification image to the server.

[0101] Here, if the received user identifier is not processed—that is, if the process of the ticket verification device and the edge server (or the edge server and the ticket verification device) cooperating to collect the verification image and calling the server's ticket verification interface for ticket verification and identity verification is not performed on the received user identifier—then in any of the above-mentioned implementations using a broadcast verification link for ticket verification, the process of the ticket verification device and the edge server cooperating to collect the verification image and calling the server's ticket verification interface for ticket verification and identity verification can be deleted. Alternatively, the process of the edge server and the ticket verification device cooperating to collect verification images and calling the server's ticket verification interface to perform ticket verification and identity verification can be deleted or not executed in any of the above-mentioned implementation methods for ticket verification processing using a network verification link. That is, in the process of ticket verification processing for a single ticket purchaser, the process of the ticket verification device and the edge server (or the edge server and the ticket verification device cooperating to collect verification images and calling the server's ticket verification interface to perform ticket verification and identity verification is executed only once.

[0102] It should be noted that, in the process of ticket verification using a network-based verification link, the edge server that cooperates with the ticket verification device and interacts with the server can be replaced by a ticket server; or, a ticket server can be added to the edge server, with the ticket server responsible for interacting with the server and communicating with the edge server, and the edge server responsible for cooperating with the ticket verification device and communicating with the ticket server; similarly, in the process of ticket verification using a broadcast verification link, a ticket server can also be added to the edge server, with the ticket server responsible for interacting with the server and communicating with the edge server, and the edge server responsible for cooperating with the ticket verification device and communicating with the ticket server. In the specific execution process, after the user terminal submits the user identifier to the server, or after the service program submits the user identifier to the server, the server can send the user identifier to the ticketing server. After receiving the user identifier, the ticketing server calls the edge server to cooperate with the ticketing verification device to collect the verification image (or, the ticketing server sends an image collection instruction to the edge server, and the edge server cooperates with the ticketing verification device to collect the verification image according to the image collection instruction). After collecting the verification image, the ticketing verification interface is called to send the received user identifier and the collected verification image to the server.

[0103] Step S404: Query the ticket entry records based on the user identifier, ticket item information, and identity verification scheme type.

[0104] After obtaining the user identifier and verification image sent by the edge server through the ticket verification interface, the system can query ticket entry records based on the user identifier, ticket item information, and / or verification scheme type. In addition, before querying ticket entry records based on the user identifier, ticket item information, and / or verification scheme type, the system can verify the user's identity information corresponding to the user identifier. After the identity verification is successful, the system can query ticket entry records based on the user identifier, ticket item information, and / or verification scheme type.

[0105] The user identifier can be either the user program identifier of the ticket purchaser within the service program or the user application identifier of the host application within the service program. The service program obtains the user application identifier of the ticket purchaser from the host application. User identity information refers to identity-related information required to verify the authenticity of the ticket purchaser's identity. For example, the user identity information used for real-name verification of the ticket purchaser could be the credential information of the ticket purchaser's identity certificate.

[0106] In this embodiment, after a ticket purchaser makes a purchase through a ticketing service provider, the ticket purchaser's ticketing record will be stored in the database. Specifically, during the storage process, the ticketing service provider can send a ticket storage request or ticket storage information to the server. After receiving the ticket storage request or ticket storage information, the server will query the application account based on the identity field contained in the ticket storage request or ticket storage information. The server will then create a ticket storage record based on the queried application account and identity field and store it in the database. Alternatively, the server can create a ticket storage record based on the queried application account and the ticketing field contained in the ticket storage request or ticket storage information and store it in the database. In addition, after receiving a ticket entry request or ticket entry information, the server can also query whether a corresponding ticket verification scheme exists based on the ticket fields contained in the ticket entry request or ticket entry information. After finding a ticket verification scheme, the server can query the application account based on the identity field in the ticket fields, create a ticket entry record based on the queried application account and identity field, and perform entry storage processing. Alternatively, the server can also create a ticket entry record based on the queried application account and ticket fields and perform entry storage processing.

[0107] Here, the ticket entry request or ticket entry information contains at least one of the following fields: the project identifier of the ticket project, the link type of the verification link configured in the ticket verification scheme of the ticket project, the service provider identifier of the ticket service provider, the ticket application identifier of the ticket application of the ticket service provider on which the ticket purchaser made the purchase, the credential identifier (or encrypted credential identifier) ​​of the ticket purchaser's identity credential, the communication number (or encrypted communication number) of the ticket purchaser, and the ticket credential code (or encrypted ticket credential code) of the ticket purchased by the ticket purchaser. Correspondingly, the ticketing fields included in the ticketing entry request or ticketing entry information can consist of one or more fields included in the ticketing entry request or ticketing entry information. For example, the ticketing fields can consist of at least one of the following four fields: project identifier, service provider identifier, ticketing application identifier, and link type. The identity field can be a credential identifier, communication number, or ticketing credential code, or it can be a credential identifier, communication number, or ticketing credential code obtained after decrypting the encrypted credential identifier, encrypted communication number, or encrypted ticketing credential code. The application account can be the user program account (user program identifier) ​​of the ticket purchaser in the service program, or the application account can also be the user application account (user application identifier) ​​of the host application of the ticket purchaser in the service program.

[0108] In one optional implementation of this embodiment, the ticket entry record is generated in the following way: based on the ticket fields sent by the ticket service provider, a query is performed to see if a corresponding ticket verification scheme exists; if so, an application account is queried based on the identity field in the ticket fields, and a ticket entry record is created and stored based on the queried application account and ticket fields.

[0109] In practical applications, there may be situations where a ticket-purchasing user has registered multiple program accounts or application accounts in the service program or host application. To address this, in order to enable ticket-purchasing users to use any program account or application account for ticket verification, during the process of creating and storing ticket entry records based on the queried application account and ticket fields, ticket entry records can be stored separately for each program account or application account. This ensures that subsequent ticket-purchasing users can perform ticket verification by logging in with any program account or application account. In one optional implementation of this embodiment, a ticket entry record is created and stored based on the queried application account and ticketing field. This includes: if multiple application accounts are queried, a ticket entry record is created based on the queried application account and ticketing field, and the ticket entry record is written into the ticket entry list mapped to each application account in the ticketing database.

[0110] Furthermore, in practical applications, there may be situations where ticket buyers cancel their tickets after purchase. To address this, a ticket release process can be performed after the refund to delete the ticket entry record; that is, the ticket entry record is deleted after the ticket release process. In one optional implementation of this embodiment, the ticket release process includes: decrypting the encrypted release field carried in the ticket release request to obtain the ticket release field; querying the corresponding ticket entry record based on the ticket release field and performing the release deletion process. The ticket release request is generated after detecting a ticket buyer's refund operation.

[0111] Step S406: If a matching ticket entry record is found, perform identity verification processing based on the verification image to obtain the ticket verification result.

[0112] In practice, after querying ticket entry records based on user identifier, ticketing item information, and / or verification scheme type, if a matching ticket entry record is found, identity verification is performed based on the verification image to obtain the ticket verification result. Here, the obtained ticket verification result includes ticket verification passed or ticket verification failed. After obtaining the ticket verification result, the server can send the ticket verification result to the edge server, and the edge server can issue a verification access instruction to the ticket verification device bound to the component identifier based on the ticket verification result. The verification access instruction includes a verification pass instruction or a verification fail instruction.

[0113] The following example uses a ticket verification processing method provided in this embodiment to illustrate its application in a ticket project verification scenario. Figure 3 The ticket verification method provided in this embodiment will be further explained below. See [link to documentation]. Figure 3 The ticket verification processing method applied to ticketing project verification scenarios includes the following steps.

[0114] Step S320: Receive the user identifier submitted by the user terminal.

[0115] Step S322: Send the user identifier to the edge server deployed for the ticketing project.

[0116] Step S324: Receive the user identifier and verification image sent by the edge server via the ticket verification interface.

[0117] Step S326: Query ticket entry records based on user identifier, ticket item information, and identity verification scheme type.

[0118] Step S328: If a matching ticket entry record is found, perform identity verification processing based on the verification image to obtain the ticket verification result.

[0119] Step S330: Send the ticket verification result to the edge server.

[0120] After receiving the ticket verification result, the edge server sends a ticket processing instruction to the ticket verification device.

[0121] Steps S320 to S322 may be executed before step S324, or in parallel with step S324, or steps S320 to S322 may be omitted.

[0122] It should be noted that any one or more steps in steps S320 to S330 can be combined with any one or more steps in steps S402 to S406 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features in steps S320 to S330 can be selected and combined with any one or more technical features provided in steps S402 to S406 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps S320 to S330 can be replaced with any one or more technical features provided in steps S402 to S406 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0123] The following is an embodiment of a ticket verification device provided in this manual: In the above embodiments, a ticket verification processing method is provided, and correspondingly, a ticket verification processing device is also provided, which will be described below with reference to the accompanying drawings.

[0124] Reference Figure 5 This illustration shows a schematic diagram of an embodiment of a ticket verification processing device provided in this embodiment.

[0125] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0126] This embodiment provides a ticket verification processing device that operates on a user terminal. The device includes: Link resolution module 502 is configured to resolve static links read from the device components of the ticket verification device via near-field communication to obtain the component identifier and the verification service link; Access encoding module 504 is configured to access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, it performs encoding transformation on the component identifier and the user identifier of the ticket purchaser to obtain an encoding field. The field broadcasting module 506 is configured to broadcast the encoded field to the ticket verification device so that the ticket verification device can cooperate with the edge server to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification processing.

[0127] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0128] Another embodiment of the ticket verification processing device provided in this manual is as follows: In the above embodiments, another ticket verification method is provided, and correspondingly, another ticket verification device is also provided, which will be described below with reference to the accompanying drawings.

[0129] Reference Figure 6 This illustration shows a schematic diagram of an embodiment of a ticket verification processing device provided in this embodiment.

[0130] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0131] This embodiment provides a ticket verification processing device, which runs on a server. The device includes: The acquisition module 602 is configured to acquire the user identifier sent by the edge server of the ticketing service provider calling the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is acquired after the ticketing verification device receives the encoded field broadcast by the user terminal, and the encoded field is obtained by link parsing and encoding transformation based on the static link read from the device component; The record query module 604 is configured to query ticket entry records based on the user identifier, ticket item information and identity verification scheme type. The identity verification module 606 is configured to perform identity verification processing based on the identity verification image to obtain the ticket identity verification result if a matching ticket entry record is found.

[0132] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0133] The following is an example of a ticket verification processing device provided in this manual: Corresponding to the ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide a ticket verification device for executing the ticket verification method provided above. Figure 7 This is a schematic diagram of the structure of a ticket verification processing device provided for one or more embodiments of this specification.

[0134] This embodiment provides a ticket verification processing device, including: like Figure 7As shown, device 700 mainly consists of a communication interface 702, a user interface 704, a processor 706, and a data storage 708. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 710. Communication interface 702 enables device 700 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, communication interface 702 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, communication interface 702 can be a wired interface such as Ethernet, Token Ring, or USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or wide area wireless interface (e.g., WiMAX or LTE). Of course, communication interface 702 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. Communication interface 702 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide area wireless interfaces. User interface 704 includes receiving user input and providing output to the user. Therefore, user interface 704 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 704 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 704 may include software, circuitry, or other forms of logic capable of transmitting data to and receiving data from external user input / output devices. Additionally or alternatively, device 700 may support remote access from other devices via communication interface 702 or another physical interface (not shown). User interface 704 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 704 may also be configured as a display device for rendering or displaying text fragments.

[0135] Processor 706 may include one or more general-purpose processors and / or special-purpose processors. Data storage 708 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 706. Data storage 708 may include removable and non-removable components.

[0136] Processor 706 is capable of executing program instructions 718 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 708 to perform the various functions described herein. Data storage 708 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 700, enable device 700 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 718 by processor 706 may result in processor 706 using data 712. For example, program instructions 718 may include an operating system 722 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 700 and one or more application programs 720 (e.g., a browser, social application, or game application). Similarly, data 712 may include operating system data 716 and application data 714. Operating system data 716 is primarily accessible to operating system 722, while application data 714 is primarily accessible to one or more application programs 720. Application data 714 may reside in a file system visible or hidden from the user of device 700. Application 720 can communicate with operating system 722 through one or more application programming interfaces (APIs). These APIs facilitate application 720 in reading and / or writing application data 714, transmitting or receiving information via communication interface 702, and receiving or displaying information on user interface 704. In some terms, application 720 may be simply referred to as "app". Furthermore, application 720 can be downloaded to device 700 through one or more online app stores or app markets. However, applications can also be installed on device 700 in other ways, such as through a web browser or a physical interface on device 700 (e.g., a USB port).

[0137] In one specific embodiment, the ticket verification processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the ticket verification processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: The static links read from the device components of the ticket verification device via near-field communication are parsed to obtain the component identifier and the verification service link; Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field. The encoded field is broadcast to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification.

[0138] Another embodiment of the ticket verification processing device provided in this manual is as follows: Corresponding to the other ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide another ticket verification device, which is used to execute the other ticket verification method provided above. Figure 8 This is a schematic diagram of another ticket verification processing device provided in one or more embodiments of this specification.

[0139] This embodiment provides a ticket verification processing device, including: like Figure 8As shown, device 800 mainly consists of a communication interface 802, a user interface 804, a processor 806, and a data storage 808. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 810. The communication interface 802 enables device 800 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 802 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 802 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 802 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 802 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces. The user interface 804 includes receiving user input and providing output to the user. Therefore, user interface 804 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 804 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 804 may include software, circuitry, or other forms of logic capable of transmitting and receiving data to and from external user input / output devices. Additionally or alternatively, device 800 may support remote access from other devices via communication interface 802 or another physical interface (not shown). User interface 804 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 804 may also be configured as a display device for rendering or displaying text fragments.

[0140] Processor 806 may include one or more general-purpose processors and / or special-purpose processors. Data storage 808 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 806. Data storage 808 may include removable and non-removable components.

[0141] Processor 806 is capable of executing program instructions 818 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 808 to perform the various functions described herein. Data storage 808 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 800, enable device 800 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 818 by processor 806 may result in processor 806 using data 812. For example, program instructions 818 may include an operating system 822 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 800 and one or more application programs 820 (e.g., a browser, social application, or game application). Similarly, data 812 may include operating system data 816 and application data 814. Operating system data 816 is primarily accessible to operating system 822, while application data 814 is primarily accessible to one or more application programs 820. Application data 814 may reside in a file system visible or hidden from the user of device 800. Application 820 can communicate with operating system 822 through one or more application programming interfaces (APIs). These APIs facilitate application 820 in reading and / or writing application data 814, transmitting or receiving information via communication interface 802, and receiving or displaying information on user interface 804. In some terms, application 820 may be simply referred to as "app". Furthermore, application 820 can be downloaded to device 800 through one or more online application stores or app markets. However, applications can also be installed on device 800 in other ways, such as through a web browser or a physical interface on device 800 (e.g., a USB port).

[0142] In one specific embodiment, the ticket verification processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the ticket verification processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: The system obtains the user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal, and the encoded field is obtained by link parsing and encoding transformation based on the static link read from the device component; Based on the user identifier, ticketing item information, and identity verification scheme type, query the ticketing entry record; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

[0143] This specification provides an embodiment of a computer-readable storage medium as follows: Corresponding to the ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer-readable storage medium.

[0144] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, implement the following process: The static links read from the device components of the ticket verification device via near-field communication are parsed to obtain the component identifier and the verification service link; Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field. The encoded field is broadcast to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification.

[0145] It should be noted that the embodiments of a computer-readable storage medium described in this specification and the embodiments of a ticket verification processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0146] Another embodiment of a computer-readable storage medium provided in this specification is as follows: Corresponding to the other ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide another computer-readable storage medium.

[0147] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, implement the following process: The system obtains the user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal, and the encoded field is obtained by link parsing and encoding transformation based on the static link read from the device component; Based on the user identifier, ticketing item information, and identity verification scheme type, query the ticketing entry record; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

[0148] It should be noted that the embodiments of another computer-readable storage medium described in this specification and the embodiments of another ticket verification processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0149] This specification provides an example of a computer program product as follows: Corresponding to the ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer program product.

[0150] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: The static links read from the device components of the ticket verification device via near-field communication are parsed to obtain the component identifier and the verification service link; Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field. The encoded field is broadcast to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification.

[0151] It should be noted that the embodiments of a computer program product described in this specification and the embodiments of a ticket verification processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0152] Another example of a computer program product provided in this specification is as follows: Corresponding to the other ticket verification method described above, based on the same technical concept, one or more embodiments of this specification also provide another computer program product.

[0153] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: The system obtains the user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal, and the encoded field is obtained by link parsing and encoding transformation based on the static link read from the device component; Based on the user identifier, ticketing item information, and identity verification scheme type, query the ticketing entry record; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

[0154] It should be noted that the embodiments of another computer program product described in this specification and the embodiments of another ticket verification processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0155] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiment, equipment embodiment and computer-readable storage medium embodiment are all similar to the method embodiment, so the description is relatively simple. When reading the relevant content of the device embodiment, equipment embodiment and computer-readable storage medium embodiment, please refer to the description of the method embodiment.

[0156] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps, and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims. This specification uses specific terms to describe embodiments of this specification. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0157] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0158] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0159] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0160] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0161] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

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

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

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

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

[0166] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0167] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0168] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0169] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising at least one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0170] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0171] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A ticket verification processing method, applied to a user terminal, characterized in that, The method includes: The static link read from the device component of the ticket verification device via near-field communication is parsed to obtain the component identifier and the verification service link; the verification service link is obtained by decoding the encoded link contained in the static link, and the verification service link contains the component identifier and / or the verification broadcast identifier; Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field. The encoded field is broadcast to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification.

2. The ticket verification method according to claim 1, characterized in that, After the operation of encoding and transforming the component identifier and the ticket-purchasing user's user identifier to obtain the encoded field is performed, the method further includes: Detect whether the network status of the user terminal is a preset network status. If so, query the ticket verification scheme associated with the component identifier. If the ticketing verification scheme includes an online verification link, the user identifier is submitted to the server to be sent to the edge server through the server.

3. The ticket verification method according to claim 2, characterized in that, After receiving a user identifier from either the ticket verification device or the server, the edge server performs the following operations: The ticket verification device, which is bound to the component identifier, collects the verification image and calls the ticket verification interface to send the received user identifier and the collected verification image to the server.

4. The ticket verification method according to claim 1, characterized in that, The ticket verification and identity verification processes include: Obtain the user identifier and the verification image sent by the edge server when calling the ticket verification interface, and query the ticket entry record based on the user identifier, ticket item information and verification scheme type; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

5. The ticket verification method according to claim 4, characterized in that, The ticket entry records are generated in the following manner: Based on the ticketing fields sent by the ticketing service provider, query whether there is a corresponding ticket verification solution; If so, query the application account based on the identity field in the ticketing field, create a ticket entry record based on the queried application account and the ticketing field, and perform entry storage processing.

6. The ticket verification method according to claim 5, characterized in that, The ticket entry record is deleted after the ticket exit process is performed; The ticketing outbound processing includes: decrypting the encrypted outbound field carried in the ticketing outbound request to obtain the ticketing outbound field; querying the corresponding ticketing inbound record based on the ticketing outbound field and performing outbound deletion processing.

7. The ticket verification method according to claim 1, characterized in that, The static link is generated after the ticket verification scheme is configured, and the verification configuration includes verification link configuration and verification identity type configuration. The identity verification service link includes an identity verification broadcast identifier, which is determined based on the identity verification link configured in the ticketing identity verification scheme.

8. The ticket verification method according to claim 7, characterized in that, The component identifier is read after the configuration terminal of the configuration personnel conducts near-field communication with the device component, and is associated with the ticketing verification scheme after the verification configuration; The static link is written to the device component via the configuration terminal.

9. The ticket verification method according to claim 8, characterized in that, The device components include: an external near-field communication tag or a built-in near-field communication component of the ticket verification device; the component identifier includes the tag identifier of the near-field communication tag or the component identifier of the near-field communication component.

10. The ticket verification method according to any one of claims 4 to 9, characterized in that, The user terminal is either offline or experiencing a network anomaly; the network anomaly includes a weak network condition.

11. A ticket verification processing method, applied to a server, characterized in that, The method includes: The system acquires the user identifier sent by the ticketing service provider's edge server via the ticketing verification interface and the verification image collected by the ticketing verification device. The verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal. The encoded field is obtained by encoding the component identifier and the user identifier after parsing the static link read from the device component to obtain the component identifier and the verification service link. If the service program is accessed based on the verification service link and the verification broadcast identifier is detected in the verification service link, the component identifier and the user identifier are encoded and transformed. The verification service link is obtained by decoding the encoded link contained in the static link. The verification service link contains the component identifier and / or the verification broadcast identifier. Based on the user identifier, ticketing item information, and identity verification scheme type, query the ticketing entry record; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

12. The ticket verification method according to claim 11, characterized in that, The method further includes: Receive the user identifier submitted by the user terminal and send the user identifier submitted by the user terminal to the edge server; The user identifier submitted by the user terminal is submitted when the network status of the user terminal is a preset network status and the ticket verification scheme associated with the component identifier of the device component includes a network verification link.

13. The ticket verification method according to claim 12, characterized in that, After receiving the user identifier sent by either the ticket verification device or the server, the edge server performs the following operations: The ticket verification device, which is bound to the component identifier, collects the verification image and calls the ticket verification interface to send the received user identifier and the collected verification image to the server.

14. The ticket verification method according to claim 12, characterized in that, The static link is generated after the ticket verification scheme is configured. The verification configuration includes verification link configuration and verification identity type configuration.

15. The ticket verification method according to claim 14, characterized in that, The component identifier is read after the configuration terminal of the configuration personnel conducts near-field communication with the device component, and is associated with the ticketing verification scheme after the verification configuration; The static link is written to the device component via the configuration terminal.

16. A ticket verification processing device, operating on a user terminal, characterized in that, The device includes: The link parsing module is configured to parse static links read from the device components of the ticketing verification device via near-field communication to obtain a component identifier and a verification service link; the verification service link is obtained by decoding the encoded link contained in the static link, and the verification service link contains a component identifier and / or a verification broadcast identifier; The access encoding module is configured to access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, the component identifier and the user identifier of the ticket purchaser are encoded and transformed to obtain an encoding field. The field broadcasting module is configured to broadcast the encoded field to the ticket verification device so that the ticket verification device can cooperate with the edge server to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification processing.

17. A ticket verification processing device, operating on a server, characterized in that, The device includes: The acquisition module is configured to acquire the user identifier sent by the ticketing service provider's edge server calling the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal; the encoded field is obtained by encoding the component identifier and the user identifier after parsing the static link read from the device component to obtain the component identifier and the verification service link, and if the service program is accessed based on the verification service link and the verification broadcast identifier is detected in the verification service link; the verification service link is obtained by decoding the encoded link contained in the static link, and the verification service link contains the component identifier and / or the verification broadcast identifier; The record query module is configured to query ticket entry records based on the user identifier, ticket item information, and identity verification scheme type. The identity verification module is configured to perform identity verification processing based on the identity verification image to obtain the ticket identity verification result if a matching ticket entry record is found.

18. A ticket verification processing device, characterized in that, include: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: The static link read from the device component of the ticket verification device via near-field communication is parsed to obtain the component identifier and the verification service link; the verification service link is obtained by decoding the encoded link contained in the static link, and the verification service link contains the component identifier and / or the verification broadcast identifier; Access the service program based on the identity verification service link, and detect whether the identity verification service link carries an identity verification broadcast identifier. If so, encode the component identifier and the user identifier of the ticket purchaser to obtain an encoded field. The encoded field is broadcast to the ticket verification device so that the ticket verification device and the edge server can cooperate to collect the verification image and call the ticket verification interface of the server to perform ticket verification and identity verification.

19. A ticket verification processing device, characterized in that, include: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: The system obtains the user identifier sent by the ticketing service provider's edge server via the ticketing verification interface and the verification image collected by the ticketing verification device; the verification image is collected after the ticketing verification device receives the encoded field broadcast by the user terminal. The encoded field is obtained by encoding the component identifier and the user identifier after parsing the static link read from the device component to obtain the component identifier and the authentication service link, and when the service program is accessed based on the authentication service link and the authentication broadcast identifier is detected in the authentication service link; the authentication service link is obtained by decoding the encoded link contained in the static link, and the authentication service link contains the component identifier and / or the authentication broadcast identifier; Based on the user identifier, ticketing item information, and identity verification scheme type, query the ticketing entry record; If a matching ticket entry record is found, the identity verification process is performed based on the verification image to obtain the ticket verification result.

20. A computer-readable storage medium for storing computer-executable instructions, characterized in that, When executed, the computer-executable instructions perform the steps of the method of claim 1 or claim 11.

Images