A method and device for managing auxiliary equipment, and auxiliary equipment

Abstract

An embodiment of the present application relates to a method for managing an accessory device, the method comprising: receiving a broadcast message sent by at least one accessory device; determining the device type of the accessory device that sends the broadcast message according to the broadcast message; determining a dedicated transceiver corresponding to the device type according to the device type of the accessory device; communicating with the accessory device through a dedicated transceiver so that a target application and the accessory device perform data interaction of target data, wherein the target application sends and / or receives target data through a device management service SDK. The present application configures a dedicated transceiver, determines the corresponding dedicated transceiver by identifying the device type of the accessory device, and uses the dedicated transceiver to communicate with the accessory device. Adaptation to any accessory device is achieved, and there is no need to deploy a dedicated APP for each type of accessory device. At the same time, communication between wearable devices and accessory devices can also be supported.

Description

Technical Field

[0001] The present application relates to the field of device management, and in particular to a method and apparatus for managing accessory devices by a terminal device and / or a wearable device, and the accessory devices. Background Art

[0002] The Internet of Things (IoT), or "Internet of Everything Connected", is a network that extends and expands on the basis of the Internet. The Internet of Things is a huge network formed by combining various information sensing devices with the Internet, thus realizing the interconnection of people, machines and things at any time and any place.

[0003] Among them, wearable devices (WD) belong to the broad category of IoT devices. Among them, wearable devices include sports bracelets, sports watches, smart watches, virtual reality (VR) glasses, augmented reality (AR) glasses, etc. With the increasing popularity of IoT devices in people's lives, these wearable devices generate a large amount of sports and health data every day. However, due to the limited storage capacity of wearable devices, most wearable devices do not have the ability to communicate directly with the cloud end (CE). For example, most wearable devices such as sports watches and bracelets lack wireless fidelity (WiFi) modules or modems, but almost all wearable devices have built-in Bluetooth (bluetooth) or low-power Bluetooth (bluetooth low energy, BLE), or dual-mode chips that support both Bluetooth and low-power Bluetooth, so that wearable devices with built-in Bluetooth and / or low-power Bluetooth can communicate with terminal devices that also have built-in Bluetooth and / or low-power Bluetooth. The Bluetooth may be a classic Bluetooth, such as Bluetooth basic rate / enhanced data rate (BR / EDR).

[0004] At the same time, in addition to wearable devices, terminal devices can also be connected to a wider range of IoT devices, namely accessory devices. Among them, the accessory devices of sports and health can be, for example, blood glucose devices with continuous glucose monitoring (GCM), body fat devices (body fat), ECG devices, fitness equipment, etc. For ECG equipment, for example, it can be an electrocardiogram (ECG) belt, ECG ring, etc.; and fitness equipment can include treadmills, rowing machines, elliptical machines, smart skipping ropes, etc. Of course, in addition to the accessory devices of sports and health, typical accessory devices can also include smart home accessory devices and car equipment with in-vehicle infotainment (IVI) systems. Among them, smart home accessory devices can be, for example, smart lights, smart air conditioners, smart TVs, etc. The terminal device can manage these wearable devices or accessory devices, such as obtaining and displaying certain states and data, configuring and controlling the paired and connected wearable devices or accessory devices, and providing channels for communication.

[0005] However, when managing the above-mentioned massive and different types of auxiliary devices, current terminal devices usually need to separately develop adaptive applications (applications, APPs), which makes the development cost high and has no universal applicability. Summary of the invention

[0006] The embodiment of the present application provides a method for managing accessory devices, which is applied to a terminal device or a wearable device. By configuring a corresponding dedicated transceiver in the terminal device or the wearable device, and selecting a corresponding dedicated transceiver for different accessory devices to receive and send data. This enables adaptation to any accessory device without deploying a dedicated APP for each type of accessory device. At the same time, communication between the wearable device and the accessory device can also be supported.

[0007] In the first aspect, a method for managing an accessory device is provided, and the method is applied to a terminal device or a wearable device, wherein the terminal device or the wearable device includes a target application, and the target application includes a device management service software development kit (SDK), and the method includes: receiving a broadcast message sent by at least one accessory device; determining the device type of the accessory device that sends the broadcast message according to the broadcast message; determining a dedicated transceiver corresponding to the device type according to the device type of the accessory device; communicating with the accessory device through the dedicated transceiver so that the target application and the accessory device perform data interaction of target data, wherein the target application sends and / or receives target data through the device management service SDK. The present application configures a dedicated transceiver, determines the corresponding dedicated transceiver by identifying the device type of the accessory device, and uses the dedicated transceiver to communicate with the accessory device. It realizes the adaptation of any accessory device, and there is no need to deploy a dedicated APP for each type of accessory device. At the same time, it can also support communication between wearable devices and accessory devices.

[0008] In one possible implementation, communicating with an accessory device through a dedicated transceiver includes: receiving target data sent by an accessory device through a dedicated transceiver; sending the target data to a convergence and forwarding module through a dedicated transceiver; determining a target application corresponding to the target data according to a pre-configured relationship between the target application and the target data; sending the target data to a device management service SDK through the convergence and forwarding module, so that the target application can read and use the target data through the device management service SDK. The present application configures a dedicated transceiver, and the dedicated transceiver is used to receive data from an accessory device. Any accessory device can be adapted through a dedicated transceiver, and communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0009] In one possible implementation, if the method is applied to a wearable device, before sending the target data to the device management service SDK through the aggregation and forwarding module, the method also includes: determining that the target application is the target application of the terminal device or the target application of the wearable device; if the target application is the target application of the terminal device, the target data is sent to the terminal device. If the present application is applied to a wearable device, it can also identify whether the target application is located on the terminal device or the wearable device, and if it is located on the terminal device, it is forwarded to the terminal device, thereby enabling the terminal device to communicate with the accessory device attached to the wearable device by relying on the wearable device.

[0010] In one possible implementation, communicating with an accessory device through a dedicated transceiver includes: sending target data generated by a target application to an aggregation and forwarding module through a device management service SDK; forwarding the target data to a dedicated transceiver through the aggregation and forwarding module; and sending the target data to an accessory device through a dedicated transceiver. The present application configures a dedicated transceiver, and uses the dedicated transceiver to receive data from an accessory device. Any accessory device can be adapted through a dedicated transceiver, and communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0011] In a possible implementation, the device types include: a standard device type and a first non-standard device type; the dedicated transceiver includes: a standard protocol transceiver; wherein the standard protocol transceiver is a dedicated transceiver corresponding to an accessory device of the standard device type and an accessory device of the first non-standard device type.

[0012] In one possible implementation, the accessory device of the first non-standard device type includes a product development kit (PDK); communicating with the accessory device through a dedicated transceiver includes: receiving target data sent by the accessory device of the first non-standard device type through a standard protocol transceiver; wherein the target data is target data determined by the accessory device of the first non-standard device type performing protocol format conversion through the PDK. The present application can achieve communication with the accessory device of the first non-standard device type through a dedicated transceiver, and by pre-installing the PDK in the accessory device of the first non-standard device type, it is ensured that the data during communication is in a standard protocol format, so that communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0013] In a possible implementation, the device type includes: a second non-standard device type; the dedicated transceiver includes: a non-standard protocol transceiver; wherein the non-standard protocol transceiver is a dedicated transceiver corresponding to an accessory device of the second non-standard device type.

[0014] In one possible implementation, communicating with an accessory device through a dedicated transceiver includes: performing protocol format conversion on data in a non-standard protocol format received from an accessory device of a second non-standard device type through a non-standard protocol transceiver to obtain target data; and performing protocol format conversion on target data sent to an accessory device of the second non-standard device type through a non-standard protocol transceiver to obtain data in a non-standard protocol format. The present application performs format conversion on target data through a dedicated transceiver, thereby enabling a device using a standard protocol format to communicate with an accessory device using a non-standard protocol format, so that communication can be achieved without deploying a dedicated APP for an accessory device using a non-standard protocol format.

[0015] In one possible implementation, the method further includes: verifying the target data sent and received to the non-standard protocol transceiver through the non-standard protocol transceiver interface, and converting the protocol format of the data in the non-standard protocol format in the target data into the standard protocol format. The present application verifies the target data through the non-standard protocol transceiver interface to ensure that the data sent to the target application are in the standard protocol format, so as to avoid the target application being unable to parse the target data due to different protocol formats.

[0016] In one possible implementation, if the method is applied to a terminal device, the device type includes: a wearable device type; the dedicated transceiver includes: a wearable protocol transceiver; wherein the wearable protocol transceiver is a dedicated transceiver corresponding to an accessory device of the wearable device type.

[0017] In one possible implementation, the target data includes: operation instructions and / or parameter data. The target data of the present application includes operation instructions and / or parameter data, so that when the terminal device or wearable device communicates with the accessory device, not only data transmission can be achieved, but also instructions can be transmitted to control the other end.

[0018] In a possible implementation, the target data is target data in a standard protocol format, and the standard protocol format is a generic attribute profile (GATT) format.

[0019] In the second aspect, a device for managing an accessory device is provided, the device is a terminal device or a wearable device, wherein the device includes a target application, the target application includes a device management service software development kit SDK, and the device includes: a universal transceiver for receiving a broadcast message sent by at least one accessory device; a processor for coupling with a memory, and reading and executing instructions stored in the memory; when the processor is running, the instructions are executed so that the processor is used to determine the device type of the accessory device that sends the broadcast message according to the broadcast message; the processor is also used to determine a dedicated transceiver corresponding to the device type according to the device type of the accessory device; the processor is also used to control the dedicated transceiver to communicate with the accessory device so that the target application and the accessory device perform data interaction of target data, wherein the target application sends and / or receives the target data through the device management service SDK. The present application configures a dedicated transceiver, determines the corresponding dedicated transceiver by identifying the device type of the accessory device, and uses the dedicated transceiver to communicate with the accessory device. It realizes the adaptation of any accessory device, and there is no need to deploy a dedicated APP for each type of accessory device. At the same time, it can also support communication between wearable devices and accessory devices.

[0020] In one possible implementation, the processor is also used to: control the dedicated transceiver to receive target data sent by the accessory device; control the dedicated transceiver to send the target data to the convergence and forwarding module; determine the target application corresponding to the target data according to the pre-configured relationship between the target application and the target data; control the convergence and forwarding module to send the target data to the device management service SDK, so that the target application can read and use the target data through the device management service SDK. The present application configures a dedicated transceiver, and the dedicated transceiver is used to receive data from the accessory device. Any accessory device is adapted by the dedicated transceiver, and communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0021] In one possible implementation, if the device is a wearable device, the processor is also used to: determine that the target application is the target application of the terminal device or the target application of the wearable device; if the target application is the target application of the terminal device, the target data is sent to the terminal device through the universal transceiver. If the present application is applied to a wearable device, it can also identify whether the target application is located on the terminal device or the wearable device, and if it is located on the terminal device, it is forwarded to the terminal device, thereby enabling the terminal device to communicate with the accessory device attached to the wearable device by relying on the wearable device.

[0022] In one possible implementation, the processor is also used to: send the target data generated by the target application to the aggregation and forwarding module through the device management service SDK; control the aggregation and forwarding module to forward the target data to the dedicated transceiver; control the dedicated transceiver to send the target data to the accessory device. The present application configures a dedicated transceiver, which is used to receive data from the accessory device. Any accessory device is adapted by the dedicated transceiver, and communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0023] In a possible implementation, the device types include: a standard device type and a first non-standard device type; the dedicated transceiver includes: a standard protocol transceiver; wherein the standard protocol transceiver is a dedicated transceiver corresponding to an accessory device of the standard device type and an accessory device of the first non-standard device type.

[0024] In one possible implementation, the processor is further used to: control the standard protocol transceiver to receive target data sent by the accessory device of the first non-standard device type; wherein the target data is target data determined by the accessory device of the first non-standard device type through protocol format conversion by the product development kit PDK. The present application can achieve communication with the accessory device of the first non-standard device type through a dedicated transceiver, and by pre-installing the PDK in the accessory device of the first non-standard device type, it is ensured that the data during communication is in a standard protocol format, so that communication can be achieved without deploying a dedicated APP for each type of accessory device.

[0025] In a possible implementation, the device type includes: a second non-standard device type; the dedicated transceiver includes: a non-standard protocol transceiver; wherein the non-standard protocol transceiver is a dedicated transceiver corresponding to an accessory device of the second non-standard device type.

[0026] In one possible implementation, the processor is further used to: control the non-standard protocol transceiver to perform protocol format conversion on data in a non-standard protocol format received from an accessory device of a second non-standard device type to obtain target data; and control the non-standard protocol transceiver to perform protocol format conversion on target data sent to an accessory device of the second non-standard device type to obtain data in a non-standard protocol format. The present application uses a dedicated transceiver to perform protocol format conversion on target data, thereby enabling communication between a device using a standard protocol format and an accessory device using a non-standard protocol format, so that communication can be achieved without deploying a dedicated APP for the accessory device using a non-standard protocol format.

[0027] In one possible implementation, the device further includes a non-standard protocol transceiver interface; the processor is further used to control the non-standard protocol transceiver interface to verify the target data sent and received to the non-standard protocol transceiver, and convert the protocol format of the data in the non-standard protocol format in the target data into the standard protocol format. The present application verifies the target data through the non-standard protocol transceiver interface to ensure that the data sent to the target application are in the standard protocol format, so as to avoid the target application being unable to parse the target data due to different protocol formats.

[0028] In a possible implementation, if the device is a terminal device, the device type includes: a wearable device type; the dedicated transceiver includes: a wearable protocol transceiver; wherein the wearable protocol transceiver is a dedicated transceiver corresponding to an accessory device of the wearable device type.

[0029] In one possible implementation, the target data includes: operation instructions and / or parameter data. The target data of the present application includes operation instructions and / or parameter data, so that when the terminal device or wearable device communicates with the accessory device, not only data transmission can be achieved, but also instructions can be transmitted to control the other end.

[0030] In a possible implementation, the target data is target data in a standard protocol format, and the standard protocol format is a Generic Attribute Profile GATT format.

[0031] In a third aspect, an accessory device is provided, the accessory device is pre-installed with a product development kit PDK, and the accessory device includes: a sensor for generating parameter data; a processor for coupling with a memory, and reading and executing instructions stored in the memory; when the processor is running, the instructions are executed, so that the processor is used to control the PDK to convert the parameter data and / or operation instructions into a protocol format to obtain target data; a transmitter is used to send the target data. This application pre-installs the PDK on the accessory device, so that the target data sent by the accessory device is in a standard protocol format, thereby eliminating the need for the peer to deploy a dedicated APP for the accessory device.

[0032] In a possible implementation, the accessory device further includes: a receiver for receiving target data sent by the terminal device or the wearable device; and the processor is further used to control the PDK to convert the target data into a protocol format to obtain parameter data and / or operation instructions.

[0033] In a fourth aspect, a computer-readable storage medium is provided, in which instructions are stored. When the instructions are executed on a terminal, the terminal executes any method of the first aspect.

[0034] In a fifth aspect, a computer device comprising instructions is provided, which, when executed on a terminal, enables the terminal to execute any one of the methods in the first aspect.

[0035] The present application discloses a method and apparatus for managing accessory devices, and accessory devices, which can identify the device type of the accessory device, determine the corresponding dedicated transceiver, and then use the dedicated transceiver to communicate with the accessory device. Thus, any accessory device can be adapted, and there is no need to deploy a dedicated APP for each type of accessory device. At the same time, since the method can be applied to wearable devices, it can also support communication between wearable devices and accessory devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 A schematic diagram of an application scenario provided for an embodiment of the present application;

[0037] Figure 2 A schematic diagram of a device architecture for managing auxiliary equipment provided in an embodiment of the present application;

[0038] Figure 3 A schematic diagram of a terminal device architecture provided in an embodiment of the present application;

[0039] Figure 4 A flow chart of a method for managing ancillary equipment provided in an embodiment of the present application;

[0040] Figure 5 A flowchart of another method for managing an auxiliary device provided in an embodiment of the present application;

[0041] Figure 6 A schematic diagram of a wearable device architecture provided in an embodiment of the present application;

[0042] Figure 7 A schematic diagram of another terminal device architecture provided in an embodiment of the present application;

[0043] Figure 8 A schematic diagram of another wearable device architecture provided in an embodiment of the present application;

[0044] Fig. 9 A flowchart of another method for managing an auxiliary device provided in an embodiment of the present application;

[0045] Fig.10 A flowchart of another method for managing an auxiliary device provided in an embodiment of the present application;

[0046] Fig.11 A flowchart of another method for managing an auxiliary device provided in an embodiment of the present application;

[0047] Fig.12 A schematic diagram of a device for managing auxiliary equipment provided in an embodiment of the present application;

[0048] Fig.13 A schematic diagram of an auxiliary device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0050] This application is mainly used in scenarios where a terminal device or a wearable device controls an auxiliary device. Figure 1As shown, the terminal device 100 is connected to and communicates with the wearable device 200 in a wireless manner. At the same time, the terminal device 100 can also be connected to and communicate with the accessory device 300 in a wireless manner. For the wearable device 200, it can also be connected to and communicate with the accessory device 300 in a wireless manner. Among them, the wireless method can be, for example, BR / EDR, BLE, WiFi and / or Zigbee, etc., which is not limited in this application. The terminal device 100 may include, for example, a mobile phone 101, a personal computer (PC) 102, a television (TV) 103, etc. The wearable device 200 may include, for example, a smart watch 201, a smart bracelet 202, and smart eyes 203. The accessory device 300 may include, for example, a smart light bulb 301, a smart blood pressure meter 302, a smart blood glucose meter 303, a smart treadmill 304, etc. It can be understood that the terminal device 100, the wearable device 200 and the accessory device 300 of the present application are not limited to the examples given above. Taking the terminal device as a mobile phone 101 as an example, the mobile phone 101 is connected to and communicates with the wearable device 200 and the accessory device 300 in a wireless manner.

[0051] At present, the mobile phone 101 on the market only provides an APP that can manage the wearable device 200 and the accessory device 300 independently developed by the mobile phone manufacturer. Such an APP can only directly connect and communicate with the wearable device 200 and the accessory device 300 independently developed. However, for other accessory devices that are not independently developed, it is impossible to connect and communicate through the APP. The current common practice is that the provider of the accessory device develops a dedicated APP separately, that is, a companion application (C-APP), and installs it in the terminal device, so that the terminal device can connect and communicate with other accessory devices that are not independently developed through the dedicated APP. When it is necessary to summarize the information, the dedicated APP needs to communicate with the APP provided by the mobile phone manufacturer first, and transfer the data to the APP provided by the mobile phone manufacturer in order to summarize the data of the accessory devices of multiple different providers. But obviously, since the accessory device provider needs to develop a dedicated APP for the accessory device, the development cost is too high. At the same time, for the terminal device, it is necessary to install a proprietary APP for each accessory device, so a large amount of storage space will be occupied on the terminal device. For the user, it is necessary to switch between multiple different proprietary APPs, which seriously affects the user experience.

[0052] Therefore, the present application provides a method for managing accessory devices, configuring a dedicated transceiver on a terminal device, and then determining the dedicated transceiver corresponding to the accessory device by identifying the device type of the accessory device. The dedicated transceiver is used to communicate with the accessory device. In this way, the terminal device can be adapted to any accessory device without deploying dedicated apps for different types of accessory devices.

[0053] The technical solutions in the embodiments of the present application will be described in detail below in conjunction with the drawings in the embodiments of the present application.

[0054] Figure 2 A schematic diagram of an apparatus architecture for managing auxiliary equipment provided in an embodiment of the present application.

[0055] The present application provides a device 20 for managing an accessory device. It is understood that the device 20 may be a terminal device 100 or a wearable device 200. The device 20 may include: a processor 210, a memory 220, an input device 230, an output device 240, a sensor 250, a communication module 260, a display 270, a camera module 280, and a vibration motor 290. Of course, it is understood that the device 20 may also include any other peripheral devices that may be required, and the present application does not limit this.

[0056] Among them, the processor 210 can be a processor of an architecture such as an advanced reduced instructionset computing machine (ARM), X86, or a microprocessor without interlocked piped stages (MIPS). The memory 220 can include a memory 221, in which an operating system 2211, a desktop program 2212, a synthesizer 2213, and a device management service 2214 can be stored. The memory 220 can also include an auxiliary memory or an external memory, such as a non-removable memory or a removable memory card, etc. The input device 230 can include, for example, a keyboard, a mouse, a button, a touch screen, etc. The output device 240 can be an audio source playback device, a printer, etc. The sensor 250 can include a gravity sensor, an acceleration sensor, an angular velocity sensor, a photoplethysmograph (PPG) sensor, a global positioning system (GPS) sensor, a fingerprint sensor, etc. The communication module 260 can include an antenna, a Bluetooth module, a WiFi module, a modem, etc. The display 270 may be, for example, a liquid crystal display (LCD) screen, an organic light-emitting diode (OLED) screen, an active-matrix organic light-emitting diode (AMOLED) screen, etc. The camera module 280 may include a front camera, a rear camera, a time of flight (ToF) camera, an infrared camera, etc. The vibration motor 290 may be, for example, a linear motor or an eccentric motor, etc. Of course, the specific forms of expression of each component in the above-mentioned device 20 may be arbitrarily replaced according to actual conditions, and this application does not limit this.

[0057] The device 20 runs various modules stored in the memory 221 through the processor 210 to implement corresponding functions. At the same time, various peripherals can also be mobilized to send and / or receive data, display corresponding information, etc. It can be understood that the device 20 can be a variety of different devices such as a mobile phone, a PC, a tablet, a smart TV, a wearable device, etc.

[0058] Since a unified device management service (UDMS) 2214 is newly added in the memory, it is possible to connect and communicate with various different accessory devices through the unified device management service 2214. Thus, the terminal device can adapt to any accessory device without deploying dedicated APPs for different types of accessory devices.

[0059] The present solution will be described in more detail below using the software architecture of device 20 .

[0060] Figure 3 A schematic diagram of a terminal device architecture provided in an embodiment of the present application.

[0061] like Figure 3 The architecture of a terminal device 100 is shown, and the architecture includes an application layer, a framework layer, a device management service and a kernel layer. Among them, the application layer includes one or more APPs that may need to communicate with the wearable device 200 and the accessory device 300. The first device management service SDK provided by the present application is pre-installed in the APP. It can be understood that the first device management service SDK is a device management service SDK installed on the terminal device. The APP calls the first device management service application programming interface (application programming interface, API) in the framework layer through the first device management service SDK to call the device management service. It can be understood that the first device management service API is a device management service API provided by the framework layer on the terminal device. At the same time, the present application also provides a device management service, which may include a convergence and forwarding module and a dedicated transceiver. Among them, the dedicated transceiver may include a wearable device protocol transceiver, a standard protocol transceiver and a non-standard protocol transceiver. It is understandable that the wearable device protocol transceiver, the standard protocol transceiver and the non-standard protocol transceiver are used to encode and decode the messages received and sent, and the wearable device protocol transceiver, the standard protocol transceiver and the non-standard protocol transceiver also communicate with the hardware transceiver device driver located at the kernel layer, so that the hardware transceiver device driver drives the real physical transceiver. Among them, the real physical transceiver can be, for example, a BR / EDR transceiver, a BLE transceiver, a WiFi transceiver and / or a ZigBee transceiver, so as to receive the target data sent from the wearable device or the accessory device through a physical link. Among them, the physical link can be any form of air interface resource. Among them, the non-standard protocol transceiver can exist in the form of a plug-in. It is understandable that due to the use of plug-in technology, it is also necessary to define the installation and uninstallation operations of the plug-in.

[0062] pass Figure 3It can be clearly seen that the wearable device protocol transceiver is used to communicate with the wearable device 200, and its communication path is shown as ① and ④. It can be understood that the wearable device protocol transceiver and the wearable device 200 complete the communication through paths ① and ④. The wearable device 200 sends data to the terminal device 100, and the terminal device 100 receives the data through the hardware transceiver device driver, that is, path ①. After that, the hardware transceiver device driver sends the received data to the wearable protocol transceiver, that is, path ④, thereby completing a communication from the wearable device 200 to the wearable protocol transceiver. Of course, the terminal device 100 sends data to the wearable device 200, which can be the wearable protocol transceiver sending data to the hardware transceiver device driver, that is, path ④. After that, the hardware transceiver device driver sends the data to the wearable device 200 after receiving the data, that is, path ①, thereby completing a communication from the wearable protocol transceiver to the wearable device 200. The standard protocol transceiver is used to communicate with the standard protocol type accessory device 400, and its communication path is shown as ② and ⑤. It can be understood that the standard protocol transceiver and the standard protocol type accessory device 400 communicate with each other through paths ② and ⑤. The standard protocol type accessory device 400 sends data to the terminal device 100, and the terminal device 100 receives the data through the hardware transceiver device driver, that is, path ②. After that, the hardware transceiver device driver sends the received data to the standard protocol transceiver, that is, path ⑤, thereby completing a communication from the standard protocol type accessory device 400 to the standard protocol transceiver. Of course, the terminal device 100 sends data to the standard protocol type accessory device 400, which can be the standard protocol transceiver sending data to the hardware transceiver device driver, that is, path ⑤. After that, the hardware transceiver device driver sends the data to the standard protocol type accessory device 400 after receiving the data, that is, path ②, thereby completing a communication from the standard protocol transceiver to the standard protocol type accessory device 400. The non-standard protocol transceiver is used to communicate with the non-standard protocol type accessory device 500, and its communication path is shown as ③ and ⑥. It can be understood that the non-standard protocol transceiver and the non-standard protocol type accessory device 500 communicate with each other through paths ③ and ⑥. The non-standard protocol type accessory device 500 sends data to the terminal device 100, and the terminal device 100 receives the data through the hardware transceiver device driver, that is, path ③. After that, the hardware transceiver device driver sends the received data to the non-standard protocol transceiver, that is, path ⑥, thereby completing a communication from the non-standard protocol type accessory device 500 to the non-standard protocol transceiver.Of course, the terminal device 100 sends data to the non-standard protocol type accessory device 500, which can be the non-standard protocol transceiver sending data to the hardware transceiver device driver, that is, path ⑥, and then the hardware transceiver device driver receives the data and sends the data to the non-standard protocol type accessory device 500, that is, path ③, thereby completing a communication from the non-standard protocol transceiver to the non-standard protocol type accessory device 500. Among them, the standard protocol type accessory device 400 and the non-standard protocol type accessory device 500 can be. Figure 1 The accessory device 300 is shown. That is, the accessory device 300 may include an accessory device 400 of a standard protocol type, and may also include an accessory device 500 of a non-standard protocol type.

[0063] In one example, the standard protocol type may be a GATT type. The GATT type belongs to the category of standard Bluetooth protocols. Of course, it is understandable that other wireless connections such as a certain protocol of WiFi or ZigBee may also be used as the standard protocol type, and this application does not limit this. In one example, the GATT type may be a blood pressure meter protocol (bloodpressure), a body composition protocol (body composition), a blood sugar protocol (glucose), a heart rate protocol (heart rate) and other protocols. This application will take Bluetooth as an example of a wireless connection method, and of course other equivalent wireless connection methods may also be used as a replacement, and this application does not limit this.

[0064] The following will be combined Figure 4 illustrate Figure 3 The terminal device 100 communicates with the wearable device 200, the accessory device 400 of the standard protocol type and / or the accessory device 500 of the non-standard protocol type. Figure 4 A flowchart of a method for managing an auxiliary device provided in an embodiment of the present application. The method can be applied in Figure 3 The terminal device 100 shown in the figure may include the following steps:

[0065] S401, scanning surrounding devices.

[0066] The terminal device needs to turn on Bluetooth and scan surrounding devices.

[0067] In one example, if the APP of the application layer needs to communicate with the surrounding wearable device 200 or accessory device 300, the terminal device 100 can continuously scan the surrounding devices through the universal transceiver to find the surrounding wearable device 200 or accessory device 300. It is understandable that the universal transceiver can drive the physical Bluetooth antenna to receive the broadcast message sent by the wearable device 200 or accessory device 300.

[0068] In some examples, for the wearable device 200 or the accessory device 300, before matching and connecting with the terminal device 100, it is necessary to send a broadcast message by broadcasting.

[0069] S402: Obtain a broadcast message and determine the device type carried in the broadcast message.

[0070] The terminal device 100 obtains broadcast messages sent by surrounding devices through a universal transceiver. In one example, after receiving a broadcast message sent by the wearable device 200 or the accessory device 300, the terminal device 100 parses the carried device information from the obtained broadcast message. The device information may include, for example, the device type. In one example, the device type may be expressed in the form of a device type identity (ID) identifier.

[0071] S403: Determine a corresponding dedicated transceiver according to the device type.

[0072] The terminal device 100 can determine the dedicated transceiver corresponding to the parsed device type according to the preset correspondence between the device type and the dedicated transceiver, and use the corresponding dedicated transceiver to communicate with the surrounding wearable device 200 or accessory device 300.

[0073] In one example, the device type may include a wearable device type, a standard protocol type, and a non-standard protocol type. It is understood that when the device sending the broadcast message is a wearable device 200, the device type carried in the broadcast message may be a wearable device type; when the device sending the broadcast message is an accessory device 400 of a standard protocol type, the device type carried in the broadcast message may be a standard protocol type; when the device sending the broadcast message is an accessory device 500 of a non-standard protocol type, the device type carried in the broadcast message may be a non-standard protocol type. Afterwards, the terminal device 100 determines the dedicated transceiver corresponding to the device type according to the pre-set correspondence between the device type and the dedicated transceiver. For example, when the device type is a wearable device type, a wearable protocol transceiver is selected as the corresponding dedicated transceiver; and when the device type is a standard protocol type, a standard protocol transceiver is selected as the corresponding dedicated transceiver; and when the device type is a non-standard protocol type, a non-standard protocol transceiver is selected as the corresponding dedicated transceiver.

[0074] It is understandable that S401 - S403 completes the pairing process of the surrounding wearable device 200 or accessory device 300 with the terminal device 100 .

[0075] In some examples, after the terminal device successfully matches with a certain wearable device 200 or accessory device 300, it can continue to execute S401 and continue scanning to match a new wearable device 200 or accessory device 300. Therefore, the matching process of the terminal device to the surroundings can be regarded as a loop. In one example, the specific form of the above loop can be an independent thread or an independent process.

[0076] After S403, S404 may be continued to be executed for the successfully matched wearable device 200 or accessory device 300. Of course, it is understandable that S401 and S404 executed after S403 may be executed synchronously without affecting each other.

[0077] S404, receiving target data through the dedicated transceiver, and packaging the target data.

[0078] The terminal device receives the target data using a dedicated transceiver corresponding to the wearable device 200 or the accessory device 300 matched with the surrounding. For example, after the actual physical transceiver detects the air interface data, i.e., the target data, it sends the corresponding target data to the corresponding dedicated transceiver so that the corresponding dedicated transceiver can receive it.

[0079] In one example, if the paired surrounding device is the wearable device 200, the wearable protocol transceiver is selected to receive the data sent by the wearable device 200, that is, Figure 3 The communication path shown in ①. Then, the wearable protocol transceiver decodes and packages the received target data. It can be understood that during the wireless transmission process, the size of the transmitted data packet is usually fixed. When the data to be transmitted is large, it needs to be transmitted through multiple data packets before the complete data can be passed to another device. Therefore, the wearable protocol transceiver of the terminal device 100 needs to parse and package the received target data.

[0080] Of course, in another example, if the paired peripheral device is an accessory device 400 of the standard protocol type, the standard protocol transceiver is selected to receive data sent by the accessory device 400 of the standard protocol type, that is, Figure 3 Then, the standard protocol transceiver decodes and packages the received target data. In another example, if the paired device is an accessory device 500 of a non-standard protocol type, the non-standard protocol transceiver is selected to receive the data sent by the accessory device 500 of the non-standard protocol type, that is, Figure 3The communication path shown in ③. Then, the non-standard protocol transceiver decodes and packages the received target data. It is understandable that when data is wirelessly transmitted across devices, the transmitted data may be encrypted, so the decoding process is the process of decrypting the encrypted data. Of course, if the transmitted data is not encrypted, the decoding process can be skipped and the package can be directly packaged, which is not limited in this application.

[0081] In one example, for the target data that has been packaged, S404 is continuously executed to receive new target data and perform decoding and packaging, until the target data is packaged, and then S405 is executed.

[0082] Of course, during the execution of S404, if the target data is not received in a certain time period, the dedicated transceiver continues to wait for the target data reported by the hardware.

[0083] S405, sending the packaged target data to the aggregation and forwarding module.

[0084] After the terminal device 100 receives the target data through the corresponding dedicated transceiver and completes the packaging, the packaged target data can be sent to the convergence and forwarding module. In one example, the dedicated transceiver can send the packaged target data to the convergence and forwarding module through the corresponding transceiver interface. For example, the wearable protocol transceiver can send the packaged target data to the convergence and forwarding module through the wearable protocol transceiver interface; the standard protocol transceiver can send the packaged target data to the convergence and forwarding module through the standard protocol transceiver interface; the non-standard protocol transceiver can send the packaged target data to the convergence and forwarding module through the non-standard protocol transceiver interface. It can be understood that the convergence and forwarding module needs to communicate with different dedicated transceivers through the above-mentioned interface.

[0085] In one example, the wearable device 200 mentioned in this application can be a wearable device independently developed by a mobile phone manufacturer. The device provider and service provider of such wearable devices are the same provider, so they can use the internally defined communication protocol for communication. Therefore, for the wearable protocol transceiver, it is only necessary to decode and package the received target data, and then the wearable protocol transceiver interface forwards the packaged target data to the aggregation and forwarding module, and the wearable protocol transceiver does not need to convert the target data into a protocol format.

[0086] In another example, for the standard protocol type accessory device 400, since the transmitted target data adopts a pre-set standard protocol format, the standard protocol transceiver does not need to convert the protocol format of the received target data, but directly parses and packages it, and forwards the packaged target data to the aggregation and forwarding module through the standard protocol transceiver interface.

[0087] In another example, for the accessory device 500 of non-standard protocol type, since the format type adopted by the target data of the transmission is not the standard protocol format pre-set in the present application. Therefore, the non-standard protocol transceiver needs to decode the received data first, and then convert the data of the non-standard protocol format into the target data of the standard protocol format, and then package the converted target data of the standard protocol format. Then, the packaged target data is forwarded to the convergence and forwarding module via the non-standard protocol transceiver interface. In some examples, due to some uncontrollable factors, the non-standard protocol transceiver may not convert all the data of the non-standard protocol format into the target data of the standard protocol format. Therefore, when forwarding via the non-standard protocol transceiver interface, the forwarded data can be verified again, the data whose protocol format is still the non-standard protocol format is screened out, and the data of the non-standard protocol format screened out above is converted into the protocol format to obtain the corresponding target data of the standard protocol format. It can be understood that the non-standard protocol transceiver interface is not only used as the forwarding target data, but also needs to verify the forwarded data, and timely convert the data that has not been converted into the protocol format into the protocol format, so as to avoid that the subsequent data that has not been converted into the protocol format cannot be correctly read.

[0088] In some examples, since there may be multiple data packets of target data, after a data packet of target data is packaged, S404 can be continued to receive new target data, thereby forming a data transceiver cycle. It is understandable that the specific form of the data transceiver cycle can be an independent thread or an independent process.

[0089] S406, sending the target data to the registered APP through the aggregation and forwarding module.

[0090] After the aggregation and forwarding module receives the target data, it can determine to forward the target data to the corresponding target application according to a preset relationship between the target application and the target data.

[0091] In one example, before S406, the APP can inform the terminal device 100 what kind of target data the APP wants to obtain by registering. Therefore, the terminal device 100 can establish a corresponding relationship between the registered APP and the target data that it wants to obtain. The corresponding relationship can be stored in the terminal device 100 in the form of a table. Of course, in some examples, the above-mentioned corresponding relationship can also be stored in any equivalent form, and this application is not limited here. At this time, the registered APP is the target application corresponding to the target data.

[0092] In one example, the target application is pre-installed with a first device management service SDK, and the target application communicates with the first device management service API located in the framework layer through the built-in first device management service SDK, so as to call the device management service through the first device management service API, that is, the target data sent by the aggregation and forwarding module is received through the first device management service API.

[0093] In some other examples, the pre-set relationship between the target application and the target data may also include the data form that the target application expects to receive, such as basic type, combination type, sequence type, etc., so that the aggregation and forwarding module can select appropriate data to send to the target application. It is understandable that one or more instances may be running in the target application, and the aggregation and forwarding module may directly send the target data to the corresponding instance in the target application through the first device management service API and then through the first device management service SDK.

[0094] Of course, in some examples, the target application may not exist in the terminal device 100. In this case, the aggregation and forwarding module may directly discard the target data.

[0095] At this point, the entire process of reporting the target data from the wearable device 200 or the accessory device 300 to the target application is completed through S404 to S406.

[0096] Figure 5 A flowchart of another method for managing ancillary devices provided in an embodiment of the present application.

[0097] Figure 5 Another method of managing attached devices is shown. Figure 3 The method describes the process of sending target data from the target application to the corresponding wearable device 200 or the auxiliary device 300. After S403, the method may further include the following steps:

[0098] S501, the target application sends target data to the aggregation and forwarding module.

[0099] The target application in the terminal device 100 can send the target data to the aggregation and forwarding module.

[0100] In one example, when the target application, i.e., the registered APP, has target data that needs to be sent to surrounding devices that have successfully matched the terminal device 100, the target application can send the target data to the aggregation and forwarding module. For example, the target application sends the target data to the aggregation and forwarding module through the pre-installed first device management service SDK. In one example, when the first device management service SDK sends the target data to the aggregation and forwarding module, the target data can be sent to the aggregation and forwarding module of the device management service through the first device management service API in the framework layer.

[0101] S502, the aggregation and forwarding module sends the target data to the corresponding dedicated transceiver.

[0102] When the aggregation and forwarding module receives the target data from the target application, it sends the target data to the dedicated transceiver according to the dedicated transceiver determined in S403.

[0103] In one example, if the dedicated transceiver determined in S403 is a wearable protocol transceiver, the convergence and forwarding module sends the target data to the wearable protocol transceiver through the wearable protocol transceiver interface. Of course, in another example, if the dedicated transceiver determined in S403 is a standard protocol transceiver, the convergence and forwarding module sends the target data to the standard protocol transceiver through the standard protocol transceiver interface. In another example, if the dedicated transceiver determined in S403 is a non-standard protocol transceiver, the convergence and forwarding module sends the target data to the non-standard protocol transceiver through the non-standard protocol transceiver interface.

[0104] S503, sending the target data to the corresponding peripheral device through the corresponding dedicated transceiver.

[0105] After receiving the target data, the dedicated transceiver in the terminal device sends the target data to the corresponding surrounding devices.

[0106] In one example, if the dedicated transceiver is a wearable protocol transceiver, the corresponding peripheral device may be the wearable device 200, and the communication path for sending the target data may be as follows: Figure 3 If the dedicated transceiver is a standard protocol transceiver, the corresponding peripheral device may be an accessory device 400 of the standard protocol type, and the communication path for sending the target data may be as follows: Figure 3 If the dedicated transceiver is a non-standard protocol transceiver, the corresponding peripheral device may be an accessory device 500 of a non-standard protocol type, and the communication path for sending the target data may be as follows: Figure 3As shown in ③.

[0107] It is understandable that, for the wearable device 200 mentioned in the present application, since the communication is performed using an internally defined communication protocol, the wearable protocol transceiver can directly send the target data to the wearable device 200 without converting the target data to a protocol format. Of course, in other examples, for the target data sent to the standard protocol transceiver, since the format type used is a pre-set standard protocol format, the standard protocol transceiver does not need to convert the target data to a protocol format, and can directly send the target data to the accessory device 400 of the standard protocol type.

[0108] In some examples, the target data sent to the non-standard protocol transceiver is in a format that is not a standard protocol format pre-set in the present application. Therefore, the non-standard protocol transceiver needs to convert the target data into a protocol format to obtain data in a corresponding non-standard protocol format. The data in the non-standard protocol format is then sent to the accessory device 500 of the corresponding non-standard protocol type.

[0109] In some examples, the dedicated transceiver may also encrypt the target data or data in a non-standard protocol format to be sent, and the encryption process may also be referred to as an encoding process. Of course, the dedicated transceiver may also directly send the target data or data in a non-standard protocol format to the corresponding peripheral device without encryption. This application is not limited here.

[0110] Understandably, Figures 3 to 5 The described non-standard protocol transceiver can be developed by each manufacturer that produces the accessory device 500 of the non-standard protocol type. Therefore, there can be a corresponding non-standard protocol transceiver for each different non-standard protocol type of accessory device 500. For example, manufacturer A produces an accessory device of protocol type A, and manufacturer B produces an accessory device of protocol type B. In this case, the terminal device 100 needs to have a non-standard protocol transceiver 1 corresponding to the accessory device of protocol type A and a non-standard protocol transceiver 2 corresponding to the accessory device of protocol type B. In another example, if manufacturer A produces multiple different accessory devices of protocol type A, it is only necessary to deploy a non-standard protocol transceiver 1 corresponding to the accessory device of protocol type A in the terminal device 100, without the need to deploy multiple identical non-standard protocol transceivers.

[0111] against Figures 3 to 5 The described standard protocol type accessory device may be a GATT device. Since the standard protocol is used, as long as the accessed standard protocol type accessory device 400 meets the GATT compatibility requirement, the terminal device may directly use the standard protocol transceiver, i.e., the GATT protocol transceiver, to communicate.

[0112] At the same time, in one example, the above Figures 3 to 5 The target data described may be an operation instruction or parameter data. The operation instruction is used to control the opposite end to perform the corresponding operation. For example, if the target application in the terminal device 100 sends an instruction, the wearable device 200 or the accessory device 300 connected thereto is the opposite end; if the wearable device 200 or the accessory device 300 sends an instruction, the terminal device 100 is the opposite end. For parameter data, it may be any parameter that the wearable device 200 or the accessory device 300 may collect, such as blood oxygen data, blood sugar data, blood pressure data, heart rate data, walking steps, temperature data, humidity data, etc. collected by the device. It is understandable that the parameter data may also include corresponding parameter units.

[0113] Figure 6 A schematic diagram of a wearable device architecture provided in an embodiment of the present application.

[0114] Figure 6 The structure of the wearable device 200 is shown mainly. It can be seen that the wearable device structure is similar to Figure 3 The main difference in the architecture of the terminal device 100 is that the wearable device 200 does not need to be configured with a wearable protocol transceiver. At the same time, for the aggregation and forwarding module in the wearable device 200. The target data can be forwarded to the terminal device 100. Among them, the APP in the wearable device 200 is pre-installed with a second device management service SDK. It can be understood that the second device management service SDK is a device management service SDK installed on the wearable device. And, the framework layer in the wearable device 200 includes a second device management service API. It can be understood that the second device management service API is a device management service API provided by the framework layer on the wearable device.

[0115] In one example, the wearable device 200 may also be matched and communicated with the accessory device 300. The specific implementation method is similar to the matching and communication method between the terminal device 100 and the accessory device 300. For details, please refer to Figures 3 to 5 The corresponding description in will not be repeated here.

[0116] Different from the terminal device 100, after the convergence and forwarding module receives the target data and determines that the target data is forwarded to the corresponding target application, the convergence and forwarding module also needs to determine whether the target application is the target application on the wearable device 200 or the target application on the terminal device 100.

[0117] In one example, if the aggregation and forwarding module determines that the target application is a target application on the wearable device 200, the implementation method is similar to the implementation method of the terminal device sending the target data to the target application. For details, please refer to Figures 3 to 5 The corresponding description in will not be repeated here.

[0118] In another example, if the aggregation and forwarding module determines that the target application is the target application on the terminal device 100, the aggregation and forwarding module in the wearable device 200 sends the target data to the terminal device 100. For the terminal device 100, the target data sent by the wearable device 200 can be received by the wearable protocol transceiver, and then the target data is sent to the target application of the terminal device 100 via the aggregation and forwarding module in the terminal device 100. The specific forwarding process of data in the terminal device 100 can be referred to Figures 3 to 5 The corresponding description in will not be repeated here.

[0119] In another example, when the terminal device 100 sends the target data to the wearable device 200, the aggregation and forwarding module of the wearable device 200 can receive the target data sent by the terminal device 100 and determine the destination address contained in the target data. If the destination address is the wearable device 200, the aggregation and forwarding module of the wearable device 200 can forward the target data to the corresponding application in the application layer through the second device management service API in the framework layer. Specifically, it can be received through the second device management service SDK pre-set in the corresponding application. Of course, in some other examples, if the destination address is an accessory device 300 connected to the wearable device 200, that is, an accessory device 400 of a standard protocol type or an accessory device 500 of a non-standard protocol type. Then the aggregation and forwarding module of the wearable device 200 can send the target data to the corresponding dedicated transceiver through the corresponding transceiver interface, and then send the target data to the corresponding accessory device 300 via the dedicated transceiver. The specific implementation process can refer to the process of the terminal device 100 sending data to the accessory device 300, and can refer to Figures 3 to 5 The corresponding description in will not be repeated here.

[0120] pass Figures 3 to 6 The described solution can support the connection and communication between the terminal device and the wearable device and the accessory device, and the connection and communication between the wearable device and the accessory device. At the same time, for the terminal device and the wearable device, there is no need to deploy a specific device C-APP for each type of connected device, and the connection and communication between the devices can be completed.

[0121] At the same time, for some existing solutions, such as deploying some super APPs, such as sports and health APPs, smart home APPs, etc., all connected accessories and wearable devices are managed through such super APPs, and data communication and protocol adaptation are performed. However, since a large number of accessories with non-standard protocols may be connected, functional coupling may be caused, increasing the difficulty of connecting new accessories. Therefore, the solution involved in this application does not require the installation of a specific APP. It only requires the pre-installed device management service SDK in various target applications that need to use the target data to call the unified device management service of this application, which increases convenience. At the same time, there is no need to consider the problem of functional coupling, which greatly reduces the difficulty of accessing accessories with non-standard protocol types.

[0122] Figure 7 A schematic diagram of another terminal device architecture provided in an embodiment of the present application.

[0123] like Figure 7 As shown, the present application also provides another schematic diagram of the architecture of the terminal device, relative to Figure 3 The terminal device 100 shown Figure 7 The terminal device 700 shown does not need to be configured with a non-standard protocol transceiver and a non-standard protocol transceiver interface. The terminal device 700 is connected to and communicates with a standard protocol type accessory device 400 and / or a non-standard protocol type accessory device 600 through a standard protocol transceiver.

[0124] It can be seen that Figure 7 The non-standard protocol type accessory device 600 and Figure 3 The difference between the non-standard protocol type accessory device 500 and the non-standard protocol type accessory device 600 is that the PDK is pre-configured in the non-standard protocol type accessory device 600. The PDK is mainly used to convert the non-standard protocol format data to be sent by the non-standard protocol type accessory device 600 to obtain the target data in the standard protocol format. Then, the target data in the standard protocol format is sent to the terminal device 700 so that the standard protocol transceiver in the terminal device 700 can receive it.

[0125] At the same time, the PDK is also used to convert the target data sent by the terminal device 700 into a protocol format. For example, the target data in a standard protocol format sent by the terminal device 700 is converted into a protocol format to obtain data in a non-standard protocol format, so that the accessory device 600 of a non-standard protocol type can correctly read and use the data in the non-standard protocol format.

[0126] In one example, the PDK may be a stub kit (SK) deployed on an accessory device 600 of a non-standard protocol type, and is mainly used to perform protocol format conversion between data in a non-standard protocol format on the accessory device 600 of a non-standard protocol type and target data in a standard protocol format. The SK may exist in the form of a plug-in. It is understandable that, since the plug-in technology is used, it is also necessary to define the installation and uninstallation operations of the plug-in.

[0127] It is understandable that the process of connecting and matching the terminal device 700 with the wearable device 200 and the standard protocol type accessory device 400 and communicating with each other can refer to Figures 3 to 5 For the process of connecting and matching the terminal device 700 and the auxiliary device 600 of the non-standard protocol type and communicating with each other, please refer to Figures 3 to 5 The description of the connection and matching between the terminal device 700 and the auxiliary device 400 of the standard protocol type and the mutual communication is not repeated in this application.

[0128] Figure 8 A schematic diagram of another wearable device architecture provided in an embodiment of the present application.

[0129] like Figure 8 As shown, the present application also provides another schematic diagram of the architecture of a wearable device, relative to Figure 6 The wearable device 200 shown Figure 8 The wearable device 800 shown also does not need to be configured with a non-standard protocol transceiver and a non-standard protocol transceiver interface. The wearable device 800 is connected and communicates with a standard protocol type accessory device 400 and / or a non-standard protocol type accessory device 600 through a standard protocol transceiver.

[0130] It is understandable that for the process of connecting and matching the wearable device 800 with the accessory device 400 of the standard protocol type and the accessory device 600 of the non-standard protocol type, and communicating with each other, reference can be made to Figure 7 The corresponding description of the terminal device 700 will not be repeated in this application.

[0131] It can be seen that Figure 8 , Fig. 9The terminal device 700 and the wearable device 800 shown in the figure no longer need to deploy non-standard protocol transceivers and non-standard protocol transceiver interfaces to achieve adaptation to any wearable device and / or accessory device. By replacing the originally deployed non-standard protocol transceiver with a PDK deployed on an accessory device 600 of a non-standard protocol type, the data sent by such an accessory device 600 of a non-standard protocol type is the target data in a standard protocol format. For the terminal device 700 and the wearable device 800, this is equivalent to transforming an accessory device 600 of a non-standard protocol type into an accessory device 400 of a standard protocol type. Therefore, it can be understood that compared to Figure 3 , Figure 6 The solution shown requires an uncertain number of non-standard protocol transceivers to be deployed. Figure 8 , Fig. 9 The solution shown requires fixed types of transceivers to be deployed, so it is more convenient to access auxiliary devices of non-standard protocol types.

[0132] It is understandable that in some cases, Figure 3 and Figure 7 The wearable device 200 in the embodiment may also be replaced by Figure 8 The wearable device 800 is shown, and Figure 6 and Figure 8 The terminal device 100 in can also be replaced by Figure 7 The terminal device 700 is shown.

[0133] Fig. 9 A flowchart of another method for managing ancillary devices provided in an embodiment of the present application.

[0134] This application provides a method for managing ancillary equipment. The method can be applied to the above Figure 3 , Figure 6 , Figure 7 , Figure 8 The terminal device or wearable device in the embodiment of the present invention may include a target application, and a device management service SDK is configured in the target application. It can be understood that if the method is applied on the terminal device, the device management service SDK is a first device management service SDK, and if the method is applied on the wearable device, the device management service SDK is a second device management service SDK. The method may include the following steps:

[0135] S901: Receive a broadcast message sent by at least one attached device.

[0136] S902: Determine, according to the broadcast message, the device type of the attached device that sends the broadcast message.

[0137] S903: Determine, according to the device type of the accessory device, a dedicated transceiver corresponding to the device type.

[0138] In one example, the device type may include: a standard device type and a first non-standard device type. The dedicated transceiver may include: a standard protocol transceiver. The standard protocol transceiver is a dedicated transceiver corresponding to an accessory device of the standard device type and an accessory device of the first non-standard device type. It is understood that the accessory device of the first non-standard device type is the above-mentioned Figure 7 , Figure 8 The non-standard protocol type accessory device 600 is shown in FIG.

[0139] In one example, the accessory device of the first non-standard device type includes a PDK.

[0140] In one example, the device type may include: a second non-standard device type. The dedicated transceiver may include: a non-standard protocol transceiver. The non-standard protocol transceiver is a dedicated transceiver corresponding to the accessory device of the second non-standard device type. It is understandable that the accessory device of the second non-standard device type is the above-mentioned Figure 3 , Figure 6 The non-standard protocol type accessory device 500 is shown in FIG.

[0141] In one example, if the method is applied to a terminal device, the device type may further include: a wearable device type. The dedicated transceiver may further include: a wearable protocol transceiver. The wearable protocol transceiver is a dedicated transceiver corresponding to an accessory device of the wearable device type.

[0142] S904, communicating with the accessory device via a dedicated transceiver so that the target application and the accessory device can perform data interaction of target data, wherein the target application sends and / or receives the target data via the device management service SDK.

[0143] In one example, the target data sent by the accessory device of the first non-standard device type may be received by the standard protocol transceiver, wherein the target data is the target data determined by the accessory device of the first non-standard device type through protocol format conversion performed by the PDK.

[0144] In one example, the non-standard protocol transceiver can perform protocol format conversion on the data in the non-standard protocol format received from the accessory device of the second non-standard device type to obtain the target data. Then, the non-standard protocol transceiver can also perform protocol format conversion on the target data sent to the accessory device of the second non-standard device type to obtain the data in the non-standard protocol format.

[0145] In another example, the target data sent and received to the non-standard protocol transceiver may be verified through the non-standard protocol transceiver interface, and the protocol format of the data in the non-standard protocol format in the target data may be converted into the standard protocol format.

[0146] In one example, the target data may include: operation instructions and / or parameter data.

[0147] In one example, the target data may be target data in a standard protocol format, and the standard protocol format may be a GATT format.

[0148] Fig.10 A flowchart of another method for managing auxiliary equipment provided in an embodiment of the present application.

[0149] The present application also provides a flow chart of another method for managing auxiliary equipment, Fig. 9 In S904, the specific steps of the dedicated transceiver receiving the target data sent by the auxiliary device may be as follows:

[0150] S1001, receiving target data sent by an auxiliary device through a dedicated transceiver.

[0151] S1002, sending the target data to the aggregation and forwarding module through a dedicated transceiver.

[0152] S1003: Determine a target application corresponding to the target data according to a pre-configured relationship between the target application and the target data.

[0153] S1004: Send the target data to the second device management service SDK through the aggregation and forwarding module, so that the target application can read and use the target data through the device management service SDK.

[0154] In one example, if the method is applied to a wearable device, before S1004, the target application may be determined to be a target application of the terminal device or a target application of the wearable device. Then, when the target application is a target application of the terminal device, the target data is sent to the terminal device.

[0155] Fig.11 A flowchart of another method for managing auxiliary equipment provided in an embodiment of the present application.

[0156] The present application also provides a flow chart of a method for managing ancillary equipment. Fig. 9 In S904, the specific steps of the dedicated transceiver sending the target data to the attached device may be as follows:

[0157] S1101, sending target data generated by a target application to a convergence and forwarding module through a device management service SDK.

[0158] S1102, forwarding the target data to the dedicated transceiver through the aggregation and forwarding module.

[0159] S1103, sending the target data to the attached device via a dedicated transceiver.

[0160] Understandably, Figures 9 to 11 The specific implementation process of the described method can be referred to Figures 3 to 8 The corresponding description in will not be repeated here.

[0161] pass Figures 3 to 11 , the present application provides a method and apparatus for managing accessory devices, and accessory devices. Through the unified device management service deployed on the mobile phone, and the device management service SDK deployed in the corresponding target application, the terminal device can pair and communicate with any wearable device or accessory device. The same is true for wearable devices. It is also possible to deploy a unified device management service and the device management service SDK in the corresponding target application, and communicate with any accessory device. Through the dedicated transceiver contained in the unified device management service, communication can be carried out with self-developed wearable devices, accessory devices that comply with the GATT protocol, and accessory devices produced by any other manufacturer. And the data is transmitted to the aggregation and forwarding module through the corresponding interface, so that it can be forwarded to the corresponding APP in the APP layer.

[0162] This application solves the problem of managing wearable devices, accessory devices and communicating with these devices on terminal devices. It makes it unnecessary for the terminal devices and wearable devices involved in this application to install C-APP separately for each type of managed device, which simplifies the development and deployment work and saves the resources required for the development and deployment of C-APP.

[0163] Fig.12 A schematic diagram of an apparatus for managing auxiliary equipment provided in an embodiment of the present application.

[0164] like Fig.12As shown, a device 1200 for managing accessory devices is provided. The device 1200 may be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device and / or a smart city device. The embodiments of the present application do not impose any special restrictions on the specific type of the device 1200.

[0165] The device 1200 may include a processor 1210, an external memory interface 1220, an internal memory 1221, a universal serial bus (USB) interface 1230, a charging management module 1240, a power management module 1241, a battery 1242, an antenna 1, an antenna 2, a mobile communication module 1250, a wireless communication module 1260, a display screen 1270, a subscriber identity module (SIM) card interface 1280, and a sensor 1290, etc.

[0166] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the device 1200. In other embodiments of the present application, the device 1200 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0167] The processor 1210 may include one or more processing units, for example, the processor 1210 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0168] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0169] The processor 1210 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 1210 is a cache memory. The memory may store instructions or data that the processor 1210 has just used or cyclically used. If the processor 1210 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 1210, and thus improves the efficiency of the system.

[0170] In some embodiments, the processor 1210 may include one or more interfaces. The interface 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, and / or a universal serial bus (USB) interface, etc.

[0171] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the device 1200. In other embodiments of the present application, the device 1200 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0172] The external memory interface 1220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the device 1200. The external memory card communicates with the processor 1210 via the external memory interface 1220 to implement a data storage function, such as storing files such as audio data in the external memory card.

[0173] The internal memory 1221 may be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 1221 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 1210 executes various functional applications and data processing of the device 1200 by running instructions stored in the internal memory 1221 and / or instructions stored in a memory provided in the processor.

[0174] The sensor 1290 may include an infrared sensor, a gyroscope, a gravity sensor, an acceleration sensor, an angular velocity sensor, a PPG sensor, a GPS sensor, a fingerprint sensor, and other sensors that may be needed.

[0175] It is understandable that if the apparatus 1200 is a wearable device, the mobile communication module 1250 and the SIM card interface 1280 may be omitted.

[0176] The device 1200 provided in this application can realize the above Figures 3 to 11 For any function of the terminal device or wearable device in the described example, the specific implementation method can refer to the description Figures 3 to 11 The corresponding description in will not be repeated here.

[0177] Fig.13 A schematic diagram of an auxiliary device provided in an embodiment of the present application.

[0178] like Fig.13 As shown, an accessory device 1300 is provided, which may be an AR device, a VR device, an AI device, a wearable device, a vehicle-mounted device, a smart home device, a smart city device and / or various devices that can perform health monitoring, etc. The embodiment of the present application does not impose any special restrictions on the specific type of the accessory device 1300.

[0179] The accessory device 1300 may include a processor 1310, an external memory interface 1320, an internal memory 1321, a USB interface 1330, a charging management module 1340, a power management module 1341, a battery 1342, an antenna, a wireless communication module 1350, a display screen 1360, and a sensor 1370, etc.

[0180] It is understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the accessory device 1300. In other embodiments of the present application, the accessory device 1300 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0181] The processor 1310 may include one or more processing units, for example, the processor 1310 may include an AP, a modem processor, a GPU, an ISP, a controller, a video codec, a DSP, a baseband processor and / or an NPU, etc. Different processing units may be independent devices or integrated into one or more processors.

[0182] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0183] The processor 1310 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 1310 is a cache memory. The memory may store instructions or data that the processor 1310 has just used or cyclically used. If the processor 1310 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 1310, and thus improves the efficiency of the system.

[0184] In some embodiments, the processor 1310 may include one or more interfaces. The interface may include an I2C interface, an I2S interface, a PCM interface, a UART interface, a MIPI, a GPIO interface, and / or a USB interface, etc.

[0185] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the accessory device 1300. In other embodiments of the present application, the accessory device 1300 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0186] The external memory interface 1320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the accessory device 1300. The external memory card communicates with the processor 1310 via the external memory interface 1320 to implement a data storage function, such as storing files such as audio data in the external memory card.

[0187] The internal memory 1321 may be used to store computer executable program codes, which may include instructions. The internal memory 1321 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a UFS, etc. The processor 1310 executes various functional applications and data processing of the accessory device 1300 by running instructions stored in the internal memory 1321 and / or instructions stored in a memory provided in the processor.

[0188] The sensor 1370 may include an infrared sensor, a gyroscope, a gravity sensor, an acceleration sensor, an angular velocity sensor, a PPG sensor, a GPS sensor, a fingerprint sensor, and other sensors that may be needed.

[0189] The accessory device 1300 provided in this application can realize the above Figures 7 to 11 The specific implementation of any function of the non-standard protocol type accessory device 600 or the first non-standard protocol type accessory device in the described example can refer to the description of Figures 7 to 11 The corresponding description in will not be repeated here.

[0190] Those of ordinary skill in the art should further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0191] A person skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing a processor through a program, and the program can be stored in a computer-readable storage medium, and the storage medium is a non-transitory medium, such as a random access memory, a read-only memory, a flash memory, a hard disk, a solid-state drive, a magnetic tape, a floppy disk, an optical disc, and any combination thereof.

[0192] The above is only a preferred specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for managing ancillary equipment, characterized in that: The method is applied to a terminal device or a wearable device, wherein the terminal device or the wearable device includes a target application, the target application includes a device management service software development kit SDK, and the method includes: receiving a broadcast message sent by at least one attached device; Determine the device type of the auxiliary device that sends the broadcast message according to the broadcast message; the device type includes: a standard device type and a first non-standard device type; Determine a dedicated transceiver corresponding to the device type according to the device type of the accessory device; the dedicated transceiver includes a standard protocol transceiver; wherein the standard protocol transceiver is a dedicated transceiver corresponding to the accessory device of the standard device type and the accessory device of the first non-standard device type; Communicating with the accessory device through the dedicated transceiver so that the target application and the accessory device perform data interaction of target data, wherein the target application sends and / or receives target data through the device management service SDK; wherein communicating with the accessory device through the dedicated transceiver includes: receiving target data sent by the auxiliary device through the dedicated transceiver; Sending the target data to the aggregation and forwarding module through the dedicated transceiver; Determine the target application corresponding to the target data according to the pre-configured relationship between the target application and the target data; Sending the target data to the device management service SDK through the aggregation and forwarding module, so that the target application reads and uses the target data through the device management service SDK; Among them, sending the target data to the aggregation and forwarding module through the dedicated transceiver includes: for an accessory device of a standard device type, packaging the target data, and forwarding the packaged target data to the aggregation and forwarding module through a standard protocol transceiver interface; for an accessory device of a first non-standard device type, converting data in a non-standard protocol format into target data in a standard protocol format, packaging the converted target data in the standard protocol format, and forwarding the packaged target data to the aggregation and forwarding module via a non-standard protocol transceiver interface.

2. The method according to claim 1, characterized in that If the method is applied to the wearable device, before sending the target data to the device management service SDK through the aggregation and forwarding module, the method further includes: Determining that the target application is a target application of the terminal device or a target application of the wearable device; If the target application is the target application of the terminal device, the target data is sent to the terminal device.

3. The method according to claim 1 or 2, characterized in that The communicating with the auxiliary device through the dedicated transceiver includes: Sending the target data generated by the target application to the aggregation and forwarding module through the device management service SDK; forwarding the target data to the dedicated transceiver through the aggregation and forwarding module; The target data is sent to the accessory device through the dedicated transceiver.

4. The method according to claim 1, characterized in that The accessory equipment of the first non-standard equipment type includes a product development kit PDK; The communicating with the auxiliary device through the dedicated transceiver comprises: The target data sent by the first non-standard device type accessory device is received through the standard protocol transceiver; wherein the target data is the protocol format transmitted by the first non-standard device type accessory device through the PDK The target data is determined by the conversion method.

5. The method according to claim 1 or 2, characterized in that: The device types include: a second non-standard device type; The dedicated transceiver includes: a non-standard protocol transceiver; The non-standard protocol transceiver is a dedicated transceiver corresponding to the auxiliary device of the second non-standard device type.

6. The method according to claim 5, characterized in that The communicating with the auxiliary device through the dedicated transceiver includes: Performing protocol format conversion on data in a non-standard protocol format received from an accessory device of the second non-standard device type by the non-standard protocol transceiver to obtain target data; and The target data sent to the accessory device of the second non-standard device type is converted into a protocol format by the non-standard protocol transceiver to obtain data in the non-standard protocol format.

7. The method according to claim 5, characterized in that The method further comprises: Verifying the target data received from the non-standard protocol transceiver through the non-standard protocol transceiver interface, and converting the protocol format of the data in the non-standard protocol format in the target data into the standard protocol format; The target data sent to the non-standard protocol transceiver is verified through the non-standard protocol transceiver interface, and the protocol format of the data in the non-standard protocol format in the target data is converted into the standard protocol format.

8. The method according to claim 1 or 2, characterized in that: If the method is applied to the terminal device, the device type includes: a wearable device type; The dedicated transceiver includes: a wearable protocol transceiver; Among them, the wearable protocol transceiver is a dedicated transceiver corresponding to the accessory device of the wearable device type.

9. The method according to claim 1 or 2, characterized in that: The target data includes: operation instructions and / or parameter data.

10. The method according to claim 1 or 2, characterized in that: The target data is target data in a standard protocol format, and the standard protocol format is a General Attribute Profile GATT format.

11. A device for managing auxiliary equipment, characterized in that: The device is a terminal device or a wearable device, wherein the device includes a target application, the target application includes a device management service software development kit SDK, and the device includes: a universal transceiver for receiving broadcast messages sent by at least one accessory device; The processor is coupled to the memory and is configured to read and execute instructions stored in the memory; When the processor is running, the instructions are executed, so that the processor is used to determine the device type of the auxiliary device that sends the broadcast message according to the broadcast message; the device type includes: a standard device type and a first non-standard device type; The processor is further configured to determine, according to the device type of the accessory device, a dedicated transceiver corresponding to the device type; the dedicated transceiver comprises a standard protocol transceiver; wherein the standard protocol transceiver is a dedicated transceiver corresponding to the accessory device of the standard device type and the accessory device of the first non-standard device type; The processor is further configured to control the dedicated transceiver to communicate with the accessory device so that the target application and the accessory device perform data interaction of target data, wherein the target application sends and / or receives target data through the device management service SDK; The processor is further configured to: Controlling the dedicated transceiver to receive target data sent by the accessory device; Controlling the dedicated transceiver to send the target data to the aggregation and forwarding module; determining the target application corresponding to the target data according to the pre-configured relationship between the target application and the target data; Controlling the aggregation and forwarding module to send the target data to the device management service SDK, so that the target application reads and uses the target data through the device management service SDK; Among them, the controlling of the dedicated transceiver to send the target data to the aggregation and forwarding module includes: for an accessory device of a standard device type, packaging the target data, and forwarding the packaged target data to the aggregation and forwarding module through a standard protocol transceiver interface; for an accessory device of a first non-standard device type, converting data in a non-standard protocol format into target data in a standard protocol format, packaging the converted target data in the standard protocol format, and forwarding the packaged target data to the aggregation and forwarding module via a non-standard protocol transceiver interface.

12. The device according to claim 11, characterized in that If the apparatus is the wearable device, the processor is further configured to: Determining that the target application is a target application of the terminal device or a target application of the wearable device; If the target application is a target application of the terminal device, the target data is sent to the terminal device via the universal transceiver.

13. The device according to claim 11 or 12, characterized in that The processor is further configured to: Sending the target data generated by the target application to the aggregation and forwarding module through the device management service SDK; Controlling the aggregation and forwarding module to forward the target data to the dedicated transceiver; The dedicated transceiver is controlled to send target data to the accessory device.

14. The device according to claim 11, characterized in that The processor is further configured to: The standard protocol transceiver is controlled to receive target data sent by the accessory device of the first non-standard device type; wherein the target data is target data determined by the accessory device of the first non-standard device type through protocol format conversion performed by a product development kit PDK.

15. The device according to claim 11 or 12, characterized in that The device types include: a second non-standard device type; The dedicated transceiver includes: a non-standard protocol transceiver; The non-standard protocol transceiver is a dedicated transceiver corresponding to the auxiliary device of the second non-standard device type.

16. The device according to claim 15, characterized in that The processor is further configured to: Controlling the non-standard protocol transceiver to perform protocol format conversion on data in a non-standard protocol format received from an accessory device of the second non-standard device type to obtain target data; as well as The non-standard protocol transceiver is controlled to perform protocol format conversion on target data sent to the accessory device of the second non-standard device type to obtain data in the non-standard protocol format.

17. The device according to claim 15, characterized in that The device also includes a non-standard protocol transceiver interface; The processor is further used to control the non-standard protocol transceiver interface to verify the target data received from the non-standard protocol transceiver, and convert the protocol format of the data in the non-standard protocol format in the target data into the standard protocol format; The non-standard protocol transceiver interface is controlled to verify the target data sent to the non-standard protocol transceiver, and the protocol format of the data in the non-standard protocol format in the target data is converted into the standard protocol format.

18. The device according to claim 11 or 12, characterized in that If the device is the terminal device, the device type includes: a wearable device type; The dedicated transceiver includes: a wearable protocol transceiver; Among them, the wearable protocol transceiver is a dedicated transceiver corresponding to the accessory device of the wearable device type.

19. The device according to claim 11 or 12, characterized in that The target data includes: operation instructions and / or parameter data.

20. The device according to claim 11 or 12, characterized in that The target data is target data in a standard protocol format, and the standard protocol format is a general attribute profile GATT format.

21. An auxiliary device, characterized in that: The accessory device is pre-installed with a product development kit PDK, and the accessory device includes: Sensors, used to generate parameter data; The processor is coupled to the memory and is configured to read and execute instructions stored in the memory; When the processor is running, the instructions are executed, so that the processor is used to control the PDK to perform protocol format conversion on the parameter data and / or operation instructions to obtain target data; A transmitter, used to send target data to a terminal device or a wearable device; the terminal device or the wearable device is used to execute the method as described in any one of 1-10.

22. The accessory device according to claim 21, characterized in that The auxiliary equipment also includes: A receiver, used to receive target data sent by a terminal device or a wearable device; The processor is further used to control the PDK to perform protocol format conversion on the target data to obtain the parameter data and / or the operation instruction.

23. A computer-readable storage medium having instructions stored therein, characterized in that: When the instruction is executed on a terminal, the terminal is caused to execute the method according to any one of claims 1 to 10.

Images