Communication method, first device, configuration device and cloud platform

Abstract

Provided are a communication method, a first device, a configuration device, and a cloud platform. The method includes a first client in the first device communicating with a cloud platform, wherein the user type of the first client is a long-term user. In an embodiment of the present application, a client for long-term users is introduced, which helps to enrich the application scenarios of the client and improve the user experience compared to the client only involving temporary users in the traditional solution.

Description

Communication method, 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 communication method, a first device, a configuration device, and a cloud platform. Background Art

[0002] Currently, the interaction process between the client and the cloud platform is designed based on the scenario that the client user is a temporary user. This scenario for temporary users is relatively simple and cannot meet the needs of users, resulting in a low user experience.

[0003] Summary of the Invention

[0004] The present application provides a communication method, a first device, a configuration device, and a cloud platform. The following introduces various aspects involved in the present application.

[0005] In a first aspect, a communication method is provided, including: a first client in a first device communicates with a cloud platform, wherein the user type of the first client is a long-term user.

[0006] In a second aspect, a communication method is provided, including: a configuration device sends first indication information to a first device, the first indication information being used to indicate a user type of a first client in the first device; and / or the configuration device sends second indication information to a cloud platform, the second indication information being used to indicate a user type of the first client, wherein the user type of the first client is a long-term user, and the first client is used to communicate with the cloud platform.

[0007] According to a third aspect, a communication method is provided, including: a cloud platform communicating with a first client in a first device, wherein the user type of the first client is a long-term user.

[0008] In a fourth aspect, a communication method is provided, wherein a first device is configured with a first client and stores first information for the first client to log in to a cloud platform. The method includes: the first device sends a fifth request to the cloud platform based on the first information, and the fifth request is used by the first client to request to re-login to the cloud platform.

[0009] In a fifth aspect, a communication method is provided, comprising: a cloud platform receives a fifth request sent by a first device, wherein the fifth request is used by a first client in the first device to request to re-login to the cloud platform.

[0010] In a sixth aspect, a first device is provided, comprising: a processing unit, configured to communicate with a cloud platform via a first client, wherein the user type of the first client is a long-term user.

[0011] In the seventh aspect, a configuration device is provided, including: a sending unit, used to send first indication information to a first device, the first indication information being used to indicate the user type of a first client in the first device; and / or, sending second indication information to a cloud platform, the second indication information being used to indicate the user type of the first client, wherein the user type of the first client is a long-term user, and the first client is used to communicate with the cloud platform.

[0012] In an eighth aspect, a cloud platform is provided, comprising: a communication unit for communicating with a first client in a first device, wherein the user type of the first client is a long-term user.

[0013] In the ninth aspect, a first device is provided, which is configured with a first client and stores first information for the first client to log in to the cloud platform. The first device includes: a sending unit for sending a fifth request to the cloud platform based on the first information, and the fifth request is used by the first client to request to re-login to the cloud platform.

[0014] In a tenth aspect, a cloud platform is provided, comprising: a receiving unit for receiving a fifth request sent by a first device, wherein the fifth request is used by a first client in the first device to request to re-login to the cloud platform.

[0015] In the eleventh 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 methods of the above aspects.

[0016] In the twelfth aspect, a configuration device is provided, including 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 part or all of the steps in the methods of the above aspects.

[0017] In the thirteenth aspect, a cloud platform is provided, including 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 methods of the above aspects.

[0018] In a fourteenth aspect, embodiments of the present application provide a communication system, comprising one or more of the aforementioned first device, configuration device, and cloud platform. In another possible design, the system may further include other devices that interact with the first device, configuration device, or cloud platform in the solutions provided in embodiments of the present application.

[0019] In the fifteenth 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 or a cloud platform) to perform some or all of the steps in the methods of the above aspects.

[0020] In a sixteenth 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, or a cloud platform) to perform some or all of the steps of the methods described in each of the above aspects. In some implementations, the computer program product may be a software installation package.

[0021] In the seventeenth 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.

[0022] In the embodiment of the present application, a client for long-term users is introduced. Compared with the client only involving temporary users in the traditional solution, it helps to enrich the application scenarios of the client and improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0026] FIG4 is a flow chart of a communication method according to an embodiment of the present application.

[0027] Figures 5(a) to 5(c) are schematic flow charts of the communication method according to an embodiment of the present application.

[0028] FIG6(a) to FIG6(c) are schematic flow charts of a communication method according to another embodiment of the present application.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0049] 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."

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

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

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

[0053] 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."

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

[0055] Model of the Matter device

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

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

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

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

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

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

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

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

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

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

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

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

[0068] 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."

[0069] Direction, usually present in a 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.

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

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

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

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

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

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

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

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

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

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

[0080] 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).

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

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

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

[0084] Connection solution between client and cloud platform

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

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

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

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

[0089] In step S313 , if the user agrees to use the first device to control the second device, the configuration device sends a certificate signing request (CSR) request command to the first device.

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

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

[0092] 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).

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

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

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

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

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

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

[0099] In step S320, the cloud platform encrypts the access token using the client's public key to obtain an encrypted access token, which is represented by "CToken".

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

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

[0102] Table 1

[0103]

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

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

[0106] Table 2

[0107]

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

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

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

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

[0112] Table 3

[0113] HTTP method interface access address POST / account

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

[0115] Table 4

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

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

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

[0119] Table 5

[0120]

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

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

[0123] Currently, the interaction process between the client and the cloud platform is designed based on the scenario that the client user is a temporary user. This scenario for temporary users is relatively simple and cannot meet the needs of users, resulting in a poor user experience. Therefore, the embodiments of the present application introduce a client for long-term users to enrich the application scenarios of the client and help improve the user experience.

[0124] The following describes the communication method according to an embodiment of the present application in conjunction with Figure 4. Figure 4 is a schematic flow chart of the communication method according to an embodiment of the present application. The steps shown in Figure 4 include S410.

[0125] In step S410, a first client in a first device communicates with a cloud platform.

[0126] The user type of the first client is a long-term user, or in other words, the first client can be a long-term client. Taking the first device as a vehicle as an example, the long-term user corresponding to the first client can be the owner of the vehicle.

[0127] Correspondingly, the first device may also be configured with a client for a temporary user (also referred to as a "temporary client"). For the client used by the temporary user, if the first device is a vehicle, the temporary user may be a temporary passenger of the vehicle.

[0128] After introducing clients for long-term users, the operations performed by the first device for such clients may be different from those performed for temporary clients. Therefore, the first device needs to know the user type of the client. Therefore, an embodiment of the present application also provides a configuration scheme for the user type of the client.

[0129] In some implementations, the user type of the client can be informed to the first device by the configuration device, that is, the configuration device sends first indication information to the first device, and the first indication information is used to indicate the user type of the first client. In other words, the first indication information can be used to indicate whether the user type of the first client is a long-term user.

[0130] In some implementations, the first indication information may be carried in a CSR request command (also known as a third request). The following describes the parameters of the CSR request command of an embodiment of the present application in conjunction with Table 6. Referring to Table 6, the CSR request may carry the parameter long-term user (i.e., the first indication information) to indicate the user type of the client. The identifier of the long-term user field may be 0, and the data type of the field may be a Boolean value. When the Boolean value is true (true), it indicates that the user type of the client is a long-term user. When the Boolean value is false (false), it indicates that the user type of the client is a temporary user.

[0131] Table 6

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

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

[0134] 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 7 shows the parameters of the CSR response command in an embodiment of the present application. Referring to Table 7, the CSR request may carry the parameter CSR. In addition, Table 7 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.

[0135] Table 7

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

[0137] Accordingly, after introducing clients for long-term users, the operations performed by the cloud platform for such clients may be different from those performed for temporary clients. Therefore, the cloud platform needs to know the user type of the client. Therefore, the embodiment of the present application also provides a configuration scheme for the user type of the client.

[0138] In other implementations, the user type of the client can be informed to the cloud platform by the configuration device, that is, the configuration device sends a second indication information to the cloud platform, and the second indication information is used to indicate the user type of the first client. In other words, the second indication information can be used to indicate whether the user type of the first client is a long-term user.

[0139] 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 this application in conjunction with Table 8 and Table 9. Referring to Table 8, the HTTP method used by the client application interface is POST, and the interface access address is " / addclient".

[0140] Table 8

[0141] HTTP Method interface access address POST / addclient

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

[0143] Table 9

[0144]

[0145]

[0146] 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").

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

[0148] It should be noted that the user type of the first client indicated by the first indication information may be the same as the user type of the first client indicated by the second indication information.

[0149] The previous section describes the user types of the first client and the configuration process for the first client user type. The following section describes the login and logout process between the client and the cloud platform.

[0150] At present, the traditional interaction schemes between the client and the cloud platform are all designed based on the scenario of temporary users using the client. If the client wants to disconnect from the cloud platform, it can only disconnect from the cloud platform by logging off. After the client logs off from the cloud platform, the cloud platform and the first device will delete the client's information accordingly (for example, the client identifier, the client's user identifier, the client's corresponding cloud platform indication information, the client's access token, etc.). In this way, if the user needs to log in to the cloud platform again through the client, the only way to re-establish the connection between the client and the cloud platform is to re-establish the connection between the client and the cloud platform according to the method shown in Figure 3. However, since the clients used by long-term users are usually configured the same, this method of disconnecting the connection between the cloud platform and the client by logging off, when applied to the scenario of long-term users using the client, may cause the long-term user to need to re-establish the connection between the client and the cloud platform every time after disconnecting the connection between the client and the cloud platform. The operation of establishing the connection is too complicated, which reduces the user experience.

[0151] Therefore, in the embodiment of the present application, the client of a long-term user can disconnect from the cloud platform by logging out. Accordingly, the cloud platform and the first device will not delete the information used by the client to log in to the cloud platform (also referred to as "first information"). In this way, when the long-term user needs to log in to the cloud platform through the client again, the first information can be reused to establish a connection between the client and the cloud platform, which helps to reduce the related operations of client configuration and improve the user experience.

[0152] In some implementations, the first device may send a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform. Therefore, the fourth request may also be referred to as a "logout request."

[0153] In the embodiment of the present application, only the client of a long-term user can be allowed to disconnect from the cloud platform in a logout manner. On the contrary, for the client of a temporary user, the connection with the cloud platform can only be disconnected in a logout manner.

[0154] In some implementations, the above method also includes: if the user type of the first client is a long-term user, in response to the fourth request, the cloud platform logs out of the first client; and / or if the user type of the first client is a temporary user, in response to the fourth request, the cloud platform logs out or refuses to log out of the first client.

[0155] Of course, in the embodiment of the present application, the client of the temporary user can also disconnect from the cloud platform by logging out, and the embodiment of the present application does not limit this.

[0156] In some implementations, the first device sends a fifth request to the cloud platform based on the first information, where the fifth request is used by the first client to request to re-login to the cloud platform.

[0157] The first information may include one or more of the following: an access token for the first client to log in to the cloud platform; a client identifier of the first client; a user identifier of the first client; and instructions for the cloud platform. The functions and maintenance methods of the first information will be described below in conjunction with the functional cluster and will not be detailed here for the sake of brevity.

[0158] Accordingly, in other implementations, after receiving the fifth request, the cloud platform may determine whether to allow the first client to log in to the cloud platform based on the pre-stored second information of the first client. That is, the cloud platform stores the second information for the first client to log in to the cloud platform, and the above method further includes: in response to the fifth request, the cloud platform determines whether to allow the first client to re-login based on the second information. Of course, in the embodiment of the present application, after receiving the fifth request, the cloud platform may also directly allow the first client to log in to the cloud platform, and the embodiment of the present application is not limited to this.

[0159] In some implementations, the second information may include one or more of the following information: an access token for the first client to log in to the cloud platform; a client identifier of the first client; a user identifier of the first client; and a user type of the first client.

[0160] The following takes the example where the first information includes an access token, a client identifier and a user identifier, and the second information includes an access token, a client identifier, a user identifier and a user type. If the access token, the client identifier and the user identifier in the first information match the access token, the client identifier and the user identifier in the second information, and the user type of the first client in the second information is a long-term user, the cloud platform can allow the first client to re-login to the cloud platform.

[0161] On the contrary, if the access token, client identifier and user identifier in the first information do not partially or completely match the access token, client identifier and user identifier in the second information, the cloud platform may refuse the first client to re-login to the cloud platform.

[0162] Of course, if the access token, client identifier and user identifier in the first information match the access token, client identifier and user identifier in the second information, but the user type of the first client in the second information is a temporary user, the cloud platform can refuse the first client to re-login to the cloud platform.

[0163] In some implementations, the fourth request and the fifth request may adopt the same command format. The fourth request and the fifth request of the embodiment of the present application are introduced below in conjunction with Table 10 and Table 11.

[0164] The following is a description of the login / logout interface and command format of an embodiment of the present application in conjunction with Table 10 and Table 11. As shown in Table 10, the HTTP method of the login / logout interface can be POST, and the access address of the login / logout interface can be represented as " / session".

[0165] Table 10

[0166] HTTP method interface access address POST / session

[0167] Referring to Table 11, the command may include "accept," "content-type," "access token," "user identifier," "client identifier," and "login status." When the login status indicates login, the command format is that of a login request (i.e., the fifth request). When the login status indicates logout, the command format is that of a logout request (i.e., the fourth request). Table 11 further describes the position of each parameter in the command, its value type, its necessity, and its description.

[0168] Table 11

[0169]

[0170] Of course, in the embodiment of the present application, the fourth request and the fifth request may also adopt different command formats and correspond to different interface parameters, which is not limited in the embodiment of the present application.

[0171] To facilitate client management and avoid confusion in client configuration, the cloud platform typically maintains only one unique client. If the client requested by the configuration device already exists on the cloud platform, the cloud platform may reject the client's request. In other words, the method further includes: the configuration device sending a sixth request to the cloud platform, the sixth request being used to request a second client from the cloud platform; if the second client is the same as the first client, the cloud platform rejects the sixth request.

[0172] The user type of the second client can be a temporary user or a long-term user, which is not limited in this embodiment of the present application. In addition, if problems such as client configuration confusion are not considered, in this embodiment of the present application, multiple identical clients can also be maintained on the cloud platform, which is not limited in this embodiment of the present application.

[0173] In some implementations, the information of the first client (e.g., the first information) can be maintained as an attribute of a functional cluster. That is, the first device can include a functional cluster (also referred to as a "client functional cluster") that is used to record the clients on the first device. Generally, the first device can record information about clients of long-term users in the functional cluster, while the first device may not record information about clients of temporary users in the functional cluster.

[0174] In some implementations, the information of the first client may include one or more of the following information: a client identifier of the first client; a user identifier of the first client; and indication information of the cloud platform.

[0175] The client identifier of the first client is used to identify the first client.

[0176] The user identification of the first client may be used to identify the user of the first client.

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

[0178] For ease of understanding, the following describes possible implementations of a functional cluster in conjunction with Tables 12 and 13. Referring to Table 12, 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").

[0179] Table 12

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

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

[0182] Table 13

[0183] 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

[0184] In some implementations, the configuration device can 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) through the functional cluster. If it is determined that a suitable client is configured in the first device, the configuration device can determine that a suitable client is already configured in the first device.

[0185] 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 client's cloud address is consistent with the cloud address of the configuration device), and the client's user ID 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.

[0186] As described above, the information of the client in the first device can be maintained by a functional cluster. Accordingly, the commands supported by the client (for example, 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 above-mentioned functional cluster also includes commands supported by the client. It should be noted that the commands included in the above-mentioned functional cluster can be supported by long-term clients and / or temporary clients. This embodiment of the present application does not limit this. The following description will be made using the commands supported by the first client as an example.

[0187] In some implementations, the functional cluster includes one or more of the following commands: a first request for requesting the first device to start the first client; 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 CSR of the first client; a response command to the third request, wherein the response command to the third request is used to request a certificate for authentication of the first client from the cloud platform.

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

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

[0190] The response command to the first request is used to indicate whether the first client is successfully started.

[0191] In some implementations, to improve the security of launching the client, the first client can be launched based on a launch password, where the launch password is used to verify whether the first client is launched, or in other words, the launch password is used to authenticate the user who launches the first client, or in other words, the launch password is used to authenticate the configuration device. If the launch password is used to authenticate the configuration device, the launch password can also be called a configuration device mediator password (MedPassword).

[0192] In some implementations, the first request may include a startup password for the first client. Accordingly, if the startup password included in the first request matches the startup password for the first client pre-stored on the first device, the first client may be launched. Conversely, if the startup password included in the first request does not match the startup password for the first client pre-stored on the first device, the launch of the first client may be denied.

[0193] It should be noted that the aforementioned match can be understood as the startup password carried in the first request being identical to the pre-stored startup password of the first client, or the startup password carried in the first request being different from the pre-stored startup password of the first client but satisfying a preset correspondence. Accordingly, the aforementioned mismatch can be understood as the startup password carried in the first request being different from the pre-stored startup password of the first client, or the startup password carried in the first request being different from the pre-stored startup password of the first client and not satisfying the preset correspondence.

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

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

[0196] Table 14

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

[0198] In some scenarios, the first device may be provided with first clients that communicate with different cloud platforms, and the client identifiers of these first clients may be the same. In this case, the first request may carry the indication information of the cloud platform corresponding to the first client to be started, so that the first device can identify the first client to be started. If different first clients in the first device have unique identifiers (for example, client IDs), the first request may only carry the unique identifiers corresponding to the first clients to be started, and no longer carry the indication information of the cloud platform. Of course, if different first clients in the first device have unique identifiers, they may also carry the indication information of the cloud platform, and this embodiment of the present application is not limited to this.

[0199] For ease of understanding, the following describes possible implementations of the first request in conjunction with Table 15. Referring to Table 15, the parameters in the first request may include the first client's client identifier, the first client's startup password, and the cloud address corresponding to the first client. Table 15 also shows the parameter data type, parameter identifier, parameter constraints, parameter quality, parameter default value, and parameter necessity.

[0200] Table 15

[0201] ID Field Data Type Constraint Quality Default Value Necessity 0 Client ID octstrmax99 M1 Startup Password octstr32 M2 Cloud Address string M

[0202] Accordingly, after receiving the first request, the first device may determine the first client based on the client identifier in the first request. Then, based on a pre-stored correspondence between the first client's client identifier and the startup password, determine whether the pre-stored startup password of the first client matches the startup password in the first request. Furthermore, based on a pre-stored correspondence between the first client and the cloud address, determine whether the pre-stored cloud address of the first client matches the cloud address in the first request.

[0203] The 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 used by the first client to authenticate itself on the cloud platform, instruction information of the cloud platform, and access token information of the cloud platform.

[0204] 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 first client.

[0205] 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".

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

[0207] Table 16

[0208]

[0209] In the embodiment of the present application, the information of the first client and the commands supported by the first 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.

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

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

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

[0213] Typically, the first client needs to access the cloud platform using an access token. In some scenarios, the first client may need to access the cloud platform multiple times. If the first client uses the same access token each time, this may not be conducive to improving the security of the cloud platform. For example, if the first client is a long-term user, the user may access the cloud platform multiple times through the first client. In this case, if the first client's access token remains unchanged, it may be intercepted by an attacker, threatening the security of the cloud platform.

[0214] Therefore, in an embodiment of the present application, the cloud platform can configure a first token (also known as a "refresh token") for the first client, which is used by the first client to request the cloud platform to update its access token. Accordingly, the first 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 consistently using the same access token to access the cloud platform.

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

[0216] In some implementations, the first token may be included in a registration response command. Table 17 illustrates the interface parameters for a registration response command according to an embodiment of the present application. Referring to Table 17, 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 17.

[0217] Table 17

[0218]

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

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

[0221] In some implementations, the third information may be carried in a registration request, wherein the registration request is used by the first 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 of the first client, and an access address of the first client (e.g., a first 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.

[0222] Table 18

[0223]

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

[0225] In other implementations, the third information may be carried in a login request, which is used by the first 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 11, with the addition of the first client access address (e.g., ClientURL).

[0226] Table 19

[0227]

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

[0229] Accordingly, if the first 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.

[0230] Accordingly, after the first client successfully logs into the cloud platform, the first client can communicate with the second device based on the access address of the second device. For example, the first client can send control information to the second device based on the access address of the second device to control the second device.

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

[0232] Table 20

[0233]

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

[0235] 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 first client identifier, and a URL of the first 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.

[0236] Table 21

[0237]

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

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

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

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

[0242] Figures 5(a) to 5(c) are schematic flow charts of a communication method according to an embodiment of the present application. The method shown in Figure 5(a) includes steps S511 to S527.

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

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

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

[0246] Among them, the client cluster can refer to the introduction of Table 12, Table 13 and Table 16 above, and will not be repeated here for the sake of brevity.

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

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

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

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

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

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

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

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

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

[0256] 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 7 above.

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

[0258] In addition, the parameters included in the client application request can be found in the introduction above in conjunction with Table 8 and Table 9.

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

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

[0261] Table 22

[0262] Position Parameter Value Type Necessity Description Header Internet Media Type String No MIME type used for command payload Subject CTokenString is the access token encrypted by the IoT client public key Subject Certificate Chain String is the certificate chain issued for the IoT client Subject Token Expiration Information Number is the validity period of the access token. When the value is -1, it means access

[0263] Token is valid forever

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

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

[0266] Table 23

[0267] ID Field Data Type Constraint Quality Default Value Necessity 0IOT Client Certificate octstringmax400 M1 Intermediate Certificate octstringmax400 O2 Root Certificate octstringmax400 M3 Cloud Address string M4 CToken octstring M5 Token Expiration Information uint16 M

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

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

[0270] 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 14 above.

[0271] 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 15 above.

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

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

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

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

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

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

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

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

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

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

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

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

[0284] 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 referred to in the above description in conjunction with Table 5.

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

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

[0287] 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 11.

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

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

[0290] Table 24

[0291]

[0292] Figures 6(a) to 6(c) are schematic flow charts of a communication method 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.

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

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

[0295] Among them, the client cluster can refer to the introduction of Table 12, Table 13 and Table 16 above, and will not be repeated here for the sake of brevity.

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

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

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

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

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

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

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

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

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

[0305] 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 17 above.

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

[0307] In addition, the parameters included in the client application request can be found in the introduction above in conjunction with Table 8 and Table 9.

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

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

[0310] Table 25

[0311]

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

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

[0314] Table 26

[0315] ID Field Data Type Constraint Quality Default Value Necessity 0IOT Client Certificate octstringmax400 M1 Intermediate Certificate octstringmax400 O2 Root Certificate octstringmax400 M3 Cloud Address string M4 CToken octstring M5 Token Expiration Information uint16 M

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

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

[0318] 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 14 above.

[0319] 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 15 above.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0335] 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 11.

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

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

[0338] Table 27

[0339]

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

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

[0342] 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 processing unit 710 .

[0343] The processing unit 710 is configured to communicate with the cloud platform via a first client, where the user type of the first client is a long-term user.

[0344] In a possible implementation, the first device further includes: a receiving unit, configured to receive first indication information sent by a configuration device, where the first indication information is used to indicate a user type of the first client.

[0345] In a possible implementation, the first device includes a function cluster, where the function cluster is used to indicate commands supported by the first client; and / or the function cluster is used to record clients in the first device whose user type is a long-term user.

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

[0347] In one possible implementation, the functional cluster includes one or more of the following commands: a first request for instructing the startup of the first client; a second request for instructing the first 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 first client; and a response command to the third request, wherein the response command to the third request is used to request a certificate for authentication of the first client from the cloud platform.

[0348] In a possible implementation, if the functional cluster includes the first request, the first request includes a startup password of the first client and / or instruction information of the cloud platform.

[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 for authentication of the first 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 first client.

[0351] In a possible implementation, the first device further includes: a first sending unit, configured to send a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

[0352] In a possible implementation, the first device further includes: a second sending unit, configured to send a fifth request to the cloud platform, where the fifth request is used by the first client to request to re-login to the cloud platform.

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

[0354] In a possible implementation manner, the user type of the client in the first device includes a long-term user or a temporary user.

[0355] FIG8 is a schematic diagram of a configuration device according to an embodiment of the present application. The configuration device 800 shown in FIG8 includes a sending unit 810 .

[0356] Sending unit 810 is used to send first indication information to the first device, where the first indication information is used to indicate the user type of the first client in the first device; and / or, to send second indication information to the cloud platform, where the second indication information is used to indicate the user type of the first client, wherein the user type of the first client is a long-term user, and the first client is used to communicate with the cloud platform.

[0357] In a possible implementation, the first device includes a function cluster, where the function cluster is used to indicate commands supported by the first client; and / or the function cluster is used to record clients in the first device whose user type is a long-term user.

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

[0359] In one possible implementation, the functional cluster includes one or more of the following commands: a first request for instructing the startup of the first client; a second request for instructing the first 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 first client; and a response command to the third request, wherein the response command to the third request is used to request a certificate for authentication of the first client from the cloud platform.

[0360] In a possible implementation, if the functional cluster includes the first request, the first request includes a startup password of the first client and / or instruction information of the cloud platform.

[0361] 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 authentication of the first client on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.

[0362] 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 a startup password of the first client.

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

[0364] In a possible implementation manner, the user type of the client in the first device includes a long-term user or a temporary user.

[0365] FIG9 is a schematic diagram of a cloud platform according to an embodiment of the present application. The cloud platform 900 shown in FIG9 includes a communication unit 910 .

[0366] The communication unit 910 is configured to communicate with a first client in a first device, where the user type of the first client is a long-term user.

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

[0368] In a possible implementation, the second indication information is carried in a client application request.

[0369] In a possible implementation, the communication unit is further configured to: receive a fourth request sent by the first device, where the fourth request is configured to request the first client to log out of the cloud platform.

[0370] In a possible implementation, the cloud platform further includes: a first processing unit, configured to log out of the first client in response to the fourth request.

[0371] In a possible implementation, the communication unit is further configured to receive a fifth request sent by the first device, where the fifth request is used by the first client to request to re-login to the cloud platform.

[0372] In one possible implementation, the communication unit is further used to receive a sixth request sent by the configuration device, where the sixth request is used to apply for a second client from the cloud platform; and the second processing unit is used to reject the sixth request if the second client is the same as the first client.

[0373] In a possible implementation manner, the user type of the client in the first device includes a long-term user or a temporary user.

[0374] FIG10 is a schematic diagram of a first device according to an embodiment of the present application, wherein the first device is configured with a first client and stores first information for the first client to log in to a cloud platform. The first device 1000 shown in FIG10 includes a sending unit 1010 .

[0375] The sending unit 1010 is configured to send a fifth request to the cloud platform based on the first information, where the fifth request is used by the first client to request to re-login to the cloud platform.

[0376] In one possible implementation, the first information includes one or more of the following information: an access token for the first client to log in to the cloud platform; a client identifier of the first client; a user identifier of the first client; and indication information of the cloud platform.

[0377] In a possible implementation, the sending unit is configured to send a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

[0378] In a possible implementation manner, the user type of the client in the first device includes a long-term user or a temporary user.

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

[0380] FIG11 is a schematic diagram of a cloud platform according to an embodiment of the present application. The cloud platform 1100 shown in FIG11 includes a receiving unit 1110 .

[0381] The receiving unit 1110 is configured to receive a fifth request sent by the first device, where the fifth request is used by the first client in the first device to request to re-login to the cloud platform.

[0382] In one possible implementation, the cloud platform stores second information for the first client to log in to the cloud platform, and the cloud platform also includes: a first processing unit, for determining whether to allow the first client to re-login based on the second information in response to the fifth request.

[0383] In one possible implementation, the second information includes one or more of the following information: an access token for the first client to log in to the cloud platform; a client identifier of the first client; a user identifier of the first client; and a user type of the first client.

[0384] In a possible implementation, the receiving unit is configured to receive a fourth request sent by the first device, where the fourth request is used to request the first client to log out of the cloud platform.

[0385] In one possible implementation, the cloud platform further includes a second processing unit, and if the user type of the first client is a long-term user, in response to the fourth request, the second processing unit is used to log out of the first client; and / or, if the user type of the first client is a temporary user, in response to the fourth request, the second processing unit is used to log out or refuse to log out of the first client.

[0386] In one possible implementation, the receiving unit is used to receive a sixth request sent by the configuration device, and the sixth request is used to apply for a second client from the cloud platform; if the second client is the same as the first client, the third processing unit is used to reject the sixth request.

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

[0388] In an optional embodiment, the processing unit 710 may be the processor 1210. The first device 700 may further include a transceiver 1230 and a memory 1220, as specifically shown in FIG12 .

[0389] In an optional embodiment, the sending unit 810 may be a transceiver 1240. The configuration device 800 may further include a processor 1210 and a memory 1220, as specifically shown in FIG12 .

[0390] In an optional embodiment, the communication unit 910 may be a transceiver 1240. The cloud platform 900 may further include a processor 1210 and a memory 1220, as specifically shown in FIG12 .

[0391] In an optional embodiment, the sending unit 1010 may be a transceiver 1240. The first device 1000 may further include a processor 1210 and a memory 1220, as specifically shown in FIG12 .

[0392] In an optional embodiment, the receiving unit 1110 may be a transceiver 1240. The cloud platform 1100 may further include a processor 1210 and a memory 1220, as specifically shown in FIG12 .

[0393] Figure 12 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 12 indicate that the unit or module is optional. The device 1200 may be used to implement the method described in the above method embodiment. The device 1200 may be a chip, a terminal device, or a network device.

[0394] The device 1200 may include one or more processors 1210. The processor 1210 may support the device 1200 to implement the method described in the above method embodiment. The processor 1210 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.

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

[0396] The apparatus 1200 may further include a transceiver 1230. The processor 1210 may communicate with other devices or chips via the transceiver 1230. For example, the processor 1210 may transmit and receive data with other devices or chips via the transceiver 1230.

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

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

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

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

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

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

[0403] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

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

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

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

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

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

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

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

[0411] 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)).

[0412] 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 communication method, characterized in that: include: A first client in the first device communicates with the cloud platform, and the user type of the first client is a long-term user.

2. The method according to claim 1, wherein The method further comprises: The first device receives first indication information sent by a configuration device, where the first indication information is used to indicate a user type of the first client.

3. The method according to claim 1 or 2, wherein: The first device includes a function cluster, and the function cluster is used to indicate commands supported by the first client; and / or The function cluster is used to record clients whose user type is a long-term user in the first device.

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

5. The method according to claim 4, wherein The function cluster includes one or more of the following commands: A first request for instructing to start the first client; A second request for instructing the first 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 first client; and 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 first client.

6. The method according to claim 5, wherein If the functional cluster includes the first request, the first request includes the startup password of the first client and / or instruction information of the cloud platform.

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

8. The method according to claim 5, 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 first client.

9. The method according to any one of claims 1 to 8, wherein The method further comprises: The first device sends a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

10. The method according to any one of claims 1 to 9, wherein The method further comprises: The first device sends a fifth request to the cloud platform, where the fifth request is used by the first client to request to re-login to the cloud platform.

11. The method according to any one of claims 1 to 10, wherein The user type of the first client is configured by the user through a configuration device.

12. The method according to any one of claims 1 to 11, wherein The user type of the client in the first device includes a long-term user or a temporary user.

13. A communication method, characterized in that: include: The configuration device sends first indication information to the first device, where the first indication information is used to indicate a user type of the first client in the first device; and / or The configuration device sends second indication information to the cloud platform, where the second indication information is used to indicate the user type of the first client. The user type of the first client is a long-term user, and the first client is used to communicate with the cloud platform.

14. The method according to claim 13, wherein The first device includes a function cluster, and the function cluster is used to indicate commands supported by the first client; and / or The function cluster is used to record clients whose user type is a long-term user in the first device.

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

16. The method according to claim 14 or 15, characterized in that The function cluster includes one or more of the following commands: A first request for instructing to start the first client; A second request for instructing the first 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 first client; and 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 first client.

17. The method according to claim 16, wherein If the functional cluster includes the first request, the first request includes the startup password of the first client and / or instruction information of the cloud platform.

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

19. The method according to claim 16, 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 first client.

20. The method according to any one of claims 13 to 19, wherein The user type of the first client is configured by the user through the configuration device.

21. The method according to any one of claims 13 to 20, wherein: The user type of the client in the first device includes a long-term user or a temporary user.

22. A communication method, characterized in that: include: The cloud platform communicates with a first client in a first device, where the user type of the first client is a long-term user.

23. The method according to claim 22, 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 indicate a user type of the first client.

24. The method according to claim 23, wherein The second indication information is carried in the client application request.

25. The method according to any one of claims 22 to 24, wherein The method further comprises: The cloud platform receives a fourth request sent by the first device, where the fourth request is used to request the first client to log out of the cloud platform.

26. The method of claim 25, wherein: The method further comprises: In response to the fourth request, the cloud platform logs out of the first client.

27. The method according to any one of claims 22 to 26, wherein The method further comprises: The cloud platform receives a fifth request sent by the first device, where the fifth request is used by the first client to request to re-login to the cloud platform.

28. The method according to any one of claims 22 to 27, wherein The method further comprises: The cloud platform receives a sixth request sent by the configuration device, where the sixth request is used to apply for a second client from the cloud platform; If the second client is the same as the first client, the cloud platform rejects the sixth request.

29. The method according to any one of claims 22 to 28, wherein The user type of the client in the first device includes a long-term user or a temporary user.

30. A communication method, characterized in that: The first device is configured with a first client and stores first information for the first client to log in to the cloud platform. The method includes: The first device sends a fifth request to the cloud platform based on the first information, where the fifth request is used by the first client to request to re-login to the cloud platform.

31. The method of claim 30, wherein: The first information includes one or more of the following information: An access token for the first client to log in to the cloud platform; a client identifier of the first client; The user identification of the first client; and Indication information of the cloud platform.

32. The method according to claim 30 or 31, wherein The method further comprises: The first device sends a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

33. The method according to any one of claims 30 to 32, wherein The user type of the client in the first device includes a long-term user or a temporary user.

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

35. A communication method, characterized in that: include: The cloud platform receives a fifth request sent by the first device, where the fifth request is used by the first client in the first device to request to re-login to the cloud platform.

36. The method of claim 35, wherein: The cloud platform stores second information used by the first client to log in to the cloud platform, and the method further includes: In response to the fifth request, the cloud platform determines whether to allow the first client to log in again based on the second information.

37. The method of claim 36, wherein: The second information includes one or more of the following information: An access token for the first client to log in to the cloud platform; a client identifier of the first client; The user identification of the first client; and The user type of the first client.

38. The method according to any one of claims 35 to 37, wherein The method further comprises: The cloud platform receives a fourth request sent by the first device, where the fourth request is used to request the first client to log out of the cloud platform.

39. The method of claim 38, wherein The method further comprises: If the user type of the first client is a long-term user, in response to the fourth request, the cloud platform logs out the first client; and / or If the user type of the first client is a temporary user, in response to the fourth request, the cloud platform logs out or refuses to log out the first client.

40. The method according to any one of claims 35 to 39, wherein The method further comprises: The cloud platform receives a sixth request sent by the configuration device, where the sixth request is used to apply for a second client from the cloud platform; If the second client is the same as the first client, the cloud platform rejects the sixth request.

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

42. A first device, characterized in that include: The processing unit is configured to communicate with the cloud platform via a first client, where the user type of the first client is a long-term user.

43. The first device according to claim 42, wherein The first device further includes: A receiving unit is configured to receive first indication information sent by a configuration device, where the first indication information is used to indicate a user type of the first client.

44. The first device according to claim 42 or 43, characterized in that The first device includes a function cluster, and the function cluster is used to indicate commands supported by the first client; and / or The function cluster is used to record clients whose user type is a long-term user in the first device.

45. The first device according to claim 44, characterized in that The function cluster is used to indicate one or more of the following information of the first client: a client identifier of the first client; The user identification of the first client; and Indication information of the cloud platform.

46. ​​The first device according to claim 45, characterized in that The function cluster includes one or more of the following commands: A first request for instructing to start the first client; A second request for instructing the first 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 first client; and 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 first client.

47. The first device according to claim 46, wherein If the functional cluster includes the first request, the first request includes the startup password of the first client and / or instruction information of the cloud platform.

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

49. The first device according to claim 46, 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 first client.

50. The first device according to any one of claims 42 to 49, characterized in that The first device further includes: The first sending unit is used to send a fourth request to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

51. The first device according to any one of claims 42 to 50, characterized in that The first device further includes: The second sending unit is used to send a fifth request to the cloud platform, where the fifth request is used by the first client to request to re-login to the cloud platform.

52. The first device according to any one of claims 42 to 51, characterized in that The user type of the first client is configured by the user through a configuration device.

53. The first device according to any one of claims 42 to 52, characterized in that The user type of the client in the first device includes a long-term user or a temporary user.

54. A configuration device, characterized in that include: a sending unit, configured to send first indication information to a first device, where the first indication information is used to indicate a user type of a first client in the first device; and / or Sending second indication information to the cloud platform, where the second indication information is used to indicate the user type of the first client, The user type of the first client is a long-term user, and the first client is used to communicate with the cloud platform.

55. The configuration device of claim 54, wherein: The first device includes a function cluster, and the function cluster is used to indicate commands supported by the first client; and / or The function cluster is used to record clients whose user type is a long-term user in the first device.

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

57. The configuration device according to claim 55 or 56, characterized in that The function cluster includes one or more of the following commands: A first request for instructing to start the first client; A second request for instructing the first 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 first client; and 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 first client.

58. The configuration device of claim 57, wherein: If the functional cluster includes the first request, the first request includes the startup password of the first client and / or instruction information of the cloud platform.

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

60. The configuration device of claim 57, 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 first client.

61. The configuration device according to any one of claims 54 to 60, characterized in that The user type of the first client is configured by the user through the configuration device.

62. The configuration device according to any one of claims 54 to 61, characterized in that The user type of the client in the first device includes a long-term user or a temporary user.

63. A cloud platform, characterized in that include: The communication unit is configured to communicate with a first client in a first device, where the user type of the first client is a long-term user.

64. The cloud platform according to claim 63, wherein: The communication unit is further configured to: Second indication information sent by a configuration device is received, where the second indication information is used to indicate a user type of the first client.

65. The cloud platform according to claim 64, wherein: The second indication information is carried in the client application request.

66. The cloud platform according to any one of claims 63 to 65, wherein: The communication unit is further configured to: A fourth request sent by the first device is received, where the fourth request is used to request the first client to log out of the cloud platform.

67. The cloud platform according to claim 66, wherein: The cloud platform also includes: The first processing unit is configured to log out of the first client in response to the fourth request.

68. The cloud platform according to any one of claims 63 to 67, wherein: The communication unit is further configured to: A fifth request sent by the first device is received, where the fifth request is used by the first client to request to re-login to the cloud platform.

69. The cloud platform according to any one of claims 63 to 68, wherein: The communication unit is further configured to receive a sixth request sent by the configuration device, wherein the sixth request is used to apply for a second client from the cloud platform; The second processing unit is configured to reject the sixth request if the second client is the same as the first client.

70. The cloud platform according to any one of claims 63 to 69, wherein: The user type of the client in the first device includes a long-term user or a temporary user.

71. A first device, characterized in that The first device is configured with a first client and stores first information for the first client to log in to the cloud platform. The first device includes: A sending unit is used to send a fifth request to the cloud platform based on the first information, where the fifth request is used by the first client to request to re-login to the cloud platform.

72. The first device according to claim 71, wherein The first information includes one or more of the following information: An access token for the first client to log in to the cloud platform; a client identifier of the first client; The user identification of the first client; and Indication information of the cloud platform.

73. The first device according to claim 71 or 72, characterized in that The sending unit is configured to: A fourth request is sent to the cloud platform, where the fourth request is used to request the first client to log out of the cloud platform.

74. The first device according to any one of claims 71 to 73, characterized in that The user type of the client in the first device includes a long-term user or a temporary user.

75. The first device according to any one of claims 71 to 74, characterized in that The user type of the first client is a long-term user.

76. A cloud platform, characterized in that include: The receiving unit is used to receive a fifth request sent by the first device, where the fifth request is used by the first client in the first device to request to re-login to the cloud platform.

77. The cloud platform according to claim 76, wherein: The cloud platform stores second information used by the first client to log in to the cloud platform, and the cloud platform further includes: The first processing unit is configured to determine, in response to the fifth request, whether to allow the first client to re-login based on the second information.

78. The cloud platform according to claim 77, wherein: The second information includes one or more of the following information: An access token for the first client to log in to the cloud platform; a client identifier of the first client; The user identification of the first client; and The user type of the first client.

79. The cloud platform according to any one of claims 76 to 78, wherein: The receiving unit is configured to: A fourth request sent by the first device is received, where the fourth request is used to request the first client to log out of the cloud platform.

80. The cloud platform according to claim 79, wherein: The cloud platform further includes a second processing unit, If the user type of the first client is a long-term user, in response to the fourth request, the second processing unit is configured to log out of the first client; and / or If the user type of the first client is a temporary user, in response to the fourth request, the second processing unit is configured to log out or refuse to log out of the first client.

81. The cloud platform according to any one of claims 76 to 80, wherein: The receiving unit is configured to receive a sixth request sent by the configuration device, wherein the sixth request is used to apply for a second client from the cloud platform; If the second client is the same as the first client, the third processing unit is configured to reject the sixth request.

82. The cloud platform according to any one of claims 76 to 81, wherein: The user type of the first client is a long-term user.

83. 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 as described in any one of claims 1-12 and 30-34.

84. 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-29 and 35-41.

85. A configuration 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 configuration device executes the method according to any one of claims 13 to 21.

86. 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 41.

87. 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 41.

88. 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 41.

89. 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 41.

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

Images