Verification method, system, electronic device, and storage medium

Abstract

A verification method, a system, an electronic device, and a storage medium. The method comprises: a first terminal device receives a first message sent by a second terminal device; the first terminal device sends a second message to the second terminal device, the second message comprising identity information of the first terminal device; and the second terminal device verifies the second message by means of a second server, and determines, on the basis of the verification result, whether to execute a first operation. A user can implement permission verification only by means of information interaction between the first terminal device and the second terminal device, without executing other pre-operations, thereby improving the verification efficiency.

Description

A verification method, system, electronic device, and storage medium

[0001] This application claims priority to Chinese Patent Application No. 202410704489.4, filed on May 31, 2024, entitled "A verification method, system, electronic device and storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of wireless communication, specifically to a verification method, system, electronic device, and storage medium. Background Technology

[0003] In modern access control systems, the automation and intelligence of ticket purchase and verification processes have greatly improved passenger travel efficiency and experience. Taking high-speed rail station entry as an example, passengers can purchase tickets through online platforms or automatic ticket vending machines at the station. When entering the station, passengers can use their ID card or ticket for verification at the automatic ticket gate, or scan the QR code on their electronic ticket on their mobile phone at the gate to pass through the gate channel.

[0004] However, in the aforementioned verification system, users need to go through multiple steps during ticket verification, such as opening the application (APP) and opening the verification QR code from the APP. For users unfamiliar with the operation, this may take a long time to complete the cumbersome process, thus reducing operational efficiency and potentially causing congestion during peak hours. Summary of the Invention

[0005] The purpose of this application is to provide a verification method, system, electronic device, and storage medium.

[0006] In a first aspect, this application provides a verification method applied to a first terminal device, comprising: receiving a first message sent by a second terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; sending a second message to the second terminal device, wherein the second message includes an identity identifier, the identity identifier representing the identity information of the first terminal device, the second message being used to instruct the second terminal device to determine the verification result of the identity identifier through a second server, and determining whether to perform a first operation on the second terminal device based on the verification result.

[0007] In this embodiment, the first terminal device can be an electronic device such as a mobile phone, and the second terminal device can be a gate device, access control device, or access control device. The identity identifier can be used to distinguish and confirm the user's identity. The second server can be the backend server of the second terminal device. Optionally, the second terminal device can upload its identity identifier to the second server, and the second server can determine whether the verification result is passed or failed based on the identity identifier, and then return the verification result to the second terminal device. The first operation can be a passage operation, such as opening a gate.

[0008] The verification method of this application embodiment only requires information exchange between the first terminal device and the second terminal device to achieve permission verification. Users do not need to perform any other pre-processing, thus improving verification efficiency. Furthermore, the verification method relying on identity identifiers is relatively reliable, and the use of identifiable identity information can avoid user data confidentiality issues, thus enabling its application in scenarios where the first and second terminal devices belong to different service providers.

[0009] In one possible implementation of the first aspect above, the identity identifier includes a first identity identifier, which represents the identity information of the first terminal device in the second server.

[0010] In this embodiment, the first identity identifier can be used to confirm the user's identity on the second server. It is understood that the second server can be the backend server of the second terminal device. For example, the second terminal device is an IoT device, and the second server is the IoT device's backend system. By sending the first identity identifier to the second terminal device, the second terminal device can efficiently verify user permissions on its own side.

[0011] In one possible implementation of the first aspect described above, the identity identifier further includes a second identity identifier, which represents the identity information of the first terminal device in the first application provided by the second server.

[0012] In this embodiment, the second identity identifier can be used to confirm the user's identity in the first application provided by the second server. It is understood that the first application can be one of the applications provided by the second server, such as a mini-program or an app. By sending the second identity identifier to the second terminal device, the second terminal device can efficiently verify the user's permissions in the first application, such as verifying ticket purchase information purchased by the user based on the first application.

[0013] In one possible implementation of the first aspect above, the first message includes a service identifier, which represents the service provider information of the second terminal device, and the method further includes: sending a third message to a first server, wherein the third message includes an account identifier and a service identifier, the account identifier representing the identity information of the first terminal device in the first server; and receiving an identity identifier sent by the first server, wherein the identity identifier is determined by the first server based on the account identifier and the service identifier.

[0014] In this embodiment, the first server can determine the identity identifier based on the account identifier and service identifier, and return the identity identifier to the first terminal device. By having the first server determine the identity identifier based on the account identifier and service identifier, the storage and computing power requirements of the first terminal device can be reduced, and the efficiency and accuracy of identity identifier determination can be improved.

[0015] In one possible implementation of the first aspect described above, the service identifier is the device identifier of the second terminal device.

[0016] In this embodiment of the application, the second terminal device can send its own device identifier to the first terminal device. The device identifier can indicate the provider of the second terminal device, so that the first terminal device or the first server can determine the provider of the second terminal device based on the device identifier, and then map out the identity identifier.

[0017] In one possible implementation of the first aspect above, the identity identifier includes a first identity identifier, a first mapping relationship is stored in the first server, the first mapping relationship includes a correspondence between a second server and a service identifier, and the first server is used to determine the second server corresponding to the service identifier based on the first mapping relationship, and to determine the first identity identifier based on the second server and the account identifier.

[0018] In this embodiment, the first server can be used to store and manage a first mapping relationship, which includes the correspondence between the second server and the service identifier. Accordingly, the first server can manage multiple third-party servers, each corresponding to a service identifier, thus enabling access from multiple equipment vendors and efficient management of the mapping relationship between various equipment vendors and service identifiers.

[0019] In one possible implementation of the first aspect above, the identity identifier includes a second identity identifier, the first server stores a second mapping relationship, the second mapping relationship includes the correspondence between the first application and the service identifier provided by the second server, and the first server is used to determine the first application corresponding to the service identifier based on the second mapping relationship, and to determine the second identity identifier based on the first application and the account identifier.

[0020] In this embodiment, the first server can be used to store and manage the second mapping relationship, which includes the correspondence between the first application and service identifier of the second server. Accordingly, the first server can manage multiple applications, each corresponding to a service identifier, thus enabling access for multiple applications and efficient management of the mapping relationship between the various applications and service identifiers.

[0021] In one possible implementation of the first aspect above, the method further includes: sending a fourth message to a first server, wherein the fourth message includes an account identifier, the account identifier representing the identity message of the first terminal device in the first server; and receiving an identity identifier sent by the first server, wherein the identity identifier is determined by the first server based on the account identifier.

[0022] In this embodiment, the first server can determine the identity identifier based on the account identifier. In this embodiment, the first server connects to only one third-party equipment vendor, and the first server can efficiently determine the identity identifier corresponding to the account identifier based on the mapping relationship between the account identifier and the identity identifier.

[0023] In one possible implementation of the first aspect above, the first message includes a service identifier, which represents the service provider information of the second terminal device. The first terminal device stores a third mapping relationship, which includes the correspondence between the service identifier and the identity identifier. The method further includes: determining the identity identifier corresponding to the second server based on the third mapping relationship.

[0024] In this embodiment, the first terminal device stores a third mapping relationship and can determine the identity identifier based on this third mapping relationship. For example, the third mapping relationship can be stored in a database in which service identifiers and first identity identifiers correspond one-to-one.

[0025] In one possible implementation of the first aspect described above, the verification result is considered successful if the authorization credential corresponding to the identity identifier is stored in the second server. That is, in this embodiment, if the identity identifier includes a first identity identifier and / or a second identity identifier, and the second server stores the authorization credential corresponding to the first identity identifier and / or the second identity identifier, the verification result is considered successful. The authorization credential can be purchase information. In some examples, after receiving the first and second identity identifiers sent by the second terminal device, the second server can choose to use either the first or the second identity identifier for verification and return the verification result to the second terminal device.

[0026] It is understandable that authorization credentials can be stored on a second server. If the second server contains the authorization credentials corresponding to the identity to be verified, the verification result is considered successful. This method ensures that the authorization credentials are stored only on the second server and do not need to be transmitted to the first server or the first terminal device, thereby avoiding the confidentiality issues of user data and enabling efficient and accurate permission verification.

[0027] Secondly, this application provides a verification method applied to a second terminal device, comprising: sending a first message to a first terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; receiving a second message sent by the first terminal device, wherein the second message includes an identity identifier, the identity identifier representing the identity information of the first terminal device; determining the verification result of the identity identifier through a second server, and determining whether to perform a first operation on the second terminal device based on the verification result.

[0028] In this embodiment, the first terminal device can be an electronic device such as a mobile phone, and the second terminal device can be a gate device, access control device, or access control device. The identity identifier can be used to distinguish and confirm the user's identity. The second server can be the backend server of the second terminal device. Optionally, the second terminal device can upload its identity identifier to the second server, and the second server can determine whether the verification result is passed or failed based on the identity identifier, and then return the verification result to the second terminal device. The first operation can be a passage operation, such as opening a gate.

[0029] The verification method of this application embodiment only requires information exchange between the first terminal device and the second terminal device to achieve permission verification. Users do not need to perform any other pre-processing, thus improving verification efficiency. Furthermore, the verification method relying on identity identifiers is relatively reliable, and the use of identifiable identity information can avoid user data confidentiality issues, thus enabling its application in scenarios where the first and second terminal devices belong to different service providers.

[0030] In one possible implementation of the second aspect above, the identity identifier includes a first identity identifier, which represents the identity information of the first terminal device in the second server.

[0031] In this embodiment, the first identity identifier can be used to confirm the user's identity on the second server. It is understood that the second server can be the backend server of the second terminal device. For example, the second terminal device is an IoT device, and the second server is the IoT device's backend system. By sending the first identity identifier to the second terminal device, the second terminal device can efficiently verify user permissions on its own side.

[0032] In one possible implementation of the second aspect described above, the identity identifier further includes a second identity identifier, which represents the identity information of the first terminal device in the first application provided by the second server.

[0033] In this embodiment, the second identity identifier can be used to confirm the user's identity in the first application provided by the second server. It is understood that the first application can be one of the applications provided by the second server, such as a mini-program or an app. By sending the second identity identifier to the second terminal device, the second terminal device can efficiently verify the user's permissions in the first application, such as verifying ticket purchase information purchased by the user based on the first application.

[0034] In one possible implementation of the second aspect above, the first message includes a service identifier, which represents the service provider information of the second terminal device.

[0035] In this embodiment of the application, the service identifier can correspond to the service provider of the second terminal device, so that the first terminal device can locate the second server in the background of the second terminal device based on the service identifier, thereby accurately returning the identity information required for verification by the second server.

[0036] In one possible implementation of the second aspect above, the service identifier is the device identifier of the second terminal device.

[0037] In this embodiment of the application, the second terminal device can send its own device identifier to the first terminal device. The device identifier can indicate the provider of the second terminal device, so that the first terminal device or the first server can determine the provider of the second terminal device based on the device identifier, and then map out the identity identifier.

[0038] In one possible implementation of the second aspect above, determining the verification result of the identity identifier by the second server includes: sending a fifth message to the second server, the fifth message including the identity identifier; the second server determining the verification result of the identity identifier; and receiving the verification result of the identity identifier sent by the second server.

[0039] In this embodiment of the application, the second terminal device can determine the verification result through the second server, thereby releasing the computing power requirement on the second terminal device side.

[0040] In one possible implementation of the second aspect above, if the authorization credential corresponding to the identity is stored in the second server, the verification result is passed.

[0041] In this embodiment of the application, when the identity identifier includes a first identity identifier and / or a second identity identifier, if the second server stores authorization credentials corresponding to the first identity identifier and / or the second identity identifier, the verification result is successful. The authorization credentials may be purchase information. In some examples, after receiving the first identity identifier and the second identity identifier sent by the second terminal device, the second server can choose to use either the first identity identifier or the second identity identifier for verification and return the verification result to the second terminal device.

[0042] It is understandable that authorization credentials can be stored on a second server. If the second server contains the authorization credentials corresponding to the identity to be verified, the verification result is considered successful. This method ensures that the authorization credentials are stored only on the second server and do not need to be transmitted to the first server or the first terminal device, thereby avoiding the confidentiality issues of user data and enabling efficient and accurate permission verification.

[0043] Thirdly, this application provides a verification system, including a first terminal device and a second terminal device, wherein the first terminal device is used to receive a first message sent by the second terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; send a second message to the second terminal device, wherein the second message includes an identity identifier, the identity identifier representing the identity information of the first terminal device; the second terminal device is used to determine the verification result of the identity identifier through a second server, and determine whether to perform a first operation on the second terminal device based on the verification result.

[0044] Fourthly, embodiments of this application provide an electronic device, including: a memory for storing instructions executed by one or more processors of the electronic device, and a processor that, when executing the instructions in the memory, causes the electronic device to perform the verification method of the first aspect or the second aspect.

[0045] Fifthly, embodiments of this application provide a non-volatile storage medium storing instructions, which, when executed on an electronic device, cause the electronic device to perform the verification method of the first or second aspect.

[0046] In a sixth aspect, embodiments of this application provide a computer program product, including: a non-volatile computer-readable storage medium containing computer program code for performing the verification method of the first aspect or the second aspect. Attached Figure Description

[0047] Figure 1A illustrates a scenario for identity verification according to this application;

[0048] Figure 1B illustrates a schematic diagram of the architecture of a location-based verification system according to this application;

[0049] Figure 2 shows a schematic diagram of a verification system according to this application;

[0050] Figure 3 illustrates a first flowchart of a verification method according to an embodiment of this application;

[0051] Figure 4 illustrates a schematic diagram of a third-party interface for a railway application according to an embodiment of this application;

[0052] Figure 5 illustrates a second flowchart of a verification method according to an embodiment of this application;

[0053] Figure 6 illustrates a third process flow diagram of a verification method according to an embodiment of this application;

[0054] Figure 7 shows a schematic diagram of a third-party interface for a scenic area application according to an embodiment of this application;

[0055] Figure 8 illustrates a fourth process flow diagram of a verification method according to an embodiment of this application;

[0056] Figure 9 illustrates a fifth process flow diagram of a verification method according to an embodiment of this application;

[0057] Figure 10A illustrates an interaction diagram between an IoT service provider and a mobile cloud service platform according to an embodiment of this application;

[0058] Figure 10B illustrates an interaction diagram between another IoT service provider and a mobile cloud service platform according to an embodiment of this application;

[0059] Figure 10C illustrates an interaction diagram of an IoT-related application and a mobile cloud service platform according to an embodiment of this application;

[0060] Figure 11 illustrates the interaction diagram of various modules of a verification system according to an embodiment of this application;

[0061] Figure 12 shows a schematic diagram of the hardware structure of an electronic device 100 according to an embodiment of this application;

[0062] Figure 13 illustrates a software architecture diagram according to an embodiment of this application. Detailed Implementation

[0063] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings.

[0064] The illustrative embodiments of this application include, but are not limited to, a verification method, system, electronic device, and storage medium.

[0065] In this embodiment, the verification method can be applied to an electronic device 100. The electronic device 100 may include terminal devices, including but not limited to smartphones, desktop computers, tablets, laptops, smart speakers, digital assistants, augmented reality (AR) / virtual reality (VR) devices, smart wearable devices, and other similar devices. Optionally, the operating system running on the electronic device 100 may include, but is not limited to, Android. TM System, iOS TM System, Linux TM Windows TM The specific details of electronic device 100 will be described in detail below with reference to Figure 12, and will not be repeated here.

[0066] To facilitate understanding of the verification method of the embodiments of this application, the technical problems to be solved by the embodiments of this application will be analyzed and explained below.

[0067] As mentioned earlier, current verification systems have some shortcomings, such as cumbersome processes. For example, users need to properly store physical credentials, such as tickets or ID cards; or they need to launch an application and open the QR code used for verification through the application. These processes are quite cumbersome and require a high level of user skill.

[0068] To address the issue of cumbersome verification processes, other methods utilize near field communication (NFC) technology to simplify the verification process.

[0069] Taking Figure 1A as an example, when a user brings their mobile phone close to an Internet of Things (IoT) device, an NFC connection can be established when the phone and IoT device are close enough. For example, if the phone and IoT device are within a preset distance, a connection is established. Then, user authentication is completed through information exchange between the phone and IoT device. The IoT device can be a gate device, and the user's terminal device can be any device other than a mobile phone.

[0070] According to some embodiments, a verification system that eliminates the need for complex user operations is achieved by interacting with an IoT device such as a turnstile via NFC, using a terminal device. This embodiment will be described in detail below with reference to Figure 1B.

[0071] As shown in Figure 1B, the verification system includes a mobile phone 11, a cloud service platform 12, a station-level server 13, and a turnstile 14. For example, the passenger first logs in through a credit consumption application (APP) on the mobile phone 11 and reports their personal information to the cloud service platform 12. The cloud service platform 12 not only stores user information but also periodically receives the passenger's location information reported by the mobile phone 11. This continuous data stream provides the verification system with real-time information about the passenger. Next, the cloud service platform 12 uses a specific algorithm (such as a linear congruential generator) to generate a globally unique random number. This random number serves as the passenger's gate access credential and is pushed to the nearest station-level server 13 and the credit consumption APP used by the passenger, and then sent to the mobile phone 11. When the passenger approaches the turnstile 14, the gate access credential can be quickly and securely transmitted between the mobile phone 11 and the turnstile 14 via NFC technology. Furthermore, the turnstile 14 sends the access pass received from the mobile phone 11 to the station-level server 13. Upon receiving the access pass, the station-level server 13 compares the stored access pass with the one transmitted by the turnstile 14 to complete passenger identity verification. This contactless interaction method not only improves passage efficiency but also reduces the potential risks associated with physical contact. After receiving the access pass sent by the turnstile 14, the station-level server 13 compares it with the pass sent by the cloud service platform 12 to complete passenger identity verification. The automation and intelligence of this process greatly improve the accuracy and efficiency of verification.

[0072] However, the verification system described in Figure 1B has some drawbacks. First, the verification system in Figure 1B relies heavily on the location information reported by the passenger's mobile phone 11. If the location information is inaccurate, it may lead to identity verification failure, affecting the passenger's passage experience. Second, periodically reporting location information may cause performance degradation, especially during peak traffic periods, where this degradation may be more pronounced. Furthermore, the verification system in Figure 1B is only applicable to platforms built by the same service provider. For example, if the credit consumption app, turnstile, station-level server, and cloud service platform in Figure 1B are operated by the same service provider, they can share data; however, in cases where multiple service providers operate, their data cannot be directly shared. For instance, the cloud service platform 12 may not have access to the location information of mobile phone 11, rendering the verification system unusable.

[0073] To overcome these problems, embodiments of this application provide a verification method and a verification system including at least a first terminal device and a second terminal device. For example, the first terminal device can be a portable device carried by a user, such as a mobile phone, tablet, or smartwatch; the second terminal device can be a device used to control access permissions, such as a turnstile. The second terminal device is deployed in an area requiring verification permissions to enter. According to some embodiments, after the first terminal device receives a first message from the second terminal device, the first terminal device sends a second message to the second terminal device, the second message including a first identity identifier. The distance between the first and second terminal devices can be less than a preset distance, and they can interact with each other based on near-field communication. The first identity identifier represents the identity information of the first terminal device in a second server, which is a third-party server indicated by the first message, i.e., a server not managed by the device manufacturer of the first terminal device but managed by a third-party service provider. For example, in the case of a high-speed rail turnstile, the second server can be a railway ticketing system, and the first identity identifier is the identity certificate of the user using the first terminal device in the railway ticketing system. If the turnstile receives a verification result of the first identity identifier that is successful, then the turnstile will perform a first operation, such as opening, allowing the user to pass. During this process, users do not need to perform cumbersome operations on the device, and the terminal device does not need to continuously report location information. Furthermore, since the first and second terminal devices only need to exchange IDs, there are no confidentiality issues involved. Therefore, this solution can be applied to scenarios where multiple service providers coexist.

[0074] It is understood that in the embodiments of this application, the identification (ID) is a code or number used to uniquely identify an individual, and may consist of at least one number or character. For example, the ID involved in the embodiments of this application may include user ID, device ID, system ID, identity ID (such as a first identity identifier), business ID, application ID, etc.

[0075] According to some embodiments, the first terminal device and the second terminal device can establish an NFC connection and transmit data through the NFC channel. After establishing an NFC connection with the first terminal device, the second terminal device can send a first message to the first terminal device.

[0076] According to some embodiments, the first message includes a service identifier, which corresponds to a second server.

[0077] For example, the service identifier can be the device identifier of the second terminal device, and the device identifier can be the device ID. It can be understood that this device ID corresponds to the second server; that is, the second server stores this device ID. The device database of the second server can store the device IDs of all terminal devices managed by the second server, such as the device IDs of all turnstiles.

[0078] For example, the service identifier can be the identifier of the second server, used to identify the second server. That is, the service identifier can be the system identifier of the third-party system to which the second terminal device belongs, such as the system ID of the IoT device service provider system to which the IoT device belongs.

[0079] According to some embodiments, the first terminal device may pre-store a first identity identifier. For example, the first terminal device may store the user's first identity ID in various third-party systems, such as the first identity ID in a high-speed rail ticketing system, the first identity ID in a performance ticketing system, and so on. These first identity IDs and the system IDs of the third-party systems, such as the system ID of the IoT device service provider system, may have a mapping relationship, and the first terminal device may cache this mapping relationship. When the first message received by the first terminal device contains the system ID of the IoT device service provider system, the first terminal device can determine the first identity ID corresponding to the system ID based on the mapping relationship, which is the user's first identity ID in that IoT device service provider system.

[0080] According to some embodiments, a first terminal device can obtain a first identity identifier through a first server. For example, the first terminal device has a corresponding account identifier, which could be a user ID assigned by the device vendor when a user uses the services and products of the device vendor to which the first terminal device belongs. The first terminal device is logged in with this user ID. This user ID can be used to log in to the cloud services provided by the device vendor, and can also be used to log in to an app store to download an app, associate an account with a third-party app, etc. The first terminal device can send the account identifier and a first message to the first server. The first server can determine the second server corresponding to the first message based on the device ID in the first message, then determine the first identity identifier in the second server corresponding to the account identifier, and return the first identity identifier to the first terminal device. It can be understood that the first identity identifier is the identifier mapped from the account identifier to the second server. For a second server, the first identity identifier and the account identifier have a one-to-one correspondence. In this embodiment, the second server and the first server can be operated by different service providers. Between the servers operated by the two service providers, only mutual recognition and association of user IDs are required, without sharing or exchanging any sensitive data. Therefore, under this setup, there is no issue of data confidentiality; each operator retains complete control and confidentiality over its user data.

[0081] In some examples, the first server can interact with an account server. The account server stores the first identity ID of each user represented by each account identifier in various third-party systems; that is, the first identity ID of each user ID represented by each user ID in various third-party systems. For example, equipment suppliers such as mobile phone providers can operate an account server that records the first identity ID of users in various third-party systems. For example, the first identity ID of a user in a railway ticketing system or a movie ticketing system would be included. It can be understood that the second server can deploy the aforementioned third-party systems. For example, the service identifier is the system ID of the third-party system. The first server can send the system ID and user ID to the account server, and then the account server returns the first identity ID corresponding to the system ID and user ID to the first server.

[0082] In some examples, the first server may store a mapping between device IDs and third-party system IDs. As an example, with the service identifier being a device ID, the first server can determine the system ID of the third-party system corresponding to the device ID based on the mapping between device IDs and third-party system IDs. Then, the first server can send the system ID and user ID to the account server, and the account server, based on the system ID and user ID, returns the first identity ID corresponding to the system ID and user ID to the first server.

[0083] According to some embodiments, the second terminal device can verify the first identity identifier through a second server. For example, the second terminal device forwards the received first identity identifier to the second server, which then verifies whether a credential corresponding to the first identity identifier exists. Optionally, the credential could be a purchase record. If it exists, the second server sends a control command to the second terminal device to control the second terminal device to perform a first operation, such as authorizing access or opening a passageway.

[0084] According to some embodiments, a user can perform a purchase operation through a first terminal device or through other services or devices that log in based on an account identifier, so that the second server stores the credential corresponding to the user. For example, when purchasing a high-speed rail ticket via a mobile phone, the railway ticketing system's APP obtains the mobile phone user's first identity identifier in the railway ticketing system from the first server of the mobile device manufacturer, generates a credential corresponding to the first identity identifier, and then sends this credential to the second server.

[0085] According to some embodiments, the second message also includes a second identity identifier, which may be the identity identifier of the user corresponding to the account identifier (i.e., user ID) in the first application provided by the second server. It can be understood that the second identity identifier corresponds to both the first application and the account identifier. The first application is one of multiple applications provided by the second server. For example, the multiple applications may include mini-programs, apps, and apps may include mobile apps, web apps, cloud applications, etc. In this embodiment, the second terminal device can verify the first identity identifier or the second identity identifier through the second server. That is, if the verification result of either the first identity identifier or the second identity identifier is successful, the second server sends a control command to the second terminal device to instruct the second terminal device to perform the first operation.

[0086] The embodiments of this application will be described below using a mobile phone as an example of the first terminal device. It should be noted that a mobile phone is only one implementation of the first terminal device, and the embodiments of this application do not limit the specific device type of the first terminal device. In other embodiments, the first terminal device may also be other types of electronic devices.

[0087] The following describes a verification system provided in an embodiment of this application with reference to Figure 2. As shown in Figure 2, the verification system includes a mobile phone 21, an IoT device 22, a mobile cloud service platform 23, an IoT device backend system 24, and an IoT-related application 25.

[0088] In some alternative embodiments, the mobile phone 21 includes an authentication module 211 and an NFC module 212.

[0089] The NFC module 212 is responsible for establishing communication with the IoT device 22 and obtaining the first message sent by the IoT device 22. Optionally, the first message may include the device ID (i.e., device identifier). It can be understood that when the distance between the mobile phone 21 and the IoT device 22 is less than a preset distance, such as 3 centimeters, the NFC module 212 in the mobile phone 21 and the NFC module 221 in the IoT device 22 can detect each other's NFC signals, thereby establishing a connection.

[0090] The authentication module 211 is responsible for sending the device ID obtained by the NFC module 212 and the user ID of the mobile phone system to the mobile cloud service platform 23 via a second message to request the user's identity ID in the IoT device service provider system (i.e., a third-party system deployed in the second server). For example, after receiving the device ID and user ID, the mobile cloud service platform 23 can determine the identity ID corresponding to the device ID and user ID according to the pre-stored mapping relationship, and then return the identity ID to the authentication module 211. The authentication module 211 can receive the user's identity ID in the IoT device service provider system obtained from the mobile cloud service platform 23. For example, the identity ID may include the first identity identifier described above, also known as the first identity ID; or it may also include a second identity identifier, also known as the second identity ID.

[0091] It can be understood that a mobile phone system is the operating system provided by the mobile phone manufacturer. When a user registers an operating system account, the system generates a unique user ID. This ID is an identifier used internally by the system to identify the user account and is used by the user when using the products and services provided by the device manufacturer. This user ID is the aforementioned user ID of the mobile phone system.

[0092] In some optional embodiments, after receiving the device ID of IoT device 22 and the system user ID of mobile phone 21, mobile cloud service platform 23 can return the user's identity ID in the IoT device service provider system to the authentication module 211 of mobile phone 21, so that the authentication module 211 of mobile phone 21 can forward the identity ID to IoT device 22.

[0093] In some optional embodiments, after establishing a communication connection with the mobile phone 21, the IoT device 22 can transmit its device ID to the user's mobile phone 21 through the NFC module 221, and receive the user's identity ID in the IoT device service provider system transmitted back by the mobile phone 21. Then, the identity ID is transmitted to the IoT device backend system 24 to verify the permissions of the identity ID.

[0094] In some optional embodiments, users can register, log in, and purchase tickets through the IoT-linked application 25.

[0095] The registration or login operation can be used to assign an identity ID. For example, after authorizing the mobile phone 21 system account to log in to the IoT-related application 25, the IoT-related application 25 can request the user's identity ID in the IoT device service provider system from the mobile cloud service platform 23.

[0096] The ticket purchase operation after login allows for the storage of business logic, which is used to provide verification credentials in subsequent permission verification processes. For example, IoT-related application 25 associates the user's ticket purchase business logic with the user's identity ID in the IoT device service provider system based on the user's ticket purchase operation, and then transmits the identity ID and business logic together to the IoT device backend system 24. According to the above example, the account registered or logged into by the user in IoT-related application 25 obtains the user's identity ID in the IoT device service provider system, and the user subsequently performs a ticket purchase operation based on this account; therefore, the generated business logic is associated with the identity ID. Thus, the IoT device backend system 24 can store the associated user business logic and the user's identity ID in the IoT device service provider system, i.e., it stores the business credentials of the identity ID in the IoT device service provider system, which can be used as a basis for verification in subsequent processes.

[0097] It can be understood that the IoT device backend system 24 is a backend service related to the IoT device 22, responsible for handling transactions related to the IoT device 22; while the IoT associated application 25 provides a service interface for users, allowing them to access and use the services and functions of the IoT device backend system 24 through the service interface. Taking the IoT device as a high-speed rail ticket verification gate as an example, the IoT device backend system 24 can handle transactions related to high-speed rail tickets, including ticket information management, seat reservation, and order management; correspondingly, the IoT associated application 25 can provide users with interfaces to access ticket information and make seat reservations. According to some embodiments, the IoT device backend system 24 may belong to the IoT device service provider system, or it may work in conjunction with the IoT device service provider system.

[0098] In some optional embodiments, during the pre-storage of business logic, the IoT device backend system 24 can receive and save the user's first identity ID in the IoT device service provider system and its user business logic transmitted by the IoT associated application 25. During the business logic-based verification process, the IoT device backend system 24 can receive the user's first identity ID in the IoT device service provider system transmitted from the IoT device 22. This first identity ID can instruct the IoT device backend system 24 to perform user legitimacy verification based on the pre-stored user identity ID and its business logic. Finally, a control command is sent to the IoT device 22 based on the verification result.

[0099] The following describes a verification method provided by an embodiment of this application with reference to Figure 3. As shown in Figure 3, an exemplary process of a verification method provided by an embodiment of this application may include:

[0100] S301: IoT device 22 sends the first message to mobile phone 21.

[0101] It is understandable that IoT device 22 can send the first message to mobile phone 21 via NFC.

[0102] Optionally, the first message includes a service identifier.

[0103] In one alternative embodiment, the service identifier is the device ID of the IoT device.

[0104] In one alternative embodiment, the service identifier is the system ID of the IoT device service provider system.

[0105] In an optional embodiment, prior to step S301, the NFC function of both the IoT device 22 and the mobile phone 21 is enabled. When the distance between the IoT device 22 and the mobile phone 21 is less than a preset distance, an NFC connection is established between them. It is understood that the connection and information exchange between the mobile phone 21 and the IoT device 22 will only occur when they are close together; in other scenarios, no interaction will take place, thus avoiding additional device power consumption.

[0106] S302: Mobile phone 21 sends the user ID and service identifier of the mobile phone system to the mobile cloud service platform 23.

[0107] According to some embodiments, the user ID and service identifier of the mobile phone system can be sent via the third message described above.

[0108] According to some embodiments, the mobile phone can send the user ID stored in the mobile phone system and the service identifier in the received first message to the mobile cloud service platform 23 to request the first identity ID required for verification from the mobile cloud service platform 23.

[0109] As we can understand, a user ID in a mobile phone system is a unique identifier assigned to a mobile phone user by the device manufacturer, used to identify and verify the user's identity in various services and applications. Furthermore, this user ID is not limited to mobile application scenarios; for example, when a user uses other terminal devices provided by the same device manufacturer, such as tablets, laptops, and smartwatches, they can also use the same user ID to log in, access services, and perform other business functions.

[0110] S303: The mobile cloud service platform 23 determines the user's first identity ID in the IoT device backend system 24 based on the user ID and service identifier of the mobile phone system.

[0111] It is understandable that the mobile cloud service platform 23 can determine the IoT device service provider system based on the service identifier, and then determine the user's first identity ID in the IoT device service provider system corresponding to the user ID. As an example, the exemplary process of step S303 includes the following steps:

[0112] S3031: The mobile cloud service platform 23 determines the IoT device service provider system ID based on the service identifier.

[0113] In one alternative embodiment, the service identifier may include the device ID of the IoT device. The mobile cloud service platform 23 can determine the corresponding IoT device service provider system ID based on the device ID.

[0114] For example, the mobile cloud service platform 23 can store a device information database containing multiple device IDs corresponding to each IoT device service provider system ID, i.e., the IDs of all gate devices managed by each IoT device service provider system. Based on this, the mobile cloud service platform 23 can determine the IoT device service provider system ID associated with the device ID according to the mapping relationship between devices and systems in the device information database.

[0115] For example, a device ID can consist of at least one character, and at least some of these characters can be associated with an IoT device service provider system ID. For instance, a device ID could be XY123456, where XY represents the first IoT device service provider system. In this case, the mobile cloud service platform 23 can determine the IoT device service provider system ID corresponding to this device ID as the first IoT device service provider system ID based on XY.

[0116] In one alternative embodiment, the service identifier may include the IoT device service provider system ID. In this embodiment, the mobile cloud service platform 23 can directly receive the IoT device service provider system ID when receiving the service identifier.

[0117] S3032: The mobile cloud service platform 23 determines the user's first identity ID in the IoT device service provider system based on the IoT device service provider system ID and the user ID.

[0118] In one optional embodiment, the mobile cloud service platform 23 can communicate with an account server, wherein the account server stores an identity database containing user IDs managed by the mobile cloud service platform 23 within mobile device service providers' services, as well as the first identity ID of each user ID in various IoT device service provider systems. For example, for the same user ID, there may be different first identity IDs in IoT device service provider systems such as railway ticketing systems and movie ticketing systems.

[0119] It is understood that the identity database stores a first identity ID that maps to the user ID and the IoT device service provider system ID. That is, for each user ID and each IoT device service provider system ID, the identity database stores a unique first identity ID, which represents the user's identity information within the IoT device service provider system. The mobile cloud service platform 23 can send the IoT device service provider system ID and the user ID to the account server; based on the aforementioned mapping relationship, the account server determines the first identity ID mapped to the user ID and the IoT device service provider system ID from the identity database, which is the first identity ID of the user ID in the IoT device service provider system to be verified, and then returns this first identity ID to the mobile cloud service platform 23.

[0120] S304: The mobile cloud service platform 23 sends the first identity ID to the mobile phone 21.

[0121] In an optional embodiment, the mobile cloud service platform 23 can return the first identity ID determined in step S303 to the mobile phone 21.

[0122] S305: Mobile phone 21 sends the first identity ID to IoT device 22.

[0123] In one optional embodiment, after receiving the first identity ID sent by the mobile cloud service platform 23, the mobile phone 21 can forward the first identity ID to the IoT device 22 so that the IoT device 22 can send it to the IoT device service provider for verification.

[0124] S306: IoT device 22 sends the first identity ID to IoT device backend system 24.

[0125] According to some embodiments, the first identity ID can be sent via the fifth message described above.

[0126] In one optional embodiment, after receiving the first identity ID, the IoT device 22 can send the first identity ID to the IoT device backend system 24, and the IoT device backend system 24 can verify whether the first identity ID has the necessary permissions.

[0127] S307: The IoT device backend system 24 determines the verification result based on the first identity ID.

[0128] It is understandable that after receiving the first identity ID, the IoT device backend system 24 can verify the first identity ID and determine the verification result.

[0129] In one optional embodiment, the verification result can include pass or fail. For example, if the IoT device backend system 24 does not find any business logic matching the first identity ID with the IoT device 22, the verification result can be determined as fail; conversely, if the IoT device backend system 24 finds any business logic matching the first identity ID with the IoT device 22, the verification result can be determined as pass. As an example, the IoT device 22 can be a light rail station entrance gate, and the matching business logic can be the ticket purchase information currently being verified by the light rail station entrance gate.

[0130] Optionally, if IoT device 22 is the gate device for scenic area B, the business logic matching IoT device 22 is the ticket purchase information of scenic area B. In this embodiment, if the IoT device backend system 24 stores the ticket purchase information of scenic area B with the first identity ID, the verification passes; otherwise, if the IoT device backend system 24 does not store the ticket purchase information of scenic area B with the first identity ID, the verification fails.

[0131] According to some embodiments, if the verification result passes, the IoT device backend system 24 can delete the ticketing information corresponding to the IoT device 22 from the stored ticketing information corresponding to the first identity ID. For example, for a first identity ID, the ticketing information stored in the IoT device backend system 24 may include ticketing information for scenic spot A and ticketing information for scenic spot B; if the IoT device 22 is a gate device for scenic spot B, then after the verification passes, the IoT device backend system 24 can delete the ticketing information for scenic spot B of the first identity ID from the ticketing information of that first identity ID.

[0132] S308: The IoT device backend system 24 sends the verification result to the IoT device 22.

[0133] It is understandable that after the IoT device backend system 24 completes the verification process, it can send the verification result of the verification process to the IoT device 22.

[0134] In one alternative embodiment, the IoT device backend system 24 can send the verification result to the IoT device 22. For example, it can send a failed verification result to the IoT device 22, or it can send a successful verification result to the IoT device 22.

[0135] In one optional embodiment, the IoT device backend system 24 may send the verification result to the IoT device 22 as appropriate, based on the verification result. For example, if the verification result is successful, the verification result is sent to the IoT device 22 as a control command to control the IoT device to perform a first operation. If the verification result is unsuccessful, no operation is performed, i.e., no verification result is sent to the IoT device 22; in this case, since the IoT device 22 will not receive any command, it will not perform the first operation, thus preventing unauthorized access from being granted.

[0136] S309: IoT device 22 performs the first operation based on the verification result.

[0137] In one optional embodiment, the IoT device backend system 24 can perform a first operation based on the received verification result. For example, after receiving a successful verification result, the IoT device 22 can perform the first operation, including opening the barrier gate, unlocking the electronic lock, controlling the access control device to open, and unlocking access permissions for a specific area.

[0138] In one optional embodiment, after the IoT device 22 receives the successful verification result, it can send a notification message to the mobile phone 21. This notification message may carry an identifier of the business logic. After receiving the notification message, the mobile phone 21 can display a third-party interface corresponding to the business logic based on the identifier of the business logic.

[0139] For example, in an embodiment where IoT device 22 is a high-speed rail ticket verification gate and the IoT device service provider is a railway service provider, the third-party interface can be interface 01 as shown in Figure 4. That is, after the user successfully verifies their ticket, the user's mobile phone 21 can display interface 01, which displays travel information, map and location information, as well as service controls such as ticket upgrade, catering services, and train information.

[0140] In one optional embodiment, the IoT device 22 can generate different prompts based on different verification results, such as screen prompts, voice prompts, indicator light information, etc. For example, if the verification result is successful, the screen of the IoT device 22 can display the words "Verification passed"; conversely, if the verification result is unsuccessful, the screen of the IoT device 22 can display the words "Verification failed".

[0141] In one optional embodiment, the IoT device 22 can also send notifications to the mobile phone 21 based on different verification results, causing the mobile phone to generate prompts such as voice prompts or notifications. For example, if the verification result is successful, the IoT device 22 can send a success notification to the mobile phone, causing the mobile phone to generate a verification success prompt, such as a "verification successful" status bar prompt; conversely, the IoT device 22 can send a failure notification to the mobile phone, causing the mobile phone to generate a verification failure prompt, such as a "verification failed" status bar prompt.

[0142] According to one verification method in this application, users only need to bring their mobile phones close to IoT devices, such as turnstiles, to establish an NFC communication connection between the phone and the IoT device. Then, authorization verification is achieved through information exchange between the phone and the IoT device. This reduces the pre-verification steps required by the user and improves verification efficiency. Furthermore, authorization verification based on a first identity ID is more reliable than other methods that rely on location information. In addition, in the verification method of this application, the mobile device system and the IoT device system are operated by two different service providers. They only need to synchronize or transmit ID information without sharing or exchanging any sensitive data. Therefore, each operator retains complete control and confidentiality over its user data.

[0143] The following describes a verification method provided by an embodiment of this application in conjunction with Figure 5. It can be understood that the steps shown in Figure 5 can be performed before steps S301 to S308 shown in Figure 3, that is, the steps shown in Figure 5 are the pre-steps of the verification process shown in Figure 3.

[0144] S501: IoT device service providers register on the mobile cloud service platform 23.

[0145] According to some embodiments, IoT device service providers can register on the mobile cloud service platform 23 to request the allocation of an IoT device service provider system ID from the mobile cloud service platform 23.

[0146] S502: The mobile cloud service platform 23 assigns IoT device service provider system IDs to IoT device service providers.

[0147] It is understandable that after an IoT device service provider submits its registration to the mobile cloud service platform 23, the mobile cloud service platform 23 can assign an IoT device service provider system ID. This ID can be used to identify the IoT device service provider system and facilitates the subsequent recording of devices that have a mapping relationship with the IoT device service provider system in the database.

[0148] In an optional embodiment, the mobile cloud service platform 23 can send the IoT device service provider system ID to the IoT device backend system 24.

[0149] S503: The mobile cloud service platform 23 binds the device ID and the IoT device service provider system ID.

[0150] It is understood that, in this embodiment of the application, one or more device IDs can be bound to the same IoT device service provider system ID.

[0151] In one alternative implementation, the web page of the mobile cloud service platform 23 can receive input operations, which can include the IoT device service provider system ID and one or more corresponding device IDs.

[0152] In one alternative implementation, for all devices managed by the IoT device service provider, such as all ticket gate devices at ticket verification entrances managed by the railway ticketing provider, the device ID is sent to the mobile cloud service platform 23 through the IoT device backend system 24, and the device ID can be associated with the IoT device service provider system ID of the IoT device backend system 24.

[0153] In one optional implementation, the IoT device backend system 24 can simultaneously send the IoT device service provider system ID and at least one device ID to the mobile cloud service platform 23, so that the mobile cloud service platform 23 can associate the device ID of at least one device with the IoT device service provider system ID, that is, establish a mapping relationship between the IoT device service provider system ID and the device ID of at least one device.

[0154] S504: IoT-related application 25 detected user login authorized based on mobile phone system user ID.

[0155] It is understandable that users can complete authorized login by entering their mobile phone system's user ID and password in the IoT-connected application 25, or by using the mobile phone system's authentication services, such as biometrics or one-click login services.

[0156] In an optional implementation, if the user has not registered for the IoT-related application 25, step S504 may also be: the IoT-related application 25 detects that the user has authorized registration based on the user ID of the mobile phone system. It should be noted that this application embodiment does not limit the device used by the user to log in or register for the IoT-related application 25; the user can log in to the IoT-related application 25 using devices such as mobile phones, tablets, smartwatches, and laptops.

[0157] S505: The IoT-related application 25 sends the IoT device service provider system ID and user ID to the mobile cloud service platform 23.

[0158] It is understood that after the IoT device service provider registers, the mobile cloud service platform 23 has already assigned an IoT device service provider system ID. In this case, after detecting a login operation, the IoT-related application 25 can send the IoT device service provider system ID and the user ID to the mobile cloud service platform 23 to request the user's first identity ID in the IoT device service provider system. In an optional embodiment, the account of the IoT-related application 25 needs to be associated with the mobile system account, that is, associated with the aforementioned first identity ID, to enable operations such as login and purchase.

[0159] S506: The mobile cloud service platform 23 sends the user's first identity ID in the IoT device service provider system to the IoT-related application 25.

[0160] In one alternative implementation, corresponding to the user's initial registration with the IoT-related application 25, the mobile cloud service platform 23 does not store a first identity ID that maps to the IoT device service provider's system ID and the user ID. In this case, the mobile cloud service platform 23 can assign the user ID a first identity ID in the IoT device service provider's system and send this first identity ID to the IoT-related application 25.

[0161] For example, the mobile cloud service platform 23 can interact with the account server. The mobile cloud service platform 23 sends the IoT device service provider system ID and the user ID to the account server. The account server assigns a first identity ID based on the IoT device service provider system ID and the user ID, and returns the first identity ID to the mobile cloud service platform 23.

[0162] In one optional implementation, corresponding to a user's registration with the IoT-related application 25, the mobile cloud service platform 23 stores a first identity ID that maps to both the IoT device service provider's system ID and the user's ID. In this case, the mobile cloud service platform 23 can send this first identity ID to the IoT-related application 25.

[0163] S507: IoT-related application 25 detected a user's purchase action.

[0164] It is understandable that after logging into the IoT-related application 25 using their mobile phone system's user ID, users can make purchases through the sales interface provided by the IoT-related application 25. For example, they can buy movie tickets or high-speed rail tickets.

[0165] S508: The IoT-related application 25 saves the purchase information corresponding to the first identity ID to the IoT device backend system 24.

[0166] It is understandable that after a user logs into the IoT-related application 25 using their mobile phone system's user ID, the mobile cloud service platform 23 assigns the user ID to the IoT-related application 25 as a first identity ID mapped to the IoT device service provider's system. After the user makes a purchase, the IoT-related application 25 can send the first identity ID along with the purchase information to the IoT device backend system 24, so that the IoT device backend system stores the purchase information as business logic associated with the first identity ID for subsequent verification of permissions. For example, during the execution of step S507, the IoT device backend system 24 can query whether the purchase information exists in the business logic associated with the first identity ID, and then determine the verification result based on the query result; for example, if the purchase information is found, the verification is successful.

[0167] Based on some examples, a single IoT device service provider can offer multiple applications. For instance, a scenic area can be divided into multiple areas, such as Scenic Area A and Scenic Area B, each selling tickets through a separate application. Scenic Area A sells tickets through application A, and Scenic Area B sells tickets through application B. In these examples, the same user ID can have a primary identity ID in the IoT device service provider's system, and simultaneously, a secondary identity ID exists within the applications provided by that system. The primary identity ID is understood to be the ID used in the IoT device service provider's system to distinguish and identify the user; the secondary identity ID is the ID used within the application to distinguish and identify the user. For example, in the scenic area example above, the user ID can correspond not only to the primary identity ID in the IoT device service provider's system, but also to the secondary identity ID A in the application for Scenic Area A, and the secondary identity ID B in the application for Scenic Area B. The secondary identity ID can be understood to indicate an application provided by the IoT device service provider. For example, secondary identity ID A indicates the application for Scenic Area A, and secondary identity ID B indicates the application for Scenic Area B.

[0168] The following describes a verification method for multiple application scenarios, with reference to Figure 6. In this scenario, IoT device 22 needs to verify whether the user carrying mobile phone 21 possesses authorization credentials or purchase credentials for the application to which IoT device 22 belongs. For example, if IoT device 22 is a gate device for scenic area A, then IoT device 22 belongs to the scenic area A application, and what needs to be verified is the purchase credentials for scenic area A.

[0169] As shown in Figure 6, an exemplary process of a verification method provided according to an embodiment of this application may include:

[0170] S601: IoT device 22 sends the first message to mobile phone 21.

[0171] It is understandable that IoT device 22 can send the first message to mobile phone 21 via NFC.

[0172] Optionally, the first message includes a service identifier.

[0173] In one alternative embodiment, the service identifier is the device ID of the IoT device.

[0174] In one alternative embodiment, the service identifier is the system ID of the IoT device service provider system.

[0175] In an optional embodiment, prior to step S601, the NFC function of both the IoT device 22 and the mobile phone 21 is enabled. When the distance between the IoT device 22 and the mobile phone 21 is less than a preset distance, an NFC connection is established between them. It is understood that the connection and information exchange between the mobile phone 21 and the IoT device 22 will only occur when they are close together; in other scenarios, no interaction will take place, thus avoiding additional device power consumption.

[0176] S602: Mobile phone 21 sends the user ID and service identifier of the mobile phone system to the mobile cloud service platform 23.

[0177] According to some embodiments, the user ID and service identifier of the mobile phone system can be sent via the third message described above.

[0178] According to some embodiments, the mobile phone can send the user ID of the mobile phone system stored in itself, as well as the service identifier in the received first message, to the mobile cloud service platform 23 to request the first identity ID and the second identity ID required for verification from the mobile cloud service platform 23.

[0179] As we can understand, a user ID in a mobile phone system is a unique identifier assigned to a mobile phone user by the device manufacturer. It is used to identify and verify the user's identity in various services and applications. Furthermore, this user ID is not limited to mobile phone application scenarios. For example, when a user uses other terminal devices provided by the same device manufacturer, such as tablets, laptops, and smartwatches, they can also use the same user ID to log in, access services, and perform other application functions.

[0180] S603: The mobile cloud service platform 23 determines the user's first identity ID in the IoT device backend system 24 and the second identity ID in the IoT associated application 25 based on the user ID and service identifier of the mobile phone system.

[0181] It is understandable that the mobile cloud service platform 23 can determine the system ID of the IoT device service provider system and the application ID to which the IoT device 22 belongs based on the service identifier, and then determine the first identity ID of the user corresponding to the user ID in the IoT device service provider system and the second identity ID of the IoT associated application 25 corresponding to the application ID.

[0182] It is understandable that the application to which IoT device 22 belongs can be categorized based on information such as region, purchase channel, and train / bus number. For example, if IoT device 22 is located at entrance B of scenic area, then the application to which IoT device 22 belongs is the scenic area B application. As another example, if for the area managed by IoT device 22, users need to make purchases through the scenic area B mini-program in the IoT-related application 25, then the application to which IoT device 22 belongs is the scenic area B application.

[0183] In one optional embodiment, there are multiple IoT-associated applications 25. For example, the gate service provider develops two applications simultaneously for scenic spots A and B: Application A and Application B. Users buy tickets for scenic spot A in Application A and tickets for scenic spot B in Application B. Application A and Application B, as two IoT-associated applications 25, can have different application IDs.

[0184] As an example, the exemplary process of step S603 includes the following steps:

[0185] S6031: The mobile cloud service platform 23 determines the IoT device service provider system ID and application ID based on the service identifier.

[0186] In one optional embodiment, the first message may include the device ID of the IoT device. The mobile cloud service platform 23 can determine the corresponding IoT device service provider system ID and application ID based on the device ID.

[0187] For example, the mobile cloud service platform 23 can store a device information database. This database contains multiple device IDs corresponding to each application ID of each IoT device service provider's system ID, i.e., the IDs of all gate devices managed by each IoT device service provider's system. Based on this, the mobile cloud service platform 23 can determine the IoT device service provider's system ID and application ID associated with the device ID according to the mapping relationship between devices, applications, and systems in the device information database.

[0188] For example, a device ID can consist of at least one character, at least some of which can be associated with an IoT device service provider system ID and at least some of which can be associated with an application ID. For instance, a device ID could be “XY123456B”, where XY represents the first IoT device service provider system. The mobile cloud service platform 23 can then determine, based on XY, that the IoT device service provider system ID corresponding to this device ID is the first IoT device service provider system ID. Where B represents the scenic area B application, the mobile cloud service platform can then determine, based on B, that the application ID corresponding to this device ID is the application ID of the scenic area B application.

[0189] S6032: The mobile cloud service platform 23 determines the user's first identity ID in the IoT device service provider system and the user's second identity ID in the IoT-related application 25 based on the IoT device service provider system ID, application ID, and user ID.

[0190] In one optional embodiment, the mobile cloud service platform 23 can communicate with an account server, wherein the account server stores all user IDs managed by the mobile cloud service platform 23 in the mobile device vendor services, the first identity ID of each user ID in each IoT device service provider system, and the second identity ID of each user ID in each IoT associated application 25 in each IoT device service provider system. For example, for the same user ID, the first identity ID of the user corresponding to that user ID in the scenic spot ticketing system and the second identity ID of that user in the IoT associated application 25 of scenic spot B can be determined.

[0191] It is understood that the identity database stores a first identity ID that is mapped to the user ID and the IoT device service provider system ID, and also stores a second identity ID that is mapped to the user ID and the application ID. The mobile cloud service platform 23 can send the IoT device service provider system ID, the application ID, and the user ID to the account server; based on the above mapping relationship, the account server determines the first identity ID mapped to the user ID and the IoT device service provider system ID from the identity database, and determines the second identity ID mapped to the user ID and the application ID.

[0192] S604: The mobile cloud service platform 23 sends the first identity ID and the second identity ID to the mobile phone 21.

[0193] In an optional embodiment, the mobile cloud service platform 23 can return the first identity ID and the second identity ID determined in step S603 to the mobile phone 21.

[0194] S605: Mobile phone 21 sends the first identity ID and the second identity ID to IoT device 22.

[0195] In one optional embodiment, after receiving the first identity ID and the second identity ID sent by the mobile cloud service platform 23, the mobile phone 21 can forward the first identity ID and the second identity ID to the IoT device 22 so that the IoT device 22 can send them to the IoT device service provider for verification.

[0196] S606: IoT device 22 sends the first identity ID and the second identity ID to IoT device backend system 24.

[0197] According to some embodiments, the first identity ID and the second identity ID can be sent via the fifth message described above.

[0198] In one optional embodiment, after receiving the first identity ID and the second identity ID, the IoT device can send the first identity ID and the second identity ID to the IoT device backend system 24, and the IoT device backend system 24 can verify whether the first identity ID or the second identity ID has the necessary permissions.

[0199] S607: The IoT device backend system 24 determines the verification result based on the first identity ID or the second identity ID.

[0200] It is understandable that after receiving the first identity ID and the second identity ID, the IoT device backend system 24 can verify either the first identity ID or the second identity ID and determine the verification result. It is also understandable that the IoT device backend system can choose to verify either the first identity ID or the second identity ID based on application requirements.

[0201] In one optional embodiment, the verification result can include pass or fail. For example, if the IoT device backend system 24 does not find any business logic matching the second identity ID, such as not finding any ticket purchase record for scenic spot B under the second identity ID, the verification result can be determined to be fail; conversely, if the IoT device backend system 24 finds any business logic matching the second identity ID, such as finding any ticket purchase record for scenic spot B under the second identity ID, the verification result can be determined to be pass.

[0202] In one optional embodiment, in some scenarios, scenic areas A and B may be temporarily connected. In this case, the IoT device backend system 24 can use a first identity ID for verification as needed. For example, if a ticket purchase record for the first identity ID is found, the verification result is considered successful; otherwise, the verification result is considered unsuccessful.

[0203] According to some embodiments, if the verification result passes, the IoT device backend system 24 can delete the ticketing information corresponding to the IoT device 22 from the stored ticketing information corresponding to the first identity ID. For example, for a first identity ID, the ticketing information stored in the IoT device backend system 24 may include ticketing information for scenic spot A and ticketing information for scenic spot B; if the IoT device 22 is a gate device for scenic spot B, then after the verification passes, the IoT device backend system 24 can delete the ticketing information for scenic spot B of the first identity ID from the ticketing information of that first identity ID.

[0204] According to some embodiments, if the verification result passes, the IoT device backend system 24 can delete the ticketing information corresponding to the second identity ID. For example, deleting the ticketing information for scenic spot B with the second identity ID means deleting all ticketing information for the second identity ID.

[0205] S608: The IoT device backend system 24 sends the verification result to the IoT device 22.

[0206] It is understood that after the IoT device backend system 24 completes the verification process, it can send the verification result to the IoT device 22. It is also understood that the IoT device 22 in step S608 and the IoT device 22 in step S606 are the same device.

[0207] In one alternative embodiment, the IoT device backend system 24 can send the verification result to the IoT device 22. For example, it can send a failed verification result to the IoT device 22, or it can send a successful verification result to the IoT device 22.

[0208] In one optional embodiment, the IoT device backend system 24 may send the verification result to the IoT device 22 as appropriate, based on the verification result. For example, if the verification result is successful, the verification result is sent to the IoT device 22 as a control command to control the IoT device to perform a first operation. If the verification result is unsuccessful, no operation is performed, i.e., no verification result is sent to the IoT device 22; in this case, since the IoT device 22 will not receive any command, it will not perform the first operation, thus preventing unauthorized access from being granted.

[0209] S609: IoT device 22 performs the first operation based on the verification result.

[0210] In one optional embodiment, the IoT device backend system 24 can perform a first operation based on the received verification result. For example, after receiving a successful verification result, the communication operation of the IoT device 22 may include opening a gate, unlocking an electronic lock, controlling the access control device to open, and unlocking access permissions for a specific area.

[0211] As an example, IoT device 22 could be an entrance gate for scenic area B, and the corresponding business logic would be the ticketing information for scenic area B. In this embodiment, if IoT device 22 receives a successful verification result or a control command, then as an entrance gate for scenic area B, IoT device 22 can perform the first operation by opening the gate.

[0212] In one optional embodiment, after the IoT device 22 receives the successful verification result, it can send a notification message to the mobile phone 21. This notification message may carry an identifier of the business logic. After receiving the notification message, the mobile phone 21 can display a third-party interface corresponding to the business logic based on the identifier of the business logic.

[0213] For example, when IoT device 22 is the entrance gate device for scenic area B, the third-party interface can be interface 02 as shown in Figure 7. In this embodiment, after the user brings their mobile phone 21 close to IoT device 22 and successfully verifies their ticket, mobile phone 21 receives a notification message, which can trigger mobile phone 21 to display interface 02. As shown in Figure 7, interface 02 may include the scenic area's opening hours, a map of the scenic area, transportation information, etc.

[0214] In one optional embodiment, the IoT device 22 can generate different prompts based on different verification results, such as screen prompts, voice prompts, indicator light information, etc. For example, if the verification result is successful, the screen of the IoT device 22 can display the words "Verification passed"; conversely, if the verification result is unsuccessful, the screen of the IoT device 22 can display the words "Verification failed".

[0215] In one optional embodiment, the IoT device 22 can also send notifications to the mobile phone 21 based on different verification results, causing the mobile phone to generate prompts such as voice prompts and notifications. For example, if the verification result is successful, the IoT device 22 can send a success notification to the mobile phone, causing the mobile phone to generate a verification success prompt, such as a "verification successful" status bar prompt; conversely, the IoT device 22 can send a failure notification to the mobile phone, causing the mobile phone to generate a verification failure prompt, such as a "verification failed" status bar prompt.

[0216] According to one verification method in this application, users only need to bring their mobile phones close to IoT devices, such as turnstiles, to establish an NFC communication connection between the phone and the IoT device. Then, authorization verification is achieved through information exchange between the phone and the IoT device. This reduces the pre-verification steps required from the user and improves verification efficiency. Furthermore, relying on the identity IDs corresponding to the IoT device manufacturer and the applications provided by the manufacturer for authorization verification is more reliable than other methods that rely on location information and is applicable to various application scenarios.

[0217] The following describes a verification method provided by an embodiment of this application in conjunction with Figure 8. It can be understood that the steps shown in Figure 8 can be performed before steps S601 to S608 shown in Figure 3, that is, the steps shown in Figure 8 are the pre-steps of the verification process shown in Figure 6.

[0218] S801: IoT device service providers register on the mobile cloud service platform 23.

[0219] According to some embodiments, IoT device service providers can register on the mobile cloud service platform 23 to request the allocation of an IoT device service provider system ID from the mobile cloud service platform 23.

[0220] S802: The mobile cloud service platform 23 assigns IoT device service provider system ID and application ID to IoT device service providers.

[0221] It is understandable that when an IoT device service provider submits its registration to the mobile cloud service platform 23, the platform can assign a system ID to the provider. This ID identifies the IoT service provider's system and facilitates subsequent recording of devices mapped to that system in the database. The platform also assigns an application ID to the IoT service provider's application. This ID represents the application and allows for subsequent recording of devices mapped to that application in the database. For example, the turnstiles in scenic area A are mapped to the application in scenic area A.

[0222] In an optional embodiment, the mobile cloud service platform 23 can send the IoT device service provider system ID and application ID to the IoT device backend system 24.

[0223] S803: The IoT device service provider and the mobile cloud service platform 23 bind the device ID to the IoT device service provider's system ID and application ID.

[0224] In one optional implementation, the web page of the mobile cloud service platform 23 can receive input operations, which can include the IoT device operator's system ID, application ID, and one or more corresponding device IDs. The IoT device operator's system ID can correspond to one or more application IDs, and each application ID can correspond to one or more device IDs.

[0225] In one alternative implementation, for all devices managed by the IoT device service provider, such as all ticket gate devices at ticket verification entrances managed by the railway ticketing provider, the device ID and application ID are sent to the mobile cloud service platform 23 through the IoT device backend system 24, so that the device ID can be associated with the IoT device service provider system ID and application ID of the IoT device backend system 24.

[0226] In one optional implementation, the IoT device backend system 24 can simultaneously send the IoT device service provider system ID, application ID, and at least one device ID to the mobile cloud service platform 23, so that the mobile cloud service platform 23 can associate the device ID of at least one device with the IoT device service provider system ID and application ID, that is, establish a mapping relationship between the IoT device service provider system ID, application ID and the device ID of at least one device respectively.

[0227] S804: IoT-related application 25 detected user login authorized based on user ID of mobile phone system.

[0228] It is understandable that users can complete authorized login by entering their mobile phone system's user ID and password in the IoT-connected application 25, or by using the mobile phone system's authentication services, such as biometrics or one-click login services.

[0229] In an optional implementation, if the user has not registered for the IoT-related application 25, step S804 may also be: the IoT-related application 25 detects that the user has authorized registration based on the user ID of the mobile phone system. It should be noted that this application embodiment does not limit the device used by the user to log in or register for the IoT-related application 25; the user can log in to the IoT-related application 25 using devices such as mobile phones, tablets, smartwatches, and laptops.

[0230] S805: The IoT-related application 25 sends the IoT device service provider system ID, application ID, and user ID to the mobile cloud service platform 23.

[0231] It is understood that after an IoT device service provider registers, the mobile cloud service platform 23 has already assigned the IoT device service provider system ID, application ID, and user ID. In this case, after detecting a user's login operation based on their mobile system user ID, the user can send the IoT device service provider system ID, application ID, and user ID to the mobile cloud service platform 23 to request the user's first identity ID in the IoT device service provider system and their second identity ID in the IoT-related application 25 corresponding to the application ID. In an optional embodiment, the account in the IoT-related application 25 needs to be associated with the mobile system account, i.e., associated with the aforementioned first identity ID, to enable operations such as login and purchase; when purchasing a product from a specific application, the purchase operation can be associated with the aforementioned second identity ID to identify the application purchased by the user.

[0232] S806: The mobile cloud service platform 23 sends the user's first identity ID in the IoT device service provider system and the user's second identity ID in the IoT associated application 25 to the IoT associated application 25.

[0233] In one optional implementation, corresponding to the user's initial registration with the IoT-related application 25, the mobile cloud service platform 23 does not store a first identity ID that maps to the IoT device service provider's system ID and the user ID, nor does it store a second identity ID that maps to the IoT-related application ID and the user ID. In this case, the mobile cloud service platform 23 can assign the user ID a first identity ID in the IoT device service provider's system and a second identity ID in the IoT-related application 25, and send this identity ID to the IoT-related application 25.

[0234] For example, the mobile cloud service platform 23 can interact with the account server. The mobile cloud service platform 23 sends the IoT device service provider system ID and the user ID to the account server. The account server assigns a first identity ID based on the IoT device service provider system ID and the user ID, and returns the first identity ID to the mobile cloud service platform.

[0235] For example, the mobile cloud service platform 23 can send the IoT device service provider system ID, application ID, and user ID to the account server. The account server assigns a second identity ID based on the IoT device service provider system ID, application ID, and user ID, and returns the second identity ID to the mobile cloud service platform.

[0236] In one optional implementation, corresponding to a user's registration with the IoT-related application 25, the mobile cloud service platform 23 stores a first identity ID that maps to the IoT device service provider's system ID and the user ID, and also stores a second identity ID that maps to the IoT-related application ID and the user ID. In this case, the mobile cloud service platform 23 can send the first identity ID and the second identity ID to the IoT-related application 25.

[0237] S807: IoT-related application 25 detected a user's purchase action.

[0238] It is understandable that after logging into the IoT-related application 25 using their mobile phone system's user ID, users can make purchases through the sales interface provided by the IoT-related application 25. For example, they can buy movie tickets or high-speed rail tickets.

[0239] S808: The IoT-related application 25 saves the purchase information corresponding to the first identity ID and the second identity ID to the IoT device backend system 24.

[0240] It is understandable that after executing step S804, in response to a user's purchase operation for a specific application, such as purchasing a ticket for scenic spot B, the IoT-related application 25 can send the first identity ID, the second identity ID in the scenic spot B system, and the purchase information together to the IoT device backend system 24. This allows the IoT device backend system to store the purchase information as business logic associated with the identity ID, for later querying in the authentication process. For example, during the execution of step S607, the IoT device backend system 24 can query whether the purchase information exists in the business logic associated with the first identity ID and the second identity ID, and then determine the verification result based on the query result. For example, if the purchase information for the first identity ID is found, or the purchase information for the second identity ID is found, the verification is successful.

[0241] It is understood that by executing steps S801 to 808, the IoT device backend system can store business logic associated with the user. This business logic can be used for verification in the verification process, thereby ensuring the accurate execution of subsequent verification processes.

[0242] Based on Figures 9 and 10A-10C, another exemplary process of an embodiment of this application is described below. As shown in Figure 9, it includes:

[0243] S901: IoT service provider registration.

[0244] In some alternative embodiments, referring to Figure 10A, the IoT service provider first requests registration from the mobile cloud service platform 23. Then, the mobile cloud service platform 23 sends a third-party system ID to the IoT service provider.

[0245] In some examples, the third-party system ID includes the IoT service provider ID, which is the IoT device service provider ID mentioned above.

[0246] In other examples, such as the embodiments described above in conjunction with Figures 5 and 8, IoT service providers need credentials to distinguish between various applications. In this case, the third-party system ID includes an IoT service provider ID and an application ID. Different application IDs are used to distinguish different applications provided by the IoT service provider, such as Scenic Area A application and Scenic Area B application.

[0247] It's understandable that an application ID can represent the IoT service provider to which the application belongs, as well as the application type. In other words, even without referring to the IoT service provider ID, the IoT service provider corresponding to the application ID can be determined solely based on the application ID.

[0248] S902: IoT device registration.

[0249] In some optional embodiments, referring to Figure 10B, the IoT service provider can complete the IoT device registration simultaneously with the mobile cloud service platform 23, that is, bind the device ID to the third-party system ID.

[0250] For example, if the third-party system ID includes an IoT service provider ID, then in step S902, the device ID is bound to the IoT service provider ID. Both the IoT service provider and the mobile cloud service platform can store the mapping relationship between the device ID and the IoT service provider ID.

[0251] For example, if the third-party system ID includes an IoT service provider ID and an application ID, then in step S902, the device ID is bound to the IoT service provider ID and the application ID. Both the IoT service provider and the mobile cloud service platform can store the mapping relationship between the device ID and the IoT service provider ID and the application ID.

[0252] S903: User authorized login to IoT-related applications.

[0253] In some optional embodiments, referring to FIG10C, after the user authorizes to log in to the IoT-related application 25 using the user ID of the mobile phone system, the IoT-related application 25 requests an identity ID from the mobile cloud service platform 23. After receiving the request, the mobile cloud service platform 23 returns the identity ID to the IoT-related application 25.

[0254] For example, if the third-party system ID includes the IoT service provider ID, then the identity ID returned in step S903 includes the first identity ID in the IoT service provider system.

[0255] For example, if the third-party system ID includes the IoT service provider ID and the application ID, then the identity ID returned in step S903 includes the first identity ID in the IoT service provider system and the second identity ID in the first application corresponding to the application ID in the IoT service provider.

[0256] S904: The user's mobile phone is brought close to the IoT device for authentication.

[0257] It is understandable that when a user's mobile phone approaches an IoT device and the distance between the two devices is less than a preset distance, a communication connection, such as an NFC connection, can be established to execute a verification process. For example, the verification process may include steps S301 to S309 described above, or steps S601 to S609 described above.

[0258] It is understood that, in one example, the mobile phone and mobile cloud service platform can be provided by the mobile phone manufacturer, while the IoT device, IoT device backend system, and IoT-related applications can be provided by the IoT service provider or device service provider. In other words, the verification method provided in this application embodiment can be applied to scenarios with multiple service providers.

[0259] The verification method described in this application allows users to quickly pass through the IoT device's control area after purchasing a ticket without any prior operation when entering the identity verification process. Users simply need to enable the NFC function of their electronic device 100 (such as a mobile phone) and touch it to the NFC sensing area of ​​the IoT device, thus improving identity verification efficiency. Furthermore, since NFC communication is limited to a certain distance, operations are only required when the electronic device 100 is close to the IoT device; therefore, neither the electronic device 100 nor the IoT device generates additional power consumption.

[0260] Referring to Figure 11, step S904 may include the following process: The IoT device transmits its device ID to the user's mobile phone via NFC; the authentication module in the mobile phone reports the device ID to the mobile cloud service platform; the mobile cloud service platform uses the device ID and user ID to obtain the third-party system ID through the mapping relationship bound in step S902, then uses the third-party system ID and user ID to map out the identity ID, and finally returns the identity ID to the mobile authentication module; the mobile authentication module sends the identity ID to the IoT device via the NFC module; the IoT device returns the identity ID to the IoT device backend; the IoT device backend performs business logic verification on the user holding the identity ID, and sends the corresponding control command to the IoT device based on the verification result. The control command instructs the IoT device to perform the first operation, such as opening a gate.

[0261] Figure 12 shows a schematic diagram of the structure of an electronic device 100 according to an embodiment of this application.

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

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

[0264] Processor 110 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0265] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0266] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0267] In some embodiments, the processor 110 of the electronic device 100 executes the verification method described above by calling program instructions stored in the memory. For example, it receives a first message sent by a second terminal device, wherein the first message instructs the first terminal device to obtain an identity identifier; it sends a second message to the second terminal device, wherein the second message includes an identity identifier, the identity identifier representing the identity information of the first terminal device, and the second message instructs the second terminal device to determine the verification result of the identity identifier through a second server, and determines whether to perform the first operation on the second terminal device based on the verification result.

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

[0269] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0270] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

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

[0272] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

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

[0274] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0275] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0276] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

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

[0278] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A may be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When a force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 may also calculate the touch position based on the detection signal from pressure sensor 180A.

[0279] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0280] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0281] Figure 13 is a software structure block diagram of an electronic device 100 according to an embodiment of the present invention.

[0282] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android Runtime, the system layer, and the kernel layer.

[0283] The application layer can include a series of application packages. As shown in Figure 13, these application packages can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, dual SIM and mobile network. Users can capture images and record videos in real time by activating the camera application or the QR code scanning application.

[0284] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0285] As shown in Figure 13, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0286] The Android Runtime consists of core libraries and a virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system.

[0287] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0288] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0289] Accordingly, embodiments of this application provide an electronic device, including: a memory for storing instructions executed by one or more processors of the electronic device, and a processor for executing instructions of the verification method described above.

[0290] Accordingly, embodiments of this application provide a storage medium storing instructions, which, when executed on an electronic device, cause the electronic device to perform the verification method described above.

[0291] Accordingly, this application provides a chip, which includes programmable logic circuits and / or program instructions, and implements the above-described verification method when the chip is running.

[0292] Accordingly, embodiments of this application provide a computer program product, including: a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium containing computer program code for performing the verification method described above.

[0293] This specification provides the methods or processes shown in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one of many execution orders and does not represent the only execution order. In actual execution, the methods or processes shown in the embodiments or drawings can be executed in sequence or in parallel (e.g., in a parallel controller or multi-threaded processing environment).

[0294] The embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0295] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0296] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0297] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried on or stored thereon on one or more transient or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media can include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, compact flash-read-only memory (CD-ROMs), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagation signals. Therefore, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0298] As used herein, the term “module” may refer to, as part of, or include: a memory (shared, dedicated, or grouped) for running one or more software or firmware programs, an application-specific integrated circuit (ASIC), electronic circuitry and / or a processor (shared, dedicated, or grouped), combinational logic circuitry, and / or other suitable components that provide the said functionality.

[0299] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order is not necessary. Rather, in some embodiments, these features may be illustrated in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular drawing does not mean that all embodiments need to include such features; in some embodiments, these features may be omitted, or they may be combined with other features.

Claims

1. A verification method, characterized in that, The method is applied to a first terminal device, and comprises: receiving a first message sent by a second terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; sending a second message to the second terminal device, wherein the second message comprises the identity identifier, the identity identifier represents identity information of the first terminal device, and the second message is used to instruct the second terminal device to determine a verification result of the identity identifier through a second server and determine whether to perform a first operation on the second terminal device according to the verification result.

2. The method of claim 1, wherein, The identity identifier comprises a first identity identifier, and the first identity identifier represents identity information of the first terminal device in the second server.

3. The method of claim 2, wherein, The identity identifier further comprises a second identity identifier, and the second identity identifier represents identity information of the first terminal device in a first application provided by the second server.

4. The method according to any one of claims 1 to 3, characterized in that, The first message comprises a service identifier, the service identifier represents service provider information of the second terminal device, and The method further comprises: sending a third message to a first server, wherein the third message comprises an account identifier and the service identifier, and the account identifier represents identity information of the first terminal device in the first server; receiving the identity identifier sent by the first server, wherein the identity identifier is determined by the first server based on the account identifier and the service identifier.

5. The method of claim 4, wherein, The service identifier is a device identifier of the second terminal device.

6. The method of claim 4, wherein, The identity identifier comprises a first identity identifier, the first server stores a first mapping relationship, the first mapping relationship comprises a corresponding relationship between the second server and the service identifier, and The first server is configured to determine the second server corresponding to the service identifier based on the first mapping relationship, and determine the first identity identifier according to the second server and the account identifier.

7. The method of claim 4, wherein, The identity identifier comprises a second identity identifier, the first server stores a second mapping relationship, the second mapping relationship comprises a corresponding relationship between a first application provided by the second server and the service identifier, and The first server is configured to determine the first application corresponding to the service identifier based on the second mapping relationship, and determine the second identity identifier according to the first application and the account identifier.

8. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: sending a fourth message to a first server, wherein the fourth message comprises an account identifier, and the account identifier represents identity information of the first terminal device in the first server; receiving the identity identifier sent by the first server, wherein the identity identifier is determined by the first server based on the account identifier.

9. The method according to any one of claims 1 to 3, characterized in that, The first message comprises a service identifier, the service identifier represents service provider information of the second terminal device, the first terminal device stores a third mapping relationship, the third mapping relationship comprises a corresponding relationship between the service identifier and the identity identifier, and The method further comprises: determining the identity identifier corresponding to the second server based on the third mapping relationship.

10. The method according to any one of claims 1 to 3, characterized in that, In a case where the second server stores an authorization credential corresponding to the identity identifier, the verification result is passed.

11. A method of verification, characterized by, Applied to a second terminal device, comprising: sending a first message to a first terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; receiving a second message sent by the first terminal device, wherein the second message includes the identity identifier, and the identity identifier represents identity information of the first terminal device; determining a verification result of the identity identifier through a second server, and determining whether to perform a first operation on the second terminal device according to the verification result.

12. The method of claim 1, wherein, The identity identifier includes a first identity identifier, and the first identity identifier represents identity information of the first terminal device in the second server.

13. The method of claim 2, wherein, The identity identifier further includes a second identity identifier, and the second identity identifier represents identity information of the first terminal device in a first application provided by the second server.

14. The method according to any one of claims 11-13, characterized in that, The first message includes a service identifier, and the service identifier represents service party information of the second terminal device.

15. The method of claim 14, wherein, The service identifier is a device identifier of the second terminal device.

16. The method according to any one of claims 11-13, characterized in that, The determination of the verification result of the identity identifier through the second server includes: sending a fifth message to the second server, wherein the fifth message includes the identity identifier, and the second server is used to determine the verification result of the identity identifier; receiving the verification result of the identity identifier sent by the second server.

17. The method according to any one of claims 11-13, characterized in that, In a case where the second server stores an authorization credential corresponding to the identity identifier, the verification result is passed.

18. A verification system, comprising: Comprising a first terminal device and a second terminal device, wherein The first terminal device is used to receive a first message sent by the second terminal device, wherein the first message is used to instruct the first terminal device to obtain an identity identifier; and send a second message to the second terminal device, wherein the second message includes the identity identifier, and the identity identifier represents identity information of the first terminal device. The second terminal device is used to determine a verification result of the identity identifier through a second server, and determine whether to perform a first operation on the second terminal device according to the verification result.

19. An electronic device, comprising: Comprising: a memory for storing instructions executed by one or more processors of an electronic device, and a processor, when the processor executes the instructions in the memory, can make the electronic device execute the method of any one of claims 1-17.

20. A storage medium, characterized by The storage medium has instructions stored thereon, and the instructions, when executed on an electronic device, cause the electronic device to execute the method of any one of claims 1-17.

21. A computer program product, comprising: A non-volatile computer readable storage medium, the non-volatile computer readable storage medium contains computer program code for executing the method of any one of claims 1-17.

Images