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

Abstract

A method for starting a client, a first device, a configuration device, and a cloud platform are provided. The method includes: the first device receives a first request sent by a configuration device, the first request is used to request to start a client in the first device, and the client is used to communicate with the cloud platform. In an embodiment of the present application, a first request for starting a client is introduced to be compatible with the needs of two scenarios: long-term users or temporary users.

Description

Method for starting a client, first device, configuration device, and cloud platform Technical Field

[0001] 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 Art

[0002] Currently, because clients are typically temporary, or in other words, the user type of the client is always temporary, establishing a connection between the client and the cloud platform requires executing a complete connection plan. This means that the client configuration process, the client registration process, and the client login process must be executed. However, with the development of technology, the user type corresponding to the client has also expanded to include long-term users. For long-term users, if the connection between the client and the cloud platform needs to be re-established before each use of the client, the complex connection plan will reduce the user experience. Therefore, traditional connection solutions are not compatible with both temporary and long-term user scenarios.

[0003] Summary of the Invention

[0004] The present application provides a method for starting a client, a first device, a configuration device, and a cloud platform. The following introduces various aspects of the present application.

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

[0006] In a second aspect, a method for starting a client is provided, comprising: a cloud platform communicating with a client configured in a first device, the client of the first device being started based on a first request, and the first request being used to request starting the client.

[0007] According to a third aspect, a method for starting a client is provided, comprising: configuring a device to send a first request to a first device, wherein the first request is used to request starting a client in the first device, and the client is used to communicate with the cloud platform.

[0008] In a fourth aspect, a first device is provided, comprising: a receiving unit for receiving a first request sent by a configuration device, wherein the first request is used to request to start a client in the first device, and the client is used to communicate with the cloud platform.

[0009] In a fifth aspect, a cloud platform is provided, comprising: a communication unit for communicating with a client configured in a first device, wherein 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.

[0010] In a sixth aspect, a configuration device is provided, comprising: a sending unit for sending a first request to a first device, wherein the first request is used to request to start a client in the first device, and the client is used to communicate with the cloud platform.

[0011] In the seventh aspect, a first device is provided, comprising a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the first device executes part or all of the steps in the method of the first aspect.

[0012] In the eighth aspect, a cloud platform is provided, comprising a processor, a memory, and a transceiver, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the cloud platform executes part or all of the steps in the method of the second aspect.

[0013] In the ninth aspect, a configuration device is provided, comprising a processor, a memory, and a transceiver, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the configuration device performs some or all of the steps in the method of the third aspect.

[0014] In a tenth aspect, an embodiment of the present application provides 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 the terminal device or network device in the solution provided in the embodiment of the present application.

[0015] In the eleventh aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program enables a communication device (for example, a first device, a configuration device, and a cloud platform) to perform some or all of the steps in the methods of the above aspects.

[0016] 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, wherein the computer program is operable to cause a communication device (e.g., a first device, a configuration device, and a cloud platform) to perform some or all of the steps of the methods described above. In some implementations, the computer program product may be a software installation package.

[0017] In the thirteenth aspect, an embodiment of the present application provides 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.

[0018] In an embodiment of the present application, a request for starting a client (also referred to as a "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 already configured 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 solution, the client configuration process does not need to be repeatedly executed, which helps to simplify the connection solution and improve the user experience. For temporary users, after completing the configuration of the client corresponding to the temporary user, the configuration device can also request to start the client corresponding to the temporary user by sending a first request to the first device. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG1 is a schematic diagram of a system architecture applicable to an embodiment of the present application.

[0020] FIG2 is a model structure of a Matter device applicable to an embodiment of the present application.

[0021] FIG3 is a flow chart of the connection between the client and the cloud platform.

[0022] FIG4 is a flowchart for starting a client according to an embodiment of the present application.

[0023] FIG5(a) to FIG5(c) are schematic flow charts of a method for starting a client according to an embodiment of the present application.

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

[0025] FIG7 is a schematic diagram of a first device according to an embodiment of the present application.

[0026] FIG8 is a schematic diagram of a cloud platform according to an embodiment of the present application.

[0027] FIG9 is a schematic diagram of a configuration device according to an embodiment of the present application.

[0028] FIG10 is a schematic structural diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] The technical solution of the present application will be described below with reference to the accompanying drawings. For ease of understanding, the following first introduces the system architecture applicable to the embodiment of the present application with reference to FIG1 .

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

[0031] 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, which may be used to communicate with the cloud platform 130 and, through the cloud platform 130, communicate with the second device 140. For example, a user may access the cloud platform 130 through the client and access the second device 140 through the cloud platform 130. For another example, a user may access the cloud platform 130 through the client and control the second device 140 through the cloud platform 130.

[0032] In some embodiments, the client may be an application (APP) or a mini-program.

[0033] The second device 140 may be a device capable of communicating with the cloud platform 130. In some implementations, the second device 140 may provide service functions for the user, and therefore, the second device 140 may also be referred to as a server or a service device.

[0034] The configuration device 120 is configured 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 may configure a client in the first device 110 so that the client can communicate with the cloud platform 130.

[0035] In some implementations, the configuration device 120 may be an application (APP) or a mini-program, etc. In other implementations, the configuration device 120 may be installed on a terminal device, wherein the terminal device may be a mobile phone, a tablet computer (Pad), a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. The embodiments of the present application are not limited to this.

[0036] The cloud platform 130, also known as a cloud computing platform or "cloud," can be understood as providing network communication capabilities for services based on hardware and software resources. Therefore, in the 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.

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

[0038] It should be noted that the cloud platform 130 may also be other systems or devices that can provide network functions, such as a cluster system that can provide network functions, etc. This embodiment of the present application does not limit this.

[0039] In addition, the configuration device 120 may be an APP or mini-program that matches the client. Of course, the configuration device 230 may be an APP or mini-program that is different from the client. This embodiment of the present application does not limit this.

[0040] In some scenarios, the system 100 may be, for example, an Internet of Things (IoT) system. The IoT, which stands for "the Internet of Everything," can be understood as a network that extends and expands upon the Internet. Various information sensing devices (such as radio frequency identification and global positioning systems) can be used to connect any object to the Internet, forming a massive network for information exchange and communication, thereby enabling interconnection and interoperability between all things.

[0041] Accordingly, in some embodiments, the first device and / or the second device may be an IoT device. IoT devices may include in-vehicle terminals, smart home devices, smart monitoring devices, and the like. Smart home devices may include, for example, smart air conditioners, smart refrigerators, washing machines, rice cookers, and robot vacuums. Smart monitoring devices may include, for example, surveillance cameras, temperature sensors, and sound sensors.

[0042] In other embodiments, the 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 an IoT system.

[0043] For ease of understanding, the system 100 is introduced using IoT devices 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 Figure 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 / or control the smart home devices on the cloud platform (or the 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."

[0044] For example, assuming the second device is a smart air conditioner, and the smart air conditioner is located on a cloud platform, the client can control the smart air conditioner's power on and off, and set the temperature, wind speed, etc. through the cloud platform. If the second device is a robot vacuum, the client can control the robot vacuum to start or stop, control its operating mode, etc. through the cloud platform.

[0045] At present, different manufacturers may use different communication protocols (also known as ecological chain protocols) to achieve interoperability between IoT devices that support the communication protocols. This may result in the inability of IoT devices produced by different manufacturers to communicate with each other, and the failure to achieve true interconnection of all things.

[0046] Based on this, the Connectivity Standards Alliance (CSA) has launched an IoT application layer technology standard - the Matter standard protocol, which can provide an interoperable application layer solution for smart home devices based on the Internet Protocol (IP). In some embodiments, the Matter standard can also be called the 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 enable IoT devices with different protocols to communicate with each other.

[0047] Accordingly, if the client described above supports the Matter protocol, it can be called a "Matter client." If the second device described above supports the Matter protocol, it can be called a "Matter server." The first device and / or second device that supports the Matter protocol can also be called a "Matter device."

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

[0049] Model of the Matter device

[0050] FIG2 is a model structure of a Matter device applicable to an embodiment of the present application. The data model structure 200 of the Matter device includes a node 210 , an endpoint 220 , and a cluster 230 .

[0051] A node 210 encapsulates a unique, addressable resource on the network, possessing a set of functions and capabilities that users can clearly perceive as a functional entity. Typically, a node 210 can be the highest or outermost first-order element in a data model. In other words, a node 210 is the only addressable element at the outermost level of a data model.

[0052] It should be noted that a physical entity (e.g., a 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 the node ID is used as the target address of an interaction, the network that specifies the node ID scope is the access network for the interaction. A node can include one or more endpoints 220. An endpoint 220 is an instance, which can be a service or a virtual device, indicated by the device type. Each endpoint 220 conforms to one or more device type definitions, which define the clusters supported on the endpoint. A cluster is an object class instantiated on an endpoint.

[0053] It should be noted that in this architecture model, the device type can be the highest semantic element. The device type defines the consistency of a set of endpoints 220. The device type defines a set of requirements for a node 210 or an endpoint 220.

[0054] Clusters 230 are functional building blocks of the data model. Clusters can also be referred to as "functional sets," "functional clusters," or "functional clusters." A cluster specification defines the clients and servers that interact with each other. Clusters 230 can be considered interfaces, services, or object classes, representing the lowest level of independent functional elements in the data model. Each cluster 230 is defined by a cluster specification, which defines its elements, including properties, events, commands, and behaviors associated with interactions with those elements. Whether the properties, events, commands, and behaviors in a cluster 230 are mandatory or optional depends on the definition of the cluster 230.

[0055] Generally, the above clusters can be categorized as either utility clusters or application clusters. A utility cluster is not part of the primary application operations of an endpoint. 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 embodiments of the present application, a utility cluster may include a client cluster.

[0056] An application cluster (also known as a "business cluster") supports the primary operations of an endpoint. It supports one or more persistent application interactions between the cluster's clients and the cluster's servers. For example, consider a smart light switch cluster (on / off cluster). The cluster's clients can send control commands to the cluster's servers (i.e., the switch cluster) to turn the smart light on or off.

[0057] A cluster command (also known as a "command") is a set of data fields, each of which is passed between client and server cluster instances to invoke behavior on the command recipient. Currently, the protocol stipulates that each command can be listed in a table, which can contain columns for the command's data quality: identification (ID), name (name), direction (direction), response (response), access (access), constraint (constraint), and conformance (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.

[0058] Attributes can be understood as cluster data. Currently, the protocol stipulates that each attribute can be listed in a table, including a data quality column. The data quality column can include ID, name, (data) type, constraints, other qualities, access, default (value), and consistency. In some implementations, attributes can also define their related semantics and behaviors. Attributes can reflect the queryable / settable state, configuration, and capabilities of the device. In some cases, if no privileges are explicitly defined for an attribute, the default access privilege takes effect.

[0059] For ease of understanding, the following describes the meanings of several common data qualities included in commands and attributes. It should be noted that the commands and attributes in the embodiments of this application may also include other quantitative qualities, or include parts of the above-mentioned data qualities. This embodiment of the application does not limit this.

[0060] Identifier, which indicates the unique field ID of the field, or the unique identifier of the command.

[0061] Name: The unique name of the field, or the name of the command.

[0062] Type indicates the data type of a field, a command parameter, or an attribute parameter. In some implementations, the data type can be an octet string, represented as "octstr or octstring"; a string; an unsigned X-bit integer (uintX), where X can be 8, 16, 24, 32, 40, 48, 56, or 64; a number; or a Boolean value represented as "bool."

[0063] 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 the client to the server. Another example is from the server to the client.

[0064] Access permissions define how an element can be accessed (e.g. read or write) and what permissions are required to access the data.

[0065] In some implementations, the access permission may include V, indicating that read access or call access requires the view privilege. The access permission may also include O, indicating that "read access," "write access," or "call access" requires the operation privilege. The access permission may also include R, indicating read access. The access permission may also include W, indicating write access.

[0066] Response, usually exists in the command list, and is used to define the response command of the command.

[0067] Quality, used to define additional data qualities not covered in other columns.

[0068] Default is used to define a default value. It should be noted that the default value is not the value used when the service device returns to factory refresh settings. Default values ​​can indicate that the consistency specified for a data field is optional and can change over time. Default values ​​can be defined to fulfill dependencies when the actual data field value does not exist.

[0069] Conformance, which defines the optionality and dependencies of any data model element or set of elements.

[0070] 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 property set.

[0071] For commands, client-to-server command conformance means that the server should recognize and support client-to-server commands and generate responses as defined. Server-to-client command conformance means that the server should send commands as defined by cluster behavior, i.e., respond to client-to-server commands. Command conformance depends on supported server features. Clients should not be required to support optional commands or commands that depend on optional features.

[0072] Constraints. In some cases, constraints may contain all and desc. Among them, all is used to define that all values ​​are allowed in the numeric data type. Desc is used to indicate that the constraint is defined in the description part. In other cases, the constraint can also indicate the maximum value of the corresponding parameter value, expressed as "max N". For example, in an embodiment of the present 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 an embodiment of the present 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 the parameter. 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.

[0073] Range: indicates the value range of the field.

[0074] In some implementations, ranges can support two forms: explicit constraints and width constraints. Explicit constraints can indicate the minimum and maximum values ​​corresponding to a field's values. For example, an explicit constraint indicates that a field's value range is (0, 128).

[0075] The width constraint can be used to constrain the number of bytes that a field's value occupies, 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 that a field's value occupies is 8 bytes.

[0076] It should be noted that when the range value includes "N / A", it indicates that it is not applicable. In addition, in the embodiment of the present application, "N / A" can also appear in other parts (other data qualities), such as default, constraint, etc.

[0077] In addition, the meaning of data quality in the commands or attributes introduced above can be applied to the solutions of the embodiments of the present application. For the sake of brevity, when introducing the data quality of commands or attributes with the same meaning below, please refer to the above introduction and no further details will be given.

[0078] Connection solution between client and cloud platform

[0079] Currently, if a client wishes to communicate with a second device via a cloud platform, the client must establish a connection with the cloud platform based on a client-platform connection solution. This connection solution includes client configuration, client registration, and client login. The following describes the client configuration, registration, and login processes in conjunction with steps S311 to S327 in FIG. 3 .

[0080] In step S311 , the configuration device determines that the first device has the capability of supporting the client.

[0081] Typically, after the first device establishes a connection with the configuration device, the configuration device may query the capabilities of the first device to determine whether the first device supports the configuration client. Of course, the first device may also directly report the capabilities of the first device so that the configuration device can determine whether the first device supports the configuration client.

[0082] In step S312, the configuration device pops up a dialogue interface, prompting the user to select whether to agree to use the first device to control the second device.

[0083] 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.

[0084] (certificate signing request, CSR) request command.

[0085] In step S314, the client generates a key pair and stores the private key in the key pair in the secure area.

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

[0087] The format of the CSR may conform to the CSR data format defined in Public Key Cryptography Standards (PKCS) #10. Accordingly, the CSR may adhere to the following principles: The CSR carries certificate request information, which may include version information, subject information, public key information, and the like. The subject information may include the vendor ID of the first device, the product ID of the first device, and the like. The public key information may indicate the public key in the key pair (see step S340).

[0088] It should be noted that the supplier identifier of the first device and the product identifier of the first device can be obtained from the data recorded in the basic information cluster (general_Info cluster) of the first device.

[0089] In addition, the CSR may be digitally signed, and the digital signature of the CSR may be generated based on the private key in the key pair.

[0090] In step S316, the configuration device sends information 1 to the cloud platform, wherein information 1 is used to apply for cloud connection credentials, namely, an access token, for the client, and information 1 carries a CSR.

[0091] In step S317, after the CSR verification is passed, the cloud platform can assign a client identifier to the client.

[0092] In step S318, the cloud platform generates a certificate for the client based on the client identifier and public key corresponding to the client.

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

[0094] In step S320, the cloud platform encrypts the access token using the client's public key to obtain an encrypted access token.

[0095] “CToken” means.

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

[0097] The parameters included 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 information 2, the value type of the parameter, whether the parameter is necessary, and the description of the parameter.

[0098] Table 1

[0099]

[0100] 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.

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

[0102] Table 2

[0103]

[0104]

[0105] In step S323, the first device decrypts the information 3 using the private key to obtain the above parameters in the information 3 and configures the client based on the above parameters.

[0106] In step S324 , the client connects to the cloud platform based on the cloud address and establishes a secure connection with the cloud platform using the client certificate.

[0107] In step S325, the client sends a registration request (also called a "cloud registration request" or "client registration request") to the cloud platform. The registration request may carry a client ID and an access token.

[0108] Table 3 shows an interface description of a registration request. Referring to Table 3, a hypertext transfer protocol (HTTP) method based on the registration request may be a POST method, and an interface access address of the registration request may be an account.

[0109] Table 3

[0110] HTTP method interface access address POST / account

[0111] Table 4 shows the interface parameters of the registration request. Table 4 indicates the position of the parameters in the registration request, the name of the parameter, the value type of the parameter, whether the parameter is necessary, and the description of the parameter.

[0112] Table 4

[0113] Position Parameter Value Type Necessity Description Subject (body) Access Token string is the client's access token body Client ID string is the client ID assigned to the client by the cloud platform.

[0114] In step S326, the cloud platform sends a registration response command (also called a "cloud registration response") to the configuration device. In some implementations, the registration response command carries the updated access token sent by the cloud platform. Of course, the cloud platform may not update the client's access token.

[0115] Table 5 shows information such as 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.

[0116] Table 5

[0117]

[0118] 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.

[0119] 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.

[0120] Currently, because clients are typically temporary, or in other words, the user type of the client is always temporary, establishing a connection between the client and the cloud platform requires executing the complete solution shown in Figure 3. This means that the client configuration process, the client registration process, and the client login process must be executed. However, with the development of technology, the user type corresponding to the client also includes long-term users. For long-term users, if the connection between the client and the cloud platform needs to be re-established before each use of the client, the complex connection solution will reduce the user experience. Therefore, traditional connection solutions are not suitable for long-term user scenarios.

[0121] The embodiment of the present application provides a solution for starting a client, and introduces a request for starting a client (also called a "first request") to be compatible with the needs of both long-term users and temporary users. For long-term users, if the first device has already configured 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 solution, the client configuration process does not need to be repeatedly executed, which helps to simplify the connection solution and improve the user experience. For temporary users, after completing the configuration of the client corresponding to the temporary user, the configuration device can also request to start the client corresponding to the temporary user by sending a first request to the first device.

[0122] The following describes a method for starting a client according to an embodiment of the present application in conjunction with Figure 4. Figure 4 is a flow chart of a method for starting a client according to an embodiment of the present application. The method shown in Figure 4 includes step S410.

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

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

[0125] The user type of the client can be a long-term user, or in other words, the client can be a long-term client. For example, if the first device is a vehicle, the user corresponding to the client can be the vehicle owner. Of course, the user type of the client can also be a temporary user, or in other words, the client can be a temporary client. For example, if the first device is a vehicle, the user corresponding to the client can be a temporary passenger in the vehicle.

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

[0127] In some implementations, the first request may carry indication information of the client to be started to indicate the client to be started, wherein the indication information may be, for example, a client identifier.

[0128] To improve client startup security, you can use a startup password to start the client. The startup password is used to verify whether the client is started. Alternatively, the startup password is used to authenticate the user who starts the client. Alternatively, the startup password is used to authenticate the configuration device. If the startup password is used to authenticate the configuration device, it can also be called the mediator password (MedPassword).

[0129] In some implementations, the first request may carry a client startup password. Accordingly, if the startup password carried in the first request matches the client startup password pre-stored on the first device, the client may be started. Conversely, if the startup password carried in the first request does not match the client startup password pre-stored on the first device, the client may be refused startup.

[0130] It should be noted that the above match can be understood as the startup password carried in the first request being the same as the pre-stored startup password of the client, or the startup password carried in the first request being different from the pre-stored startup password of the client but satisfying a preset correspondence. This embodiment of the application is not limited to this.

[0131] In some implementations, the client may inform the configuration device of the client's startup password so that when the configuration device starts the client through the first request, the startup password can be included in the first request. The client may include the startup password by adding a cloud response command (also known as a "response command to the second request").

[0132] Table 6 shows the parameters carried in the add cloud response command of an embodiment of the present application. Referring to Table 6, the add cloud response command may include: a status code and a startup password, wherein the status code is used to indicate whether the client has successfully added the cloud platform.

[0133] Table 6

[0134] ID Field Data Type Constraint Quality Default Value Necessity 0 Status Code octstr M1 Startup Password octstr32 M

[0135] In some scenarios, the first device may be configured with clients that communicate with different cloud platforms, and these clients may have the same client identifier. In this case, the first request may carry information indicating the cloud platform corresponding to the client to be started, so that the first device can identify the client to be started. Of course, if different clients in the first device have unique identifiers (e.g., client IDs), the first request may only carry the unique identifier corresponding to the client to be started, and no longer carry information indicating the cloud platform.

[0136] The cloud platform indication information may be any information used to identify the cloud platform, and the embodiments of the present application are not limited thereto. For example, the cloud platform indication information may be the cloud platform identifier (cloud ID). For another example, the cloud platform indication information may be the cloud platform address.

[0137] For ease of understanding, the following describes possible implementations of the first request in conjunction with Table 7. As shown in 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. Table 7 also shows the parameter data type, parameter identifier, parameter constraints, parameter quality, parameter default value, and parameter necessity.

[0138] Table 7

[0139] ID Field Data Type Constraint Quality Default Value Necessity 0 Client ID octstrmax99 M1 Startup Password octstr32 M

[0140] 2 Cloud address string M

[0141] Accordingly, after receiving the first request, the first device can determine the client to be activated based on the client identifier in the first request. Then, based on the pre-stored correspondence between the client identifier and the activation password, determine whether the pre-stored activation password of the client to be activated matches the activation password in the first request. Furthermore, based on the pre-stored correspondence between clients and cloud addresses, determine whether the pre-stored cloud address of the client to be activated matches the cloud address in the first request.

[0142] 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 configuration device in response to the first request, indicating that the client startup was successful. Conversely, if at least one of the startup password and the cloud address does not match, the first device can refuse to start the client to be started and send a response command to the configuration device in response to the first request, indicating that the client startup failed.

[0143] In some implementations, the client information described above, such as the client identifier and cloud platform indication information, can be maintained as attributes of a functional cluster. In other words, the first device can include a functional cluster (also known as a "client functional cluster") that is used to record the clients on the first device. Typically, the first device can record the client information of long-term users in the functional cluster, but the first device may not record the client information of temporary users in the functional cluster.

[0144] For ease of understanding, the following describes possible implementations of a functional cluster in conjunction with Table 8. Referring to Table 8, a functional cluster may include the following attributes: a long-term user list (or a long-term client list), the constraint of which may be "all", the quality of which may be "N", the permission of which may be "R", the default value of which may be "empty", the necessity of which may be "M", the data type of which may be a list, and the list may contain a client structure (represented as "ClientStruct").

[0145] Table 8

[0146] ID Name Data Type Constraint Quality Permission Default Value Necessity 0 Long-term User List List [Client Structure] allNR Empty M

[0147] The client information recorded in the client structure can be as shown in Table 9, including the client identifier, user identifier, and cloud address. In addition, Table 9 also shows the parameter data type, parameter identifier, parameter constraint, parameter quality, parameter authority, parameter default value, and parameter necessity.

[0148] Table 9

[0149] ID Name Data Type Constraint Quality Permission Default Value Necessity 0 Client ID octstringmax99 R M1 User ID octstringmax99 R M2 Cloud Address string RM

[0150] 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 a suitable client is configured in the first device, the configuration device may request the first device to start the client by sending the first request.

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

[0152] As described above, the client information in the first device can be maintained by a functional cluster. Accordingly, the commands supported by the client (e.g., commands for configuring the client and / or commands for starting the client) can also be maintained by the same functional cluster. In other words, the functional cluster also includes the commands supported by the client.

[0153] In some implementations, the above-mentioned functional cluster includes one or more of the following commands: a first request; a response command to the first request; a second request for instructing the client to add the cloud platform; a response command to the second request, wherein the response command to 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 client authentication from the cloud platform.

[0154] The above-mentioned second request is also called an add cloud request. In some implementations, the second request includes one or more of the following information: certificate information for the client to authenticate itself on the cloud platform, instruction information of the cloud platform, and access token information of the cloud platform.

[0155] Accordingly, the response command to the second request may also be referred to as an “add cloud response command.” In some implementations, the response command to the second request includes: information indicating whether the cloud platform has been successfully added, and / or a startup password of the client.

[0156] The above-mentioned third request can also be called a CSR request command, and accordingly, the third response command to the third request command can be called a "CSR response command".

[0157] For ease of understanding, the following describes the commands supported by the functional cluster in the embodiment of this application in conjunction with Table 10. Referring to Table 10, the commands included in the functional cluster include CSR request commands, CSR response commands, add cloud request commands, add cloud response commands, and start client request commands. In addition, Table 10 also shows the corresponding identifier for each command, the command direction, the command response, the command authority, and the necessity of the command.

[0158] Table 10

[0159]

[0160] In the embodiment of the present application, the information of the client and the commands supported by the client can also be maintained by multiple different functional clusters, which is not limited by the embodiment of the present application. In addition, the parameters included in each of the above commands will be specifically introduced below and will not be repeated here for the sake of brevity.

[0161] 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.

[0162] If the configuration device determines that the client is not configured in the first device, the client configuration process can be triggered. In some implementations, the configuration device can read a long-term user list in the first device, and if the long-term user list does not record a suitable client, the client configuration process can be triggered.

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

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

[0165] The above-mentioned first indication information can be carried in a CSR request command (also known as the third request). The following introduces the parameters of the CSR request command of the embodiment of the present application in conjunction with Table 11. Referring to Table 11, the CSR request can carry the parameter long-term user (i.e., 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 the 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 (false), it is used to indicate that the user type of the client is a temporary user.

[0166] Table 11

[0167] ID Field Data Type Constraint Quality Default Value Necessity 0 Long User bool FalseM

[0168] It should be noted that the above-mentioned first indication information can also be carried in other commands besides the CSR request command, or the first indication information can also be carried in a dedicated command, which is not limited in the embodiment of the present application.

[0169] In some implementations, after receiving the CSR request command, the first device may send a CSR response command (also known as a "response command to 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 an embodiment of the present application. Referring to Table 12, the CSR request may carry the parameter CSR. In addition, Table 12 also shows the identifier corresponding to the parameter, the data type of the parameter, the constraint of the parameter, the quality of the parameter, the default value of the parameter, and the necessity of the parameter.

[0170] Table 12

[0171] ID Field Data Type Constraint Quality Default Value Necessity 0CSRoctstrmax 900 M

[0172] The cloud platform may perform slightly different operations for clients that are long-term users or clients that are temporary users. Therefore, during the configuration process, the configuration device can inform the cloud platform of the client's user type. In some implementations, the configuration device can send a second indication message to the cloud platform to indicate the client's user type. The second indication message can indicate that the client's user type is a long-term user, or the second indication message can indicate that the client's user type is a temporary user. Alternatively, the second indication message can indicate whether the client's user type is a long-term user. Alternatively, the second indication message can indicate whether the client's user type is a temporary user.

[0173] The above-mentioned second indication information can be carried in the client application request (also called "application request"), wherein 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 of the embodiment of the present application in conjunction with Table 13 and Table 14. Referring to Table 13, the HTTP method used by the client application interface is POST, and the interface access address is " / addclient".

[0174] Table 13

[0175] HTTP Method interface access address POST / addclient

[0176] Table 14 shows the parameters carried in the client application request command. The application request command may include accept, internet media type (content-type), access token, CSR, and long-term user. Table 14 also shows the parameter's location, value type, necessity, and description.

[0177] Table 14

[0178]

[0179] In some implementations, the user type of the client can be configured by the user through a configuration device. In other words, the user can select the user type of the client as a long-term user or a temporary user through the configuration device. Of course, in the embodiments of the present application, other methods can also be used to help the configuration device determine the user type of the client, and the embodiments of the present application are not limited to this.

[0180] In an embodiment of the present application, the cloud platform may send the client's certificate to the configuration device via a client application response command in response to the client application request. In some implementations, the above-mentioned certificate may be indicated by the parameter "CertChain" in the client application response command. In other implementations, the above-mentioned 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").

[0181] Typically, clients access cloud platforms using access tokens. In some scenarios, clients may need to access the cloud platform multiple times. If the client uses the same access token each time, this may compromise the cloud platform's security. For example, a long-term user may access the cloud platform multiple times through the client. If the access token remains unchanged, it could be intercepted by attackers, threatening the cloud platform's security.

[0182] Therefore, in an embodiment of the present application, the cloud platform can configure a first token (also known as a "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. This access token update mechanism helps improve the security of the cloud platform compared to always using the same access token to access the cloud platform.

[0183] In some implementations, when the original access token of the first device expires, the first device may apply to the cloud platform for an updated access token based on the first token. Of course, the embodiment of the present application does not specifically limit the timing of applying for an updated token. For example, the first device may also apply to the cloud platform for an updated 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 an updated access token based on the first token at a target time, wherein the target time and the expiration time of the original access token are less than a first time interval. For another example, the first device may periodically apply to the cloud platform for an updated access token, wherein the update period of the access token may be less than or equal to the valid time period of the access token.

[0184] In some implementations, the first token may be included in a registration response command. Table 15 illustrates the interface parameters for a registration response command according to an embodiment of the present application. Referring to Table 15, the registration response command may include an access token, token expiration, user identifier, and the first token. The position of the parameters in the command, the corresponding value types, the necessity of the parameters, and the description of the parameters are described in Table 15.

[0185] Table 15

[0186]

[0187]

[0188] In some implementations, the first device can log in to the cloud platform based on the user identifier, that is, the first device sends a second message to the cloud platform. The second message is used to request to log in to the cloud platform. Therefore, the second message can be referred to as a "login request." The second message can include the user identifier of the client.

[0189] The following is a description of the login interface and the parameters included in the login request according to an embodiment of the present application, 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 represented as " / session".

[0190] Table 16

[0191] HTTP method interface access address POST / session

[0192] As shown in Table 17, the login request command may include "accept", "content-type", "access token", "user ID", "client ID", and "login status". 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.

[0193] Table 17

[0194]

[0195] In some scenarios, the client and the second device can communicate using the AMTP protocol. In this case, the client needs to send its access address to the cloud platform so that subsequent communication can proceed based on the client's access address. Specifically, the method further includes: the first device sending third information to the cloud platform, the third information including the client's access address. The access address is an AMTP-based access address.

[0196] 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, the third information is also used to indicate that the communication protocol supported by the client is the AMTP protocol.

[0197] In some implementations, the third information may be carried in a registration request, wherein the registration request is used by the client to request registration on the cloud platform. The following describes the parameters carried in the registration request of an embodiment of the present application 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 (e.g., a 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.

[0198] Table 18

[0199]

[0200] It should be noted that the interface description of the registration request can be found in Table 3, which will not be repeated here for the sake of brevity.

[0201] In other implementations, the third information may be carried in a login request, which is used by the client to request to log in to the cloud platform. The following describes the parameters carried in the login request command of an embodiment of the present application in conjunction with Table 19. The parameters in Table 19 are compared to the parameters shown in Table 17, with the addition of a client access address (e.g., ClientURL).

[0202] Table 19

[0203]

[0204]

[0205] It should be noted that the interface description of the login request can be found in Table 16, which will not be repeated here for the sake of brevity.

[0206] Accordingly, 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, i.e., the access address of the second device based on the AMTP protocol (also known as the "access URL"). In other words, the above method further includes: in response to the third information, the first device receives fourth information sent by the cloud platform, the fourth information including the access address of the second device to be accessed by the client.

[0207] Accordingly, when the client successfully logs into 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.

[0208] In some implementations, the fourth information may be carried in a response command to a registration request, i.e., a registration response command. Table 20 shows the parameters included in the registration response command of an embodiment of the present application. As shown in Table 20, the registration response command includes an access token, a user identifier, 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.

[0209] Table 20

[0210]

[0211] It should be noted that the interface description of the registration request can be found in Table 3, which will not be repeated here for the sake of brevity.

[0212] In other implementations, the fourth information may be carried in a response command to a login request, i.e., a login response command. Table 21 shows the parameters contained in the login response command of an embodiment of the present application. As shown in Table 21, the login response command includes an access token, a client identifier, and a URL of the client, wherein 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.

[0213] Table 21

[0214]

[0215] It should be noted that the interface description of the login request can be found in Table 16, which will not be repeated here for the sake of brevity.

[0216] In an embodiment of the present application, the transmission method of the third information and the transmission method of the fourth information described above can be used separately or in combination. For example, the third information can be carried in a login request, and accordingly, the fourth information can be carried in a login response command. For another example, the third information can be carried in a registration request, and accordingly, the fourth information can be carried in a registration response command. For another example, the third information can be carried in a registration request, and accordingly, the fourth information can be carried in a login response command. For another example, the third information can be carried in a registration response, and accordingly, the fourth information can be carried in a login request.

[0217] 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 described above, in one implementation, the client may first send the access address of the client to the cloud platform, and then the cloud platform may send the access address of the second device to the client. In another implementation, 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 may send the access address of the client to the cloud platform through a login request.

[0218] For ease of understanding, the following describes the solution of the embodiment of the present application using the IoT scenario as an example in conjunction with Figures 5 and 6. In this case, the 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 Figures 5 and 6 have the same meaning as those described above and use the same names. For the sake of brevity, please refer to the above introduction and will not be repeated below.

[0219] Figures 5(a) to 5(c) are schematic flow charts 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.

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

[0221] For example, a mobile phone can establish a connection with the vehicle terminal via Bluetooth low energy (BLE) combined with wireless network communication technology Wifi.

[0222] In step S512, the mobile phone checks the client cluster of the vehicle terminal.

[0223] The client cluster can be found in the above description in conjunction with Table 9 and Table 10, and will not be described here for brevity.

[0224] In step S513, the user confirms through the mobile phone that the vehicle terminal is used as the IoT client to access the smart home device.

[0225] It should be noted that step S513 may be placed before step S512, or the two steps may be performed simultaneously, or step S512 may be placed before step S513, and this embodiment of the present application does not limit this.

[0226] 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.

[0227] If the long-term user list contains a client on the same cloud platform as the mobile phone, and the client's user ID is consistent with the mobile phone's user ID, then step S515 is executed. If the long-term user list contains a client on a different cloud platform than the mobile phone, or the client's user ID is inconsistent with the mobile phone's user ID, then step S516 is executed.

[0228] In step S515 , the mobile phone sends a client startup request command to the vehicle-mounted terminal to request startup of the client.

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

[0230] The above-mentioned long-term mode corresponds to creating a client with the user type of long-term users, while the temporary mode can be used to create a client with the user type of temporary users. The following example uses the client that the user chooses to create a long-term user as an example, but the following solution can also be applied to creating temporary users.

[0231] In step S517, the mobile phone sends a CSR request command to the IoT client, wherein the CSR request command may carry the user type of the client.

[0232] In addition, the CSR request command can refer to the introduction shown in Table 11 above.

[0233] In step S518, the IoT client generates a key pair and sends a CSR response command to the mobile phone. The CSR response command can be found in the introduction of Table 12 above.

[0234] 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. The client application request carries the user type of the client.

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

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

[0237] 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 an embodiment of this application, as well as the parameter value type, parameter location, parameter necessity, and parameter description.

[0238] Table 22

[0239]

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

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

[0242] Table 23

[0243] ID Field Data Type Constraint Quality Default Value Necessity 0IOT Client Certificate octstringmax400 M

[0244] 1 Intermediate certificate octstringmax400 O2 Root certificate octstringmax400 M3 Cloud address string M4 CToken octstring M5 Token expiration information uint16 M

[0245] In step S522, the IoT client uses the private key in the key pair to decrypt Ctoken to obtain an access token.

[0246] In step S523, the IoT client sends an add cloud response command to the mobile phone, wherein the add cloud response command includes the client's startup password.

[0247] Typically, 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, the Add Cloud Response command can be referred to in conjunction with Table 6 above.

[0248] In step S524, the mobile phone sends a client startup request command to the vehicle terminal to request the startup of the IoT client. The client startup request command can be referred to the introduction shown in Table 7 above.

[0249] It should be noted that the above steps S515 and S524 can be understood as two scenarios for sending a client startup request command. Specifically, step S515 can be understood as when a suitable client is configured on the first device, and the configuration device can directly start the client through step S515. Step S524 can be understood as when a suitable client is not configured on the first device, and the configuration device can start the client through step S524 after reconfiguring the client.

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

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

[0252] In step S526 , the vehicle-mounted terminal starts the IoT client and indicates to the mobile phone that the IoT client has been successfully started.

[0253] In step S527 , the vehicle-mounted terminal indicates to the mobile phone that the IoT client startup has failed.

[0254] In some implementations, the vehicle terminal may indicate to the mobile phone the reason why the IoT client failed to start, for example, the startup password of the IoT client is incorrect, the client ID of the IoT client does not exist, etc.

[0255] It should be noted that during the above-mentioned client configuration process, the cloud platform can generate CToken and establish a binding relationship according to the method shown in steps S317 to S320. For the sake of brevity, please refer to the above introduction.

[0256] The client configuration and startup processes are described above in conjunction with steps S511 to S527. If the IoT client is successfully started, the client registration process is described below in conjunction with Figure 5(b). The method shown in Figure 5(b) includes steps S531 to S533.

[0257] 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.

[0258] 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.

[0259] In some implementations, the client registration request may include a client ID and an access token. The client registration request may refer to the description above in conjunction with Table 3.

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

[0261] In some scenarios, the client registration response command can carry the new access token, user ID, and first token assigned by the IoT cloud platform to the IoT client. The client registration response command can be found in the description of Table 5 above.

[0262] The following describes the client login process in the embodiment of the present application in conjunction with Figure 5(c). The method shown in Figure 5(c) includes steps S541 to S542.

[0263] 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.

[0264] In some implementations, the login request includes a user ID, a client ID, and an access token. See the description above in conjunction with Table 17.

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

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

[0267] Table 24

[0268]

[0269] Figures 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 a client communicating with a smart home device using the AMTP protocol.

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

[0271] In step S612, the mobile phone checks the client cluster of the vehicle terminal.

[0272] The client cluster can be found in the above description in conjunction with Table 9 and Table 10, and will not be described here for brevity.

[0273] In step S613, the user confirms through the mobile phone that the vehicle terminal is used as the IoT client to access the smart home device.

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

[0275] 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.

[0276] If the long-term user list contains a client on the same cloud platform as the mobile phone, and the client's user ID is consistent with the mobile phone's user ID, then step S615 is executed. If the long-term user list contains a client on a different cloud platform than the mobile phone, or the client's user ID is inconsistent with the mobile phone's user ID, then step S616 is executed.

[0277] In step S615 , the mobile phone sends a client startup request command to the vehicle-mounted terminal to request startup of the client.

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

[0279] The above-mentioned long-term mode corresponds to creating a client with the user type of long-term users, while the temporary mode can be used to create a client with the user type of temporary users. The following example uses the client that the user chooses to create a long-term user as an example, but the following solution can also be applied to creating temporary users.

[0280] In step S617, the mobile phone sends a CSR request command to the IoT client, wherein the CSR request command may carry the user type of the client.

[0281] In addition, the CSR request command can refer to the introduction shown in Table 11 above.

[0282] In step S618, the IoT client generates a key pair and sends a CSR response command to the mobile phone. The CSR response command can be found in the introduction of Table 12 above.

[0283] 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. The client application request carries the user type of the client.

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

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

[0286] 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 an embodiment of this application, as well as the parameter value type, parameter location, parameter necessity, and parameter description.

[0287] Table 25

[0288]

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

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

[0291] Table 26

[0292] ID field data type constraints quality default value necessity

[0293] 0IOT client certificate octstringmax400 M1 intermediate certificate octstringmax400 O2 root certificate octstringmax400 M3 cloud address string M4CTokenoctstring M5 token expiration information uint16 M

[0294] In step S622, the IoT client uses the private key in the key pair to decrypt Ctoken to obtain an access token.

[0295] In step S623, the IoT client sends an add cloud response command to the mobile phone, wherein the add cloud response command includes the client's startup password.

[0296] Typically, 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, the Add Cloud Response command can be referred to in conjunction with Table 6 above.

[0297] In step S624, the mobile phone sends a client startup request command to the vehicle terminal to request the startup of the IoT client. The client startup request command can be referred to the introduction shown in Table 7 above.

[0298] It should be noted that the above steps S615 and S624 can be understood as two scenarios for sending a client startup request command. Specifically, step S615 can be understood as when a suitable client is configured on the first device, and the configuration device can directly start the client through step S615. Step S624 can be understood as when a suitable client is not configured on the first device, and the configuration device can start the client through step S624 after reconfiguring the client.

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

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

[0301] In step S626, the vehicle-mounted terminal starts the IoT client and indicates to the mobile phone that the IoT client has been successfully started.

[0302] In step S627, the vehicle-mounted terminal indicates to the mobile phone that the IoT client startup has failed.

[0303] In some implementations, the vehicle terminal may indicate to the mobile phone the reason why the IoT client failed to start, for example, the startup password of the IoT client is incorrect, the client ID of the IoT client does not exist, etc.

[0304] It should be noted that during the above-mentioned client configuration process, the cloud platform can generate CToken and establish a binding relationship according to the method shown in steps S317 to S320. For the sake of brevity, please refer to the above introduction.

[0305] The client configuration and startup processes are described above in conjunction with steps S611 to S627. If the IoT client is successfully started, the client registration process is described below in conjunction with Figure 6(b). The method shown in Figure 6(b) includes steps S631 to S633.

[0306] In step S631 , the IoT client connects to the IoT cloud address and establishes a secure connection with the IoT cloud using a certificate.

[0307] 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.

[0308] In some implementations, the client registration request may include a client ID, an access token, and an access address of the IoT client. The client registration request may refer to the description above in conjunction with Table 18.

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

[0310] In some scenarios, the client registration response command can carry the new access token, user ID, first token, and smart home device access address assigned by the IoT cloud platform to the IoT client. For details about the client registration response command, see the description above in conjunction with Table 20.

[0311] The following describes the client login process in the embodiment of the present application in conjunction with Figure 6(c). The method shown in Figure 6(c) includes steps S641 to S642.

[0312] 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.

[0313] In some implementations, the login request includes a user ID, a client ID, and an access token. See the description above in conjunction with Table 17.

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

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

[0316] Table 27

[0317]

[0318] It should be noted that in the embodiments of the present application, in addition to exchanging the IoT client's access address and the smart home device's access address through the registration request and registration response commands as shown in FIG6 , the IoT client's access address and the smart home device's access address can also be exchanged through login request and login response commands, as described above. For example, the commands described in Tables 19 and 21 can be used. In this case, the client registration request and client registration response can be combined with the commands described in Tables 3 and 5. For the sake of brevity, this will not be repeated below.

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

[0320] FIG7 is a schematic diagram of a first device according to an embodiment of the present application. The first device 700 shown in FIG7 includes a receiving unit 710 .

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

[0322] 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.

[0323] In one possible implementation, the first device also includes: a first processing unit, used to determine whether the startup password carried in the first request matches the pre-stored 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 used to start the client.

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

[0325] 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.

[0326] In a possible implementation, the first device includes a function cluster, where the function 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.

[0327] 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 identifier of the client; and indication information of the cloud platform.

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

[0329] In one possible implementation, if the functional cluster includes the second request, the second request includes one or more of the following information: certificate information for the client to authenticate itself on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

[0330] In a possible implementation, if the functional 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.

[0331] In a possible implementation, the receiving unit is configured to 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.

[0332] 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 logging into the cloud platform, and the second information includes a user identifier of the client.

[0333] 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 a user type of the client.

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

[0335] In a possible implementation, the user type includes a long-term user or a temporary user.

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

[0337] 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.

[0338] In a possible implementation, the third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

[0339] 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 communicate using the AMTP protocol.

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

[0341] In one 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 a login request for the client to log in to the cloud platform.

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

[0343] The communication unit 810 is 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.

[0344] 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.

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

[0346] In a possible implementation, the first device includes a function cluster, and the function cluster is used to record the client.

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

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

[0349] In one possible implementation, if the functional cluster includes the second request, the second request includes one or more of the following information: certificate information used for the client to authenticate the identity of the client on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

[0350] In a possible implementation, if the functional 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.

[0351] In a possible implementation, the communication unit is further used to: 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.

[0352] In a possible implementation, the communication unit is further 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, and the second information includes a user identifier of the client.

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

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

[0355] In a possible implementation, the user type includes a long-term user or a temporary user.

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

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

[0358] In a possible implementation, the third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

[0359] 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 communicate using the AMTP protocol.

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

[0361] In one 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 a login request for the client to log in to the cloud platform.

[0362] FIG9 is a schematic diagram of a configuration device according to an embodiment of the present application. The configuration device 900 shown in FIG9 includes a sending unit 910 .

[0363] The sending unit 910 is configured to send a first request to a 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.

[0364] In a possible implementation, the first request carries a startup password of the client, where the startup password is used to authenticate the user who starts the client, and / or the first request carries cloud platform information of the client.

[0365] In a possible implementation, the first device includes a function cluster, where the function 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.

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

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

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

[0369] In a possible implementation, if the functional 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.

[0370] 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 store the startup password of the client if the user type of the client is a long-term user.

[0371] 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 a user type of the client.

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

[0373] In a possible implementation, the user type includes a long-term user or a temporary user.

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

[0375] In an optional embodiment, the receiving unit 710 may be a transceiver 1040. The first device 700 may further include a processor 1010 and a memory 1020, as specifically shown in FIG10 .

[0376] In an optional embodiment, the communication unit 810 may be a transceiver 1040. The cloud platform 800 may further include a processor 1010 and a memory 1020, as specifically shown in FIG10 .

[0377] In an optional embodiment, the sending unit 910 may be a transceiver 1040. The configuration device 900 may further include a processor 1010 and a memory 1020, as specifically shown in FIG10 .

[0378] Figure 10 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 10 indicate that the unit or module is optional. The device 1000 may 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.

[0379] The device 1000 may include one or more processors 1010. The processor 1010 may support the device 1000 to implement the method described in the method embodiment above. 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 may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

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

[0381] The apparatus 1000 may further include a transceiver 1030. The processor 1010 may communicate with other devices or chips via the transceiver 1030. For example, the processor 1010 may transmit and receive data with other devices or chips via the transceiver 1030.

[0382] The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to a terminal or network device provided in the present application, and the program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0383] The present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in the present application, and the program causes a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0384] The embodiments of the present application also provide a computer program. The computer program can be applied to the terminal or network device provided in the embodiments of the present application, and the computer program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

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

[0386] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

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

[0388] In the embodiments of the present application, the term "corresponding" may indicate that there is a direct correspondence or indirect relationship between the two, or that there is an association relationship between the two, or a relationship of indication and being indicated, configuration and being configured, etc.

[0389] In the embodiments of the present application, "pre-definition" or "pre-configuration" may be implemented by pre-storing corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a terminal device and a network device). The present application does not limit the specific implementation method. For example, pre-definition may refer to information defined in a protocol.

[0390] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0391] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

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

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

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

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

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

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

Claims

1. A method for starting a client, characterized in that: include: The first device receives 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.

2. The method according to 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.

3. The method according to claim 2, wherein The method further comprises: Determining, by the first device, whether the startup password carried in the first request matches a pre-stored startup password of the client; If the startup password carried in the first request matches the pre-stored startup password, the first device starts the client.

4. The method according to claim 1, wherein The first request carries indication information of the cloud platform.

5. The method according to claim 4, wherein The method further comprises: The first device selects the client based on the cloud platform information carried in the first request.

6. The method according to any one of claims 1 to 5, wherein The first device includes a function cluster, and the function cluster is used to indicate commands supported by the client; and / or The functional cluster is used to record the client corresponding to the long-term user in the first device.

7. The method according to 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: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

8. The method according to claim 6 or 7, wherein: 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; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request the cloud platform for a certificate for identity authentication of the client.

9. The method according to claim 8, wherein If the functional cluster includes the second request, the second request includes one or more of the following information: certificate information for the client to authenticate itself on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

10. The method according to claim 8, wherein If the functional 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.

11. The method according to any one of claims 1 to 10, wherein The method further comprises: 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.

12. The method according to any one of claims 1 to 11, wherein The method further comprises: The first device sends second information to the cloud platform, where the second information is used to request logging into the cloud platform, and the second information includes a user identifier of the client.

13. The method according to any one of claims 1 to 12, wherein The method further comprises: The first device receives first indication information sent by the configuration device, where the first indication information is used to configure a user type of the client.

14. The method according to claim 13, wherein The user type of the client is configured by the user through the configuration device.

15. The method according to claim 13 or 14, characterized in that The user type includes a long-term user or a temporary user.

16. The method according to any one of claims 1 to 15, wherein The user type of the client is a long-term user.

17. The method according to any one of claims 1 to 16, wherein The method further comprises: The first device sends third information to the cloud platform, where the third information includes the access address of the client.

18. The method according to claim 17, wherein The third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

19. The method according to 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 communicate using the AMTP protocol.

20. The method according to any one of claims 17 to 19, wherein The method further comprises: In response to the third information, the first device receives fourth information sent by the cloud platform, where the fourth information includes an access address of a second device to be accessed by the client.

21. The method according to claim 20, 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 is carried in a response command to a login request of the client requesting to log in to the cloud platform.

22. A method for starting a client, characterized in that: include: The cloud platform communicates 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.

23. The method according to 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.

24. The method of claim 22, wherein: The first request carries the cloud platform information of the client.

25. The method according to any one of claims 22 to 24, wherein The first device includes a functional cluster, and the functional cluster is used to record the client.

26. The method of claim 25, wherein: The function cluster is used to indicate one or more of the following information of the client: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

27. The method according to claim 25 or 26, wherein 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; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request a certificate from the cloud platform for authentication of the client.

28. 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: certificate information used for the client to authenticate the identity of the client on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

29. The method of claim 27, wherein: If the functional 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.

30. The method according to any one of claims 22 to 29, wherein The method further comprises: 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.

31. The method according to any one of claims 22 to 30, wherein The method further comprises: The cloud platform receives second information sent by the first device, where the second information is used to request logging into the cloud platform, and the second information includes a user identifier of the client.

32. The method according to any one of claims 22 to 31, wherein The method further comprises: The cloud platform receives second indication information sent by the configuration device, where the second indication information is used to configure a user type of the client.

33. The method of claim 32, wherein: The user type of the client is configured by the user through the configuration device.

34. The method according to claim 32 or 33, wherein The user type includes a long-term user or a temporary user.

35. The method according to any one of claims 22 to 34, wherein The user type of the client is a long-term user.

36. The method according to any one of claims 22 to 35, wherein The method further comprises: The cloud platform receives third information sent by the first device, where the third information includes the access address of the client.

37. The method of claim 36, wherein: The third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

38. The method according to 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 communicate using the AMTP protocol.

39. The method according to any one of claims 36 to 38, wherein The method further comprises: In response to the third information, the cloud platform sends fourth information to the first device, where the fourth information includes an access address of a second device to be accessed by the client.

40. The method of claim 39, 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 is carried in a response command to a login request of the client requesting to log in to the cloud platform.

41. A method for starting a client, characterized in that: include: 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.

42. The method of claim 41, wherein 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 cloud platform information of the client.

43. The method according to claim 41 or 42, wherein The first device includes a function cluster, and the function cluster is used to indicate commands supported by the client; and / or The functional cluster is used to record the client corresponding to the long-term user in the first device.

44. The method of claim 43, wherein: The function cluster is used to indicate one or more of the following information of the client: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

45. The method according to claim 43 or 44, wherein 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; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request the cloud platform for a certificate for identity authentication of the client.

46. ​​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: certificate information used for the client to authenticate the identity on the cloud platform, address information of the cloud platform, and access token information of the cloud platform.

47. The method of claim 45, wherein If the functional 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.

48. The method of claim 47, wherein If the response command to the second request includes the 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.

49. The method according to any one of claims 41 to 48, wherein The method further comprises: The configuration device sends first indication information to the first device, where the first indication information is used to configure a user type of the client.

50. The method of claim 49, wherein The user type of the client is configured by the user through the configuration device.

51. The method according to claim 49 or 50, wherein The user type includes a long-term user or a temporary user.

52. The method according to any one of claims 41 to 51, wherein The user type of the client is a long-term user.

53. A first device, characterized in that include: The receiving unit is configured to receive a first request sent by a configuration device, where the first request is used to request the startup of a client in the first device, where the client is used to communicate with the cloud platform.

54. 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.

55. The first device according to claim 54, wherein The first device further includes: a first processing unit, configured to determine whether the startup password carried in the first request matches a pre-stored 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 further configured to start the client.

56. The first device according to claim 53, wherein The first request carries indication information of the cloud platform.

57. The first device according to claim 56, wherein 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.

58. The first device according to any one of claims 53 to 57, characterized in that The first device includes a function cluster, and the function cluster is used to indicate commands supported by the client; and / or The functional cluster is used to record the client corresponding to the long-term user in the first device.

59. The first device according to 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: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

60. The first device according to claim 58 or 59, characterized in that 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; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request the cloud platform for a certificate for identity authentication of the client.

61. The first device according to claim 60, wherein If the functional cluster includes the second request, the second request includes one or more of the following information: certificate information for the client to authenticate itself on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

62. The first device according to claim 60, wherein If the functional 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.

63. The first device according to any one of claims 53 to 62, characterized in that The receiving unit is configured to: 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.

64. The first device according to any one of claims 53 to 63, characterized in that The first device further includes: The first sending unit is used to send second information to the cloud platform, where the second information is used to request to log in to the cloud platform, and the second information includes a user identifier of the client.

65. The first device according to any one of claims 53 to 64, characterized in that The receiving unit is configured to: Receive first indication information sent by the configuration device, where the first indication information is used to configure a user type of the client.

66. The first device according to claim 65, wherein The user type of the client is configured by the user through the configuration device.

67. The first device according to claim 65 or 66, characterized in that The user type includes a long-term user or a temporary user.

68. 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.

69. The first device according to any one of claims 53 to 68, characterized in that The first device further includes: The second sending unit is used to send third information to the cloud platform, where the third information includes the access address of the client.

70. The first device according to claim 69, wherein The third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

71. The first device according to claim 69 or 70, characterized in that The access address is an access address based on the AMTP protocol, and the third information is used to instruct the client to communicate using the AMTP protocol.

72. The first device according to any one of claims 69 to 71, characterized in that The receiving unit is configured to: In response to the third information, fourth information sent by the cloud platform is received, where the fourth information includes an access address of a second device to be accessed by the client.

73. The first device according to claim 72, characterized in that 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 is carried in a response command to a login request of the client requesting to log in to the cloud platform.

74. A cloud platform, characterized in that include: The communication unit is 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.

75. The cloud platform according to 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.

76. The cloud platform according to claim 74, wherein: The first request carries the cloud platform information of the client.

77. The cloud platform according to any one of claims 74 to 76, wherein: The first device includes a functional cluster, and the functional cluster is used to record the client.

78. The cloud platform according to claim 77, wherein: The function cluster is used to indicate one or more of the following information of the client: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

79. The cloud platform according to claim 77 or 78, wherein: 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; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request a certificate from the cloud platform for authentication of the client.

80. The cloud platform according to claim 79, wherein: If the functional cluster includes the second request, the second request includes one or more of the following information: certificate information used for the client to authenticate the identity of the client on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

81. The cloud platform according to claim 79, wherein: If the functional 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.

82. The cloud platform according to any one of claims 74 to 81, wherein: The communication unit is further configured to: A first message is sent to the first device, where the first message includes a first token, and the first token is used to request the cloud platform to update the access token.

83. The cloud platform according to any one of claims 74 to 82, wherein: 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, and the second information includes a user identifier of the client.

84. The cloud platform according to any one of claims 74 to 83, wherein: The communication unit is further configured to: Second indication information sent by the configuration device is received, where the second indication information is used to configure a user type of the client.

85. The cloud platform according to claim 84, wherein: The user type of the client is configured by the user through the configuration device.

86. The cloud platform according to claim 84 or 85, wherein: The user type includes a long-term user or a temporary user.

87. The cloud platform according to any one of claims 74 to 86, wherein: The user type of the client is a long-term user.

88. The cloud platform according to any one of claims 74 to 87, wherein: 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.

89. The cloud platform according to claim 88, wherein: The third information is carried in a registration request from the client to register on the cloud platform, and / or the third information is carried in a login request from the client to log in to the cloud platform.

90. The cloud platform according to 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 communicate using the AMTP protocol.

91. The cloud platform according to any one of claims 88 to 90, wherein: The communication unit is further configured to: In response to the third information, fourth information is sent to the first device, where the fourth information includes an access address of a second device to be accessed by the client.

92. The cloud platform according to 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 is carried in a response command to a login request of the client requesting to log in to the cloud platform.

93. A configuration device, characterized in that include: A sending unit is used to send a first request to a first device, where the first request is used to request to start a client in the first device, and the client is used to communicate with the cloud platform.

94. The configuration device of claim 93, wherein: 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 cloud platform information of the client.

95. The configuration device according to claim 93 or 94, characterized in that The first device includes a function cluster, and the function cluster is used to indicate commands supported by the client; and / or The functional cluster is used to record the client corresponding to the long-term user in the first device.

96. The configuration device of claim 95, wherein: The function cluster is used to indicate one or more of the following information of the client: a client identifier of the client; The user identification of the client; and Indication information of the cloud platform.

97. 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 for instructing the client to add the cloud platform; a response command to the second request, wherein the response command to the second request is used to indicate whether the cloud platform is added successfully; a third request for requesting a CSR for the client; A response command to the third request, wherein the response command to the third request is used to request the cloud platform for a certificate for identity authentication of the client.

98. The configuration device of claim 97, wherein: If the functional cluster includes the second request, the second request includes one or more of the following information: certificate information used for the client to authenticate the identity on the cloud platform, address information of the cloud platform, and access token information of the cloud platform.

99. The configuration device of claim 97, wherein: If the functional 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.

100. 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: The processing unit is configured to store the startup password of the client if the user type of the client is a long-term user.

101. The configuration device according to any one of claims 93 to 100, characterized in that: The sending unit is further configured to: First indication information is sent to the first device, where the first indication information is used to configure a user type of the client.

102. The configuration device according to claim 101, wherein The user type of the client is configured by the user through the configuration device.

103. The configuration device according to claim 101 or 102, characterized in that The user type includes a long-term user or a temporary user.

104. The configuration device according to any one of claims 93 to 103, characterized in that The user type of the client is a long-term user.

105. A first device, characterized in that The device comprises a transceiver, a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory and control the transceiver to receive or send a signal, so that the first device executes the method according to any one of claims 1 to 21.

106. 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 programs in the memory and control the transceiver to receive or send signals so that the cloud platform executes the method as described in any one of claims 22-40.

107. 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 programs in the memory and control the transceiver to receive or send signals so that the configuration device executes the method as described in any one of claims 41-52.

108. A device, characterized in that The device comprises a processor configured to call a program from a memory so as to cause the device to execute the method according to any one of claims 1 to 52.

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

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

111. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 52.

112. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 1 to 52.

Images