WO2024050754A1

WO2024050754A1 - Method for starting client, first device, configuration device, and cloud platform

Info

Publication number: WO2024050754A1
Application number: PCT/CN2022/117782
Authority: WO
Inventors: 茹昭; 吕小强; 包永明; 张军; 杨宁
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-09-08
Filing date: 2022-09-08
Publication date: 2024-03-14

Abstract

Provided are a method for starting a client, a first device, a configuration device, and a cloud platform. The method comprises: a first device receives a first request sent by a configuration device, the first request being used for requesting to start a client in the first device, and the client being used for communicating with a cloud platform. In embodiments of the present application, a first request used for starting a client is introduced, so as to be compatible with requirements of both long-term users and temporary users.

Description

Method for starting the client, first device, configuration device and cloud platform

Technical field

The present application relates to the field of communication technology, and more specifically, to a method for starting a client, a first device, a configuration device and a cloud platform.

Background technique

At present, since the client is usually a temporary client, or the user type of the client is a temporary user, it is stipulated that a complete connection plan needs to be executed when establishing a connection between the client and the cloud platform, that is to say, a complete connection plan needs to be executed Client configuration process, client registration process, and client login process. However, with the development of technology, the user types corresponding to the client also include long-term users. For long-term users, complex connection solutions will degrade the user experience if the connection between the client and the cloud platform needs to be re-established before each use of the client. Therefore, traditional connection solutions are not compatible with both temporary user and long-term user scenarios.

Contents of the invention

This application provides a method for starting a client, a first device, a configuration device and a cloud platform. Each aspect involved in this application is introduced below.

In a first aspect, a method for starting a client is provided, including: a first device receiving a first request sent by a configuration device, the first request being used to request starting the client in the first device, the The client is used to communicate with the cloud platform.

In a second aspect, a method for starting a client is provided, including: the cloud platform communicates with a client configured in a first device, the client of the first device is started based on the first request, and the third A request is used to request to start the client.

In a third aspect, a method for starting a client is provided, including: configuring a device to send a first request to a first device, the first request being used to request to start a client in the first device, and the client The terminal is used to communicate with the cloud platform.

In a fourth aspect, a first device is provided, including: a receiving unit configured to receive a first request sent by a configuration device, the first request being used to request to start a client in the first device, and the client The terminal is used to communicate with the cloud platform.

In a fifth aspect, a cloud platform is provided, including: a communication unit configured to communicate with a client configured in a first device, where the client of the first device is started based on a first request, and the first Request is used to request to start the client.

In a sixth aspect, a configuration device is provided, including: a sending unit configured to send a first request to a first device, the first request being used to request to start a client in the first device, and the client Used to communicate with the cloud platform.

A seventh aspect provides a first device, including a processor, a memory and a communication interface, the memory is used to store one or more computer programs, the processor is used to call the computer program in the memory, so that the The first device performs some or all of the steps of the method of the first aspect.

An eighth aspect provides a cloud platform, including a processor, a memory, and a transceiver. The memory is used to store one or more computer programs. The processor is used to call the computer program in the memory so that the cloud The platform performs some or all of the steps in the method of the second aspect.

A ninth aspect provides a configuration device, including a processor, a memory, and a transceiver. The memory is used to store one or more computer programs. The processor is used to call the computer program in the memory so that the configuration The device performs some or all of the steps of the method of the third aspect.

In a tenth aspect, embodiments of the present application provide a communication system, which includes one or more of the above-mentioned first device, configuration device, and cloud platform. In another possible design, the system may also include other devices that interact with terminal devices or network devices in the solutions provided by the embodiments of this application.

In an eleventh aspect, embodiments of the present application provide a computer-readable storage medium that stores a computer program, and the computer program enables a communication device (for example, a first device, a configuration device, and a cloud platform ) performs some or all of the steps in the methods of each aspect described above.

In a twelfth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause the communication device ( For example, the first device, the configuration device, and the cloud platform) perform some or all of the steps in the methods of the above aspects. In some implementations, the computer program product can be a software installation package.

In a thirteenth aspect, embodiments of the present application provide a chip, which includes a memory and a processor. The processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects. .

In the embodiment of this application, a request for starting the client (also called the "first request") is introduced to start the client to accommodate the needs of both long-term users and temporary users. For long-term users, if the first device has been configured with a client corresponding to the long-term user, the configuration device can directly request to start the client by sending a first request to the client. Compared with the traditional connection scheme, it does not require Repeating the client configuration process helps simplify the connection solution and improve user experience. For a temporary user, after configuring the client corresponding to the temporary user, the configuration device may also request to start the client corresponding to the temporary user by sending a first request to the first device.

Description of the drawings

Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application.

Figure 2 is a model structure of a Matter device applicable to the embodiment of this application.

Figure 3 is a flow chart for connecting the client to the cloud platform.

Figure 4 is a flow chart for starting a client according to an embodiment of the present application.

Figures 5(a) to 5(c) are schematic flowcharts of a method for starting a client according to an embodiment of the present application.

6(a) to 6(c) are schematic flow charts of a method for starting a client according to another embodiment of the present application.

Figure 7 is a schematic diagram of the first device according to the embodiment of the present application.

Figure 8 is a schematic diagram of the cloud platform according to the embodiment of the present application.

Figure 9 is a schematic diagram of a configuration device according to an embodiment of the present application.

Figure 10 is a schematic structural diagram of a communication device according to an embodiment of the present application.

Detailed ways

The technical solutions in this application will be described below with reference to the accompanying drawings. In order to facilitate understanding, the system architecture applicable to the embodiment of the present application will be introduced below with reference to Figure 1 .

Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application. The system 100 shown in Figure 1 may include a first device 110, a configuration device (mediator) 120, a cloud platform 130 and a second device 140.

The first device 110 may be a device capable of communicating with the cloud platform 130 . In some implementations, the first device 110 may be provided with a client, and the client may be used to communicate with the cloud platform 130 and communicate with the second device 140 through the cloud platform 130 . For example, the user can access the cloud platform 130 through the client and access the second device 140 through the cloud platform 130 . For another example, the user can access the cloud platform 130 through the client and control the second device 140 through the cloud platform 130 .

In some embodiments, the above-mentioned client may be an application (application, APP) or an applet, etc.

The second device 140 may be a device capable of communicating with the cloud platform 130 . In some implementations, the second device 140 can provide service functions for users. Therefore, the second device 140 can also be called a server (server) or a service device.

The configuration device 120 is used to configure the first device 110 and/or the second device 140 . For example, the configuration device 120 may configure the first device 110 and/or the second device 140 to communicate with the cloud platform 130 . For another example, the configuration device 120 can configure the client in the first device 110 so that the client can communicate with the cloud platform 130 .

In some implementations, the configuration device 120 may be an application (application, APP) or applet. In other implementations, the configuration device 120 can be installed on a terminal device, where the terminal device can be a mobile phone, a tablet computer (Pad), a notebook computer, a handheld computer, a mobile internet device (mobile internet device, MID), a wearable Equipment, virtual reality (VR) equipment, augmented reality (AR) equipment, wireless terminals in industrial control, wireless terminals in self-driving, remote surgery (remote medical) Wireless terminals in surgery, wireless terminals in smart grid, wireless terminals in transportation safety, wireless terminals in smart city, and wireless terminals in smart home wait. The embodiments of the present application do not limit this.

Cloud platform 130, also known as cloud computing platform or "cloud", can be understood as providing network communication capabilities for services based on hardware resources and software resources. Therefore, in this embodiment of the present application, the client in the first device 110 can access or control the second device 140 through the cloud platform 130 .

In some implementations, the cloud platform 130 can be built based on one or more cloud servers to provide network functions.

It should be noted that the above-mentioned cloud platform 130 can also be other systems or devices that can provide network functions. For example, a cluster system that can provide network functions, etc. The embodiments of the present application do not limit this.

In addition, the above-mentioned configuration device 120 may be an APP or applet that matches the client. Of course, the configuration device 230 may be a different APP or applet from the client. The embodiments of the present application do not limit this.

In some scenarios, the above-mentioned system 100 may be, for example, an Internet of Things (IoT) system. Among them, the Internet of Things is the "Internet where everything is connected", which can be understood as a network that is extended and expanded based on the Internet. Any item can be connected to the Internet through various information sensing devices (such as radio frequency identification, global positioning systems, etc.) Together they form a huge network for information exchange and communication to achieve interconnection between all things.

Correspondingly, in some embodiments, the above-mentioned first device and/or second device may be an IoT device. Among them, IoT devices can include vehicle-mounted terminals, smart home equipment, intelligent monitoring equipment, etc. Smart home devices may include, for example, smart air conditioners, smart refrigerators, washing machines, rice cookers, sweeping robots, and other devices. Intelligent monitoring devices may include, for example, surveillance cameras, temperature sensors, sound sensors and other devices.

In other embodiments, the above-mentioned cloud platform may be an IoT cloud platform, referred to as "IOT cloud", which is used to provide communication service functions for IOT devices in the IOT system.

For ease of understanding, the system 100 is introduced taking an IoT device as an example. Assume that the first device 110 is a vehicle-mounted terminal, the second device 140 is a smart home device, and the configuration device 120 can be a terminal device. Continuing to refer to FIG. 1 , the terminal device 120 can configure the client in the vehicle-mounted terminal 110 so that the client can communicate with the cloud platform 130 . After the client is successfully configured, the user can access and/control the smart home devices on the cloud platform (or smart home devices connected to the cloud platform) through the client. A client that can access and/or control smart home devices can also be called a "smart home client".

For example, assuming that the second device is a smart air conditioner, and the smart air conditioner is located on the cloud platform, at this time, the client can control the switch of the smart air conditioner and set the air conditioner temperature, wind speed, etc. through the cloud platform. When the second device is a sweeping robot, the client can control the sweeping robot to start or stop working, control the working mode of the sweeping robot, etc. through the cloud platform.

At present, different manufacturers may use different communication protocols (also called ecological chain protocols) to achieve interconnection and interoperability between IoT devices that support this communication protocol. This may cause IoT devices produced by different manufacturers to be unable to communicate with each other. The true Internet of Everything cannot be achieved.

Based on this, the Connectivity Standards Alliance (CSA) launched an Internet of Things application layer technology standard—Matter Standard Protocol, which can provide an interoperable application layer for smart home devices based on Internet Protocol (Internet Protocol, IP) solution. In some embodiments, the matter standard may also be called a connected home over IP (CHIP) standard. In some embodiments, the Matter standard can support three underlying communication protocols: Ethernet, Wi-Fi, and Thread, and can allow IoT devices with different protocols to communicate with each other.

Correspondingly, if the client introduced above supports the Matter protocol, it can be called a "Matter client". If the above-mentioned second device supports the Matter protocol, it can be called a "Matter server". The first device and/or the second device supporting the Matter protocol may also be called "Matter devices".

The following uses the Matter protocol scenario as an example to introduce the terminology involved in the embodiments of this application and the solutions of the embodiments of this application. Of course, the solutions in the embodiments of this application can also be applied to other Internet of Things protocols.

Matter device model

Figure 2 is a model structure of a Matter device applicable to the embodiment of this application. The data model structure 200 of the Matter device includes a node 210, an endpoint 220, and a cluster 230.

Node 210 encapsulates an addressable and unique resource on the network, has a set of functions and capabilities, and the user can clearly view it as a functional whole. Typically, node 210 may be the highest or outermost first-order element in the data model. In other words, node 210 is the only addressable element in the outermost layer of the data model.

It should be noted that one physical entity (for example, Matter device) can support multiple nodes 210 . In addition, a node can have multiple node IDs, and the scope of each node ID is a specific network (fabric). For example, when a node ID is used as the target address for an interaction, the network within the scope of the specified node ID is the access network for the interaction. A node may include one or more endpoints 220. Endpoint 220 is an instance, which can be a service or a virtual device, as indicated by the device type. Each endpoint 220 conforms to one or more device type definitions that define the clusters supported on the endpoint. Whereas a cluster is an object class instantiated on an endpoint.

It should be noted that in this architectural model, the above device types can be the highest semantic elements. A device type defines a consistent set of endpoints 220. A device type defines a set of requirements for a node 210 or endpoint 220.

Clusters 230 are functional building block elements of the data model, and thus clusters may also be referred to as "functional sets", "functional clusters", "functional clusters", etc. The cluster specification defines clients and servers that interact with each other. Cluster 230 can be viewed as an interface, service or object class, which is the lowest independent functional element in the data model. Each cluster 230 is defined by a cluster specification that defines the elements of the cluster 230, including properties, events, commands, and behaviors related to interactions with these elements. Properties, events, commands, and behaviors in cluster 230 are mandatory or optional, depending on the definition of cluster 230 .

Generally, the above clusters can be divided into two categories: utility cluster (utility cluster) or application cluster (application cluster). Utility clusters are not part of the endpoint's primary application operations. It can be used for configuration, discovery, addressing, diagnostics, monitoring device health, software updates, and more. It may have a temporary relationship with its cluster counterpart. In this embodiment of the present application, the utility cluster may include a client cluster.

Application clusters (also known as "business clusters") support the primary operations of endpoints. Application clustering supports one or more persistent application interactions between clustered clients and clustered servers. For example, in a switch cluster (On/Off cluster) in a smart light, the client of the cluster can send control commands to the server of the cluster (i.e., switch cluster) to control the switch of the smart light.

A cluster command (also known as a "command") is a set of data fields, each data type, that is passed between client and server cluster instances to invoke the behavior of the command recipient. Currently, the agreement stipulates that each command can be listed in a table, which can contain the data quality columns of the command: identification (ID), name (name), direction (direction), response (response), access (access) ), constraint and conformance. Accordingly, a command can indicate zero or more fields defined in a table. Each command field is defined as a row in the table.

Attributes can be understood as cluster data. Currently, the agreement stipulates that each attribute can be listed in a table, including a data quality column. Data quality columns can include ID, name, (data) type, constraints, other qualities, access, default (value), and consistency. In some implementations, properties may also define their associated semantics and behavior. Properties can reflect the device's queryable/settable status, configuration, and capabilities. In some cases, if no privileges are explicitly defined for a property, default access privileges take effect.

For ease of understanding, the following describes the meanings of several common data qualities contained in commands and properties. It should be noted that the commands and attributes in the embodiments of this application may also include other quantitative qualities, or include part of the above-mentioned data qualities. The embodiments of the present application do not limit this.

Identification represents the unique field ID of the field, or in other words, it is the unique identification of the command.

Name represents the unique name of the field, or in other words, the name of the command.

Type, indicating the data type of a field, the data type of a command parameter, or the data type of an attribute parameter. In some implementations, the value of the data type can be an octet string, expressed as "octstr or octstring"; the value of the data type can be a string (string); the value of the data type can be X Bit unsigned number (unsigned X-bit integer, uintX), where the value of ; Boolean value is represented as "bool".

Direction, usually present in the command list, is used to define the transmission direction of the command. For example, it can be defined as from client to server. For another example, it can be determined from the server to the client.

Access permissions are used to define how an element can be accessed (such as read or write) and what permissions are required to access the data.

In some implementations, access rights may include V, where V indicates that read access or call access requires view privileges. Access permissions can also include O, which means "read access", "write access" or "call access" require operation permissions. Access permissions can also include R, which stands for read access. Access permissions can also include W, which represents write access.

Responses, usually present in a command list, are used to define the command's response.

Quality, used to define additional data quality not covered in other columns.

Default, used to define the default value. It should be noted that the default value is not the value used when the service device returns to the factory refresh settings. The default value can indicate that the consistency specified for the data field can be optional or change over time. Default values can be defined to complete the dependency when the actual data field value is not present.

Consistency, used to define the optionality and dependencies of any data model element or set of elements.

Typically, this column is valid for properties, commands, events, enumerations, and fields of commands, events, or structures. In some implementations, "M" indicates that the corresponding command is part of the basic mandatory feature set.

For commands, client-to-server command consistency means that the server should recognize and support client-to-server commands and generate responses as defined. Server-to-client command consistency means that the server should send commands in a manner defined by cluster behavior, i.e., in response to client-to-server commands. The consistency of the command depends on the supported server features. Clients should not be required to support optional commands or commands that rely on optional features.

Constraints, in some cases, constraints can contain all and desc. Among them, all is used to define that all values are allowed in numeric data types. Desc is used to indicate that the constraints are defined in the description section. In other cases, constraints can also indicate the maximum value of the corresponding parameter value, expressed as "max N". For example, in the embodiment of this application, when N is 99, "max 99" is used to indicate that the maximum value of the corresponding parameter is 99. For another example, in the embodiment of this application, when N is 400, "max 400" is used to indicate that the maximum value of the corresponding parameter is 400. In other cases, constraints can be used to define the number of bytes occupied by parameters. For example, when the value of the constraint is 32, it is used to indicate that the number of bytes occupied by the corresponding parameter is 32.

Range (range) represents the value range of the field.

In some implementations, the range can support two forms: explicit constraints and width constraints. Among them, explicit constraints can indicate the minimum and maximum values corresponding to the values of the fields. For example, explicit constraints indicate that the value range of a certain field is (0, 128).

The above width constraint can be used to limit the number of bytes occupied by the value of a field, or in other words, the width constraint can limit the value of a field to a specific number of bytes. For example, a width constraint can indicate that the maximum number of bytes occupied by the value of a certain field is 8 bytes.

It should be noted that when the value of the range contains "N/A", the indication is not applicable. In addition, in the embodiment of this application, "N/A" may also appear in other parts (other data quality), such as default, constraints, etc.

In addition, the meaning of data quality in the commands or attributes introduced above can be applied to the solution of the embodiment of the present application. For the sake of simplicity, when introducing commands or attributes involving data quality with the same meaning below, you can refer to the above introduction. Repeat.

Connection solution between client and cloud platform

Currently, if you want to communicate with a second device through the cloud platform through the client, the client needs to establish a connection with the cloud platform based on the connection solution between the client and the platform. Among them, the connection solution between the client and the platform includes the client configuration process, client registration process, client login process, etc. The following describes the client configuration process, client registration process, and client login process in conjunction with steps S311 to S327 shown in FIG. 3 .

In step S311, the configuration device determines that the first device has the capability to support the client.

Generally, after the first device establishes a connection with the configuration device, the configuration device can query the capabilities of the first device to determine whether the first device supports the configuration client. Of course, the first device can also directly configure and report the capability of the first device, so that the configuration device can determine whether the first device supports the configuration client.

In step S312, the configuration device pops up a dialog interface, prompting the user to choose whether to agree to use the first device to control the second device.

In step S313, if the user agrees to use the first device to control the second device, the configuration device sends a certificate request to the first device.

(certificate signing request, CSR) request command.

In step S314, the client generates a key pair and stores the private key in the key pair in the safe zone.

In step S315, the client sends a CSR response command to the configuration device to transmit the CSR.

The format of the above-mentioned CSR may be a CSR data format defined in public key cryptography standards (PKCS) #10. Accordingly, CSR can follow the following principles: CSR carries certificate request information, which can include version information, subject information, public key information, etc. The subject information may include the vendor ID of the first device, the product ID of the first device, etc. The public key information may indicate the public key in the above-mentioned key pair (see step S340).

It should be noted that the above-mentioned supplier ID of the first device and the product ID of the first device can be obtained from the data recorded in the basic information cluster (general_Info cluster) of the first device.

In addition, the above-mentioned CSR can be digitally signed, and the digital signature of the CSR can be generated based on the private key in the key pair.

In step S316, the configuration device sends information 1 to the cloud platform, where information 1 is used to apply for a cloud connection credential, that is, an access token (access token) for the client, and information 1 carries a CSR.

In step S317, after the CSR verification is passed, the cloud platform can assign a client identification to the client.

In step S318, the cloud platform generates the client's certificate based on the client ID and public key corresponding to the client.

In step S319, the cloud platform allocates an access token to the client and establishes a binding relationship between the user ID, client ID and access token.

In step S320, the cloud platform uses the client's public key to encrypt the access token to obtain an encrypted access token.

"CToken" means.

In step S321, the cloud platform sends information 2 to the configuration device to indicate the client's certificate and CToken.

The parameters contained in the above information 2 may include CToken, certificate chain (CertChain) and token expiration (TokenExpiration) information. The description of the above parameters and the corresponding attributes can be found in Table 1. Table 1 shows information such as the parameters included in the information 2, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.

Table 1

In step S322, the configuration device sends information 3 to the first device to configure the client's certificate, CToken, and cloud registration address for the client.

The configuration parameters in the above information 3 can include: client certificate (represented by "ClienCert"), intermediate certificate (represented by "IntermediateCert"), root certificate (represented by "RootCert"), cloud address of the cloud platform (cloud address) , CToken and token expiration information. The description of the above parameters, the identification of the parameters, the attributes corresponding to the parameters, and the fields where the parameters are located can be found in Table 2. Table 2 shows the parameters included in the information 3, the field where the parameter is located, the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the necessity of the parameter, and the description of the parameter.

Table 2

In step S323, the first device decrypts the information 3 using the private key to obtain the above parameters in the information 3. And configure the client based on the above parameters.

In step S324, the client connects to the cloud platform based on the cloud address and uses the client certificate to establish a secure connection with the cloud platform.

In step S325, the client sends a registration request (also called "cloud registration request" or "client registration request") to the cloud platform. The above registration request can carry the client ID and access token.

Table 3 shows the interface description of the registration request. Refer to Table 3. The hypertext transfer protocol (HTTP) method based on the registration request can be the POST method, and the interface access address of the registration request can be the account (account). .

table 3

HTTP方法HTTP method	接口访问地址Interface access address
POSTPOST	/account/account

Table 4 shows the interface parameters of the registration request. Table 4 points out the position of the parameters in the registration request in the request, the name of the parameter, the value type of the parameter, whether the parameter is necessary, and the description of the parameter and other information.

Table 4

位置Location	参数parameter	值类型value type	必要性necessity	说明illustrate
主体(body)body	接入令牌access token	stringstring	是yes	客户端的访问令牌Client access token
主体main body	客户端IDClient ID	stringstring	是yes	云平台为客户端分配的客户端ID。The client ID assigned to the client by the cloud platform.

In step S326, the cloud platform sends a registration response command (also called "cloud registration response") to the configuration device. In some implementations, the registration response command will carry the updated access token sent by the cloud platform. Of course, the cloud platform does not need to update the client's access token.

Table 5 shows the parameters included in the registration response command, the location of the parameters, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.

table 5

In step S327, the client of the first device logs in to the cloud platform based on the client identifier and the access token carried in the registration response.

After successfully logging into the cloud platform, the user can communicate with the second device on the cloud platform through the client. For example, discover the second device, access the second device, control the second device, etc.

At present, because the client is usually a temporary client, or the user type of the client is a temporary user, therefore, when establishing a connection between the client and the cloud platform, it is stipulated that the complete solution shown in Figure 3 needs to be executed, that is to say , need to perform the client configuration process, client registration process and client login process. However, with the development of technology, the user types corresponding to the client also include long-term users. For long-term users, complex connection solutions will degrade the user experience if the connection between the client and the cloud platform needs to be re-established before each use of the client. Therefore, traditional connection solutions are not suitable for long-term user scenarios.

The embodiment of the present application provides a solution for starting a client, and introduces a request for starting the client (also called a "first request") to be compatible with the needs of long-term users or temporary users. For long-term users, if the first device has been configured with a client corresponding to the long-term user, the configuration device can directly request to start the client by sending a first request to the client. Compared with the traditional connection scheme, it does not require Repeating the client configuration process helps simplify the connection solution and improve user experience. For a temporary user, after configuring the client corresponding to the temporary user, the configuration device may also request to start the client corresponding to the temporary user by sending a first request to the first device.

The method for starting the client according to the embodiment of the present application is introduced below with reference to Figure 4. Figure 4 is a flow chart for starting a client according to an embodiment of the present application. The method shown in Figure 4 includes step S410.

In step S410, the configuration device sends a first request to the first device.

The first request is used to request the first device to start the client (also called "client to be started"). Therefore, the first request can also be called "start client request" (start client request).

The user type of the above-mentioned client may be a long-term user, or in other words, the above-mentioned client may be a long-term client. Taking the first device as a vehicle as an example, the user corresponding to the client may be the owner of the vehicle. Of course, the user type of the above-mentioned client can also be a temporary user, or in other words, the above-mentioned client can be a temporary client. Taking the first device as a vehicle as an example, the user corresponding to the client may be a temporary passenger of the vehicle.

In some implementations, the first device may also send a response command to the first request (see step S420) to the configuration device to indicate whether the client is successfully started.

In some implementations, the first request may indicate the client to be activated by carrying indication information of the client to be activated. The indication information may be, for example, a client identifier.

In order to improve the security of starting the client, the client can be started based on the startup password, where the startup password is used to verify whether to start the client, or in other words, the startup password is used to authenticate the user who starts the client, or in other words, to start the client. The password is used to authenticate to the configuration device. If the startup password is used to authenticate the configuration device, the startup password can also be called the configuration device password (mediator password, MedPassword).

In some implementations, the first request may carry the client's startup password. Correspondingly, if the startup password carried in the first request matches the startup password of the client prestored in the first device, the client can be started. On the contrary, if the startup password carried in the first request does not match the startup password of the client prestored by the first device, the client may be refused to be started.

It should be noted that the above matching can be understood as the startup password carried in the first request is the same as the pre-stored startup password of the client, or the startup password carried in the first request is different from the pre-stored startup password of the client but satisfies the preset correspondence. relation. The embodiments of the present application do not limit this.

In some implementations, the client can inform the configuration device of the client's startup password, so that when the configuration device starts the client through the first request, it can carry the startup password in the first request. Among them, the client can carry the above-mentioned startup password through the add cloud response command (also known as the "response command for the second request").

Table 6 shows the parameters carried in the add cloud response command in the embodiment of the present application. Refer to Table 6. The add cloud response command may include: status code (status code) and startup password, where the status code is used to indicate to the client Whether the cloud platform was added successfully.

Table 6

IDID	字段Field	数据类型type of data	约束constraint	质量quality	默认值default value	必要性necessity
00	状态编码status code	octstroctstr				MM
11	启动口令Start password	octstroctstr	3232			MM

In some scenarios, the first device may be equipped with clients that communicate with different cloud platforms, and the client identifiers of these clients may be the same. In this case, the first request may carry the cloud platform corresponding to the client to be started. Instruction information so that the first device can identify the client to be started. Of course, if different clients in the first device have unique identifiers (for example, client IDs), the first request may only carry the unique identifier corresponding to the client to be started, and no longer carry the indication information of the cloud platform.

The above indication information of the cloud platform may be any information used to identify the cloud platform, which is not limited in the embodiments of the present application. For example, the indication information of the cloud platform may be the identification of the cloud platform (cloud ID). For another example, the indication information of the cloud platform may be the address of the cloud platform.

For ease of understanding, possible implementations of the first request are introduced below in conjunction with Table 7. Referring to Table 7, the parameters in the first request may include the client identifier of the client to be activated, the activation password of the client to be activated, and the cloud address corresponding to the client to be activated. In addition, Table 7 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.

Table 7

IDID	字段Field	数据类型type of data	约束constraint	质量quality	默认值default value	必要性necessity
00	客户端标识Client ID	octstroctstr	max99max99			MM
11	启动口令Start password	octstroctstr	3232			MM

2

Cloud address

string

M

Correspondingly, after receiving the above-mentioned first request, the first device may determine the client to be started based on the client identifier in the first request. Then based on the correspondence between the pre-stored client identification and the startup password, it is determined whether the pre-stored startup password of the client to be started matches the startup password in the first request. And based on the corresponding relationship between the pre-stored client and the cloud address, it is determined whether the pre-stored cloud address of the client to be started matches the cloud address in the first request.

If both the startup password and the cloud address match, the first device can start the client to be started, and send a response command to the first request to the configuration device to indicate that the client is started successfully. On the contrary, if at least one of the startup password and the cloud address does not match, the first device may refuse to start the client to be started, and send a response command to the first request to the configuration device to indicate that the client fails to start.

In some implementations, client information such as client identification and cloud platform indication information introduced above can be maintained as attributes of the functional cluster. That is to say, the first device may include a function cluster (also called a "client function cluster"), and the function cluster is used to record the client in the first device. Generally, for information about clients of long-term users, the first device may be recorded in the functional cluster, and for information about clients of temporary users, the first device may not be recorded in the functional cluster.

For ease of understanding, possible implementation methods of functional clusters are introduced below in conjunction with Table 8. Referring to Table 8, the functional cluster can include attributes: long-term user list (or long-term client list), the constraint of this attribute can be "all", the quality of this attribute can be "N", and the permission of this attribute can be " R", the default value of this attribute can be "empty", the necessity of this attribute can be "M", the data type of this attribute can be a list, and the client structure (represented as "ClientStruct" is recorded in the list ").

Table 8

IDID	名称name	数据类型type of data	约束constraint	质量quality	权限Permissions	默认值default value	必要性necessity
00	长期用户列表Long term user list	列表[客户端结构体]list[client structure]	allall	NN	RR	空null	MM

Among them, the client information recorded in the client structure can be as shown in Table 9, including client identification, user identification and cloud address. In addition, Table 9 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the authority of the parameter, the default value of the parameter and the necessity of the parameter.

Table 9

IDID	名称name	数据类型type of data	约束constraint	质量quality	权限Permissions	默认值default value	必要性necessity
00	客户端标识Client ID	octstringoctstring	max99max99		RR		MM
11	用户标识User ID	octstringoctstring	max99max99		RR		MM
22	云地址Cloud address	stringstring			RR		MM

In some implementations, before sending the first request, the configuration device may query whether there is a suitable client in the first device (for example, a client corresponding to the cloud platform where the configuration device is located). If it is determined that the first device is configured with If there is a suitable client, the configuration device can request the first device to start the client by sending a first request.

For example, if the configuration device confirms that the long-term user list contains the same client as the cloud platform where the configuration device is located (that is, the client's cloud address is consistent with the cloud address where the configuration device is located), and the user ID of the client is also consistent with the user ID of the configuration device , the configuration device can determine that the first device has been configured with a client connected to the cloud platform. At this time, the configuration device can directly start the client through the first request.

As introduced above, the information of the client in the first device can be maintained through the functional cluster. Correspondingly, the commands supported by the client (for example, the command for configuring the client and/or the command for starting the client) can also be maintained through the same Functional cluster maintenance. That is to say, the above functional cluster also includes commands supported by the client.

In some implementations, the above functional cluster includes one or more of the following commands: a first request; a response command for the first request; a second request for instructing the client to add the cloud platform; a response command for the second request , where the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the client's CSR; the response command for the third request, where the response command for the third request is used to The cloud platform requests a certificate from the client for authentication.

The above second request is also called add cloud request. In some implementations, the second request includes one or more of the following information: the client's certificate information for authentication on the cloud platform, the cloud platform's Instruction information, as well as access token information of the cloud platform.

Correspondingly, the response command for the second request may also be called "add cloud response command". In some implementations, the response command to the second request includes: information indicating whether the cloud platform is successfully added, and/or the client's startup password.

The above third request may also be called a CSR request command, and accordingly, the third response command to the third request command may be called a "CSR response command".

For ease of understanding, the commands supported by the functional cluster in the embodiment of this application are introduced below in conjunction with Table 10. Referring to Table 10, the commands included in the functional cluster include CSR request command, CSR response command, add cloud request command, add cloud response command, and start client request command. In addition, Table 10 also shows the identification corresponding to each command, the direction of the command, the response of the command, the authority of the command, and the necessity of the command.

Table 10

In the embodiment of the present application, the above-mentioned client information and commands supported by the client can also be maintained through multiple different functional clusters, which is not limited in the embodiment of the present application. In addition, the parameters contained in each of the above commands will be introduced in detail below. For the sake of brevity, they will not be described again here.

The above describes the client startup process in the embodiment of the present application, and the following describes the client configuration process in the embodiment of the present application.

If the configuration device determines that the client is not configured in the first device, the client configuration process may be triggered. In some implementations, the configuration device can read the long-term user list in the first device. If a suitable client is not recorded in the long-term user list, the client configuration process can be triggered.

For example, if the configuration device confirms that the long-term user list does not contain the same client as the cloud platform where the configuration device is located (that is, the cloud address of the client is consistent with the cloud address of the configuration device), and/or, the user of the client in the first device The ID is inconsistent with the user ID of the configuration device, and the configuration device determines that the first device is not configured with a client connected to the cloud platform. At this time, the configuration device can trigger the client configuration process.

The first device may perform related operations slightly differently for a long-term user client or a temporary user client. Therefore, during the process of configuring the client, the configuration device may inform the first device of the user type of the client. In some implementations, the configuration device may send first indication information to the first device to indicate the user type of the client. The first indication information may indicate that the user type of the client is a long-term user, or the first indication information may indicate that the user type of the client is a temporary user. Alternatively, the second indication information may indicate whether the user type of the client is a long-term user. Alternatively, the second indication information may indicate whether the user type of the client is a temporary user.

The above-mentioned first indication information may be carried in a CSR request command (also called a third request). The parameters of the CSR request command in the embodiment of this application are introduced below in conjunction with Table 11. Referring to Table 11, the CSR request can carry the parameter long-term user (ie, the first indication information) to indicate the user type corresponding to the client. Among them, the identifier of the long-term user field can be 0, and the data type of this field can be a Boolean value. When the Boolean value is true (true), it is used to indicate that the user type of the client is a long-term user. When the Boolean value is false, it is used to indicate that the client's user type is a temporary user.

Table 11

IDID	字段Field	数据类型type of data	约束constraint	质量quality	默认值default value	必要性necessity
00	长期用户long term user	boolbool			FalseFalse	MM

It should be noted that the above-mentioned first instruction information can also be carried in other commands except the CSR request command, or the first instruction information can also be carried in a dedicated command, which is not limited in the embodiments of the present application.

In some implementations, after receiving the CSR request command, the first device may send a CSR response command (also called a "response command for the third request") to the configuration device, where the CSR response command carries the client's CSR. Table 12 shows the parameters of the CSR response command in the embodiment of the present application. Refer to Table 12. The CSR request can carry the parameter CSR. In addition, Table 12 also shows the identification corresponding to the parameters, the data type of the parameters, the constraints of the parameters, the quality of the parameters, the default values of the parameters, and the necessity of the parameters.

Table 12

IDID	字段Field	数据类型type of data	约束constraint	质量quality	默认值default value	必要性necessity
00	CSRCSR	octstroctstr	max 900max 900			MM

The relevant operations performed by the cloud platform may be slightly different for long-term users or temporary users. Therefore, during the process of configuring the client, the cloud platform can be informed of the user type of the client. In some implementations, the configuration device may send second indication information to the cloud platform to indicate the user type of the client. The second indication information may indicate that the user type of the client is a long-term user, or the second indication information may indicate that the user type of the client is a temporary user. Alternatively, the second indication information may indicate whether the user type of the client is a long-term user. Alternatively, the second indication information may indicate whether the user type of the client is a temporary user.

The above-mentioned second instruction information may be carried in a client application request (also called an "application request"), where the client application request is used to apply for the client's certificate and token from the cloud platform. The following describes the client application interface description and the parameters in the client application request according to the embodiment of the present application in conjunction with Table 13 and Table 14. Refer to Table 13. The HTTP method used by the client to apply for the interface is POST, and the interface access address is "/addclient".

Table 13

HTTP MethodHTTP Method	接口访问地址Interface access address
POSTPOST	/addclient/addclient

Table 14 shows the parameters carried in the client application request command. The application request command may include acceptance, Internet media type (content-type), access token, CSR, and long-term user. In addition, Table 14 also shows the location, value type, necessity and description of the parameters.

Table 14

In some implementations, the user type of the client may be configured by the user through the configuration device. That is to say, the user can select the user type of the client as a long-term user or a temporary customer by configuring the device. Of course, in the embodiment of the present application, other methods can also be used to help the configuration device determine the user type of the client, and the embodiment of the present application does not limit this.

In this application embodiment, the cloud platform can send the client's certificate to the configuration device through a client application response command for the client application request. In some implementations, the above certificate can be indicated by the parameter "CertChain" in the client application response command. In other implementations, the above certificate may include one or more of a client certificate (represented by "ClienCert"), an intermediate certificate (represented by "IntermediateCert"), and a root certificate (represented by "RootCert").

Usually, the client needs to access the cloud platform based on the access token. In some scenarios, the client may need to access the cloud platform multiple times. If the client uses the same access token each time to access the cloud platform, it may not be conducive to improving the security of the cloud platform. For example, for a long-term user client, the user may access the cloud platform multiple times through the client. If the access token remains unchanged, it may be intercepted by the attacker, threatening the security of the cloud platform.

Therefore, in this embodiment of the present application, the cloud platform can configure a first token (also called "refresh token") for the client, which is used by the client to request the cloud platform to update the access token. Accordingly, the client can access the cloud platform based on the updated access token. The above access token update mechanism helps to improve the security of the cloud platform compared to always using the same access token to access the cloud platform.

In some implementations, when the original access token of the first device expires, the first device can apply to the cloud platform for updating the access token based on the first token. Of course, the embodiment of this application does not specifically limit the timing of applying for an update token. For example, the first device can also apply to the cloud platform for an update access token based on the first token when the original access token is about to expire. . That is, the first device may apply to the cloud platform for updating the access token based on the first token at the target time, where the expiration time of the target time and the original access token is less than the first time interval. For another example, the first device may periodically apply to the cloud platform for updating the access token, where the update period of the access token may be less than or equal to the validity period of the access token.

In some implementations, the above-mentioned first token may be carried in the registration response command. Table 15 shows the interface parameters of the registration response command in the embodiment of this application. Referring to Table 15, the registration response command may include access token, token expiry, user identification and first token. Among them, the position of the above parameters in the command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter can be found in Table 15.

Table 15

In some implementations, the first device can log in to the cloud platform based on the user identity, that is, the first device sends the second information to the cloud platform. Among them, the second information is used to request to log in to the cloud platform. Therefore, the second information may be called a "login request". The second information may include the user identification of the client.

The description of the login interface and the parameters included in the login request according to the embodiment of the present application are shown below in conjunction with Table 16 and Table 17. As shown in Table 16, the HTTP method of the login interface can be POST, and the access address of the login interface can be expressed as "/session".

Table 16

HTTP方法HTTP method	接口访问地址Interface access address
POSTPOST	/session/session

Referring to Table 17, the login request command may include acceptance, Internet media type (content-type), access token, user ID, client ID, and login status (login). Among them, the position of each parameter in the command, the value type of the parameter, the necessity of the parameter, and the description of the parameter can be seen in Table 17.

Table 17

In some scenarios, the AMTP protocol can be used to communicate between the client and the second device. In this case, the client needs to send the client's access address to the cloud platform so that subsequent communication can be based on the client's access address. That is, the above method also includes: the first device sends third information to the cloud platform, and the third information includes the access address of the client. Among them, the access address is an access address based on the AMTP protocol.

In some implementations, if the third information carries the access address of the client, the cloud platform can determine that the client selects the AMTP protocol for communication. That is to say, the third information is also used to indicate that the communication protocol supported by the client is the AMTP protocol. .

In some implementations, the above third information may be carried in a registration request, where the registration request is used by the client to request registration on the cloud platform. The parameters carried in the registration request in the embodiment of this application are introduced below in conjunction with Table 18. As shown in Table 18, the registration request may include an access token, a client identifier, and a client access address (eg, client uniform resource locator (ClientURL)). In addition, Table 18 also shows the position of each parameter in the command, the value type of the parameter, the necessity of the parameter, and the description of the parameter.

Table 18

It should be noted that the interface description of the registration request can be found in Table 3. For the sake of brevity, it will not be described again here.

In other implementations, the third information may be carried in the login request, which is used by the client to request to log in to the cloud platform. The parameters carried in the login request command in the embodiment of this application are introduced below in conjunction with Table 19. Compared with the parameters shown in Table 17, the parameters in Table 19 include the client access address (for example, ClientURL).

Table 19

It should be noted that the interface description of the login request can be found in Table 16. For the sake of brevity, it will not be described again here.

Correspondingly, if the client and the second device communicate based on the AMTP protocol, the cloud platform can inform the first device of the access address of the second device, that is, the access address of the second device based on the AMTP protocol (also known as "access URL"). "). That is to say, the above method further includes: in response to the third information, the first device receives fourth information sent by the cloud platform, where the fourth information includes the access address of the second device to be accessed by the client.

Correspondingly, when the client successfully logs in to the cloud platform, the client can communicate with the second device based on the access address of the second device. For example, the client can send control information to the second device based on the access address of the second device to control the second device.

In some implementations, the above fourth information may be carried in a response command to the registration request, that is, a registration response command. Table 20 shows the parameters included in the registration response command in this embodiment of the present application. As shown in Table 20, the registration response command includes an access token, a user ID, and an access URL, where the access URL is used to indicate the access address of the second device. In addition, Table 20 also shows the position of the above parameters in the registration response command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter.

Table 20

In other implementations, the above fourth information may be carried in a response command to the login request, that is, a login response command. Table 21 shows the parameters included in the login response command in the embodiment of this application. As shown in Table 21, the login response command includes an access token, a client identifier, and a URL of the client, where the access URL is used to indicate the access address of the second device. In addition, Table 21 also shows the position of the above parameters in the login response command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter.

Table 21

In the embodiment of the present application, the transmission method of the third information and the transmission method of the fourth information introduced above can be used alone or in combination. For example, the third information may be carried in the login request, and accordingly, the fourth information may be carried in the login response command. For another example, the third information may be carried in the registration request, and accordingly, the fourth information may be carried in the registration response command. For another example, the third information may be carried in the registration request, and correspondingly, the fourth information may be carried in the login response command. For another example, the third information may be carried in the registration response, and correspondingly, the fourth information may be carried in the login request.

In addition, the embodiment of the present application does not limit the order of interaction between the access address of the client and the access address of the second device. As mentioned above, in one implementation, the client may first send the client's access address to the cloud platform, and then the cloud platform may send the access address of the second device to the client. In another implementation manner, the cloud platform may first send the access address of the second device to the client, and then the client may send the access address of the client to the cloud platform. For example, the cloud platform may send the access address of the second device to the client through a registration response command, and then the client sends the client's access address to the cloud platform through a login request.

In order to facilitate understanding, the solution of the embodiment of the present application will be introduced below with reference to Figures 5 and 6, taking the IOT scenario as an example. At this time, the above-mentioned cloud platform can be an IoT cloud platform, the client can be an IoT client, the first device can be a vehicle-mounted terminal, the second device can be a smart home device, and the configuration device can be a mobile phone. In addition, the command and information function clusters involved in Figure 5 and Figure 6 have the same meaning as the above introduction and use the same names. For the sake of brevity, please refer to the above introduction and will not go into details below.

Figures 5(a) to 5(c) are schematic flowcharts of a method for starting a client according to an embodiment of the present application. The method shown in Figure 5(a) includes steps S511 to S527.

In step S511, the mobile phone establishes a secure connection with the vehicle-mounted terminal.

For example, a mobile phone can establish a connection with a vehicle-mounted terminal through Bluetooth low energy (BLE) combined with the wireless network communication technology Wifi.

In step S512, the mobile phone checks the client cluster of the vehicle-mounted terminal.

Among them, the client cluster can be seen in the above introduction combined with Table 9 and Table 10. For the sake of simplicity, it will not be described again here.

In step S513, the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.

It should be noted that step S513 may be located before step S512, or the two steps may be performed simultaneously, or step S512 may be located before step S513, which is not limited in the embodiment of the present application.

In step S514, the mobile phone reads the long-term user list in the client cluster and confirms whether a suitable client is recorded in the long-term user list.

If the long-term user list includes a client that is the same as the cloud platform where the mobile phone is located, and the user ID of the client is consistent with the user ID of the mobile phone, step S515 is executed. If the client included in the long-term user list is different from the cloud platform where the mobile phone is located, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S516 is executed.

In step S515, the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.

In step S516, the mobile phone prompts the user to select long-term mode or temporary mode.

The above long-term mode corresponds to creating a client whose user type is long-term user, and the temporary mode can correspond to creating a client whose user type is temporary user. The following description takes the client where the user chooses to create a long-term user as an example. The solution below can also be applied to creating temporary users.

In step S517, the mobile phone sends a CSR request command to the IoT client. Among them, the CSR request command can carry the user type of the client.

In addition, the CSR request command can be found in the introduction shown in Table 11 above.

In step S518, the IoT client generates a key pair and sends a CSR response command to the mobile phone. Among them, the CSR response command can be found in the introduction above in conjunction with Table 12.

In step S519, the mobile phone sends a client application request command to the IoT cloud platform to apply for an IoT client certificate and token through the IoT cloud interface. Among them, the client's application request carries the client's user type.

In addition, the parameters included in the client application request can be found in the above introduction in combination with Table 13 and Table 14.

In step S520, the IoT cloud platform sends a client application response command to the mobile phone.

In some implementations, the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface. Table 22 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.

Table 22

In step S521, the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.

Table 23 shows the parameters included in the add cloud request command in this embodiment of the present application. Referring to Table 23, the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information. In addition, Table 23 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.

Table 23

IDID	字段Field	数据类型type of data	约束constraint	质量quality	默认值default value	必要性necessity
00	IOT客户端证书IoT client certificate	octstringoctstring	max400max400			MM

11	中间证书intermediate certificate	octstringoctstring	max400max400	OO
22	根证书root certificate	octstringoctstring	max400max400	MM
33	云地址Cloud address	stringstring		MM
44	CTokenCToken	octstringoctstring		MM
55	令牌到期信息Token expiry information	uint16uint16		MM

In step S522, the IoT client uses the private key in the key pair to decrypt the Ctoken and obtain the access token.

In step S523, the IoT client sends an add cloud response command to the mobile phone. Among them, the add cloud response command includes the client's startup password.

Usually, when the user type of the IoT client is a long-term user, the mobile phone can store the startup password in the add cloud response command and associate the startup password with the client ID and cloud address of the IoT client. In addition, to add cloud response commands, please refer to the relevant introduction in Table 6 above.

In step S524, the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client. For the command to start the client request, please refer to the introduction shown in Table 7 above.

It should be noted that the above-mentioned steps S515 and S524 can be understood as two scenarios of sending a start client request command. Step S515 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S515. Step S524 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S524 after reconfiguring the client.

In step S525, the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.

If the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster, step S526 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S527 is executed.

In step S526, the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.

In step S527, the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.

In some implementations, the vehicle-mounted terminal can indicate to the mobile phone the reason why the IoT client fails to start, for example, the startup password of the IoT client is wrong, the client ID of the IoT client does not exist, etc.

It should be noted that during the above client configuration process, the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320. For simplicity, please refer to the above introduction.

The above describes the client configuration process and client startup process in conjunction with steps S511 to S527. If the IoT client starts successfully, the client registration process will be introduced below with reference to Figure 5(b). The method shown in Figure 5(b) includes steps S531 to S533.

In step S531, the IoT client connects to the IoT cloud address and uses the certificate to establish a secure connection with the IoT cloud platform.

In step S532, the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.

In some implementations, the client registration request may include the client ID and access token. For the client registration request, please refer to the introduction in Table 3 above.

In step S533, in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.

In some scenarios, the client registration response command can carry a new access token, user ID, and first token assigned by the IoT cloud platform to the IoT client. For the client registration response command, please refer to the introduction in Table 5 above.

The client login process in the embodiment of this application is introduced below with reference to Figure 5(c). The method shown in Figure 5(c) includes steps S541 to S542.

In step S541, the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.

In some implementations, the above login request includes a user ID, a client ID, and an access token. Please refer to the introduction in conjunction with Table 17 above.

In step S542, in response to the login request, the IoT cloud platform sends a login response command to the IoT client.

Table 24 shows a possible implementation of the login response command in the embodiment of this application. As shown in Table 24, the login response command may include Internet media type and token expiration information.

Table 24

6(a) to 6(c) are schematic flow charts of a method for starting a client according to another embodiment of the present application. The method shown in Figure 6(a) includes steps S611 to S627. It should be noted that the method shown in Figure 6 can be applied to the client using the AMTP protocol to communicate with smart home devices.

In step S611, the mobile phone establishes a secure connection with the vehicle-mounted terminal.

In step S612, the mobile phone checks the client cluster of the vehicle-mounted terminal.

In step S613, the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.

It should be noted that step S613 may be located before step S612, or the two steps may be performed simultaneously, or step S612 may be located before step S613, which is not limited in the embodiment of the present application.

In step S614, the mobile phone reads the long-term user list in the client cluster and confirms whether a suitable client is recorded in the long-term user list.

If the long-term user list includes a client that is the same as the cloud platform where the mobile phone is located, and the user ID of the client is consistent with the user ID of the mobile phone, step S615 is executed. If the client included in the long-term user list is on a different cloud platform than the mobile phone, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S616 is executed.

In step S615, the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.

In step S616, the mobile phone prompts the user to select long-term mode or temporary mode.

In step S617, the mobile phone sends a CSR request command to the IoT client. Among them, the CSR request command can carry the user type of the client.

In step S618, the IoT client generates a key pair and sends a CSR response command to the mobile phone. Among them, the CSR response command can be found in the introduction above in conjunction with Table 12.

In step S619, the mobile phone sends a client application request command to the IoT cloud platform to apply for an IoT client certificate and token through the IoT cloud interface. Among them, the client's application request carries the client's user type.

In step S620, the IoT cloud platform sends a client application response command to the mobile phone.

In some implementations, the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface. Table 25 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.

Table 25

In step S621, the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.

Table 26 shows the parameters included in the add cloud request command in this embodiment of the present application. Referring to Table 26, the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information. In addition, Table 26 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.

Table 26

ID

Field

type of data

constraint

quality

default value

necessity

00	IOT客户端证书IoT client certificate	octstringoctstring	max400max400	MM
11	中间证书intermediate certificate	octstringoctstring	max400max400	OO
22	根证书root certificate	octstringoctstring	max400max400	MM
33	云地址Cloud address	stringstring		MM
44	CTokenCToken	octstringoctstring		MM
55	令牌到期信息Token expiry information	uint16uint16		MM

In step S622, the IoT client decrypts the Ctoken using the private key in the key pair to obtain the access token.

In step S623, the IoT client sends an add cloud response command to the mobile phone. Among them, the add cloud response command includes the client's startup password.

In step S624, the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client. For the command to start the client request, please refer to the introduction shown in Table 7 above.

It should be noted that the above-mentioned step S615 and step S624 can be understood as two scenarios of sending a start client request command. Step S615 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S615. Step S624 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S624 after reconfiguring the client.

In step S625, the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.

If the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster, step S626 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S627 is executed.

In step S626, the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.

In step S627, the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.

The client configuration process and client startup process are introduced above in conjunction with steps S611 to S627. If the IoT client is started successfully, the client registration process will be introduced below with reference to Figure 6(b). The method shown in Figure 6(b) includes steps S631 to S633.

In step S631, the IoT client connects to the IoT cloud address and uses the certificate to establish a secure connection with the IoT cloud.

In step S632, the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.

In some implementations, the client registration request may include the client ID, access token, and access address of the IoT client. For the client registration request, please refer to the introduction in Table 18 above.

In step S633, in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.

In some scenarios, the client registration response command can carry the new access token, user ID, first token, and access address of the smart home device assigned by the IoT cloud platform to the IoT client. For the client registration response command, please refer to the introduction in Table 20 above.

The client login process in the embodiment of this application is introduced below with reference to Figure 6(c). The method shown in Figure 6(c) includes steps S641 to S642.

In step S641, the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.

In some implementations, the above login request includes a user ID, a client ID, and an access token. Please refer to the above introduction in conjunction with Table 17.

In step S642, in response to the login request, the IoT cloud platform sends a login response command to the IoT client.

Table 27 shows a possible implementation of the login response command in the embodiment of this application. As shown in Table 27, the login response command may include Internet media type and token expiration information.

Table 27

It should be noted that in this embodiment of the present application, in addition to using the registration request and registration response commands according to the method shown in Figure 6, the access address of the IoT client and the access address of the smart home device are exchanged. In addition, as described above, the access address of the IoT client and the access address of the smart home device can also be interacted through login request and login response commands. For example, the commands introduced in Table 19 and Table 21 can be used. At this time, the client registration request and client registration response can be combined with the commands introduced in Table 3 and Table 5. For the sake of brevity, no further details will be given below.

The method embodiments of the present application are described in detail above with reference to FIGS. 1 to 6 , and the device embodiments of the present application are described in detail below with reference to FIGS. 7 to 10 . It should be understood that the description of the method embodiments corresponds to the description of the device embodiments. Therefore, the parts not described in detail can be referred to the previous method embodiments.

Figure 7 is a schematic diagram of the first device according to the embodiment of the present application. The first device 700 shown in FIG. 7 includes: a receiving unit 710.

The receiving unit 710 is configured to receive a first request sent by a configuration device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.

In a possible implementation, the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.

In a possible implementation, the first device further includes: a first processing unit, configured to determine whether the startup password carried in the first request matches the prestored startup password of the client; if the The startup password carried in the first request matches the pre-stored startup password, and the first processing unit is also used to start the client.

In a possible implementation, the first request carries indication information of the cloud platform.

In a possible implementation, the first device further includes: a second processing unit configured to select the client based on the cloud platform information carried in the first request.

In a possible implementation, the first device includes a functional cluster, the functional cluster is used to indicate commands supported by the client; and/or the functional cluster is used to record the first device Client corresponding to long-term users.

In a possible implementation, if the user type of the client is a long-term user, the function cluster is used to indicate one or more of the following information of the client: the client identifier of the client; The user identification of the terminal; and the instruction information of the cloud platform.

In a possible implementation, the function cluster includes one or more of the following commands: the first request; a second request for instructing the client to add the cloud platform; for the second The response command for the request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the CSR of the client; the response command for the third request, Wherein, the response command to the third request is used to request from the cloud platform a certificate for identity verification of the client.

In a possible implementation, if the functional cluster includes the second request, the second request includes one or more of the following information: the client authenticates itself on the cloud platform. Certificate information, indication information of the cloud platform, and access token information of the cloud platform.

In a possible implementation, if the function cluster includes the response command to the second request, the response command to the second request includes: information indicating whether the cloud platform is added successfully, and /or, the startup password of the client.

In a possible implementation, the receiving unit is configured to receive the first information sent by the cloud platform, where the first information includes a first token, and the first token is used to send the message to the cloud platform. The cloud platform requests to update the access token.

In a possible implementation, the first device further includes: a first sending unit, configured to send second information to the cloud platform, where the second information is used to request to log in to the cloud platform, the The second information includes the user identification of the client.

In a possible implementation, the receiving unit is configured to: receive first indication information sent by the configuration device, where the first indication information is used to configure the user type of the client.

In a possible implementation, the user type of the client is configured by the user through the configuration device.

In a possible implementation, the user types include long-term users or temporary users.

In a possible implementation, the user type of the client is a long-term user.

In a possible implementation, the first device further includes: a second sending unit, configured to send third information to the cloud platform, where the third information includes the access address of the client.

In a possible implementation, the third information is carried in a registration request of the client requesting to register on the cloud platform, and/or the third information is carried in a login request of the client. Describe the login request of the cloud platform.

In a possible implementation, the access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to use the AMTP protocol to communicate.

In a possible implementation, the receiving unit is configured to: in response to the third information, receive fourth information sent by the cloud platform, where the fourth information includes the information to be accessed by the client. The access address of the second device.

In a possible implementation, the fourth information is carried in a response command to a registration request for the client to register on the cloud platform, and/or the fourth information is carried in a response command to the registration request of the client. In the response command of the login request of the client requesting to log in to the cloud platform.

Figure 8 is a schematic diagram of the cloud platform according to the embodiment of the present application. The cloud platform shown in Figure 8 may be, for example, one or more cloud servers. The cloud platform 800 shown in FIG. 8 includes: a communication unit 810.

The communication unit 810 is used to communicate with the client configured in the first device. The client of the first device is started based on a first request, and the first request is used to request to start the client.

In a possible implementation, the first request carries cloud platform information of the client.

In a possible implementation, the first device includes a functional cluster, and the functional cluster is used to record the client.

In a possible implementation, the function cluster is used to indicate one or more of the following information of the client: a client identification of the client; a user identification of the client; and an indication of the cloud platform information.

In a possible implementation, the function cluster includes one or more of the following commands: the first request; a second request for instructing the client to add the cloud platform; for the second The response command for the request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the CSR of the client; the response command for the third request, Wherein, the response command to the third request is used to request the cloud platform for a certificate used for identity authentication of the client.

In a possible implementation, if the functional cluster includes the second request, the second request includes one or more of the following information: used for the client to identify itself on the cloud platform Verified certificate information, indication information of the cloud platform and access token information of the cloud platform.

In a possible implementation, the communication unit is further configured to: send first information to the first device, where the first information includes a first token, and the first token is used to send The cloud platform requests to update the access token.

In a possible implementation, the communication unit is further configured to: receive second information sent by the first device, where the second information is used to request to log in to the cloud platform. Contains the user ID of the client.

In a possible implementation, the communication unit is further configured to: receive second instruction information sent by the configuration device, where the second instruction information is used to configure the user type of the client.

In a possible implementation, the user type of the client is a long-term user.

In a possible implementation, the communication unit is further configured to receive third information sent by the first device, where the third information includes the access address of the client.

In a possible implementation, the communication unit is further configured to: in response to the third information, send fourth information to the first device, where the fourth information includes the client to be accessed The access address of the second device.

Figure 9 is a schematic diagram of a configuration device according to an embodiment of the present application. The configuration device 900 shown in FIG. 9 includes a sending unit 910.

The sending unit 910 is configured to send a first request to the first device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.

In a possible implementation, the first request carries a startup password of the client, the startup password is used to authenticate the user who starts the client, and/or the first request carries the The client’s cloud platform information.

In a possible implementation, the first device includes a function cluster, the function cluster is used to indicate the commands supported by the client; and/or the function cluster is used to record the commands in the first device. A client for long-term users.

In a possible implementation, if the functional cluster includes the second request, the second request includes one or more of the following information: used for the client to identify itself on the cloud platform The verified certificate information, the address information of the cloud platform and the access token information of the cloud platform.

In a possible implementation, if the response command to the second request includes the startup password of the client, the configuration device further includes: a processing unit, configured to: if the user type of the client is a long-term user, Stores the client's startup password.

In a possible implementation, the sending unit is further configured to: send first indication information to the first device, where the first indication information is used to configure the user type of the client.

In a possible implementation, the user type of the client is a long-term user.

In an optional embodiment, the receiving unit 710 may be a transceiver 1040. The first device 700 may also include a processor 1010 and a memory 1020, as specifically shown in FIG. 10 .

In an optional embodiment, the communication unit 810 may be a transceiver 1040. The cloud platform 800 may also include a processor 1010 and a memory 1020, as specifically shown in Figure 10.

In an optional embodiment, the sending unit 910 may be a transceiver 1040. The configuration device 900 may also include a processor 1010 and a memory 1020, as specifically shown in Figure 10.

Figure 10 is a schematic structural diagram of a communication device according to an embodiment of the present application. The dashed line in Figure 10 indicates that the unit or module is optional. The device 1000 can be used to implement the method described in the above method embodiment. The device 1000 may be a chip, a terminal device or a network device.

Apparatus 1000 may include one or more processors 1010. The processor 1010 can support the device 1000 to implement the method described in the foregoing method embodiments. The processor 1010 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 can also be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or an off-the-shelf programmable gate array (FPGA) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

Apparatus 1000 may also include one or more memories 1020. The memory 1020 stores a program, which can be executed by the processor 1010, so that the processor 1010 executes the method described in the foregoing method embodiment. The memory 1020 may be independent of the processor 1010 or integrated in the processor 1010.

Apparatus 1000 may also include a transceiver 1030. Processor 1010 may communicate with other devices or chips through transceiver 1030. For example, the processor 1010 can transmit and receive data with other devices or chips through the transceiver 1030.

An embodiment of the present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

An embodiment of the present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

An embodiment of the present application also provides a computer program. The computer program can be applied to the terminal or network device provided by the embodiments of the present application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.

It should be understood that the terms "system" and "network" may be used interchangeably in this application. In addition, the terms used in this application are only used to explain specific embodiments of the application and are not intended to limit the application. The terms “first”, “second”, “third” and “fourth” in the description, claims and drawings of this application are used to distinguish different objects, rather than to describe a specific sequence. . Furthermore, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. In addition, "request" in the embodiment of this application can be replaced by "request message", "request command", etc. Correspondingly, "response command" in the embodiment of this application may be replaced by "response message", "response", etc.

In the embodiments of this application, the "instruction" mentioned may be a direct instruction, an indirect instruction, or an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association between A and B. relation.

In the embodiment of this 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 only based on A. B can also be determined based on A and/or other information.

In the embodiments of this application, the term "correspondence" can mean that there is a direct correspondence or indirect relationship between the two, or it can also mean that there is an associated relationship between the two, or it can also be a relationship between indicating and being instructed, configuring and being configured, etc. .

In the embodiment of this application, "predefinition" or "preconfiguration" can be achieved by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in devices (for example, including terminal devices and network devices). The application does not limit its specific implementation method. For example, predefined can refer to what is defined in the protocol.

In the embodiment of this application, the "protocol" may refer to a standard protocol in the communication field, which may include, for example, LTE protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this.

The term "and/or" in the embodiment of this application is only an association relationship describing associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A alone exists, and A and B exist simultaneously. , there are three situations of B alone. In addition, the character "/" in this article generally indicates that the related objects are an "or" relationship.

In the various embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its functions and internal logic, and should not be determined by the implementation process of the embodiments of the present application. constitute any limitation.

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 only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

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

In addition, each functional unit in various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may 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 processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center integrated with one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVD)) or semiconductor media (e.g., solid state disks (SSD) )wait.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application. should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A method for starting a client, characterized by including:

The first device receives a first request sent by the configuration device. The first request is used to request to start a client in the first device. The client is used to communicate with the cloud platform.
The method of claim 1, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
The method of claim 2, further comprising:

The first device determines whether the startup password carried in the first request matches the prestored startup password of the client;

If the startup password carried in the first request matches the prestored startup password, the first device starts the client.
The method of claim 1, wherein the first request carries indication information of the cloud platform.
The method of claim 4, further comprising:

The first device selects the client based on the cloud platform information carried in the first request.
The method according to any one of claims 1 to 5, characterized in that the first device includes a functional cluster, and the functional cluster is used to indicate commands supported by the client; and/or

The function cluster is used to record the client corresponding to the long-term user in the first device.
The method of claim 6, wherein if the user type of the client is a long-term user, the function cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The method of claim 6 or 7, wherein the functional cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the client.
The method of claim 8, wherein if the functional cluster includes the second request, the second request includes one or more of the following information: the client is on the cloud platform Certificate information for identity verification, instruction information of the cloud platform, and access token information of the cloud platform.
The method of claim 8, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform is added successfully. information, and/or, the client's startup password.
The method according to any one of claims 1-10, characterized in that the method further includes:

The first device receives first information sent by the cloud platform, where the first information includes a first token, and the first token is used to request the cloud platform to update the access token.
The method according to any one of claims 1-11, characterized in that the method further includes:

The first device sends second information to the cloud platform, the second information is used to request to log in to the cloud platform, and the second information includes the user identification of the client.
The method according to any one of claims 1-12, characterized in that the method further includes:

The first device receives first indication information sent by the configuration device, where the first indication information is used to configure the user type of the client.
The method of claim 13, wherein the user type of the client is configured by the user through the configuration device.
The method of claim 13 or 14, wherein the user type includes a long-term user or a temporary user.
The method according to any one of claims 1 to 15, characterized in that the user type of the client is a long-term user.
The method according to any one of claims 1-16, characterized in that the method further includes:

The first device sends third information to the cloud platform, where the third information includes the access address of the client.
The method of claim 17, wherein the third information is carried in a registration request of the client to register on the cloud platform, and/or the third information is carried in the client's registration request. The client requests a login request to log in to the cloud platform.
The method of claim 17 or 18, wherein the access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to use the AMTP protocol for communication.
The method according to any one of claims 17-19, characterized in that the method further includes:

In response to the third information, the first device receives fourth information sent by the cloud platform, where the fourth information includes the access address of the second device to be accessed by the client.
The method of claim 20, wherein the fourth information is carried in a response command to a registration request for the client to register on the cloud platform, and/or the fourth information Carried in the response command to the login request of the client requesting to log in to the cloud platform.
A method for starting a client, characterized by including:

The cloud platform communicates with the client configured in the first device, and the client of the first device is started based on a first request, and the first request is used to request to start the client.
The method of claim 22, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
The method of claim 22, wherein the first request carries cloud platform information of the client.
The method according to any one of claims 22 to 24, characterized in that the first device includes a functional cluster, and the functional cluster is used to record the client.
The method of claim 25, wherein the functional cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The method of claim 25 or 26, wherein the functional cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command to the third request, wherein the response command to the third request is used to request a certificate for authentication of the client from the cloud platform.
The method of claim 27, wherein if the functional cluster includes the second request, the second request includes one or more of the following information: used by the client in the Certificate information for identity verification by the cloud platform, instruction information of the cloud platform, and access token information of the cloud platform.
The method of claim 27, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform is added successfully. information, and/or, the client's startup password.
The method according to any one of claims 22-29, characterized in that the method further includes:

The cloud platform sends first information to the first device, where the first information includes a first token, and the first token is used to request the cloud platform to update the access token.
The method according to any one of claims 22-30, characterized in that the method further includes:

The cloud platform receives the second information sent by the first device, the second information is used to request to log in to the cloud platform, and the second information includes the user identification of the client.
The method according to any one of claims 22-31, characterized in that the method further includes:

The cloud platform receives second indication information sent by the configuration device, and the second indication information is used to configure the user type of the client.
The method of claim 32, wherein the user type of the client is configured by the user through the configuration device.
The method of claim 32 or 33, wherein the user type includes a long-term user or a temporary user.
The method according to any one of claims 22 to 34, characterized in that the user type of the client is a long-term user.
The method according to any one of claims 22-35, characterized in that the method further includes:

The cloud platform receives third information sent by the first device, where the third information includes the access address of the client.
The method of claim 36, wherein the third information is carried in a registration request of the client to register on the cloud platform, and/or the third information is carried in the client's registration request. The client requests a login request to log in to the cloud platform.
The method of claim 36 or 37, wherein the access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to use the AMTP protocol for communication.
The method according to any one of claims 36-38, characterized in that the method further includes:

In response to the third information, the cloud platform sends fourth information to the first device, where the fourth information includes the access address of the second device to be accessed by the client.
The method of claim 39, wherein the fourth information is carried in a response command to a registration request for the client to register on the cloud platform, and/or the fourth information Carried in the response command to the login request of the client requesting to log in to the cloud platform.
A method for starting a client, characterized by including:

The configuration device sends a first request to the first device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.
The method of claim 41, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client, and/or

The first request carries the cloud platform information of the client.
The method of claim 41 or 42, wherein the first device includes a functional cluster, and the functional cluster is used to indicate commands supported by the client; and/or

The function cluster is used to record the client corresponding to the long-term user in the first device.
The method of claim 43, wherein the functional cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The method of claim 43 or 44, wherein the functional cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the client.
The method of claim 45, wherein if the functional cluster includes the second request, the second request includes one or more of the following information: used by the client in the Certificate information for identity verification by the cloud platform, address information of the cloud platform and access token information of the cloud platform.
The method of claim 45, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform is added successfully. information, and/or, the client's startup password.
The method of claim 47, wherein if the response command to the second request includes a startup password of the client, the method further includes:

If the user type of the client is a long-term user, the configuration device stores the startup password of the client.
The method according to any one of claims 41-48, characterized in that the method further includes:

The configuration device sends first indication information to the first device, where the first indication information is used to configure the user type of the client.
The method of claim 49, wherein the user type of the client is configured by the user through the configuration device.
The method of claim 49 or 50, wherein the user type includes a long-term user or a temporary user.
The method according to any one of claims 41-51, characterized in that the user type of the client is a long-term user.
A first device, characterized by including:

A receiving unit configured to receive a first request sent by a configuration device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.
The first device according to claim 53, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
The first device according to claim 54, characterized in that the first device further includes:

A first processing unit configured to determine whether the startup password carried in the first request matches the prestored startup password of the client;

If the startup password carried in the first request matches the pre-stored startup password, the first processing unit is also configured to start the client.
The first device according to claim 53, wherein the first request carries indication information of the cloud platform.
The first device according to claim 56, characterized in that the first device further includes:

The second processing unit is configured to select the client based on the cloud platform information carried in the first request.
The first device according to any one of claims 53 to 57, characterized in that the first device includes a functional cluster, and the functional cluster is used to indicate commands supported by the client; and/or

The function cluster is used to record the client corresponding to the long-term user in the first device.
The first device of claim 58, wherein if the user type of the client is a long-term user, the function cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The first device according to claim 58 or 59, characterized in that the functional cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the client.
The first device according to claim 60, characterized in that, if the functional cluster includes the second request, the second request includes one or more of the following information: the client is in the Certificate information for identity verification by the cloud platform, instruction information of the cloud platform, and access token information of the cloud platform.
The first device of claim 60, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform Add success information, and/or, the client's startup password.
The first device according to any one of claims 53-62, characterized in that the receiving unit is used for:

Receive first information sent by the cloud platform, where the first information includes a first token, and the first token is used to request the cloud platform to update the access token.
The first device according to any one of claims 53-63, characterized in that the first device further includes:

The first sending unit is configured to send second information to the cloud platform. The second information is used to request to log in to the cloud platform. The second information includes the user identification of the client.
The first device according to any one of claims 53-64, characterized in that the receiving unit is used for:

Receive first indication information sent by the configuration device, where the first indication information is used to configure the user type of the client.
The first device according to claim 65, characterized in that the user type of the client is configured by the user through the configuration device.
The first device according to claim 65 or 66, characterized in that the user type includes a long-term user or a temporary user.
The first device according to any one of claims 53 to 67, characterized in that the user type of the client is a long-term user.
The first device according to any one of claims 53-68, characterized in that the first device further includes:

The second sending unit is configured to send third information to the cloud platform, where the third information includes the access address of the client.
The first device according to claim 69, wherein the third information is carried in a registration request of the client to register on the cloud platform, and/or the third information is carried in the cloud platform. The client requests a login request to log in to the cloud platform.
The first device according to claim 69 or 70, wherein the access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to use the AMTP protocol for communication.
The first device according to any one of claims 69-71, characterized in that the receiving unit is used for:

In response to the third information, receive fourth information sent by the cloud platform, where the fourth information includes the access address of the second device to be accessed by the client.
The first device according to claim 72, wherein the fourth information is carried in a response command to a registration request of the client requesting to register on the cloud platform, and/or, the third The fourth information is carried in the response command to the login request of the client requesting to log in to the cloud platform.
A cloud platform is characterized by including:

A communication unit configured to communicate with a client configured in the first device, where the client of the first device is started based on a first request, and the first request is used to request to start the client.
The cloud platform of claim 74, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
The cloud platform of claim 74, wherein the first request carries cloud platform information of the client.
The cloud platform according to any one of claims 74 to 76, characterized in that the first device includes a functional cluster, and the functional cluster is used to record the client.
The cloud platform of claim 77, wherein the functional cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The cloud platform of claim 77 or 78, wherein the functional cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command to the third request, wherein the response command to the third request is used to request a certificate for authentication of the client from the cloud platform.
The cloud platform of claim 79, wherein if the functional cluster includes the second request, the second request includes one or more of the following information: for the location of the client. The certificate information for identity verification of the cloud platform, the instruction information of the cloud platform and the access token information of the cloud platform.
The cloud platform of claim 79, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform adds success message, and/or, the client's startup password.
The cloud platform according to any one of claims 74-81, characterized in that the communication unit is also used for:

Send first information to the first device, where the first information includes a first token, and the first token is used to request the cloud platform to update the access token.
The cloud platform according to any one of claims 74-82, characterized in that the communication unit is also used to:

Receive second information sent by the first device, where the second information is used to request to log in to the cloud platform, where the second information includes a user identification of the client.
The cloud platform according to any one of claims 74-83, characterized in that the communication unit is also used to:

Receive second indication information sent by the configuration device, where the second indication information is used to configure the user type of the client.
The cloud platform of claim 84, wherein the user type of the client is configured by the user through the configuration device.
The cloud platform according to claim 84 or 85, characterized in that the user types include long-term users or temporary users.
The cloud platform according to any one of claims 74 to 86, characterized in that the user type of the client is a long-term user.
The cloud platform according to any one of claims 74-87, characterized in that the communication unit is also used for:

Receive third information sent by the first device, where the third information includes the access address of the client.
The cloud platform of claim 88, wherein the third information is carried in a registration request of the client requesting to register on the cloud platform, and/or the third information is carried in the The client requests a login request to log in to the cloud platform.
The cloud platform of claim 88 or 89, wherein the access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to use the AMTP protocol for communication.
The cloud platform according to any one of claims 88-90, characterized in that the communication unit is also used for:

In response to the third information, fourth information is sent to the first device, where the fourth information includes the access address of the second device to be accessed by the client.
The cloud platform of claim 91, wherein the fourth information is carried in a response command to a registration request of the client requesting to register on the cloud platform, and/or, the fourth information The information is carried in a response command to the login request of the client requesting to log in to the cloud platform.
A configuration device, characterized by including:

A sending unit, configured to send a first request to the first device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.
The configuration device according to claim 93, wherein the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client, and/or

The first request carries the cloud platform information of the client.
The configuration device according to claim 93 or 94, wherein the first device includes a functional cluster, and the functional cluster is used to indicate commands supported by the client; and/or

The function cluster is used to record the client corresponding to the long-term user in the first device.
The configuration device according to claim 95, wherein the functional cluster is used to indicate one or more of the following information of the client:

The client identifier of the client;

the user identification of the client; and

Instructions for the cloud platform.
The configuration device according to claim 95 or 96, characterized in that the function cluster includes one or more of the following commands:

the first request;

A second request used to instruct the client to add the cloud platform;

A response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully;

A third request for requesting the client's CSR;

A response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the client.
The configuration device according to claim 97, characterized in that, if the functional cluster includes the second request, the second request includes one or more of the following information: for the location of the client. The certificate information for identity verification of the cloud platform, the address information of the cloud platform and the access token information of the cloud platform.
The configuration device of claim 97, wherein if the function cluster includes the response command to the second request, the response command to the second request includes: indicating whether the cloud platform adds success message, and/or, the client's startup password.
The configuration device of claim 99, wherein if the response command to the second request includes the startup password of the client, the configuration device further includes:

A processing unit, configured to store the startup password of the client if the user type of the client is a long-term user.
The configuration device according to any one of claims 93-100, characterized in that the sending unit is also used to:

Send first indication information to the first device, where the first indication information is used to configure the user type of the client.
The configuration device according to claim 101, characterized in that the user type of the client is configured by the user through the configuration device.
The configuration device according to claim 101 or 102, characterized in that the user type includes a long-term user or a temporary user.
The configuration device according to any one of claims 93-103, wherein the user type of the client is a long-term user.
A first device, characterized in that it includes a transceiver, a memory and a processor, the memory is used to store programs, the processor is used to call the program in the memory, and control the transceiver to receive or send signals , so that the first device performs the method according to any one of claims 1-21.
A cloud platform, characterized in that it includes a transceiver, a memory and a processor, the memory is used to store programs, the processor is used to call the program in the memory, and control the transceiver to receive or send signals, To enable the cloud platform to execute the method as described in any one of claims 22-40.
A configuration device, characterized in that it includes a transceiver, a memory and a processor, the memory is used to store programs, the processor is used to call the program in the memory, and control the transceiver to receive or send signals, To cause the configuration device to perform the method according to any one of claims 41-52.
A device, characterized by comprising a processor for calling a program from a memory, so that the device executes the method according to any one of claims 1-52.
A chip, characterized in that it includes a processor for calling a program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1-52.
A computer-readable storage medium, characterized in that a program is stored thereon, and the program causes the computer to execute the method according to any one of claims 1-52.
A computer program product, characterized by comprising a program that causes a computer to execute the method according to any one of claims 1-52.
A computer program, characterized in that the computer program causes a computer to perform the method according to any one of claims 1-52.