An authentication method, system and device

Abstract

The application discloses an authentication method, system and device, and the method comprises the following steps: a client device sends a request for applying for a client identifier to a terminal device, the terminal device requests a push server to allocate the client identifier, receives the client identifier returned by the push server and sends the client identifier to the client device, and the push server successfully authenticates the client device based on the client identifier and opens the push permission of the terminal device. Without the need of user registration account password, the application effectively authenticates the client device, so that the user can realize the technical purpose of the authentication of the client device by the push server and the safe acquisition of the specified terminal device related data by the client device without the account system. The application also discloses a corresponding authentication system and device.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication security technology, and in particular to an authentication method, system, and device. Background Technology

[0002] With the rapid popularization of IoT technology, the scale of device interconnection in fields such as security monitoring, smart homes, and industrial IoT is growing exponentially. In multi-device interconnection scenarios, the communication security between client devices (such as mobile phones and tablets) and terminal devices (such as cameras, sensors, and smart home appliances) relies on efficient and reliable authentication mechanisms. The core requirement is to verify the legitimacy of the client device's identity while ensuring real-time performance and low power consumption, preventing unauthorized device access or data leakage.

[0003] The current mainstream IoT authentication technology is based on account and password authentication. This mode requires users to register an account and set a password on the client device, and then complete the identity verification by entering the account and password.

[0004] The IoT authentication model based on account passwords has the following significant problems: users need to change their passwords regularly to ensure security, which significantly increases the user's memory burden. At the same time, when users forget their account passwords, the client devices cannot pass the server's legitimacy verification, which seriously affects the user experience. Summary of the Invention

[0005] This application provides an authentication method, system, and device, which aims to achieve secure authentication without requiring users to register account passwords.

[0006] In a first aspect, embodiments of this application provide an authentication method applied to a terminal device, comprising: receiving a first request sent by a client device, the first request being used to request the terminal device to request a push server to issue a client identifier for the client device, wherein the client identifier is used by the push server to verify the client device; sending a second request to the push server, the second request being used to request the push server to issue a client identifier for the client device; receiving the client identifier returned by the push server based on the second request; and sending the client identifier to the client device so that the client device can carry the client identifier to the push server to enable push permissions for the terminal device.

[0007] Based on the above implementation method, without requiring users to register an account and password, the client device can obtain the client identifier, thereby enabling the push server to effectively verify the client device and achieve the technical effect of secure authentication.

[0008] One possible implementation of the method further includes: verifying the client device; the verification of the client device includes: the terminal device receiving a login request initiated by the client device, and if the client device successfully logs into the terminal device, then the client device is verified.

[0009] Based on the above implementation method, the client device gains the trust of the terminal device through the verification of the client device by the terminal device.

[0010] In one possible implementation, the method further includes: before sending a second request to the push server, the terminal device sends a third request to the authentication server, the third request being used to request identity authentication from the authentication server; and receiving an authentication success result returned from the authentication server.

[0011] Based on the above implementation, the terminal device can obtain the successful identity authentication result issued by the authentication server, thereby gaining the trust of the push server.

[0012] In one possible implementation, the second request carries the authentication success result, which is used by the push server to verify that the terminal device has passed the authentication.

[0013] Based on the above implementation method, the push server can verify the terminal device.

[0014] In one possible implementation, the authentication success result returned by the authentication server carries a first authentication token, which has a first expiration time. The method further includes: after receiving the first expiration time of the first authentication token, the terminal device sends a new third request to the authentication server; receives a second authentication token generated by the authentication server for the terminal device based on the new third request; or receives an update feedback from the authentication server on the validity period of the first authentication token based on the new third request.

[0015] Based on the above implementation, the authentication token has an expiration time and can be updated after expiration, which improves security.

[0016] Secondly, this application also provides an authentication method applied to a client device. The method includes: sending a first request to a terminal device, the first request being used to request the terminal device to request a push server to issue a client identifier to the client device, wherein the client identifier is used by the push server to verify the client device; receiving the client identifier returned from the terminal device; and sending a fourth request to the push server, the fourth request being used to request the push server to enable push permissions for the terminal device, wherein the fourth request carries the client identifier.

[0017] Based on the above implementation method, without requiring users to register an account and password, the client device can obtain the client identifier, thereby enabling the push server to effectively verify the client device and achieve the technical effect of secure authentication.

[0018] One possible implementation of the method further includes: initiating a login request to the terminal device and successfully logging into the terminal device.

[0019] Based on the above implementation method, the client device gains the trust of the terminal device through the verification of the client device by the terminal device.

[0020] In one possible implementation, the client identifier has a second expiration time, and the method further includes: after receiving the second expiration time of the client identifier, the client device sends a fifth request to the push server, wherein the fifth request is used to request the push server to issue a new client identifier for the client device or extend the validity period of the current client identifier of the client device; receiving the new client identifier issued by the push server for the client device based on the fifth request, and sending a sixth request to the push server; or, receiving the update feedback from the push server on the validity period of the client identifier based on the fifth request; wherein the sixth request is used to request the push server to enable new push permissions for the terminal device, or the sixth request is used to request the push server to associate the push permissions of the expired client identifier with the new client identifier, wherein the sixth request carries the new client identifier.

[0021] Based on the above implementation, the client identifier has an expiration time and can be updated after expiration, which improves security.

[0022] Thirdly, this application also provides an authentication method applied to a push server. The method includes: receiving a second request from a terminal device, the second request being used by the push server to issue a client identifier to a client device, wherein the client identifier is used by the push server to verify the client device; generating the client identifier based on the second request and sending it to the terminal device; and receiving a fourth request from the client device, wherein the fourth request is used to grant the client device push permissions to the terminal device, and the fourth request carries the client identifier.

[0023] Based on the above implementation method, without requiring users to register an account and password, the client device can obtain the client identifier, thereby enabling the push server to effectively verify the client device and achieve the technical effect of secure authentication.

[0024] In one possible implementation, the method further includes: the second request carrying an authentication success result issued by the authentication server to the terminal device, the authentication success result being used by the push server to verify that the terminal device has passed the authentication.

[0025] Based on the above implementation method, the push server can verify the terminal device.

[0026] In one possible implementation, the client identifier has a second expiration time, and the method further includes: receiving a fifth request sent by the client device, wherein the fifth request is used by the client device to request the push server to issue a new client identifier for the client device or extend the validity period of the current client identifier of the client device; based on the new client identifier issued to the client device by the fifth request, receiving a sixth request sent by the client device, wherein the sixth request is used to request the push server to enable new push permissions for the terminal device, or, the sixth request is used to request the push server to associate the push permissions of the expired client identifier with the new client identifier, wherein the sixth request carries the new client identifier; or, based on the fifth request, extending the validity period of the current client identifier of the client device.

[0027] Based on the above implementation, the client identifier has an expiration time and can be updated after expiration, which improves security.

[0028] Fourthly, this application also provides an authentication system, the system comprising a client device, a terminal device, and a push server; wherein, the client device sends a first request to the terminal device, the first request being used to request the terminal device to request the push server to issue a client identifier for the client device, the client identifier being used by the push server to verify the client device; the terminal device sends a second request to the push server, the second request being used to request the push server to issue a client identifier for the client device; the push server generates the client identifier based on the second request and sends the client identifier to the terminal device; the terminal device sends the client identifier to the client device; the client device sends a fourth request to the push server, the fourth request being used to request the push server to enable push permissions for the terminal device, wherein the fourth request carries the client identifier.

[0029] Fifthly, this application also provides a terminal device, including: a sending module configured to send a second request to a push server and send a client identifier to a client device, wherein the second request is used to request the push server to issue the client identifier to the client device, and the client identifier is used by the push server to verify the client device; and a receiving module configured to receive a first request sent by the client device and receive the client identifier generated by the push server, wherein the first request is used to request the terminal device to request the push server to issue the client identifier to the client device.

[0030] Sixthly, this application also provides a client device, including: a sending module configured to send a first request to a terminal device and a fourth request to a push server, wherein the first request is used to request the terminal device to request the push server to issue a client identifier to the client device, and the fourth request is used to request the push server to enable push permissions for the terminal device, wherein the client identifier is used by the push server to verify the client device, and the fourth request carries the client identifier; and a receiving module configured to receive the client identifier sent by the terminal device.

[0031] In a seventh aspect, this application also provides a push server, comprising: a sending module configured to send a client identifier to a terminal device, the client identifier being used by the push server to verify the client device; and a receiving module configured to receive a second request sent by the terminal device and a fourth request from the client device, the fourth request being used to request the push server to enable push permissions for the terminal device, wherein the fourth request carries the client identifier.

[0032] Eighthly, this application also provides a terminal device, including: a processor for executing a program stored in a memory, wherein when the program is executed, the terminal device performs a method as implemented in any of the first aspects.

[0033] In a ninth aspect, this application also provides a client, comprising: a processor for executing a program stored in a memory, wherein when the program is executed, the terminal device performs a method as implemented in any of the second aspects.

[0034] In a tenth aspect, this application also provides a push server, comprising: a processor for executing a program stored in a memory, wherein when the program is executed, the push server performs a method as implemented in any of the third aspects.

[0035] In an eleventh aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, causes the method of any one of the first, second, and third aspects to be executed.

[0036] The beneficial effects of the system embodiments and device embodiments of the fourth to eleventh aspects described above can be referred to the beneficial effects of the corresponding methods in any possible implementation of the first to third aspects described above, and will not be repeated here.

[0037] In summary, the authentication method, system, and device provided in this application have the following beneficial effects: the push server effectively authenticates the client without requiring the user to register an account and password, so that the user can achieve the technical purpose of secure authentication of the client device by the push server without an account system. Attached Figure Description

[0038] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, wherein: Figure 1 A schematic diagram of the system architecture provided for one embodiment of this application; Figure 2 A schematic flowchart of an authentication method on the terminal device side provided in one embodiment of this application; Figure 3 Another flowchart illustrating the authentication method on the terminal device side provided in one embodiment of this application; Figure 4 Another flowchart illustrating the authentication method on the terminal device side provided in one embodiment of this application; Figure 5 Another flowchart illustrating the authentication method on the terminal device side provided in one embodiment of this application; Figure 6 A schematic flowchart of an authentication method on the client device side provided in one embodiment of this application; Figure 7 Another flowchart illustrating the authentication method on the client device side provided in one embodiment of this application; Figure 8 Another flowchart illustrating the authentication method on the client device side provided in one embodiment of this application; Figure 9 A flowchart illustrating an authentication method on the push server side provided in one embodiment of this application; Figure 10 Another flowchart illustrating the authentication method on the push server side provided in one embodiment of this application; Figure 11 A flowchart illustrating an authentication method provided in one embodiment of this application; Figure 12 A module block diagram of a terminal device provided in one embodiment of this application; Figure 13 This is a schematic diagram of the structure of a terminal device provided in one embodiment of this application; Figure 14 A module block diagram of a client device provided in one embodiment of this application; Figure 15 A schematic diagram of the structure of a client device provided in one embodiment of this application; Figure 16 A block diagram of a push server provided in one embodiment of this application; Figure 17 This is a schematic diagram of a push server provided in one embodiment of this application. Detailed Implementation

[0039] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. Obviously, the described embodiments are some, but not all, embodiments of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the embodiments of this application, and should not be construed as limiting the embodiments of this application.

[0040] It should be noted that, in this disclosure, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this disclosure may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0041] It should be understood that although the steps in the flowcharts of the embodiments of this disclosure are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this disclosure, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0042] It should be noted that step codes such as 101 and 102 are used in this disclosure for the purpose of more clearly and concisely describing the corresponding content, and do not constitute a substantial restriction on the order. When implementing the procedure, those skilled in the art may execute 102 first and then 101, etc., but these should all be within the protection scope of this disclosure.

[0043] In this disclosure, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this disclosure can be combined with other embodiments.

[0044] A system architecture diagram of one embodiment disclosed in this application is shown below. Figure 1As shown, it includes: client device 1, terminal device 2, push server 3, and authentication server 4. Client device 1, terminal device 2, and push server 3 can all communicate with each other via wireless communication. Authentication server 4 and push server 3 are located in the same cloud internal network and communicate with each other through the cloud internal LAN, virtual private network, or internal interface.

[0045] Specifically, client device 1 can be a mobile phone, tablet, or other device, running a client application (such as an APP). Client device 1 completes the corresponding operations through the client application. Terminal device 2 can be a terminal device in the Internet of Things (IoT) with communication capabilities and built-in authentication parameters (such as a network camera, smart monitoring device, etc.). Push server 3 is a server that implements message push and client authentication based on device identification routing, long connection management, and token trust verification. It can be deployed independently, such as as a standalone server, virtual machine, container, or microservice cluster, or it can be deployed in conjunction with the business server, running in different processes, modules, and services within a physical machine, virtual machine, or container.

[0046] The technical solutions of this application embodiment can be applied to various communication systems, especially suitable for various systems in IoT scenarios that require account-free trusted interconnection between client devices and terminal devices. That is, the above system architecture diagram can be used for various communication systems or various systems in IoT scenarios. For example, security monitoring systems, such as remote video viewing systems, intelligent access control linkage systems, emergency alarm push systems, etc., are adapted to the permission application and data push between user clients and security devices such as monitoring cameras, access controllers, and infrared alarms; for example, when terminal device 1 collects an alarm, it can push an alarm notification to terminal device 2 through push server 3.

[0047] Smart home control systems, such as whole-house smart ecosystem interconnection systems, single-brand smart device control platforms, and home smart gateway linkage systems, enable user clients to quickly interconnect and transmit control commands to devices such as smart air conditioners, security cameras, smart door locks, and robot vacuum cleaners without accounts. Industrial Internet of Things (IoT) control systems, such as monitoring systems covering factory production line equipment, industrial gateway data acquisition systems, and remote equipment operation and maintenance management platforms, support secure authentication and data interaction between operation and maintenance terminals and devices such as PLC controllers, industrial sensors, and industrial robots.

[0048] In another embodiment of this application, the system architecture may further include an authentication server 4. Specifically, the authentication server 4 is a cloud-based security authentication device used to authenticate the legitimacy of the terminal, issue authentication tokens, and maintain the legitimate status of the terminal. The authentication server 4 and the push server 3 are located in the same cloud internal network and communicate with each other through the cloud internal LAN, virtual private network, or internal interface, without transmitting through the public network, thus ensuring communication security.

[0049] One embodiment of this application provides an authentication method applied to a terminal device. In embodiments of this disclosure, such as... Figure 2 As shown, the method includes: Step S101: Receive a first request sent by the client device. The first request is used to request the terminal device to request the push server to issue a client identifier for the client device.

[0050] Specifically, the push server is responsible for generating and distributing client IDs, assigning a unique identifier to each client device for authentication before push notifications. It also manages and maintains push permissions, enabling or disabling push permissions for specific client devices and establishing push relationships between client and terminal devices. Furthermore, it handles message routing and scheduling, forwarding push messages to the corresponding push gateway for final delivery to the client device. The client ID is a unique, unforgeable, and expiration-sensitive identity credential generated and assigned to the client device by the push server. The client ID can be generated by the push server using a custom encoding method based on a random number, unique device identifier, timestamp, hash value, and a server's asymmetric encryption private key for digital signature. Alternatively, it can be generated in JWT format based on a header, payload, and signature, or using UUIDv4 to bind the device UID and expiration time. The client ID uses a tamper-proof encoding format, containing identity information, expiration information, and the server's signature, ensuring it cannot be illegally tampered with or forged. The push server binds and stores the client ID to the client device's identity.

[0051] Since the client device itself does not carry authentication parameters that can be used by the server (including the authentication server and the push server) to verify its identity, it cannot prove its legitimacy to the push server on its own. Therefore, it needs to rely on the terminal device to request the issuance of a client identifier from the push server. Step S101 involves receiving a first request initiated by the client device to the terminal device. The purpose of this first request is to request the terminal device to apply for a client identifier from the push server. Specifically, the client identifier is used by the push server to subsequently verify the legitimacy of the client device and serves as the client device's identity credential on the push server side.

[0052] Step S102: Send a second request to the push server. The second request is used to request the push server to issue a client identifier to the client device.

[0053] Specifically, step S102 involves the terminal device sending a second request to the push server. Specifically, after receiving the first request, the terminal device sends a second request to the push server, calling the interface provided by the push server to request the push server to issue a client identifier for the client device. The purpose of step S102 is for the terminal device to establish trust endorsement with the push server based on its own legitimacy, enabling the push server to respond to the request to issue a client identifier for the client device. The input of the second request comes from the internal processing result triggered by the first request received by the terminal device in step S101. After receiving the second request from the terminal device, the push server generates a globally unique client identifier. The client identifier is unique globally within the push server and is used to verify the legitimacy of the client device in subsequent communications.

[0054] Step S103: Receive the client identifier returned by the push server based on the second request.

[0055] Step S104: Send a client identifier to the client device so that the client device can carry the client identifier to the push server to enable the terminal device to push permissions.

[0056] Specifically, step S103 involves the terminal device receiving the client identifier returned by the push server based on the second request. Step S104 involves the terminal device sending the client identifier to the client device, enabling the client device to request push permissions from the push server using the client identifier. Specifically, the terminal device forwards the client identifier received in step S103 to the client device. After obtaining the client identifier, the client device can use it as an identity credential to directly send a request to the push server to grant push permissions, carrying the client identifier in the request. The push server verifies the legitimacy of the client device based on the client identifier and grants the client device push permissions for the terminal device, thus completing the authentication process of the client device by the push server.

[0057] In one embodiment, after obtaining a client identifier, the client device can use the client identifier as an identity credential to send a request to the terminal device requesting the push server to grant push permissions to the client device, the request carrying the client identifier. Upon receiving the request, the terminal device sends a request to the push server to grant push permissions to the client device, also carrying the client identifier. The push server verifies the legitimacy of the client device based on the client identifier and grants the client device push permissions to the terminal device, thereby completing the push server's authentication process for the client device.

[0058] Through the above steps S101 to S104, the terminal device completes the application and transfer of the client identifier without requiring the user to register an account and password, thereby enabling the push server to effectively verify the legitimacy of the client device and achieve the technical effect of secure authentication.

[0059] In one embodiment, such as Figure 3 As shown, before step S101, the method further includes step S100a, in which the terminal device receives a login request initiated by the client device and verifies the client device.

[0060] Specifically, before initiating the first request to the terminal device, the client device first sends a login request to the terminal device, attempting to log in. The terminal device receives the login request and verifies the legitimacy of the client device: if the client device successfully logs in, the terminal device determines that the client device has passed verification; if the client device fails to log in, the terminal device determines that the client device has failed verification and rejects the subsequent processing.

[0061] The terminal device only receives the first request sent by the client device after the client device has been authenticated, and then executes steps S101 to S104.

[0062] The purpose of this step is to gain the trust of the client device by verifying the login of the client device through the terminal device, thereby ensuring that the terminal device will not apply for client identifiers on behalf of unauthorized client devices and guaranteeing the security of the authentication process.

[0063] In one embodiment, such as Figure 4 As shown, before step S101, the method further includes steps S100b and S100c. Step S100b is for the terminal device to send a third request to the authentication server. The third request is used to request identity authentication from the authentication server. Step S100c is for the terminal device to receive the authentication success result returned from the authentication server.

[0064] Specifically, the terminal device sends a third request to the authentication server, carrying its own authentication parameters, to request the authentication server to verify the legitimacy of the terminal device. The authentication parameters can be a security code built into the terminal device at the factory, or a key pair held by the terminal device. The third request also carries the terminal device's unique ID.

[0065] Since the terminal device's unique ID, authentication parameters, key, or certificate are pre-programmed and registered in the authentication server's trusted device library during the manufacturing process, the authentication server can verify the identity of the terminal device based on the device ID and authentication parameters.

[0066] Specifically, the device identifier can be generated based on the MAC address, serial number and hash value, or randomly. The identity verification process can be based on a shared key or an asymmetric key. After verifying the legitimacy of the terminal device, the authentication server returns a successful authentication result to the terminal device. In this embodiment, the successful authentication result may specifically include a device authentication token issued by the authentication server to the terminal device. The device authentication token is bound to the device identifier of the terminal device and can only be used to operate the relevant resources of the terminal device corresponding to that specific device identifier; it cannot be used to operate the relevant resources of other terminal devices without authorization. The authentication token uses a private key signing and public key verification mechanism, making it unforgeable and unalterable.

[0067] In one embodiment, the second request carries an authentication success result, which is used to push the server to verify that the terminal device has passed authentication.

[0068] Specifically, after completing step S100c, the terminal device attaches the authentication success result to the second request and sends it to the push server. Since the terminal device obtains the authentication server's trust endorsement after receiving the authentication success result, it has the prerequisite to initiate the second request to the push server. In this embodiment, the authentication success result can specifically be a device authentication token issued by the authentication server to the terminal device.

[0069] Since the push server and the authentication server are both internal servers in the cloud, they are interconnected through the cloud's internal LAN, Virtual Private Network (VPC), API, or message bus, constituting secure internal cloud communication. Therefore, the push server can identify and verify the successful authentication result issued by the authentication server to the terminal device.

[0070] Specifically, after receiving the second request, the push server verifies the authentication success result carried in the second request to confirm the legitimacy of the terminal device. If the verification is successful, the push server responds to the second request and issues a client identifier to the client device. If the push server fails the verification, it refuses to respond to the second request and terminates the subsequent process.

[0071] By carrying the authentication success result in the second request, the push server can verify the legitimacy of the requesting terminal device before issuing a client identifier to the client device. This ensures that the client identifier is applied for only by authenticated and legitimate terminal devices, preventing unauthorized devices from impersonating legitimate terminal devices to make requests to the push server, and further guaranteeing the security of the authentication process.

[0072] In one embodiment, the authentication success result returned by the authentication server carries a first authentication token, which has a first expiration time.

[0073] Specifically, the first authentication token includes: device identifier, generation time, expiration time, permission scope, and server signature. After expiration, the first authentication token cannot be verified by the push server. Before the first expiration time arrives, the terminal device can continue to send requests to the push server using the first authentication token. By setting a first expiration time for the first authentication token, abuse due to prolonged holding of the token can be prevented, thereby improving the security of the authentication process.

[0074] In one embodiment, such as Figure 5 As shown, the method also includes step S200, in which the terminal device sends a new third request to the authentication server after receiving the first expiration time of the first authentication token.

[0075] Specifically, after the first authentication token expires, the terminal device sends a new third request to the authentication server to request the authentication server to re-authenticate the terminal device or renew the existing token. The format of the new third request is the same as that of the third request in step S100a, and it also carries the authentication parameters and device identifier of the terminal device.

[0076] The authentication server responds to the new third-party request in two ways. The steps for the terminal device based on the two response methods are steps S201a and S201b, respectively.

[0077] Specifically, based on a new third-party request, the authentication server responds in one of two ways: In one implementation, step S201a involves the terminal device receiving a second authentication token. Specifically, the authentication server regenerates a second authentication token for the terminal device based on the new third request, and the terminal device receives the second authentication token. The second authentication token replaces the first authentication token and serves as the valid identity credential carried by the terminal device when subsequently initiating requests to the push server.

[0078] In another implementation, step S201b involves the terminal device receiving an update feedback from the authentication server regarding the validity period of the first authentication token based on a new third request. Specifically, the authentication server extends the validity period of the first authentication token based on the new third request and returns an update feedback to the terminal device, which then receives the update feedback. At this point, the content of the first authentication token remains unchanged; only its validity period is extended, and the terminal device continues to use the first authentication token to communicate with the push server.

[0079] It should be noted that steps S201a and S201b are parallel optional implementation methods. The specific method adopted is determined by the authentication server's strategy and does not affect the core objective of the terminal device obtaining a continuously valid identity credential.

[0080] One embodiment of this application also provides an authentication method applied to a client device. In embodiments of this disclosure, such as... Figure 6 As shown, the method includes: Step S301: Send a first request to the terminal device. The first request is used to request the terminal device to request the push server to issue a client identifier for the client device.

[0081] Specifically, the client device proactively initiates a first request to the terminal device, requesting the terminal device to apply for a client identifier from the push server on its behalf. The client device itself does not carry authentication parameters for the server to verify its identity and cannot prove its legitimacy to the push server on its own. Therefore, it needs to rely on the terminal device as a trusted intermediary, using its own legitimacy to apply for the client identifier from the push server. The client identifier is used by the push server to subsequently verify the legitimacy of the client device and serves as the client device's identity credential on the push server side. The output of this step is the first request, which is transmitted to the terminal device, which then executes the subsequent process of applying for the client identifier from the push server.

[0082] Step S302: Receive the client identifier returned from the terminal device.

[0083] Specifically, after requesting and obtaining the client identifier from the push server, the terminal device forwards the client identifier to the client device, which then receives it. The client identifier is globally unique within the push server and is used to identify the client device and serve as its identity credential for subsequent communication with the push server.

[0084] After receiving the client identifier, the client device can register a push token with a push gateway (such as FCM, APN, etc.) to establish a push association between the client device and the terminal device, preparing for the subsequent activation of push permissions. It should be noted that push token registration is not limited to the aforementioned push gateways; those skilled in the art can choose according to the actual deployment environment.

[0085] Step S303: Send a fourth request to the push server. The fourth request is used to request the push server to enable push permissions for the terminal device. The fourth request carries the client identifier.

[0086] Specifically, after obtaining the client identifier, the client device uses it as an identity credential to send a fourth request directly to the push server, requesting the push server to grant the client device push permissions. The fourth request carries the client identifier, and the push server verifies the client device's legitimacy based on this identifier. If the verification is successful, the push server grants the client device push permissions, thus completing the push server's authentication process for the client device.

[0087] In one embodiment, after obtaining a client identifier, the client device can use the client identifier as an identity credential to send a request to the terminal device requesting the push server to grant push permissions to the client device, the request carrying the client identifier. Upon receiving the request, the terminal device sends a request to the push server to grant push permissions to the client device, also carrying the client identifier. The push server verifies the legitimacy of the client device based on the client identifier and grants the client device push permissions to the terminal device, thereby completing the push server's authentication process for the client device.

[0088] Through the steps S301 to S303 described above, the client device can achieve the technical effect of secure authentication by relying solely on the client identifier to pass the legality verification of the push server without requiring the user to register an account and password.

[0089] In one embodiment, such as Figure 7 As shown, before step S301, the method further includes step S300, in which the client device initiates a login request to the terminal device and successfully logs in to the terminal device.

[0090] Specifically, before sending the first request, the client device first initiates a login request to the terminal device, attempting to log in. After receiving the login request, the terminal device verifies the legitimacy of the client device. If the client device successfully logs in, the terminal device determines that the client device has passed verification and gains the client device's trust; if the client device fails to log in, the login fails, the client device cannot send the first request to the terminal device, and the subsequent process terminates.

[0091] The purpose of this step is to gain the trust of the client device by logging into the terminal device, ensuring that the terminal device only requests the client identifier from the push server on behalf of the verified legitimate client device. This prevents unauthorized client devices from obtaining the client identifier through the legitimate terminal device, thus guaranteeing the security of the authentication process. This step corresponds to the terminal device-side verification logic in step S100 of the aforementioned embodiment where the terminal device is the execution subject, and together they describe the respective execution actions of the client device and the terminal device during the same login verification interaction.

[0092] In one embodiment, the client identifier has a second expiration time.

[0093] Specifically, the client identifier received by the client device in step S302 has a second expiration time. Before the second expiration time arrives, the client device can continue to communicate with the push server using the client identifier. By setting a second expiration time for the client identifier, abuse due to prolonged holding of the client identifier can be prevented, thereby improving the security of the authentication process.

[0094] In one embodiment, such as Figure 8 As shown, the method further includes step S401, in which the client device sends a fifth request to the push server after receiving the second expiration time of the client identifier. The fifth request is used to request the push server to issue a new client identifier to the client device or extend the validity period of the current client identifier of the client device.

[0095] Specifically, after the client identifier expires for the second time, the client device directly sends a fifth request to the push server to request the push server to issue a new client identifier or extend the validity period of the current client identifier. The fifth request carries the client identifier so that the push server can identify the client device that initiated the request.

[0096] Based on the fifth request, the push server has two response methods, namely step S402a and step S402b.

[0097] Step S402a involves the client device receiving a new client identifier issued by the push server based on the fifth request; subsequently, a sixth request is sent to the push server, carrying the new client identifier.

[0098] Specifically, the push server issues a new client identifier to the client device based on the fifth request and returns the new client identifier to the client device, which then receives it. After obtaining the new client identifier, the client device sends a sixth request to the push server, which carries the new client identifier.

[0099] The sixth request has two uses: In one implementation, the sixth request is used to request the push server to re-enable the push permission of the terminal device for the client device based on the new client identifier; In another implementation, the sixth request is used to request the push server to associate the push permission corresponding to the expired client identifier with the new client identifier, so as to achieve a smooth migration of push permissions and avoid the additional interaction overhead caused by re-enabling push permissions.

[0100] Step S402b involves receiving the push server's update feedback on the validity period of the client identifier based on the fifth request.

[0101] Specifically, based on the fifth request, the push server extends the validity period of the client identifier currently held by the client device and returns an update feedback to the client device, which receives the update feedback. At this time, the content of the client identifier remains unchanged, only its validity period is extended. The client device can continue to use the original client identifier to communicate with the push server without needing to re-enable push permissions.

[0102] It should be noted that steps S402a and S402b are parallel optional implementation methods. The specific method adopted is determined by the push server's strategy and does not affect the core objective of the client device continuously holding a valid client identifier and maintaining secure communication with the push server.

[0103] One embodiment of this application also provides an authentication method applied to a push server. In embodiments of this disclosure, such as... Figure 9 As shown, the method includes: Step S501: Receive a second request from the terminal device. The second request is used to push the server to issue a client identifier to the client device.

[0104] Specifically, the push server receives a second request from the terminal device, requesting the push server to issue a client identifier to the client device. The client identifier is used by the push server to subsequently verify the legitimacy of the client device and is the client device's unique identity credential on the push server side. Since the client device itself does not carry authentication parameters that the push server can use to verify its identity, it cannot directly prove its legitimacy to the push server. Therefore, the second request is sent by the terminal device on its behalf, and the push server indirectly establishes trust in the client device by trusting the terminal device. The input to this step is the second request sent by the terminal device, which triggers the push server to execute step S502, generating a client identifier for the client device.

[0105] Step S502: Generate a client identifier based on the second request and send it to the terminal device.

[0106] Specifically, after receiving and processing the second request, the push server generates a globally unique client identifier to ensure that the identifiers of different client devices do not conflict within the global scope of the push server. The push server sends the client identifier to the terminal device, which then forwards it to the client device. The output of this step is a globally unique client identifier, which, after being relayed through the terminal device, finally reaches the client device, which uses it in the fourth request sent to the push server in subsequent step S503.

[0107] Step S503: Receive a fourth request sent by the client device. The fourth request is used to enable push permissions for the terminal device for the client device. The fourth request carries the client identifier.

[0108] Specifically, after obtaining the client identifier, the client device uses it as an identity credential to send a fourth request directly to the push server. This fourth request carries the client identifier. Upon receiving the fourth request, the push server verifies the validity of the client identifier carried in the request. If the verification passes, the push server grants the client device push permissions, thus completing the authentication process for the client device. If the verification fails, the push server refuses to respond to the fourth request and terminates the subsequent process.

[0109] In one embodiment, after obtaining a client identifier, the client device can use the client identifier as an identity credential to send a request to the terminal device requesting the push server to grant push permissions to the client device, the request carrying the client identifier. Upon receiving the request, the terminal device sends a request to the push server to grant push permissions to the client device, also carrying the client identifier. The push server verifies the legitimacy of the client device based on the client identifier and grants the client device push permissions to the terminal device, thereby completing the push server's authentication process for the client device.

[0110] Through the steps S501 to S503 described above, the push server issues the client identifier to the client device without requiring the user to register an account and password. This enables the push server to effectively verify the legitimacy of the client device and achieves the technical effect of secure authentication.

[0111] In one embodiment, in step S501, the push server receives a second request from the terminal device. The second request carries the authentication success result issued by the authentication server to the terminal device. The authentication success result is used by the push server to verify that the terminal device has passed the authentication.

[0112] Specifically, after receiving the second request, the push server verifies the authentication success result carried in the second request to verify the legitimacy of the terminal device that issued the request. In this embodiment, the authentication success result can specifically be a device authentication token issued by the authentication server to the terminal device. The device authentication token is bound to the device identifier of the terminal device and can only be used to operate the relevant resources of the terminal device corresponding to that specific device identifier. It cannot be used to operate the relevant resources of other terminal devices without authorization.

[0113] The push server verifies the terminal device based on the successful authentication result: if the verification is successful, the push server determines that the terminal device is legitimate, continues to respond to the second request, and executes step S502 to generate a client identifier for the client device; if the verification fails, the push server refuses to respond to the second request and terminates the subsequent process.

[0114] The purpose of this step is to ensure that the client identifier is applied for only by legitimate terminal devices certified by the authentication server by verifying the authentication success result carried by the terminal device through the push server. This prevents unauthorized devices from impersonating legitimate terminal devices to initiate requests to the push server, further ensuring the security of the authentication process. This step echoes the corresponding implementation of claim 4 in the aforementioned embodiments where the terminal device is the execution subject, jointly describing the respective execution actions of the push server and the terminal device during the same authentication success result verification interaction.

[0115] In one embodiment, the client identifier generated by the push server has a second expiration time.

[0116] Specifically, the client identifier generated by the push server for the client device in step S502 has a second expiration time. Before the second expiration time arrives, the client device can continue to communicate with the push server using the client identifier. By setting a second expiration time for the client identifier, abuse due to prolonged holding of the client identifier can be prevented, thereby improving the security of the authentication process.

[0117] In one embodiment, such as Figure 10 As shown, the method further includes: step S601, receiving a fifth request sent by the client device, the fifth request being used by the client device to request the push server to issue a new client identifier for the client device or extend the validity period of the current client identifier of the client device.

[0118] Specifically, after the client identifier expires for the second time, the client device sends a fifth request to the push server to request the push server to issue a new client identifier. After receiving the fifth request, the push server can process it in two ways, as described in steps S602a and S602b.

[0119] Step S602a issues a new client identifier to the client device; receives a sixth request sent by the client device, the sixth request carrying the new client identifier.

[0120] Specifically, based on the fifth request, the push server issues a new client identifier to the client device and sends the new client identifier to the client device. The push server then receives a sixth request from the client device, which carries the new client identifier.

[0121] The sixth request has two uses: In one implementation, the sixth request is used to request the push server to re-enable the push permission of the terminal device for the client device based on the new client identifier. The push server responds to the sixth request and enables the new push permission for the client device. In another implementation, the sixth request is used to request the push server to associate the push permission corresponding to the expired client identifier with the new client identifier. The push server responds to the sixth request and smoothly migrates the original push permission to the new client identifier to avoid the additional interaction overhead caused by re-enabling the push permission.

[0122] Step S602b extends the validity period of the current client identifier of the client device.

[0123] Specifically, based on the fifth request, the push server extends the validity period of the client identifier currently held by the client device and returns an update feedback to the client device. At this time, the content of the client identifier remains unchanged, only its validity period is extended. The client device can continue to use the original client identifier to communicate with the push server without having to re-execute the push permission activation process.

[0124] It should be noted that steps S602a and S602b are parallel optional implementations, and the specific method adopted is determined by the push server's strategy. This does not affect the core objective of the client device continuously holding a valid client identifier and maintaining secure communication with the push server. This embodiment echoes the implementation of claim 8 in the aforementioned embodiments where the client device is the execution subject, jointly describing the respective execution actions of the push server and the client device during the interaction process of handling the expiration of the same client identifier.

[0125] One embodiment of this application also provides an authentication system. In embodiments of this disclosure, such as... Figure 11 As shown, the system includes: terminal devices, push server, authentication server, and client devices.

[0126] In step S1, the client device sends a first request to the terminal device. This first request requests the terminal device to request the push server to issue a client identifier for the client device. The client identifier is used by the push server to verify the client device. Specifically, the client device can be a mobile phone, tablet, etc., and an application, such as an app, is running on it.

[0127] Step S2 involves the client device initiating a login request to the terminal device. If the login is successful, the next steps will proceed. Step S3 involves the terminal device sending a third request to the authentication server, which is used to request identity authentication from the authentication server. Step S4 involves the authentication server verifying the legitimacy of the terminal device. Specifically, the terminal device sends a third request to the authentication server, carrying its own authentication parameters, to request the authentication server to verify the legitimacy of the terminal device. The authentication parameters can be a security code built into the terminal device at the factory, or a key pair held by the terminal device. The third request also carries the terminal device's unique ID.

[0128] Step S5 involves the authentication server sending an authentication success result to the terminal device. Specifically, the authentication success result may include a device authentication token issued by the authentication server to the terminal device. This device authentication token is bound to the terminal device's device identifier and can only be used to operate the resources of the terminal device corresponding to that specific device identifier. It cannot be used to operate the resources of other terminal devices without authorization. The authentication token uses a private key signing and public key verification mechanism, making it impossible to forge or tamper with.

[0129] Step S6 involves the terminal device sending a second request to the push server. This second request requests the push server to issue a client identifier to the client device. Specifically, the terminal device can be a terminal device with communication capabilities and built-in authentication parameters in the Internet of Things (IoT) field, such as a network camera or smart monitoring device.

[0130] Step S7 involves the push server generating a client identifier based on the second request and sending the client identifier to the terminal device. Specifically, the push server is a server that implements message push and client device authentication based on device identifier routing, long connection management, and token trust verification. It can be deployed independently, such as as a standalone server, virtual machine, container, or microservice cluster, or it can be deployed in conjunction with the business server, running in different processes, modules, and services within physical machines, virtual machines, or containers. The push server is responsible for generating and distributing the client identifier (client ID), i.e., assigning a unique identity identifier to the client device for authentication before push; it is also responsible for push permission management and maintenance, i.e., enabling or disabling push permissions for specified devices on the client device and establishing push relationships between the client device and the terminal device; and it is also responsible for message routing and scheduling, i.e., forwarding push messages to the corresponding push gateway and ultimately delivering them to the client device. The client identifier is a unique, unforgeable, and expired identity credential generated and assigned to the client device by the push server. The client identifier can be generated by the push server using a custom encoding method based on a random number, unique device identifier, timestamp, hash value, and a server's asymmetric encryption private key for digital signature. Alternatively, it can be generated in JWT format based on a header, payload, and signature, or by binding the device UID and expiration time using UUIDv4. The client identifier uses a tamper-proof encoding format and includes identity information, expiration information, and the server signature, ensuring it cannot be illegally tampered with or forged. The push server binds and stores the client identifier with the client device identity.

[0131] Step S8 involves the push server sending the client identifier to the terminal device.

[0132] Step S9 involves the terminal device sending a client identifier to the client device.

[0133] Step S10 involves the client device sending a fourth request to the push server. The fourth request requests the push server to grant the terminal device push permissions, and the fourth request carries the client identifier.

[0134] Step S11 involves the terminal device sending a new third request to the authentication server after the first authentication token expires, requesting the authentication server to re-authenticate the terminal device or renew the existing token. The format of the new third request is the same as the third request in step S100a, and it also carries the authentication parameters and device identifier of the terminal device.

[0135] Step S12 involves the authentication server regenerating a second authentication token for the terminal device based on a new third request, or the authentication server extending the validity period of the first authentication token based on a new third request and returning an update feedback to the terminal device.

[0136] Step S13 involves the client device sending a fifth request to the push server after the client identifier has reached the second expiration time, requesting the push server to issue a new client identifier to the client device.

[0137] Step S14 involves the push server generating a new client identifier for the client device based on the fifth request and returning the new client identifier to the client device; or, based on the fifth request, the push server extending the validity period of the client identifier currently held by the client device and returning update feedback to the client device.

[0138] Through the above steps S1 to S14, the push server effectively authenticates the client without requiring the user to register an account and password, so that the user can achieve the technical purpose of the push server's secure authentication of the client device without an account system.

[0139] One embodiment of this application also provides a terminal device, as described in the embodiments of this disclosure, such as... Figure 12 , 13 As shown, the terminal device includes: The sending module 601 is configured to send a second request to the push server and send a client identifier to the client device, wherein the second request is used to request the push server to issue a client identifier to the client device, and the client identifier is used by the push server to verify the client device; The receiving module 602 is configured to receive a first request sent by the client device and a client identifier generated by the push server, wherein the first request is used to request the terminal device to request the push server to issue a client identifier to the client device.

[0140] The processor 701 and the memory 702 store a computer program. When the processor 701 executes the computer program stored in the memory 702, it implements the above-mentioned authentication method.

[0141] One embodiment of this application also provides a client device, as described in this disclosure embodiment, such as Figure 14 , 15 As shown, the client device includes: The sending module 801 is configured to send a first request to the terminal device and a fourth request to the push server. The first request is used to request the terminal device to request the push server to issue a client identifier to the client device. The fourth request is used to request the push server to enable the push permission of the terminal device. The client identifier is used by the push server to verify the client device. The fourth request carries the client identifier. The receiving module 802 is configured to receive the client identifier sent by the terminal device; The processor 901 and the memory 902 store a computer program. When the processor 901 executes the computer program stored in the memory 902, it implements the above-mentioned authentication method.

[0142] This application also provides a push server, as described in the embodiments of this disclosure, such as... Figure 16 , 17 As shown, the push server includes: The sending module 1001 is configured to send a client identifier to the terminal device, which is used to push the server to verify the client device. The receiving module 1002 is configured to receive a second request sent by a terminal device and a fourth request sent by a client device. The fourth request is used to request the push server to enable push permissions for the terminal device, and the fourth request carries a client identifier.

[0143] The processor 1101 and the memory 1102 are provided. The memory 1102 stores a computer program. When the processor 1101 executes the computer program stored in the memory 1102, it implements the above-mentioned authentication method.

[0144] An embodiment of this application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, causes any of the methods described in the above embodiments to be performed.

[0145] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

Claims

1. An authentication method, characterized in that, The method is applied to a terminal device, and the method includes: The terminal device receives a first request from a client device, the first request being used to request the push server to issue a client identifier to the client device, wherein the client identifier is used by the push server to verify the client device; Send a second request to the push server, the second request being used to request the push server to issue a client identifier to the client device; Receive the client identifier returned by the push server based on the second request; The client identifier is sent to the client device so that the client device can use the client identifier to request push access from the push server.

2. The method according to claim 1, characterized in that, The method further includes: verifying the client device; The verification of the client device includes: The terminal device receives a login request initiated by the client device. If the client device successfully logs into the terminal device, the client device is verified.

3. The method according to any one of claims 1 or 2, characterized in that, The method further includes: Before sending the second request to the push server, the terminal device sends a third request to the authentication server, the third request being used to request identity authentication from the authentication server; Receive the authentication success result returned from the authentication server.

4. The method according to claim 3, characterized in that, The second request carries the authentication success result, which is used by the push server to verify that the terminal device has passed the authentication.

5. The method according to any one of claims 3 or 4, characterized in that, The authentication success result returned by the authentication server carries a first authentication token, which has a first expiration time. The method further includes: After receiving the first expiration time of the first authentication token, the terminal device sends a new third request to the authentication server. Receive the second authentication token generated by the authentication server for the terminal device based on the new third request; or, receive the update feedback from the authentication server on the validity period of the first authentication token based on the new third request.

6. An authentication method, characterized in that, The method is applied to a client device, and the method includes: Send a first request to the terminal device, the first request being used to request the terminal device to request the push server to issue a client identifier for the client device, wherein the client identifier is used by the push server to verify the client device; Receive the client identifier returned from the terminal device; A fourth request is sent to the push server, the fourth request being used to request the push server to enable push permissions for the terminal device, wherein the fourth request carries the client identifier.

7. The method according to claim 6, characterized in that, The method further includes: A login request is initiated to the terminal device, and the user successfully logs in to the terminal device.

8. The method according to any one of claims 6 or 7, characterized in that, The client identifier has a second expiration time, and the method further includes: After receiving the second expiration time of the client identifier, the client device sends a fifth request to the push server, wherein the fifth request is used to request the push server to issue a new client identifier to the client device or extend the validity period of the current client identifier of the client device; The system receives a new client identifier issued to the client device by the push server based on the fifth request, and sends a sixth request to the push server; or, the system receives feedback from the push server regarding the validity period of the client identifier based on the fifth request. The sixth request is used to request the push server to grant the terminal device a new push permission, or the sixth request is used to request the push server to associate the expired push permission of the client identifier with the new client identifier, wherein the sixth request carries the new client identifier.

9. An authentication method, characterized in that, The method is applied to a push server, and the method includes: The push server receives a second request from a terminal device, the second request being used by the push server to issue a client identifier to the client device, wherein the client identifier is used by the push server to verify the client device; The client identifier is generated based on the second request and sent to the terminal device. The client device sends a fourth request, wherein the fourth request is used to enable push permissions for the terminal device for the client device, and the fourth request carries the client identifier.

10. The method according to claim 9, characterized in that, The method further includes: The second request carries the authentication success result issued by the authentication server to the terminal device, and the authentication success result is used by the push server to verify that the terminal device has passed the authentication.

11. The method according to any one of claims 9 or 10, characterized in that, The client identifier has a second expiration time, and the method further includes: The fifth request sent by the client device is received, wherein the fifth request is used by the client device to request the push server to issue a new client identifier for the client device or extend the validity period of the current client identifier of the client device; Based on the new client identifier issued to the client device by the fifth request, a sixth request sent by the client device is received, wherein the sixth request is used to request the push server to enable new push permissions for the terminal device, or the sixth request is used to request the push server to associate the push permissions of the expired client identifier with the new client identifier, wherein the sixth request carries the new client identifier; Alternatively, based on the fifth request, extend the validity period of the current client identifier of the client device.

12. An authentication system, characterized in that, The system includes client devices, terminal devices, and a push server; wherein... The client device sends a first request to the terminal device, the first request being used to request the terminal device to request the push server to issue a client identifier for the client device, the client identifier being used by the push server to verify the client device; The terminal device sends a second request to the push server, the second request being used to request the push server to issue a client identifier to the client device; The push server generates the client identifier based on the second request and sends the client identifier to the terminal device; The terminal device sends the client identifier to the client device; The client device sends a fourth request to the push server, the fourth request being used to request the push server to enable push permissions for the terminal device, wherein the fourth request carries the client identifier.

13. A terminal device, characterized in that, include: The sending module is configured to send a second request to the push server and send a client identifier to the client device, wherein the second request is used to request the push server to issue the client identifier to the client device, and the client identifier is used by the push server to verify the client device; The receiving module is configured to receive a first request sent by the client device and to receive the client identifier generated by the push server, wherein the first request is used to request the terminal device to request the push server to issue the client identifier to the client device.

14. A client device, characterized in that, include: The sending module is configured to send a first request to a terminal device and a fourth request to a push server. The first request is used to request the terminal device to request the push server to issue a client identifier to the client device. The fourth request is used to request the push server to enable push permissions for the terminal device. The client identifier is used by the push server to verify the client device. The fourth request carries the client identifier. The receiving module is configured to receive the client identifier sent by the terminal device.

15. A terminal device, characterized in that, include: A processor for executing a program stored in memory, which, when executed, causes the terminal device to perform the method as described in any one of claims 1-5.

16. A client device, characterized in that, include: A processor for executing a program stored in memory, which, when executed, causes the terminal device to perform the method as described in any one of claims 6-8.

17. A push server, characterized in that, include: A processor for executing a program stored in memory, which, when executed, causes the push server to perform the method as described in any one of claims 9-11.

18. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a computer, causes the method of any one of claims 1-11 to be performed.

Images