Device verification method and apparatus, and device and storage medium

Abstract

On the basis of the embodiments of the present disclosure, provided are a device verification method and apparatus, and a device and a storage medium. The method comprises: acquiring an access authorization request from a terminal device, wherein the access authorization request is used for requesting an access permission for a target service, the access authorization request comprises authorization information of the terminal device or information related to a provider of the terminal device, and the target service is at least partially based on a target model; verifying the terminal device on the basis of the access authorization request and service information of the provider, wherein the service information comprises at least one of the following: registration information of the provider for the target service, or authorization information of the target service for the provider; and in response to the terminal device passing the verification, providing the terminal device with authorization information for accessing the target service.

Description

Methods, apparatus, devices, and storage media for device validation Technical Field

[0001] The exemplary embodiments disclosed herein relate generally to the field of computers, and in particular to methods, apparatus, devices, and storage media for device verification. Background Technology

[0002] With the rapid development of machine learning technology, an increasing number of Internet of Things (IoT) devices are providing smarter services and interactive experiences by integrating target models. In this process, IoT devices can perform verification through negotiation with the service provider of the target model. However, maintaining efficiency and security during the verification process remains a critical challenge. Summary of the Invention

[0003] In a first aspect of this disclosure, a device verification method is provided. The method includes: obtaining an access authorization request from a terminal device, the access authorization request requesting access to a target service, and the access authorization request including authorization information of the terminal device or information related to a provider of the terminal device, the target service being at least partially based on a target model; verifying the terminal device based on the access authorization request and service information of the provider, the service information including at least one of the following: registration information of the provider for the target service or authorization information of the target service for the provider; and, in response to the terminal device passing verification, providing the terminal device with authorization information for accessing the target service.

[0004] In a second aspect of this disclosure, a device verification method is provided. The method includes: generating an access authorization request based on authorization information of a terminal device or information of the terminal device's provider, the access authorization request being used to request access rights to a target service, the target service being at least partially based on a target model; providing the access authorization request to a server of the target service; and obtaining authorization information from the server for accessing the target service.

[0005] In a third aspect of this disclosure, an apparatus for device verification is provided. The apparatus includes: an acquisition module configured to acquire an access authorization request from a terminal device, the access authorization request requesting access to a target service, and the access authorization request including authorization information of the terminal device or information related to a provider of the terminal device, the target service being at least partially based on a target model; a verification module configured to verify the terminal device based on the access authorization request and service information of the provider, the service information including at least one of the following: registration information of the provider for the target service or authorization information of the target service for the provider; and a provision module configured to provide authorization information for accessing the target service to the terminal device in response to the terminal device passing verification.

[0006] In a fourth aspect of this disclosure, an apparatus for device verification is provided. The apparatus is applied to a client and includes: a generation module configured to generate an access authorization request based on authorization information of a terminal device or information of a provider of the terminal device, the access authorization request being used to request access rights to a target service, the target service being at least partially based on a target model; a providing module configured to provide the access authorization request to a server of the target service; and an obtaining module configured to obtain authorization information from the server for accessing the target service.

[0007] In a fifth aspect of this disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the methods of the first or second aspect.

[0008] In a sixth aspect of this disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that can be executed by a processor to implement the methods of the first or second aspect.

[0009] It should be understood that the content described in this section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 shows a schematic diagram of an example environment in which embodiments of the present disclosure can be implemented;

[0012] Figure 2 illustrates a schematic diagram of an example interaction process for device verification according to some embodiments of the present disclosure;

[0013] Figure 3 illustrates a flowchart of a device verification process at a server according to some embodiments of the present disclosure;

[0014] Figure 4 illustrates a flowchart of a device verification process at a terminal device according to some embodiments of the present disclosure;

[0015] Figure 5 shows a block diagram of an apparatus for device verification applied to a server according to some embodiments of the present disclosure;

[0016] Figure 6 shows a block diagram of an apparatus for device verification applied to a terminal device according to some embodiments of the present disclosure; and

[0017] Figure 7 shows a block diagram of an apparatus capable of implementing several embodiments of the present disclosure. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below.

[0020] In this document, unless explicitly stated otherwise, performing a step in response to A does not mean that the step is performed immediately after A, but may include one or more intermediate steps.

[0021] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition, use, storage or deletion of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, relevant users should be informed of the type, scope of use, and usage scenarios of the information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and their authorization should be obtained. Among them, relevant users may include any type of rights holder, such as individuals, enterprises, or groups.

[0023] For example, in response to receiving an active request from a user, a prompt message is sent to the relevant user to clearly indicate that the operation requested will require obtaining and using the relevant user's information. This allows the relevant user to choose whether to provide information to the software or hardware such as the electronic device, application, server, or storage medium that performs the operation of the technical solution disclosed herein, based on the prompt message.

[0024] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, for example, via a pop-up window where the prompt message can be presented as text. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide information to the electronic device.

[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0026] In embodiments of this disclosure, the target model can employ any suitable algorithm or operation to implement the described functionality. In some embodiments, the target model may include any appropriate machine learning model. In some embodiments, one or more target models may be constructed based on a language model (LM), such as a large language model (LLM). The machine learning model used may be a content-generative model capable of generating corresponding outputs based on model inputs. In some embodiments, the machine learning model may be a multimodal model capable of receiving textual modal model inputs (e.g., natural language and / or machine language) and / or non-textual modal model inputs (e.g., images, speech, video, etc.), and capable of generating the desired output based on the model inputs and prompts.

[0027] As briefly described above, with the rapid development of machine learning technology, more and more IoT devices are providing smarter services and interactive experiences by integrating target models. Traditionally, device verification schemes utilize traditional device identification mechanisms and negotiations between the IoT device and the target model service provider to perform verification. However, several problems exist in this process. First, traditional device identification mechanisms are imperfect; different IoT devices often lack a unified identification mechanism, making it difficult to effectively manage and track device interface usage. Second, channel management is chaotic; when a device provider collaborates with multiple service providers, it is difficult to accurately distinguish and manage IoT devices from different channels. This can lead to issues such as mixed interface keys and billing confusion.

[0028] According to embodiments of this disclosure, an improved device verification scheme is provided. In this scheme, the server of the target service provider (also known as the service provider) obtains an access authorization request from a terminal device. The access authorization request requests access to the target service, which is at least partially based on a target model. The access authorization request includes authorization information of the terminal device or information related to the terminal device provider (also known as the device provider). Then, the server verifies the terminal device based on the access authorization request and the service information of the terminal device provider. The service information includes at least one of the following: the provider's registration information for the target service or the target service's authorization information for the provider. Subsequently, if the terminal device passes verification, the server provides the terminal device with authorization information for accessing the target service.

[0029] In the embodiments of this disclosure, when a terminal device requests access authorization for a target service from a service provider, it can include its own authorization information or provider-related information in the request. This allows the service provider to establish an association between the terminal device and the device provider upon receiving the access authorization request, thereby verifying the terminal device. This approach improves the accuracy and security of device verification and also enhances device management efficiency in multi-provider scenarios.

[0030] Figure 1 illustrates a schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented. As shown in Figure 1, the example environment 100 may include a terminal device 110, a provider 120 of the terminal device 110 (also referred to as device provider 120), and a supplier 130 of the target service 140 (hereinafter also referred to as supplier 130 or service provider). Provider 120 may be, for example, a manufacturer, distributor, etc. of the terminal device 110. Supplier 130 may provide the target service 140 externally. The target service 140 may provide various suitable services based on a target model (e.g., a machine learning model), such as content generation services, intelligent dialogue services, translation services, etc. Embodiments of the present disclosure are not limited in this respect.

[0031] As shown in Figure 1, the Application Programming Interface (API) service 150 can be deployed in the provider 130, for example, on the provider 130's server. Device authentication can be performed on the terminal device 110 through communication between the terminal device 110 and the provider 130, and through communication between the provider 120 and the provider 130. In some embodiments, the terminal device 110 can invoke the corresponding target service by calling the API associated with the target service in the provider 130.

[0032] Terminal device 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio broadcast receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of user-facing interface (such as "wearable" circuitry).

[0033] In some embodiments, terminal device 110 may include an IoT device. Compared to some terminal devices with strong computing capabilities (e.g., computers, smartphones, etc.), the computing power of IoT devices is typically limited. In this case, the IoT device needs to use the target service 140 provided by provider 130. A non-limiting example of an IoT device is a toy. By using the target service 140, a toy can, for example, interact with a child through conversation. However, it should be understood that this is merely one example of an IoT device and is not intended to be limiting.

[0034] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure. In other words, the structure, function, number, and linkage of the elements in environment 100 can be changed as needed. This disclosure is not limited in this respect.

[0035] Some exemplary embodiments of this disclosure will now be described in detail with reference to the example in Figure 2.

[0036] Figure 2 illustrates an example interaction process 200 for device verification according to some embodiments of the present disclosure. The interaction process 200 includes a terminal device 110, a server 201, and a provider 120. A development platform 202 (hereinafter also referred to as development platform 202) of provider 130 and an interface service 203 (hereinafter also referred to as interface service 203) of provider 130 can be deployed on server 201. For ease of discussion, the interaction process 200 will be described with reference to the environment 100 of Figure 1.

[0037] As shown in Figure 2, during the provider initialization phase, provider 120 applies to development platform 202 for (205) provider qualifications. Development platform 202 reviews (206) the provider qualifications. If the provider qualifications meet the predetermined review conditions, development platform 202 creates (207) a provider account. Then, based on the provider account, development platform 202 generates (208) the private key of provider 120. For example, in an asymmetric encryption algorithm, there are two keys: a public key and a private key. The private key can be used to create digital signatures and decrypt received encrypted information, while the public key can be used to verify digital signatures and encrypted information. Then, development platform 202 sends (209) the private key to provider 120. Correspondingly, development platform 202 can store provider 120's public key.

[0038] During the device authorization phase, terminal device 110 sends a first authorization request (211) to provider 120. The first authorization request can be used to request authorization from service provider 130 for terminal device 110. For example, the first authorization request can be used to request authorization information for terminal device 110. The authorization information can include various suitable types of information. In some embodiments, the authorization information for terminal device 110 can include at least one of a verification code of terminal device 110 or a visual code corresponding to terminal device 110. In some examples, the visual code can be a QR code, which can include static and dynamic QR codes. In some embodiments, the verification code is signed with the private key of provider 120. In some examples, the private key signature can include a digital signature, which can indicate a generation result encrypted with the private key.

[0039] Continuing with reference to Figure 2, an example embodiment where the authorization information is a verification code is described. Provider 120 receives a first authorization request from terminal device 110. Next, provider 120 can generate a verification code for terminal device 110 and sign the verification code using (212) a private key. Then, provider 120 can generate (213) a visual code, such as a QR code, with the verification code. Afterward, provider 120 can return (214) the verification code and the visual code to terminal device 110.

[0040] Accordingly, terminal device 110 receives a verification code and a visual code. For example, a signed verification code may be included within a QR code. In some embodiments, terminal device 110 may utilize a display component to present the visual code to provide it to supplier 130.

[0041] In some embodiments, before the terminal device 110 requests access authorization from the provider 130, a visual code corresponding to the terminal device 110 can be provided to the provider 130, for example, sent to the server 201. After receiving the visual code, the server 201 can extract the verification code of the terminal device 110 from the visual code. Then, the server 201 can verify the verification code using the public key of the provider 120. If the server 201 successfully verifies the verification code, it stores the verification code as a valid verification code. In this embodiment, in subsequent access authorization requests, the server 201 can verify the terminal device based on one or more stored valid verification codes.

[0042] The visual code can be provided to supplier 130 in any suitable manner. For example, terminal device 110 can directly send the visual code to server 201. Alternatively, terminal device 110 can be equipped with a corresponding scanner. The scanner can be a proprietary scanning device or a smart device (e.g., a smartphone) running a relevant application or app.

[0043] Continuing with reference to Figure 2, an example is described. As shown in Figure 2, scanner 204 can scan (215) a visual code to obtain the visual code. In some embodiments, the visual code can be scanned using an application with scanning functionality in terminal device 110. Then, scanner 204 can send (216) the visual code to development platform 202. Development platform 202 can use the public key of provider 120 to verify (217) the validity period of the visual code. If the visual code has not expired, development platform 202 can store the checksum in the visual code as a valid checksum. Then, development platform 202 returns (218) a first verification result to scanner 204.

[0044] If terminal device 110 needs to access target service 140, terminal device 110 requests access authorization from provider 130. In some embodiments, terminal device 110 may generate an access authorization request based on its own authorization information and provide it to server 201 of target service 140. The access authorization request is used to request access rights to target service 140. Accordingly, server 201 receives the access authorization request from terminal device 110. However, server 201 may verify the access authorization request initiated by terminal device 110 based on provider 120's registration or authorization information.

[0045] In some embodiments, the authorization information of the terminal device 110 included in the access authorization request may include the checksum described above. This embodiment will now be described with reference to FIG2. As shown in FIG2, the terminal device 110 sends an access authorization request (219) to the interface service 203 of the provider 130. Accordingly, the interface service 203 receives the access authorization request from the terminal device 110. The interface service 203 extracts the checksum from the access authorization request. Next, the interface service 203 sends the checksum (220) to the development platform 202. The checksum is signed with the private key of the provider 120. The development platform 202 verifies (221) the checksum. For example, the development platform 202 may use the public key of the provider 120 to verify the signature. Alternatively, the development platform 202 may determine whether the checksum is valid based on one or more stored valid checksums. For example, the development platform 202 may compare the received checksum with a stored valid checksum. If the received checksum matches a stored valid checksum, the checksum is determined to be valid. If the verification code is found to be valid, server 201 can determine that terminal device 110 has passed verification. If the verification code is found to be invalid, server 201 can determine that terminal device 110 has failed verification. Then, development platform 202 can send (222) a second verification result to interface service 203. The second verification result indicates whether terminal device 110 has passed verification.

[0046] The second verification result received by interface service 203 may include at least one of verification success or verification failure. In some embodiments, if terminal device 110 passes verification, server 201 provides terminal device 110 with authorization information for accessing target service 140. In some embodiments, the authorization information may include at least an authorized token. Interface service 203 generates (223) an authorized token. Next, interface service 203 returns (224) the authorized token to terminal device 110.

[0047] In the embodiments described above, the access authorization request includes a verification code signed with the provider's private key. This embodiment implements a device identification mechanism based on visual encoding (e.g., QR codes). By associating visual encoding with provider encoding, a clear provider management system can be established, enabling the target service to support device management in multi-provider scenarios. Furthermore, in this embodiment, it is not necessary to expose the key to the terminal device, effectively preventing unauthorized use.

[0048] Alternatively, access authorization requests may include other types of information. An example embodiment of this is described below.

[0049] In some embodiments, the access authorization request may include an access address of terminal device 110 (which can be considered an example of authorization information for terminal device 110). In some examples, the access address may include a Media Access Control (MAC) address. In this embodiment, terminal device 110 may be verified as follows: Before obtaining the access authorization request, server 201 may obtain multiple access addresses from provider 120. Then, server 201 stores the multiple access addresses as part of provider 120's registration information for target service 140. If an access authorization request is obtained from terminal device 110, server 201 may determine the multiple access addresses registered by provider 120 for target service 140 based on provider 120's registration information. Then, if it is determined that the access address of terminal device 110 is one of the multiple access addresses, server 201 determines that terminal device 110 has passed verification.

[0050] In the embodiments described above, the access authorization request includes authorization information from terminal device 110, such as a checksum or access address. Alternatively or additionally, in some embodiments, the access authorization request may include information related to provider 120 of terminal device 110. For example, information related to provider 120 may include a token signed with provider 120's private key. In this embodiment, provider 120's private key may be stored in the hardware of terminal device 110. Provider 120 may provide an access token to terminal device 110, which terminal device 110 may sign with provider's private key. After receiving the access authorization request from terminal device 110, server 201 may determine provider 120's public key based on provider 120's registration information with target service 140. Then, server 201 uses the public key to verify the signature of the token in the access authorization request. If the signature verification is successful, server 201 may determine that terminal device 110 has passed verification. In this embodiment, the authorization information returned to the terminal device includes a positive response to the access authorization request.

[0051] The above describes the device authorization phase. Continuing with Figure 2, in the interface call phase, terminal device 110 initiates an interface call request (231) to interface service 203. Interface service 203 verifies (232) the validity of the token based on the interface call request. If interface service 203 determines the token is valid, it queries (233) the provider quota from development platform 202. Accordingly, development platform 202 returns (235) the quota status to interface service 203. If the quota status indicates that provider 120 has a remaining quota, interface service 203 forwards (236) the API request, returns (237) the processing result, and records (238) the call statistics. Next, interface service 203 returns (239) the interface call result to terminal device 110, thereby providing services to terminal device 110. In some examples, the interface call result may include whether the call was successful and interface information. For example, interface information may indicate which interface was called and information such as interface performance. In this way, device usage can be accurately statistically analyzed for billing and management purposes.

[0052] In some embodiments, authorization information (e.g., access tokens) may be updated, such as periodically or in response to a specific event. In some embodiments, server 201 may receive an update request for authorization information from terminal device 110. In response to the update request, server 201 verifies the validity of the authorization information. If the authorization information is valid, server 201 generates updated authorization information. The updated authorization information is then provided to terminal device 110.

[0053] In some embodiments, the authorization information may include a token from provider 120. Continuing with FIG2, an example is described. As shown in FIG2, during the token refresh phase, terminal device 110 sends (241) an update request for the access token to interface service 203. Interface service 203 verifies (242) the validity of the token and generates (243) an updated token. Interface service 203 returns (244) the updated token to terminal device 110.

[0054] The embodiments of this disclosure can verify terminal devices based on access authorization requests and service information from the provider. Upon successful verification, authorization information for the target service is provided to the terminal device. Through these improvements, each device can be uniquely identified and located, thereby enhancing the accuracy and security of device verification and improving device management efficiency in multi-supplier scenarios.

[0055] Example process

[0056] Figure 3 shows a flowchart of a device verification process 300 for a server according to some embodiments of the present disclosure. Process 300 can be applied to server 201. Process 300 will now be described with reference to Figure 1.

[0057] In box 310, server 201 obtains an access authorization request from a terminal device. The access authorization request is used to request access rights to a target service, and the access authorization request includes authorization information of the terminal device or information related to the provider of the terminal device. The target service is at least partially based on the target model.

[0058] In box 320, server 201 verifies the terminal device based on the access authorization request and the service information of the provider. The service information includes at least one of the following: the provider's registration information for the target service or the target service's authorization information for the provider.

[0059] In box 330, in response to the terminal device passing authentication, server 201 provides the terminal device with authorization information for accessing the target service.

[0060] In some embodiments, the authorization information of the terminal device includes a verification code of the terminal device, which is signed with the provider's private key, and verifying the terminal device includes: determining whether the verification code is valid based on one or more stored valid verification codes; and determining that the terminal device passes verification in response to determining that the verification code is valid.

[0061] In some embodiments, process 300 further includes: before obtaining an access authorization request, obtaining a visual code corresponding to the terminal device, the visual code including a verification code; verifying the verification code using the provider's public key; and in response to successful verification of the verification code, storing the verification code as a valid verification code.

[0062] In some embodiments, the authorization information of the terminal device includes the access address of the terminal device, and verifying the terminal device includes: determining multiple access addresses registered by the provider for the target service based on the provider's registration information for the target service; and determining that the terminal device passes verification in response to determining that the access address of the terminal device is one of the multiple access addresses.

[0063] In some embodiments, process 300 further includes: obtaining multiple access addresses from the provider before obtaining an access authorization request; and storing the multiple access addresses as part of the provider's registration information for the target service.

[0064] In some embodiments, the information associated with the provider of the terminal device includes a token signed with the provider's private key, and verifying the terminal device includes: determining the provider's public key based on the provider's registration information for the target service; verifying the signature of the token using the public key; and determining that the terminal device has passed verification in response to successful signature verification. In other embodiments, the authorization information includes an affirmative response to an access authorization request.

[0065] In some embodiments, process 300 further includes: receiving an update request for authorization information from a terminal device; verifying the validity of the authorization information in response to the update request; generating updated authorization information in response to the validity of the authorization information; and providing the updated authorization information to the terminal device.

[0066] In some embodiments, the terminal device includes an Internet of Things (IoT) device.

[0067] Figure 4 shows a flowchart of a device verification process 400 for a terminal device according to some embodiments of the present disclosure. Process 400 can be applied to terminal device 110. Process 400 will now be described with reference to Figure 1.

[0068] In box 410, terminal device 110 generates an access authorization request based on the terminal device's authorization information or the information of the terminal device's provider. The access authorization request is used to request access permissions for a target service, which is at least partially based on a target model.

[0069] In box 420, terminal device 110 provides an access authorization request to the server of the target service.

[0070] In box 430, terminal device 110 obtains authorization information from the server for accessing the target service.

[0071] In some embodiments, the authorization information of the terminal device includes a verification code of the terminal device, which is signed with the provider's private key.

[0072] In some embodiments, process 400 further includes: the terminal device sending a device authorization request to the provider; and receiving a visual encoding including a checksum from the provider.

[0073] In some embodiments, process 400 further includes: presenting visual encoding in a display component of a terminal device to provide visual encoding to a server.

[0074] In some embodiments, the access authorization request is generated based on the access address of the terminal device.

[0075] In some embodiments, information relating to the provider of the terminal device includes a token signed with the provider's private key, and the private key is stored in the hardware of the terminal device.

[0076] In some embodiments, process 400 further includes: sending an update request for authorization information to the server; and receiving updated authorization information from the server.

[0077] In some embodiments, the terminal device includes an Internet of Things (IoT) device.

[0078] Example devices and equipment

[0079] Figure 5 shows a schematic structural block diagram of a device verification apparatus 500 for a server according to certain embodiments of the present disclosure. The apparatus 500 can be applied to server 201. The various modules / components in the apparatus 500 can be implemented by hardware, software, firmware, or any combination thereof.

[0080] As shown in Figure 5, the apparatus 500 includes an acquisition module 510 configured to acquire an access authorization request from a terminal device. The access authorization request is used to request access rights to a target service, and the access authorization request includes authorization information of the terminal device or information related to the provider of the terminal device. The target service is at least partially based on a target model. The apparatus 500 also includes a verification module 520 configured to verify the terminal device based on the access authorization request and the service information of the provider. The service information includes at least one of the following: the provider's registration information for the target service or the target service's authorization information for the provider. The apparatus 500 also includes a provision module 530 configured to provide the terminal device with authorization information for accessing the target service in response to the terminal device passing the verification.

[0081] In some embodiments, the authorization information of the terminal device includes a verification code of the terminal device, which is signed with the provider's private key, and the verification module 520 is further configured to determine whether the verification code is valid based on one or more stored valid verification codes; and in response to determining that the verification code is valid, to determine that the terminal device has passed the verification.

[0082] In some embodiments, the apparatus 500 further includes a first storage module configured to, before obtaining an access authorization request, obtain a visual code corresponding to the terminal device, the visual code including a check code; verify the check code using the provider's public key; and, in response to successful verification of the check code, store the check code as a valid check code.

[0083] In some embodiments, the authorization information of the terminal device includes the access address of the terminal device, and the verification module 520 is further configured to determine multiple access addresses registered by the provider for the target service based on the provider's registration information for the target service; and to determine that the terminal device passes verification in response to determining that the access address of the terminal device is one of the multiple access addresses.

[0084] In some embodiments, the apparatus 500 further includes a second storage module configured to obtain multiple access addresses from the provider before obtaining an access authorization request; and to store the multiple access addresses as part of the provider's registration information for the target service.

[0085] In some embodiments, the information associated with the provider of the terminal device includes a token signed with the provider's private key, and the verification module 520 is further configured to determine the provider's public key based on the provider's registration information for the target service; verify the signature of the token using the public key; and determine that the terminal device has passed verification in response to successful signature verification. In other embodiments, the authorization information includes an affirmative response to the access authorization request.

[0086] In some embodiments, the apparatus 500 further includes a first providing module configured to receive an update request for authorization information from a terminal device; in response to the update request, verify the validity of the authorization information; in response to the validity of the authorization information, generate updated authorization information; and provide the updated authorization information to the terminal device.

[0087] In some embodiments, the terminal device includes an Internet of Things (IoT) device.

[0088] Figure 6 shows a schematic structural block diagram of a device verification apparatus 600 for a terminal device according to certain embodiments of the present disclosure. The apparatus 600 can be applied to a terminal device 110. The various modules / components in the apparatus 600 can be implemented by hardware, software, firmware, or any combination thereof.

[0089] As shown in Figure 6, the apparatus 600 includes a generation module 610 configured to generate an access authorization request based on authorization information of a terminal device or information of the provider of the terminal device. The access authorization request is used to request access rights to a target service, which is at least partially based on a target model. The apparatus 600 also includes a providing module 620 configured to provide the access authorization request to the server of the target service. The apparatus 600 also includes an obtaining module 630 configured to obtain authorization information for accessing the target service from the server.

[0090] In some embodiments, the authorization information of the terminal device includes a verification code of the terminal device, which is signed with the provider's private key.

[0091] In some embodiments, the apparatus 600 further includes a first receiving module configured to send a device authorization request from the terminal device to the provider; and to receive a visual encoding including a checksum from the provider.

[0092] In some embodiments, the apparatus 600 further includes a first providing module configured to present visual encoding in a display component of a terminal device to provide visual encoding to a server.

[0093] In some embodiments, the access authorization request is generated based on the access address of the terminal device.

[0094] In some embodiments, information relating to the provider of the terminal device includes a token signed with the provider's private key, and the private key is stored in the hardware of the terminal device.

[0095] In some embodiments, the apparatus 600 further includes a second receiving module configured to send an update request for authorization information to a server and receive updated authorization information from the server.

[0096] In some embodiments, the terminal device includes an Internet of Things (IoT) device.

[0097] The units and / or modules included in devices 500 and 600 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units and / or modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units and / or modules in device 500 can be implemented at least partially by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0098] Figure 7 illustrates a block diagram of an electronic device 700 in which one or more embodiments of the present disclosure may be implemented. It should be understood that the electronic device 700 shown in Figure 7 is merely exemplary and should not constitute any limitation on the functionality and scope of the embodiments described herein.

[0099] As shown in Figure 7, the electronic device 700 is in the form of a general-purpose electronic device. Components of the electronic device 700 may include, but are not limited to, one or more processors or processing units 710, memory 720, storage devices 730, one or more communication units 740, one or more input devices 750, and one or more output devices 760. The processing unit 710 may be a physical or virtual processor and is capable of performing various processes according to programs stored in the memory 720. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of the electronic device 700.

[0100] Electronic device 700 typically includes multiple computer storage media. Such media can be any available media accessible to electronic device 700, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 720 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 730 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media capable of storing information and / or data and accessible within electronic device 700.

[0101] Electronic device 700 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 7, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. Memory 720 may include computer program product 725 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0102] The communication unit 740 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 700 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 700 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0103] Input device 750 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 760 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 700 can also communicate with one or more external devices (not shown) via communication unit 740 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 700, or with any device that enables electronic device 700 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0104] According to an exemplary implementation of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to an exemplary implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0105] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0106] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0107] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0109] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A device verification method, comprising: Obtain an access authorization request from a terminal device, the access authorization request being used to request access permissions for a target service, and the access authorization request including authorization information of the terminal device or information related to the provider of the terminal device, the target service being at least partially based on a target model; Based on the access authorization request and the service information of the provider, the terminal device is verified, wherein the service information includes at least one of the following: the provider's registration information for the target service or the target service's authorization information for the provider; as well as In response to the terminal device passing the authentication, authorization information for accessing the target service is provided to the terminal device.

2. The method according to claim 1, wherein the authorization information of the terminal device includes a verification code of the terminal device, the verification code being signed with the provider's private key, and verifying the terminal device includes: Based on one or more stored valid check codes, determine whether the check code is valid; as well as In response to determining that the verification code is valid, the terminal device is determined to have passed the verification.

3. The method according to claim 2, further comprising: Before obtaining the access authorization request, a visual code corresponding to the terminal device is obtained, the visual code including the check code; The verification code is verified using the provider's public key; as well as In response to successful verification of the verification code, the verification code is stored as a valid verification code.

4. The method according to claim 1, wherein the authorization information of the terminal device includes the access address of the terminal device, and verifying the terminal device includes: Based on the provider's registration information for the target service, determine multiple access addresses registered by the provider for the target service; as well as In response to determining that the access address of the terminal device is one of the plurality of access addresses, the terminal device is determined to have passed authentication.

5. The method according to claim 4, further comprising: Before obtaining the access authorization request, obtain the plurality of access addresses from the provider; as well as The multiple access addresses are stored as part of the provider's registration information for the target service.

6. The method of claim 1, wherein the information related to the provider of the terminal device includes a token signed with the provider's private key, and verifying the terminal device includes: Based on the provider's registration information for the target service, the provider's public key is determined; The signature of the token is verified using the public key; In response to successful verification of the signature, it is determined that the terminal device has passed verification, and The authorization information includes an affirmative response to the access authorization request.

7. The method according to claim 1, further comprising: Receive an update request for the authorization information from the terminal device; In response to the update request, verify the validity of the authorization information; In response to the validity of the authorization information, updated authorization information is generated; as well as The updated authorization information is provided to the terminal device.

8. The method according to claim 1, wherein the terminal device includes an Internet of Things (IoT) device.

9. A device verification method, comprising: Based on the authorization information of the terminal device or the information of the provider of the terminal device, an access authorization request is generated. The access authorization request is used to request access permissions for a target service, which is at least partially based on the target model. The access authorization request is provided to the server of the target service; as well as Obtain authorization information for accessing the target service from the server.

10. The method according to claim 9, wherein the authorization information of the terminal device includes a verification code of the terminal device, the verification code being signed with the private key of the provider.

11. The method of claim 10, further comprising: The terminal device sends a device authorization request to the provider; as well as Receive a visual encoding including the checksum from the provider.

12. The method according to claim 9, further comprising: The visualization encoding is presented in the display component of the terminal device to provide the visualization encoding to the server.

13. The method of claim 9, wherein the access authorization request is generated based on the access address of the terminal device.

14. The method of claim 9, wherein the information relating to the provider of the terminal device includes a token signed with the provider's private key, and the private key is stored in the hardware of the terminal device.

15. The method of claim 9, further comprising: Send an update request for the authorization information to the server; as well as Receive the updated authorization information from the server.

16. The method of claim 9, wherein the terminal device includes an Internet of Things (IoT) device.

17. An apparatus for device verification, comprising: The acquisition module is configured to acquire an access authorization request from a terminal device, the access authorization request being used to request access permissions for a target service, and the access authorization request including authorization information of the terminal device or information related to the provider of the terminal device, the target service being at least partially based on a target model; The verification module is configured to verify the terminal device based on the access authorization request and the service information of the provider, wherein the service information includes at least one of the following: the provider's registration information for the target service or the target service's authorization information for the provider; as well as A module is configured to provide authorization information to the terminal device for accessing the target service in response to the terminal device passing authentication.

18. An apparatus for device authentication, the apparatus being applied to a client and comprising: The generation module is configured to generate an access authorization request based on the authorization information of the terminal device or the information of the provider of the terminal device. The access authorization request is used to request access permissions for a target service, which is at least partially based on the target model. A module is configured to provide the access authorization request to the server of the target service; as well as An obtaining module, configured to obtain, from the server, authorization information for accessing the target service.

19. An electronic device, comprising: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions when executed by the at least one processing unit cause the electronic device to perform a method according to any of claims 1-8 or claims 9-16.

20. A computer-readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement a method according to any of claims 1-8 or claims 9-16.

Images