Methods, apparatuses, electronic devices, and media for identifying devices

Abstract

Embodiments of the present application provide a method, apparatus, electronic device and medium for identifying a device. In the method, in response to receiving a broadcast message from a second device, a first device determines that the second device is an active trusted device based on an identity key of a trusted device set of the first device and a source address of the broadcast message, and provides information of the second device. In this way, when the first device and the second device have a trusted relationship, the first device can identify the second device in an active state through address information of a broadcast system of the second device. Therefore, the second device can be identified without broadcasting its identification information, reducing the risk of being monitored and tracked by the second device.

Description

Technical Field

[0001] The embodiments of this disclosure primarily relate to the field of communication technology. More specifically, the embodiments of this disclosure relate to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for identifying a device. Background Technology

[0002] With the advent of the Internet of Things era, more and more electronic devices are appearing in users' lives. A user is likely to own many electronic devices at the same time. Different electronic devices have different advantages in hardware capabilities and provide different functions. Users often use multiple electronic devices for different tasks such as entertainment, communication, and work.

[0003] To facilitate access to these electronic devices or to obtain useful information from them, these devices send broadcast messages. However, broadcast messages may lead to the disclosure of user credentials, resulting in the risk of user surveillance. This risk exists on devices across various operating systems. Therefore, a secure method for identifying devices is needed to reduce the risk of user identification and tracking. Summary of the Invention

[0004] Embodiments of this application provide a scheme for identifying devices.

[0005] According to a first aspect of this application, a method for identifying a device is provided, comprising: in response to receiving a broadcast message from a second device, a first device determining that the second device is an active trusted device based on an identity key of a set of trusted devices of the first device and the source address of the broadcast message; and the first device providing information about the second device.

[0006] In this application, the first device and the second device are devices with broadcast communication capabilities (sending and receiving broadcasts), and when they are trusted by each other, they can further establish a connection for business transmission. In this application, a trusted device refers to a device that trusts each other and can send personal data, such as devices with the same user account or devices that have been authenticated by other means.

[0007] The first device possesses identity keys of one or more other devices with which it has a trusted relationship, and can use these identity keys to verify whether a particular device is a trusted device. According to embodiments of this application, when a device is active, it broadcasts a message (e.g., a heartbeat message). The broadcast message does not carry a device identifier; its address is generated via the device's identity key and is variable to ensure that the device is not monitored or tracked. According to embodiments of this application, when receiving a broadcast message from another device, the first device can use the identity keys of trusted devices from its set of trusted devices to verify the address of the broadcast message, thereby discovering the active trusted device.

[0008] In this way, when the first and second devices have a trusted relationship, the first device can identify the active second device through the address information of the second device's broadcast system. Therefore, the second device can be identified without broadcasting its identification information, reducing the risk of the second device being monitored and tracked.

[0009] In some embodiments, determining that the second device is an active trusted device may include: verifying the broadcast message using a first identity key from the set of trusted devices' identity keys and the source address; and if the broadcast message passes verification, the first device determines that the second device is an active trusted device. In this way, the first device can verify whether the source of the broadcast message is a trusted device based on pre-stored trusted device identity keys.

[0010] In some embodiments, verifying the broadcast message may include: generating a hash value based on the first identity key and a first portion of the source address; comparing the hash value with a second portion of the source address; and determining that the broadcast message has passed verification if the hash value and the second portion match. In this way, a reliable method for verifying broadcast messages using an identity key is provided.

[0011] In some embodiments, providing information about the second device may include: in response to receiving a search request from a user regarding a trusted device, the first device provides the user with information about the second device. In this way, a user can operate the first device to request the discovery of a trusted device associated with the first device's activities, and information about the second device (e.g., graphical elements displayed on a user interface) is provided to the user to facilitate further operation of the discovered trusted device.

[0012] In some embodiments, the method according to the first aspect of this application may further include: in response to receiving an operation from the user on the second device, the first device establishes a connection with the second device. In this manner, the first device can be connected to a discovered, active, and trusted device based on user operation to meet specific business needs, without requiring verification, pairing, or other processes, thereby accelerating connection speed and providing a better user experience.

[0013] In some embodiments, the identity key of the trusted device set is stored at the first device, and the method may further include: in response to determining that a target trusted device in the trusted device set has withdrawn from the trusted relationship with the first device, the first device deletes the identity key of the target trusted device from the stored identity key of the trusted device set. In this way, the trusted relationships between the first device and other devices can be persistently maintained and dynamically updated, thereby enabling rapid detection of active trusted devices.

[0014] In some embodiments, the identity key may be an identity resolution key. In some embodiments, the broadcast message may be a Bluetooth broadcast message. In this way, the identity key can be applied to a randomized broadcast address conforming to the Bluetooth communication protocol.

[0015] According to a second aspect of this application, a communication method is provided, comprising: a first device determining that the second device is a trusted device of the first device based on authentication information received from the second device; the first device sending an identity key of the first device to the second device; the first device receiving the identity key of the second device from the second device, wherein the identity key of the second device is used to generate a source address of a broadcast message of the second device; and the first device adding the identity key of the second device to an identity key set of trusted devices of the first device.

[0016] In this way, the first device can exchange its identity keys with other devices that are certified as trusted devices to form a trusted device network. In the trusted device network, devices can identify each other through the address information of broadcast messages, without having to carry identification information in the broadcast messages, thus avoiding the monitoring and tracking of devices.

[0017] In some embodiments, determining that the second device is a trusted device of the first device may include: sending the account information of the first device to the second device; receiving authentication information for the account information of the first device from the second device; and determining that the second device is a trusted device if the authentication information indicates that the first device and the electronic device have the same or associated account. In this way, when multiple devices have the same or associated account information, these devices are considered to be trusted by each other, thereby providing a convenient and fast networking method for trusted device networks.

[0018] In some embodiments, determining that the second device is a trusted device of the first device may include: obtaining binding information from the authentication information; determining, based on the binding information, whether the first device and the second device have been bound together; and if it is determined that the first device and the second device have been bound together, determining that the second device is a trusted device of the first device. In some embodiments, the binding information indicates that the two devices are bound together by at least one of a QR code, a PIN code, and physical contact. In this way, when multiple devices are bound together, these devices are considered to be trusted by each other, thereby providing a flexible and widely applicable networking method for trusted device networks.

[0019] In some embodiments, the method according to the second aspect of this application may further include: the first device sending the identity key of the second device to a trusted device in the set of trusted devices; and the first device sending the identity key of the trusted device in the set of trusted devices to the second device. In this manner, the identity keys of multiple mutually trusted devices can be quickly disseminated and shared, thereby providing a convenient and efficient networking method for trusted device networks.

[0020] In some embodiments, the method according to the second aspect of this application may further include: if the second device is determined to be a trusted device of the first device, establishing a connection between the first device and the second device. In this manner, it is possible to facilitate the exchange of identity keys between the first device and the second device, which is authenticated as a trusted device.

[0021] In some embodiments, the method according to the second aspect of this disclosure may further include: in response to determining that the second device has exited a trusted relationship with the first device, the first device deletes the identity key of the second device from the identity keys of the first device's trusted device set. In this way, the first device can manage and dynamically maintain its own trusted device set.

[0022] In some embodiments, the method according to the second aspect of this application may further include: updating the identity key of the first device if it is determined that the first device has terminated its trusted relationship with the set of trusted devices. In this way, the first device can easily terminate its trusted relationship with other devices.

[0023] In some embodiments, the identity key may be an identity resolution key. In some embodiments, the broadcast message may be a Bluetooth broadcast message. In this way, the identity key can be applied to a randomized broadcast address conforming to the Bluetooth communication protocol.

[0024] According to a third aspect of this application, a communication apparatus is provided, comprising: an active trusted device determining unit configured to, in response to receiving a broadcast message from a second device, determine the second device as an active trusted device based on an identity key of a trusted device set of a first device and the source address of the broadcast message; and an information providing unit configured to provide information about the second device.

[0025] In some embodiments, the active trusted device determination unit may further be configured to: verify the broadcast message using a first identity key from the identity keys of the trusted device set and the source address; and if the broadcast message passes verification, determine the second device as an active trusted device.

[0026] In some embodiments, the active trusted device determination unit may further be configured to: generate a hash value based on the first identity key and a first portion of the source address; compare the hash value with a second portion of the source address; and determine that the broadcast message has been verified if the hash value and the second portion match.

[0027] In some embodiments, the information providing unit may also be configured to: in response to receiving a search request from a user regarding a trusted device, provide the user with information about the second device.

[0028] In some embodiments, the apparatus according to the third aspect of this application may further include: a connection establishment unit configured to establish a connection with the second device in response to receiving an operation by the user on the second device.

[0029] In some embodiments, the apparatus according to the third aspect of this application may further include an identity key storage unit configured to: store identity keys of the trusted device set; and delete the identity key of the target trusted device from the identity key of the trusted device set in response to determining that a target trusted device in the trusted device set has withdrawn from a trusted relationship with the first device.

[0030] In some embodiments, the identity key may be an identity resolution key. In some embodiments, the broadcast message may be a Bluetooth broadcast message.

[0031] According to a fourth aspect of this application, a communication apparatus is also provided, comprising: an authentication unit configured to determine that the second device is a trusted device of a first device based on authentication information received from the second device; an identity key exchange unit configured to send an identity key of the first device to the second device and receive an identity key of the second device from the second device, wherein the identity key of the second device is used to generate a source address of a broadcast message of the second device; and an identity key addition unit configured to add the identity key of the second device to an identity key set of trusted devices of the first device.

[0032] In some embodiments, the authentication unit may also be configured to: send account information of the first device to the second device; receive authentication information for the account information of the first device from the second device; and determine the second device as a trusted device of the first device if the authentication information indicates that the first device and the second device have the same or associated account.

[0033] In some embodiments, the authentication unit may also be configured to obtain binding information from the information used for authentication; determine, based on the binding information, whether the first device and the second device have been bound; and if it is determined that the first device and the second device have been bound, determine that the second device is a trusted device of the first device.

[0034] In some embodiments, the binding information indicates that two devices are bound together by at least one of a QR code, a PIN code, and physical contact.

[0035] In some embodiments, the identity key exchange unit may also be configured to: send the identity key of the second device to a trusted device in the set of trusted devices; and send the identity key of the trusted device in the set of trusted devices to the second device.

[0036] In some embodiments, the apparatus according to the fourth aspect of this application may further include: a connection establishment unit configured to establish a connection between the first device and the second device.

[0037] In some embodiments, the apparatus according to the fourth aspect of this application, wherein the identity key storage unit is further configured to delete the identity key of the second device from the identity key set of trusted devices of the first device in response to determining that the second device has exited a trusted relationship with the first device.

[0038] In some embodiments, the apparatus according to the fourth aspect of this application may further include: an identity key update unit configured to update the identity key of the first device if it is determined that the first device has exited a trusted relationship with the set of trusted devices.

[0039] In some embodiments, the identity key may be an identity resolution key. In some embodiments, the broadcast message may be a Bluetooth broadcast message.

[0040] According to a fifth aspect of this application, an electronic device is also provided, comprising: a processing unit and a memory; the processing unit executes instructions in the memory, causing the electronic device to perform the method according to a first or second aspect of this application.

[0041] According to a sixth aspect of this application, a computer-readable storage medium is also provided, having stored thereon one or more computer instructions, wherein one or more computer instructions, when executed by a processor, cause the processor to perform the method described according to the first or second aspect of this application.

[0042] According to a sixth aspect of this application, a computer program product is also provided, including machine-executable instructions that, when executed by a device, cause the device to perform the method described according to a first or second aspect of this application. Attached Figure Description

[0043] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 An exemplary system diagram provided in this application is shown; Figures 2a to 2b This is a schematic diagram illustrating a set of application interfaces provided by embodiments of this application; Figure 3a A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application is shown; Figure 3b A schematic diagram of the software structure of an electronic device provided in an embodiment of this application; Figures 4a to 4c These are schematic diagrams of an application interface provided in an embodiment of this application; Figure 5 A schematic diagram illustrating interactions between devices according to some embodiments of this application is shown; Figures 6a to 6d This is another set of application interface diagrams provided by embodiments of this application; Figure 7A schematic diagram illustrating interactions between devices according to some embodiments of this application is shown; Figure 8 A schematic flowchart of a communication method according to some embodiments of this application is shown; Figure 9 A schematic flowchart of a communication method according to some embodiments of this application is shown; Figure 10 A schematic block diagram of a communication device according to some embodiments of this application is shown; Figure 11 A schematic block diagram of a communication device according to some embodiments of this application is shown. Detailed Implementation

[0044] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0045] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0046] Electronic devices in the Internet of Things (IoT) often notify their presence to surrounding devices via broadcast messages (e.g., Bluetooth broadcasts for heartbeats), and may also carry business data within these broadcast messages. To identify themselves, electronic devices often include identifying information in their broadcast messages, making them easily identifiable and trackable. Malicious users may use these broadcast messages to monitor other users. This risk exists in devices running operating systems such as Windows 10®, iOS®, Android®, and macOS®. For example, for Apple devices, the payload (AdvData field) of a Bluetooth broadcast message includes a company identifier (e.g., 0x004c), the device's nearby field, and the handoff field as device identification information; for Windows 10® devices, the broadcast message payload includes a company identifier (0x0006) and a 27-byte string as identification information. Although these devices use randomized MAC addresses (i.e., source addresses), broadcast messages are generally unencrypted and cannot be used for authentication. Therefore, attackers can easily obtain this characteristic information by listening for a period of time to track the device.

[0047] While secure connections between devices (e.g., pairing) can be used to receive heartbeat messages or transmit business data, the number of connections each device can maintain is limited (e.g., typically a maximum of seven devices simultaneously), while the number of discoverable devices in the vicinity may be much greater, making it impossible to maintain an active connection with all devices. Furthermore, some lightweight devices (e.g., smart water bottles, smart toothbrushes, etc.) may not be paired, and are unlikely to maintain a continuous connection, due to power consumption considerations. Additionally, even after pairing, users may still want to be able to use these lightweight devices when switching to richer devices like phones or tablets, or they may want other trusted devices, whether with the same account or different accounts, to be able to use them. In other words, when a device sends a broadcast message, trusted devices should be able to identify it. Moreover, because broadcast messages from electronic devices may be randomized using their own identity keys, only devices possessing those keys can identify the source of the broadcast message. However, traditionally, device identity keys can only be exchanged through pairing, which also complicates the reception of broadcast messages and device identification.

[0048] Therefore, a secure method for identifying devices is needed to reduce the risks of device surveillance and tracking. This application provides a scheme for identifying devices using broadcast messages, specifically for IoT applications. In this scheme, devices establish a trusted relationship and exchange identity keys. These identity keys can then be used to generate the address of a broadcast message, allowing the device to be identified by its trusted device without carrying identification information in its broadcast message. According to embodiments of this disclosure, when a first device (e.g., a mobile phone, tablet, etc.) receives a broadcast message from a second device (e.g., a lightweight device), it uses the identity key of its known trusted device to verify the address of the broadcast message. If the verification is successful, it indicates that the second device is its trusted device, and the corresponding identity key used implicitly contains or corresponds to the device's identification information. This achieves secure identification of the second device, and the second device does not need to carry identification information that could lead to tracking risks in its broadcast message.

[0049] The system architecture involved in the embodiments of this application will be introduced first below.

[0050] Figure 1 An exemplary system diagram provided in this application is shown. Figure 1 As shown, the system includes multiple electronic devices, such as the exemplary electronic devices 200, 201, 202, 203, and 204. The various electronic devices within the system can form a network (i.e., a network) according to certain communication protocols and networking strategies, enabling communication between them. For example, the electronic devices in the system can connect wirelessly. For instance, connections can be established through at least one of the following wireless connection methods: Bluetooth (BT) or Bluetooth Low Energy (BLE), Near Field Communication (NFC), Wireless Fidelity (Wi-Fi), or Wi-Fi Direct. This application does not specifically limit the type of electronic device (e.g., electronic device 200, electronic device 201, electronic device 202, electronic device 203, or electronic device 204). In some embodiments, the electronic device in this application may be a mobile phone, wearable device (e.g., smart bracelet, smartwatch, earphone, etc.), tablet computer, laptop computer, handheld computer, ultra-mobile personal computer (UMPC), cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, etc., and may also be a television, large screen, speaker, television set, refrigerator, air conditioner, in-vehicle equipment, printer, projector, etc. Exemplary embodiments of the electronic device include, but are not limited to, electronic devices running iOS®, Android®, Microsoft®, Harmony, or other operating systems.

[0051] In some embodiments, electronic devices 200, 201, 202, 203, and 204 can be connected to a local area network (LAN) via wired or wireless fidelity connections. Electronic devices 200, 201, 202, 203, and 204 can communicate with each other through the LAN. Furthermore, electronic devices 200, 201, 202, 203, and 204 can also communicate with each other through third-party devices within the LAN, such as routers, gateways, or smart device controllers.

[0052] In some embodiments, electronic devices 200, 201, 202, 203, and 204 may have a distributed operating system. With this distributed operating system, electronic devices 200, 201, 202, 203, and 204 form a network of trusted devices with mutually trusted relationships, constituting a seemingly integrated super terminal from the user's perspective. The super terminal function allows the user to automatically connect all nearby smart devices equipped with this distributed operating system, forming a collaborative working scenario. For example, it can identify other currently active trusted devices, establish connections with these trusted devices, and transmit data. According to embodiments of this application, when active, electronic devices 200, 201, 202, 203, and 204 broadcast heartbeat-indicating messages to their surroundings so that they can be recognized by other devices covered by the super terminal, and secure connections between devices can be established according to user instructions.

[0053] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the system architecture. In other embodiments of this application, the system architecture may include more or fewer devices than illustrated.

[0054] Based on the above Figure 1 The system architecture diagram shown illustrates that, in one possible implementation, when electronic devices 200, 201, 202, 203, and 204 identify or communicate, the electronic devices need to verify or establish a trusted relationship to provide support for subsequent data synchronization.

[0055] In some embodiments, if electronic device 200 can discover, via a mobile network or the Internet, that one or more other devices have logged-in accounts that are accounts of electronic device 200, or that the accounts logged-in by the one or more other devices are associated accounts of the account logged in by electronic device 200, then the one or more other devices and electronic device 200 have a trust relationship. These one or more other devices include electronic device 201, electronic device 202, electronic device 203, or electronic device 204. Devices logged into the same account or associated accounts can obtain each other's device information and achieve data communication. The associated account can be an account authorized by the same account.

[0056] The aforementioned accounts can be accounts provided to users by cloud server providers, such as Huawei accounts, or accounts used to log in to applications, such as accounts for various communication software and payment software.

[0057] In some embodiments, trust relationships can be established between electronic devices through manual addition, including methods such as tapping and scanning. For example, such as... Figure 2a As shown, users can access the device management interface 310 from the Settings app. The device management interface 310 can include a list named "My Devices". "My Devices" includes the device itself and the speaker. The device and speaker can be devices using the same account (e.g., sharing a Huawei account). Alternatively, the device and speaker can be devices using different accounts but authenticated and bound together.

[0058] Optionally, the device management interface 310 may include a "Bind Other Devices" button 311. In this embodiment, binding refers to establishing a trusted relationship between two devices, thereby enabling operations such as device identification and data synchronization between the devices. In response to the user's operation on the "Bind Other Devices" button 311 (e.g., clicking), the interface enters... Figure 2b The device binding interface 320 shown includes a list of scanned addable devices, from which the user can select the device they wish to bind. For example... Figure 2b The room TV 321, tablet 322, and smartwatch 323 shown herein can be used to bind electronic devices to the room TV 321, tablet 322, or smartwatch 323 by clicking the binding button 321A corresponding to the room TV 321, the binding button 322A corresponding to the tablet 322, or the binding button 323A corresponding to the smartwatch 323.

[0059] Optionally, the device binding interface 320 also includes a tap-to-add button 324 and a scan-to-add button 325, which can be used to bind with electronic devices that the electronic device has not scanned. For example, in response to a user operation on the tap-to-add button 324, the electronic device enables NFC and can bind to the other device by tapping its back against the ontag tag on the other device; in response to a user operation on the scan-to-add button 325, the electronic device scans the QR code of the other device to bind to the other device.

[0060] It should be understood that, Figure 2a and Figure 2b The positions, names, and shapes of the various elements (e.g., buttons, icons, text, etc.) in the corresponding UI interface are not fixed and can be freely combined or designed according to requirements. For example, you can... Figure 2a Replace button 311 in the middle with Figure 2b Buttons 324 and 325 are shown in the image.

[0061] It should be noted that the identification and communication between devices to achieve the embodiments of this application can be based on the same network (e.g., a super terminal); or it can be based on the existence of a trust relationship between the devices, such as a common account, associated account, or binding relationship; or it can be based on the same network and the establishment of a trust relationship. This application does not limit this.

[0062] The following uses electronic device 100 as an example to introduce the electronic devices involved in the embodiments of this application (electronic device 100 includes electronic device 200, electronic device 201, electronic device 202, electronic device 203, electronic device 204, etc.).

[0063] See Figure 3a , Figure 3a A schematic diagram of the structure of an exemplary electronic device 100 provided in an embodiment of this application is shown.

[0064] like Figure 3a As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0065] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0066] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0067] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0068] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0069] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0070] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0071] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0072] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0073] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0074] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0075] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0076] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0077] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0078] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0079] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0080] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0081] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0082] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0083] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0084] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including UWB, wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0085] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0086] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0087] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0088] In some embodiments of this application, the display screen 194 displays the interface content currently output by the system. For example, the interface content is the interface provided by an instant messaging application.

[0089] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0090] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0091] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0092] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0093] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0094] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs can enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0095] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0096] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0097] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0098] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0099] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0100] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0101] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In some embodiments, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic device 100 may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0102] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0103] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0104] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0105] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0106] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with or separate from the electronic device 100.

[0107] The specific description of the hardware structure of electronic device 100 described above applies to the description of the hardware structure of electronic devices 200, 201, 202, 203, and 204.

[0108] Figure 3b A software structure block diagram of an electronic device 100 according to an embodiment of this application is shown.

[0109] Layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the hardware abstraction layer (HAL). Figure 3b (Not illustrated in the text), and the kernel layer.

[0110] The application layer can include a series of application packages.

[0111] like Figure 3b As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, games, shopping, travel, and instant messaging (such as SMS). Additionally, the application package may also include system applications such as the home screen (i.e., desktop), the negative one screen, control center, and notification center. In this embodiment, the application package may also include a hyperterminal application, which can be a system application or a third-party application. The application package may also include a task flow manager application for calling and managing the task flow manager.

[0112] The HyperTerminal application provides a service or function that enables electronic device 100 to establish a trusted device network with other electronic devices, and enables electronic device 100 to identify the trusted device of its activity by receiving broadcast heartbeat messages from trusted devices.

[0113] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0114] like Figure 3b As shown, the application framework layer may include a task flow manager, a database management system (DBMS), a local task flow database, a distributed database, an input manager, a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, a display manager, an activity manager, and so on.

[0115] The Trusted Device Manager manages a set of trusted devices for electronic devices. This set includes the trusted devices' identity keys, current addresses, and status information. The Trusted Device Manager adds, updates, and deletes trusted devices based on information that can be used to authenticate the system. It can also generate and update the identity keys for the electronic device itself.

[0116] A Database Management System (DBMS) is software used to manipulate and manage databases. It is used to create, use, and maintain databases, including interfaces for calling the database. A DBMS provides unified management and control of the database to ensure its security and integrity.

[0117] An authentication system is used to determine whether a device is a trusted device of electronic device 100 by using authentication information from other devices. Authentication information can include account information, binding information, etc.

[0118] The account management system is used to record and manage user account information of the first electronic device 100. User accounts include, for example, Huawei accounts, payment accounts, instant messaging accounts, and the relationships between these accounts in different systems.

[0119] In this embodiment, the Super Collection application of the electronic device 100 calls the client of the task flow manager (the application of the task flow manager) to register a task listening service with the local task flow database. The task flow manager client calls the interface of the database management system (DBMS) to register the task listening service with the task flow manager. This task listening service is used to synchronize the changed task data (e.g., addition, deletion, modification) to the Super Collection application when the task flow manager detects changes in task data in the local task flow database.

[0120] The input manager is used to receive instructions or requests reported by lower layers such as the kernel layer and hardware abstraction layer.

[0121] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0122] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0123] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. An application's display interface can consist of one or more views. For example, the display interface including a text notification icon can include views for displaying text and views for displaying images. A view system can provide views for HyperTerminal applications, such as interfaces for building HyperTerminals and interfaces for discovering active trusted devices.

[0124] The display manager is used to transmit display content to the kernel layer.

[0125] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0126] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0127] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0128] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0129] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0130] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0131] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0132] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0133] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0134] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0135] A 2D graphics engine is a graphics engine for 2D drawing.

[0136] The Hardware Abstraction Layer (HAL) serves as the interface between operating system software and hardware components, providing a platform for interaction between upper-layer software and lower-layer hardware. The HAL abstracts the underlying hardware into software containing corresponding hardware interfaces. By accessing the HAL, settings can be configured for the underlying hardware devices; for example, enabling or disabling relevant hardware components can be done within the HAL. In some embodiments, the core architecture of the HAL layer is constructed using at least one of C++ or C++.

[0137] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, camera driver, audio driver, sensor driver, touch chip driver, and input system. For ease of explanation, Figure 3bIn this example, the kernel layer includes the input system, touch chip driver, display driver, and storage driver. The display driver and storage driver can be jointly configured within the driver module.

[0138] It is understood that the structure illustrated in this application does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0139] The following describes the implementation of a device identification method provided in this application on a display interface, using an application scenario as an example. As an example, the device identification method can be implemented, for instance, in a terminal application. It should be understood that this method can also be implemented in other application software of the electronic device, or in the system program of the electronic device; this application does not impose any limitations on this.

[0140] First, taking an electronic device 100 as a smartphone as an example, we will introduce an exemplary application interface displayed on the electronic device 100 by the HyperTerminal application.

[0141] like Figure 4a As shown, Figure 4a An exemplary user interface 410 for displaying a list of applications on an electronic device 100 is shown. The user interface 410 includes a status bar 402 located at the top of the user interface and multiple application icons 404.

[0142] The status bar 402 may include: one or more signal strength indicators for mobile communication signals (also known as cellular signals), one or more signal strength indicators for wireless fidelity (Wi-Fi) signals, a battery status indicator, and a time indicator.

[0143] The display interface 410 displays multiple application icons, including icons for applications such as cloud sharing, email, gallery, and settings. The user interface 410 also includes an area 406 for accessing the electronic device's control center interface, which can be located at the top of the display interface 410. In response to user actions on this area, such as a swipe down, the display interface 410 can switch to the control center interface 420. Figure 4b As shown. In Figure 4b The control center interface 420 shown displays the interface of the HyperTerminal application 413, which can be launched. Optionally, the HyperTerminal application 413 can be displayed as an application icon, a card, a window, a floating component, etc.

[0144] like Figure 4b As shown, Figure 4b An example application interface 420 of a HyperTerminal application is shown. This application interface 420 includes a quick control bar 411, a media application 412, and a HyperTerminal application 413. The quick control bar 411 includes icons for controlling commonly used configurations of electronic devices, such as Wi-Fi, Bluetooth, mobile data, mute, auto-rotate, and brightness control (auto-brightness checkbox). The media application 412 includes, for example, video applications, music applications, and related controls.

[0145] The display area of ​​the HyperTerminal application 413 displays one or more device information areas 414, each corresponding to a trusted device of the electronic device 100. For example, as shown in the figure, the HyperTerminal 413 lists four trusted devices, including a smart switch, a water dispenser, a smart camera, and a watch. As an example, the device information area 414 displays information such as the device name, device status, device location, and device control keys, allowing users to easily and intuitively understand the status of currently available devices and interact with them through the electronic device 100.

[0146] Due to the limited display area, the HyperTerminal application 413 may not display all trusted devices of the electronic device 100. In this case, the device operation area of ​​more trusted devices can be displayed in a scrolling manner by clicking the more device controls 415.

[0147] exist Figure 4b In the interface shown, the devices displayed in the HyperTerminal application 413 include currently active trusted devices. According to embodiments of this application, the electronic device 100 can detect active trusted devices in response to receiving a broadcast message (e.g., a heartbeat message) from a trusted device, and present the detected active trusted devices in the display area of ​​the HyperTerminal application 413 of the control center interface 410. Alternatively, if the display area of ​​the HyperTerminal application 413 is not completely filled by active devices, currently inactive trusted devices can also be displayed. Active and inactive trusted devices can be presented in different display formats; for example, active trusted devices can be displayed as color images, while inactive devices can be displayed as grayscale images.

[0148] The device information area 414 can display business data related to the device. According to embodiments of this disclosure, this business data is not necessarily transmitted via a connection between the electronic device 100 and the device, but is carried in broadcast messages emitted by the device. For example, a smart water dispenser may include information such as the current remaining water volume and temperature in the payload of its broadcast message (e.g., heartbeat information). This information changes frequently and is therefore difficult to track. In this way, without the need to establish an additional connection between devices, the electronic device 100 can obtain business data such as the status of active trusted devices.

[0149] exist Figure 4b In the interface shown, the HyperTerminal application 413 also includes an icon 416 for establishing a connection between the electronic device 100 and an active trusted device. In response to the user clicking icon 416, the electronic device 100 can switch to... Figures 6a to 6d The collaborative operation interface shown enables collaboration within the SuperTerminal. The following section will combine this with... Figures 6a to 6d , Figure 7 Detailed description.

[0150] exist Figure 4b In the interface shown, the HyperTerminal application 413 also includes an icon 417 for discovering trusted devices to build a HyperTerminal. In response to the user clicking icon 417, the electronic device 100 can switch to... Figure 4c The network interface 430 of the super terminal shown is used. It will be combined with... Figure 5 The process of setting up a HyperTerminal is described. It should be noted that, as an example, a device network is established by setting up a HyperTerminal. It should be understood that the HyperTerminal application is merely an exemplary application for implementing the embodiments of this application; therefore, device networks can also be established in other application software or system software. Furthermore, this description illustrates the process of triggering the establishment of a device network by the user manually operating the electronic device 100; however, the electronic device 100 can also spontaneously trigger the device network process.

[0151] Figure 5 Schematic diagrams illustrating interactions between devices and between a user and a device according to some embodiments of this application are shown. A first electronic device 100 presents as follows: Figure 4b The control center interface includes a super terminal application 413. User 10 wants to discover more trusted devices, such as a second electronic device 101, to form a super terminal with the first electronic device 100. Here, the second electronic device 101 can have similar functionality to the first electronic device 100, such as... Figure 3a and Figure 3b The functions and structure are shown. Optionally, the second electronic device 101 may have, for example... Figure 3a and Figure 3bThe electronic devices 100 shown have fewer functions and structures; for example, the first electronic device 101 is a rich device, while the second electronic device 102 is a lightweight device with relatively small computing and storage resources.

[0152] First, user 10 expects electronic device 100 to discover surrounding electronic devices and view their information in order to choose whether to add them to the hyperterminal. According to an embodiment of this application, user 10 can click icon 417 to generate a network request 502. Optionally, the user can also issue the network request 502 via voice command. In response to this operation, the first electronic device 100 displays... Figure 4c The interface 430 is described above. Interface 430 may include... Figure 4b Similar to the device information area 421 shown in the device information area 414, the device information area 421 presents information about trusted devices currently active by the first electronic device 100. Simultaneously, the first electronic device 100 can act as a master device (e.g., in Bluetooth communication mode) to scan for broadcast messages on a specific frequency.

[0153] In some embodiments, the user can manually switch the second electronic device 101 to a discoverable mode. In discoverable mode, the second electronic device 101 can broadcast a message 504 on a specific frequency band, enabling the second electronic device 101 to be discovered as a slave device. The address of the broadcast message can be completely randomized, and some device model information, etc., is carried in the payload portion of the broadcast message. This broadcast message cannot be monitored or tracked.

[0154] Then, the first electronic device 100 can display a list 422 of devices discovered by 506, including the second electronic device 101, on interface 430. It should be understood that the second electronic device 101 is only discovered by the first electronic device 100, but the first electronic device 100 is unaware whether it is a trusted device, and has not established a connection with the second electronic device 101, therefore it cannot exchange their respective identity keys. This describes the discovery of devices through scanning and displaying the discovered devices on the HyperTerminal application interface. It should be understood that devices can also be discovered and presented to the user through other methods, and this application does not limit this. For example, the process of scanning and discovering devices can also be enabled from the connection settings interface of the electronic device 100 (e.g., Bluetooth connection settings interface).

[0155] Next, the user selects a device of interest (e.g., the second electronic device 101) to join the super terminal. According to embodiments of this application, the second electronic device 101 needs to be authenticated, that is, a trusted relationship needs to be established between the first electronic device 100 and the second electronic device 101.

[0156] Therefore, as an example, user 10 can click the add icon 423 corresponding to the second electronic device 101 on interface 430, requesting 508 to add the second electronic device 101 to the trusted device network of the hyperterminal. Add icon 423 can trigger an authentication process for electronic device 101. In response, first electronic device 100 can send an authentication request 510 to second electronic device 101, for example, by broadcasting using a fully randomized address in broadcast message 504.

[0157] In some embodiments, a trusted relationship can be established using the device's account information. For this purpose, authentication request 510 may include the account information of the first electronic device 100. Correspondingly, the second electronic device 101 can send authentication information 512 to the first electronic device based on the account information of the first electronic device 100. For example, this information indicates that the first electronic device 100 and the second electronic device 101 have the same or associated accounts. Here, the same or associated accounts may include, for example, the accounts on the first electronic device 100 and the second electronic device 102 are the same Huawei account or other service provider account, or the accounts on the first electronic device 100 and the second electronic device 101 are different accounts but associated with the same identity, such as being associated with the same mobile phone number, communication software account, payment software account, etc. To protect the privacy of the second electronic device 101, the second electronic device 101 does not need to transmit or broadcast its account information to the first electronic device; instead, the first electronic device 100 transmits the account information to the second electronic device. In this case, the second electronic device 101 only needs to verify whether the account information of the two devices is the same or associated, and then transmits the verification result as authentication information 510 to the first electronic device.

[0158] Alternatively or additionally, the first electronic device 100 and the second electronic device 101 can establish a trusted relationship manually. This can be achieved, for example, by referring to... Figure 2a and Figure 2b The described method is used to bind the first electronic device 100 and the second electronic device 101. After the user 10 operates the first electronic device 100 and the second electronic device 101 to complete operations such as PIN code input, tap-to-pay, or scan, the second electronic device 101 can send authentication information 512, including binding information, back to the first electronic device 100. Thus, the first electronic device 100 determines whether it has been bound to the second electronic device 101, that is, whether the two have a trusted relationship. In some embodiments, the binding information can also indicate how the first electronic device 100 and the second electronic device 101 were bound, such as through a PIN code, QR code, or physical contact.

[0159] Through the above methods, the first electronic device 100 can determine that the second electronic device 101 is its trusted device. This description uses account signals and binding information to determine a trust relationship; however, it should be understood that other methods can also be used to determine whether the second electronic device 101 is a trusted device, and this application does not impose any limitations on this.

[0160] Next, the devices included in the super terminal can share their respective identity keys. According to embodiments of this application, the device's identity key is used to generate a randomized address for broadcast messages. Other devices can then identify the source device of the broadcast message based on this shared identity key. The identity key and its exchange process are described in more detail below.

[0161] According to embodiments of this application, the identity key is a password (e.g., a string of a certain length) generated by an electronic device and remains unchanged for a period of time. The identity key of the electronic device can be shared with a trusted device of the electronic device via a secure communication connection. Compared to a fixed address, the electronic device can use the identity key to generate a changing, randomized address as the source address for broadcast messages, thereby reducing the risk of information leakage.

[0162] For example, in the Bluetooth communication protocol, the address of a broadcast message consists of 6 bytes (48 bits). Electronic devices can generate randomized addresses using a varying random number and their own identity key, where the identity key can be an identity resolution key conforming to the Bluetooth communication protocol. The random number can be regenerated, for example, each time the device restarts or at any suitable time.

[0163] As an example, a randomized address can consist of two parts. One part is a random number portion, such as the high 24 bits (most significant bit, MSB), where the most significant two bits can be in a specified format (e.g., binary "10") to identify the type of address. A randomized address can also include a value obtained by processing the random number and an identity key (e.g., a hash operation), such as the low 24 bits. It should be understood that the format of a randomized address is not limited to this. After receiving a broadcast message, the peer device scans for this type of address and can verify the randomized address using the identity keys from its set of trusted devices. Specifically, the device performs the same hash operation using the high-order random number from the randomized address and the identity keys retrieved sequentially from the set of trusted devices, comparing the result with the low-order 24 bits. If they match, the peer device can identify the source device of the broadcast message. In this way, regardless of how the device changes its randomized address by altering its random number, only the peer device holding the identity key (i.e., the peer device and the device have a trusted relationship) can identify the device. If none of the identity keys in the set of trusted devices match the randomized address, the device cannot be identified.

[0164] The above describes an example implementation of generating a randomized address from an identity key. It should be understood that other methods, different from this one, can also be used to generate a randomized address from an identity key. For example, other methods can be used to obtain another portion of the randomized address for matching from a random number and an identity key, not limited to hash operations.

[0165] Continue to refer to Figure 5 This describes the process of exchanging identity keys. After the trusted relationship between the first electronic device 100 and the second electronic device 101 is determined, the first electronic device 100 establishes a secure connection 516 with the second electronic device 101. Then, the first electronic device 100 can send its identity key 517 to the second electronic device 101 via the secure connection and receive the identity key 518 from the second electronic device 101.

[0166] Accordingly, the first electronic device 100 stores the received identity key of the second electronic device 101 in its set of trusted devices 520. The second electronic device 101 also stores the received identity key of the first electronic device 100 in its set of trusted devices 522.

[0167] It should be noted that when the second electronic device 101 is a lightweight device and therefore has only limited storage space and computing power (e.g., smart socket, smart water dispenser, etc.), the first electronic device 100 may not send its identity key to the second electronic device 101, and the second electronic device 101 may not store the identity key of the first electronic device 100.

[0168] Optionally, after the first electronic device 100 and the second electronic device 101 exchange their identity keys, the identity keys can be forwarded and further shared in the device network of the super terminal.

[0169] For example, the first electronic device 100 can also propagate the identity key of a newly joined second electronic device 101 within the super terminal. In some embodiments, as described above, the first electronic device 100 has a set of trusted devices, and the first electronic device 100 can send the identity key of the second electronic device 101 to a trusted device in the set of trusted devices. For example, the second electronic device 100 can send the identity key of the second electronic device 101 to a rich device with greater processing power and storage space, such as... Figure 4c The connected watch 424 shown sends the identity key of the second electronic device 101.

[0170] It should be understood that since the first electronic device 100 and the watch 424 have a trusted relationship, when the first electronic device 100 and the second electronic device 101 have been determined to be devices with a trusted relationship, the watch 424 and the second electronic device 101 also have a trusted relationship. Similarly, the first electronic device 100 can also send the identity keys of trusted devices in its trusted device set to the second electronic device 101, so that the second electronic device 101 does not need to perform additional authentication and exchange identity keys with these devices. Therefore, by forwarding identity keys to other super terminals, that is, other trusted devices in the trusted device network, the operation of establishing a secure connection to exchange identity keys after pairing or verifying the trusted relationship between devices is eliminated, thus speeding up the construction process of the trusted device network.

[0171] This completes the process of adding the second electronic device 101 to the super terminal to form a trusted device network.

[0172] According to embodiments of this application, the second electronic device 101 can also exit the HyperTerminal. It can exit the network in the following manner.

[0173] For example, if user 10 of the first electronic device 100 has administrator privileges, they can operate on electronic device 100 to cause the second electronic device 101 to exit the HyperTerminal. Alternatively, user 10 can also operate the second electronic device 101, for example, to restore the second electronic device 101 to factory settings. Restoring factory settings means that the second electronic device 101 will generate a new identity key, which needs to be re-authenticated to join the HyperTerminal. Alternatively, when the second electronic device 101 logs out of its original user account (i.e., the same or associated account as the first electronic device), the second electronic device 101 can also generate a new identity key, which can be used to create a new HyperTerminal or to re-authenticate. Alternatively, the second electronic device 101 can also be manually unbound from its trusted devices.

[0174] In these cases, the second electronic device 101 can send a message to its trusted device, such as the first electronic device 100, indicating its withdrawal from the trusted relationship. Alternatively, the second electronic device 101 can send the message to a trusted module (e.g., an account center or authentication center) in the super terminal, which then forwards the message to devices in the super terminal. The first electronic device 100 can receive a message from the trusted module instructing the second electronic device 101 to withdraw from the super terminal. Thus, the first electronic device 100 can remove the identity key of the second electronic device 101 from its set of trusted devices.

[0175] It should be noted that when the second electronic device 101 goes offline, such as by turning it off, its identity key may not be deleted, so that the device can be quickly brought back online. When the electronic device 101 is online, it can periodically send heartbeat broadcast messages so that devices in the super terminal with a trusted relationship with it (e.g., those holding its identity key) can recognize that it is active.

[0176] In this way, the first electronic device 100 can exchange its identity keys with other devices that are certified as trusted devices to form a trusted device network. In the trusted device network, devices can identify each other through the address information of broadcast messages, without having to carry identification information in the broadcast messages, thus avoiding the monitoring and tracking of devices.

[0177] The above description of the HyperTerminal networking process, with reference to the exemplary user interface and interaction diagrams, is as follows. It should be understood that... Figures 4a to 4c The positions, names, and shapes of the various elements (e.g., buttons, icons, text, etc.) in the corresponding UI interfaces are not fixed and can be freely combined or designed according to requirements. The process of building a super terminal network can be achieved through... Figure 5 The interaction diagram shown can be implemented in different ways; for example, it can include more or fewer actions, and some actions can be implemented through interaction with... Figure 5 The different sequences shown can be executed, or they can be executed in parallel, to achieve the various functions of the HyperTerminal application described above.

[0178] The following text refers to Figures 6a to 6d , Figure 7 Describes the process by which the first electronic device 100 in a super terminal identifies an active trusted device. Figures 6a to 6d This is another set of application interface diagrams provided by the embodiments of this application. Figure 7 A schematic diagram illustrating the interaction between devices according to some embodiments of this application is shown.

[0179] As described above, in response to user 10 performing a swipe-down operation in the upper right corner area 406 of the first electronic device 100, the first electronic device 100 displays as shown below. Figure 6aThe control center interface 420 shown includes the HyperTerminal application 413. The HyperTerminal application 413 includes a device information area 414 for one or more trusted devices.

[0180] According to embodiments of this application, a first electronic device 100 may provide information related to an active trusted device to a user 10 in response to a query request 702 from a user 10. In some embodiments, a query request 702 is generated in response to a user operation that switches to a control center interface 420, causing the first electronic device 100 to query for an active trusted device, thereby presenting the current status of one or more trusted devices and their control elements in the device information area 414 of the HyperTerminal application 413.

[0181] Alternatively, when switching to the control center interface 420, the first electronic device 100 may not display the device information area 414, but instead list trusted devices in the hyperterminal application display area, for example, only displaying the device name and its corresponding icon to save display space. Then, when the user wants to query active trusted devices, the user performs a specific operation on the first electronic device 100 to generate a query request 702, for example, by clicking icon 416 to trigger the first electronic device 100 to query active trusted devices. Alternatively, the first electronic device 100 can periodically query active trusted devices in the background without user interaction.

[0182] As described above, devices in the Internet of Things, such as the second electronic device 101, can periodically send heartbeat broadcast messages 704 when they come online. The first electronic device 100 can receive the broadcast messages 704 from the second electronic device 101 based on a query request 702 or periodically by scanning.

[0183] In response to the received broadcast message 704 from the second electronic device 101, the first electronic device 100 determines whether the second electronic device 101 is a trusted device based on the identity key of the set of trusted devices it holds and the source address of the broadcast message 704.

[0184] In some embodiments, the first electronic device 100 can determine that the source address of the broadcast message 704 is a randomized address generated using the identity key of the second electronic device 101, based on the address type of the source address of the broadcast message 704, such as the highest two bits of a 48-bit address (e.g., binary "10"). Based on this, the first electronic device 100 can verify the source address using the identity keys of a set of trusted devices in a traversal manner. If the identity key of a trusted device enables the verification of the source address of the broadcast message, the first electronic device 100 can identify the second electronic device 101 as an active trusted device. In other words, the trusted device corresponding to the identity key is the second electronic device, thereby identifying the second electronic device 101 as an active trusted device.

[0185] The method of verifying the source address of a broadcast message can correspond to the method by which the second electronic device 101 generates the randomized source address. In some embodiments, the first electronic device 100 generates a hash value based on a first identity key from a set of trusted devices and a portion of the randomized address (e.g., a random number contained in the high 24 bits). The first electronic device 100 then compares this hash value with another portion of the randomized address (e.g., the low 24 bits). If the generated hash value matches the other portion of the randomized address, the broadcast message is verified. This indicates that the first identity key used to calculate the hash value is the identity key of the second electronic device 101.

[0186] If the first electronic device 100 cannot find the identity key of the second electronic device 101 after traversing all the identity keys in the set of trusted devices, it indicates that the second electronic device 101 is not a trusted device of the first electronic device. The first electronic device 100 can continue scanning, find the next broadcast message, and repeat the above process to obtain all the currently active trusted devices of the first electronic device 100.

[0187] In response to the second electronic device 101 being identified as a trusted device of the first electronic device 100, i.e., an active trusted device, the first electronic device 100 can provide information about the device. In some embodiments, the device information can be provided in a list or graphical manner. Thus, the first electronic device 100 discovers and identifies other active devices in the hyperterminal.

[0188] The specific way to provide device information may be: when user 10 enters interface 420 and the first electronic device 100 is triggered to query the trusted device, the information 414 of the trusted device can be presented in the super terminal application 413 of user interface 420.

[0189] Another specific way to provide device information is: when the first electronic device 101 responds to the user clicking icon 416 to enter, such as Figure 6b The collaborative operation interface 440 shown, and when the first electronic device 100 is triggered to query a trusted device, can display information related to the active trusted device in the user interface 440. Figure 6b The exemplary user interface 440 shown includes an icon 442 corresponding to the first electronic device 110 located at the center of the interface, and icons 444 of at least one active trusted device arranged around the icon 442. In some embodiments, information about the electronic device identified as an active trusted device is provided in this graphical or animated manner.

[0190] In addition, device information can also be transmitted to other electronic devices different from the first electronic device 100, such as devices that perform collaborative tasks with electronic device 100, such as smart TVs.

[0191] After the second electronic device 101 is identified and displayed to the user 10 by the first electronic device, the user 10 can operate the icon 444 of the second electronic device 710 to initiate task collaboration. For example... Figure 6c As shown, user 10 can select icon 444 corresponding to the smart water dispenser and drag it near icon 442 of the first electronic device 100 to establish task collaboration between the smart water dispenser and the first electronic device 100 in this intuitive way. For example, in response to user 10's operation 710 on interface 450, the first electronic device 100 can establish 712 a connection with the corresponding second electronic device 101. For example, if the second electronic device 101 is a smart water dispenser, after the connection is established, the first electronic device 100 can issue control commands to the smart water dispenser via the established connection, such as turning off the device or heating it. If the second electronic device 101 is a smart speaker, the first electronic device 100 can transmit audio data to the smart speaker via the established connection. The embodiments of this application do not limit the type of the second electronic device or the associated services.

[0192] In this way, when the first electronic device 100 and the second electronic device 101 have a trusted relationship, the first electronic device can identify the active second electronic device through the address information of the second device's broadcast system. Therefore, the second electronic device can be identified without broadcasting its identification information, reducing the risk of the second electronic device being monitored and tracked.

[0193] According to embodiments of this application, the first electronic device 100 can manage the super terminal, for example, by adding and deleting the identity keys of target devices in a set of trusted devices. The above, in conjunction with 4a to 4c, and Figure 5This document describes the addition of an identity key during the establishment of a device network. If a target electronic device in the trusted device set determines that it has terminated its trusted relationship with the first electronic device 100, the electronic device 100 can also remove the target electronic device's identity key from the trusted device set. The target electronic device can be a second electronic device 101 or other active trusted device. The following describes an exemplary operation of user 10 deleting an identity key in a HyperTerminal application. It should be understood that the operation of deleting an identity key can also be implemented in other applications or system software, and this application is not limiting.

[0194] In some embodiments, user 10 can also Figure 6b The task collaboration interface 440 shown operates to detach the trust relationship of one or more active electronic devices. For example... Figure 6d As shown, the lower part of interface 440 includes icon 446. User 10 drags icon 448 of the target electronic device whose trust relationship needs to be severed to overlap with icon 446, thus severing the trust relationship in this intuitive way. Accordingly, the first electronic device 100 removes the identity key of the target electronic device 448 from its set of trusted devices.

[0195] In some embodiments, the first electronic device 100 can determine the target electronic device to be deregistered by receiving a message from the target electronic device deregistering from the trusted relationship. For example, if the target electronic device is restored to factory settings, logs out of its original user account (i.e., the same or associated account as the first electronic device 100), or manually unbinds from any trusted device, the second electronic device 101 can send a message deregistering from the trusted relationship to its trusted device or trusted module (e.g., account center, authentication center) in the super terminal, and generate a new identity key, which can be used to build a new super terminal. Electronic devices that have deregistered from the super terminal need to be re-authenticated to rejoin the super terminal's trusted relationship network. Thus, the first electronic device 100 can receive a message instructing the target electronic device to deregister from the super terminal and delete the target electronic device's identity key from its set of trusted devices.

[0196] It should be understood that, Figures 6a to 6d The positions, names, and shapes of the various elements (e.g., buttons, icons, text, etc.) in the corresponding UI interface are not fixed and can be freely combined or designed according to requirements. Users can interact with... Figures 6a to 6d The interface shown illustrates different ways to interact with electronic devices. The process of identifying electronic devices can be achieved through [various methods / methods]. Figure 7 The interaction diagram shown can be implemented in different ways; for example, it can include more or fewer actions, and some actions can be implemented through interaction with... Figure 5The different sequences shown can be executed, or they can be executed in parallel, to achieve the various functions of the HyperTerminal application described above.

[0197] Based on the above application scenarios, a schematic flowchart of a communication method 800 according to an embodiment of this application is described below with reference to examples. The devices involved in the flowchart of method 800 include a first device and a second device, both of which have a HyperTerminal application installed. (Refer to...) Figures 4a to 7 As described above, the first device can be the first electronic device 100, and the second device can be the second electronic device 101. Furthermore, the first and second devices can also be any type of device among the electronic devices 200, 201, 202, 203, and 204 described above.

[0198] The first device can be an electronic device with Bluetooth communication capabilities, which discovers the second device by scanning broadcast messages emitted by nearby devices. The second device can also be an electronic device with Bluetooth communication capabilities, which can be triggered to emit broadcast messages in the hope of being discovered by other devices. When the first device discovers the presence of the second device, the first device can send an authentication request to the second device to receive authentication information from the second device and to authenticate the second device.

[0199] In box 810, the first device determines that the second device is a trusted device of the first device based on the authentication information received from the second device.

[0200] In some embodiments, the authentication request sent by the first device to the second device may include the account information of the first device. Accordingly, the first device receives authentication information from the second device based on the account information of the first device. This authentication information may indicate that the first device and the second device have the same or associated accounts, thus determining that the second device is a trusted device. That is, if the first device and the second device have the same or associated account information, then they are mutually trusted, thereby facilitating the convenient and rapid establishment of a trusted device network, forming a super terminal.

[0201] In some embodiments, the authentication request sent by the first device to the second device is a binding request. The binding method can be, for example, scanning a QR code, entering a PIN code, or physical contact. Accordingly, the authentication information returned by the second device to the first device may include binding information. The first device can determine whether the first device and the second device have been bound based on the binding information. If it is determined that the first device and the second device have been bound, the first device can consider the second device to be a trusted device of the first device. Therefore, when devices are bound, these devices are considered to be mutually trusted, thereby providing a flexible and widely applicable networking method for trusted device networks.

[0202] In block 820, the first device sends its own identity key to the second device, and in block 830, the first device can also receive the second device's identity key from the second device. That is, mutually trusted devices exchange their respective identity keys. According to embodiments of this application, the identity key is used to generate the source address of the device's broadcast message. Furthermore, in block 840, the first device adds the second device's identity key to the identity keys of the first device's set of trusted devices. Because the second device uses its identity key to generate the source address of its broadcast message, the first device can use the second device's identity key to verify the source address of the second device's broadcast message. Thus, the first device is able to identify the second device.

[0203] In this way, the first device can exchange its identity keys with other devices (second devices) that have been authenticated as trusted devices to form a trusted device network. In this network, devices can identify each other through address information in broadcast messages. The second device does not need to carry identification information in its broadcast messages to be recognized by the first device, thus avoiding surveillance and tracking.

[0204] In some embodiments, after receiving the identity key of the second device, the first device may also send the identity key of the second device to one or more trusted devices in its set of trusted devices. The first device may also send the identity keys of one or more trusted devices in its set of trusted devices to the second device. In this way, in the trusted device network of the super terminal, the identity keys of multiple mutually trusted devices can be quickly propagated and shared, accelerating network deployment and saving user operations.

[0205] In some embodiments, a connection is established between the first device and the second device in order to exchange their identity keys.

[0206] In some embodiments, the first device and the second device can sever their trusted relationship with each other. When it is determined that the second device is leaving its trusted relationship with the first device (e.g., by performing a factory reset, logging out of a user account, or manually unbinding), the first device deletes the second device's identity key from the trusted device set's identity key. If it is determined that the first device is leaving its trusted relationship with the trusted device set (e.g., by performing a factory reset, logging out of a user account, or manually unbinding), the first device's identity key is updated. In this way, the first device can easily manage and dynamically maintain its own trusted device set, or sever trusted relationships with other devices.

[0207] In some embodiments, the identity key may be an identity resolution key, and the broadcast message may be a Bluetooth broadcast message. In this way, the identity key can be applied to a randomized broadcast address conforming to the Bluetooth communication protocol.

[0208] Figure 9 A schematic flowchart of another communication method 900 according to an embodiment of this application is shown. The devices involved in the flowchart of method 900 include a first device and a second device, both of which have a HyperTerminal application installed. (Refer to...) Figures 4a to 7 As described above, the first device can be the first electronic device 100, and the second device can be the second electronic device 101. Furthermore, the first and second devices can also be any type of device among the electronic devices 200, 201, 202, 203, and 204 described above.

[0209] The first device responds to user query requests or periodically queries trusted devices active in its vicinity. To do this, the first device scans nearby devices to receive broadcast messages from them.

[0210] In box 910, in response to receiving a broadcast message from the second device, the first device determines the second device as an active trusted device based on the identity key of its trusted device set and the source address of the broadcast message. (See also: Trusted device networking of a super terminal, e.g., refer to...) Figure 8 The described method involves a first device having identity keys of one or more devices with which it has a trusted relationship, and the ability to use these identity keys to check whether a particular device (e.g., a second device) is a trusted device of the device.

[0211] According to an embodiment of this application, a device (e.g., a second device) broadcasts a message when it is active. The broadcast message does not carry a device identifier, and its address is generated via the device's identity key and is variable to ensure that the device is not monitored and tracked.

[0212] According to an embodiment of this application, when a broadcast message is received from another device, the first device can use the identity key of a trusted device in its set of trusted devices to verify the address of the broadcast message, thereby discovering an active trusted device. Specifically, the first device generates a hash value based on a first identity key and a first part of the source address, and compares the generated hash value with a second part of the source address. If the hash value and the second part match, the first device determines that the broadcast message has been verified. Verification of the broadcast message indicates that the first device holds the identity key of a second device. That is, the second device is a trusted device of the first device, and thus, the first device can identify the second device as an active trusted device. In this way, the first device can verify whether the source of the broadcast message is a trusted device based on the pre-stored identity keys of trusted devices.

[0213] In box 920, the first device provides information about the second device. In some embodiments, in response to a user's request to locate an active trusted device, for example, when the user interacts with a graphical element on the first device's interface, the first device provides the user with information about the second device. For example, the first device may present information about the second device, such as device status or business data, on a user interface, and may do so graphically.

[0214] In some embodiments, the user can further manipulate information on the second device. For example, the user may want the first and second devices to operate collaboratively and manipulate information on the second device (e.g., graphical elements corresponding to the second device). This establishes a connection between the first and second devices. In this way, the first device can be connected to a discovered, trusted device based on user actions to meet specific business needs, thereby saving device connection resources and providing a good user experience.

[0215] In some embodiments, the identity key of the trusted device set is stored at the first device. If it is determined that a target trusted device in the trusted device set has withdrawn from the trusted relationship with the first device, the first device deletes the target trusted device's identity key from the stored identity key of the trusted device set. In this way, the trusted relationships between the first device and other devices can be persistently maintained and dynamically updated, thereby enabling rapid detection of active trusted devices.

[0216] In some embodiments, the identity key can be an identity resolution key; the broadcast message can be a Bluetooth broadcast message. In this way, the identity key can be applied to a randomized broadcast address that conforms to the Bluetooth communication protocol.

[0217] In this way, when the first and second devices have a trusted relationship, the first device can identify the active second device through the address information of the second device's broadcast system. Therefore, the second device can be identified without broadcasting its identification information, reducing the risk of the second device being monitored and tracked.

[0218] Figure 10 A schematic block diagram of a communication device 1000 according to an embodiment of this application is shown. The device 1000 can be implemented, for example, at a first electronic device 100. The device 1000 includes an authentication unit 1010 and an identity key exchange unit 1020.

[0219] The authentication unit 1010 is configured to determine whether the second device is a trusted device of the first device based on authentication information received from the second device.

[0220] The identity key exchange unit 1020 is configured to send the identity key of the first device to the second device and receive the identity key of the second device from the second device if the second device is determined to be a trusted device of the first device, wherein the identity key of the second device is used to generate the source address of the broadcast message of the second device.

[0221] The identity key adding unit 1030 is configured to add the identity key of the second device to the identity key of the trusted device set of the first device.

[0222] More details and references regarding Device 1000 Figure 8 The method described is similar to 800, so it will not be repeated here.

[0223] Figure 11 A schematic block diagram of a communication device 1100 according to an embodiment of this application is shown. The device 1100 can be implemented, for example, at a first electronic device 100. The device 1100 includes an active trusted device determination unit 1110 and an information providing unit 1020.

[0224] The active trusted device determination unit 1110 is configured to determine the second device as an active trusted device in response to receiving a broadcast message from the second device, based on the identity key of the trusted device set of the first device and the source address of the broadcast message.

[0225] The information providing unit 1120 is configured to provide information about the second device if the second device is determined to be an active trusted device.

[0226] More details and references regarding device 1100 Figure 9 The method described is similar to 900, so it will not be repeated here.

[0227] The solutions of this application may be methods, apparatus, systems, and / or computer program products. Computer program products may include computer-readable storage media loaded with computer-readable program instructions for performing various aspects of this disclosure.

[0228] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0229] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0230] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0231] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0232] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0233] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0234] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0235] Various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for identifying trusted devices, characterized in that, include: Based on the fact that the first device and the second device have the same or related accounts, the first device determines that the second device is a trusted device; The first device receives the identity key of the second device from the second device and stores the identity key of the second device in the trusted device set of the first device; In response to receiving a broadcast message from the second device, the first device determines the second device as an active trusted device based on an identity key in the first device's set of trusted devices and the source address of the broadcast message, wherein the set of trusted devices includes pre-stored identity keys of at least one trusted device, and wherein the source address is a randomized address; and The first device provides information about the second device.

2. The method according to claim 1, characterized in that, The determination that the second device is an active trusted device includes: The broadcast message is verified using a first identity key from the identity keys of the trusted device set and the source address; and If the broadcast message passes verification, the first device determines the second device as an active trusted device.

3. The method according to claim 2, characterized in that, Verification of the broadcast message includes: A hash value is generated based on the first identity key and a first part of the source address; Compare the hash value with the second part of the source address; If the hash value matches the second part, the broadcast message is determined to have passed verification.

4. The method according to claim 1, characterized in that, The information provided for the second device includes: In response to receiving a lookup request from a user regarding a trusted device, the first device provides the user with information about the second device.

5. The method according to claim 1, characterized in that, Also includes: In response to receiving a user's operation on the second device, the first device establishes a connection with the second device.

6. The method according to claim 1, characterized in that, The identity key of the set of trusted devices is stored at the first device, and the method further includes: In response to determining that a target trusted device in the set of trusted devices has withdrawn from the trusted relationship with the first device, the first device deletes the identity key of the target trusted device from the stored identity key of the set of trusted devices.

7. The method according to any one of claims 1 to 6, characterized in that, The identity key mentioned therein is an identity resolution key.

8. The method according to any one of claims 1 to 6, characterized in that, The broadcast message mentioned above is a Bluetooth broadcast message.

9. A method for identifying trusted devices, characterized in that, include: The first device determines that the first device and the second device have the same or related accounts based on the authentication information received from the second device; Based on the fact that the first device and the second device have the same or related accounts, the first device determines that the second device is a trusted device of the first device; The first device sends its identity key to the second device. The first device receives the identity key of the second device from the second device, wherein the identity key of the second device is used to generate the randomized source address of the broadcast message of the second device, and The first device adds the identity key of the second device to the identity key of the first device's trusted device set.

10. The method according to claim 9, characterized in that, Among them, the trusted devices that identify the second device as the first device include: Send the account information of the first device to the second device; Receive authentication information for the account information of the first device from the second device; and If the information used for authentication indicates that the first device and the second device have the same or associated account, the second device is determined to be a trusted device.

11. The method according to claim 9, characterized in that, The following are identified as trusted devices of the second device as the first device: Obtain binding information from the information used for authentication; Based on the binding information, determine whether the first device and the second device have been bound; and If it is determined that the first device and the second device are bound together, the second device is determined to be a trusted device of the first device.

12. The method according to claim 11, characterized in that, The binding information indicates that the two devices are bound together by at least one of QR code, PIN code, and physical contact.

13. The method according to claim 9, characterized in that, The method further includes: The first device sends the identity key of the second device to a trusted device in the set of trusted devices; and The first device sends the identity key of one of the trusted devices in the set of trusted devices to the second device.

14. The method according to claim 9, characterized in that, Also includes: Establish a connection between the first device and the second device.

15. The method according to claim 9, characterized in that, Also includes: In response to determining that the second device has exited its trusted relationship with the first device, the first device removes the identity key of the second device from the identity keys of the first device's set of trusted devices.

16. The method according to claim 9, characterized in that, Also includes: If it is determined that the first device has withdrawn from the trusted relationship with the set of trusted devices, the identity key of the first device is updated.

17. The method according to any one of claims 9 to 16, characterized in that, The identity key mentioned therein is an identity resolution key.

18. The method according to any one of claims 9 to 16, characterized in that, The broadcast message mentioned above is a Bluetooth broadcast message.

19. An electronic device, characterized in that, include: Processing unit and memory; The processing unit executes instructions in the memory, causing the electronic device to perform the method according to any one of claims 1 to 8 or the method according to any one of claims 9 to 18.

20. A computer-readable storage medium, characterized in that, It stores one or more computer instructions, wherein one or more computer instructions are executed by a processor to cause the processor to perform the method according to any one of claims 1 to 8 or the method according to any one of claims 9 to 18.

Images