Method for bringing device online , electronic device, and computer-readable storage medium

Abstract

Provided in the present application are a method for bringing a device online, an electronic device, and a computer-readable storage medium. The method comprises: receiving a first message, wherein the first message comprises identification information, first verification data and first version number of a second device, the first verification data is obtained on the basis of a valid communication key currently stored in the second device, and the first version number is a version number of device information which currently corresponds to the second device and is required for bringing online; on the basis of the first verification data, determining that a communication key which is currently stored in a first device and corresponds to the second device is valid, and on the basis of the first version number, determining that device information which is currently stored in the first device, corresponds to the second device and is required for bringing online is valid; and bringing the second device online. In the embodiment of the present application, when the first device determines, on the basis of the first verification data and the first version number, that both the communication key which is currently stored in the first device and corresponds to the second device and the device information which is currently stored in the first device, corresponds to the second device and is required for bringing online are valid, the first device can directly bring the second device online, thereby improving efficiency of bringing a device online.

Description

Device online method, electronic device and computer-readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on March 8, 2024, with application number 202410277872.6 and application name “Equipment Online Method, Electronic Device and Computer-readable Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a device online method, an electronic device, and a computer-readable storage medium. Background Art

[0003] With the rapid development of smart terminals such as mobile phones, tablets, watches, car computers, large screens, virtual reality devices, and speakers, the ability of multi-device collaboration (such as cross-device application flow, file sharing, and multi-screen collaboration) is also widely used in all aspects of work, life, travel, and learning. The ability of multi-device collaboration can provide users with a more convenient, efficient, and colorful user experience.

[0004] Currently, before performing cross-device transfers, file sharing, and multi-screen collaboration, devices typically need to discover and bring the devices online. For example, if a mobile phone wants to collaborate with a tablet, it must first discover the tablet and bring it online. Improving the efficiency of device online is a concern for relevant technical personnel. Summary of the Invention

[0005] The embodiments of the present application disclose a device online method, an electronic device, and a computer-readable storage medium, which can implement hierarchical device online and improve device online efficiency.

[0006] The first aspect discloses a device online method, which can be applied to a first device, or to a module (for example, a processor) in the first device, or to a logic module or software that can realize all or part of the functions of the first device. The following description is given by taking the application to the first device as an example. The device online method may include: receiving a first message, the first message including identification information of the second device, first verification data and a first version number, wherein the first verification data is obtained based on the valid communication key currently stored in the second device, and the first version number is the version number of the device information required for the current online operation of the second device; determining based on the first verification data that the communication key corresponding to the second device currently stored in the first device is valid, and determining based on the first version number that the device information required for the online operation of the second device currently stored in the first device is valid; and bringing the second device online.

[0007] In an embodiment of the present application, for the device information required for the second device to go online, the second device can set and maintain the corresponding device information version number. When the device information required for the second device to go online changes, the corresponding device information version number will change accordingly. In addition, the second device can also generate corresponding verification data (first verification data) based on the currently stored valid communication key. During the device online process, the second device can send the version number (first version number) of the device information required for its own online operation and the first verification data to the first device. The first device can determine whether the device information required for the online operation of the second device currently stored in its own storage is valid based on the first version number, and can determine whether the communication key corresponding to the second device currently stored in its own storage is valid based on the first verification data. If both are valid, the first device can directly bring the second device online. As can be seen, in this manner, by carrying the first verification data and the first version number in the message, the second device can help the first device determine that the communication key corresponding to the second device currently stored on it and the device information required for going online are valid. In this way, the first device does not need to establish a connection with the second device, authenticate the second device, or obtain the device information required for going online. This can avoid unnecessary connection establishment, device authentication, and device information exchange, thereby improving the efficiency of device online. In addition, reducing the number of connection establishments, device authentications, and device information exchanges can also save processing resources, transmission resources, etc.

[0008] In combination with the first aspect, in a possible implementation, the method also includes: receiving a second message, the second message including identification information, third verification data and a third version number of a third device, wherein the third verification data is obtained based on the valid communication key currently stored in the third device, and the third version number is the version number of the device information required for the current third device to go online; determining that the communication key corresponding to the third device currently stored in the first device is valid based on the third verification data, and determining that the device information required for the current third device to go online currently stored in the first device is invalid based on the third version number; establishing a connection with the third device, obtaining the device information required for the current third device to go online; and bringing the third device online.

[0009] In an embodiment of the present application, the first device can determine that the communication key corresponding to the third device currently stored in itself is valid based on the third verification data, and determine that the device information required for going online corresponding to the third device currently stored in itself is invalid based on the third version number. In this case, the first device can only re-acquire the device information required for going online corresponding to the current third device, without having to re-authenticate the third device, thereby avoiding unnecessary device authentication, thereby saving related resources (transmission resources, processing resources, etc.).

[0010] In combination with the first aspect, in a possible implementation, a third message is received, which includes identification information, fourth verification data and a fourth version number of a fourth device, wherein the fourth verification data is obtained based on the valid communication key currently stored in the fourth device, and the fourth version number is the version number of the device information required for the fourth device to go online; based on the fourth verification data, it is determined that the communication key corresponding to the fourth device currently stored in the first device is invalid, and based on the fourth version number, it is determined that the device information required for the fourth device to go online currently stored in the first device is valid; a connection is established with the fourth device, and the fourth device is authenticated and the communication key is negotiated; and the fourth device is brought online.

[0011] In an embodiment of the present application, the first device can determine that the communication key corresponding to the fourth device currently stored in itself is invalid based on the fourth verification data, and determine that the device information required for going online corresponding to the fourth device currently stored in itself is valid based on the fourth version number. In this case, the first device can only re-authenticate the fourth device and negotiate a new communication key without exchanging device information, thereby avoiding unnecessary device information interaction and saving transmission resources.

[0012] As can be seen from the above description, the first device can bring other devices online in various situations, such as when the communication key of the corresponding device and the device information required for online are both valid, when the communication key of the corresponding device is valid but the device information required for online is invalid, and when the communication key of the corresponding device is invalid but the device information required for online is valid. In this way, if there are multiple devices, the first device may divide these multiple devices into different levels for online according to the actual situation. For example, some devices can go online directly, some devices can go online after exchanging device information, and some devices can go online after obtaining a new communication key through authentication negotiation. This online method divided into different levels can reduce signal conflicts between devices.

[0013] In combination with the first aspect, in a possible embodiment, the first verification data includes a first Bloom code vector, which is generated based on the valid communication key currently stored by the second device and one or more hash functions. Determining that the communication key corresponding to the second device currently stored by the first device based on the first verification data is valid includes: determining that the communication key corresponding to the second device currently stored by the first device is valid based on the first Bloom code vector.

[0014] In combination with the first aspect, in a possible implementation, determining that the communication key corresponding to the second device currently stored by the first device is valid based on the first Bloom code vector includes: processing the communication key corresponding to the second device currently stored by the first device through one or more hash functions corresponding to the first Bloom code vector to obtain one or more hash values; when the values ​​of the bits corresponding to the one or more hash values ​​in the first Bloom code vector are all 1, determining that the communication key corresponding to the second device currently stored by the first device is valid.

[0015] In an embodiment of the present application, the valid communication key currently stored in the second device is processed by Bloom coding, and the obtained verification data occupies fewer bits, which can save transmission resources.

[0016] In combination with the first aspect, in a possible embodiment, the fourth verification data includes a fourth Bloom code vector, which is generated based on the valid communication key currently stored by the fourth device and one or more hash functions, and determining the invalidation of the communication key corresponding to the fourth device currently stored by the first device based on the fourth verification data includes: determining the invalidation of the communication key corresponding to the fourth device currently stored by the first device based on the fourth Bloom code vector.

[0017] In combination with the first aspect, in a possible implementation, the communication key corresponding to the fourth device currently stored in the first device is processed by one or more hash functions corresponding to the fourth Bloom code vector to obtain one or more hash values; when the values ​​of the bits corresponding to the one or more hash values ​​in the fourth Bloom code vector are not all 1, it is determined that the communication key corresponding to the fourth device currently stored in the first device is invalid.

[0018] In combination with the first aspect, in a possible implementation, determining based on the first version number whether the device information required for the second device to go online currently stored in the first device is valid includes: when the first version number is the same as the second version number, determining that the device information required for the second device to go online currently stored in the first device is valid; the second version number is the version number of the device information required for the second device to go online currently stored in the first device.

[0019] In this embodiment of the present application, the first device can quickly and accurately determine that the device information currently stored by the first device is valid by comparing the first version number with the second version number. In addition, the device information version number usually occupies fewer bits, which can save transmission resources.

[0020] In combination with the first aspect, in a possible implementation, the determination based on the third version number that the device information required for the online operation of the third device currently stored in the first device is invalid includes: when the third version number is different from the fifth version number, determining that the device information required for the online operation of the third device currently stored in the first device is invalid; the fifth version number is the version number of the device information required for the online operation of the third device currently stored in the first device.

[0021] In combination with the first aspect, in a possible implementation, the device information required for the third device to go online currently stored on the first device and the device information required for the third device to go online currently include corresponding multiple device information, the third version number and the fifth version number respectively include multiple parts, and each part of the multiple parts corresponds to one or more device information in the multiple device information; the method also includes: when the third version number is different from the fifth version number, based on each part corresponding to the third version number and the fifth version number, respectively determine the device information corresponding to each part in the device information required for the third device to go online currently stored on the first device Whether it is valid; in the case that the third version number is the same as the first part corresponding to the fifth version number, determine that the device information corresponding to the first part in the device information required for the third device to go online currently stored in the first device is valid; the first part is any part of the multiple parts; in the case that the third version number is different from the first part corresponding to the fifth version number, determine that the device information corresponding to the first part in the device information required for the third device to go online currently stored in the first device is invalid; obtaining the device information required for the current third device to go online includes: obtaining the device information corresponding to the invalid part in the device information required for the current third device to go online.

[0022] In an embodiment of the present application, the device information version number can be divided into multiple independent parts, each part can correspond to one or more device information. In this way, when the third version number is different from the fifth version number, the first device can determine which specific device information has changed by comparing each part in the third version number and the fifth version number. In this way, the first device can only obtain the device information corresponding to the invalid part of the device information required for the current online operation of the third device, that is, the device information can be updated in a targeted manner, which can save transmission resources.

[0023] In combination with the first aspect, in one possible implementation, the third version number and the fifth version number include a second part and a third part, the number of bits occupied by the second part is greater than the number of bits occupied by the third part, and the frequency of change of the device information corresponding to the second part is greater than the frequency of change of the device information corresponding to the third part.

[0024] In an embodiment of the present application, the change frequencies of multiple device information corresponding to the device information version number may be different, some with high change frequencies and some with low change frequencies. Therefore, in order to save transmission resources while avoiding misjudgment (such as a certain device information actually changes, but the first device determines that there is no change based on the corresponding version number), the most appropriate number of bits can be determined for a device information based on its change frequency, and the higher the change frequency of a device information, the more bits it can occupy.

[0025] In combination with the first aspect, in a possible implementation, the device information required for the second device to go online includes device information of a first change frequency, device information of a second change frequency, and device information of a third change frequency, the first change frequency is greater than the second change frequency, the second change frequency is greater than the third change frequency, and the third change frequency is 0; the first version number is the version number of the device information of the second change frequency in the device information required for the current second device to go online, or the first version number is the version number of the device information of the first change frequency and the second change frequency in the device information required for the current second device to go online; wherein, in the case where the first version number is the version number of the device information of the second change frequency in the device information required for the current second device to go online, the first message also includes the device information of the first change frequency in the device information required for the current second device to go online.

[0026] In an embodiment of the present application, the device information required for the device to go online can be divided into multiple types based on the frequency of change, such as device information with a first change frequency, device information with a second change frequency, and device information with a third change frequency. Since device information with a high change frequency will cause the device information version number to change at a high frequency, it may be necessary for the first device to re-establish a connection with the second device each time the second device goes online, and re-acquire the device information required for the second device to go online. Therefore, in the present application, the device information version number can be associated only with the device information with a low change frequency in the device information required for going online, and the device information with a high change frequency in the device information required for going online can be directly carried in the first message, so that the number of times the connection is established can be reduced.

[0027] In combination with the first aspect, in a possible implementation manner, the first verification data and the first version number are carried in a data field of the first message.

[0028] The second aspect discloses an electronic device, which may be a first device, comprising a processor and a communication interface; the communication interface is used to receive and send data; the processor calls a computer program or computer instructions stored in a memory to implement the method provided in the above-mentioned first aspect and any possible implementation method of the first aspect.

[0029] As a possible implementation, the electronic device disclosed in the second aspect may include one or more processors.

[0030] Optionally, the electronic device disclosed in the second aspect further includes one or more memories.

[0031] The third aspect discloses a computer-readable storage medium having a computer program or computer instructions stored thereon. When the computer program or computer instructions are executed, the method provided in the first aspect and any possible implementation of the first aspect is implemented.

[0032] A fourth aspect discloses a chip, comprising a processor for executing a program stored in a memory. When the program is executed, the chip executes the method provided in the above-mentioned first aspect and any possible implementation of the first aspect.

[0033] As a possible implementation, the memory is located outside the chip.

[0034] A fifth aspect discloses a computer program product, which includes a computer program code. When the computer program code is run, the method provided in the first aspect and any possible implementation of the first aspect is executed.

[0035] It should be understood that the implementation and beneficial effects of the above-mentioned multiple aspects or any possible implementation methods of the present application can be referenced to each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] FIG1 is a schematic diagram of a process flow of a device going online disclosed in an embodiment of the present application;

[0038] FIG2 is a schematic diagram of the architecture of a communication system disclosed in an embodiment of the present application;

[0039] FIG3 is a flow chart of a communication method disclosed in an embodiment of the present application;

[0040] FIG4 is a schematic diagram of a message structure of a BLE broadcast message disclosed in an embodiment of the present application;

[0041] 5A-5C are schematic diagrams of some device information version number changes disclosed in the embodiments of the present application;

[0042] FIG6 is a flow chart of another communication method disclosed in an embodiment of the present application;

[0043] FIG7 is a flow chart of another communication method disclosed in an embodiment of the present application;

[0044] FIG8 is a flow chart of another communication method disclosed in an embodiment of the present application;

[0045] FIG9 is a schematic diagram of the hardware structure of an electronic device 900 disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0047] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of the technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0048] The term "user interface (UI)" in the following embodiments of this application refers to a medium interface for interaction and information exchange between an application (APP) or an operating system (OS) and a user, which realizes the conversion between the internal form of information and the form acceptable to the user. The user interface is a source code written in a specific computer language such as Java and extensible markup language (XML). The interface source code is parsed and rendered on an electronic device and finally presented as content that the user can recognize. The commonly used form of user interface is a graphical user interface (GUI), which refers to a user interface related to computer operations that is displayed in a graphical manner. It can be a visual interface element such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, etc. displayed on the display screen of an electronic device.

[0049] With the rapid development of smart devices (such as mobile phones, tablets, watches, car computers, large screens, virtual reality devices, and audio equipment), the interconnectedness of everything and multi-device collaboration are being widely applied to all aspects of work, life, travel, and learning, providing users with a more convenient, efficient, and diverse user experience. For example, in the mobile office scenario, users can use multi-device collaboration to connect their mobile phones, tablets, laptops, etc. to meet the needs of various business types. For example, they can switch the file currently being edited on their mobile phone to the tablet or laptop to continue editing, or they can transfer the task currently being executed on their mobile phone to the tablet to continue executing. For another example, in the smart home scenario, multi-device collaboration can be used to connect exercise equipment (such as treadmills and exercise bikes) to refrigerators. After the user exercises on the exercise equipment, the exercise equipment can synchronize the collected exercise data to the refrigerator. The refrigerator can then intelligently recommend some healthy recipes based on the exercise data that are most suitable for physical recovery and nutritional supplementation, and the user can place an order for the corresponding food through the refrigerator.

[0050] Currently, before performing operations such as cross-device transfer, file sharing, and multi-screen collaboration, devices usually need to discover the devices, bring them online, and establish a connection.

[0051] The following is an exemplary description of a device online process, with reference to FIG1 . As shown in FIG1 , the process may include but is not limited to the following steps:

[0052] 101. Device A discovers device B.

[0053] In the embodiment of the present application, there may be multiple possible implementations for device A to discover device B, two of which are illustrated below.

[0054] The first is that device A actively initiates a scan to search for devices in the same network or nearby. In this way, device A can send a discovery message by broadcasting, and the discovery message may include relevant information about device A (such as the name of device A, device type, etc.). Devices in the same network as device A or near device A can receive the discovery message sent by device A, and can send a discovery response message to device B based on the discovery message, which may include relevant information about itself. When device A receives a discovery response message returned by other devices, device A can discover the corresponding device. For example, after device B receives the discovery message sent by device A, it can send a discovery response message to device A, which may include relevant information about device B (such as the name of device B, device type, etc.). After device A receives the discovery response message from device B, it can discover device B.

[0055] In the second method, device B typically periodically sends its information (such as its name and type) through broadcast or multicast. Device A can receive this information and thus discover device B. This method is equivalent to device A passively scanning for devices on the same network or nearby.

[0056] It should be understood that the above two methods are just examples, and the specific process of device discovery may be different for different communication methods (such as Bluetooth, Ethernet, Wi-Fi, etc.).

[0057] 102. Device A establishes a connection with device B and authenticates device B.

[0058] After device A discovers device B, it can establish a communication connection with device B, such as a Bluetooth or Wi-Fi connection. After establishing the communication connection, device A can authenticate device B, such as by using a trust ring mechanism to confirm whether device B is trustworthy. It should be understood that establishing a connection essentially establishes a communication link between the two devices.

[0059] It is understandable that in some cases, device B may also perform trust authentication on device A, which means that two-way authentication is required.

[0060] 103. After device B passes the authentication, device A and device B exchange device information.

[0061] After device B passes authentication, devices A and B can exchange device information required for going online, such as device name, device capabilities, and connection information, and can store this information locally. It should be noted that during the device authentication process, devices A and B can negotiate a communication key, which can then be used for encrypted communication.

[0062] 104. Device B comes online on device A.

[0063] After device A and device B exchange device information, device B can go online on device A, and device A can notify the corresponding upper-layer services (such as HyperTerminal). It should be understood that due to the limited underlying device resources, device A can usually disconnect from device B after device B successfully goes online on device A. Later, when devices A and B need to perform operations such as cross-device streaming, file sharing, and multi-screen collaboration, device A can reconnect to device B.

[0064] It is understood that device B can go offline after going online. For example, the user can turn off the Bluetooth, Wi-Fi, and other functions of device B. Of course, when the Bluetooth, Wi-Fi, and other functions of device B are turned back on, steps 101-104 can be repeated to go back online.

[0065] It can be seen that the above processing flow is applicable to both the first time a device goes online and the non-first time it goes online. That is, when device B goes online for the first time and the non-first time it goes online, the above steps 101-104 will be executed between device A and device B. Among them, the process of establishing a connection and performing authentication between device A and device B takes a long time. In addition, when device A discovers multiple devices, device A may establish connections with multiple devices at the same time. In this case, there may be signal conflicts or interference between devices, which will affect the reliability of the connection and reduce the success rate of the connection. In addition, under normal circumstances, after a device goes offline, when it goes online again, the device information changes little or nothing. In this case, device A and device B will still exchange all the device information required for going online, resulting in a lot of unnecessary data interaction and a waste of transmission resources.

[0066] Furthermore, as various devices are currently developing in the direction of intelligence, more and more devices need to be connected, such as smart screens, laptops, mobile phones, tablets, sweeping robots, refrigerators, sports equipment (such as treadmills, exercise bikes, etc.), air purifiers, smart ovens, smart curtains, smart sensors (such as temperature sensors, humidity sensors, and smoke sensors in each room), etc. In this case, if all devices need to establish a connection for authentication and exchange device information before going online, there may be bottlenecks in the underlying resources, resulting in low efficiency in going online.

[0067] In order to solve the above problems, the present application provides a device online method. This method can avoid unnecessary device information interaction, save transmission resources, and can also divide devices into multiple levels for online (referred to as hierarchical online), which can improve the efficiency of devices that are not online for the first time and reduce signal conflicts between devices. The core idea of ​​the method is that: when the second device is not online for the first time, the first device can locally store the authentication information of the second device (such as a communication key) and the device information required for the second device to go online. In this case, if the authentication information of the second device stored by the first device is valid, then the first device does not need to re-authenticate the second device. Similarly, if the device information required for the second device to go online stored by the first device is valid, then the first device does not need to re-acquire the device information of the second device, or, if part of the device information required for the second device to go online stored by the first device is valid and part is invalid, then the first device can only re-acquire the device information of the invalid part. For specific content, please refer to the steps in the method embodiment such as Figure 3 below.

[0068] In some embodiments, the second device can generate first verification data based on the valid communication key currently stored in itself (referred to as the valid communication key). During the discovery process, the second device can send the first verification data to the first device, and the first device can generate second verification data based on the communication key corresponding to the second device currently stored. Afterwards, the first device can determine whether the communication key corresponding to the second device is valid based on the first verification data and the second verification data. If it is valid, there is no need to re-authenticate the second device. Otherwise, it is necessary to establish a connection and re-authenticate the second device to negotiate a new communication key.

[0069] In some embodiments, the device information required for a device to go online can be divided into three types based on the frequency of change: unchanged, medium-frequency change, and high-frequency change. For unchanged device information, the first device can obtain and save it locally during the second device's first online process. Subsequently, for non-first online processes of the second device, the first device does not need to re-acquire this information. For device information with medium and high frequency of change, the second device can initially set / bind a device information version number for it as a whole, and each change in the device information will result in a change in the device information version number. Based on this, the second device can send the current device information version number to the first device during the discovery process, so that the first device can determine, based on the device information version number, whether the device information with medium and high frequency of change in the device information required for the current second device to go online has changed, that is, whether the device information with medium and high frequency of change in the device information required for the current second device to go online is the same as the device information with medium and high frequency of change in the locally stored device information required for the current second device to go online. For example, the second device can send a first version number to the first device during the discovery process. The first version number can be the device information version number of the device information required for the current second device to go online. The first device locally stores the device information required for the second device to go online and the corresponding second version number that was previously obtained. The first device can compare the first version number with the second version number. If they are the same, it indicates that the device information with medium and high change frequencies in the device information required for the second device to go online has not changed, and there is no need to re-acquire it. If they are different, it indicates that the device information with medium and high change frequencies in the device information required for the second device to go online has changed, and it is necessary to re-establish a connection with the second device to obtain it.

[0070] Furthermore, since device information with a high frequency of change will cause the device information version number to change more frequently, it may cause the first version number and the second version number to be different each time the second device goes online, and a connection needs to be established to obtain the relevant device information. Therefore, in some possible implementations, in order to avoid the need to establish a connection each time the second device goes online, the second device can set the device information version number only based on device information with a medium frequency of change. For device information with a high frequency of change (this part of information is generally less), the second device can directly send it to the first device during the discovery process, so that the number of times the connection is established can be reduced.

[0071] Furthermore, the first device may also determine which device information has changed based on the first version number and the second version number, so that the device information may be updated in a targeted manner, thereby saving transmission resources.

[0072] It can be seen that based on the above method, when the second device goes online, the first device can determine whether it needs to re-authenticate the second device based on the encoding vector corresponding to the valid key, and can also determine whether it needs to re-acquire the relevant device information of the second device based on the device information version number. In this way, unnecessary authentication and device information exchange can be avoided, transmission resources can be saved, the number of connection establishments can be reduced, and the efficiency of device online can be improved. In some cases, the second device can even go online without establishing a connection between the first and second devices.

[0073] In order to better understand the embodiments of the present application, the following briefly introduces the relevant contents, terms or nouns involved in the present application.

[0074] 1. Soft Bus

[0075] A soft bus can be understood as a virtual bus technology that enables flexible connection and networking between devices through software, facilitating communication (data exchange) and collaborative work between devices. For example, a soft bus can serve as the communication base for mobile phones, tablets, smart wearables, smart screens, and vehicle computers, providing unified distributed communication capabilities for interconnection between various devices. A soft bus can also be called a distributed soft bus.

[0076] The soft bus can provide various functions, including device discovery, device connection, and device networking. Furthermore, the soft bus supports device discovery via various media, such as Wi-Fi, Bluetooth, and Ethernet, and can be selected based on device capabilities. Furthermore, the soft bus can adjust the appropriate scanning and broadcasting cycles based on device capabilities and business requirements.

[0077] In short, through the distributed soft bus, devices with different capabilities and characteristics can be interconnected, thereby achieving collaboration between multiple devices, such as executing cross-device task flow, file sharing, multi-screen collaboration and other operations.

[0078] 2. Bloom Filter

[0079] A hash algorithm (function), also known as a hash algorithm, can transform an input of arbitrary length into an output of fixed length. This output value can be called a hash value or hash value. A key characteristic of a hash function is that its output is theoretically irreversible, meaning the original input data cannot be derived from the hash value, thereby ensuring security. For example, a hash function can be hash(key) = key%p, where key is the input value, % is the modulus operation, and p is the modulus.

[0080] Bloom filter can compress a data set into a smaller storage space, and can query whether an element is in a data set. Specifically, for a data set, Bloom filter can compress its code into an m-bit vector based on a hash function. Initially, all bits of the m-bit vector can be 0. For a data set S, assuming that set S includes three elements x1, x2 and x3, each element can use three independent hash functions to calculate its hash value, and then three bits can be selected from the m-bit vector based on the calculated three hash values, and these three bits can be set to 1. The range of hash values ​​generated by each of the three hash functions can belong to [0, m-1]. For example, if the three calculated hash values ​​are 0, 2, and 5, the 0th, 2nd, and 5th bits in the m-bit vector can be set to 1 respectively, such as 101001000... After computing hash values ​​for all elements in set S and setting specific bits in an m-bit vector to 1 based on the calculated hash values, the encoding vector corresponding to set S is obtained, which is an m-bit vector containing 0s and 1s. Subsequently, to determine whether an element xn exists in set S, the three hash values ​​corresponding to xn can be calculated using the same three hash functions. This yields an m-bit encoding vector corresponding to xn, which may have three bits set to 1. The encoding vector corresponding to set S can then be checked to see if the corresponding three bits are 1. If all are 1, xn is considered included in set S. If not all are 1, or at least one bit is not 1, xn is considered not included in set S. It should be understood that all hash values ​​calculated for all elements in set S using multiple different hash functions may contain duplicate hash values. Therefore, a bit in the encoding vector corresponding to set S may be set to 1 multiple times, but only the first bit will be affected.

[0081] In order to better understand the embodiments of the present application, the system architecture of the embodiments of the present application is described below.

[0082] Please refer to Figure 2, which is a schematic diagram of the architecture of a communication system provided by an embodiment of the present application. As shown in Figure 2, the communication system may include a first device 201 and a second device 202.

[0083] The first device 201 and the second device 202 can communicate with each other, and the communication method adopted can be wired communication or wireless communication. Exemplarily, the first device 201 and the second device 202 can communicate with each other through Wi-Fi, Ethernet, Bluetooth, Zigbee, power line communication (PLC), infrared, near field communication (NFC), ultra wideband (UWB), etc. In some embodiments, the first device 201 and the second device 202 can be in the same network, such as connected to the same access point (AP).

[0084] In the embodiment of the present application, the specific types of the first device 201 and the second device 202 are not limited. The first device 201 and the second device 202 can be a smart phone, a television, a wireless headset, a wearable device (such as a smart watch, a smart bracelet, etc.), a speaker, a laptop computer, a desktop computer, an ultra-mobile personal computer (UMPC), a tablet computer, an augmented reality (AR) device, a virtual reality (VR) device, an Internet of Things (IoT) device (such as a temperature sensor, an air quality sensor, a humidity sensor, etc.), a smart home device (such as a smart door lock, a smart refrigerator, a smart desk lamp, a treadmill, an exercise bike, an air purifier, an air conditioner, a dishwasher, a sweeping robot, an electric curtain, etc.), an in-vehicle device (such as a car computer, a large screen on the main driver's seat, a large screen on the co-driver's seat, a rear display screen 1, a rear display screen 2, etc.), etc. The first device 201 and the second device 202 can also be chips or processing systems in the above-mentioned devices.

[0085] In an embodiment of the present application, the second device 202 may send first verification data to the first device 201 via broadcast, multicast, or the like. The first verification data is generated by the second device 202 based on a valid communication key currently stored in the second device 201. The first device 201 may determine whether it is necessary to re-authenticate the second device 202 based on the first verification data to negotiate a new communication key. The second device 202 may also send a first version number to the first device 201 via broadcast, multicast, or the like. The first version number may be the device information version number of the device information with a medium frequency of change in the device information currently required for the second device 202 to go online. The first device 201 may determine whether it is necessary to re-acquire the device information with a medium frequency of change in the device information required for the second device 202 to go online based on the first version number and the second version number. The second version number may be the device information version number of the device information with a medium frequency of change in the device information currently stored in the first device 201 for the second device 202 to go online. The second device 202 may also send the device information that changes frequently among the device information required for the current second device 202 to go online to the first device 201 through broadcasting, multicasting, etc., so that the first device 201 can update this part of the information without establishing a connection with the second device 202.

[0086] It can be seen that through the above method, devices can be online without establishing a connection (that is, devices can be online without establishing a connection for authentication and obtaining device information), or devices can be online with only authentication and no need to exchange device information, or devices can be online with only exchange of device information and no need for authentication.

[0087] It should be understood that FIG2 is merely a schematic diagram, and the architecture shown in FIG2 may include more or fewer devices, which is not limited here.

[0088] It should be noted that the system architecture and business scenarios (or application scenarios) described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application.

[0089] The following is an illustrative description of the overall processing flow of the technical solution provided in the embodiments of the present application.

[0090] Please refer to Figure 3, which is a flow chart of a communication method disclosed in an embodiment of the present application. As shown in Figure 3, the method may include but is not limited to the following steps:

[0091] 301. The second device sends identification information of the second device and first information to the first device, where the first information includes first verification data and a first version number.

[0092] The identification information of the second device is information that can identify the second device, such as the name of the second device, the identification (ID) of the second device, or the address information of the second device. The identification of the second device can be a unique device identifier (UDID), a hash value corresponding to the UDID, etc. The address information of the second device can be a media access control (MAC) address of the second device, an Internet protocol (IP) address, or an IP address plus a port number, etc.

[0093] The first verification data is generated based on the valid communication key currently stored by the second device and can be used by the first device to verify whether the communication key corresponding to the second device currently stored by it is valid. Exemplarily, the first verification data can be a first Bloom code vector. The first Bloom code vector can be generated based on the valid communication key currently stored by the second device and one or more hash functions. It should be understood that in embodiments of the present application, the communication key negotiated through authentication between two devices (such as the first device and the second device) can be a symmetric key, that is, the key used by both parties sending and receiving data is the same. Exemplarily, assuming that the valid communication keys currently stored by the second device include communication key 1, pass key 2, and communication key 3, communication key 1 can be the communication key used with the second device, communication key 2 can be the communication key used with the third device, and communication key 3 can be the communication key used with the fourth device. The first Bloom code vector can be associated with a first hash function, which can include one or more hash functions. Assuming that the first hash function includes three hash functions, namely hash function 1, hash function 2, and hash function 3, the range of hash values ​​generated by each hash function can fall within [0, m-1], where m is a positive integer greater than 2. The second device can calculate the three hash values ​​(such as 0, 2, and 10) corresponding to the communication key 1 through hash function 1, hash function 2, and hash function 3. The second device can also calculate the three hash values ​​(such as 5, 15, and 31) corresponding to the communication key 2 through hash function 1, hash function 2, and hash function 3. The second device can also calculate the three hash values ​​(such as 13, 19, and 25) corresponding to the communication key 3 through hash function 1, hash function 2, and hash function 3, and a total of 9 hash values ​​can be obtained. The second device can set the positions corresponding to these 9 hash values ​​in the m-bit vector to 1, and can obtain the corresponding first Bloom code vector. It should be understood that if these 9 hash values ​​are all different, then the m bits can include 9 bits set to 1. For example, if m is 32, the nine calculated hash values ​​can be 0, 2, 5, 10, 13, 15, 19, 25, and 31, respectively. Then the 0th, 2nd, 5th, 10th, 13th, 15th, 19th, 25th, and 31st bits in the m-bit vector can be set to 1, such as 101001000...10.

[0094] In addition to verifying whether the communication key is valid by Bloom coding, other processing can be performed based on the valid communication key currently stored in the second device to generate the corresponding first verification data. For example, the second device can directly process the currently stored valid communication key through one or more hash functions (such as the above-mentioned hash function 1, hash function 2 and hash function 3) to obtain one or more hash values, and then use these one or more hash values ​​as the first verification data. Afterwards, the first device can process the communication key corresponding to the currently stored second device based on the same hash function to obtain one or more hash values, and then check whether the one or more hash values ​​exist in the first verification data. If so, it can be considered that the communication key corresponding to the currently stored second device is valid. Otherwise, it can be considered that the communication key corresponding to the currently stored second device is invalid. For another example, the second device can encrypt the preset information (such as a string of arrays) with the currently stored valid communication key to obtain the encrypted data corresponding to each communication key, and then use the encrypted data corresponding to all communication keys as the first verification data. Afterwards, the first device can decrypt the first verification data using the communication key corresponding to the currently stored second device. If one of the decryption results is the preset information, the communication key corresponding to the currently stored second device can be considered valid; otherwise, the communication key corresponding to the currently stored second device can be considered invalid.

[0095] Before introducing the first version number, the device information is first exemplified below. From the perspective of change frequency, device information can be divided into multiple or multiple levels based on different change frequencies. The embodiment of the present application is mainly divided into three levels, but in other embodiments of the present application, more or fewer levels can also be divided. Exemplarily, the three levels divided in the embodiment of the present application can be unchanged, medium change frequency, and high change frequency. Among them, "unchanged" can be understood as the device information will never change and will not be affected by external conditions such as restoring factory settings and restarting. "Medium change frequency" can be understood as the device information will change, but will not change frequently, such as the average change frequency is greater than 0 times / minute, but less than the first change frequency (such as 1 time / 6 hours). "High change frequency" can be understood as the device information will change frequently, such as the average change frequency is greater than or equal to the first change frequency (such as 1 time / 6 hours). The above is to measure the frequency of change by the average number of changes in a certain time period, but this is not limited to the embodiments of the present application, and the frequency of change can also be measured in other ways. For example, the device information that does not change within the first time threshold (such as 10 minutes) after the device goes offline can be regarded as "medium-frequency device information", and the device information that changes within the first time threshold (such as 10 minutes) after the device goes offline can be regarded as "high-frequency device information". From the perspective of going online, device information can be divided into two categories, one is the device information that must be available for the device to go online (referred to as the device information required for going online in this article), and the other is the device information that is not necessary for the device to go online. For example, please refer to Table 1 below, which illustrates the frequency of change of some device information and whether it is necessary for going online.

[0096] Table 1

[0097] For example, the device capabilities may include the current short-range capabilities of the device, such as the Wi-Fi status (on or off), the Bluetooth status, the P2P capability, whether COC is supported, etc. It should be understood that the above Table 1 is only an example and should not be construed as limiting the embodiments of the present application. Based on the above description, the first version number is exemplified below.

[0098] The first version number may be the device information version number of the device information required for the current second device to go online. The device information version number of the device information may also be referred to as the device information version number. In an embodiment of the present application, a device information version number may be set for the device information required for the second device to go online to indicate / identify the version of the corresponding device information. When the device information required for the second device to go online changes, the corresponding device information version number may also change, such as by incrementing the version number by 1.

[0099] Furthermore, since the device information required for the second device to go online includes multiple pieces and can be divided into multiple levels based on the frequency of change, there are multiple ways to set the device information version number in the embodiment of the present application. The following are two examples. The first is to set the device information version number based on the device information with medium and high change frequencies in the device information required for the second device to go online, that is, the device information version number is associated with the device information with medium and high change frequencies in the device information required for the second device to go online. The second is to set the device information version number only based on the device information with medium change frequency in the device information required for the second device to go online, that is, the device information version number is only associated with the device information with medium change frequency in the device information required for the second device to go online.

[0100] For example, assuming that the device information version number is set based on the device information with medium and high change frequencies in the device information required for the second device to go online, the device information version number is represented by 8 bits. As shown in Figure 5A, at the initial time t0, the device information version number can be 00000000. If the device name changes at t1, the device information version number can be increased by 1 and changed to 00000001. If the device capability changes at t2 (such as Bluetooth is turned off), the device information version number can be increased by 1 and changed to 00000010. If the account ID changes at t3, the device information version number can be increased by 1 and changed to 00000011. Assuming that the device information version number is set only based on the device information with medium change frequencies in the device information required for the second device to go online, the device information version number is represented by 8 bits. As shown in Figure 5B, at the initial time t0, the device information version number can be 00000000. If the device name changes at t1, the device information version number can be increased by 1, changing to 00000001. If the device capability changes at t2 (such as Bluetooth is turned off), since device capability is device information that changes frequently, the device information version number can remain unchanged at 00000001. If the account ID changes at t3, the device information version number can be increased by 1 again, changing to 00000010.

[0101] In an embodiment of the present application, considering that the device information required for the second device to go online with a high frequency of change may cause the corresponding device information version number to change frequently, which may cause the first device to frequently determine that it needs to re-acquire the device information required for the second device to go online from the second device based on the device information version number during the second device's online process, therefore, when the device information version number is set based only on the device information required for the second device to go online with a medium frequency of change, the first information may include, in addition to the first version number, device information with a first frequency of change. Here, the device information with a first frequency of change refers to the device information required for the second device to go online with a high frequency of change. In other words, the second device can directly send the device information required for the second device to go online with a high frequency of change directly to the first device, so that the first device can obtain the device information required for the second device to go online with a high frequency of change without establishing a connection with the second device, thereby updating the device information required for the second device to go online with a high frequency of change currently stored in the first device.

[0102] It is understandable that the above-mentioned device information version number is associated with the device information with a medium frequency of change among the device information required for the online operation of the unified second device, or is associated with the device information with a medium frequency of change and a high frequency of change among the device information required for the online operation of the unified second device. When any of the device information changes, the device information version number will also change. Therefore, it is not possible to distinguish which specific device information has changed. Therefore, in order to facilitate the distinction of which specific device information has changed, in some possible implementations, the device information version number can be divided into multiple independent parts, each of which can correspond to one or more device information. For example, taking the device information version number associated with the device information with a medium frequency of change among the device information required for the online operation of the second device as an example, the device information with a medium frequency of change among the device information required for the online operation of the second device can include the device name, device UUID (universally unique identifier), transmission protocol, Bluetooth MAC address, account ID, and features supported by the soft center line. Among them, the device information version number can be represented by 12 bits, and the device name, device UUID, transmission protocol, Bluetooth MAC address, account ID, and features supported by the soft center line can occupy 2 bits respectively. For example, as shown in FIG5C , at the initial time t0, the device information version number may be 000000000000. If the device name changes at t1, the bit corresponding to the device name in the device information version number may be incremented by 1, and the device information version number may change to 010000000000. If the transmission protocol changes at t2, the bit corresponding to the transmission protocol in the device information version number may be incremented by 1, and the device information version number may change to 010001000000. If the account ID changes at t3, the bit corresponding to the account ID in the device information version number may be incremented by 1, and the device information version number may change to 010001000100.

[0103] It should be understood that, in the case where the device information version number is divided into multiple independent parts, if the two bits corresponding to a certain device information in the device information version number are both 1, the next time 1 is added, it may become 00, and the cycle will start again. Therefore, in order to avoid misjudgment of whether a certain device information has changed, a longer number of bits can be used to associate the device information (for example, each of the above-mentioned device information can occupy 4 bits respectively). Accordingly, the number of bits corresponding to the device information version number can also be more. Of course, in order to save transmission resources, in some possible implementations, the most appropriate number of bits can also be determined for a piece of device information based on its change frequency, so that as few bits as possible are occupied without causing misjudgment. For example, the most appropriate number of bits corresponding to different change frequency intervals can be determined in advance through testing or calculation. Based on this, the corresponding number of bits can be determined for each piece of device information based on its change frequency (such as the average change frequency), wherein the higher the change frequency, the more bits can be occupied.

[0104] In some possible implementations, to further conserve transmission resources, multiple pieces of device information can be associated with the same bit. For example, assuming the device information version number is represented by 12 bits, the device name and device UUID can be associated with the first four bits, the transmission protocol and Bluetooth MAC address can be associated with the middle four bits, and the account ID and features supported by the soft center line can be associated with the last four bits. This reduces the number of bits required for transmission and conserves transmission resources. Furthermore, since when multiple pieces of device information are associated with the same bit, when any piece of device information changes, the value of the corresponding bit in the device information version number is incremented by 1, it may be impossible to determine which piece of device information has changed, necessitating a connection to re-acquire the multiple pieces of device information. Based on this, in some embodiments, the device information required for the second device to go online and with a medium frequency of change can be further classified. For device information with a relatively high frequency of change (e.g., above a threshold of 1), multiple bits can be associated with each piece of device information. For device information with a relatively low frequency of change (e.g., below a threshold of 1), multiple pieces of device information can be associated with multiple bits.

[0105] From the above description, it can be seen that in the embodiment of the present application, there are multiple possible settings for the device information version number, which is highly flexible and can be set according to actual conditions to save transmission resources as much as possible while avoiding misjudgment.

[0106] It is understandable that the device information required for the device to go online may be different for different situations. For example, for different device types (such as spinning bikes, smart screens, sweeping robots, etc.), or different devices of the same device type (such as devices with different configurations), the device information required to go online may be different. Therefore, in an embodiment of the present application, for different situations, when the device information version number is divided into multiple parts, a unified device information version number format can be adopted. If a device does not have corresponding device information, the corresponding bit can be filled with 0. Of course, in some possible implementations, in order to save transmission resources, different device information version number formats can also be used in a targeted manner.

[0107] The above content introduces the first verification data, the first version number, etc. The following is an exemplary description of the case where the second device sends the identification information of the second device and the first information.

[0108] In some possible implementations, the second device may periodically send the identification information and first information of the second device so that other devices (such as the first device) can discover the second device. For example, the second device may periodically send a broadcast message (such as a BLE broadcast message) or a multicast message (such as a COPA (constrained application protocol) multicast message), etc., and the broadcast message or multicast message may carry the identification information and first information of the second device. In addition to the second device actively sending the identification information and first information of the second device, the second device may also respond to requests from other devices and then send the identification information and first information of the second device to the corresponding device. For example, the first device may send a discovery message by broadcasting, multicasting, etc., and the discovery message may include relevant information of the first device (such as the name of device A, device type, etc.). The second device may receive the discovery message sent by the first device and may send a discovery response message to the first device based on the discovery message, and the discovery response message may include the identification information and first information of the second device. For example, please refer to Figure 4, which illustrates a message structure diagram of a low-energy Bluetooth (Bluetooth low energy, BLE) broadcast message sent by a first device. As shown in Figure 4, the first device can carry the device information of the first change frequency, the first version number, and the first verification data in the data field of the BLE broadcast message. It should be understood that the structure of the BLE broadcast message shown in Figure 4 is only an example and does not constitute a limitation. For example, in addition to these three pieces of information, the data field can also include more or less information, such as the identification information of the second device. It should also be understood that for other communication methods, such as WI-FI, Ethernet, etc., the three pieces of information, namely the device information of the first change frequency, the first version number, and the first verification data, can also be carried in the data field of the WI-FI message or Ethernet message, and are not limited here.

[0109] It should be noted that, in addition to the first verification data and the first version number (and the device information of the first change frequency), the above-mentioned first information can also include more content, such as the device type of the second device, the manufacturer identification of the second device, etc. This application does not limit this and can be set according to actual needs.

[0110] 302. The first device determines whether the communication key corresponding to the currently stored second device is valid based on the first verification data, and determines whether the device information required for going online corresponding to the currently stored second device is valid based on the first version number.

[0111] It should be understood that after the first device receives the identification information of the second device and the first information sent by the second device, it can determine that the first information is associated with the second device based on the identification information of the second device. Afterwards, the first device can determine whether the communication key corresponding to the currently stored second device is valid based on the first verification data in the first information, and can determine whether the device information required for going online corresponding to the currently stored second device is valid based on the first version number in the first information. Among them, when the first device determines that the communication key corresponding to the second device currently stored in the first device is valid, but the device information required for the second device to go online is invalid or partially invalid, the first device needs to establish a connection with the second device to obtain the invalid device information, and step 303 can be executed. When the first device determines that the device information required for the second device to go online currently stored in the first device is valid, but the communication key corresponding to the second device is invalid, the first device needs to establish a connection with the second device to authenticate the second device and negotiate a new communication key, and step 305 can be executed. When the first device determines that the communication key corresponding to the second device currently stored in the first device is valid and the device information required for the second device to go online is valid, the first device can directly bring the second device online and step 310 can be directly executed. When the first device determines that the communication key corresponding to the second device currently stored in the first device is invalid and the device information required for the second device to go online is invalid or partially invalid, the first device needs to establish a connection with the second device to authenticate the second device and negotiate a new communication key, and needs to obtain the invalid device information, and step 307 can be directly executed.

[0112] The following is an exemplary description of a case where the first verification data is a first Bloom code vector, and the first device determines whether the currently stored communication key corresponding to the second device is valid based on the first Bloom code vector.

[0113] Specifically, the first device can obtain one or more corresponding hash values ​​(first hash values) based on the first hash function and the communication key corresponding to the currently stored second device, and then check whether the bit values ​​corresponding to the one or more hash values ​​in the first Bloom code vector are 1. If they are all 1, then the communication key corresponding to the second device currently stored by the first device can be considered to be valid. If they are not all 1, that is, the value corresponding to at least one bit is 0, then the communication key corresponding to the second device currently stored by the first device can be considered to be invalid. For example, assuming that the first Bloom code vector is 101001000...10, the first hash function includes three hash functions, namely hash function 1, hash function 2 and hash function 3, and the communication key corresponding to the second device currently stored by the first device is communication key 1. The first device can calculate the three hash values ​​corresponding to communication key 1 through hash function 1, hash function 2 and hash function 3, such as 0, 2, and 10. After that, the first device can determine that the values ​​corresponding to the 0th, 2nd and 10th bits in the first Bloom code vector are all 1, thereby determining that the communication key corresponding to the second device currently stored by the first device is valid.

[0114] The following is an exemplary description of a case where the first device determines, based on the first version number, whether the currently stored device information required for the second device to go online is valid.

[0115] Among them, since there are multiple ways to set the device information version number in the embodiment of the present application, the situations in which the first device determines whether the currently stored device information required for the second device to go online is valid based on the first version number also include multiple corresponding situations. The following are two examples. In the first, the device information version number is only associated with the device information with a medium frequency of change in the device information required for the second device to go online. In the second, the device information version number is associated with the device information with a medium frequency of change and a high frequency of change in the device information required for the second device to go online. Of course, based on the above two methods, further distinctions can be made. For example, the device information version number is associated as a whole with the device information with a medium frequency of change in the device information required for the second device to go online, or it can be divided into multiple different parts, and different parts can be associated with some of the device information therein.

[0116] First, an example will be provided for the case where, under the first approach described above, the device information version number is associated with the device information with a medium frequency of change in the device information required for the second device to go online. In this case, the first device can determine whether the device information with a medium frequency of change in the device information required for the second device to go online currently stored on the first device is valid based on the first version number and the second version number. The second version number can be the device information version number corresponding to the device information with a medium frequency of change in the device information required for the second device to go online currently stored on the first device. Specifically, if the first version number and the second version number are the same, the first device can determine that the device information with a medium frequency of change in the device information required for the second device to go online currently stored on the first device is the same as the device information with a medium frequency of change in the device information required for the second device to go online currently, thus determining that the device information with a medium frequency of change in the device information required for the second device to go online currently stored on the first device is valid. Conversely, if the first version number and the second version number are different, the first device can determine that the device information with a medium frequency of change in the device information required for the second device to go online currently stored on the first device is invalid. For example, as shown in FIG5B , the device information version number may be 8 bits. Assuming that the current moment is t3, the first version number may be 00000010. However, the first device currently stores the device information with a medium frequency of change among the device information required for the second device to go online at the previous moment t1. The second version number may be 00000001. Therefore, the first device may determine, based on the first version number and the second version number, that the device information with a medium frequency of change among the device information required for the second device to go online currently stored in the first device has become invalid.

[0117] Secondly, for the first method mentioned above, the device information version number can be divided into multiple parts, and each part can be associated with one or more device information in the device information with a medium frequency of change in the device information required for the second device to go online, and an example is given. In this case, the first device can determine whether the device information corresponding to the part is valid based on different parts of the first version number and the second version number. Among them, the second version number can be the device information version number corresponding to the device information with a medium frequency of change in the device information required for the second device to go online currently stored by the first device. Specifically, if the first version number is the same as a certain part corresponding to the second version number, the first device can determine that the device information corresponding to the part in the device information with a medium frequency of change in the device information required for the second device to go online currently stored by the first device is the same as the device information corresponding to the part in the device information with a medium frequency of change in the device information required for the current second device to go online, that is, it can be determined that the device information corresponding to the part in the device information with a medium frequency of change in the device information required for the second device to go online currently stored by the first device is valid. Conversely, if a portion of the first version number and the second version number differ, the first device may determine that the device information corresponding to that portion of the device information currently stored on the first device, which has a medium-frequency change, is no longer valid. For example, as shown in FIG5C , the device information version number may be 12 bits, with the device name, device UUID, transmission protocol, Bluetooth MAC address, account ID, and features supported by the software each occupying 2 bits. Assume that the current moment is t3. At this time, the first version number can be 010001000100, but the first device currently stores the device information with a medium frequency of change among the device information required for the second device to go online at the previous moment t1. The second version number can be 010000000000. Therefore, the first device can determine that the parts corresponding to the transmission protocol and account ID are different based on the first version number and the second version number, that is, it can be determined that the transmission protocol and account ID have expired, and it can also be determined that the device information such as device name, device UUID, Bluetooth MAC address and features supported by the soft center line is valid. In this way, after that, the first device can only re-acquire the transmission protocol and account ID corresponding to the current second device, and does not need to re-acquire the device name, device UUID, Bluetooth MAC address and features supported by the soft center line corresponding to the second device, which can save transmission resources. The above is explained by taking each part divided in the device information version number associating one device information as an example, but in the embodiment of the present application, a part divided in the device information version number can also be associated with multiple device information. In this case, it can be determined whether the multiple device information is valid based on the part in the first version number and the second version number.

[0118] Next, an example is provided for the second embodiment described above, where the device information version number is associated with the device information with medium and high frequency of change in the device information required for the second device to go online. In this case, the first device can determine whether the device information with medium and high frequency of change in the device information required for the second device to go online currently stored on the first device is valid based on the first version number and the second version number. The second version number can be the device information version number corresponding to the device information with medium and high frequency of change in the device information required for the second device to go online currently stored on the first device. Specifically, if the first version number and the second version number are the same, the first device can determine that the device information with medium and high frequency of change in the device information required for the second device to go online currently stored on the first device is the same as the device information with medium and high frequency of change in the device information required for the second device to go online currently, thus determining that the device information with medium and high frequency of change in the device information required for the second device to go online currently stored on the first device is valid. Conversely, if the first version number and the second version number are different, the first device can determine that the device information with medium and high frequency of change in the device information required for the second device to go online currently stored on the first device is invalid.

[0119] It should be understood that for the second method mentioned above, the device information version number can be divided into multiple parts, and each part can be respectively associated with one or more device information in the device information with medium change frequency and high change frequency in the device information required for the second device to go online. This is similar to the first method mentioned above, where each part can be respectively associated with one or more device information in the device information with medium change frequency in the device information required for the second device to go online. You can refer to the relevant description corresponding to the first method mentioned above and will not repeat it here.

[0120] It should be noted that in some cases (such as when the storage space of the first device is formatted, or the communication key has expired and been deleted), even if the second device has been online on the first device before, the first device may not have the communication key corresponding to the second device and / or the device information required for the second device to go online stored locally. In this case, it can be regarded as that the communication key corresponding to the second device currently stored in the first device, and / or the device information required for the second device to go online with medium change frequency in the device information required for the second device to go online has expired (or the device information required for the second device to go online with medium and high change frequencies has expired). The first device will subsequently need to establish a connection with the second device, and then authenticate the second device, and / or obtain the device information required for the current second device to go online.

[0121] 303. The first device establishes a connection with the second device.

[0122] If a first device determines that the communication key currently stored on the first device for a second device is valid, but the device information required for the second device to go online is invalid or partially invalid, the first device may establish a connection with the second device to obtain the device information required for the second device to go online and bring the second device online. It should be understood that if the first device determines that the communication key currently stored on the first device for the second device is valid, this indicates that the communication key previously negotiated by the first device for authenticating the second device is still usable. Therefore, in this case, the current communication key may continue to be used to reduce the number of connection establishments, thereby reducing the probability of signal conflicts between devices.

[0123] 304. The first device obtains the device information required for the current second device to go online.

[0124] After a communication connection (such as a Bluetooth connection or a Wi-Fi connection) is established between the first device and the second device, the first device can obtain the device information required for the second device to go online. In the process of obtaining the device information required for the second device to go online, the first device and the second device can use a communication key to perform encrypted communication.

[0125] Among them, since there are multiple ways to set the device information version number in the embodiment of the present application, there are also multiple corresponding situations in which the first device obtains the device information required for the current second device to go online.

[0126] In the first method described above, if the device information version number is associated with device information with a medium frequency of change in the device information required for online access corresponding to the unified second device, the first device can only obtain the device information with a medium frequency of change in the device information required for online access corresponding to the current second device. Device information with a high frequency of change in the device information required for online access corresponding to the current second device can be included in the first information, and the first device can obtain it from the first information.

[0127] For the second method mentioned above, the device information version number is associated with the device information with medium and high change frequencies in the device information required for the online operation of the unified second device. The first device can obtain the device information with medium and high change frequencies in the device information required for the online operation of the current second device.

[0128] In the first method described above, the device information version number can be divided into multiple parts, each of which can be associated with one or more pieces of device information in the device information required for the second device to go online and that has a medium frequency of change. The first device can only obtain the invalid device information in the device information required for the second device to go online and that has a medium frequency of change. For example, as shown in FIG5C , assuming that the first version number can be 010001000100 and the second version number can be 010000000000. In this case, the first device can determine that the two device information, the transmission protocol and the account ID, corresponding to the second device, have expired, and the device information, such as the device name, device UUID, Bluetooth MAC address, and features supported by the soft center line, corresponding to the second device, is valid. Therefore, the first device can only check and re-acquire the two device information, the transmission protocol and the account ID, corresponding to the current second device.

[0129] Similarly, for the second method mentioned above, the device information version number can be divided into multiple parts, each part can be respectively associated with one or more device information in the device information with medium change frequency and high change frequency in the device information required for the second device to go online. The first device can only obtain the invalid device information in the device information with medium change frequency and high change frequency in the device information required for the second device to go online.

[0130] It should be noted that in the embodiments of the present application, after the first device and the second device establish a connection, the manner in which the first device obtains the device information required for the second device to go online is not limited. For example, the first device may send a device information acquisition request to the second device, and the device information acquisition request may indicate whether to obtain all or part of the information. Accordingly, the second device may receive the device information acquisition request from the first device and then send the corresponding device information to the first device based on the device information acquisition request.

[0131] It should also be noted that in some cases (such as when the storage space of the first device is formatted), even if the second device has been online on the first device before, the first device may not have locally stored the device information with a change frequency of "unchanged" in the device information required for the second device to go online. In this case, in addition to obtaining the device information with a medium change frequency in the device information required for the second device to go online, the first device can also obtain the device information with a change frequency of "unchanged" in the device information required for the second device to go online.

[0132] 305. The first device establishes a connection with the second device.

[0133] When the first device determines that the device information required for the second device to go online currently stored in the first device is valid, but the communication key corresponding to the second device is invalid, the first device can establish a connection with the second device so that the first device can re-authenticate the second device, negotiate a new communication key, and then bring the second device online.

[0134] 306. The first device authenticates the second device and negotiates a new communication key.

[0135] After a communication connection (such as a Bluetooth connection or a Wi-Fi connection) is established between the first device and the second device, the first device can authenticate the second device and obtain a new communication key through negotiation. In an embodiment of the present application, there is no limitation on the authentication method between the first device and the second device. For example, the first device can authenticate whether the second device is trustworthy through a trust ring mechanism. In some possible implementations, the first device can use a HiChain module to authenticate the second device. It should also be noted that in some possible authentication methods, the second device can also dynamically generate relevant information (such as a PIN code, a QR code, etc.), and the first device can receive a PIN code entered by the user or a scanned QR code to authenticate the second device. It should be understood that in some cases, the first device may fail to authenticate the second device, thereby terminating the online process and making it impossible for the first device to go online with the second device.

[0136] It is understandable that in some cases, the second device may also authenticate the first device, that is, two-way authentication is required.

[0137] In some possible implementations, a Keystore may be used to store communication keys. Keystore is a key management tool that helps users create, store, and manage keys.

[0138] 307. The first device establishes a connection with the second device.

[0139] When the first device determines that the communication key corresponding to the second device currently stored in the first device is invalid, and the device information required for the second device to go online is invalid or partially invalid, the first device can establish a connection with the second device so that the first device can re-authenticate the second device, negotiate a new communication key, and obtain the invalid device information in the device information required for the second device to go online, and then bring the second device online.

[0140] 308. The first device authenticates the second device and negotiates a new communication key.

[0141] After a communication connection (such as a Bluetooth connection or a Wi-Fi connection) is established between the first device and the second device, the first device can authenticate the second device and obtain a new communication key through negotiation.

[0142] 309. The first device obtains the device information required for the current second device to go online.

[0143] After the first device negotiates a new communication key with the second device, the first device can obtain the device information required for the second device to go online based on the new communication key.

[0144] 310. The first device brings the second device online.

[0145] In the case that the first device locally stores a valid communication key corresponding to the second device and valid device information required for the second device to go online, the first device can bring the second device online.

[0146] Afterwards, when the first device and the second device need to perform operations such as cross-device transfer, file sharing, and multi-screen collaboration, the first device can establish a connection with the second device through the locally stored relevant information of the second device (such as Bluetooth MAC address, IP address, etc.) and perform encrypted communication based on a valid communication key. For example, if the first device has a display module (such as a display screen), after the first device brings the second device online, the user can view the second device added to the currently online devices through the display module of the first device.

[0147] It should be noted that after the first device brings the second device online, the first device can keep the second device alive by sending a BLE broadcast (such as sending a BLE broadcast message to the second device once every 5 minutes, requesting the second device to respond) or through the TCP keepALive mechanism (such as a period of 5 minutes) to detect whether the second device can communicate, whether it is online, etc. For example, if it is determined that the second device cannot communicate or is offline (such as sending a BLE broadcast message or ack packet to the second device 3 times at intervals, and the second device responds), the user can view through the display module of the first device that the second device has been removed from the currently online devices.

[0148] Optionally, in some possible implementations, before executing step 302, the first device may first determine whether a potential trusted relationship exists between the first device and the second device. If a potential trusted relationship exists, the first device may execute step 302. If no potential trusted relationship exists, the first device may execute steps 307-310 to bring the second device online. Alternatively, in some possible implementations, when no potential trusted relationship exists, the first device may also determine, based on the first version number, whether the device information required for bringing the second device online that is currently stored on the first device is valid. If valid, the second device may be brought online by executing steps 305, 306, and 310. If invalid or partially invalid, the second device may be brought online by executing steps 307-310. In other words, if no potential trusted relationship exists between the first device and the second device, even if the first device determines, based on the first verification data, that the communication key corresponding to the second device currently stored on the first device is valid, the first device still needs to establish a connection with the second device, re-authenticate the second device, and negotiate a new communication key.

[0149] The following examples illustrate possible ways to determine whether there is a potential trusted relationship between the first device and the second device. In the first way, the first device can locally store a trusted device list, which may include identification information of one or more devices. If the trusted device list includes the identification information of the second device, it can be considered that there is a potential trusted relationship with the second device. Otherwise, it can be considered that there is no potential trusted relationship with the second device. In this embodiment of the present application, the identification information of the devices in the potential trusted list is not limited. For example, it can be pre-configured or dynamically generated (such as adding the identification information of the previously authenticated device and setting a time limit). In the second way, the first device can determine whether the second device is logged into the same account as itself based on the identification information of the second device. In this case, the first device can request the corresponding device list from the account management server based on the currently logged-in account. The device list can include the identification information of all devices with the same account as the first device. The first device can check whether the device list includes the identification information of the second device. If it does, it can be considered that there is a potential trusted relationship with the second device. Otherwise, it can be considered that there is no potential trusted relationship with the second device. It should be understood that the above two ways are only exemplary and do not constitute limitations.

[0150] It is understood that in some embodiments, the first device may also send its own identification information, a Bloom code vector generated based on its currently stored valid communication key, and the device information version number of its current corresponding device information required for online access to the second device, so that the second device can online the first device in multiple levels. For example, the first device may periodically send the corresponding information via broadcast. For another example, the first device may send the corresponding information to the first device after bringing the second device online.

[0151] In the above process, if the first device and the second device are not connected, the second device can send its own identification information, first verification data, and first version number. The first device can then receive the second device's identification information, first verification data, and first version number sent by the second device. The first device can then perform a hierarchical onboarding of the second device based on the second device's identification information, first verification data, and first version number. As shown in Table 2 below, this can be divided into three levels.

[0152] Table 2

[0153] It can be seen that according to the actual situation of communication keys and device information, hierarchical online access can be carried out, wherein the time required for online access is from short to long in the order of level 1, level 2, level 3 and level 4. For example, level 1 takes about 1 second (s), level 2 takes about 2s, level 3 takes about 3 seconds, and level 4 takes about 4s. Through this hierarchical online access method, the number of times connection establishment and the information that needs to be interacted can be minimized, thereby greatly shortening the time required for online access and improving user experience. In the case of multiple devices, it can help multiple devices to quickly form a network to meet the user's usage needs. Moreover, by setting the device information version number and the device information in an associated manner, it can quickly help the first device determine whether it needs to query and obtain the relevant device information of the second device while occupying less transmission resources. In addition, since this hierarchical online access method can reduce the number of connection establishments, the number of device information acquisitions, and the number of authentications, it can also reduce the power consumption of the first and second devices.

[0154] In the embodiment corresponding to FIG. 3 above, the first information may include both the first verification data and the first version number. However, it should be understood that in other embodiments of the present application, the first information may include only one of the two, that is, only the first verification data or the first version number. The following is an exemplary description of the processing flow in these two cases.

[0155] Please refer to Figure 6, which is a flow chart of another communication method disclosed in an embodiment of the present application. Figure 6 corresponds to the case where only the first version number is included. As shown in Figure 6, the method may include but is not limited to the following steps:

[0156] 601. The second device sends identification information of the second device and first information to the first device, where the first information includes a first version number.

[0157] For the identification information and the first version number of the second device, reference may be made to the relevant description in the above step 301 .

[0158] 602. The first device determines whether the currently stored device information required for the second device to go online is valid based on the first version number. If it is valid, step 603 can be executed; if it is invalid or partially invalid, step 605 can be executed.

[0159] After the first device receives the identification information of the second device and the first information sent by the second device, it can determine that the first information is associated with the second device based on the identification information of the second device. Thereafter, the first device can determine whether the device information required for going online corresponding to the second device currently stored is valid based on the first version number in the first information. Wherein, if the first device determines that the device information required for going online corresponding to the second device currently stored in the first device is valid, the first device needs to establish a connection with the second device to perform device authentication on the second device and negotiate a communication key, and step 603 can be executed. If the first device determines that the device information required for going online corresponding to the second device currently stored in the first device is invalid or partially invalid, the first device needs to establish a connection with the second device to perform device authentication on the second device and negotiate a communication key, and needs to obtain the invalid device information, and step 605 can be executed.

[0160] For a specific manner in which the first device determines whether the currently stored device information required for the second device to go online is valid based on the first version number, reference may be made to the relevant description in the above step 302 .

[0161] 603. The first device establishes a connection with the second device.

[0162] 604. The first device authenticates the second device and negotiates a communication key.

[0163] Step 603 and step 604 are similar to the above-mentioned step 305 and step 306 respectively. Please refer to the relevant descriptions in the above-mentioned step 305 and step 306, and will not be repeated here.

[0164] 605. The first device establishes a connection with the second device.

[0165] 606. The first device authenticates the second device and negotiates a communication key.

[0166] 607. The first device obtains the device information required for the current second device to go online.

[0167] Steps 605-607 are similar to the above steps 307-309. Please refer to the relevant descriptions in the above steps 307-309 and will not be repeated here.

[0168] 608. The first device brings the second device online.

[0169] In the case that the first device locally stores a valid communication key corresponding to the second device and valid device information required for the second device to go online, the first device can bring the second device online.

[0170] Please refer to Figure 7 again, which is a flow chart of another communication method disclosed in an embodiment of the present application. Figure 7 corresponds to the case where only the first verification data is included. As shown in Figure 7, the method may include but is not limited to the following steps:

[0171] 701. The second device sends identification information of the second device and first information to the first device, where the first information includes first verification data.

[0172] For the identification information of the second device and the first verification data, reference may be made to the relevant description in the above step 301 .

[0173] 702. The first device determines whether the communication key corresponding to the second device currently stored is valid based on the first verification data. If it is valid, step 703 can be executed; if it is invalid, step 705 can be executed.

[0174] After the first device receives the identification information of the second device and the first information sent by the second device, it can determine that the first information is associated with the second device based on the identification information of the second device. Thereafter, the first device can determine whether the communication key corresponding to the currently stored second device is valid based on the first verification data in the first information. Wherein, if the first device determines that the communication key corresponding to the second device currently stored in the first device is valid, the first device needs to establish a connection with the second device to obtain the device information required for the current second device to go online, and step 703 can be executed. If the first device determines that the communication key corresponding to the second device currently stored in the first device is invalid, the first device needs to establish a connection with the second device to perform device authentication on the second device, negotiate the communication key, and obtain the device information required for the current second device to go online, and step 605 can be executed.

[0175] Regarding the specific manner in which the first device determines whether the currently stored communication key corresponding to the second device is valid based on the first verification data, reference may be made to the relevant description in the above step 302 .

[0176] 703. The first device establishes a connection with the second device.

[0177] 704. The first device obtains the device information required for the current second device to go online.

[0178] Step 703 and step 704 are similar to the above-mentioned step 303 and step 304 respectively. Please refer to the relevant descriptions in the above-mentioned step 303 and step 304, and will not be repeated here.

[0179] 705. The first device establishes a connection with the second device.

[0180] 706. The first device authenticates the second device and negotiates a communication key.

[0181] 707. The first device obtains the device information required for the current second device to go online.

[0182] Steps 605-607 are similar to the above steps 307-309. Please refer to the relevant descriptions in the above steps 307-309 and will not be repeated here.

[0183] 708. The first device brings the second device online.

[0184] In the case that the first device locally stores a valid communication key corresponding to the second device and valid device information required for the second device to go online, the first device can bring the second device online.

[0185] It should be understood that in the embodiments corresponding to Figures 3, 6, and 7 above, the above-mentioned processing flow is mainly illustrated by taking the first device and the second device as the execution subjects of the interaction diagram as an example, but this application does not limit the execution subjects of the interaction diagram. For example, the first device and the second device in Figures 3, 6, and 7 above can also be chips, chip systems, or processors that support the first device and the second device to implement the method, or can also be logic modules or software that can implement all or part of the functions of the first device and the second device.

[0186] In one possible implementation, the first device and the second device may include software modules such as a soft bus, an authentication module (such as a HiChain module), and a distributed application (such as a super terminal, a distributed device center, a cross-end fusion center, etc.). The following example illustrates the method embodiment corresponding to Figure 3 from the perspective of the soft bus, the authentication module, and the distributed application.

[0187] Please refer to Figure 8, which is a flow chart of another communication method disclosed in an embodiment of the present application. As shown in Figure 8, the method may include but is not limited to the following steps:

[0188] 801. The soft bus module of the second device sends a BLE broadcast message, including identification information of the second device and first information, where the first information includes a first version number and first verification data.

[0189] Exemplarily, the soft bus module of the second device can periodically broadcast, that is, periodically send a BLE broadcast message, which can include the identification information and first information of the second device, and the first information can include a first version number and first verification data. Accordingly, the soft bus module of the first device can receive the BLE broadcast message sent by the soft bus module of the second device.

[0190] For a detailed description of the identification information, the first version number, and the first verification data of the second device, reference may be made to the relevant description in the above step 301 .

[0191] It is understandable that the soft bus module of the second device can also broadcast through other means, such as WI-FI, Ethernet, UWB, etc.

[0192] 802. The soft bus module of the first device determines whether the communication key corresponding to the currently stored second device is valid based on the first verification data, and determines whether the device information required for going online corresponding to the currently stored second device is valid based on the first version number. When both are valid, the processing flow corresponding to situation 1 can be executed. When only the communication key is valid, the processing flow corresponding to situation 2 can be executed. When only the device information required for going online is valid, the processing flow corresponding to situation 3 can be executed. When both are invalid, the processing flow corresponding to situation 4 can be executed.

[0193] After the soft bus module of the first device receives the identification information and the first information of the second device sent by the soft bus module of the second device, it can determine that the first information is associated with the second device based on the identification information of the second device. After that, the soft bus module of the first device can determine whether the communication key corresponding to the currently stored second device is valid based on the first verification data in the first information, and can determine whether the device information required for going online corresponding to the currently stored second device is valid based on the first version number in the first information, so as to facilitate going online in multiple levels. Among them, there can be four specific situations, situation 1 can be that both are valid, that is, the communication key corresponding to the second device currently stored in the first device is valid, and the device information required for going online corresponding to the currently stored second device is valid, situation 2 can be that only the communication key corresponding to the second device currently stored in the first device is valid, situation 3 can be that only the device information required for going online corresponding to the currently stored second device is valid, and situation 4 can be that both are invalid.

[0194] 803. The soft bus module of the first device directly brings the second device online.

[0195] When the soft bus module of the first device determines that the communication key corresponding to the second device currently stored in the first device is valid, and the device information required for the second device to go online currently stored is valid, the soft bus module of the first device can directly bring the second device online, and can notify the distributed application that the second device is online, so that the distributed application can provide corresponding services to the user.

[0196] 804. The soft bus module of the first device establishes a connection with the soft bus module of the second device.

[0197] When the soft bus module of the first device determines that the communication key corresponding to the second device currently stored in the first device is valid, but the device information required for the second device to go online is invalid or partially invalid, the soft bus module of the first device can establish a connection with the soft bus module of the second device to obtain the device information required for the current second device to go online and bring the second device online.

[0198] 805. The soft bus module of the first device obtains the device information required for the current second device to go online.

[0199] After a communication connection is established between the soft bus module of the first device and the soft bus module of the second device, the soft bus module of the first device can obtain device information required for the current online access of the second device. In the process of obtaining the device information required for the current online access of the second device, the soft bus module of the first device and the soft bus module of the second device can use a communication key for encrypted communication.

[0200] 806. The soft bus module of the first device brings the second device online.

[0201] When the soft bus module of the first device obtains the device information required for the current second device to go online, the soft bus module of the first device can bring the second device online and notify the distributed application that the second device is online so that the distributed application can provide corresponding services to the user.

[0202] 807. The soft bus module of the first device establishes a connection with the soft bus module of the second device.

[0203] When the soft bus module of the first device determines that the device information required for the second device to go online currently stored in the first device is valid, but the communication key corresponding to the second device is invalid, the soft bus module of the first device can establish a connection with the soft bus module of the second device to re-authenticate the second device, negotiate a new communication key, and then bring the second device online.

[0204] 808. The authentication module of the first device authenticates the second device and negotiates a new communication key.

[0205] After the soft bus module of the first device establishes a connection with the soft bus module of the second device, the soft bus module of the first device can call the interface provided by the authentication module of the first device to authenticate the second device. Specifically, the authentication module of the first device and the authentication module of the second device can interact to authenticate the second device. After the authentication is passed, the authentication module of the first device and the authentication module of the second device can negotiate a new communication key. The authentication module of the first device can return the negotiated new communication key to the soft bus module of the first device, and the authentication module of the second device can also return the negotiated new communication key to the soft bus module of the second device, so that the soft bus module of the first device and the soft bus module of the second device can use the communication key for encrypted communication.

[0206] 809. The soft bus module of the first device brings the second device online.

[0207] When the soft bus module of the first device receives the communication key returned by the authentication module of the first device, the soft bus module of the first device can bring the second device online and notify the distributed application that the second device is online so that the distributed application can provide corresponding services to the user.

[0208] 810. The soft bus module of the first device establishes a connection with the soft bus module of the second device.

[0209] When the soft bus module of the first device determines that the communication key corresponding to the second device currently stored in the first device is invalid, and the device information required for the second device to go online is invalid or partially invalid, the soft bus module of the first device can establish a connection with the soft bus module of the second device to re-authenticate the second device, negotiate a new communication key, and obtain the invalid device information in the device information required for the second device to go online, and then go online for the second device.

[0210] 811. The authentication module of the first device authenticates the second device and negotiates a new communication key.

[0211] 812. The soft bus module of the first device obtains the device information required for the current second device to go online.

[0212] When the soft bus module of the first device receives the communication key returned by the authentication module of the first device, the soft bus module of the first device can then obtain the device information required for the current second device to go online.

[0213] 813. The soft bus module of the first device brings the second device online.

[0214] When the soft bus module of the first device obtains the device information required for the current second device to go online, the soft bus module of the first device can bring the second device online and notify the distributed application that the second device is online so that the distributed application can provide corresponding services to the user.

[0215] It should be understood that, in fact, the operations performed by the various functional modules in FIG. 8 may be performed by corresponding chips, chip systems or processors (such as a CPU).

[0216] Figure 9 shows a schematic diagram of a possible hardware structure of an electronic device 900 provided in an embodiment of the present application. Electronic device 900 may include a communication interface 904, at least one processor 902, and at least one memory 901. Optionally, it may also include a bus 903. Memory 901, processor 902, and communication interface 904 may be connected via bus 903.

[0217] The memory 901 is used to provide storage space, which can store data such as an operating system and computer programs. In the embodiment of the present application, the memory can store device information version numbers (such as the first version number and the second version number mentioned above), verification data (such as the first verification data and the second verification data mentioned above), device information, etc. The memory 901 can be a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a portable read-only memory (CD-ROM), or a combination of multiple thereof.

[0218] The processor 902 is a module that performs arithmetic operations and / or logical operations, and can specifically be one or more combinations of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and a complex programmable logic device (CPLD).

[0219] The communication interface 904 is used to receive data sent externally and / or send data externally. It can be a wired link interface such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, etc.). Optionally, the communication interface 904 can also include a transmitter (such as a radio frequency transmitter, antenna, etc.) or a receiver coupled to the interface. Exemplarily, the electronic device 900 can include a communication chip, such as a Bluetooth chip, a wireless local area network (WLAN) chip, etc.

[0220] In one design, the electronic device 900 can be used to perform the functions of the first device in the aforementioned embodiment. For details, please refer to the corresponding description of the first device in the above method embodiment, which will not be repeated here.

[0221] In another design, the electronic device 900 can be used to perform the functions of the second device in the aforementioned embodiment. For details, please refer to the corresponding description of the second device in the above method embodiment, which will not be repeated here.

[0222] In one possible design, the processor 902 in the electronic device 900 is used to read the computer program stored in the memory 901 to execute the operations performed by the first device or the second device in the aforementioned communication method, such as the communication method described in the embodiments corresponding to Figures 3, 6, 7 or 8.

[0223] It should be noted that the electronic device 900 shown in FIG9 is only one implementation of the embodiment of the present application. In actual applications, the electronic device 900 may also include more or fewer components, which is not limited here.

[0224] It should be noted that the relevant information (ie, the same information or similar information) and related descriptions in the above different embodiments can refer to each other.

[0225] It should be understood that the transmission in the embodiments of the present application can be direct transmission or indirect transmission. Direct transmission means that a device or module sends information / data directly to a corresponding device or module, and indirect transmission means that a device or module sends information / data to a corresponding device or module through another device or module.

[0226] Obviously, the embodiments described above are only some of the embodiments of this application, and not all of them. Reference to "embodiments" herein means that the specific features, structures, or characteristics described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it refer to independent or alternative embodiments that are mutually exclusive with other embodiments. It is understood, both explicitly and implicitly, that the embodiments described herein can be combined with other embodiments. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. In the specification, claims, and accompanying drawings of this application, the terms "first," "second," "third," and so on are used to distinguish between different objects, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a list of steps or elements may be included, or alternatively, steps or elements not listed may be included, or alternatively, other steps or elements inherent to the process, method, product, or device may be included. It is understandable that, in some embodiments, the equal sign of the above-mentioned conditional judgment can be taken as greater than one end or less than one end. For example, the above-mentioned conditional judgment of a threshold being greater than, less than, or equal to can also be changed to a conditional judgment of the threshold being greater than, equal to, or less than. This is not limited here. It is also understandable that, for an architecture with multiple devices or modules, if one of the devices or modules generates information and another device or module uses the information, there can be multiple ways for the other device to obtain the information. For example, the device or module that generates the information can send the information directly to the device or module that uses the information (equivalent to direct sending), or the device or module that generates the information can send the information to the device or module that uses the information through other devices or modules (equivalent to indirect sending).

[0227] It will be appreciated that only the parts relevant to the present application, not all of the contents, are shown in the accompanying drawings. It will be appreciated that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the various operations (or steps) as sequential processes, many of the operations therein can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the various operations can be rearranged as long as it is logical. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0228] As used in this specification, the terms "component," "module," "system," "unit," and the like are used to refer to computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a unit can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or distributed between two or more computers. In addition, these units can be executed from various computer-readable media having various data structures stored thereon. For example, a unit can communicate through local and / or remote processes based on signals having one or more data packets (e.g., data from a second unit interacting with another unit in a local system, a distributed system, and / or a network. For example, the Internet interacts with other systems via signals).

[0229] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of this application. It should be understood that the above description is only the specific implementation methods of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of this application should be included in the scope of protection of this application.

Claims

1. A device online method, applied to a first device, characterized in that: include: Receive a first message, where the first message includes identification information of a second device, first verification data, and a first version number, where the first verification data is obtained based on a valid communication key currently stored on the second device, and the first version number is a version number of device information required for the second device to go online. Determining, based on the first verification data, that the communication key corresponding to the second device currently stored in the first device is valid, and determining, based on the first version number, that the device information required for going online corresponding to the second device currently stored in the first device is valid; Bring the second device online.

2. The method according to claim 1, characterized in that The method further comprises: Receive a second message, where the second message includes identification information of a third device, third verification data, and a third version number, where the third verification data is obtained based on a valid communication key currently stored on the third device, and the third version number is a version number of device information required for the third device to go online. Determining, based on the third verification data, that a communication key corresponding to the third device currently stored in the first device is valid, and determining, based on the third version number, that device information required for going online corresponding to the third device currently stored in the first device is invalid; Establishing a connection with the third device and obtaining device information required for the third device to go online; Bring the third device online.

3. The method according to claim 1 or 2, characterized in that The method further comprises: Receive a third message, the third message including identification information of a fourth device, fourth verification data, and a fourth version number, wherein the fourth verification data is obtained based on a valid communication key currently stored on the fourth device, and the fourth version number is a version number of device information required for the fourth device to go online; Determining, based on the fourth verification data, that a communication key corresponding to the fourth device currently stored in the first device is invalid, and determining, based on the fourth version number, that device information required for going online corresponding to the fourth device currently stored in the first device is valid; Establishing a connection with the fourth device, authenticating the fourth device, and negotiating a communication key; Bring the fourth device online.

4. The method according to any one of claims 1 to 3, characterized in that The first verification data includes a first Bloom code vector, the first Bloom code vector is generated based on a valid communication key currently stored by the second device and one or more hash functions, and determining, based on the first verification data, that the communication key corresponding to the second device currently stored by the first device is valid includes: Based on the first Bloom code vector, it is determined that the communication key corresponding to the second device currently stored in the first device is valid.

5. The method according to claim 4, characterized in that The determining, based on the first Bloom code vector, that the communication key corresponding to the second device currently stored by the first device is valid includes: Processing the communication key corresponding to the second device currently stored on the first device using one or more hash functions corresponding to the first Bloom code vector to obtain one or more hash values; When the values ​​of the bits corresponding to the one or more hash values ​​in the first Bloom code vector are all 1, it is determined that the communication key corresponding to the second device currently stored in the first device is valid.

6. The method according to any one of claims 1 to 5, characterized in that The determining, based on the first version number, device information required for the second device to go online and currently stored on the first device effectively includes: When the first version number is the same as the second version number, it is determined that the device information required for the second device to go online currently stored in the first device is valid; the second version number is the version number of the device information required for the second device to go online currently stored in the first device.

7. The method according to any one of claims 2 to 6, characterized in that: The determining, based on the third version number, that the device information currently stored in the first device and required for the third device to go online is invalid includes: When the third version number is different from the fifth version number, it is determined that the device information required for the third device to go online currently stored in the first device is invalid; the fifth version number is the version number of the device information required for the third device to go online currently stored in the first device.

8. The method according to claim 7, characterized in that The device information required for the third device to go online currently stored in the first device and the device information required for the third device to go online currently stored in the first device respectively include corresponding multiple pieces of device information, the third version number and the fifth version number respectively include multiple parts, each of the multiple parts corresponding to one or more pieces of device information in the multiple pieces of device information; The method further comprises: If the third version number is different from the fifth version number, determining, based on each corresponding part of the third version number and the fifth version number, whether the device information corresponding to each part in the device information required for the third device to go online and currently stored by the first device is valid; If the third version number is identical to the first part corresponding to the fifth version number, determining that the device information corresponding to the first part in the device information required for the third device to go online currently stored on the first device is valid; the first part is any one of the multiple parts; In a case where the third version number and the first part corresponding to the fifth version number are different, determining that the device information corresponding to the first part in the device information required for the third device to go online, currently stored by the first device, is invalid; The acquiring of device information required for the current third device to go online includes: Obtain device information corresponding to the invalid part of the device information required for the current third device to go online.

9. The method according to any one of claims 6 to 8, characterized in that: The third version number and the fifth version number include a second part and a third part, the second part occupies more bits than the third part, and the frequency of change of the device information corresponding to the second part is greater than the frequency of change of the device information corresponding to the third part.

10. The method according to any one of claims 1 to 9, characterized in that The device information required for the second device to go online includes device information of a first change frequency, device information of a second change frequency, and device information of a third change frequency, wherein the first change frequency is greater than the second change frequency, the second change frequency is greater than the third change frequency, and the third change frequency is 0; The first version number is the version number of the device information with the second change frequency in the device information required for the current online operation of the second device, or the first version number is the version number of the device information with the first change frequency and the second change frequency in the device information required for the current online operation of the second device; Among them, when the first version number is the version number of the device information with the second change frequency in the device information required for the current second device to go online, the first message also includes the device information with the first change frequency in the device information required for the current second device to go online.

11. The method according to any one of claims 1 to 10, characterized in that The first verification data and the first version number are carried in the data field of the first message.

12. An electronic device, characterized in that: It comprises a processor and a communication interface; the communication interface is used to receive and / or send data; the processor calls a computer program or computer instruction stored in a memory to implement the method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program or computer instructions, and the computer program or computer instructions are executed by a processor to implement the method according to any one of claims 1 to 11.

14. A computer program product, characterized in that The computer program product includes computer program codes or computer instructions, and when the computer program codes or computer instructions are executed, the method according to any one of claims 1 to 11 is implemented.

Images