WO2024050753A1 - 通信方法、第一设备、配置设备以及云平台 - Google Patents

通信方法、第一设备、配置设备以及云平台 Download PDF

Info

Publication number
WO2024050753A1
WO2024050753A1 PCT/CN2022/117779 CN2022117779W WO2024050753A1 WO 2024050753 A1 WO2024050753 A1 WO 2024050753A1 CN 2022117779 W CN2022117779 W CN 2022117779W WO 2024050753 A1 WO2024050753 A1 WO 2024050753A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
request
cloud platform
user
information
Prior art date
Application number
PCT/CN2022/117779
Other languages
English (en)
French (fr)
Inventor
茹昭
吕小强
包永明
张军
杨宁
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2022/117779 priority Critical patent/WO2024050753A1/zh
Publication of WO2024050753A1 publication Critical patent/WO2024050753A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

Definitions

  • 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.
  • the interaction process between the client and the cloud platform is designed based on the scenario where 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.
  • This application provides a communication method, a first device, a configuration device and a cloud platform. Each aspect involved in this application is introduced below.
  • a communication method including: a first client in a first device communicating with a cloud platform, and the user type of the first client is a long-term user.
  • a communication method including: configuring a device 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, the configuration device sends second indication information to the cloud platform, 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 The first client is used to communicate with the cloud platform.
  • a communication method including: the cloud platform communicates with a first client in a first device, and the user type of the first client is a long-term user.
  • a communication method is provided.
  • a 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 is based on The first information sends a fifth request to the cloud platform, and the fifth request is used by the first client to request to log in to the cloud platform again.
  • a communication method including: the cloud platform receiving a fifth request sent by a first device, the fifth request being used by the first client in the first device to request to log in to the cloud platform again.
  • a first device including: a processing unit configured to communicate with the cloud platform through a first client, where the user type of the first client is a long-term user.
  • a configuration device including: 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, send second indication information to the cloud platform, 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 third A client is used to communicate with the cloud platform.
  • a cloud platform including: a communication unit configured to communicate with a first client in a first device, where the user type of the first client is a long-term user.
  • a first device configured with a first client and stores first information for the first client to log in to the cloud platform.
  • the first device includes: sending A unit configured to send a fifth request to the cloud platform based on the first information, where the fifth request is used for the first client to request to log in to the cloud platform again.
  • a cloud platform including: a receiving unit configured to receive a fifth request sent by a first device, where the fifth request is used for the first client in the first device to request to re-log in to the client.
  • a receiving unit configured to receive a fifth request sent by a first device, where the fifth request is used for the first client in the first device to request to re-log in to the client.
  • a first device including a processor, a memory, and a communication interface.
  • the memory is used to store one or more computer programs.
  • the processor is used to call the computer program in the memory, so that the The first device performs some or all of the steps in the methods of the above aspects.
  • a configuration device including a processor, a memory, and a transceiver, 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 Configure the device to perform some or all of the steps in the method described above.
  • a cloud platform including a processor, a memory, and a transceiver.
  • the memory is used to store one or more computer programs.
  • the processor is used to call the computer program in the memory, so that the The cloud platform performs some or all of the steps in each of the above aspects.
  • embodiments of the present application provide a communication system, which includes one or more of the above-mentioned first device, configuration device, and cloud platform.
  • the system may also include other devices that interact with the first device, the configuration device, or the cloud platform in the solution provided by the embodiments of this application.
  • embodiments of the present application provide a computer-readable storage medium that stores a computer program, and the computer program enables a communication device (for example, a first device, a configuration device or a cloud platform ) performs some or all of the steps in the methods of each aspect described above.
  • a communication device for example, a first device, a configuration device or a cloud platform
  • embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause the communication device ( For example, the first device, the configuration device or the cloud platform) performs some or all of the steps in the methods of the above aspects.
  • the computer program product can be a software installation package.
  • embodiments of the present application provide a chip, which includes a memory and a processor.
  • the processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects. .
  • 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 traditional solution that only involves temporary users.
  • Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application.
  • Figure 2 is a model structure of a Matter device applicable to the embodiment of this application.
  • Figure 3 is a flow chart for connecting the client to the cloud platform.
  • Figure 4 is a flow chart of the communication method according to the embodiment of the present application.
  • 5(a) to 5(c) are schematic flow charts of the communication method according to the embodiment of the present application.
  • Figures 6(a) to 6(c) are schematic flow charts of a communication method according to another embodiment of the present application.
  • Figure 7 is a schematic diagram of the first device according to the embodiment of the present application.
  • Figure 8 is a schematic diagram of a configuration device according to an embodiment of the present application.
  • Figure 9 is a schematic diagram of the cloud platform according to the embodiment of the present application.
  • Figure 10 is a schematic diagram of the first device according to the embodiment of the present application.
  • Figure 11 is a schematic diagram of the cloud platform according to the embodiment of the present application.
  • Figure 12 is a schematic structural diagram of a communication device according to an embodiment of the present application.
  • Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application.
  • the system 100 shown in Figure 1 may include a first device 110, a configuration device (mediator) 120, a cloud platform 130 and a second device 140.
  • the first device 110 may be a device capable of communicating with the cloud platform 130 .
  • the first device 110 may be provided with a client, and the client may be used to communicate with the cloud platform 130 and communicate with the second device 140 through the cloud platform 130 .
  • the user can access the cloud platform 130 through the client and access the second device 140 through the cloud platform 130 .
  • the user can access the cloud platform 130 through the client and control the second device 140 through the cloud platform 130 .
  • the above-mentioned client may be an application (application, APP) or an applet, etc.
  • the second device 140 may be a device capable of communicating with the cloud platform 130 .
  • the second device 140 can provide service functions for users. Therefore, the second device 140 can also be called a server (server) or a service device.
  • the configuration device 120 is used to configure the first device 110 and/or the second device 140 .
  • the configuration device 120 may configure the first device 110 and/or the second device 140 to communicate with the cloud platform 130 .
  • the configuration device 120 can configure the client in the first device 110 so that the client can communicate with the cloud platform 130 .
  • the configuration device 120 may be an application (application, APP) or applet.
  • the configuration device 120 can be installed on a terminal device, where the terminal device can be a mobile phone, a tablet computer (Pad), a notebook computer, a handheld computer, a mobile internet device (mobile internet device, MID), a wearable Equipment, virtual reality (VR) equipment, augmented reality (AR) equipment, wireless terminals in industrial control, wireless terminals in self-driving, remote surgery (remote medical) Wireless terminals in surgery, wireless terminals in smart grid, wireless terminals in transportation safety, wireless terminals in smart city, and wireless terminals in smart home wait.
  • the embodiments of the present application do not limit this.
  • Cloud platform 130 also known as cloud computing platform or “cloud” can be understood as providing network communication capabilities for services based on hardware resources and software resources. Therefore, in this embodiment of the present application, the client in the first device 110 can access or control the second device 140 through the cloud platform 130 .
  • the cloud platform 130 can be built based on one or more cloud servers to provide network functions.
  • the above-mentioned cloud platform 130 can also be other systems or devices that can provide network functions.
  • a cluster system that can provide network functions, etc.
  • the embodiments of the present application do not limit this.
  • configuration device 120 may be an APP or applet that matches the client.
  • configuration device 230 may be a different APP or applet from the client. The embodiments of the present application do not limit this.
  • the above-mentioned system 100 may be, for example, an Internet of Things (IoT) system.
  • IoT Internet of Things
  • the Internet of Things is the "Internet where everything is connected", which can be understood as a network that is extended and expanded based on the Internet. Any item can be connected to the Internet through various information sensing devices (such as radio frequency identification, global positioning systems, etc.) Together they form a huge network for information exchange and communication to achieve interconnection between all things.
  • the above-mentioned first device and/or second device may be an IoT device.
  • IoT devices can include vehicle terminals, smart home equipment, intelligent monitoring equipment, etc.
  • Smart home devices may include, for example, smart air conditioners, smart refrigerators, washing machines, rice cookers, sweeping robots, and other devices.
  • Intelligent monitoring devices may include, for example, surveillance cameras, temperature sensors, sound sensors and other devices.
  • the above-mentioned cloud platform may be an IoT cloud platform, referred to as "IOT cloud", which is used to provide communication service functions for IOT devices in the IOT system.
  • IOT cloud an IoT cloud platform
  • the system 100 is introduced taking an IoT device as an example.
  • the first device 110 is a vehicle-mounted terminal
  • the second device 140 is a smart home device
  • the configuration device 120 can be a terminal device.
  • 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 .
  • the user can access and/control the smart home devices on the cloud platform (or smart home devices connected to the cloud platform) through the client.
  • a client that can access and/or control smart home devices can also be called a "smart home client".
  • the client can control the switch of the smart air conditioner and set the air conditioner temperature, wind speed, etc. through the cloud platform.
  • the client can control the sweeping robot to start or stop working, control the working mode of the sweeping robot, etc. through the cloud platform.
  • the Connectivity Standards Alliance launched an Internet of Things application layer technology standard—Matter Standard Protocol, which can provide an interoperable application layer for smart home devices based on Internet Protocol (Internet Protocol, IP) solution.
  • IP Internet Protocol
  • the matter standard may also be called a connected home over IP (CHIP) standard.
  • the Matter standard can support three underlying communication protocols: Ethernet, Wi-Fi, and Thread, and can allow IoT devices with different protocols to communicate with each other.
  • the client introduced above supports the Matter protocol, it can be called a "Matter client”.
  • the above-mentioned second device supports the Matter protocol, it can be called a “Matter server”.
  • the first device and/or the second device supporting the Matter protocol may also be called “Matter devices”.
  • Figure 2 is a model structure of a Matter device applicable to the embodiment of this application.
  • the data model structure 200 of the Matter device includes a node 210, an endpoint 220, and a cluster 230.
  • Node 210 encapsulates an addressable and unique resource on the network, has a set of functions and capabilities, and the user can clearly view it as a functional whole.
  • node 210 may be the highest or outermost first-order element in the data model. In other words, node 210 is the only addressable element in the outermost layer of the data model.
  • one physical entity can support multiple nodes 210 .
  • a node can have multiple node IDs, and the scope of each node ID is a specific network (fabric). For example, when a node ID is used as the target address for an interaction, the network within the scope of the specified node ID is the access network for the interaction.
  • a node may include one or more endpoints 220. Endpoint 220 is an instance, which can be a service or a virtual device, as indicated by the device type. Each endpoint 220 conforms to one or more device type definitions that define the clusters supported on the endpoint. Whereas a cluster is an object class instantiated on an endpoint.
  • a device type defines a consistent set of endpoints 220.
  • a device type defines a set of requirements for a node 210 or endpoint 220.
  • Clusters 230 are functional building block elements of the data model, and thus clusters may also be referred to as “functional sets”, “functional clusters", “functional clusters”, etc.
  • the cluster specification defines clients and servers that interact with each other.
  • Cluster 230 can be viewed as an interface, service or object class, which is the lowest independent functional element in the data model.
  • Each cluster 230 is defined by a cluster specification that defines the elements of the cluster 230, including properties, events, commands, and behaviors related to interactions with these elements. Properties, events, commands, and behaviors in cluster 230 are mandatory or optional, depending on the definition of cluster 230 .
  • the above clusters can be divided into two categories: utility cluster (utility cluster) or application cluster (application cluster).
  • Utility clusters are not part of the endpoint's primary application operations. It can be used for configuration, discovery, addressing, diagnostics, monitoring device health, software updates, and more. It may have a temporary relationship with its cluster counterpart.
  • the utility cluster may include a client cluster.
  • Application clusters support the primary operations of endpoints.
  • Application clustering supports one or more persistent application interactions between clustered clients and clustered servers.
  • the client of the cluster can send control commands to the server of the cluster (i.e., switch cluster) to control the switch of the smart light.
  • a cluster command (also known as a "command") is a set of data fields, each data type, that is passed between client and server cluster instances to invoke the behavior of the command recipient.
  • each command can be listed in a table, which can contain the data quality columns of the command: identification (ID), name (name), direction (direction), response (response), access (access) ), constraint consistency. Accordingly, a command can indicate zero or more fields defined in a table. Each command field is defined as a row in the table.
  • Attributes can be understood as cluster data. Currently, the agreement stipulates that each attribute can be listed in a table, including a data quality column. Data quality columns can include ID, name, (data) type, constraints, other qualities, access, default (value), and consistency. In some implementations, properties may also define their associated semantics and behavior. Properties can reflect the device's queryable/settable status, configuration, and capabilities. In some cases, if no privileges are explicitly defined for a property, default access privileges take effect.
  • commands and attributes in the embodiments of this application may also include other quantitative qualities, or include part of the above-mentioned data qualities.
  • the embodiments of the present application do not limit this.
  • Identification represents the unique field ID of the field, or in other words, it is the unique identification of the command.
  • Name represents the unique name of the field, or in other words, the name of the command.
  • the value of the data type can be an octet string, expressed as "octstr or octstring"; the value of the data type can be a string (string); the value of the data type can be X Bit unsigned number (unsigned X-bit integer, uintX), where the value of ; Boolean value is represented as "bool”.
  • Direction usually present in the command list, is used to define the transmission direction of the command. For example, it can be defined as from client to server. For another example, it can be determined from the server to the client.
  • Access permissions are used to define how an element can be accessed (such as read or write) and what permissions are required to access the data.
  • access rights may include V, where V indicates that read access or call access requires view privileges.
  • Access permissions can also include O, which means "read access”, “write access” or “call access” require operation permissions.
  • Access permissions can also include R, which stands for read access.
  • Access permissions can also include W, which represents write access.
  • Responses usually present in a command list, are used to define the command's response.
  • Default used to define the default value. It should be noted that the default value is not the value used when the service device returns to the factory refresh settings. The default value can indicate that the consistency specified for the data field can be optional or change over time. Default values can be defined to complete the dependency when the actual data field value is not present.
  • Consistency used to define the optionality and dependencies of any data model element or set of elements.
  • this column is valid for properties, commands, events, enumerations, and fields of commands, events, or structures.
  • "M" indicates that the corresponding command is part of the basic mandatory feature set.
  • client-to-server command consistency means that the server should recognize and support client-to-server commands and generate responses as defined.
  • Server-to-client command consistency means that the server should send commands in a manner defined by cluster behavior, i.e., in response to client-to-server commands. The consistency of the command depends on the supported server features. Clients should not be required to support optional commands or commands that rely on optional features.
  • constraints can contain all and desc. Among them, all is used to define that all values are allowed in numeric data types. Desc is used to indicate that the constraints are defined in the description section. In other cases, constraints can also indicate the maximum value of the corresponding parameter value, expressed as "max N". For example, in the embodiment of this application, when N is 99, "max 99" is used to indicate that the maximum value of the corresponding parameter is 99. For another example, in the embodiment of this application, when N is 400, “max 400” is used to indicate that the maximum value of the corresponding parameter is 400. In other cases, constraints can be used to define the number of bytes occupied by parameters. For example, when the value of the constraint is 32, it is used to indicate that the number of bytes occupied by the corresponding parameter is 32.
  • Range represents the value range of the field.
  • the range can support two forms: explicit constraints and width constraints.
  • explicit constraints can indicate the minimum and maximum values corresponding to the value of a field.
  • explicit constraints indicate that the value range of a certain field is (0, 128).
  • the above width constraint can be used to constrain the number of bytes occupied by the value of a field, or in other words, the width constraint can limit the value of a field to a specific number of bytes.
  • a width constraint can indicate that the maximum number of bytes occupied by the value of a certain field is 8 bytes.
  • the client needs to establish a connection with the cloud platform based on the connection solution between the client and the platform.
  • the connection solution between the client and the platform includes the client configuration process, client registration process, client login process, etc. The following describes the client configuration process, client registration process, and client login process in conjunction with steps S311 to S327 shown in FIG. 3 .
  • step S311 the configuration device determines that the first device has the capability to support the client.
  • the configuration device can query the capabilities of the first device to determine whether the first device supports the configuration client.
  • the first device can also directly configure and report the capability of the first device, so that the configuration device can determine whether the first device supports the configuration client.
  • step S312 the configuration device pops up a dialog interface, prompting the user to choose whether to agree to use the first device to control the second device.
  • step S313 if the user agrees to use the first device to control the second device, the configuration device sends a certificate request (certificate signing request, CSR) request command to the first device.
  • a certificate request certificate signing request, CSR
  • step S314 the client generates a key pair and stores the private key in the key pair in the safe zone.
  • step S315 the client sends a CSR response command to the configuration device to transmit the CSR.
  • CSR may be a CSR data format defined in public key cryptography standards (PKCS) #10. Accordingly, CSR can follow the following principles: CSR carries certificate request information, which can include version information, subject information, public key information, etc.
  • the subject information may include the vendor ID of the first device, the product ID of the first device, etc.
  • the public key information may indicate the public key in the above-mentioned key pair (see step S340).
  • the above-mentioned supplier ID of the first device and the product ID of the first device can be obtained from the data recorded in the basic information cluster (general_Info cluster) of the first device.
  • the above-mentioned CSR can be digitally signed, and the digital signature of the CSR can be generated based on the private key in the key pair.
  • step S316 the configuration device sends information 1 to the cloud platform, where information 1 is used to apply for a cloud connection credential, that is, an access token (access token) for the client, and information 1 carries a CSR.
  • a cloud connection credential that is, an access token (access token) for the client
  • information 1 carries a CSR.
  • step S317 after the CSR verification is passed, the cloud platform can assign a client identification to the client.
  • step S318 the cloud platform generates the client's certificate based on the client ID and public key corresponding to the client.
  • step S319 the cloud platform allocates an access token to the client and establishes a binding relationship between the user ID, client ID and access token.
  • step S320 the cloud platform uses the client's public key to encrypt the access token to obtain an encrypted access token, which is represented by "CToken”.
  • step S321 the cloud platform sends information 2 to the configuration device to indicate the client's certificate and CToken.
  • the parameters contained in the above information 2 may include CToken, certificate chain (CertChain) and token expiration (TokenExpiration) information.
  • CToken certificate chain
  • CitChain certificate chain
  • TokenExpiration token expiration
  • Table 1 shows information such as the parameters included in the information 2, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.
  • step S322 the configuration device sends information 3 to the first device to configure the client's certificate, CToken, and cloud registration address for the client.
  • the configuration parameters in the above information 3 can include: client certificate (represented by "ClienCert”), intermediate certificate (represented by “IntermediateCert”), root certificate (represented by "RootCert”), cloud address of the cloud platform (cloud address) , CToken and token expiration information.
  • client certificate represented by "ClienCert”
  • intermediate certificate represented by "IntermediateCert”
  • root certificate represented by "RootCert”
  • cloud address of the cloud platform cloud address
  • CToken and token expiration information can be found in Table 2.
  • Table 2 shows the parameters included in information 3, the field where the parameter is located, the identification of the parameter, the data type of the parameter, the constraints of the parameter, the necessity of the parameter, and the description of the parameter.
  • step S323 the first device decrypts the information 3 using the private key to obtain the above parameters in the information 3. And configure the client based on the above parameters.
  • step S324 the client connects to the cloud platform based on the cloud address and uses the client certificate to establish a secure connection with the cloud platform.
  • step S325 the client sends a registration request (also called “cloud registration request” or “client registration request”) to the cloud platform.
  • a registration request also called “cloud registration request” or “client registration request”
  • the above registration request can carry the client ID and access token.
  • Table 3 shows the interface description of the registration request.
  • the hypertext transfer protocol (HTTP) method based on the registration request can be the POST method, and the interface access address of the registration request can be the account (account). .
  • HTTP hypertext transfer protocol
  • Table 4 shows the interface parameters of the registration request. Table 4 points out the position of the parameters in the registration request in the request, the name of the parameter, the value type of the parameter, whether the parameter is necessary, and the description of the parameter and other information.
  • Location parameter value type necessity illustrate body access token string yes Client access token main body Client ID string yes The client ID assigned by the cloud platform to the client.
  • step S326 the cloud platform sends a registration response command (also called “cloud registration response") to the configuration device.
  • the registration response command will carry the updated access token sent by the cloud platform.
  • the cloud platform does not need to update the client's access token.
  • Table 5 shows the parameters included in the registration response command, the location of the parameters, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.
  • 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.
  • the user 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.
  • the interaction process between the client and the cloud platform is designed based on the scenario where 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. Therefore, the embodiment of this application introduces a client for long-term users to enrich the application scenarios of the client and help improve user experience.
  • Figure 4 is a schematic flow chart of the communication method according to the embodiment of the present application.
  • the steps shown in Figure 4 include S410.
  • step S410 the first client in the first device communicates with the cloud platform.
  • the user type of the first client is a long-term user, or in other words, the first client may be a long-term client.
  • the first device as a vehicle as an example
  • the long-term user corresponding to the first client may be the owner of the vehicle.
  • the first device may also be configured with a client of a temporary user (also called a "temporary client").
  • a client of a temporary user also called a "temporary client”
  • the temporary user can be a temporary passenger of the vehicle.
  • the operations performed by the first device on such clients may not be the same as those performed on temporary clients. Therefore, the first device needs to know the user type of the client. Therefore, the embodiment of this application also provides a configuration solution for the user type of the client.
  • the user type of the client can be informed by the configuration device to the first 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.
  • the first indication information may be used to indicate whether the user type of the first client is a long-term user.
  • the first indication information may be carried in a CSR request command (also called the third request).
  • the parameters of the CSR request command in the embodiment of the present application are introduced below in conjunction with Table 6.
  • the CSR request can carry the parameter long-term user (ie, the first indication information) to indicate the user type of the client.
  • the identifier of the long-term user field can be 0, and the data type of this field can be a Boolean value.
  • the Boolean value is true (true)
  • the Boolean value is false, it is used to indicate that the client's user type is a temporary user.
  • first instruction information can also be carried in other commands except the CSR request command, or the first instruction information can also be carried in a dedicated command, which is not limited in the embodiments of the present application.
  • the first device may send a CSR response command (also called a "response command for the third request") to the configuration device, where the CSR response command carries the client's CSR.
  • Table 7 shows the parameters of the CSR response command in this embodiment of the present application. See Table 7.
  • the CSR request can carry the parameter CSR.
  • Table 7 also shows the identifier corresponding to the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter, and the necessity of the parameter.
  • the embodiment of this application also provides a configuration solution for the user type of the client.
  • the user type of the client can be informed to the cloud platform by the configuration device, that is, the configuration device sends second indication information to the cloud platform, and the second indication information is used to indicate the user type of the first client.
  • the second indication information is used to indicate the user type of the first client.
  • the second indication information may be used to indicate whether the user type of the first client is a long-term user.
  • the above-mentioned second instruction information may be carried in a client application request (also called an "application request"), where the client application request is used to apply for the client's certificate and token from the cloud platform.
  • client application request also called an "application request”
  • the client application interface description and the parameters in the client application request according to the embodiment of the present application in conjunction with Table 8 and Table 9. Refer to Table 8.
  • the HTTP method used by the client to apply for the interface is POST, and the interface access address is "/addclient".
  • Table 9 shows the parameters carried in the client application request command.
  • the application request command may include acceptance, Internet media type (content-type), access token, CSR, and long-term user.
  • Table 9 also shows the location, value type, necessity and description of the parameters.
  • the cloud platform can send the client's certificate to the configuration device through a client application response command for the client application request.
  • the above certificate can be indicated by the parameter "CertChain” in the client application response command.
  • the above certificate may include one or more of a client certificate (represented by "ClienCert”), an intermediate certificate (represented by "IntermediateCert”), and a root certificate (represented by "RootCert”).
  • the user type of the client may be configured by the user through the configuration device. That is to say, the user can select the user type of the client as a long-term user or a temporary customer by configuring the device.
  • the user can select the user type of the client as a long-term user or a temporary customer by configuring the device.
  • other methods can also be used to help the configuration device determine the user type of the client, and the embodiment of the present application does not limit this.
  • 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.
  • the above describes the user type of the first client and the configuration process of the user type of the first client.
  • the following describes the login and logout process between the client and the cloud platform.
  • the traditional interaction solutions between the client and the cloud platform are 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 out. After the client logs out from the cloud platform, the cloud platform and the first device will delete the client's information accordingly (for example, the client identification, the client's user identification, 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 through the client again, he can only re-establish the connection between the client and the cloud platform according to the method shown in Figure 3.
  • the client's information for example, the client identification, the client's user identification, the client's corresponding cloud platform indication information, the client's access token, etc.
  • this method of disconnecting the connection between the cloud platform and the client by logging out when applied to scenarios where long-term users use the client, may cause long-term users to Every time the connection between the client and the cloud platform is disconnected, the connection between the client and the cloud platform needs to be re-established.
  • the operation of establishing the connection is too complicated and reduces the user experience.
  • the client of a long-term user can disconnect from the cloud platform by logging out.
  • the cloud platform and the first device will not delete the information used for the client to log in to the cloud platform (also known as "first information").
  • first information also known as "first information”.
  • long-term users need to log in to the cloud platform through the client again, they can Reusing the first information to establish a connection between the client and the cloud platform helps reduce client configuration-related operations and improve user experience.
  • the first device may send a fourth request to the cloud platform, and the fourth request is used to request the first client to log out of the cloud platform. Therefore, the fourth request can also be called a "logout request”.
  • the above method further 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 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.
  • the client of the temporary user can also disconnect from the cloud platform by logging out, which is not limited in the embodiment of the present application.
  • 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 log in to the cloud platform again.
  • the above-mentioned first information may include one or more of the following information: an access token used by the first client to log in to the cloud platform; a client identification of the first client; a user identification of the first client; and indication information of the cloud platform. .
  • an access token used by the first client to log in to the cloud platform a client identification of the first client
  • a user identification of the first client a user identification of the first client
  • indication information of the cloud platform may include one or more of the following information: an access token used by the first client to log in to the cloud platform; a client identification of the first client; a user identification of the first client; and indication information of the cloud platform.
  • 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 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 log in again based on the second information.
  • the cloud platform may also directly allow the first client to log in to the cloud platform, which is not limited in the embodiment of the present application.
  • the above-mentioned second information may include one or more of the following information: an access token used by the first client to log in to the cloud platform; a client identification of the first client; a user identification of the first client; and the user type of the first client.
  • the first information includes an access token, a client identification, and a user identification
  • the second information includes an access token, a client identification, a user identification, and a user type. If the access token in the first information , client ID and user ID match the access token, client ID and user ID in the second information, and the user type of the first client in the second information is a long-term user, then the cloud platform can allow the first The client logs in to the cloud platform again.
  • the cloud platform may refuse The first client logs in to the cloud platform again.
  • the cloud platform can refuse the first client to log in to the cloud platform again.
  • the above-mentioned fourth request and fifth request may adopt the same command format.
  • the fourth request and the fifth request in the embodiment of the present application are introduced below in conjunction with Table 10 and Table 11.
  • the login/logout interface description and command format of the embodiment of the present application are shown below in conjunction with Table 10 and Table 11.
  • the HTTP method of the login/logout interface can be POST, and the access address of the login/logout interface can be expressed as "/session”.
  • the command may include accept, Internet media type (content-type), access token, user ID, client ID, and login status (login), where the login status indicates login.
  • the command format It is the command format of the login request (i.e. the fifth request).
  • the command format is the command format of the logout request (ie, the fourth request).
  • the position of each parameter in the command, the value type of the parameter, the necessity of the parameter, and the description of the parameter can continue to be shown in Table 11.
  • 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.
  • the cloud platform can only maintain a unique client.
  • the cloud platform can reject the client's application. That is to say, the above method also includes: configuring the device to send a sixth request to the cloud platform.
  • the sixth request is used to apply for a second client to the cloud platform; if the second client is the same as the first client, the cloud platform rejects the sixth request. ask.
  • the user type of the second client may be a temporary user or a long-term user, which is not limited in this embodiment of the present application.
  • multiple identical clients can also be maintained on the cloud platform, which is not limited in the embodiment of the present application.
  • the above-mentioned information of the first client may be maintained as an attribute of the functional cluster. That is to say, the first device may include a function cluster (also called a "client function cluster"), and the function cluster is used to record the client in the first device. Generally, for information about clients of long-term users, the first device may be recorded in the functional cluster, and for information about clients of temporary users, the first device may not be recorded in the functional cluster.
  • a function cluster also called a "client function cluster”
  • the function cluster is used to record the client in the first device.
  • the first device may be recorded in the functional cluster, and for information about clients of temporary users, the first device may not be recorded in the functional cluster.
  • the information of the first client may include one or more of the following information: a client identification of the first client; a user identification of the first client; and indication information of the cloud platform.
  • the client identifier of the first client is used to identify the first client.
  • the user ID of the first client may be used to identify the user of the first client.
  • the above indication information of the cloud platform may be any information used to identify the cloud platform, which is not limited in the embodiments of the present application.
  • the indication information of the cloud platform may be the identification of the cloud platform (cloud ID).
  • the indication information of the cloud platform may be the address of the cloud platform.
  • the functional cluster can include attributes: long-term user list (or long-term client list), the constraint of this attribute can be "all”, the quality of this attribute can be "N”, and the permission of this attribute can be " R”, the default value of this attribute can be "empty”, the necessity of this attribute can be "M”, the data type of this attribute can be a list, and the client structure (represented as "ClientStruct” is recorded in the list ").
  • the client information recorded in the client structure can be as shown in Table 13, including client identification, user identification and cloud address.
  • Table 13 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the authority of the parameter, the default value of the parameter and the necessity of the parameter.
  • the configuration device can query the first device through the function cluster whether there is a suitable client (for example, the client corresponding to the cloud platform where the configuration device is located). If it is determined that the first device is configured with a suitable client , then the configuration device can determine that a suitable client has been configured in the first device.
  • a suitable client for example, the client corresponding to the cloud platform where the configuration device is located.
  • the configuration device can determine that the first device has been configured with a client connected to the cloud platform.
  • the information of the client in the first device can be maintained through the functional cluster.
  • the commands supported by the client for example, the command for configuring the client and/or the command for starting the client
  • the above functional cluster also includes commands supported by the client.
  • the commands included in the above functional cluster may be supported by the long-term client and/or the temporary client. This is not limited in the embodiment of the present application.
  • the commands supported by the first client will be introduced below as an example.
  • the above 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 for the first request; and a command for instructing the client to add the cloud platform.
  • the above-mentioned first request is used to request the first device to start the first client (also called the “client to be started”). Therefore, the first request can also be called a “start client request” (start client request).
  • the first request may indicate the client to be activated by carrying indication information of the client to be activated.
  • the indication information may be, for example, a client identifier.
  • the above response command to the first request is used to indicate whether the first client is successfully started.
  • the first client in order to improve the security of starting the client, can be started based on the startup password, where the startup password is used to verify whether to start the first client, or in other words, the startup password is used to verify whether to start the first client.
  • the client user authenticates, or the startup password is used to authenticate the configured device. If the startup password is used to authenticate the configuration device, the startup password can also be called the configuration device password (mediator password, MedPassword).
  • the first request may carry the activation password of the first client.
  • the startup password carried in the first request matches the startup password of the first client prestored in the first device, the first client can be started.
  • the startup password carried in the first request does not match the startup password of the first client prestored in the first device, the first client may be refused to be started.
  • the above matching can be understood as the startup password carried in the first request is the same as the prestored startup password of the first client, or the startup password carried in the first request is different from the prestored startup password of the first client. Satisfy the preset corresponding relationship.
  • the above-mentioned mismatch can be understood as the startup password carried in the first request is different from the prestored startup password of the first client, or the startup password carried in the first request is different from the prestored startup password of the first client and The preset correspondence is not satisfied.
  • the first client can inform the configuration device of the startup password of the first client, so that when the configuration device starts the first client through the first request, the first client can carry the startup password in the first request.
  • the first client can carry the above-mentioned startup password through the add cloud response command (also known as the "response command for the second request").
  • Table 14 shows the parameters carried in the add cloud response command in the embodiment of the present application.
  • the add cloud response command may include: status code (status code) and startup password, where the status code is used to indicate the first Whether the client successfully added the cloud platform.
  • 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.
  • the first request to be started may be carried in the first request. Instruction information of the cloud platform corresponding to the client, 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 identifier corresponding to the first client to be started, and no longer carry the indication information of the cloud platform. .
  • the first request may only carry the unique identifier corresponding to the first client to be started, and no longer carry the indication information of the cloud platform.
  • different first clients in the first device may also carry indication information of the cloud platform, which is not limited in the embodiments of the present application.
  • the parameters in the first request may include the client identifier of the first client, the startup password of the first client, and the cloud address corresponding to the first client.
  • Table 15 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • the first device may determine the first client based on the client identifier in the first request. Then based on the correspondence between the pre-stored client identification of the first client and the startup password, it is determined whether the pre-stored startup password of the first client matches the startup password in the first request, and based on the pre-stored first client and the cloud The correspondence between the addresses determines whether the pre-stored cloud address of the first client matches the cloud address in the first request.
  • the above second request is also called add cloud request.
  • the second request includes one or more of the following information: certificate information for the first client to authenticate on the cloud platform, indication information of the cloud platform, and access token information of the cloud platform.
  • the response command for the second request may also be called "add cloud response command”.
  • 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.
  • the above third request may also be called a CSR request command, and accordingly, the third response command to the third request command may be called a "CSR response command".
  • the commands supported by the functional cluster in the embodiment of this application are introduced below in conjunction with 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.
  • Table 16 also shows the identification corresponding to each command, the direction of the command, the response of the command, the authority of the command, and the necessity of the command.
  • the above-mentioned information of the first client and the commands supported by the first client can also be maintained through multiple different functional clusters, which is not limited in the embodiment of the present application.
  • the parameters contained in each of the above commands will be introduced in detail below. For the sake of brevity, they will not be described again here.
  • the first client configuration process may be triggered.
  • the configuration device can read the long-term user list in the first device. If a suitable first client is not recorded in the long-term user list, the first client configuration process can be triggered.
  • the configuration device may trigger the first client configuration process.
  • the first client needs to access the cloud platform based on the access token.
  • the first client may need to access the cloud platform multiple times. If the first client uses the same access token each time to access the cloud platform, it may not be conducive to improving the security of the cloud platform. For example, if the user type of the first client is a long-term user, the user may access the cloud platform multiple times through the first client. At this time, if the access token of the first client remains unchanged, it may be intercepted by the attacker. Threaten the security of the cloud platform.
  • the cloud platform can configure the first token (also known as "refresh token") for the first client, which is used by the first client to request the cloud platform to update the access token. Card.
  • the first client can access the cloud platform based on the updated access token.
  • the above access token update mechanism helps to improve the security of the cloud platform compared to always using the same access token to access the cloud platform.
  • the first device when the original access token of the first device expires, can apply to the cloud platform for updating the access token based on the first token.
  • the embodiment of this application does not specifically limit the timing of applying for an update token.
  • the first device can also apply to the cloud platform for an update access token based on the first token when the original access token is about to expire. . That is, the first device can apply to the cloud platform for updating the access token based on the first token at the target time, where the expiration time of the target time and the original access token is less than the first time interval.
  • the first device may periodically apply to the cloud platform for updating the access token, where the update period of the access token may be less than or equal to the validity period of the access token.
  • the above-mentioned first token may be carried in the registration response command.
  • Table 17 shows the interface parameters of the registration response command in the embodiment of this application. Referring to Table 17, the registration response command may include access token, token expiration, user identification and first token. Among them, the position of the above parameters in the command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter can be found in Table 17.
  • the AMTP protocol may be used for communication between the first client and the second device.
  • the first device needs to send the access address of the first client to the cloud platform so that subsequent communication can be conducted based on the access address of the first client. That is, the above method also includes: the first device sends third information to the cloud platform, where the third information includes the access address of the first client.
  • the access address is an access address based on the AMTP protocol.
  • the cloud platform can determine that the first client selects the AMTP protocol for communication. That is to say, the third information is also used to indicate that the first client supports The communication protocol is AMTP protocol.
  • the above third information may be carried in a registration request, where the registration request is used by the first client to request registration on the cloud platform.
  • the parameters carried in the registration request in the embodiment of this application are introduced below in conjunction with Table 18.
  • the registration request may include an access token, a client identifier of the first client, and an access address of the first client (for example, the first client uniform resource locator (ClientURL)).
  • ClientURL uniform resource locator
  • 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.
  • the third information may be carried in the login request, and the login request is used by the first client to request to log in to the cloud platform.
  • the parameters carried in the login request command in the embodiment of this application are introduced below in conjunction with Table 19. Compared with the parameters shown in Table 11, the parameters in Table 19 add the first client access address (for example, ClientURL).
  • the cloud platform can inform the first device of the access address of the second device, that is, the access address of the second device based on the AMTP protocol (also known as "access address"). Enter URL"). That is to say, the above method also includes: in response to the third information, the first device receives fourth information sent by the cloud platform, where the fourth information includes the access address of the second device to be accessed.
  • the first client when the first client successfully logs in to 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.
  • the above fourth information may be carried in a response command to the registration request, that is, a registration response command.
  • Table 20 shows the parameters included in the registration response command in this embodiment of the present application.
  • the registration response command includes an access token, a user ID, and an access URL, where the access URL is used to indicate the access address of the second device.
  • 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.
  • the above fourth information may be carried in a response command to the login request, that is, a login response command.
  • Table 21 shows the parameters included in the login response command in the embodiment of this application. As shown in Table 21, the login response command includes an access token, a first client identifier, and a URL of the first client, where the access URL is used to indicate the access address of the second device. In addition, Table 21 also shows the position of the above parameters in the login response command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter.
  • the transmission method of the third information and the transmission method of the fourth information introduced above can be used alone or in combination.
  • the third information may be carried in the login request, and accordingly, the fourth information may be carried in the login response command.
  • the third information may be carried in the registration request, and accordingly, the fourth information may be carried in the registration response command.
  • the third information may be carried in the registration request, and correspondingly, the fourth information may be carried in the login response command.
  • the third information may be carried in the registration response, and correspondingly, the fourth information may be carried in the login request.
  • 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.
  • 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.
  • the cloud platform may first send the access address of the second device to the first client, and then the first client sends the access address of the first client to the cloud platform.
  • 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 sends the access address of the first client to the cloud platform through a login request.
  • the solution of the embodiment of the present application will be introduced below with reference to Figures 5 and 6, taking the IOT scenario as an example.
  • the above-mentioned cloud platform can be an IoT cloud platform
  • the client can be an IoT client
  • the first device can be a vehicle-mounted terminal
  • the second device can be a smart home device
  • the configuration device can be a mobile phone.
  • the command and information function clusters involved in Figure 5 and Figure 6 have the same meaning as the above introduction and use the same names. For the sake of brevity, please refer to the above introduction and will not go into details below.
  • FIGS 5(a) to 5(c) are schematic flow charts of the communication method according to the embodiment of the present application.
  • the method shown in Figure 5(a) includes steps S511 to S527.
  • step S511 the mobile phone establishes a secure connection with the vehicle-mounted terminal.
  • a mobile phone can establish a connection with a vehicle-mounted terminal through Bluetooth low energy (BLE) combined with the wireless network communication technology Wifi.
  • BLE Bluetooth low energy
  • step S512 the mobile phone checks the client cluster of the vehicle-mounted terminal.
  • the client cluster can be seen in the above introduction combined with Table 12, Table 13 and Table 16. For the sake of brevity, it will not be described again here.
  • step S513 the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.
  • step S513 may be located before step S512, or the two steps may be performed simultaneously, or step S512 may be located before step S513, which is not limited in the embodiment of the present application.
  • 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.
  • step S515 is executed. If the client included in the long-term user list is different from the cloud platform where the mobile phone is located, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S516 is executed.
  • step S515 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.
  • step S5166 the mobile phone prompts the user to select long-term mode or temporary mode.
  • the above long-term mode corresponds to creating a client whose user type is long-term user
  • the temporary mode can correspond to creating a client whose user type is temporary user.
  • the following description takes the client where the user chooses to create a long-term user as an example.
  • the solution below can also be applied to creating temporary users.
  • step S517 the mobile phone sends a CSR request command to the IoT client.
  • the CSR request command can carry the user type of the client.
  • CSR request command can be found in the introduction shown in Table 6 above.
  • step S5128 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 above in conjunction with Table 7.
  • 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's application request carries the client's user type.
  • step S520 the IoT cloud platform sends a client application response command to the mobile phone.
  • the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface.
  • Table 22 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.
  • Location parameter value type necessity illustrate head Internet media types String no The MIME type used by the command payload main body CToken String yes IoT client public key encrypted access token main body certificate chain String yes Certificate chain issued for IoT clients main body Token expiration information Number yes The validity period of the access token. When the value is -1, it indicates access.
  • step S521 the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.
  • Table 23 shows the parameters included in the add cloud request command in this embodiment of the present application.
  • the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information.
  • Table 23 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • step S522 the IoT client uses the private key in the key pair to decrypt the Ctoken and obtain the access token.
  • step S523 the IoT client sends an add cloud response command to the mobile phone.
  • the add cloud response command includes the client's startup password.
  • 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.
  • add cloud response commands please refer to the relevant introduction in Table 14 above.
  • step S524 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • Step S515 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S515.
  • Step S524 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S524 after reconfiguring the client.
  • step S525 the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.
  • step S526 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S527 is executed.
  • step S526 the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.
  • step S527 the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.
  • the vehicle-mounted terminal can indicate to the mobile phone the reason why the IoT client fails to start, for example, the startup password of the IoT client is wrong, the client ID of the IoT client does not exist, etc.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • 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.
  • step S532 the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.
  • the client registration request may include the client ID and access token.
  • the client registration request please refer to the introduction in Table 3 above.
  • step S533 in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.
  • 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 please refer to the introduction in Table 5 above.
  • the client login process in the embodiment of this application is introduced below with reference to Figure 5(c).
  • the method shown in Figure 5(c) includes steps S541 to S542.
  • step S541 the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.
  • the above login request includes a user ID, a client ID, and an access token. Please refer to the introduction in Table 11 above.
  • step S542 in response to the login request, the IoT cloud platform sends a login response command to the IoT client.
  • Table 24 shows a possible implementation of the login response command in the embodiment of this application.
  • the login response command may include Internet media type and token expiration information.
  • 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 the client using the AMTP protocol to communicate with smart home devices.
  • step S611 the mobile phone establishes a secure connection with the vehicle-mounted terminal.
  • step S612 the mobile phone checks the client cluster of the vehicle-mounted terminal.
  • the client cluster can be seen in the above introduction combined with Table 12, Table 13 and Table 16. For the sake of brevity, it will not be described again here.
  • step S613 the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.
  • step S613 may be located before step S612, or the two steps may be performed simultaneously, or step S612 may be located before step S613, which is not limited in the embodiment of the present application.
  • 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.
  • step S615 is executed. If the client included in the long-term user list is on a different cloud platform than the mobile phone, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S616 is executed.
  • step S615 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.
  • step S616 the mobile phone prompts the user to select long-term mode or temporary mode.
  • the above long-term mode corresponds to creating a client whose user type is long-term user
  • the temporary mode can correspond to creating a client whose user type is temporary user.
  • the following description takes the client where the user chooses to create a long-term user as an example.
  • the solution below can also be applied to creating temporary users.
  • step S617 the mobile phone sends a CSR request command to the IoT client.
  • the CSR request command can carry the user type of the client.
  • CSR request command can be found in the introduction shown in Table 16 above.
  • 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 above in conjunction with Table 17.
  • 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's application request carries the client's user type.
  • step S620 the IoT cloud platform sends a client application response command to the mobile phone.
  • the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface.
  • Table 25 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.
  • step S621 the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.
  • Table 26 shows the parameters included in the add cloud request command in this embodiment of the present application.
  • the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information.
  • Table 26 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • step S622 the IoT client decrypts the Ctoken using the private key in the key pair to obtain the access token.
  • step S623 the IoT client sends an add cloud response command to the mobile phone.
  • the add cloud response command includes the client's startup password.
  • 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.
  • add cloud response commands please refer to the relevant introduction in Table 14 above.
  • step S624 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • step S615 and step S624 can be understood as two scenarios of sending a start client request command.
  • Step S615 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S615.
  • Step S624 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S624 after reconfiguring the client.
  • step S625 the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.
  • step S626 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S627 is executed.
  • step S626 the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.
  • step S627 the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.
  • the vehicle-mounted terminal can indicate to the mobile phone the reason why the IoT client fails to start, for example, the startup password of the IoT client is wrong, the client ID of the IoT client does not exist, etc.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the client configuration process and client startup process are introduced above in conjunction with steps S611 to S627. If the IoT client is started successfully, the client registration process will be introduced below with reference to Figure 6(b).
  • the method shown in Figure 6(b) includes steps S631 to S633.
  • step S631 the IoT client connects to the IoT cloud address and uses the certificate to establish a secure connection with the IoT cloud.
  • step S632 the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.
  • the client registration request may include the client ID, access token, and access address of the IoT client.
  • the client registration request please refer to the introduction in Table 18 above.
  • step S633 in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.
  • the client registration response command can carry the new access token, user ID, first token, and access address of the smart home device assigned by the IoT cloud platform to the IoT client.
  • the client registration response command can be found in the introduction above in conjunction with Table 20.
  • the client login process in the embodiment of this application is introduced below with reference to Figure 6(c).
  • the method shown in Figure 6(c) includes steps S641 to S642.
  • step S641 the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.
  • the above login request includes a user ID, a client ID and an access token. Please refer to the introduction in Table 11 above.
  • step S642 in response to the login request, the IoT cloud platform sends a login response command to the IoT client.
  • Table 27 shows a possible implementation of the login response command in the embodiment of this application.
  • the login response command may include Internet media type and token expiration information.
  • the access address of the IoT client and the access address of the smart home device are exchanged.
  • the access address of the IoT client and the access address of the smart home device can also be interacted through login request and login response commands.
  • the commands introduced in Table 19 and Table 21 can be used.
  • the client registration request and client registration response can be combined with the commands introduced in Table 3 and Table 5.
  • FIG. 7 is a schematic diagram of the first device according to the embodiment of the present application.
  • the first device 700 shown in FIG. 7 includes: a processing unit 710.
  • the processing unit 710 is configured to communicate with the cloud platform through a first client, where the user type of the first client is a long-term user.
  • the first device further includes: a receiving unit, configured to receive first indication information sent by the configuration device, where the first indication information is used to indicate the user type of the first client.
  • the first device includes a functional cluster
  • the functional cluster is used to indicate commands supported by the first client; and/or the functional cluster is used to record the first client.
  • the function cluster is used to indicate one or more of the following information of the first client: the client identification of the first client; the user identification of the first client; and Instructions for the cloud platform.
  • the function cluster includes one or more of the following commands: used to instruct the first request to start the first client; used to instruct the first client to add the cloud platform a second request; a response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; a third request for the CSR of the first client request; and a response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the first client.
  • the functional cluster includes the first request
  • the first request includes a startup password of the first client and/or indication information of the cloud platform.
  • the second request includes one or more of the following information: the first client identifies itself on the cloud platform Verified certificate information, instruction information of the cloud platform, and access token information of the cloud platform.
  • 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.
  • 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.
  • the cloud platform 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.
  • 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 re-login.
  • the cloud platform is not limited to: 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 re-login.
  • the cloud platform is not limited to: 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 re-login.
  • the user type of the first client is configured by the user through a configuration device.
  • the user type of the client in the first device includes long-term users or temporary users.
  • FIG 8 is a schematic diagram of a configuration device according to an embodiment of the present application.
  • the configuration device 800 shown in Figure 8 includes a sending unit 810.
  • the sending unit 810 is configured 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 send a second indication to the cloud platform.
  • Information 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.
  • the first device includes a functional cluster
  • the functional cluster is used to indicate commands supported by the first client; and/or the functional cluster is used to record the first Clients whose user type is long-term user in the device.
  • the function cluster is used to indicate one or more of the following information of the first client: the client identification of the first client; the user identification of the first client; and Instructions for the cloud platform.
  • the function cluster includes one or more of the following commands: used to instruct the first request to start the first client; used to instruct the first client to add the cloud platform a second request; a response command for the second request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; a third request for the CSR of the first client request; and a response command for the third request, wherein the response command for the third request is used to request the cloud platform for a certificate for authentication of the first client.
  • the functional cluster includes the first request
  • the first request includes a startup password of the first client and/or indication information of the cloud platform.
  • the second request includes one or more of the following information: the first client identifies itself on the cloud platform Verified certificate information, instruction information of the cloud platform, and access token information of the cloud platform.
  • 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.
  • the user type of the first client is configured by the user through the configuration device.
  • the user type of the client in the first device includes long-term users or temporary users.
  • FIG 9 is a schematic diagram of a cloud platform according to an embodiment of the present application.
  • the cloud platform 900 shown in Figure 9 includes a communication unit 910.
  • the communication unit 910 is configured to communicate with the first client in the first device, where the user type of the first client is a long-term user.
  • the communication unit is further configured to: receive second indication information sent by the configuration device, where the second indication information is used to indicate the user type of the first client.
  • the second indication information is carried in the client application request.
  • the communication unit is further 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.
  • the cloud platform further includes: a first processing unit, configured to log out of the first client in response to the fourth request.
  • 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 log in to the cloud platform again. .
  • the communication unit is also configured to receive a sixth request sent by the configuration device, where the sixth request is used to apply for a second client to the cloud platform; the second processing unit is configured to If the second client is the same as the first client, reject the sixth request.
  • the user type of the client in the first device includes long-term users or temporary users.
  • FIG 10 is a schematic diagram of the first device according to the embodiment of the present application.
  • 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 1000 shown in Figure 10 includes a sending unit 1010.
  • 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 for the first client to request to log in to the cloud platform again.
  • the first information includes one or more of the following information: an access token used by the first client to log in to the cloud platform; identification; the user identification of the first client; and the indication information of the cloud platform.
  • 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.
  • the user type of the client in the first device includes long-term users or temporary users.
  • the user type of the first client is a long-term user.
  • FIG. 11 is a schematic diagram of the cloud platform according to the embodiment of the present application.
  • the cloud platform 1100 shown in FIG. 11 includes a receiving unit 1110.
  • 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 log in to the cloud platform again.
  • the cloud platform stores second information for the first client to log in to the cloud platform, and the cloud platform further includes: a first processing unit configured to respond to the The fifth request is to determine whether to allow the first client to log in again based on the second information.
  • the second information includes one or more of the following information: an access token used by the first client to log in to the cloud platform; identification; the user identification of the first client; and the user type of the first client.
  • 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.
  • 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 used to log in. 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. client.
  • the receiving unit is configured to receive a sixth request sent by the configuration device, where the sixth request is used to apply for a second client to the cloud platform; if the second client Similar to the first client, the third processing unit is configured to reject the sixth request.
  • the user type of the first client is a long-term user.
  • the processing unit 710 may be a processor 1210.
  • the first device 700 may also include a transceiver 1230 and a memory 1220, as specifically shown in FIG. 12 .
  • the sending unit 810 may be a transceiver 1240.
  • the configuration device 800 may also include a processor 1210 and a memory 1220, as specifically shown in FIG. 12 .
  • the communication unit 910 may be a transceiver 1240.
  • the cloud platform 900 may also include a processor 1210 and a memory 1220, as specifically shown in Figure 12.
  • the sending unit 1010 may be a transceiver 1240.
  • the first device 1000 may also include a processor 1210 and a memory 1220, as specifically shown in Figure 12.
  • the receiving unit 1110 may be a transceiver 1240.
  • the cloud platform 1100 may also include a processor 1210 and a memory 1220, as specifically shown in Figure 12.
  • Figure 12 is a schematic structural diagram of a communication device according to an embodiment of the present application.
  • the dashed line in Figure 12 indicates that the unit or module is optional.
  • the device 1200 can be used to implement the method described in the above method embodiment.
  • Device 1200 may be a chip, terminal device or network device.
  • Apparatus 1200 may include one or more processors 1210.
  • the processor 1210 can support the device 1200 to implement the method described in the foregoing method embodiments.
  • the processor 1210 may be a general-purpose processor or a special-purpose processor.
  • the processor may be a central processing unit (CPU).
  • the processor can also be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or an off-the-shelf programmable gate array (FPGA) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA off-the-shelf programmable gate array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • Apparatus 1200 may also include one or more memories 1220.
  • the memory 1220 stores a program, which can be executed by the processor 1210, so that the processor 1210 executes the method described in the foregoing method embodiment.
  • the memory 1220 may be independent of the processor 1210 or integrated in the processor 1210.
  • Device 1200 may also include a transceiver 1230.
  • Processor 1210 may communicate with other devices or chips through transceiver 1230.
  • the processor 1210 can transmit and receive data with other devices or chips through the transceiver 1230.
  • An embodiment of the present application also provides a computer-readable storage medium for storing a program.
  • the computer-readable storage medium can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An embodiment of the present application also provides a computer program product.
  • the computer program product includes a program.
  • the computer program product can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An embodiment of the present application also provides a computer program.
  • the computer program can be applied to the terminal or network device provided by the embodiments of the present application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • the "instruction" mentioned may be a direct instruction, an indirect instruction, or an association relationship.
  • a indicates B which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association between A and B. relation.
  • B corresponding to A means that B is associated with A, and B can be determined based on A.
  • determining B based on A does not mean determining B only based on A.
  • B can also be determined based on A and/or other information.
  • the term "correspondence” can mean that there is a direct correspondence or indirect correspondence between the two, or it can also mean that there is an association between the two, or it can also mean indicating and being instructed, configuring and being configured, etc. relation.
  • predefinition or “preconfiguration” can be achieved by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in devices (for example, including terminal devices and network devices).
  • devices for example, including terminal devices and network devices.
  • predefined can refer to what is defined in the protocol.
  • the "protocol” may refer to a standard protocol in the communication field, which may include, for example, LTE protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this.
  • the size of the sequence numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its functions and internal logic, and should not be determined by the implementation process of the embodiments of the present application. constitute any limitation.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means.
  • the computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center integrated with one or more available media.
  • the available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVD)) or semiconductor media (e.g., solid state disks (SSD) )wait.
  • magnetic media e.g., floppy disks, hard disks, magnetic tapes
  • optical media e.g., digital video discs (DVD)
  • semiconductor media e.g., solid state disks (SSD)

Abstract

提供了一种通信方法、第一设备、配置设备以及云平台。该方法包括第一设备中的第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。在本申请实施例中，引入了针对长期用户的客户端，相比于传统的方案中只涉及临时用户的客户端，有助于丰富客户端的应用场景，提高用户体验。

Description

通信方法、第一设备、配置设备以及云平台 技术领域
本申请涉及通信技术领域，并且更为具体地，涉及通信方法、第一设备、配置设备以及云平台。
背景技术
目前，客户端与云平台之间的交互过程都是基于客户端的用户为临时用户的场景来设计的，这种针对临时用户的场景比较单一无法满足用户的需求，导致用户体验较低。
发明内容
本申请提供一种通信方法、第一设备、配置设备以及云平台。下面对本申请涉及的各个方面进行介绍。
第一方面，提供了一种通信方法，包括：第一设备中的第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。
第二方面，提供了一种通信方法，包括：配置设备向第一设备发送第一指示信息，所述第一指示信息用于指示所述第一设备中的第一客户端的用户类型；和/或，所述配置设备向云平台发送第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型，其中，所述第一客户端的用户类型为长期用户，且所述第一客户端用于与所述云平台通信。
第三方面，提供了一种通信方法，包括：云平台与第一设备中的第一客户端进行通信，所述第一客户端的用户类型为长期用户。
第四方面，提供了一种通信方法，第一设备配置有第一客户端，并存储有用于所述第一客户端登录云平台的第一信息，所述方法包括：所述第一设备基于所述第一信息向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
第五方面，提供了一种通信方法，包括：云平台接收第一设备发送的第五请求，所述第五请求用于所述第一设备中的第一客户端请求重新登录所述云平台。
第六方面，提供了一种第一设备，包括：处理单元，用于通过第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。
第七方面，提供了一种配置设备，包括：发送单元，用于向第一设备发送第一指示信息，所述第一指示信息用于指示所述第一设备中的第一客户端的用户类型；和/或，向云平台发送第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型，其中，所述第一客户端的用户类型为长期用户，且所述第一客户端用于与所述云平台通信。
第八方面，提供了一种云平台，包括：通信单元，用于与第一设备中的第一客户端进行通信，所述第一客户端的用户类型为长期用户。
第九方面，提供了一种第一设备，所述第一设备配置有第一客户端，并存储有用于所述第一客户端登录云平台的第一信息，所述第一设备包括：发送单元，用于基于所述第一信息向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
第十方面，提供了一种云平台，包括：接收单元，用于接收第一设备发送的第五请求，所述第五请求用于所述第一设备中的第一客户端请求重新登录所述云平台。
第十一方面，提供一种第一设备，包括处理器、存储器以及通信接口，所述存储器用于存储一个或多个计算机程序，所述处理器用于调用所述存储器中的计算机程序，使得所述第一设备执行上述各个方面的方法中的部分或全部步骤。
第十二方面，提供一种配置设备，包括处理器、存储器、收发器，所述存储器用于存储一个或多个计算机程序，所述处理器用于调用所述存储器中的计算机程序，使得所述配置设备执行上述各个方面的方法中的部分或全部步骤。
第十三方面，提供一种云平台，包括处理器、存储器、收发器，所述存储器用于存储一个或多个计算机程序，所述处理器用于调用所述存储器中的计算机程序，使得所述云平台执行上述各个方面的方法中的部分或全部步骤。
第十四方面，本申请实施例提供了一种通信系统，该系统包括上述的第一设备、配置设备以及云平台中的一种或多种。在另一种可能的设计中，该系统还可以包括本申请实施例提供的方案中与第一设备、配置设备或云平台进行交互的其他设备。
第十五方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算 机程序，所述计算机程序使得通信设备(例如，第一设备、配置设备或云平台)执行上述各个方面的方法中的部分或全部步骤。
第十六方面，本申请实施例提供了一种计算机程序产品，其中，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序可操作来使通信设备(例如，第一设备、配置设备或云平台)执行上述各个方面的方法中的部分或全部步骤。在一些实现方式中，该计算机程序产品可以为一个软件安装包。
第十七方面，本申请实施例提供了一种芯片，该芯片包括存储器和处理器，处理器可以从存储器中调用并运行计算机程序，以实现上述各个方面的方法中所描述的部分或全部步骤。
在本申请实施例中，引入了针对长期用户的客户端，相比于传统的方案中只涉及临时用户的客户端，有助于丰富客户端的应用场景，提高用户体验。
附图说明
图1是本申请实施例适用的系统架构的示意图。
图2是本申请实施例适用的Matter设备的模型结构。
图3是客户端与云平台进行连接的流程图。
图4是本申请实施例的通信方法的流程图。
图5(a)～图5(c)是本申请实施例的通信方法的示意性流程图。
图6(a)～图6(c)是本申请另一实施例的通信方法的示意性流程图。
图7是本申请实施例的第一设备的示意图。
图8是本申请实施例的配置设备的示意图。
图9是本申请实施例的云平台的示意图。
图10是本申请实施例的第一设备的示意图。
图11是本申请实施例的云平台的示意图。
图12是本申请实施例的通信装置的示意性结构图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。为了便于理解，下文先结合图1介绍本申请实施例适用的系统架构。
图1是本申请实施例适用的系统架构的示意图。图1所示的系统100可以包括第一设备110，配置设备(mediator)120，云平台130以及第二设备140。
第一设备110，可以是具有与云平台130进行通信功能的设备。在一些实现方式中，第一设备110可以设置有客户端(client)，客户端可以用于与云平台130进行通信，并通过云平台130与第二设备140进行通信。例如，用户可以通过客户端访问云平台130，并通过云平台130访问第二设备140。又例如，用户可以通过客户端访问云平台130，并通过云平台130控制第二设备140。
在一些实施例中，上述客户端可以为应用程序(application，APP)或者小程序等。
第二设备140，可以是具有与云平台130进行通信功能的设备。在一些实现方式中，第二设备140可以为用户提供服务功能，因此，第二设备140又可以称为服务端(server)，或者服务设备。
配置设备120，用于对第一设备110和/或第二设备140进行配置。例如，配置设备120可以配置第一设备110和/或第二设备140与云平台130进行通信。又例如，配置设备120可以为第一设备110中的客户端进行配置，使得客户端可以与云平台130进行通信。
在一些实现方式中，配置设备120可以为应用程序(application，APP)或者小程序等。在另一些实现方式中，配置设备120可以安装在终端设备上，其中，终端设备可以是手机、平板电脑(Pad)、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备，虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。本申请实施例对此并不进行限定。
云平台130，又称为云计算平台(cloud computing platform)或者“云端”，可以理解为基于硬件资源和软件资源的服务提供网络通信能力。因此，在本申请实施例中，第一设备110中的客户端可以通过云平台130对第二设备140进行访问或控制。
在一些实现方式中，云平台130可以基于一个或多个云端服务器搭建而成，来提供网络功能。
需要说明的是，上述云平台130还可以是其他可以提供网络功能的系统或设备。例如，可以提供网 络功能的集群系统等等。本申请实施例对此不作限定。
另外，上述配置设备120可以与客户端是匹配的APP或小程序，当然，配置设备230可以与客户端是不同的APP或小程序。本申请实施例对此不作限定。
在一些场景中，上述系统100例如可以是物联网(internet of things，IoT)系统。其中，物联网即“万物相连的互联网”，可以理解为是在互联网基础上延伸和扩展的网络，可以通过各种信息传感设备(如射频识别、全球定位系统等)将任何物品与互联网连接起来形成一个巨大的网络，来进行信息交换和通信，以实现万物之间的互联互通。
相应地，在一些实施例中，上述第一设备和/或第二设备可以是IoT设备。其中，IoT设备可以包括车载终端、智能家居设备、智能监控设备等。智能家居设备例如可以包括智能空调、智能冰箱、洗衣机、电饭煲、扫地机器人等设备。智能监控设备例如可以包括监控摄像头、温度传感器、声音传感器等设备。
在另一些实施例中，上述云平台可以是IoT云平台，简称“IOT云”，用于为IOT系统中的IOT设备提供通信服务功能。
为了便于理解，以IoT设备为例介绍系统100。假设第一设备110为车载终端，第二设备140为智能家居设备，配置设备120可以为终端设备。继续参见图1，终端设备120可以对车载终端110中的客户端进行配置，使得客户端可以与云平台130进行通信。在客户端配置成功后，用户便可以通过客户端对于云平台上的智能家居设备(或者说与云平台连接的智能家居设备)进行访问和/控制。对于可以对智能家居设备进行访问和/或控制的客户端又可以称为“智能家居客户端(smart home client)”。
示例性地，假设第二设备为智能空调，并且智能空调位于云平台，此时，客户端可以通过云平台控制智能空调的开关以及设置空调温度、风速等。当第二设备为扫地机器人时，客户端可以通过云平台控制扫地机器人开始工作或停止工作、控制扫地机器人的工作模式等。
目前，不同厂家可能使用不同的通信协议(也可以称为生态链协议)，实现支持该通信协议的物联网设备之间的互联互通，这样可能导致不同厂家生产的物联网设备之间不能通信，不能达到真正的万物互联。
基于此，连接标准联盟(connectivity standards alliance，CSA)推出一种物联网应用层技术标准—Matter标准协议，其可以提供基于互联网协议(internet protocol，IP)的智能家居设备的可互操作的应用层解决方案。在一些实施例中，matter标准也可以称为基于IP的互联家居(connected home over IP，CHIP)标准。在一些实施例中，Matter标准可以支持以太网、Wi-Fi和Thread三种底层通信协议，并且可以让不同协议的物联网设备互相通信。
相应地，若上文介绍的客户端支持Matter协议，可以称为“Matter客户端”。若上述第二设备支持Matter协议，可以称为“Matter服务端”。对于支持Matter协议的第一设备和/或第二设备也可以称为“Matter设备”。
下文以Matter协议的场景为例，介绍本申请实施例涉及的术语，以及本申请实施例的方案。当然，本申请实施例的方案还可以应用于其他物联网协议。
Matter设备的模型
图2是本申请实施例适用的Matter设备的模型结构。Matter设备的数据模型结构200包括节点(node)210、端点(endpoint)220、群集(cluster)230。
节点(node)210，封装了网络上可寻址的、唯一的资源，具有一组功能和能力，用户可以清楚地将其视为一个功能整体。通常，节点210可以是数据模型中最高或最外层的一阶元素。或者说，节点210是数据模型最外层唯一的可寻址元素。
需要说明的是，一个物理实体(例如，Matter设备)可以支持多个节点210。另外，一个节点可以有多个节点ID，每个节点ID的作用域是一个特定的网络(fabric)。例如，当节点ID被用作交互的目标地址时，指定节点ID作用域的网络就是交互的访问网络。一个节点可以包括一个或多个端点220。端点220是一个实例，它可以是一个服务或虚拟设备，由设备类型指示。每个端点220都符合一个或多个设备类型定义，这些设备类型定义了端点上支持的群集。而群集是在端点上实例化的对象类。
需要说明的是，在这个体系结构模型中，上述设备类型可以是最高语义元素。设备类型定义了一组端点220的一致性。设备类型为节点210或端点220定义了一组需求。
群集230是数据模型的功能构建块元素，因此，群集又可以称为“功能集”、“功能集群”、“功能群集”等。群集规范定义了通过交互相互对应的客户端和服务端。群集230可以被视为接口、服务或对象类，是数据模型中最低的独立功能元素。每个群集230都由一个群集规范定义，该规范定义了群集230的元素，包括属性、事件、命令以及与这些元素交互相关的行为。群集230中的属性、事件、命令和行为是强制性的还是可选的，取决于群集230的定义。
通常，上述群集可以分为实用程序群集(utility cluster)或应用程序群集(application cluster)两类。 实用程序群集不是端点的主要应用程序操作的一部分。它可以用于配置、发现、寻址、诊断、监视设备运行状况、软件更新等。它可能与它的群集对等物有一个临时的关系。在本申请实施例中，实用程序群集可以包括客户端群集。
应用程序群集(又称“业务群集”)支持端点的主要操作。应用程序群集支持群集的客户端和群集的服务端之间的一个或多个持久应用程序交互。例如，智能电灯中的开关群集(On/Off cluster)，该群集的客户端可以向群集的服务端(即，开关群集)发送控制命令，以控制智能电灯的开关。
群集命令(又称“命令”)是一组数据字段，每个数据类型在客户端和服务端群集实例之间传递，以调用命令接收者的行为。目前，协议中约定，每个命令都可以列在一个表中，该表可以包含命令的数据质量列：标识(ID)、名称(name)、方向(direction)、响应(response)、访问(access)、约束(constraint)一致性(conformance)。相应地，一条命令可以指示一个表中定义的零个或多个字段。每个命令字段定义为表中的一行。
属性可以理解为是群集数据。目前，协议中约定每个属性可以列在一个表中，包含数据质量列。数据质量列可以包括ID、name、(数据)类型、约束、其他质量、访问、默认(值)和一致性。在一些实现方式中，属性还可以定义其相关的语义和行为。属性可以反映设备的可查询/可设置的状态、配置和能力。在一些情况下，如果没有为属性显式定义特权，则默认的访问特权生效。
为了便于理解，下文介绍命令和属性中包含几种常见的数据质量的含义。需要说明的是，本申请实施例中的命令和属性中还可以包含其他数量质量，或者包含上述数据质量中的部分。本申请实施例对此不作限定。
标识，表示字段的唯一字段ID，或者说，是命令的唯一标识。
名称，表示字段的唯一名称，或者说，表示命令的名称。
类型，表示字段的数据类型，命令参数的数据类型，或者属性参数的数据类型。在一些实现方式中，数据类型的取值可以为字节串(octet string)，表示为“octstr或octstring”；数据类型的取值可以为字符串(string)；数据类型的取值可以为X位无符号数(unsigned X-bit integer，uintX)，其中X的取值可以为8、16、24、32、40、48、56、64等；数据类型的取值可以为数值型(Number)；布尔值(boolean)表示为“bool”。
方向，通常存在于命令列表中，用于定义命令的传输方向，例如，可以定义为从客户端到服务端。又例如，可以定于为从服务端到客户端。
访问权限，用于定义一个元素如何被访问(例如读或写)以及访问该数据需要哪些权限。
在一些实现方式中，访问权限可以包括V，V表示读取访问或调用访问需要视图特权。访问权限还可以包括O，O表示“读访问”、“写访问”或“调用访问”需要操作权限。访问权限还可以包括R，R表示读访问。访问权限还可以包括W，W表示写访问。
响应，通常存在于命令列表中，用于定义命令的响应命令。
质量，用于定义其他列中没有涉及的其他数据质量。
默认，用于定义的默认值。需要说明的是，默认值并不是服务设备返回出厂刷新设置时使用的值。默认值可以指示为数据字段指定的一致性可以是可选的，也可以随时间变化。当实际数据字段值不存在时，可以定义默认值以完成依赖关系。
一致性，用于定义任何数据模型元素或元素集的可选性和依赖性。
通常，此列对属性、命令、事件、枚举以及命令、事件或结构的字段有效。在一些实现方式中，“M”表示对应的命令为基本的强制特性集的一部分。
对于命令而言，客户端到服务端命令的一致性意味着服务器应该识别并支持客户端到服务器的命令，并按照定义生成响应。服务端到客户端命令的一致性意味着服务器应该按照群集行为定义的方式发送命令，例如，响应客户端到服务器的命令。命令的一致性取决于所支持的服务器特性。客户端不应被要求支持可选命令或依赖于可选特性的命令。
约束，在一些情况下，约束可以包含all和desc。其中，all用于定义在数值数据类型中表示允许所有值。Desc用于表示约束是在描述部分定义的。在另一些情况下，约束还可以指示对应参数取值的最大值，表示为“max N”。例如，在本申请实施例中，N为99时，“max 99”用于指示对应的参数的取值最大值为99。又例如，在本申请实施例中，N为400时，“max 400”用于指示对应的参数的取值最大值为400。在另一些情况下，约束可以用于定义参数的占用的字节数量，例如，约束的取值为32时用于指示对应的参数占用的字节数量为32。
范围(range)，表示字段的取值范围。
在一些实现方式中，范围可以支持两种形式：显式约束(explicit constraint)和宽度约束(width constraint)。其中，显式约束可以指示字段的取值对应的最小值和最大值，例如，显示约束指示某个字 段的取值范围为(0，128)。
上述宽度约束可以用于约束字段的取值占用的字节数，或者说，宽度约束可以将字段的取值限定在特定字节数内。例如，宽度约束可以指示某个字段的取值占用的最大字节数为8字节。
需要说明的是，范围的取值包含“N/A”时，指示不适用。另外，在本申请实施例中，“N/A”也可以出现在其他部分(其他数据质量中)，比如，默认、约束等。
另外，上文介绍的命令或属性中数据质量的含义，可以实用本申请实施例的方案，为了简洁，下文在介绍命令或属性涉及相同含义的数据质量时，可以参见上文的介绍，不再赘述。
客户端与云平台的连接方案
目前，如果希望通过客户端通过云平台与第二设备进行通信，客户端需要基于客户端与平台的连接方案，来与云平台建立连接。其中，客户端与平台的连接方案包括经过客户端配置过程、客户端注册过程以及客户端登录过程等。下文结合图3所示的步骤S311至步骤S327介绍客户端配置过程、客户端注册过程以及客户端登录过程。
在步骤S311中，配置设备确定第一设备具有支持客户端的能力。
通常，第一设备与配置设备建立连接之后，配置设备可以查询第一设备的能力，来确定第一设备是否支持配置客户端。当然，第一设备也可以直接上配置上报第一设备的能力，以便配置设备确定第一设备是否支持配置客户端。
在步骤S312中，配置设备弹出对话界面，提示用户选择是否同意用第一设备控制第二设备。
在步骤S313中，若用户同意用第一设备控制第二设备，则配置设备向第一设备发送证书请求(certificate signing request，CSR)请求命令。
在步骤S314中，客户端生成密钥对，并将密钥对中的私钥存储在安全区。
在步骤S315中，客户端向配置设备发送CSR响应命令以传输CSR。
上述CSR的格式可以是符合公钥加密标准(public key cryptography standards，PKCS)#10定义的CSR数据格式。相应地，CSR可以遵循以下原则：CSR携带证书请求信息，该信息可以包括版本(version)信息、主题(subject)信息、公钥信息等。其中，主题信息可以包含第一设备的供应商标识(vendor ID)、第一设备的产品标识(product ID)等。公钥信息可以指示上述密钥对(参见步骤S340)中的公钥。
需要说明的是，上述第一设备的供应商标识、第一设备的产品标识可以与第一设备的基本信息群集(general_Info cluster)中记录的数据获得。
另外，上述CSR可以经过数字签名，并且CSR的数字签名可以是基于密钥对中的私钥生成的。
在步骤S316中，配置设备向云平台发送信息1，其中，信息1用于为客户端申请云连接的凭证即接入令牌(access token)，并且，信息1中携带CSR。
在步骤S317中，在CSR验证通过后，云平台可以为客户端分配客户端标识。
在步骤S318中，云平台基于客户端对应的客户端标识和公钥，生成客户端的证书。
在步骤S319中，云平台为客户端分配接入令牌，并建立用户ID、客户端ID和接入令牌之间的绑定关系。
在步骤S320中，云平台利用客户端的公钥对接入令牌进行加密得到加密后的访问令牌，用“CToken”表示。
在步骤S321中，云平台向配置设备发送信息2，以指示客户端的证书和CToken。
上述信息2中包含的参数可以包括CToken、证书链(CertChain)以及令牌到期(TokenExpiration)信息。上述参数的说明以及对应的属性可以参见表1所示。表1示出了信息2包括的参数、参数的值类型、参数是否为必要性以及参数的说明等信息。
表1
Figure PCTCN2022117779-appb-000001
在步骤S322中，配置设备向第一设备发送信息3，以为客户端配置将客户端的证书、CToken、以及云注册地址。
上述信息3中的配置参数可以包括：客户端证书(用“ClienCert”表示)、中间证书(用“IntermediateCert”表示)、根证书(用“RootCert”表示)、云平台的云地址(cloud address)、CToken以及令牌到期信息。上述参数的说明、参数的标识、参数对应的属性以及参数所在字段可以参见表2所示。表2示出了信息3包括的参数、参数所在的字段、参数的标识、参数的数据类型、参数的约束、参数的必要性以及参数 的说明等信息。
表2
Figure PCTCN2022117779-appb-000002
在步骤S323中，第一设备用私钥对信息3进行解密，得到信息3中的上述参数。并基于上述参数对客户端进行配置。
在步骤S324中，客户端基于云地址连接云平台，并使用客户端证书与云平台建立安全连接。
在步骤S325中，客户端向云平台发送注册请求(又称“云端注册请求”、或者“客户端注册请求”)。上述注册请求可以携带客户端ID和接入令牌。
表3示出了注册请求的接口说明，参见表3，注册请求的基于的超文本传输协议(hyper text transfer protocol，HTTP)方法可以是POST方法，注册请求的接口访问地址可以是账户(account)。
表3
HTTP方法 接口访问地址
POST /account
表4示出了注册请求的接口参数。表4中指出了注册请求中的参数在请求中的位置、参数的名称、参数的值类型、参数是否为必要性，以及参数的说明等信息。
表4
位置 参数 值类型 必要性 说明
主体(body) 接入令牌 string 是 客户端的访问令牌
主体 客户端ID string 是 云平台为客户端分配的客户端ID。
在步骤S326中，云平台向配置设备发送注册响应命令(又称“云端注册响应”)。在一些实现方式中，注册响应命令中会携带云平台发送的更新后的接入令牌。当然，云平台也可以不更新客户端的接入令牌。
表5示出了注册响应命令包括的参数、参数所在的位置、参数的值类型、参数是否为必要性以及参数的说明等信息。
表5
Figure PCTCN2022117779-appb-000003
在步骤S327中，第一设备的客户端基于客户端标识以及注册响应中携带的接入令牌，登录云平台。
在成功登录云平台后，用户便可以通过客户端与云平台上的第二设备进行通信。例如，发现第二设备，对第二设备进行访问，对第二设备进行控制等。
目前，客户端与云平台之间的交互过程都是基于客户端的用户为临时用户的场景来设计的，这种针对临时用户的场景比较单一无法满足用户的需求，导致用户体验较低。因此，本申请实施例中引入了针对长期用户的客户端，以丰富客户端的应用场景，有助于提高用户体验。
下文结合图4介绍本申请实施例的通信方法。图4是本申请实施例的通信方法的示意性流程图。图4所示的步骤包括S410。
在步骤S410中，第一设备中的第一客户端与云平台进行通信。
其中，第一客户端的用户类型为长期用户，或者说，第一客户端可以是长期客户端。以第一设备为车辆为例，第一客户端对应的长期用户可以是车辆的车主。
相应地，第一设备中还可以配置有临时用户的客户端(又称“临时客户端”)。对于临时用户使用的客户端而言，若第一设备为车辆，临时用户可以是车辆的临时搭乘人员。
在引入了针对长期用户的客户端后，第一设备针对此类客户端执行的操作与针对临时客户端执行的操作可能不太相同，那么，对于第一设备而言需要获知客户端的用户类型。因此，本申请实施例中还提供了一种客户端的用户类型的配置方案。
在一些实现方式中，客户端的用户类型可以由配置设备告知第一设备，即配置设备向第一设备发送第一指示信息，第一指示信息用于指示第一客户端的用户类型，换句话说，第一指示信息可以用于指示第一客户端的用户类型是否为长期用户。
在一些实现方式中，第一指示信息可以承载于CSR请求命令(又称第三请求)中。下文结合表6介绍本申请实施例的CSR请求命令的参数。参见表6，CSR请求可以携带参数长期用户(即第一指示信息)，来指示客户端的用户类型。其中，长期用户字段的标识可以为0，该字段的数据类型可以为布尔值，当布尔值为真(true)时，用于指示客户端的用户类型为长期用户。当布尔值为假(false)时，用于指示客户端的用户类型为临时用户。
表6
ID 字段 数据类型 约束 质量 默认值 必要性
0 长期用户 bool     False M
需要说明的是，上述第一指示信息也可以承载于除CSR请求命令之外的其他命令中，或者第一指示信息也可以承载于专用命令中，本申请实施例对此不作限定。
在一些实现方式中，在接收到CSR请求命令后，第一设备可以向配置设备发送CSR响应命令(又称“针对第三请求的响应命令”)，该CSR响应命令中携带客户端的CSR。表7示出了本申请实施例的CSR响应命令的参数。参见表7，CSR请求可以携带参数CSR。另外，表7中还示出了参数对应的标识、参数的数据类型、参数的约束、参数的质量、参数的默认值以及参数的必要性。
表7
ID 字段 数据类型 约束 质量 默认值 必要性
0 CSR octstr max 900     M
相应地，在引入了针对长期用户的客户端后，云平台针对此类客户端执行的操作与针对临时客户端执行的操作可能不太相同，那么，对于云平台而言需要获知客户端的用户类型。因此，本申请实施例中还提供了一种客户端的用户类型的配置方案。
在另一些实现方式中，客户端的用户类型可以由配置设备告知云平台，即配置设备向云平台发送第二指示信息，第二指示信息用于指示第一客户端的用户类型，换句话说，第二指示信息可以用于指示第一客户端的用户类型是否为长期用户。
上述第二指示信息可以承载于客户端申请请求(又称“申请请求”)中，其中，客户端申请请求用于向云平台申请客户端的证书以及令牌。下文结合表8和表9介绍本申请实施例的客户端申请接口说明以及客户端申请请求中的参数。参见表8，客户端申请接口使用的HTTP方法为POST，接口访问地址为“/addclient”。
表8
HTTP Method 接口访问地址
POST /addclient
表9示出了客户端申请请求命令中携带的参数。申请请求命令中可以包括接收(accept)、互联网媒体类型(content-type)、接入令牌、CSR、长期用户。另外，表9还示出了参数的位置、值类型、必要性以及参数的说明。
表9
Figure PCTCN2022117779-appb-000004
Figure PCTCN2022117779-appb-000005
在本申请实施例中，云平台可以通过针对客户端申请请求的客户端申请响应命令，向配置设备发送客户端的证书。在一些实现方式中，上述证书可以通过客户端申请响应命令中的参数“证书链(CertChain)”指示。在另一些实现方式中，上述证书可以包括客户端证书(用“ClienCert”表示)、中间证书(用“IntermediateCert”表示)、根证书(用“RootCert”表示)中的一种或多种。
在一些实现方式中，客户端的用户类型可以是由用户通过配置设备配置的。也即是说，用户可以通过配置设备选择客户端的用户类型为长期用户或临时客户。当然，在本申请实施例中，还可以采用其他方式帮助配置设备确定客户端的用户类型，本申请实施例对此不作限定。
需要说明的是，上述第一指示信息指示的第一客户端的用户类型可以与第二指示信息指示的第一客户端的用户类型相同。
上文介绍了第一客户端的用户类型，以及第一客户端的用户类型的配置过程。下文介绍客户端与云平台的登录、登出过程。
目前，客户端与云平台之间的传统交互方案都是以临时用户使用客户端的场景进行设计的。如果客户端希望断开与云平台之间的连接，只能通过注销的方式断开与云平台之间的连接。在客户端从云平台注销后，云平台和第一设备都会相应地删除客户端的信息(例如，客户端标识、客户端的用户标识、客户端对应的云平台指示信息、客户端的接入令牌等)，这样一来，如果用户需要重新通过客户端登录云平台，只能重新按照图3所示的方法建立客户端与云平台之间的连接。然而，由于长期用户使用的客户端通常是配置相同的客户端，这种以注销的方式断开云平台与客户端之间连接的方式，应用于长期用户使用客户端的场景时，可能导致长期用户每次在断开客户端与云平台之间的连接后，都需要重新建立客户端与云平台之间的连接，建立连接的操作过于复杂，降低了用户体验。
因此，在本申请实施例中，长期用户的客户端可以以登出的方式，断开与云平台之间的连接。相应地，云平台和第一设备并不会删除用于客户端登录云平台的信息(又称“第一信息”)，这样一来，当长期用户需要再通过客户端登录云平台时，可以复用第一信息建立客户端与云平台之间的连接，有助于减少客户端配置的相关操作，提高用户体验。
在一些实现方式中，第一设备可以向云平台发送第四请求，第四请求用于请求第一客户端登出云平台。因此，第四请求又可以称为“登出请求”。
在本申请实施例中，可以仅允许长期用户的客户端可以以登出的方式，断开与云平台之间的连接。相反地，对于临时用户的客户端而言，只能采用注销的方式，断开与云平台之间的连接。
在一些实现方式中，上述方法还包括：若第一客户端的用户类型为长期用户，响应于第四请求，云平台登出第一客户端；和/或若第一客户端的用户类型为临时用户，响应于第四请求，云平台注销或拒绝登出第一客户端。
当然，在本申请实施例中，临时用户的客户端也可以以登出的方式，断开与云平台的连接，本申请实施例对此不作限定。
在一些实现方式中，第一设备基于第一信息向云平台发送第五请求，第五请求用于第一客户端请求重新登录云平台。
上述第一信息可以包括以下信息中的一种或多种：第一客户端登录云平台的接入令牌；第一客户端的客户端标识；第一客户端的用户标识；以及云平台的指示信息。其中，第一信息的功能以及维护方式将在下文介绍结合功能集群进行介绍，为了简洁，在此不再赘述。
相应地，在另一些实现方式中，云平台在收到第五请求后，可以基于预存的第一客户端的第二信息，确定是否允许第一客户端登录云平台。即，云平台存储有用于第一客户端登录云平台的第二信息，上述方法还包括：响应于第五请求，云平台基于第二信息确定是否允许第一客户端重新登录。当然，在本申请实施例中，云平台在收到第五请求之后，也可以直接允许第一客户端登录云平台，本申请实施例对此不作限定。
在一些实现方式中，上述第二信息可以包括以下信息中的一种或多种：第一客户端登录云平台的接入令牌；第一客户端的客户端标识；第一客户端的用户标识；以及第一客户端的用户类型。
下文以第一信息包括接入令牌、客户端标识以及用户标识，且第二信息包括接入令牌、客户端标识、用户标识以及用户类型为例，若第一信息中的接入令牌、客户端标识以及用户标识，与第二信息中的接入令牌、客户端标识以及用户标识匹配，且第二信息中的第一客户端的用户类型为长期用户，则云平台可以允许第一客户端重新登录云平台。
相反地，若第一信息中的接入令牌、客户端标识以及用户标识，与第二信息中的接入令牌、客户端标识以及用户标识中部分或全部不匹配，则云平台可以拒绝第一客户端重新登录云平台。
当然，若第一信息中的接入令牌、客户端标识以及用户标识，与第二信息中的接入令牌、客户端标识以及用户标识匹配，但第二信息中的第一客户端的用户类型为临时用户，则云平台可以拒绝第一客户端重新登录云平台。
在一些实现方式中，上述第四请求以及第五请求可以采用相同的命令格式，下文结合表10和表11介绍本申请实施例的第四请求以及第五请求。
下文结合表10和表11示出了本申请实施例的登录/登出接口说明以及命令格式。参见表10所示，登录/登出接口的HTTP方法可以为POST，登录/登出接口的访问地址可以表示为“/session”。
表10
HTTP方法 接口访问地址
POST /session
参见表11，命令可以包括接收(accept)、互联网媒体类型(content-type)、接入令牌、用户标识、客户端标识以及登录状态(login)，其中，登录状态指示登录时，该命令格式为登录请求(即第五请求)的命令格式。登录状态指示登出时，该命令格式为登出请求(即第四请求)的命令格式。另外，各个参数在命令中的位置、参数的值类型、参数的必要性以及参数的说明可以继续参见表11所示。
表11
Figure PCTCN2022117779-appb-000006
当然，在本申请实施例中，第四请求与第五请求也可以采用不同的命令格式，对应不同的接口参数，本申请实施例对此不作限定。
为了便于管理客户端，避免客户端配置混乱。通常，云平台可以仅维护一个唯一的客户端，当云平台中已存在配置设备请求申请的客户端时，云平台可以拒绝客户端申请。也就是说，上述方法还包括：配置设备向云平台发送第六请求，第六请求用于向云平台申请第二客户端；若第二客户端与第一客户端相同，云平台拒绝第六请求。
上述第二客户端的用户类型可以为临时用户或者长期用户，本申请实施例对此不作限定。另外，如果不考虑客户端配置混乱等问题，在本申请实施例中，云平台上也可以维护多个相同的客户端，本申请实施例对此不作限定。
在一些实现方式中，上述第一客户端的信息(例如，第一信息)可以作为功能集群的属性维护。也即是说，第一设备可以包括功能集群(又称“客户端功能集群”)，功能集群用于记录第一设备中的客户端。通常，对于长期用户的客户端的信息而言，第一设备可以记录在功能集群中，对于临时用户的客户端的信息而言，第一设备可以不在功能集群中记录。
在一些实现方式中，第一客户端的信息可以包括以下信息中的一种或多种：第一客户端的客户端标识；第一客户端的用户标识；以及云平台的指示信息。
上述第一客户端的客户端标识用于标识第一客户端。
上述第一客户端的用户标识可以用于标识第一客户端的用户。
上述云平台的指示信息可以是用于标识云平台的任意信息，本申请实施例对此不作限定。例如，云平台的指示信息可以是云平台的标识(cloud ID)。又例如，云平台的指示信息可以是云平台的地址。
为了便于理解，下文结合表12和表13介绍功能集群的可能的实现方式。参见表12，功能集群中可以包括属性：长期用户列表(或者说长期客户端列表)，该属性的约束可以为“all”，该属性的质量可以为“N”，该属性的权限可以为“R”，该属性的默认值可以为“空(empty)”，该属性的必要性可以为“M”，该属性的数据类型可以列表，并且列表中记录有客户端结构体(表示为“ClientStruct”)。
表12
ID 名称 数据类型 约束 质量 权限 默认值 必要性
0 长期用户列表 列表[客户端结构体] all N R 空 M
其中，客户端结构体中记录的客户端信息可以如表13所示，即包括客户端标识，用户标识以及云地址。另外，表13中还示出了参数的数据类型，参数的标识，参数的约束，参数的质量，参数的权限、参数的默认值以及参数的必要性。
表13
ID 名称 数据类型 约束 质量 权限 默认值 必要性
0 客户端标识 octstring max99   R   M
1 用户标识 octstring max99   R   M
2 云地址 string     R   M
在一些实现方式中，配置设备可以通过功能集群查询第一设备中是否有合适的客户端(例如，配置设备所在的云平台对应的客户端)，若确定第一设备中配置有合适的客户端，则配置设备可以确定第一设备中已配置有合适的客户端。
例如，若配置设备确认长期用户列表中包含与配置设备所在云平台相同的客户端(即客户端的云地址与配置设备所在的云地址一致)，且客户端的用户ID与配置设备的用户ID也一致，则配置设备可以确定第一设备中已配置有连接云平台的客户端。
如上文介绍，第一设备中客户端的信息可以通过功能群集来维护，相应地，客户端支持的命令(例如，用于配置客户端的命令和/或用于启动客户端的命令)也可以通过相同的功能群集维护。也就是说，上述功能集群还包括客户端支持的命令。需要说明的是，上述功能集群包括的命令可以是长期客户端和/或临时客户端支持的，本申请实施例对此不作限定，下文以第一客户端支持的命令为例进行介绍。
在一些实现方式中，上述功能集群包括以下一种或多种命令：用于请求第一设备启动第一客户端的第一请求；针对第一请求的响应命令；用于指示客户端添加云平台的第二请求；针对第二请求的响应命令，其中，针对第二请求的响应命令用于指示云平台是否添加成功；用于请求第一客户端的CSR的第三请求；针对第三请求的响应命令，其中，针对第三请求的响应命令用于向云平台请求第一客户端进行身份验证的证书。
上述第一请求用于请求第一设备启动第一客户端(又称“待启动客户端”)，因此，第一请求又可以称为“启动客户端请求”(start client request)。
在一些实现方式中，第一请求中可以通过携带待启动客户端的指示信息，来指示待启动的客户端。其中，指示信息例如可以是客户端标识。
上述针对第一请求的响应命令，用于指示第一客户端是否被成功启动。
在一些实现方式中，为了提高启动客户端的安全性，可以基于启动口令来启动第一客户端，其中，启动口令用于验证是否启动第一客户端，或者说，启动口令用于对启动第一客户端的用户进行身份验证，又或者说，启动口令用于对配置设备进行身份验证。若启动口令用于对配置设备进行身份认证，则启动口令又可以称为配置设备密码(mediator password，MedPassword)。
在一些实现方式中，第一请求可以携带第一客户端的启动口令。相应地，如果第一请求中携带的启动口令，与第一设备预存的第一客户端的启动口令匹配，则可以启动第一客户端。相反地，如果第一请求中携带的启动口令与第一设备预存的第一客户端的启动口令不匹配，则可以拒绝启动第一客户端。
需要说明的是，上述匹配可以理解为第一请求中携带的启动口令与预存的第一客户端的启动口令相同，或者，第一请求中携带的启动口令与预存的第一客户端的启动口令不同但满足预设对应关系。相应地，上述不匹配可以理解为第一请求中携带的启动口令与预存的第一客户端的启动口令不相同，或者，第一请求中携带的启动口令与预存的第一客户端的启动口令不同且不满足预设对应关系。
在一些实现方式中，第一客户端可以向配置设备告知第一客户端的启动口令，以便配置设备在通过第一请求启动第一客户端时，可以在第一请求中携带启动口令。其中，第一客户端可以通过添加云响应(add cloud response)命令(又称“针对第二请求的响应命令”)来携带上述启动口令。
表14示出了本申请实施例的添加云响应命令中携带的参数，参见表14，添加云响应命令中可以包括：状态编码(status code)以及启动口令，其中，状态编码用于指示第一客户端是否成功添加云平台。
表14
ID 字段 数据类型 约束 质量 默认值 必要性
0 状态编码 octstr       M
1 启动口令 octstr 32     M
在一些场景中，第一设备中可能会设置有与不同云平台进行通信的第一客户端，这些第一客户端的客户端标识可能相同，此时，可以在第一请求中携带待启动第一客户端对应的云平台的指示信息，以便第一设备识别待启动的第一客户端。如果第一设备中不同的第一客户端具有唯一的标识(例如，客户端ID)，则第一请求可以仅携带待启动第一客户端对应的唯一标识，而不再携带云平台的指示信息。当然，如果第一设备中不同的第一客户端具有唯一的标识，也可以携带云平台的指示信息，本申请实施例对此不作限定。
为了便于理解，下文结合表15介绍第一请求的可能的实现方式。参见表15，第一请求中的参数可以包括第一客户端的客户端标识、第一客户端的启动口令以及第一客户端对应的云地址。另外，表15中还示出了参数的数据类型，参数的标识，参数的约束，参数的质量，参数的默认值以及参数的必要性。
表15
ID 字段 数据类型 约束 质量 默认值 必要性
0 客户端标识 octstr max99     M
1 启动口令 octstr 32     M
2 云地址 string       M
相应地，第一设备在接收到上述第一请求后，可以基于第一请求中的客户端标识确定第一客户端。然后基于预存的第一客户端的客户端标识与启动口令之间的对应关系，确定预存的第一客户端的启动口令与第一请求中的启动口令是否匹配，并基于预存的第一客户端与云地址之间的对应关系，确定预存的第一客户端的云地址与第一请求中的云地址是否匹配。
上述第二请求又称添加云请求(add cloud request)。在一些实现方式中，第二请求包括以下信息中的一种或多种：第一客户端在云平台进行身份验证的证书信息，云平台的指示信息，以及云平台的接入令牌信息。
相应地，针对第二请求的响应命令又可以称为“添加云响应命令”。在一些实现方式中，针对第二请求的响应命令包括：指示云平台是否添加成功的信息，和/或，第一客户端的启动口令。
上述第三请求又可以称为CSR请求命令，相应地，针对第三请求命令的第三响应命令可以称为“CSR响应命令”。
为了便于理解，下文结合表16介绍本申请实施例中功能集群支持的命令。参见表16，功能集群中包含的命令包括CSR请求命令、CSR响应命令、添加云请求命令、添加云响应命令、启动客户端请求命令。另外，表16还示出了各个命令对应的标识、命令的方向、命令的响应、命令的权限以及命令的必要性。
表16
Figure PCTCN2022117779-appb-000007
在本申请实施例中，上述第一客户端的信息以及第一客户端支持的命令也可以通过多个不同的功能群集维护，本申请实施例对此不作限定。另外，上述各个命令包含的参数将在下文中具体介绍，为了简洁，在此不再赘述。
上文介绍了本申请实施例中的第一客户端启动过程，下文介绍本申请实施例中第一客户端配置过程。
若配置设备确定第一设备中未配置第一客户端，则可以触发第一客户端配置过程。在一些实现方式中，配置设备可以读取第一设备中的长期用户列表，若长期用户列表中并未记录合适的第一客户端，则可以触发第一客户端配置过程。
例如，若配置设备确认长期用户列表中不包含与配置设备所在云平台相同的第一客户端，(即第一客户端的云地址与配置设备所在的云地址一致)，和/或，第一设备中第一客户端的用户ID与配置设备的用户ID不一致，则配置设备确定第一设备中未配置有连接云平台的第一客户端，此时，配置设备可以触发第一客户端配置过程。
通常，第一客户端需要基于接入令牌来接入云平台。在一些场景中，第一客户端可能需要多次接入云平台，如果第一客户端每次接入云平台使用的接入令牌相同，可能不利于提高云平台的安全性。例如，若第一客户端的用户类型为长期用户，用户可能会通过第一客户端多次接入云平台，此时，如果第一客户端的接入令牌不变，可能导致被攻击方截获，威胁云平台的安全。
因此，在本申请实施例中，云平台可以为第一客户端配置第一令牌(又称“更新令牌(refresh token)”)，用于第一客户端向云平台请求更新接入令牌。相应地，第一客户端可以基于更新后的接入令牌接入云平台。上述接入令牌的更新机制相比于一直使用相同的接入令牌接入云平台，有助于提高云平台的安全性。
在一些实现方式中，当第一设备原有的接入令牌到期后，第一设备可以基于第一令牌向云平台申请更新接入令牌。当然，本申请实施例对申请更新令牌的时机不作具体限定，例如，第一设备还可以在原有的接入令牌快到期时，基于第一令牌向云平台申请更新接入令牌。即，第一设备可以在目标时间基于第一令牌向云平台申请更新接入令牌，其中目标时间与原有的接入令牌的到期时间小于第一时间间隔。又例如，第一设备可以周期性地向云平台申请更新接入令牌，其中，接入令牌的更新周期可以小于或等于接入令牌的有效时间段。
在一些实现方式中，上述第一令牌可以承载于注册响应命令中。表17示出了本申请实施例的注册响应命令的接口参数。参见表17，注册响应命令可以包括接入令牌、令牌到期、用户标识以及第一令牌。其中，上述参数在命令中的位置、参数对应的值类型、参数的必要性以及参数的说明可以参见表17的介绍。
表17
Figure PCTCN2022117779-appb-000008
在一些场景中，第一客户端与第二设备之间可以采用AMTP协议进行通信。这种情况下，第一设备需要将第一客户端的访问地址发送给云平台，以便后续可以基于第一客户端的访问地址进行通信。即上述方法还包括：第一设备向云平台发送第三信息，第三信息中包括第一客户端的访问地址。其中，访问地址为基于AMTP协议的访问地址。
在一些实现方式中，若第三信息中携带第一客户端的访问地址，则云平台可以确定第一客户端选择AMTP协议进行通信，也就是说，第三信息还用于指示第一客户端支持的通信协议为AMTP协议。
在一些实现方式中，上述第三信息可以承载于注册请求中，其中，注册请求用于第一客户端请求在云平台上进行注册。下文结合表18介绍本申请实施例的注册请求中携带的参数。参见表18所示，注册请求可以包括接入令牌、第一客户端的客户端标识以及第一客户端的访问地址(例如，第一客户端统一资源定位器(client uniform resource locator，ClientURL))。另外，表18还示出了各个参数在命令中的位置、参数的值类型、参数的必要性以及参数的说明。
表18
Figure PCTCN2022117779-appb-000009
需要说明的是，注册请求的接口说明可以参见表3所示，为了简洁，在此不再赘述。
在另一些实现方式中，第三信息可以承载于登录请求中，登录请求用于第一客户端请求登录云平台。 下文结合表19介绍本申请实施例的登录请求命令中携带的参数。表19中的参数相比于表11所示的参数，增加了第一客户端访问地址(例如，ClientURL)。
表19
Figure PCTCN2022117779-appb-000010
需要说明的是，登录请求的接口说明可以参见表10所示，为了简洁，在此不再赘述。
相应地，如果第一客户端与第二设备之间基于AMTP协议进行通信，云平台可以向第一设备告知第二设备的访问地址，即第二设备基于AMTP协议的访问地址(又称“接入URL”)。也即是说，上述方法还包括：响应于第三信息，第一设备接收云平台发送的第四信息，第四信息中包括待访问的第二设备的访问地址。
相应地，当第一客户端登录云平台成功后，第一客户端可以基于第二设备的访问地址，与第二设备进行通信。例如，第一客户端可以基于第二设备的访问地址，向第二设备发送控制信息，以对第二设备进行控制。
在一些实现方式中，上述第四信息可以承载于针对注册请求的响应命令中，即注册响应命令。表20示出了本申请实施例的注册响应命令包含的参数。参见表20所示，注册响应命令包括接入令牌、用户标识以及接入URL，其中，接入URL用于指示第二设备的访问地址。另外，表20还示出了上述参数在注册响应命令中的位置、参数对应的值类型、参数的必要性以及参数的说明。
表20
Figure PCTCN2022117779-appb-000011
需要说明的是，注册请求的接口说明可以参见表3所示，为了简洁，在此不再赘述。
在另一些实现方式中，上述第四信息可以承载于针对登录请求的响应命令中，即登录响应命令。表21示出了本申请实施例的登录响应命令包含的参数。参见表21所示，登录响应命令包括接入令牌、第一客户端标识以及第一客户端的URL，其中，接入URL用于指示第二设备的访问地址。另外，表21还示出了上述参数在登录响应命令中的位置、参数对应的值类型、参数的必要性以及参数的说明。
表21
Figure PCTCN2022117779-appb-000012
需要说明的是，登录请求的接口说明可以参见表10所示，为了简洁，在此不再赘述。
在本申请实施例中，上文介绍的第三信息的传输方式与第四信息的传输方式可以单独使用，也可以 结合使用。例如，第三信息可以承载于登录请求中，相应地，第四信息可以承载于登录响应命令中。又例如，第三信息可以承载于注册请求中，相应地，第四信息可以承载于注册响应命令中。又例如，第三信息可以承载于注册请求中，相应地，第四信息可以承载于登录响应命令中。又例如，第三信息可以承载于注册响应中，相应地，第四信息可以承载于登录请求中。
另外，本申请实施例对上述第一客户端的访问地址与第二设备的访问地址的交互顺序不作限定。如上文所述，在一种实现方式中，可以由第一客户端先向云平台发送第一客户端的访问地址，然后，由云平台向第一客户端发送第二设备的访问地址。在另一种实现方式中，可以由云平台先向第一客户端发送第二设备的访问地址，然后，由第一客户端向云平台发送第一客户端的访问地址。例如，云平台可以通过注册响应命令向第一客户端发送第二设备的访问地址，然后，由第一客户端通过登录请求向云平台发送第一客户端的访问地址。
为了便于理解，下文结合图5和图6，以IOT场景为例介绍本申请实施例的方案。此时，上述云平台可以为IoT云平台，客户端为IoT客户端，第一设备可以为车载终端，第二设备可以为智能家居设备，配置设备为手机。另外，图5和图6中涉及的命令、信息功能集群与上文的介绍含义相同，并采用相同的名称，为了简洁可以参见上文介绍，下文不再赘述。
图5(a)～图5(c)是本申请实施例的通信方法的示意性流程图。图5(a)所示的方法包括步骤S511至步骤S527。
在步骤S511中，手机与车载终端建立安全连接。
例如，手机可以与车载终端通过蓝牙低能耗(bluetooth low energy，BLE)结合无线网络通信技术Wifi建立连接。
在步骤S512中，手机查看车载终端的客户端集群。
其中，客户端集群可以参见上文结合表12、表13和表16的介绍，为了简洁，在此不再赘述。
在步骤S513中，用户通过手机确认以车载终端为IoT客户端访问智能家居设备。
需要说明的是，步骤S513可以位于步骤S512之前，或者两个步骤同时进行，又或者，骤S512可以位于步骤S513之前，本申请实施例对此不作限定。
在步骤S514中，手机读取客户端集群中的长期用户列表，并确认长期用户列表中是否记录有合适的客户端。
若长期用户列表中包含与手机所在云平台相同的客户端，且该客户端的用户ID与手机的用户ID一致，则执行步骤S515。若长期用户列表中包含的客户端与手机所在云平台不同，或者客户端的用户ID与手机的用户ID不一致，则执行步骤S516。
在步骤S515中，手机向车载终端发送启动客户端请求命令，以请求启动该客户端。
在步骤S516中，手机提示用户选择长期模式或临时模式。
上述长期模式对应创建用户类型为长期用户的客户端，临时模式可以对应创建用户类型为临时用户的客户端。下文以用户选择创建长期用户的客户端为例进行说明，下文的方案也可以适用于创建临时用户。
在步骤S517中，手机向IoT客户端发送CSR请求命令。其中，CSR请求命令可以携带客户端的用户类型。
另外，CSR请求命令可以参见上文结合表6所示的介绍。
在步骤S518中，IoT客户端生成密钥对，并向手机发送CSR响应命令。其中，CSR响应命令可以参见上文结合表7的介绍。
在步骤S519中，手机向IoT云平台发送客户端申请请求命令，以通过IoT云接口申请IoT客户端证书及令牌。其中，客户端申请请求中携带客户端的用户类型。
另外，客户端申请请求包括的参数可以参见上文结合表8和表9的介绍。
在步骤S520中，IoT云平台向手机发送客户端申请响应命令。
在一些实现方式中，手机可以通过客户端申请响应接口获得IoT云平台返回的IoT客户端证书链及令牌。表22示出了本申请实施例中客户端申请响应命令中包含的参数，以及参数的值类型、参数的位置、参数的必要性以及参数的说明。
表22
位置 参数 值类型 必要性 说明
头部 互联网媒体类型 String 否 命令负载所使用的MIME类型
主体 CToken String 是 IoT客户端公钥加密的访问令牌
主体 证书链 String 是 为IoT客户端颁发的证书链
主体 令牌到期信息 Number 是 接入令牌的有效时长，当值为-1时表示接入
        令牌永久有效
在步骤S521中，手机向IoT客户端发送添加云请求命令，以请求客户端添加云。
其中，表23示出了本申请实施例的添加云请求命令包括的参数。参见表23，添加云请求命令可以包括IoT客户端证书、中间证书、根证书、云地址、CToken以及令牌到期信息。另外，表23中还示出了参数的标识、参数的数据类型、参数的约束、参数的质量、参数的默认值以及参数的必要性。
表23
ID 字段 数据类型 约束 质量 默认值 必要性
0 IOT客户端证书 octstring max400     M
1 中间证书 octstring max400     O
2 根证书 octstring max400     M
3 云地址 string       M
4 CToken octstring       M
5 令牌到期信息 uint16       M
在步骤S522中，IoT客户端利用密钥对中的私钥解密Ctoken，得到接入令牌。
在步骤S523中，IoT客户端向手机发送添加云响应命令。其中，添加云响应命令中包括客户端的启动口令。
通常，当IoT客户端的用户类型为长期用户时，手机可以存储添加云响应命令中的启动口令，并将启动口令与该IoT客户端的客户端ID、云地址进行关联。另外，添加云响应命令可以参见上文结合表14的相关介绍。
在步骤S524中，手机向车载终端发送启动客户端请求命令，以请求启动IoT客户端。其中，启动客户端请求命令可以参见上文关于表15所示的介绍。
需要说明的是，上述步骤S515和步骤S524可以理解为是发送启动客户端请求命令的两种场景。其中，步骤S515可以理解为是第一设备中配置有合适的客户端的情况下，配置设备可以通过步骤S515直接启动客户端。步骤S524可以理解为是第一设备中未配置有合适的客户端的情况下，配置设备在重新配置客户端之后可以通过步骤S524启动客户端。
在步骤S525中，IoT客户端校验启动客户端请求中的客户端ID对应的云地址和启动口令是否与客户端集群中记录的一致。
若启动客户端请求中的客户端ID对应的云地址和启动口令与客户端集群中记录的一致，则执行步骤S526。若启动客户端请求中的客户端ID对应的云地址和启动口令与客户端集群中记录的不一致，则执行步骤S527。
在步骤S526中，车载终端启动IoT客户端，并指示手机IoT客户端启动成功。
在步骤S527中，车载终端向手机指示IoT客户端启动失败。
在一些实现方式中，车载终端可以向手机指示IoT客户端启动失败的原因，例如，IoT客户端的启动口令错误，IoT客户端的客户端ID不存在等。
需要说明的是，上述客户端配置过程中，云平台可以按照步骤S317至步骤S320所示的方法，生成CToken并建立绑定关系，为了简洁，可以参见上文的介绍。
上文结合步骤S511至步骤S527介绍了客户端配置过程以及客户端启动过程。若IoT客户端启动成功，下文结合图5(b)介绍客户端注册过程。图5(b)所示的方法包括步骤S531至步骤S533。
在步骤S531中，IoT客户端连接IoT云地址，并使用证书与IoT云平台建立安全连接。
在步骤S532中，IoT客户端向IoT云平台发送客户端注册请求，以请求在IoT云平台上进行客户端注册。
在一些实现方式中，客户端注册请求可以包括客户端ID和接入令牌。其中，客户端注册请求可以参见上文结合表3的介绍。
在步骤S533中，响应于客户端注册请求，IoT云平台向IoT客户端发送客户端注册响应命令。
在一些场景中，客户端注册响应命令可以携带IoT云平台为IoT客户端分配的新的接入令牌、用户 ID、第一令牌。其中，客户端注册响应命令可以参见上文结合表5的介绍。
下文结合图5(c)介绍本申请实施例中的客户端登录过程。图5(c)所示的方法包括步骤S541至步骤S542。
在步骤S541中，IoT客户端向IoT云平台发送登录请求，以请求登录IoT云平台。
在一些实现方式中，上述登录请求包括用户ID、客户端ID和接入令牌。可以参见上文结合表11的介绍。
在步骤S542中，响应于登录请求，IoT云平台向IoT客户端发送登录响应命令。
表24示出了本申请实施例的登录响应命令的一种可能的实现方式。参见表24所示，登录响应命令可以包括互联网媒体类型以及令牌到期信息。
表24
Figure PCTCN2022117779-appb-000013
图6(a)～图6(c)是本申请另一实施例的通信方法的示意性流程图。图6(a)所示的方法包括步骤S611至步骤S627。需要说明的是，图6所示的方法可以适用于客户端采用AMTP协议与智能家居设备通信。
在步骤S611中，手机与车载终端建立安全连接。
在步骤S612中，手机查看车载终端的客户端集群。
其中，客户端集群可以参见上文结合表12、表13和表16的介绍，为了简洁，在此不再赘述。
在步骤S613中，用户通过手机确认以车载终端为IoT客户端访问智能家居设备。
需要说明的是，步骤S613可以位于步骤S612之前，或者两个步骤同时进行，又或者，骤S612可以位于步骤S613之前，本申请实施例对此不作限定。
在步骤S614中，手机读取客户端集群中的长期用户列表，并确认长期用户列表中是否记录有合适的客户端。
若长期用户列表中包含与手机所在云平台相同的客户端，且该客户端的用户ID与手机的用户ID一致，则执行步骤S615。若长期用户列表中包含的客户端与手机所在云平台不同，或者客户端的用户ID与手机的用户ID不一致，则执行步骤S616。
在步骤S615中，手机向车载终端发送启动客户端请求命令，以请求启动该客户端。
在步骤S616中，手机提示用户选择长期模式或临时模式。
上述长期模式对应创建用户类型为长期用户的客户端，临时模式可以对应创建用户类型为临时用户的客户端。下文以用户选择创建长期用户的客户端为例进行说明，下文的方案也可以适用于创建临时用户。
在步骤S617中，手机向IoT客户端发送CSR请求命令。其中，CSR请求命令可以携带客户端的用户类型。
另外，CSR请求命令可以参见上文结合表16所示的介绍。
在步骤S618中，IoT客户端生成密钥对，并向手机发送CSR响应命令。其中，CSR响应命令可以参见上文结合表17的介绍。
在步骤S619中，手机向IoT云平台发送客户端申请请求命令，以通过IoT云接口申请IoT客户端证书及令牌。其中，客户端申请请求中携带客户端的用户类型。
另外，客户端申请请求包括的参数可以参见上文结合表8和表9的介绍。
在步骤S620中，IoT云平台向手机发送客户端申请响应命令。
在一些实现方式中，手机可以通过客户端申请响应接口获得IoT云平台返回的IoT客户端证书链及令牌。表25示出了本申请实施例中客户端申请响应命令中包含的参数，以及参数的值类型、参数的位置、参数的必要性以及参数的说明。
表25
Figure PCTCN2022117779-appb-000014
在步骤S621中，手机向IoT客户端发送添加云请求命令，以请求客户端添加云。
其中，表26示出了本申请实施例的添加云请求命令包括的参数。参见表26，添加云请求命令可以包括IoT客户端证书、中间证书、根证书、云地址、CToken以及令牌到期信息。另外，表26中还示出了参数的标识、参数的数据类型、参数的约束、参数的质量、参数的默认值以及参数的必要性。
表26
ID 字段 数据类型 约束 质量 默认值 必要性
0 IOT客户端证书 octstring max400     M
1 中间证书 octstring max400     O
2 根证书 octstring max400     M
3 云地址 string       M
4 CToken octstring       M
5 令牌到期信息 uint16       M
在步骤S622中，IoT客户端利用密钥对中的私钥解密Ctoken，得到接入令牌。
在步骤S623中，IoT客户端向手机发送添加云响应命令。其中，添加云响应命令中包括客户端的启动口令。
通常，当IoT客户端的用户类型为长期用户时，手机可以存储添加云响应命令中的启动口令，并将启动口令与该IoT客户端的客户端ID、云地址进行关联。另外，添加云响应命令可以参见上文结合表14的相关介绍。
在步骤S624中，手机向车载终端发送启动客户端请求命令，以请求启动IoT客户端。其中，启动客户端请求命令可以参见上文关于表15所示的介绍。
需要说明的是，上述步骤S615和步骤S624可以理解为是发送启动客户端请求命令的两种场景。其中，步骤S615可以理解为是第一设备中配置有合适的客户端的情况下，配置设备可以通过步骤S615直接启动客户端。步骤S624可以理解为是第一设备中未配置有合适的客户端的情况下，配置设备在重新配置客户端之后可以通过步骤S624启动客户端。
在步骤S625中，IoT客户端校验启动客户端请求中的客户端ID对应的云地址和启动口令是否与客户端集群中记录的一致。
若启动客户端请求中的客户端ID对应的云地址和启动口令与客户端集群中记录的一致，则执行步骤S626。若启动客户端请求中的客户端ID对应的云地址和启动口令与客户端集群中记录的不一致，则执行步骤S627。
在步骤S626中，车载终端启动IoT客户端，并指示手机IoT客户端启动成功。
在步骤S627中，车载终端向手机指示IoT客户端启动失败。
在一些实现方式中，车载终端可以向手机指示IoT客户端启动失败的原因，例如，IoT客户端的启动口令错误，IoT客户端的客户端ID不存在等。
需要说明的是，上述客户端配置过程中，云平台可以按照步骤S317至步骤S320所示的方法，生成CToken并建立绑定关系，为了简洁，可以参见上文的介绍。
上文结合步骤S611至步骤S627介绍了客户端配置过程以及客户端启动过程。若IoT客户端启动成功，下文结合图6(b)介绍客户端注册过程。图6(b)所示的方法包括步骤S631至步骤S633。
在步骤S631中，IoT客户端连接IoT云地址，并使用证书与IoT云建立安全连接。
在步骤S632中，IoT客户端向IoT云平台发送客户端注册请求，以请求在IoT云平台上进行客户端注册。
在一些实现方式中，客户端注册请求可以包括客户端ID、接入令牌以及IoT客户端的访问地址。其中，客户端注册请求可以参见上文结合表18的介绍。
在步骤S633中，响应于客户端注册请求，IoT云平台向IoT客户端发送客户端注册响应命令。
在一些场景中，客户端注册响应命令可以携带IoT云平台为IoT客户端分配的新的接入令牌、用户ID、第一令牌、以及智能家居设备的访问地址。其中，客户端注册响应命令可以参见上文结合表20的 介绍。
下文结合图6(c)介绍本申请实施例中的客户端登录过程。图6(c)所示的方法包括步骤S641至步骤S642。
在步骤S641中，IoT客户端向IoT云平台发送登录请求，以请求登录IoT云平台。
在一些实现方式中，上述登录请求包括用户ID、客户端ID和接入令牌。可以参见上文结合表11的介绍。
在步骤S642中，响应于登录请求，IoT云平台向IoT客户端发送登录响应命令。
表27示出了本申请实施例的登录响应命令的一种可能的实现方式。参见表27所示，登录响应命令可以包括互联网媒体类型以及令牌到期信息。
表27
Figure PCTCN2022117779-appb-000015
需要说明的是，在本申请实施例中，除了按照图6所示的方法通过注册请求以及注册响应命令，交互IoT客户端的访问地址以及智能家居设备的访问地址。另外，如上文的介绍IoT客户端的访问地址以及智能家居设备的访问地址，也可以通过登录请求以及登录响应命令交互，例如，可以采用表19和表21所介绍的命令。此时，客户端注册请求以及客户端注册响应可以结合表3和表5所介绍的命令。为了简洁，下文不再赘述。
上文结合图1至图6，详细描述了本申请的方法实施例，下面结合图7至图12，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图7是本申请实施例的第一设备的示意图。图7所示的第一设备700包括：处理单元710。
处理单元710，用于通过第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。
在一种可能的实现方式中，所述第一设备还包括：接收单元，用于接收配置设备发送的第一指示信息，所述第一指示信息用于指示所述第一客户端的用户类型。
在一种可能的实现方式中，所述第一设备中包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或，所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
在一种可能的实现方式中，所述功能集群用于指示所述第一客户端的以下一种或多种信息：所述第一客户端的客户端标识；所述第一客户端的用户标识；以及所述云平台的指示信息。
在一种可能的实现方式中，所述功能集群包括以下一种或多种命令：用于指示启动所述第一客户端的第一请求；用于指示所述第一客户端添加所述云平台的第二请求；针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；用于请求所述第一客户端的CSR的第三请求；以及针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
在一种可能的实现方式中，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
在一种可能的实现方式中，若所述功能集群包括所述第二请求，所述第二请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
在一种可能的实现方式中，若所述功能集群包括所述针对所述第二请求的响应命令，针对所述第二请求的响应命令包括指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
在一种可能的实现方式中，所述第一设备还包括：第一发送单元，用于向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
在一种可能的实现方式中，所述第一设备还包括：第二发送单元，用于向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
在一种可能的实现方式中，所述第一客户端的用户类型是由用户通过配置设备配置的。
在一种可能的实现方式中，所述第一设备中客户端的用户类型包括长期用户或临时用户。
图8是本申请实施例的配置设备的示意图，图8所示的配置设备800包括发送单元810。
发送单元810，用于向第一设备发送第一指示信息，所述第一指示信息用于指示所述第一设备中的第一客户端的用户类型；和/或，向云平台发送第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型，其中，所述第一客户端的用户类型为长期用户，且所述第一客户端用于与所述云平台 通信。
在一种可能的实现方式中，所述第一设备包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或，所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
在一种可能的实现方式中，所述功能集群用于指示所述第一客户端的以下一种或多种信息：所述第一客户端的客户端标识；所述第一客户端的用户标识；以及所述云平台的指示信息。
在一种可能的实现方式中，所述功能集群包括以下一种或多种命令：用于指示启动所述第一客户端的第一请求；用于指示所述第一客户端添加所述云平台的第二请求；针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；用于请求所述第一客户端的CSR的第三请求；以及针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
在一种可能的实现方式中，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
在一种可能的实现方式中，若所述功能集群包括所述第二请求，所述第二请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
在一种可能的实现方式中，若所述功能集群包括所述针对所述第二请求的响应命令，所述针对第二请求的响应命令包括：指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
在一种可能的实现方式中，所述第一客户端的用户类型是由用户通过所述配置设备配置的。
在一种可能的实现方式中，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
图9是本申请实施例的云平台的示意图，图9所示的云平台900包括通信单元910。
通信单元910，用于与第一设备中的第一客户端进行通信，所述第一客户端的用户类型为长期用户。
在一种可能的实现方式中，所述通信单元还用于：接收配置设备发送的第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型。
在一种可能的实现方式中，所述第二指示信息承载于客户端申请请求中。
在一种可能的实现方式中，所述通信单元还用于：接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
在一种可能的实现方式中，所述云平台还包括：第一处理单元，用于响应于所述第四请求，登出所述第一客户端。
在一种可能的实现方式中，所述通信单元，还用于：接收所述第一设备发送的第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
在一种可能的实现方式中，所述通信单元，还用于接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；第二处理单元，用于若所述第二客户端与所述第一客户端相同，拒绝所述第六请求。
在一种可能的实现方式中，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
图10是本申请实施例的第一设备的示意图。其中，第一设备配置有第一客户端，并存储有用于所述第一客户端登录云平台的第一信息，图10所示的第一设备1000包括发送单元1010。
发送单元1010，用于基于所述第一信息向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
在一种可能的实现方式中，所述第一信息包括以下信息中的一种或多种：所述第一客户端登录所述云平台的接入令牌；所述第一客户端的客户端标识；所述第一客户端的用户标识；以及所述云平台的指示信息。
在一种可能的实现方式中，所述发送单元，用于向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
在一种可能的实现方式中，所述第一设备中客户端的用户类型包括长期用户或临时用户。
在一种可能的实现方式中，所述第一客户端的用户类型为长期用户。
图11是本申请实施例的云平台的示意图。图11所示的云平台1100包括接收单元1110。
接收单元1110，用于接收第一设备发送的第五请求，所述第五请求用于所述第一设备中的第一客户端请求重新登录所述云平台。
在一种可能的实现方式中，所述云平台存储有用于所述第一客户端登录所述云平台的第二信息，所述云平台还包括：第一处理单元，用于响应于所述第五请求，基于所述第二信息确定是否允许所述第一客户端重新登录。
在一种可能的实现方式中，所述第二信息包括以下信息中的一种或多种：所述第一客户端登录所述云平台的接入令牌；所述第一客户端的客户端标识；所述第一客户端的用户标识；以及所述第一客户端的用户类型。
在一种可能的实现方式中，所述接收单元，用于：接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
在一种可能的实现方式中，所述云平台还包括第二处理单元，若所述第一客户端的用户类型为长期用户，响应于所述第四请求，所述第二处理单元用于登出所述第一客户端；和/或，若所述第一客户端的用户类型为临时用户，响应于所述第四请求，所述第二处理单元用于注销或拒绝登出所述第一客户端。
在一种可能的实现方式中，所述接收单元，用于接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；若所述第二客户端与所述第一客户端相同，第三处理单元，用于拒绝所述第六请求。
在一种可能的实现方式中，所述第一客户端的用户类型为长期用户。
在可选的实施例中，所述处理单元710可以为处理器1210。第一设备700还可以包括收发器1230和存储器1220，具体如图12所示。
在可选的实施例中，所述发送单元810可以为收发器1240。配置设备800还可以包括处理器1210和存储器1220，具体如图12所示。
在可选的实施例中，所述通信单元910可以为收发器1240。云平台900还可以包括处理器1210和存储器1220，具体如图12所示。
在可选的实施例中，所述发送单元1010可以为收发器1240。第一设备1000还可以包括处理器1210和存储器1220，具体如图12所示。
在可选的实施例中，所述接收单元1110可以为收发器1240。云平台1100还可以包括处理器1210和存储器1220，具体如图12所示。
图12是本申请实施例的通信装置的示意性结构图。图12中的虚线表示该单元或模块为可选的。该装置1200可用于实现上述方法实施例中描述的方法。装置1200可以是芯片、终端设备或网络设备。
装置1200可以包括一个或多个处理器1210。该处理器1210可支持装置1200实现前文方法实施例所描述的方法。该处理器1210可以是通用处理器或者专用处理器。例如，该处理器可以为中央处理单元(central processing unit，CPU)。或者，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
装置1200还可以包括一个或多个存储器1220。存储器1220上存储有程序，该程序可以被处理器1210执行，使得处理器1210执行前文方法实施例所描述的方法。存储器1220可以独立于处理器1210也可以集成在处理器1210中。
装置1200还可以包括收发器1230。处理器1210可以通过收发器1230与其他设备或芯片进行通信。例如，处理器1210可以通过收发器1230与其他设备或芯片进行数据收发。
本申请实施例还提供一种计算机可读存储介质，用于存储程序。该计算机可读存储介质可应用于本申请实施例提供的终端或网络设备中，并且该程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
本申请实施例还提供一种计算机程序产品。该计算机程序产品包括程序。该计算机程序产品可应用于本申请实施例提供的终端或网络设备中，并且该程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
本申请实施例还提供一种计算机程序。该计算机程序可应用于本申请实施例提供的终端或网络设备中，并且该计算机程序使得计算机执行本申请各个实施例中的由终端或网络设备执行的方法。
应理解，本申请中术语“系统”和“网络”可以被可互换使用。另外，本申请使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。
在本申请的实施例中，提到的“指示”可以是直接指示，也可以是间接指示，还可以是表示具有关联关系。举例说明，A指示B，可以表示A直接指示B，例如B可以通过A获取；也可以表示A间接指示B，例如A指示C，B可以通过C获取；还可以表示A和B之间具有关联关系。
在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
在本申请实施例中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。
本申请实施例中，“预定义”或“预配置”可以通过在设备(例如，包括终端设备和网络设备)中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。比如预定义可以是指协议中定义的。
本申请实施例中，所述“协议”可以指通信领域的标准协议，例如可以包括LTE协议、NR协议以及应用于未来的通信系统中的相关协议，本申请对此不做限定。
本申请实施例中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(digital video disc，DVD))或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (90)

  1. 一种通信方法，其特征在于，包括：
    第一设备中的第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。
  2. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    所述第一设备接收配置设备发送的第一指示信息，所述第一指示信息用于指示所述第一客户端的用户类型。
  3. 如权利要求1或2所述的方法，其特征在于，所述第一设备中包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或
    所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
  4. 如权利要求3所述的方法，其特征在于，所述功能集群用于指示所述第一客户端的以下一种或多种信息：
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  5. 如权利要求4所述的方法，其特征在于，所述功能集群包括以下一种或多种命令：
    用于指示启动所述第一客户端的第一请求；
    用于指示所述第一客户端添加所述云平台的第二请求；
    针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；
    用于请求所述第一客户端的CSR的第三请求；以及
    针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
  6. 如权利要求5所述的方法，其特征在于，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
  7. 如权利要求5所述的方法，其特征在于，若所述功能集群包括所述第二请求，所述第二请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
  8. 如权利要求5所述的方法，其特征在于，若所述功能集群包括所述针对所述第二请求的响应命令，针对所述第二请求的响应命令包括指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
  9. 如权利要求1-8中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一设备向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  10. 如权利要求1-9中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一设备向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  11. 如权利要求1-10中任一项所述的方法，其特征在于，所述第一客户端的用户类型是由用户通过配置设备配置的。
  12. 如权利要求1-11中任一项所述的方法，其特征在于，所述第一设备中客户端的用户类型包括长期用户或临时用户。
  13. 一种通信方法，其特征在于，包括：
    配置设备向第一设备发送第一指示信息，所述第一指示信息用于指示所述第一设备中的第一客户端的用户类型；和/或
    所述配置设备向云平台发送第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型，
    其中，所述第一客户端的用户类型为长期用户，且所述第一客户端用于与所述云平台通信。
  14. 如权利要求13所述的方法，其特征在于，所述第一设备包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或
    所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
  15. 如权利要求14所述的方法，其特征在于，所述功能集群用于指示所述第一客户端的以下一种或多种信息：
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  16. 如权利要求14或15所述的方法，其特征在于，所述功能集群包括以下一种或多种命令：
    用于指示启动所述第一客户端的第一请求；
    用于指示所述第一客户端添加所述云平台的第二请求；
    针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；
    用于请求所述第一客户端的CSR的第三请求；以及
    针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
  17. 如权利要求16所述的方法，其特征在于，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
  18. 如权利要求16所述的方法，其特征在于，若所述功能集群包括所述第二请求，所述第二请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
  19. 如权利要求16所述的方法，其特征在于，若所述功能集群包括所述针对所述第二请求的响应命令，所述针对第二请求的响应命令包括：指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
  20. 如权利要求13-19中任一项所述的方法，其特征在于，所述第一客户端的用户类型是由用户通过所述配置设备配置的。
  21. 如权利要求13-20中任一项所述的方法，其特征在于，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
  22. 一种通信方法，其特征在于，包括：
    云平台与第一设备中的第一客户端进行通信，所述第一客户端的用户类型为长期用户。
  23. 如权利要求22所述的方法，其特征在于，所述方法还包括：
    所述云平台接收配置设备发送的第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型。
  24. 如权利要求23所述的方法，其特征在于，所述第二指示信息承载于客户端申请请求中。
  25. 如权利要求22-24中任一项所述的方法，其特征在于，所述方法还包括：
    所述云平台接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  26. 如权利要求25所述的方法，其特征在于，所述方法还包括：
    响应于所述第四请求，所述云平台登出所述第一客户端。
  27. 如权利要求22-26中任一项所述的方法，其特征在于，所述方法还包括：
    所述云平台接收所述第一设备发送的第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  28. 如权利要求22-27中任一项所述的方法，其特征在于，所述方法还包括：
    所述云平台接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；
    若所述第二客户端与所述第一客户端相同，所述云平台拒绝所述第六请求。
  29. 如权利要求22-28中任一项所述的方法，其特征在于，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
  30. 一种通信方法，其特征在于，第一设备配置有第一客户端，并存储有用于所述第一客户端登录云平台的第一信息，所述方法包括：
    所述第一设备基于所述第一信息向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  31. 如权利要求30所述的方法，其特征在于，所述第一信息包括以下信息中的一种或多种：
    所述第一客户端登录所述云平台的接入令牌；
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  32. 如权利要求30或31所述的方法，其特征在于，所述方法还包括：
    所述第一设备向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  33. 如权利要求30-32中任一项所述的方法，其特征在于，所述第一设备中客户端的用户类型包括长期用户或临时用户。
  34. 如权利要求30-33中任一项所述的方法，其特征在于，所述第一客户端的用户类型为长期用户。
  35. 一种通信方法，其特征在于，包括：
    云平台接收第一设备发送的第五请求，所述第五请求用于所述第一设备中的第一客户端请求重新登录所述云平台。
  36. 如权利要求35所述的方法，其特征在于，所述云平台存储有用于所述第一客户端登录所述云平台的第二信息，所述方法还包括：
    响应于所述第五请求，所述云平台基于所述第二信息确定是否允许所述第一客户端重新登录。
  37. 如权利要求36所述的方法，其特征在于，所述第二信息包括以下信息中的一种或多种：
    所述第一客户端登录所述云平台的接入令牌；
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述第一客户端的用户类型。
  38. 如权利要求35-37中任一项所述的方法，其特征在于，所述方法还包括：
    所述云平台接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  39. 如权利要求38所述的方法，其特征在于，所述方法还包括：
    若所述第一客户端的用户类型为长期用户，响应于所述第四请求，所述云平台登出所述第一客户端；和/或
    若所述第一客户端的用户类型为临时用户，响应于所述第四请求，所述云平台注销或拒绝登出所述第一客户端。
  40. 如权利要求35-39中任一项所述的方法，其特征在于，所述方法还包括：
    所述云平台接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；
    若所述第二客户端与所述第一客户端相同，所述云平台拒绝所述第六请求。
  41. 如权利要求35-40中任一项所述的方法，其特征在于，所述第一客户端的用户类型为长期用户。
  42. 一种第一设备，其特征在于，包括：
    处理单元，用于通过第一客户端与云平台进行通信，所述第一客户端的用户类型为长期用户。
  43. 如权利要求42所述的第一设备，其特征在于，所述第一设备还包括：
    接收单元，用于接收配置设备发送的第一指示信息，所述第一指示信息用于指示所述第一客户端的用户类型。
  44. 如权利要求42或43所述的第一设备，其特征在于，所述第一设备中包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或
    所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
  45. 如权利要求44所述的第一设备，其特征在于，所述功能集群用于指示所述第一客户端的以下一种或多种信息：
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  46. 如权利要求45所述的第一设备，其特征在于，所述功能集群包括以下一种或多种命令：
    用于指示启动所述第一客户端的第一请求；
    用于指示所述第一客户端添加所述云平台的第二请求；
    针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；
    用于请求所述第一客户端的CSR的第三请求；以及
    针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
  47. 如权利要求46所述的第一设备，其特征在于，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
  48. 如权利要求46所述的第一设备，其特征在于，若所述功能集群包括所述第二请求，所述第二 请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
  49. 如权利要求46所述的第一设备，其特征在于，若所述功能集群包括所述针对所述第二请求的响应命令，针对所述第二请求的响应命令包括指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
  50. 如权利要求42-49中任一项所述的第一设备，其特征在于，所述第一设备还包括：
    第一发送单元，用于向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  51. 如权利要求42-50中任一项所述的第一设备，其特征在于，所述第一设备还包括：
    第二发送单元，用于向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  52. 如权利要求42-51中任一项所述的第一设备，其特征在于，所述第一客户端的用户类型是由用户通过配置设备配置的。
  53. 如权利要求42-52中任一项所述的第一设备，其特征在于，所述第一设备中客户端的用户类型包括长期用户或临时用户。
  54. 一种配置设备，其特征在于，包括：
    发送单元，用于向第一设备发送第一指示信息，所述第一指示信息用于指示所述第一设备中的第一客户端的用户类型；和/或
    向云平台发送第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型，
    其中，所述第一客户端的用户类型为长期用户，且所述第一客户端用于与所述云平台通信。
  55. 如权利要求54所述的配置设备，其特征在于，所述第一设备包括功能集群，所述功能集群用于指示所述第一客户端支持的命令；和/或
    所述功能集群用于记录所述第一设备中用户类型为长期用户的客户端。
  56. 如权利要求55所述的配置设备，其特征在于，所述功能集群用于指示所述第一客户端的以下一种或多种信息：
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  57. 如权利要求55或56所述的配置设备，其特征在于，所述功能集群包括以下一种或多种命令：
    用于指示启动所述第一客户端的第一请求；
    用于指示所述第一客户端添加所述云平台的第二请求；
    针对所述第二请求的响应命令，其中，针对所述第二请求的响应命令用于指示所述云平台是否添加成功；
    用于请求所述第一客户端的CSR的第三请求；以及
    针对所述第三请求的响应命令，其中，针对所述第三请求的响应命令用于向所述云平台请求所述第一客户端进行身份验证的证书。
  58. 如权利要求57所述的配置设备，其特征在于，若所述功能集群包括所述第一请求，所述第一请求包括所述第一客户端的启动口令，和/或，所述云平台的指示信息。
  59. 如权利要求57所述的配置设备，其特征在于，若所述功能集群包括所述第二请求，所述第二请求包括以下信息中的一种或多种：所述第一客户端在所述云平台进行身份验证的证书信息，所述云平台的指示信息，以及所述云平台的接入令牌信息。
  60. 如权利要求57所述的配置设备，其特征在于，若所述功能集群包括所述针对所述第二请求的响应命令，所述针对第二请求的响应命令包括：指示所述云平台是否添加成功的信息，和/或，所述第一客户端的启动口令。
  61. 如权利要求54-60中任一项所述的配置设备，其特征在于，所述第一客户端的用户类型是由用户通过所述配置设备配置的。
  62. 如权利要求54-61中任一项所述的配置设备，其特征在于，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
  63. 一种云平台，其特征在于，包括：
    通信单元，用于与第一设备中的第一客户端进行通信，所述第一客户端的用户类型为长期用户。
  64. 如权利要求63所述的云平台，其特征在于，所述通信单元，还用于：
    接收配置设备发送的第二指示信息，所述第二指示信息用于指示所述第一客户端的用户类型。
  65. 如权利要求64所述的云平台，其特征在于，所述第二指示信息承载于客户端申请请求中。
  66. 如权利要求63-65中任一项所述的云平台，其特征在于，所述通信单元还用于：
    接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  67. 如权利要求66所述的云平台，其特征在于，所述云平台还包括：
    第一处理单元，用于响应于所述第四请求，登出所述第一客户端。
  68. 如权利要求63-67中任一项所述的云平台，其特征在于，所述通信单元还用于：
    接收所述第一设备发送的第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  69. 如权利要求63-68中任一项所述的云平台，其特征在于，
    所述通信单元，还用于接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；
    第二处理单元，用于若所述第二客户端与所述第一客户端相同，拒绝所述第六请求。
  70. 如权利要求63-69中任一项所述的云平台，其特征在于，所述第一设备中的客户端的用户类型包括长期用户或临时用户。
  71. 一种第一设备，其特征在于，所述第一设备配置有第一客户端，并存储有用于所述第一客户端登录云平台的第一信息，所述第一设备包括：
    发送单元，用于基于所述第一信息向所述云平台发送第五请求，所述第五请求用于所述第一客户端请求重新登录所述云平台。
  72. 如权利要求71所述的第一设备，其特征在于，所述第一信息包括以下信息中的一种或多种：
    所述第一客户端登录所述云平台的接入令牌；
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述云平台的指示信息。
  73. 如权利要求71或72所述的第一设备，其特征在于，所述发送单元，用于：
    向所述云平台发送第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  74. 如权利要求71-73中任一项所述的第一设备，其特征在于，所述第一设备中客户端的用户类型包括长期用户或临时用户。
  75. 如权利要求71-74中任一项所述的第一设备，其特征在于，所述第一客户端的用户类型为长期用户。
  76. 一种云平台，其特征在于，包括：
    接收单元，用于接收第一设备发送的第五请求，所述第五请求用于所述第一设备中的第一客户端请求重新登录所述云平台。
  77. 如权利要求76所述的云平台，其特征在于，所述云平台存储有用于所述第一客户端登录所述云平台的第二信息，所述云平台还包括：
    第一处理单元，用于响应于所述第五请求，基于所述第二信息确定是否允许所述第一客户端重新登录。
  78. 如权利要求77所述的云平台，其特征在于，所述第二信息包括以下信息中的一种或多种：
    所述第一客户端登录所述云平台的接入令牌；
    所述第一客户端的客户端标识；
    所述第一客户端的用户标识；以及
    所述第一客户端的用户类型。
  79. 如权利要求76-78中任一项所述的云平台，其特征在于，所述接收单元，用于：
    接收所述第一设备发送的第四请求，所述第四请求用于请求所述第一客户端登出所述云平台。
  80. 如权利要求79所述的云平台，其特征在于，所述云平台还包括第二处理单元，
    若所述第一客户端的用户类型为长期用户，响应于所述第四请求，所述第二处理单元用于登出所述第一客户端；和/或
    若所述第一客户端的用户类型为临时用户，响应于所述第四请求，所述第二处理单元用于注销或拒绝登出所述第一客户端。
  81. 如权利要求76-80中任一项所述的云平台，其特征在于，所述接收单元，用于接收配置设备发送的第六请求，所述第六请求用于向所述云平台申请第二客户端；
    若所述第二客户端与所述第一客户端相同，第三处理单元，用于拒绝所述第六请求。
  82. 如权利要求76-81中任一项所述的云平台，其特征在于，所述第一客户端的用户类型为长期用户。
  83. 一种第一设备，其特征在于，包括收发器、存储器和处理器，所述存储器用于存储程序，所述处理器用于调用所述存储器中的程序，并控制所述收发器接收或发送信号，以使所述第一设备执行如权利要求1-12以及30-34中任一项所述的方法。
  84. 一种云平台，其特征在于，包括收发器、存储器和处理器，所述存储器用于存储程序，所述处理器用于调用所述存储器中的程序，并控制所述收发器接收或发送信号，以使所述云平台执行如权利要求22-29以及35-41中任一项所述的方法。
  85. 一种配置设备，其特征在于，包括收发器、存储器和处理器，所述存储器用于存储程序，所述处理器用于调用所述存储器中的程序，并控制所述收发器接收或发送信号，以使所述配置设备执行如权利要求13-21中任一项所述的方法。
  86. 一种装置，其特征在于，包括处理器，用于从存储器中调用程序，以使所述装置执行如权利要求1-41中任一项所述的方法。
  87. 一种芯片，其特征在于，包括处理器，用于从存储器调用程序，使得安装有所述芯片的设备执行如权利要求1-41中任一项所述的方法。
  88. 一种计算机可读存储介质，其特征在于，其上存储有程序，所述程序使得计算机执行如权利要求1-41中任一项所述的方法。
  89. 一种计算机程序产品，其特征在于，包括程序，所述程序使得计算机执行如权利要求1-41中任一项所述的方法。
  90. 一种计算机程序，其特征在于，所述计算机程序使得计算机执行如权利要求1-41中任一项所述的方法。
PCT/CN2022/117779 2022-09-08 2022-09-08 通信方法、第一设备、配置设备以及云平台 WO2024050753A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/117779 WO2024050753A1 (zh) 2022-09-08 2022-09-08 通信方法、第一设备、配置设备以及云平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/117779 WO2024050753A1 (zh) 2022-09-08 2022-09-08 通信方法、第一设备、配置设备以及云平台

Publications (1)

Publication Number Publication Date
WO2024050753A1 true WO2024050753A1 (zh) 2024-03-14

Family

ID=90192701

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/117779 WO2024050753A1 (zh) 2022-09-08 2022-09-08 通信方法、第一设备、配置设备以及云平台

Country Status (1)

Country Link
WO (1) WO2024050753A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108200022A (zh) * 2017-12-22 2018-06-22 新华三云计算技术有限公司 一种云平台接入方法、装置及多云平台管理系统
EP3413508A1 (en) * 2017-06-06 2018-12-12 Thomson Licensing Devices and methods for client device authentication
CN113112621A (zh) * 2021-04-12 2021-07-13 泉州市巨将机电设备有限公司 一种基于app和二维码的区域化车位共享管理系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3413508A1 (en) * 2017-06-06 2018-12-12 Thomson Licensing Devices and methods for client device authentication
CN108200022A (zh) * 2017-12-22 2018-06-22 新华三云计算技术有限公司 一种云平台接入方法、装置及多云平台管理系统
CN113112621A (zh) * 2021-04-12 2021-07-13 泉州市巨将机电设备有限公司 一种基于app和二维码的区域化车位共享管理系统

Similar Documents

Publication Publication Date Title
US11128612B1 (en) Zero-touch provisioning of IoT devices with multi factor authentication
US10965473B2 (en) Smart object identification in the digital home
US10630647B2 (en) Secure wireless communication between controllers and accessories
EP3679709B1 (en) Automated service enrollment in a machine-to-machine communications network
JP5981662B2 (ja) 無線通信システムにおいて接近権限認証のための方法及び装置
US10951592B2 (en) Secure wireless communication between controllers and accessories
EP3355521B1 (en) Smart home service server and control method therefor
KR101741967B1 (ko) 에이전트 디바이스를 제1 디바이스 레지스트리로부터 제2 디바이스 레지스트리로 할당하기 위한 방법
US10708769B2 (en) Cloud assisted accessory pairing
US20170339159A1 (en) Registering apparatus, terminal apparatus, registering method, and non-transitory computer readable storage medium
US20230208831A1 (en) Service processing method and apparatus, server, and storage medium
US11394534B2 (en) Electronic device sharing key with external electronic device and operating method for electronic device
CN113612747B (zh) 设备控制权限的设置方法、装置、计算机设备和存储介质
CN113596141B (zh) 设备控制权限的设置方法、装置、计算机设备和存储介质
WO2024050753A1 (zh) 通信方法、第一设备、配置设备以及云平台
JP4683587B2 (ja) 通信制御装置及び方法
WO2024050754A1 (zh) 用于启动客户端的方法、第一设备、配置设备及云平台
JP7474302B2 (ja) 通信ネットワークにおける自動サービス登録
US20200295927A1 (en) Management of groups of connected objects using wireless communication protocols
US20220141658A1 (en) One-time wireless authentication of an internet-of-things device
WO2023230983A1 (zh) 建立互操作通道的方法、装置、芯片和存储介质