Method and device for logout equipment

Abstract

Provided are a device logout method and apparatus, the method comprising: a first device sending first information to a service device (S320), the first information being used for requesting the service device to logout a client corresponding to a second device (S330). According to the method in the embodiment of the invention, the convenience of equipment logout can be improved.

Description

Method and apparatus for deregistering a device Technical Field

[0001] The present application relates to the field of communication technology, and more specifically, to a method and apparatus for deregistering a device. Background Art

[0002] With the continuous development of technology, users can configure devices to access service devices (such as the cloud) and access or control the devices through the service devices. However, if you want to deregister the device from the service device, the current method is not convenient or flexible enough.

[0003] Summary of the Invention

[0004] The present application provides a method and apparatus for deregistering a device. The following describes various aspects of the embodiments of the present application.

[0005] In a first aspect, a method for deregistering a device is provided, comprising: a first device sending first information to a service device, wherein the first information is used to request the service device to deregister a client corresponding to the second device.

[0006] In a second aspect, a method for deregistering a device is provided, including: a service device receiving first information sent by a first device, wherein the first information is used to request the service device to deregister a client corresponding to a second device; and the service device performs a deregistration operation according to the first information.

[0007] In a third aspect, a method for deregistering a device is provided, including: a second device receiving third information sent by a service device, the third information being used to indicate that a client corresponding to the second device has been deregistered on the service device; and the second device deleting configuration information of the second device.

[0008] In a fourth aspect, an apparatus for deregistering a device is provided, comprising: a sending unit, configured to send first information to a service device, wherein the first information is used to request the service device to deregister a client corresponding to the second device.

[0009] In the fifth aspect, a device for deregistering a device is provided, comprising: a receiving unit for receiving first information sent by a first device, wherein the first information is used to request the device to deregister a client corresponding to a second device; and an execution unit for performing a deregistration operation according to the first information.

[0010] In the sixth aspect, a device for deregistering a device is provided, comprising: a receiving unit for receiving third information sent by a service device, wherein the third information is used to indicate that a client corresponding to the device has been deregistered from the service device; and an execution unit for deleting configuration information of the device.

[0011] In a seventh aspect, an apparatus for deregistering a device is provided, comprising a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory to execute the method described in the first aspect or the third aspect.

[0012] In an eighth aspect, an apparatus for deregistering a device is provided, comprising a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory to execute the method described in the second aspect.

[0013] In a ninth aspect, an apparatus for deregistering a device is provided, comprising a processor for calling a program from a memory to execute the method described in the first aspect or the third aspect.

[0014] In a tenth aspect, an apparatus for deregistering a device is provided, comprising a processor for calling a program from a memory to execute the method described in the second aspect.

[0015] In an eleventh aspect, a chip is provided, comprising a processor for calling a program from a memory so that a device equipped with the chip executes the method described in the first aspect or the third aspect.

[0016] In a twelfth aspect, a chip is provided, comprising a processor for calling a program from a memory so that a device equipped with the chip executes the method described in the second aspect.

[0017] In a thirteenth aspect, a computer-readable storage medium is provided, on which a program is stored, wherein the program enables a computer to execute the method described in the first aspect or the third aspect.

[0018] In a fourteenth aspect, a computer-readable storage medium is provided, on which a program is stored, wherein the program enables a computer to execute the method described in the second aspect.

[0019] In a fifteenth aspect, a computer program product is provided, comprising a program, wherein the program enables a computer to execute the method described in the first aspect or the third aspect.

[0020] In a sixteenth aspect, a computer program product is provided, comprising a program, wherein the program enables a computer to execute the method described in the second aspect.

[0021] In the seventeenth aspect, a computer program is provided, which enables a computer to execute the method described in the first aspect or the third aspect.

[0022] In an eighteenth aspect, a computer program is provided, which enables a computer to execute the method described in the second aspect.

[0023] In an embodiment of the present application, the first device may directly request the service device to deregister the second device, thereby improving the convenience of device deregistration. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG1 is an example diagram of a system used in an embodiment of the present application.

[0025] FIG2 is a schematic flowchart of a method for deregistering a device in an embodiment of the present application.

[0026] FIG3 is a schematic flowchart of a method for deregistering a device according to an embodiment of the present application.

[0027] FIG4 is a schematic flowchart of a method for deregistering a device according to an embodiment of the present application.

[0028] FIG5 is a schematic flowchart of a method for deregistering a device provided in another embodiment of the present application.

[0029] FIG6 is a schematic flowchart of a method for deregistering a device provided in yet another embodiment of the present application.

[0030] FIG7 is a schematic flowchart of a method for deregistering a device provided in yet another embodiment of the present application.

[0031] FIG8 is a schematic structural diagram of an apparatus for deregistering a device according to an embodiment of the present application.

[0032] FIG9 is a schematic structural diagram of an apparatus for canceling a device provided in another embodiment of the present application.

[0033] FIG10 is a schematic structural diagram of an apparatus for canceling a device provided in another embodiment of the present application.

[0034] FIG11 is a schematic structural diagram of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The technical solution in this application will be described below with reference to the accompanying drawings.

[0036] FIG1 is a system 100 used in an embodiment of the present application. The system 100 may include an Internet of Things (IoT) cloud platform 110 , a configuration management device 120 , and a device 130 .

[0037] The cloud platform 110 can be referred to as a cloud or server, etc. The cloud platform 110 allows IoT devices to access, can store relevant data of IoT devices, and can also implement management, access, and control of IoT devices. For example, the cloud platform 110 can be the OCF cloud in the Open Connectivity Foundation (OCF) platform. In this case, the cloud platform 110 can include a resource directory, a cloud access interface, and an authorization server. The resource directory can include an index of server resources, and the client can obtain the resources of the target device (such as the server) by searching the resource index; the cloud access interface can serve as an anchor point on the cloud, responsible for access management of the server, and providing message routing for remote communication between the client and the server. The cloud access interface can provide a unified address and port number to the outside world, for example, address: coaps+tcp: / / example.com, port number: 443; the authorization server can be responsible for server registration and authentication of the client and the server.

[0038] Configuration management device 120 can create a platform account (or cloud platform account) in cloud platform 110. Configuration management device 120 can also use this platform account to configure IoT devices (such as device 130) to access cloud platform 110, thereby enabling access to or control of IoT devices through cloud platform 110. Configuration management device 120 can be a device with administrator privileges under this platform account.

[0039] Device 130 may be an IoT device. Device 130 may include an IoT client or an IoT server. For example, the IoT client or IoT server may refer to an application (APP) in device 130. A device including an IoT client (hereinafter referred to as a client) may be understood as a control device. The client may control other devices in the same platform account. For example, the client may be a mobile phone (or an APP in a mobile phone), a car (or an APP in a car), a tablet (Pad), a laptop, a PDA, or a wearable device. A device including an IoT server (hereinafter referred to as a server) may be understood as a control device. Configuration management devices and clients in the same platform account may be controlled by the server. For example, the server may be a car (or an APP in a car), lighting, door locks, blinds, televisions, HVAC systems, security sensors and controllers, gateways, and other devices.

[0040] In the scenario shown in FIG1 , configuration management device 120 can configure device 130 to access cloud platform 110. Alternatively, configuration management device 120 can act as a proxy device, with device 130 connecting to cloud platform 110 via configuration management device 120. For example, assuming that an app on a mobile phone can implement the functions of configuration management device 120 and a car is device 130, if the app on the car can connect to the internet, the app on the mobile phone can configure the app in the car to directly connect to the cloud platform. If the app in the car cannot connect to the internet, the app in the car can connect to the cloud platform via the mobile phone.

[0041] The following uses the OCF platform as an example to describe the process of creating a cloud business. The details are as follows:

[0042] 1. The user creates a cloud platform account. The app on the user's phone can provide a configurator (mediator) function (such as the configuration management device 120 in Figure 1), which can request an access token (AccessToken) from the cloud for the configured device (such as the device 130 in Figure 1). The configurator can use the AccessToken authorized from the cloud, the cloud access uniform resource identifier (URI), and the cloud universally unique identifier (UUID) to update the "oic.r.coapcloudconf" resource on the device.

[0043] Second, the device establishes a secure transport layer security (TLS) connection with the cloud using a pre-configured digital certificate. To register with the cloud, the device can send an UPDATE request to the account resource " / oic / sec / account" on the cloud.

[0044] 3. The device needs to log in to the cloud to transfer data between the device and the cloud. The device can send an UPDATE operation request to the session resource " / oic / sec / session" in the cloud.

[0045] Fourth, the device exposes its hosted resources in the cloud's resource directory to facilitate remote access to these resources. When a client (or configurator) requests a create, update, retrieve, delete, notify, or CURDN operation on a resource referenced by a cloud-hosted resource link, the cloud forwards the CURDN request to the device that actually hosts the resource (e.g., the server). The device responds to the cloud's request, and the cloud forwards the response to the client. The communication path between the client and device is: client -> cloud -> device -> cloud -> client.

[0046] The following describes the process of deregistering a device from the cloud (e.g., OCF cloud). FIG2 is a schematic flow chart of a method 200 for deregistering a device in the prior art. The method 200 includes steps S201 to S210, which are as follows:

[0047] S201, when a user wants to deregister a device from the cloud (e.g., disconnect the device from the cloud and cancel its registration), an update operation with an empty “cis” attribute may be sent to the device’s “oic.r.coapcloudconf” resource via the configurator.

[0048] As can be seen in Figure 2, a session has been established between the device and the cloud, and the TLS connection has been authorized.

[0049] S202: The device may return a success response to the configurator.

[0050] S203, the device may send a delete operation to the “ / oic / sec / account” resource in the cloud.

[0051] If a session has not yet been established between the device and the cloud and the TLS connection is unauthorized, the device can send a delete operation to the cloud and log out with the cloud along with the "AccessToken" and "uid" or "di" attributes as query parameters. If the "di" attribute is omitted from the delete operation, the cloud will log out the device using the matching "AccessToken" attribute value.

[0052] If a session has been established between the device and the cloud and the TLS connection has been authorized, query parameters ("accesstoken", "uid", or "di") are not required in the delete request.

[0053] S204: The cloud performs the deletion operation and returns a successful logout response to the device.

[0054] As can be seen from Figure 2, after the cloud performs the deletion operation, the TLS connection between the device and the cloud is disconnected.

[0055] S205: The device clears related resources.

[0056] The device can clear the oic.r.coapcloudconf resource and delete related data stored internally.

[0057] S206: The configurator requests the device to delete the related entity.

[0058] For example, the configurator can request the device to delete an access control entry (ACE) entity. An access control list (ACL) ( / oic / sec / acl2) can contain multiple ACE2 entities, and the configurator can request the device to delete some or all ACE2 entities in the ACL.

[0059] S207: The device executes the deletion operation and returns a deletion success response to the configurator.

[0060] S208: The configurator requests the device to delete the relevant certificate.

[0061] S209: The device executes the deletion operation and returns a deletion success response to the configurator.

[0062] At this point, the device is deregistered from the cloud. After deregistering from the cloud, the device can connect to any other cloud.

[0063] As shown in Figure 2, existing device deregistration solutions require the configurator to initiate a deregistration request (when the configurator and device are connected and can exchange data). This approach is inconvenient and inflexible. For example, in a connected car scenario, users cannot deregister directly from the car (client), nor can they deregister from their phone after leaving the car and disconnecting their phone (configurator). The user must first initiate a deregistration request from the phone to the car while the phone is connected and can exchange data. After the car returns a successful response, the car then sends the deregistration request to the cloud.

[0064] In order to solve one or more of the above technical problems, the present application proposes a method and apparatus for deregistering a device.

[0065] The embodiments of the present application are described in detail below with reference to FIG3 to FIG7 .

[0066] FIG3 is a schematic flow chart of a method for deregistering a device according to an embodiment of the present application. The method 300 shown in FIG3 may include the following steps:

[0067] S320: The first device sends first information to the service device.

[0068] The first device may be the second device. The second device may be the device 130 in FIG1 , for example, the second device may be a car, lighting, door locks, blinds, a television, a heating and air conditioning system, a security sensor and controller, a gateway, etc.

[0069] The first device may also be a configuration management device for the second device. The configuration management device for the second device may have the configurator capabilities of a service device and may be able to configure the second device to access the service device. For example, the first device may be a mobile phone, tablet computer, laptop computer, PDA, or wearable device. It should be noted that for ease of description, the following embodiments are described using the second device as a client. The methods of this application are also applicable to scenarios where the second device is a server.

[0070] The service device may be a cloud or a server. For example, the service device may be the cloud platform 110 in FIG1 .

[0071] The first information may be used to request the service device to deregister the client corresponding to the second device. Optionally, the client here may refer to a client or service included in the second device (e.g., an APP in the second device). Optionally, the first information may include an access token of the second device.

[0072] The first information may include a service identifier of the second device, and the service identifier may be a client identifier (ClientID) or a server identifier (ServerID) corresponding to the second device.

[0073] Optionally, the first information may include a first field, and the first field may indicate a service identifier of the second device. For example, the first information may be a deregistration request, and the first field may be a service identifier field.

[0074] Alternatively, the first information may include a first query parameter, which may be a service identifier of the second device. For example, the first information may be a deregistration request, and the service identifier of the second device may be carried in the deregistration request as a query parameter.

[0075] The service device may store (or maintain) one or more of the following correspondences: an access token and the service identifier of the device corresponding to the access token, an access token and the account identifier of the platform account containing the device corresponding to the access token, and a service identifier of the device corresponding to the access token and the account identifier of the platform account containing the device corresponding to the access token. For example, the service device may maintain a binding relationship between a device identifier (ClientID or ServerID), an access token (AccessToken), and an account identifier (UserID). The account identifier here may refer to the account identifier of the service device platform account generated after the user creates a platform account through the configurator.

[0076] In some embodiments, the first device can be used to obtain a user operation. The user operation can be used to trigger the first device to request the service device to deregister the client corresponding to the second device. In this way, when triggered by the user operation, the first device directly requests the service device to deregister the second device, which can improve the flexibility of device deregistration.

[0077] For example, before step S320, the method 300 may further include step S310, which is as follows:

[0078] S310: The first device obtains a user operation.

[0079] A user operation may refer to an operation instruction input by a user through the interactive interface of a first device. For example, the first device may be a car (or a mobile phone, etc.). The user may input an operation instruction to an app in the car through the car's central control screen. The operation instruction may be used to request the service device to deregister the client corresponding to the car. Accordingly, after receiving (or obtaining) the user operation, the car may request the service device to deregister its (i.e., the car's) client.

[0080] Alternatively, a user operation may also refer to an action that satisfies a preset condition. For example, after the user leaves the car or the user's mobile phone (configurator) is disconnected from the car for 10 minutes, the car may request the service device to deregister its (i.e., the car's) corresponding client.

[0081] S330: The service device performs a logout operation according to the first information.

[0082] The deregistration operation may refer to the service device deleting relevant information of the second device.

[0083] In some embodiments, the service device may determine, based on the first information and the corresponding relationship, whether the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information. Further, if the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information, the service device may delete the relevant information of the second device.

[0084] In some embodiments, the service device may determine, based on the first information and the corresponding relationship maintained by the service device, whether the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token in the first information. Furthermore, if the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token, the service device may delete the relevant information of the second device.

[0085] The relevant information of the second device here may include: a service identifier (ClientID or ServerID) of a client corresponding to the second device, an access token, a certificate, and other data related to the second device.

[0086] S340: The service device sends notification information to the second device.

[0087] In some embodiments, when the first device is the second device, the service device may send a deregistration response to the second device, informing the second device that its corresponding client has been deregistered from the service device.

[0088] In some embodiments, when the first device is a configuration management device of the second device, the service device may send third information to the second device.

[0089] The third information may be used to indicate that the client corresponding to the second device has been deregistered from the serving device. Optionally, the third information may be a deregistration event notification. The third information may include an identifier and / or type of the deregistration event.

[0090] The identifier of the client deregistration event can refer to the identifier (ID) of the event subscription, for example, "subscriptionId":"9cfbeb8e-5a1e-4d1c-9d01-00c04fd430c8". This identifier can be different for different devices, for example, the deregistration event ID for device A is 111, and the deregistration event ID for device B is 222. The type of the client deregistration event can be determined by the "eventTypes" field in the service device deregistration interface. This field can indicate "client_registered", indicating that the device (or IoT client) has been deregistered. This field can be the same for all devices.

[0091] S350: The second device deletes the configuration information of the second device.

[0092] For example, the second device may clear the certificate chain, cloud address, access token, and user password of the second device.

[0093] In an embodiment of the present application, the first device may directly request the service device to deregister the second device, thereby improving the convenience of device deregistration.

[0094] As mentioned above, the first information may include the service identifier of the second device. In some embodiments, a new field (such as a client identification field or a server identification field) may be defined in the existing logout interface parameters (for example, the cloud logout interface parameters of the OCF platform) to indicate the service identifier of the second device. The following takes the cloud logout interface parameters of the OCF platform as an example, and describes it in detail in conjunction with Figures 4 and 5. It should be noted that the embodiments of the present application are not limited to the OCF platform, but can also be applied to various other platforms.

[0095] First, let's introduce the cloud-based logout interface. The definition of the cloud-based logout interface is as follows:

[0096] Table 1 Cloud logout interface parameters

[0097] HTTP Method interface access address DELETE / account /

[0098] The Hypertext Transfer Protocol (HTTP) method "DELETE" indicates a delete operation (or logout operation), and the interface access address " / account / " represents the cloud access address (HTTP address). It should be noted that the interface access address " / account / " in Table 1 is a relative address. Its corresponding absolute address must be combined with the cloud's unified access address, such as "https: / / example.com." The resulting cloud logout interface address is "https: / / example.com / account / ."

[0099] Table 2 Logout request interface parameters

[0100]

[0101] The header portion of Table 2 includes the parameters Accept, Content-Type, and AccessToken, and the Body portion includes the Client ID. The value types of the Content-Type, Access-Token, and Client ID are string types. The Client ID field in Table 2 may be a newly defined field in this application, used to directly indicate to the cloud the device that wishes to be deregistered. The Client ID field may also represent a server ID, which is not limited in this application.

[0102] Table 3 Logout response interface parameters

[0103]

[0104] In some embodiments, a deregistration request may be initiated by the client based on the cloud deregistration interface shown in Tables 1 to 3. The method for deregistering a device may be shown as method 400 in FIG4 .

[0105] S410: The IoT client sends a logout request to the IoT cloud.

[0106] For example, a user can enter an operation instruction to the IoT client, and in response, the IoT client can send a logout request to the IoT cloud:

[0107] DELETE <cloudurl> / account{ClientID=1234567890}

[0108] Among them, "DELETE" means the deletion operation (or logout operation), <cloudurl>" represents the uniform resource locator (URL) of the IoT cloud, and "{ClientID=1234567890}" indicates that the client ID requesting deregistration is "1234567890".

[0109] In some embodiments, the ClientID carried in the deregistration request needs to be consistent with the ClientID of the IoT client that initiates the request, that is, the deregistration request can only be used to deregister itself (ie, the IoT client).

[0110] S420, the IoT cloud performs corresponding operations according to the deregistration request.

[0111] The IoT Cloud can determine whether the AccessToken carried in the deregistration request is valid. For example, the IoT Cloud can determine whether the AccessToken carried in the deregistration request was assigned by the IoT Cloud. If so, the AccessToken can be considered valid. Otherwise, the AccessToken can be considered invalid.

[0112] The IoT cloud can compare the ClientID in the logout request with the ClientID corresponding to the AccessToken carried in the logout request. If they match, the IoT cloud can execute the logout operation (e.g., executing S450) and return a successful logout response to the IoT client. Otherwise, the IoT cloud may not execute the logout operation and return a 406 "Not Acceptable" error code to the IoT client.

[0113] S430, the IoT cloud sends a logout notification to the configurator.

[0114] The configurator is a configuration management device for the IoT client, capable of configuring the IoT client to access the IoT cloud. The deregistration notification may include the IoT client's ClientID to inform the configurator that the IoT client has been deregistered. It should be noted that step S430 is optional and may or may not be performed.

[0115] S440, the IoT cloud sends a logout response to the IoT client.

[0116] S450: The IoT cloud deletes the relevant information of the IoT client.

[0117] For example, the IoT cloud may clear the Client ID, access token, certificate, and other data related to the IoT client.

[0118] S460: The IoT client deletes the configuration information of the IoT client.

[0119] For example, the IoT client can clear the IoT client's certificate chain, cloud address, access token, and user password.

[0120] In some embodiments, a configuration management device (such as a configurator) may initiate a deregistration request based on the cloud deregistration interface described in Tables 1 to 3. The method for deregistering a device may be as shown in method 500 in FIG5 .

[0121] S510: The configurator sends a logout request to the IoT cloud.

[0122] For example, a user can enter an operation instruction to the configurator, and in response, the configurator can send a logout request to the IoT cloud:

[0123] DELETE <cloudurl> / account{ClientID=1234567890}

[0124] Among them, "DELETE" means the deletion operation (or logout operation), <cloudurl>" represents the uniform resource locator (URL) of the IoT cloud, and "{ClientID=1234567890}" indicates that the client ID requesting deregistration is "1234567890".

[0125] S520: The IoT cloud performs corresponding operations according to the deregistration request.

[0126] The IoT Cloud can determine whether the AccessToken carried in the deregistration request is valid. For example, the IoT Cloud can determine whether the AccessToken carried in the deregistration request was assigned by the IoT Cloud. If so, the AccessToken can be considered valid. Otherwise, the AccessToken can be considered invalid.

[0127] The IoT cloud can compare the UserID corresponding to the ClientID in the logout request with the UserID corresponding to the AccessToken included in the logout request. If they match, the IoT cloud can execute the logout operation (e.g., executing S550) and return a successful logout response to the IoT client. Otherwise, the IoT cloud may not execute the logout operation and return a 406 "Not Acceptable" error code to the IoT client.

[0128] S530: The IoT cloud sends an event notification to the IoT client.

[0129] The event notification may carry the identifier or type of the client deregistration event to inform the IoT client that it has been deregistered.

[0130] S540, the IoT cloud sends a logout response to the configurator.

[0131] S550: The IoT cloud deletes the relevant information of the IoT client.

[0132] For example, the IoT cloud may clear the Client ID, access token, certificate, and other data related to the IoT client.

[0133] S560: The IoT client deletes the configuration information of the IoT client.

[0134] For example, the IoT client can clear the IoT client's certificate chain, cloud address, access token, and user password.

[0135] As mentioned above, a new field can be defined in the deregistration request interface parameters to indicate the service identifier of the second device. In some embodiments, the deregistration request interface parameters may not be modified. This is described in detail below with reference to Figures 6 and 7.

[0136] The logout request interface parameters used in Figures 6 and 7 are defined as follows:

[0137] Table 4 Logout request interface parameters

[0138]

[0139] It can be seen that Table 4 differs from Table 2 in that it does not include the Client ID field. The cloud logout interface used in Figures 6 and 7 is the same as that in Figures 4 and 5, i.e., the interface parameters corresponding to Tables 1 and 3.

[0140] In some embodiments, a deregistration request may be initiated by the client based on the cloud deregistration interface shown in Table 1, Table 3, and Table 4. The method for deregistering a device may be shown as method 600 in FIG6 .

[0141] S610: The IoT client sends a logout request to the IoT cloud.

[0142] For example, a user can enter an operation instruction to the IoT client, and in response, the IoT client can send a logout request to the IoT cloud:

[0143] DELETE <cloudurl> / account

[0144] Among them, "DELETE" means the deletion operation (or logout operation), <cloudurl>" represents the uniform resource locator (URL) of the IoT cloud. It can be seen that, unlike S410 in method 400, the deregistration request does not include the client identifier (ClientID).

[0145] S620: The IoT cloud performs corresponding operations according to the deregistration request.

[0146] The IoT Cloud can determine whether the AccessToken carried in the deregistration request is valid. For example, the IoT Cloud can determine whether the AccessToken carried in the deregistration request was assigned by the IoT Cloud. If so, the AccessToken can be considered valid. Otherwise, the AccessToken can be considered invalid.

[0147] If the AccessToken is valid, the IoT cloud may perform the logout operation (such as executing S650) and return a logout success message to the IoT client; otherwise, the IoT cloud may not perform the logout operation and return a 406 "Not Acceptable" error code to the IoT client.

[0148] S630: The IoT cloud sends a logout notification to the configurator.

[0149] The configurator is a configuration management device for the IoT client, capable of configuring the IoT client to access the IoT cloud. The deregistration notification may include the IoT client's ClientID to inform the configurator that the IoT client has been deregistered. It should be noted that step S630 is optional and may or may not be performed.

[0150] S640: The IoT cloud sends a logout response to the IoT client.

[0151] S650: The IoT cloud deletes the relevant information of the IoT client.

[0152] For example, the IoT cloud may clear the Client ID, access token, certificate, and other data related to the IoT client.

[0153] S660: The IoT client deletes the configuration information of the IoT client.

[0154] For example, the IoT client can clear the IoT client's certificate chain, cloud address, access token, and user password.

[0155] In some embodiments, a configuration management device (such as a configurator) may initiate a deregistration request based on the cloud deregistration interfaces shown in Tables 1, 3, and 4. A method for deregistering a device may be shown as method 700 in FIG.

[0156] S710: The configurator sends a logout request to the IoT cloud.

[0157] For example, a user can enter an operation instruction to the configurator, and in response, the configurator can send a logout request to the IoT cloud:

[0158] DELETE <cloudurl> / account? ClientID=1234567890

[0159] Here, "ClientID=1234567890" indicates that the client ID requesting deregistration is "1234567890." Unlike the previous embodiment, here, ClientID is a query parameter in the deregistration request, rather than being carried in the deregistration request interface (by adding a ClientID field). This eliminates the need to change existing interface parameters, making implementation more convenient.

[0160] S720: The IoT cloud performs corresponding operations according to the deregistration request.

[0161] The IoT Cloud can determine whether the AccessToken carried in the deregistration request is valid. For example, the IoT Cloud can determine whether the AccessToken carried in the deregistration request was assigned by the IoT Cloud. If so, the AccessToken can be considered valid. Otherwise, the AccessToken can be considered invalid.

[0162] The IoT cloud can compare the UserID corresponding to the ClientID in the logout request with the UserID corresponding to the AccessToken included in the logout request. If they match, the IoT cloud can execute the logout operation (e.g., executing S750) and return a logout success message to the IoT client. Otherwise, the IoT cloud may not execute the logout operation and return a 406 "Not Acceptable" error code to the IoT client.

[0163] S730: The IoT cloud sends an event notification to the IoT client.

[0164] The event notification may carry the identifier or type of the client deregistration event to inform the IoT client that it has been deregistered.

[0165] S740: The IoT cloud sends a logout response to the configurator.

[0166] S750: The IoT cloud deletes the relevant information of the IoT client.

[0167] For example, the IoT cloud may clear the Client ID, access token, certificate, and other data related to the IoT client.

[0168] S760: The IoT client deletes the configuration information of the IoT client.

[0169] For example, the IoT client can clear the IoT client's certificate chain, cloud address, access token, and user password.

[0170] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 7 . The device embodiment of the present application is described in detail below in conjunction with Figures 8 to 11 . It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for portions not described in detail, reference can be made to the above method embodiment.

[0171] FIG8 is a schematic structural diagram of an apparatus for deregistering a device according to an embodiment of the present application. As shown in FIG8 , the apparatus 800 includes a sending unit 810, which is specifically as follows:

[0172] The sending unit 810 is configured to send first information to a service device, where the first information is used to request the service device to deregister a client corresponding to the second device.

[0173] Optionally, the service device stores one or more of the following correspondences: the access token and the service identifier of the device corresponding to the access token, the access token and the account identifier of the platform account where the corresponding device is located, and the service identifier and the account identifier.

[0174] Optionally, the apparatus is used to obtain a user operation, and the user operation is used to trigger the apparatus to request the service device to deregister a client corresponding to the second device.

[0175] Optionally, the apparatus is the second device.

[0176] Optionally, the first information includes a service identifier of the second device.

[0177] Optionally, the apparatus is a configuration management device of the second device, and the first information includes a service identifier of the second device.

[0178] Optionally, the first information includes a first field, and the first field indicates a service identifier of the second device.

[0179] Optionally, the first information is a deregistration request, and the first field is a service identification field.

[0180] Optionally, the first information includes a first query parameter, and the first query parameter is a service identifier of the second device.

[0181] Optionally, the first information is a logout request.

[0182] Optionally, the apparatus 800 further includes a receiving unit 820, configured to receive second information sent by the service device, where the second information is used to indicate whether the service device successfully deregisters the client corresponding to the second device.

[0183] Optionally, the second information is a logout response.

[0184] FIG9 is a schematic structural diagram of an apparatus for deregistering a device according to an embodiment of the present application. The apparatus 900 of the deregistering device in FIG9 includes a receiving unit 910 and an executing unit 920, which are specifically as follows:

[0185] A receiving unit 910 is configured to receive first information sent by a first device, where the first information is used to request the apparatus to deregister a client corresponding to a second device;

[0186] The execution unit 920 is configured to execute a logout operation according to the first information.

[0187] Optionally, the device stores one or more of the following correspondences: the service identifier of the access token and the device corresponding to the access token, the account identifier of the platform account where the access token and the corresponding device are located, and the service identifier and the account identifier.

[0188] Optionally, the first device is the second device, and the execution unit 920 is specifically configured to delete relevant information of the second device.

[0189] Optionally, the first information includes the service identifier of the second device, and the execution unit 920 is specifically used to: determine whether the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information based on the first information and the corresponding relationship; if the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information, delete the relevant information of the second device.

[0190] Optionally, the first device is a configuration management device of the second device, the first information includes a service identifier of the second device, and the execution unit 920 is specifically configured to delete relevant information of the second device.

[0191] Optionally, the execution unit 920 is specifically used to: determine whether the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token in the first information based on the first information and the corresponding relationship; if the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token, delete the relevant information of the second device.

[0192] Optionally, the apparatus 900 further includes a sending unit 930, configured to send third information to the second device, where the third information is used to indicate that the client corresponding to the second device has been deregistered from the apparatus.

[0193] Optionally, the third information is a deregistration event notification, and the third information includes an identifier and / or type of the deregistration event.

[0194] Optionally, the first information includes a first field, and the first field indicates a service identifier of the second device.

[0195] Optionally, the first information is a deregistration request, and the first field is a service identification field.

[0196] Optionally, the first information includes a first query parameter, and the first query parameter is a service identifier of the second device.

[0197] Optionally, the first information is a logout request.

[0198] Optionally, the apparatus 900 further includes a sending unit 930, configured to send second information to the first device, where the second information is used to indicate whether the apparatus successfully deregisters the client corresponding to the second device.

[0199] Optionally, the second information is a logout response.

[0200] FIG10 is a schematic structural diagram of an apparatus for deregistering a device according to an embodiment of the present application. The apparatus 1000 of the deregistering device in FIG10 includes a receiving unit 1010 and an executing unit 1020, as follows:

[0201] The receiving unit 1010 is configured to receive third information sent by a service device, where the third information is used to indicate that the client corresponding to the apparatus has been deregistered from the service device;

[0202] The execution unit 1020 is configured to delete the configuration information of the device.

[0203] Optionally, the third information is a deregistration event notification, and the third information includes an identifier or type of the deregistration event.

[0204] Figure 11 is a schematic diagram of the structure of an apparatus provided in one embodiment of the present application. The dashed lines in Figure 11 indicate that the unit or module is optional. Apparatus 1100 may be used to implement the method described in the above method embodiment. Apparatus 1100 may be a chip or a deregistration device.

[0205] The device 1100 may include one or more processors 1110. The processor 1110 may support the device 1100 to implement the method described in the method embodiment above. The processor 1110 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0206] The apparatus 1100 may further include one or more memories 1120. The memories 1120 store programs that can be executed by the processor 1110, causing the processor 1110 to perform the methods described in the above method embodiments. The memories 1120 may be independent of the processor 1110 or integrated into the processor 1110.

[0207] The apparatus 1100 may further include a transceiver 1130. The processor 1110 may communicate with other devices or chips via the transceiver 1130. For example, the processor 1110 may transmit and receive data with other devices or chips via the transceiver 1130.

[0208] The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to the apparatus of the deregistration device provided in the present application, and the program causes a computer to execute the method performed by the apparatus of the deregistration device in various embodiments of the present application.

[0209] The present application also provides a computer program product. This computer program product includes a program. This computer program product can be applied to the apparatus of the deregistration device provided in the present application, and the program causes a computer to execute the method performed by the apparatus of the deregistration device in each embodiment of the present application.

[0210] The present application also provides a computer program that can be applied to the deregistration device provided in the present application and enables a computer to execute the method performed by the deregistration device in each embodiment of the present application.

[0211] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B based solely on A; B can also be determined based on A and / or other information.

[0212] It should be understood that the term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0213] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0214] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0215] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0216] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0217] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0218] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.< / cloudurl> < / cloudurl> < / cloudurl> < / cloudurl> < / cloudurl> < / cloudurl> < / cloudurl>

Claims

1. A method for deregistering a device, characterized in that: include: The first device sends first information to the service device, where the first information is used to request the service device to deregister a client corresponding to the second device.

2. The method according to claim 1, characterized in that The service device stores one or more of the following correspondences: the access token and the service identifier of the device corresponding to the access token, the access token and the account identifier of the platform account where the corresponding device is located, and the service identifier and the account identifier.

3. The method according to claim 1 or 2, characterized in that The first device is used to obtain a user operation, where the user operation is used to trigger the first device to request the service device to deregister a client corresponding to the second device.

4. The method according to any one of claims 1 to 3, characterized in that The first device is the second device.

5. The method according to claim 4, characterized in that The first information includes a service identifier of the second device.

6. The method according to any one of claims 1 to 3, characterized in that The first device is a configuration management device of the second device, and the first information includes a service identifier of the second device.

7. The method according to claim 5 or 6, characterized in that The first information includes a first field, and the first field indicates a service identifier of the second device.

8. The method according to claim 7, characterized in that The first information is a deregistration request, and the first field is a service identification field.

9. The method according to claim 6, characterized in that The first information includes a first query parameter, which is a service identifier of the second device.

10. The method according to claim 9, characterized in that The first information is a logout request.

11. The method according to any one of claims 1 to 10, characterized in that The method further comprises: The first device receives second information sent by the service device, where the second information is used to indicate whether the service device successfully deregisters the client corresponding to the second device.

12. The method according to claim 11, characterized in that The second information is a logout response.

13. A method for deregistering a device, characterized in that: include: The service device receives first information sent by the first device, where the first information is used to request the service device to deregister a client corresponding to the second device; The service device performs a logout operation according to the first information.

14. The method according to claim 13, characterized in that The service device stores one or more of the following correspondences: the access token and the service identifier of the device corresponding to the access token, the access token and the account identifier of the platform account where the corresponding device is located, and the service identifier and the account identifier.

15. The method according to claim 13 or 14, characterized in that The first device is the second device, and the service device performs a deregistration operation according to the first information, including: The service device deletes the relevant information of the second device.

16. The method according to claim 15, characterized in that The first information includes a service identifier of the second device, and the service device deletes the relevant information of the second device, including: The service device determines, based on the first information and the corresponding relationship, whether the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information; In a case where the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information, the service device deletes the relevant information of the second device.

17. The method according to claim 14, characterized in that The first device is a configuration management device of the second device, the first information includes a service identifier of the second device, and the service device performs a deregistration operation according to the first information, including: The service device deletes the relevant information of the second device.

18. The method according to claim 17, characterized in that The service device deletes the relevant information of the second device, including: The service device determines, based on the first information and the corresponding relationship, whether the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token in the first information; In a case where the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token, the service device deletes the relevant information of the second device.

19. The method according to claim 18, characterized in that The method further comprises: The service device sends third information to the second device, where the third information is used to indicate that the client corresponding to the second device has been deregistered from the service device.

20. The method according to claim 19, characterized in that The third information is a logout event notification, and the third information includes an identifier and / or type of the logout event.

21. The method according to any one of claims 17 to 20, characterized in that The first information includes a first field, and the first field indicates a service identifier of the second device.

22. The method according to claim 21, characterized in that The first information is a deregistration request, and the first field is a service identification field.

23. The method according to any one of claims 17 to 20, characterized in that The first information includes a first query parameter, which is a service identifier of the second device.

24. The method according to claim 23, wherein The first information is a logout request.

25. The method according to any one of claims 13 to 24, characterized in that The method further comprises: The service device sends second information to the first device, where the second information is used to indicate whether the service device successfully deregisters the client corresponding to the second device.

26. The method according to claim 25, characterized in that The second information is a logout response.

27. A method for deregistering a device, characterized in that: include: The second device receives third information sent by the service device, where the third information is used to indicate that the client corresponding to the second device has been deregistered from the service device; The second device deletes the configuration information of the second device.

28. The method according to claim 27, characterized in that The third information is a logout event notification, and the third information includes an identifier or type of the logout event.

29. A device for deregistering a device, characterized in that: include: A sending unit is configured to send first information to a service device, where the first information is used to request the service device to deregister a client corresponding to the second device.

30. The device according to claim 29, characterized in that The service device stores one or more of the following correspondences: the access token and the service identifier of the device corresponding to the access token, the access token and the account identifier of the platform account where the corresponding device is located, and the service identifier and the account identifier.

31. The method according to claim 29 or 30, characterized in that The device is used to obtain a user operation, and the user operation is used to trigger the device to request the service device to deregister a client corresponding to the second device.

32. The device according to any one of claims 29 to 31, characterized in that The apparatus is the second device.

33. The device according to claim 32, characterized in that The first information includes a service identifier of the second device.

34. The device according to any one of claims 29 to 31, characterized in that The apparatus is a configuration management device of the second device, and the first information includes a service identifier of the second device.

35. The device according to claim 33 or 34, characterized in that The first information includes a first field, and the first field indicates a service identifier of the second device.

36. The device according to claim 35, characterized in that The first information is a deregistration request, and the first field is a service identification field.

37. The device according to claim 34, characterized in that The first information includes a first query parameter, which is a service identifier of the second device.

38. The device according to claim 37, characterized in that The first information is a logout request.

39. The device according to any one of claims 29 to 38, characterized in that The apparatus further includes a receiving unit configured to receive second information sent by the service device, where the second information is used to indicate whether the service device successfully deregisters the client corresponding to the second device.

40. The device according to claim 39, characterized in that The second information is a logout response.

41. A device for deregistering a device, characterized in that: include: a receiving unit, configured to receive first information sent by a first device, wherein the first information is used to request the apparatus to deregister a client corresponding to a second device; An execution unit, configured to execute a logout operation according to the first information.

42. The device according to claim 41, characterized in that The device stores one or more of the following correspondences: the access token and the service identifier of the device corresponding to the access token, the access token and the account identifier of the platform account where the corresponding device is located, and the service identifier and the account identifier.

43. The device according to claim 41 or 42, characterized in that The first device is the second device, and the execution unit is specifically configured to delete relevant information of the second device.

44. The device according to claim 43, characterized in that The first information includes the service identifier of the second device, and the execution unit is specifically used to: determine whether the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information based on the first information and the corresponding relationship; if the service identifier of the second device is the same as the service identifier of the device corresponding to the access token in the first information, delete the relevant information of the second device.

45. The device according to claim 42, characterized in that The first device is a configuration management device for the second device, the first information includes a service identifier of the second device, and the execution unit is specifically configured to delete relevant information of the second device.

46. ​​The device according to claim 45, characterized in that The execution unit is specifically used to: determine whether the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token in the first information based on the first information and the corresponding relationship; if the account identifier corresponding to the service identifier of the second device is the same as the account identifier corresponding to the access token, delete the relevant information of the second device.

47. The device according to claim 46, characterized in that The apparatus further includes a sending unit configured to send third information to the second device, where the third information is used to indicate that the client corresponding to the second device has been deregistered from the apparatus.

48. The device according to claim 47, characterized in that The third information is a logout event notification, and the third information includes an identifier and / or type of the logout event.

49. The device according to any one of claims 45 to 48, characterized in that The first information includes a first field, and the first field indicates a service identifier of the second device.

50. The device according to claim 49, characterized in that The first information is a deregistration request, and the first field is a service identification field.

51. The device according to any one of claims 45 to 48, characterized in that The first information includes a first query parameter, which is a service identifier of the second device.

52. The device according to claim 51, characterized in that The first information is a logout request.

53. The device according to any one of claims 41 to 52, characterized in that The apparatus further includes a sending unit configured to send second information to the first device, where the second information is used to indicate whether the apparatus successfully deregisters the client corresponding to the second device.

54. The device according to claim 53, characterized in that The second information is a logout response.

55. A device for deregistering a device, characterized in that: include: A receiving unit, configured to receive third information sent by a service device, wherein the third information is used to indicate that the client corresponding to the apparatus has been deregistered from the service device; An execution unit is configured to delete the configuration information of the device.

56. The device according to claim 55, characterized in that The third information is a logout event notification, and the third information includes an identifier or type of the logout event.

57. A device for deregistering a device, characterized in that: The system comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory to execute the method according to any one of claims 1 to 12, 27, and 28.

58. A device for deregistering a device, characterized in that: The system comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory to execute the method according to any one of claims 13 to 26.

59. A device for deregistering a device, characterized in that: The system comprises a processor configured to call a program from a memory to execute the method according to any one of claims 1 to 12, 27 and 28.

60. A device for deregistering a device, characterized in that: The device comprises a processor configured to call a program from a memory to execute the method according to any one of claims 13 to 26.

61. A chip, characterized in that: The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 1 to 12, 27 and 28.

62. A chip, characterized in that: The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 13 to 26.

63. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 1 to 12, 27, and 28.

64. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 13 to 26.

65. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 12, 27 and 28.

66. A computer program product, characterized in that A program is included, the program causing a computer to execute the method according to any one of claims 13 to 26.

67. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 1 to 12, 27, and 28.

68. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 13 to 26.

Images