Bluetooth device identification system and process thereof

Abstract

A computing system and process for identifying a type of computing device communicating over a wireless Bluetooth protocol. The computing systems relate to customized or non-customized computing systems configured to send queries through all protocols described in the Bluetooth specification and vendor-specific protocols. The computing system analyzes in conjunction with raw data, behavioral data, and real data about known devices to establish a device identification of any computing device communicating over Bluetooth. In the absence of real data, the device identifier is deduced by integrating all the collected data, and is attached with related confidence.

Description

[0001] Statement regarding federally funded research or development not applicable.

[0002] Copyright Notice This disclosure contains copyrighted material. The copyright holder has no objection to any person making copies of the patent document or patent description in the form presented in the patent office documents or records, but reserves all copyright rights. Technical Field

[0003] This invention relates to a Bluetooth device identification computing system and its process, and more particularly to a computing system and its process for identifying Bluetooth devices using multiple Bluetooth protocols and other Bluetooth-related data. Background Technology

[0004] The Bluetooth wireless protocol for information transmission was defined in 1999. A subsequent update in 2004 introduced Bluetooth Enhanced Data Rate (EDR) and reverted the name of the previous Bluetooth wireless protocol to Basic Rate (BR). These protocols are collectively referred to as Bluetooth BR / EDR. In 2009, Bluetooth Low Energy (BLE) was defined, and many new technologies and protocols incompatible with BR / EDR were added. These technologies and protocols are collectively referred to as BLE in this document.

[0005] Bluetooth describes "profiles" as documents that define "the features and functionalities required by each layer in the Bluetooth system" (Bluetooth Core Specification 6.0 (2024)). https: / / www. Bluetooth .com / specifications / specs / core- specification-6-0 / The document states that configuration files define the vertical interactions between layers and the point-to-point interactions between devices at specific layers. Therefore, Bluetooth configuration files can be considered supplementary specifications to the Bluetooth core specification. They contain additional data and behaviors that devices choose to conform to in order to achieve interoperability. Configuration files can be public and standardized, or proprietary and vendor-specific.

[0006] Previous research on Bluetooth device identification has fallen into four categories. Category 1 Bluetooth device identification systems refer to those that attempt to identify a single device over a period of time, regardless of the device type. One common application scenario for this type of system is to implement access control, authorize access to a single authorized device, and prevent other devices from impersonating authorized devices to gain access. US Patent 2022 / 312507A1 by Wang et al. and US Patent 2021 / 058393A1 by Alpert et al. are examples of this type of system. Another common application scenario is that although Bluetooth Device Address (BDADDR) is designed to track a single device over a long period of time, this makes tracking more difficult. US Patent 2020 / 236004A1 by Tavares et al. is an example of this type of technology. Unlike the systems disclosed in this invention, these systems are not concerned with distinguishing and identifying specific devices, such as Apple® iPhones and Samsung® TVs.

[0007] Category 2 Bluetooth device identification systems refer to those that attempt to create a fingerprint for a specific device based on its device-specific wireless characteristics. This category often overlaps with Category 1 (e.g., US Patent 2022 / 312507 A1 by Wang et al. and US Patent 2021 / 058393 A1 by Alpert et al. both employ these techniques). Although the system disclosed in this invention can also use this type of fingerprinting system as another supplementary source of multi-source information as described herein, this type of information is not the preferred data source. This is because the primary function of this type of information is to identify individual devices (i.e., device #1 vs. device #2) over time, but it does not significantly contribute to determining the type of device. In other words, it is not a strong signal to distinguish that device #1 is an iPhone and device #2 is a TV. Physical layer feature fingerprinting is more reflective of the characteristics of the Bluetooth chip's radio frequency hardware, and therefore it is primarily suitable for distinguishing that device #1 uses Bluetooth chip manufacturer #1 and device #2 uses Bluetooth chip manufacturer #2. However, this is only one aspect of the overall device identification implemented by the system of this invention.

[0008] Category 3 Bluetooth device identification systems refer to those that use a single data source to create a device ID (DID) "fingerprint" for the device to be identified (DTI). An example is "Automatic Fingerprinting of Vulnerable BLE IoT Devices with Static UUIDs from Mobile Apps" (2019) by Zuo et al. https: / / web.archive.org / web / 20191124060800 / https: / / web.cse.ohio-state.edu / ~lin.3021 / file / CCS19a.pdf) and Celosia and Cunche's "Fingerprinting Bluetooth-Low-Energy Devices Based on the Generic Attribute Profile" (2021) https: / / inria.hal.science / hal-02359914 / file / paper.pdf Both papers use a single data source—the Generic Attribute Profile (GATT). GATT information includes a hierarchy of "services" and "features." The former paper only collected the hierarchical information, which it termed a fingerprint. The latter, by reading specific values ​​from GATT features, not only collected this information but also delved deeper into more complex details. However, both fingerprints completely ignore other information obtained through other protocols, profiles, and behavioral data. Another example of a single-data-source system is Zhang et al.'s "Bluetooth Low Energy Device Identification Based on Link Layer BroadcastPacket Fingerprinting" (2023). https: / / gitlab.com / XenoKovah / bluetooth-security- timeline / - / blob / main / paper-mirror / ZhangJinghui_whitepaper_Bluetooth_Low_ Energy_Device_Identification_Based_on_Link_Layer_Broadcast_Packet_ Fingerprinting.pdf In their system, they analyzed only BLE broadcast data. Almost all systems described in academic works are single-data-source systems. Our system, however, collects and synthesizes data from a complete set of protocols, configuration files, and behaviors, including some elements never before described in previous related research.

[0009] Category 4 Bluetooth device identification systems refer to multi-data source systems. This is discussed in the academic paper "Fingerprinting and analysis of Bluetooth devices with automatalearning" (2022) by Pferscher and Aichernig. https: / / arxiv.org / pdf / 2211.16074Such a system is described in [the document / article title]. It is also the only system that introduces behavioral analysis when attempting to fingerprint a device. This system studies the state machine of the DTI using a technique called "fuzz testing," where data for certain packet types is randomized or even automatically modified to be invalid. This method is applied only to a limited number of protocols, such as BLE Link Layer (LL) control packets, Security Manager Protocol (SMP), and Attribute Protocol (ATT). The result is a state machine that represents edges as packet types and nodes as speculative internal states of the target DTI. However, the system takes several hours to generate a baseline DID for a single DTI. This system is not suitable for on-demand identification of hundreds or thousands of Bluetooth devices in busy environments. Furthermore, the system cannot create DIDs for devices not controlled by the system owner, nor can it generate meaningful results for devices without true information. In other words, it can create two DIDs but cannot determine whether one corresponds to an Apple® iPhone and the other to an Apple® MacBook unless the system is explicitly told beforehand which device each DID corresponds to. Furthermore, this system does not attempt to identify the minimum discriminative sequence in the state machine, which distinguishes devices with minimal queries, rather than trying all possible permutations and combinations. In contrast, our system can create high-confidence and meaningful DIDs even without real-world information. Moreover, our system focuses on behavioral analysis for device identification, which is efficient (completed within seconds) and scalable to thousands of concurrent DTIs.

[0010] Therefore, there is an urgent need for a system that can detect and distinguish different types of devices.

[0011] A system is also needed that can establish connections with other devices and detect and distinguish different devices by synthesizing device identification data from multi-source data obtained from all protocol layers, configuration files, and behaviors.

[0012] A system is also needed that can send queries using all possible protocols described in the Bluetooth specification as well as vendor-specific protocols to identify the type of device communicating via the Bluetooth wireless protocol.

[0013] A system is also needed that can collect raw and behavioral information of devices communicating via the Bluetooth wireless protocol, thereby identifying the device's model, manufacturer, Bluetooth chip used, Bluetooth chip manufacturer, software / firmware version, etc.

[0014] A system is also needed that can collect raw and behavioral information of devices communicating via the Bluetooth wireless protocol to determine which Bluetooth chips are used inside these Bluetooth communication devices, thereby determining whether the device is susceptible to wireless exploitation of the Bluetooth firmware.

[0015] A system is also needed that not only utilizes state machine reasoning mechanisms, but also has the ability to generate minimum distinguishable data packet sequences based on the differences between two or more state machines. Attached Figure Description

[0016] These and / or other features and functions of the present invention will become more apparent in the following description of embodiments and will be more readily understood in conjunction with the accompanying drawings, wherein: Figure 1 A system for integrating Bluetooth device identification information is shown as an exemplary embodiment according to the concept of the present invention.

[0017] Figure 2 A process for integrating various information of a Bluetooth device identifier is illustrated in an exemplary embodiment according to the concept of the present invention.

[0018] Figure 2A It shows that according to Figure 2 The process in the middle is a sub-process for raw data acquisition. This process generates DID D118 for all Bluetooth communication devices by traversing all layers of the BR / EDR and BLE protocol stack and sending data to all discovered devices to be identified.

[0019] Figure 2B It shows that according to Figure 2 The exemplary embodiment of the process describes a subprocess that performs behavioral analysis on all possible protocol stack layers.

[0020] Figure 2C It shows that according to Figure 2 An exemplary embodiment of the inference engine subprocess is provided, which is used to synthesize information about the Bluetooth device identifier.

[0021] Figure 3 A system for integrating Bluetooth device identification information is shown as another exemplary embodiment of the present invention.

[0022] Figure 4 A system for integrating Bluetooth device identification information is shown as yet another exemplary embodiment of the present invention.

[0023] Figure 5 A system for integrating Bluetooth device identification information is shown as yet another exemplary embodiment of the present invention.

[0024] The accompanying drawings illustrate a process for generating the invention according to an exemplary embodiment of the concept, and should not be considered as limiting its scope, as the entire inventive concept may include other equivalent embodiments. Detailed Implementation

[0025] Reference will now be made in detail to embodiments of the general concept of the invention, examples of which are shown in the accompanying drawings, wherein like reference numerals denote like elements. These embodiments are described below in conjunction with the drawings to explain the general concept of the invention. Furthermore, in describing the general concept of the invention, for the sake of brevity, detailed descriptions of known functions or configurations related to the general concept of the invention have been omitted to avoid affecting the clarity of the key points of the invention.

[0026] It should be understood that although the terms “first” and “second” are used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish the elements from one another. Therefore, without departing from the teachings of this disclosure, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element.

[0027] Expressions such as "at least one" modify the entire list of elements when they appear before a list of elements, rather than modifying a single element in the list.

[0028] All terms used herein, including descriptive or technical terms, should be interpreted in accordance with their ordinary meaning as understood by one of ordinary skill in the art. However, these terms may have different meanings depending on the intent of the terminologist, illustrative interpretation, or the emergence of new technologies. Furthermore, some terms may be arbitrarily chosen by the inventor; in such cases, the meaning of these terms will be explained in detail in the detailed description section of this specification. Therefore, the terms used herein should be understood in conjunction with the overall content of this specification and the general definitions of the terms.

[0029] In the following, one or more exemplary embodiments of the general concept of the present invention will be described in detail with reference to the accompanying drawings.

[0030] Exemplary embodiments of the general concept of the present invention relate to a computing system and process for Bluetooth device identification, and more particularly to a computing system and process for Bluetooth device identification utilizing multiple Bluetooth protocols and other Bluetooth-related data.

[0031] Figure 1A block diagram of a Bluetooth Device Identification System (DIS) 100 according to an exemplary embodiment of the present invention is shown. This system integrates various pieces of information from the Bluetooth DTI and determines its DID D118. The DIS 100 according to this exemplary embodiment is a custom-designed DIS 100 that achieves maximum flexibility in Bluetooth transmission / reception by introducing custom hardware, firmware, and software (including reconfigurable hardware such as a Field Programmable Gate Array (FPGA)) and is designed to optimize ideal device identification capabilities. For example, the DIS 100 may include a main processor 102a, a main memory 101a, and multiple Bluetooth chips / processors supporting BR / EDR 106 and BLE 108. In the following figures, it can be assumed that all steps are performed by a process stored in the main memory 101a and run on the main processor 102a. The Bluetooth chip may support both BR / EDR and BLE simultaneously, or only one technology. Furthermore, multiple such chips (or processors) can be present to query numerous DTIs in parallel. Each such chip can also run custom firmware that does not reject data packets sent to it by the main processor 102a that do not conform to the Bluetooth specification, but instead transmits them as is over the air. The custom firmware stored in the Bluetooth chip can also allow the main processor 102a to process data packets that are not normally under its jurisdiction, based on the standard Bluetooth responsibility allocation between the main processor 102a and Bluetooth processors 106, 108. Each Bluetooth chip can be connected to amplifiers 113 (113a-113b) to amplify the transmission power before transmission if the chip itself does not support transmission at the maximum permissible power. Additionally, each Bluetooth chip 106, 108, etc., can be connected to high-gain antennas 114 (114a-114b) to ensure reception of responses from DTIs at greater physical distances. Furthermore, according to this exemplary embodiment, DIS The custom hardware included in 100 can utilize reconfigurable hardware, such as a field-programmable gate array (FPGA) 110. This reconfigurable hardware can be configured as a software-defined radio (SRD) transceiver capable of parallel transmission and reception on all 40 (2MHz wide) BLE RF channels or 80 (1MHz wide) BR / EDR RF channels in the 2.4GHz radio spectrum. Similar to Bluetooth chips 106 and 108, the FPGA 110 can also be connected to amplifier 112c and high-gain antenna 114c. The Bluetooth chip and / or FPGA are intended to act as a transmitter / receiver for wireless transmission with DTI under the command of a main processor 102a.

[0032] Figure 1The exemplary embodiment shown in the example illustrates that the DIS 100 can be based on Figure 2 The exemplary process described above is used to implement this.

[0033] Figure 2 A flow for integrating various information from Bluetooth DTI's DID D118 is illustrated in an exemplary embodiment according to the concept of the present invention. See also Figure 2 In step S202, this exemplary process begins detecting all Bluetooth devices of types such as BLE and BR / EDR located nearby within the area. Step S202 includes the discovery procedure defined in the Bluetooth core specification. However, step S202 may also include any known non-standardized discovery procedure, such as using software-defined radio (SDR) to listen to the Bluetooth wireless channel to discover devices that are not in discoverable mode (Tucker et al., *Blue'sClues: Practical Discovery of Non-Discoverable Bluetooth Devices* (2023)). https: / / ieeexplore.ieee.org / stamp / stamp.jsp?tp=&arnumber=10179358 ).

[0034] For each discovered Bluetooth communication device, DIS 100 attempts to request all possible direct query information in step S204, covering all possible protocol layers. In step S204 of this process, DIS 100 traverses all layers of the BR / EDR and BLE protocol stacks and sends data packets to all discovered DTIs to assist in generating DID D118. The term "protocol stack" as used herein refers to the specific data packets listed in the Bluetooth specification and the programs that use these data packets. A protocol can be layered or "stacked" on top of another protocol if data from a higher-level protocol can be encapsulated in a data unit (PDU) of a lower-level protocol. In the Bluetooth specification, a "protocol stack layer" can be described as a physical channel, physical link, logical transport, logical link, or a specific packet protocol or packet type, such as DM1, SCO, HV1, HV2, HV3, DV, eSCO, EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV5, ACL, DM1, DH1, DM3, DH3, DM5, DH5, AUX1, 2-DH1, 2-DH3, 2-DH5, 3-DH1, 3-DH3, or 3-DH5. It should be noted that this list of protocols or packet types is not exhaustive, because when new packet types and protocols are introduced in updated specifications, systems can be easily updated to use these new packet types and protocols without departing from the spirit and scope of the overall inventive concept.

[0035] Examples of Bluetooth protocol stack layers used to implement BR / EDR can include query scan physical channels, paging scan physical channels, Link Manager Protocol (LMP), and Service Discovery Protocol (SDP). Examples of Bluetooth protocol stack layers used to implement BLE can include various broadcast packet types sent on the broadcast physical channel (e.g., ADV_IND, ADV_SCAN_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, etc.) and link layer (LL) protocols.

[0036] Some protocols, such as the Link Layer Control and Adaptation Protocol (L2CAP) or Security Management Protocol (SMP), are technically shared by the BR / EDR and BLE protocol stacks. However, in practice, only some packet types and functions are shared, while others are limited to BR / EDR or BLE. Similarly, some higher-layer protocols, such as the Attributes Tolerance (ATT) protocol, can technically be used by both BR / EDR and BLE, but in practice, they are primarily adopted through the implementation of BLE.

[0037] Through information gathering, the Bluetooth "profiles" were also analyzed. Profiles, supplementing the Bluetooth core specification, describe the behavior and dependencies between layers and how devices communicate to achieve interoperability. For example, a Bluetooth profile might specify how a bathroom scale transmits and formats information such as weight and body mass index, and which services must be exposed for clients to request this information. This profile definition enables the bathroom scale manufacturer's mobile application or third-party applications to know how to communicate with any scale conforming to that profile. Step S204 utilizes information from the Bluetooth core specification, as well as information from all official Bluetooth Special Interest Group (SIG) profiles. This allows the process in step S204 to delve deeper into the data, finding information such as company IDs defined by the Bluetooth SIG, which can indicate potential device manufacturers or Bluetooth chip manufacturers. It should be noted that step S204 is not limited to using information defined by the official Bluetooth SIG, but can also utilize information on proprietary protocols and data published in public literature, such as patent applications ("Synchronization of multi-channel audio communicated over Bluetooth Low Energy" by Linde et al., US 9,712.266 B2) and public research works ("Discontinued Privacy: Personal Data Leaks in Apple Bluetooth-Low-Energy Continuity Protocols" by Celosia and Cunche (2020)). https: / / petsymposium.org / popets / 2020 / popets-2020-0003.pdf (or our own private research). Vendor proprietary information is imported through the independent protocol and configuration file definitions in data D110 and used as part of the processing in step S204.

[0038] Now refer to Figure 2A Step S204 is described in further detail. Figure 2A It shows that according to Figure 2 The exemplary embodiment of the process shows a sub-process for raw data acquisition, which generates DID D118 for all DTIs by traversing all layers of the BR / EDR and BLE protocol stacks and sending data to all discovered devices.

[0039] See Figure 2A , Figure 2The sub-process of step S204 begins with step S400. Step S400 includes a process of collecting raw information about itself that the DTI may be broadcasting. For example, in BR / EDR, this may include broadcast data (AdvData) in Extended Inquiry Response (EIR) packets as part of the discovery process. For BLE, this may be AdvData in broadcast packets (e.g., ADV_IND, ADV_NONCONN_IND, etc.). AdvData may include Bluetooth standardization information such as a complete or incomplete device name, the device's transmission power, and flags indicating whether the device supports both BR / EDR and BLE. AdvData may also include "Manufacturer-Specific Data" (MSD), which is not specified at all by the Bluetooth SIG, except that MSD type data should begin with a 2-byte company ID assigned by the SIG.

[0040] After passively collectable information is gathered in step S400, step S401 is a process of selecting a known packet type for the target protocol / profile. Step S401 is part of an iterative and proactive process that repeatedly executes each known protocol and Bluetooth profile (whether Bluetooth standardized or vendor-customized). Thus, for example, in step S401, DIS 100 might select the BLE LL protocol in the first iteration, the L2CAP protocol in the second iteration, the SMP protocol in the third iteration, and so on. Then, or in parallel with the BLE protocol, it can select BR / EDR protocols such as LMP, SDP, RFCOMM, etc. Next, it can switch to vendor-specific protocols such as the Apple® LE Audio Protocol (LEAP), the Wireless iPhone Accessory Protocol (WiAP), etc., defined by data D110. Once all protocols have been traversed, the system continues to execute all profile-specific queries, such as the "A / V Remote Control Profile" specified by the Bluetooth SIG, followed by the "Asset Tracking Profile," then the "Basic Audio Profile," and so on. Finally, step S401 will continue to perform the vendor-specific profile query defined by data D110, such as Silicon Labs® Wireless (Over-The-Air, OTA) firmware update.

[0041] In step S402, DIS 100 sends a single, separate packet type for the selected profile or protocol to collect information from the DTI. The exemplary packet types described herein are not exhaustive but are merely examples of information that can be queried and that has not been described in previously known procedures. For instance, suppose that in step S401, DIS 100 has currently selected the L2CAP protocol. In this protocol, there is a data packet type, (L2CAP_LE_CREDIT_BASED_CONNECTION_REQ), which can be sent by DIS 100 to DTI to establish a connection through which other data can be sent. In step 402, DIS sends this data packet, and in step S403, DIS determines whether DTI has responded. If there is no response, for example due to wireless interference or the device being out of range, this is recorded in database D120 in step S404. If a response is received, it is checked in step S405 whether the response is an error message. If it is an error message, it is recorded in database D120 in step S407. If it is not an error message, the contents of the response data packet are stored in database D120 in step S406. For data sent by DIS... The expected non-error response to the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet sent by DIS 100 is the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. The specific fields of this packet may differ between different operating systems, thus providing some potential operating system identification information that helps generate the DTI's DID D118. After storing information about the DTI response (if any), DIS 100 will check in step S408 whether more L2CAP packets need to be sent; if so, it will return to step S402 to continue sending different information queries.

[0042] Another typical example is if, in step S401, DIS 100 has already selected the LMP protocol. In step S402, one of the LMP packets that can be sent is LMP_FEATURES_REQ. This is a feature request that can be sent by DIS 100, and the expected response from the DTI is an LMP_FEATURES_RES response. Both packets have the same format and content, namely a 64-bit bit field. Each bit is either Reserved for Future Us (RFU) or corresponds to a specific feature that a DTI can indicate whether it supports (bit set to 1) or does not support (bit set to 0). The specific combination of bits can indicate a specific Bluetooth chip vendor or Bluetooth chip type. DIS 100 sends LMP_FEATURES_REQ in step S402 and determines whether a response has been received in step S403. If no response is received, no response is recorded in step S404. If a response is received, it is checked in step S405 whether it is an error message. If it is an error message, it is recorded in step S407; otherwise, the actual response data is recorded in step S406. Then, in step S408, DIS 100 checks if there are more LMP packets to send. If so, it returns to step S402 to continue sending different information queries.

[0043] Currently, the Bluetooth 6.0 core specification defines 88 LMP packet types. With very few exceptions, almost all LMP packet requests and responses provide useful information for DTI to create DID D118. It should be noted that other protocols and packet types can also be used to acquire and process data to create DID D118 without departing from the spirit and scope of the general conception of the invention described herein.

[0044] This pattern of using almost any packet type to provide some useful information can be repeated across all other protocol and profile types. Previous systems, such as those mentioned in paragraph

[0007] , were designed only to request all information about the device from sources like GATT and AdvData, and then treat this information separately as DID D118. However, references... Figure 2 The process described in the exemplary embodiment, DIS 100: (1) integrates and synthesizes information from all protocol and profile layers; (2) includes not only the protocol and profile information specified by the Bluetooth SIG, but also vendor-specific non-public information; and (3) collects information from protocol and profile layers (such as LMP, L2CAP, SMP, etc.) that is not inherently intended to be contributed to DID D118 in the manner of GATT or AdvData.

[0045] like Figure 2A As shown, the text data received in step S406 is not only considered part of DID D118. The process also collects information about whether the device did not respond in step S404 or whether it received an erroneous response in step S407. While this is not always as useful as receiving the expected response, it can also be considered part of DID D118 if a particular type of DTI consistently chooses not to respond to certain packets or consistently responds incorrectly to certain packets. Furthermore, since the 2.4 GHz radio frequency spectrum is used not only for Bluetooth but also for other data protocols such as WiFi, data transmission itself is susceptible to interference and potential packet loss. Similarly, the device may also go out of range during data acquisition. Therefore, due to missing data, the DTI response may sometimes only partially conform to DID D118. It is important to understand whether the lack of response is an inherent characteristic of DID D118 or can be explained by packet loss; therefore, due to incomplete matching, the DTI should use a lower confidence level to match DID D118.

[0046] Once a response has been received for each packet type at a given protocol / profile layer (or it has been determined that no response has been received based on a timeout), Figure 2A The process shown allows for a determination in step S408 whether more data packets need to be sent from the protocol / configuration layer. If more data packets need to be sent, then... Figure 2A The process will return to step S402 and send the next data packet type. If no more data packets need to be sent, the process will proceed to step S409. In step S409, it can be determined whether the protocol / configuration layer has behavior that can assist in determining DID D118. If Figure 2A The process ( Figure 2 In step S204, if it is determined in step S409 that the protocol / configuration file does not have known device differentiation behavior, then... Figure 2A The process can check in step S410 whether there are other protocol / configuration layers that need to be queried. If it is determined in step S410 that there are other protocol / configuration layers that need to be queried, then DIS 100 returns to step S401 and repeats the process for that protocol / configuration layer. If not, the active data acquisition is complete.

[0047] if Figure 2A In the process, if it is determined in step S409 that the protocol / configuration file has known device differentiation behavior, then... Figure 2A The process will enter Figure 2B The process shown is as follows: Figure 2B It shows Figure 2The detailed process of step S206 in the process.

[0048] There may be many device-differentiating behaviors within a given protocol layer. Therefore, Figure 2B Step S500 can select and prepare to execute each such action.

[0049] refer to Figure 2B Step S500 can select the device differentiation behavior known at this protocol layer from either data D111 for BLE or data D112 for BR / EDR, depending on the specific protocol layer. Figure 2A The type of analysis performed in step S409. Then, in step S501, the system performs a specific behavioral evaluation of the DTI. The following are some non-exhaustive but representative examples of behavioral evaluation. In paragraph

[0047] , it is described that LMP_FEATURES_REQ is a 64-bit feature bit vector sent by DIS 100, while LMP_FEATURES_RES is the response returned by the DTI. One possible DTI behavior is that the features reported in LMP_FEATURES_RES depend on the features sent by DIS 100 in LMP_FEATURES_REQ. Thus, for example, if all bits of LMP_FEATURES_REQ are set to 0, the DTI may return a different LMP_FEATURES_REQ than when all bits are set to 1, or the DTI may return the exact same LMP_FEATURES_RES regardless of the requested value. Therefore, an exemplary behavioral evaluation that can be performed in step S501 is that DIS 100 intentionally sends a different LMP_FEATURES_REQ value than in step S402, and then records whether LMP_FEATURES_RES is different from the response value recorded in step S404 or S406. For example, in step S506, if the response does not change, DIS 100 can record 0x00 in database D120; if the response changes, it is recorded as 0x01. At the same time, DIS 100 can also record the original value of the actually received LMP_FEATURES_RES in step S505 (or record an error response in step S507, or record a no-response situation in step S503), because the response itself may vary due to factors such as Bluetooth chip manufacturer, device model, firmware version, etc.

[0050] Another example of behavioral analysis involves inferring the implementation of the internal state machines of the software and firmware running on the DTI. The Bluetooth core specification defines several finite state machines designed to describe the states a device might be in. For example, the "Link Controller State Diagram" in the Bluetooth 6.0 specification indicates that a BR / EDR device can be in states such as "Standby," "Synchronous Training," "Synchronous Scan," "Paging," "Paging Scan," "Query," "Query Scan," and "Connected." In all state machine cases, state transitions are responses to specific data packets received by the device or specific data packets selected to be sent based on user input. For example, when a user discovers a nearby Bluetooth device through an interface in the operating system, they can place a BR / EDR device in the "Query Scan" state or a BLE device in the "Scan" state. However, the specific data packets or Host Controller Interface (HCI) sequences that trigger state transitions are not given in the Bluetooth specification state machine diagram. Instead, this information is scattered throughout the specification. Therefore, the present invention concept can construct an idealized state diagram based on all the information in the Bluetooth specification. For example, for a BLE device, DIS 100 might discover that the device is in the "Broadcast" state and collect its broadcast data in step S400. Subsequently, the DIS 100 can send a "CONNECT_IND" packet to initiate a connection with the DTI, which then enters the "connected" state. Once in this state, many new sub-states become available for protocols that do not require authentication or encryption. However, other protocols, such as L2CAP or GATT profiles, may require authentication or encryption before full information can be retrieved. This necessitates enabling the Security Management Protocol (SMP) state machine, in which devices can pair or unpair, bind or unbind, remain unencrypted, unauthenticated with encryption, or authenticated with encryption. Specific messages in SMP, such as "Pairing Request," "Pairing Confirmation," "Pairing Random Number," and "Security Request," can drive transitions in the DTI's internal state machine. However, invalid messages can be sent, or valid messages can be sent in an invalid order, compared to the specified exchange method. This reveals the differences between the state machine implementations of different devices.

[0051] Previous systems, such as those described in paragraph

[0008] , are not well-suited for performing device identification of hundreds or thousands of Bluetooth devices on demand in busy environments. In contrast, Figure 1The DIS 100 of the exemplary embodiment shown implements several related state machine inference mechanisms and adds a key missing component that was previously unimplemented. This is the ability to generate a “minimum discriminative packet sequence” from the differences between two or more state machines. That is, given the complete state machines of 10 very similar and related Bluetooth chips from the same manufacturer, the DIS 100 will further analyze these state machines to find the minimum packet sequence that can distinguish chip 1 from chip 2, etc., by generating a series of responses from the states of all provided devices. The DIS 100 can apply this minimum discriminative packet sequence to thousands of DTIs because it is more efficient than attempting to infer the complete state machine (approximately seconds instead of hours). This unique contribution of the DIS 100 is one of the innovative features that makes the system feasible in behavioral analysis. Furthermore, Figure 1 The exemplary embodiment of DIS 100 can perform state machine analysis not only on the benchmark Bluetooth core specification protocols mentioned in previous studies, but also on Bluetooth profiles and vendor-specific protocols, such as the information contained in data D110 (see Figure 2 ).

[0052] See still Figure 2B In the context of the foregoing example, it is understandable that the nature of the response data can vary significantly. More specifically, the baseline response may receive no reply in step S502 and be stored in step S503, just as with the original data, or an erroneous response may be received in step S504 and stored in step S507. However, there are also more complex cases where data is received and the original data is stored in step S505, and where some behavior-dependent description of the observed device behavior is performed in step S506.

[0053] Step S508 assesses whether there are any further behaviors in the current protocol / configuration layer that require analysis. If so, then... Figure 2B The process will return to step S501 to evaluate the next action; otherwise, the process will return to... Figure 2A Step S410 in the process will determine whether there are additional protocol / configuration layers that need to be analyzed. If so, Figure 2A The process will return to step S401 and repeat the process for that protocol / configuration layer. If it is determined in step S10 that no more protocol / configuration layers need to be analyzed, then... Figure 2A The process shown will complete the active data collection.

[0054] exist Figure 2 Step S206 ( Figure 2B When the process in the middle is completed, execution begins. Figure 2Step S208. Step S208 formats all acquired data for storage in database D120. Additionally, in step S208, any raw data not yet stored in database D120 will be stored in that database. This raw data is then post-processed in step S210 to extract meaningful semantic information. The input to step S210 can be information about protocol D113 defined in the Bluetooth specification, profile D114, and custom vendor-specific data parsers or protocol D115. (See Celosia and Cunche's *Discontinued Privacy: Personal Data Leaks in Apple Bluetooth-Low-EnergyContinuity Protocols* (2020)). https: / / petsymposium.org / popets / 2020 / popets-2020- 0003.pdf The paper provides a public example of a vendor-specific protocol parser. In that work, the authors used reverse engineering to determine the meaning of Apple's "Manufacturer-Specific Data" (MSD) in BLE AdvData. For example, they found it possible to extract information about when only one or both earbuds of Apple® AirPods were in the wearer's ear, rather than in the storage case. However, this older work is outdated, as new message types have been introduced that are not yet described in the public literature. Figure 1 The DIS 100 integrates the latest and unpublished information about vendor proprietary data protocols and information, as well as information that has been found to be related to the system.

[0055] Some vendors, such as Microsoft, have released specifications describing their BLE MSD formatted data. https: / / learn.microsoft.com / en-us / openspecs / windows_protocols / ms-cdp / 77b446d0-8cea- 4821-ad21- fabdf4d9a569 and https: / / learn.microsoft.com / en-us / windows-hardware / design / component-guidelines / bluetooth-swift-pair. However, these specifications may also be outdated and do not match the information observed in actual data packets. For example, at the time of writing, the present invention concepts have observed device names associated with the D118 DID in such data packets that are not described in the Microsoft specifications (https: / / learn.microsoft.com / en-us / openspecs / windows_protocols / ms-cdp / 77b446d0-8cea-4821-ad21-fabdf4d9a569).

[0056] A Bluetooth profile, also known as the device identification profile, can be described in data D114 and contains D11 DID-related information. An example is shown below: (https: / / www.bluetooth.com / specifications / specs / device-id-profile-1-3 / ). This is the profile for the Extended Service Discovery Protocol (SDP) of the BR / EDR system. This profile outlines data fields such as a 2-byte vendor ID, a 2-byte product ID, and a 2-byte version. The vendor ID field can be a company ID assigned by the Bluetooth SIG or the USB SIG (the VendorIDSource field indicates which one is used). This information directly tells us the product manufacturer and may also tell us the Bluetooth chip manufacturer (if the product manufacturer does not override its ID). The version field in the device identification profile has a specific format definition: a field value of 0xJJMN indicates version JJ.MN (JJ - major version number, M - minor version number, N - child version number), for example, version 2.1.3 is represented by the value 0x0213. This information can provide useful supplementary information as part of DID D118.

[0057] However, it should be understood that even profiles not directly related to device identification often contain D118 DID information. This is why all Bluetooth profiles are analyzed to extract D118 DID information, and data D114 contains relevant data collected for this information.

[0058] In step S210, all available semantic information is extracted and processed (see...) Figure 2 After that, this data will be input into the inference engine (step S212), which inference engine... Figure 2C A more detailed description is available in the text.

[0059] See Figure 2C The sub-process steps of the inference engine (step S212) are as follows. Step S600 of this sub-process receives real data D116. This is real and known correct DID D118 information, based on the device's Bluetooth device address (BDADDR). Database D120 uses BDADDR as a unique index for each device it has seen. Therefore, in steps S601 and S602, Figure 2CThe process iterates through all real BDADDRs to check if the device's information is already stored in the local database. Step S603 begins by checking all database tables storing BLE data and determining if data for a given BDADDR exists in these tables. If not, the process proceeds to step S608. However, if relevant information exists in some database tables, all such information is searched in step S604. In step S605, for certain types of data, it may be necessary to remove or mask data that naturally changes over time between the same devices or within the same device. For example, GATT data may contain a unique serial number for the device. When attempting to create a baseline DID D118 for DTI, literal serial numbers should be excluded. However, cases where the serial number can be read via GATT should be included. Similarly, a device may have a name that contains a portion of the BDADDR. Apart from this BDADDR component, the pattern of this name can be common across all the same devices. Therefore, if the BDADDR component is removed (or replaced with a regular expression indicating that the byte pattern must match BDADDR), the name can be used as part of the DID D118. For example, Samsung® headphones might be labeled with the textual name "Galaxy Buds Pro (A42D)". The "Galaxy Buds Pro" part is common across all such Samsung® headphones. However, a more precise match can be given using the regular expression "^Galaxy Buds Pro \\\([A-F0-9]{4}\\\)$", where ^ indicates the beginning of the pattern, $ indicates the end, [A-F0-9]{4} represents four characters consisting of the uppercase character AF and the digits 0-9 (uppercase hexadecimal characters), and the "\" symbol is used to "escape" the "(" and ")" characters so that they are interpreted as "(" and ")" literal characters, rather than the special syntax of the regular expression. This regular expression can then be enhanced with additional data, such as specifying that a match is only made if the four characters in the name that conform to the pattern [A-F0-9]{4} also match the four least significant characters of BDADDR. This results in DID D118, which can be matched with a pair of Samsung® Galaxy Buds Pro earphones with maximum accuracy.

[0060] In step S606, after the mapping in step S606, the complete information existing in database D120 will be added to the speculative fingerprint list D117 for export via the speculative fingerprint. Note that the speculative fingerprint contains almost the same information as DID D118, but it is not exactly the same. The speculative fingerprint is generated from real data, so the confidence level of the data is close to 100% (it should be acknowledged that some natural variations in the data may not have been considered initially, and these data may need to be updated as the understanding of the data deepens). The confidence level of DID D118 is generally lower because it may completely match a single speculative fingerprint, partially match one or more speculative fingerprints, or not match any speculative fingerprints at all.

[0061] See still Figure 2C In step S607, the system determines whether a given BDADDR can be found in any BR / EDR database table. If not found, the system returns to step S602 and processes the next BDADDR. If found, the system proceeds to step S609. It should be noted that there are four types of BDADDRs in BLE, of which only one, the "common" BDADDR, can be used in both BLE and BR / EDR. Therefore, a given BDADDR may appear only in BLE or BR / EDR, or in both database tables.

[0062] In step S609, all records of all information for a given BDADDR are collected. In step S610, as performed in step S605, information is removed or masked as needed. Then, in step S611, the information is added to the inferred speculative fingerprint list D117. At this point, it is known that the BLE information for the BDADDR has either been processed or does not exist, so the process returns to step S602. In step S602, when all BDADDRs in the real data have been processed, the inference engine will stop running, and the system will... Figure 2 Step S214 continues.

[0063] See Figure 2 In step S214, the system has now obtained all the information from step S202 of the currently discoverable devices, all the original information collected in step S204 and post-processed in step S210, all the available behavioral information collected in step S206, and all the speculative fingerprints output in step S212 (at the inference engine) as D117.

[0064] The system is now ready to synthesize this information and create a DID D118 for each DTI. As mentioned earlier, DID D118 may perfectly match a single speculative fingerprint in D117, partially match one or more speculative fingerprints, or not match any speculative fingerprints at all. When DID D118 perfectly matches a single speculative fingerprint, the confidence level is reported based on the stored true confidence level. When the true data is created by the system creator, the confidence level is 100%. However, since true data can be received from external entities through a crowdsourcing system, the confidence level associated with that data may be lower than 100%, depending on factors such as user reputation and the credibility of human evaluation. However, if multiple users submit matching true data, the confidence level will increase.

[0065] When DID D118 matches multiple speculative fingerprints, the confidence level is reported based on a scoring system that may involve statistical techniques such as weighted averages, Bayesian inference, machine learning, etc. When DID D118 does not match any available speculative fingerprint, the system reports the confidence level for each field and the overall DID D118 separately, based on a weighted average of the available data fields. For example, if a complete, minimally distinguishable packet sequence is available, a high confidence level can be provided, confirming that the given Bluetooth chip is the reported chip. Alternatively, a high confidence level is also reported if multiple fields point to the same manufacturer (e.g., GATT and IEEE Organizationally Unique ID (OUI) data associated with the "public" type BDADDR). However, if conflicting fields exist—for example, if the BDADDR points to "Qualcomm®" while the GATT field reports "Bose®"—more complex rules are used to distinguish those fields that more frequently contain the Bluetooth chip manufacturer's company ID. Therefore, step S214 will combine all rules to collect all DID D118 fields and report the overall confidence level of DID D118 and the confidence level of each field.

[0066] like Figure 2 As shown in D118, the final DID D118 can include various types of information. This information can include, but is not limited to: Bluetooth chip manufacturer, specific chip model and version, Bluetooth module... [1] Manufacturer, specific module model, device manufacturer, device model, software and firmware version, device "appearance" (a value pre-specified according to the Bluetooth core specification), the functions and services provided by the device, and the confidence level of the aforementioned information.

[0067] Once the final DID D118 has been created for a given DTI, the created DID D118 is presented to the system's users. This can be performed via a desktop PC graphical user interface, command-line interface, web application interface, mobile application interface, or other computing devices with a graphical user interface. Finally, in step S216, information about DID D118 and any additional data D119 are made available for export to the crowdsourcing system. This can be performed via peer-to-peer transactions between DISs or by sending to a central server that can send and receive DID D118 information.

[0068] Figure 3 A system for integrating Bluetooth device identification information is illustrated in another exemplary embodiment according to the concept of the present invention. The figure shows how to build a system that is more efficient than traditional Bluetooth devices using commercial off-the-shelf (COTS) components. Figure 1 A simpler system, where these components reside within a personal computer (PC). Such a system may have main memory 101b for storing and running software or firmware. The system may have a main processor 102b capable of running the specified software or firmware. The system may have Bluetooth chips, which may differ from the main processor, such as 103b, and may support only one of BLE and BR / EDR or both. The Bluetooth processor must be connected to antenna 104b to enable wireless transmission and reception over greater distances. Bidirectional transmission occurs between the communication channel via Bluetooth wireless signal 115d and antenna 104c of DTI 099b.

[0069] There are many limitations to building a DIS system using COTS systems. Their Bluetooth processors may not support BR / EDR and BLE. Their antenna designs may be optimized for a small physical size rather than for maximizing received signal strength. Their transmission power may be below the maximum allowed by wireless regulations, so their signals may not reach the DTI. The firmware on their Bluetooth chips will likely perform probabilities checks on packets about to be transmitted wirelessly and reject packets that do not conform to the Bluetooth specification. Furthermore, their Bluetooth chips may not be able to tune to multiple wireless frequencies simultaneously, instead hopping between frequencies according to the patterns defined in the Bluetooth specification.

[0070] Figure 4 This figure illustrates yet another exemplary embodiment of a system for integrating Bluetooth device identification information according to the concept of the present invention. The figure shows how to build a system using commercially available off-the-shelf (COTS) components. Figure 1A simpler system, where these components reside in a mobile phone or tablet. Such a system will share many of the limitations described in paragraph

[0069] . This system may have a main memory 101c for storing and running software or firmware. The system may have a main processor 105 capable of running the specified software or firmware. It may have one or more Bluetooth chips that are logically distinct from the main processor but packaged together as a single System on a Chip (SoC). These Bluetooth chips may support only one of BLE and BR / EDR or both. The Bluetooth processor must be connected to antenna 104d to enable it to send and receive wireless transmissions over greater distances. A bidirectional communication channel via Bluetooth wireless signal 115e is established between the communication channel and antenna 104e of DTI 099c.

[0071] Figure 5 A system for integrating Bluetooth device identification information is illustrated in yet another exemplary embodiment according to the concept of the present invention. This system is a customized and highly functional system 100 (such as...). Figure 1 (as shown) and COTS-based systems (such as Figure 3 or Figure 4 The system shown is a hybrid of systems 111 and 100. This hybrid design overcomes the inherent limitations of COTS systems while also benefiting from cost savings from mass production of COTS systems, such as reduced prices for memory, computing, display, and other functions. One system (100 or 111) will have ultimate control, responsible for sending commands to the other system. These commands and the data following their execution can be transmitted via a wired control channel 143 or a wireless control channel 142. The wireless control channel can utilize existing necessary wireless antenna features, such as a 2.4GHz Bluetooth antenna 104f connected to 111 or a Bluetooth antenna 104g connected to 100. However, alternative wireless control channels can also be used to avoid interference with Bluetooth signals. As with other systems, a Bluetooth wireless channel 115f is still required for communication with DTI099d via Bluetooth antenna 104h.

[0072] The general concept of this invention can exist as computer-readable code on a non-transitory computer-readable medium. A non-transitory computer-readable medium can include computer-readable recording media and computer-readable transmission media. A computer-readable recording medium refers to any data storage device capable of storing data, which, after being stored as a program, can be read by a specifically configured computer system and executed as... Figure 1The functions described in DIS 100 shown are as follows. Examples of computer-readable recording media include semiconductor memory, read-only memory (ROM), random access memory (RAM), USB memory, memory cards, Blu-ray discs, CD-ROMs, magnetic tapes, floppy disks, and optical data storage devices. Computer-readable recording media can also be distributed across a specially configured computer system via a network, enabling computer-readable code to be stored and executed in a distributed manner. Computer-readable transmission media can transmit carrier waveforms or signals (e.g., wired or wireless data transmission over the Internet). Furthermore, programmers in the art can readily conceive of functional programs, code, and code segments for implementing the general concept of this invention.

[0073] Although several embodiments of the general concept of the invention have been shown and described, those skilled in the art will understand that changes can be made to these embodiments without departing from the principles and spirit of the general concept of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A Bluetooth Device Identification System (DIS), comprising: Memory, which stores a program containing the steps of its execution process; The database stores data received from the device to be identified (DTI); One or more Bluetooth chip processors, configured with transceivers, are capable of discovering Bluetooth Low Energy (BLE) and Basic Rate / Enhanced Data Rate (BR / EDR) type devices to be identified in the vicinity; A data acquisition channel is connected to each of the one or more Bluetooth chip processors to acquire data received from the discovered device to be identified; The main processor is configured to execute the following process steps: To select a known packet type from the target protocol / profile received from the discovered device to be identified, Send each individual data packet type externally to gather information from discovered devices to be identified, and Receive responses from the device to be identified for each type of sent data packet, including the protocol / configuration layer, and store the received responses in the database; Determine whether the received protocol / configuration layer has behavior that can be used to determine the device identifier (DID); Select a known device differentiation behavior for each of the received protocol / profile layers; Perform behavior evaluation on the device to be identified; and The collected data is formatted for storage in the database.

2. A Bluetooth Device Identification System (DIS), comprising: A memory that stores a program, the program comprising a set of instructions, each of the instructions corresponding to one or more process steps; A database, stored in the memory, is used to store and / or track response data values ​​from Bluetooth Devices to be Identified (DTI), which are generated by sending query packets to one or more DTIs, and if a response packet is received, the actual response packet value is stored. One or more Bluetooth chip processors, configured with transceivers, are capable of discovering Bluetooth Low Energy (BLE) and Basic Rate / Enhanced Data Rate (BR / EDR) type Bluetooth devices to be identified within the area; A data acquisition channel, connected to each of the one or more Bluetooth chip processors, is used to acquire data received from the discovered device to be identified; At least one processor is configured to execute the program, thereby performing the process steps, the process steps including: Select one or more known query packet types from one or more target protocols and / or profiles received from the discovered device to be identified. Send each selected query data packet type to at least one of the discovered devices to generate a response data packet from the discovered devices. Receive one or more response data packets from the device to be identified in response to each of the query packet types, including protocol and / or configuration file information, and store the corresponding response data values ​​in the database; and The collected data is formatted for storage in the database.

3. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, If no response packet is received in response to any given query packet, the database may also store the corresponding no-response packet value.

4. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, The process steps also include: Determine whether any of the received protocol / profile layers has behavior that can be used to determine the device identifier (DID); For each protocol / profile in the received protocol / profile layer that has these behaviors, select a known device-distinguishing behavior; and A behavior evaluation is performed on the device to be identified in order to collect additional response data values.

5. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, If no response packet is received in response to any given query packet, the database may also store the corresponding no-response packet value, and the process steps further include: Determine whether the received protocol / configuration layer has behavior that can be used to determine the device identifier (DID); For each of the received protocol / profile layers, select a known device differentiation behavior; and A behavior evaluation is performed on the device to be identified in order to collect additional response data values.

6. The Bluetooth Device Identification System (DIS) according to claim 5, wherein, The process steps also include: Determine whether the failure to receive a response packet in response to any given query packet is due to packet loss in transit, an error in the response of the given device to be identified, or the lack of a corresponding response value for the given query packet by the given device to be identified; Using the determination result from the previous step as a factor, the known device differentiation behavior of each protocol / profile layer in the received protocol / profile layer is determined; and The known device differentiation behaviors identified in the previous step are used as part of the evaluation of the behavior of the device to be identified in order to collect additional response data values.

7. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, At least one of the query data packet types has multiple possible valid configurations, and the process steps further include: At least one of the query packets is sent with at least two valid configurations to obtain a first response packet having a first response data value and a second response packet having a second response data value; Compare the first response data value and the second response data value to generate a discrimination value, and use the discrimination value as a factor to determine the known device discrimination behavior of each protocol / profile layer in the received protocol / profile layers; and The known device differentiation behaviors identified in the previous step are used as part of the evaluation of the behavior of the device to be identified in order to collect additional response data values.

8. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, The Bluetooth chip processor can also passively detect one or more independent data packets transmitted by Bluetooth devices to be identified within the area. Each independent data packet has an independent data value, and the independent data packet value can be stored in the database.

9. The Bluetooth Device Identification System (DIS) according to claim 4, wherein, The Bluetooth chip processor can also passively detect one or more independent data packets sent by Bluetooth devices to be identified within the area. Each independent data packet has an independent data value. The Bluetooth chip processor can store the independent data packet values ​​in the database, and the independent data packet values ​​can be used as a second factor in determining the known device differentiation behavior of a given device to be identified.

10. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, The Bluetooth DIS can transmit one or more invalid query data packets, which are intentionally configured to not conform to one or more valid Bluetooth protocols and / or Bluetooth standards, and an invalid query response data value is generated by a response data packet sent by a device to be identified in response to the invalid query data packet, which can be stored in the database.

11. The Bluetooth Device Identification System (DIS) according to claim 4, wherein, The Bluetooth device identification system can transmit one or more invalid query packets, which are intentionally configured to not conform to one or more valid Bluetooth protocols and / or Bluetooth standards, and a given device to be identified will generate an invalid query response data value in response to a response packet sent by the invalid query packet. The invalid query response data value can be used as a second factor in determining the known device distinguishing behavior of a given device to be identified.

12. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, At least one of the query data packet types is a state machine query data packet. The state machine query data can affect the complete state machine configuration of a given device to be identified. The complete state machine configuration generated by the given device to be identified in response to receiving the given state machine query data packet can be determined by the device identification system, and a complete state machine response value can be generated. The complete state machine response value can be stored in the database.

13. The Bluetooth Device Identification System (DIS) according to claim 4, wherein, At least one of the query data packet types is a state machine query data packet, which can affect the complete state machine configuration of a given device to be identified. The complete state machine configuration generated by the given device to be identified in response to receiving the given state machine query data packet can be determined by the device identification system, which generates a complete state machine response value. The complete state machine response value can be used as a second factor to determine the known device differentiation behavior of the given device to be identified.

14. The Bluetooth Device Identification System (DIS) according to claim 12, wherein, The device identification system stores or dynamically generates minimum distinguishable data packet sequences (MDPS), which can be used to determine a series of query data packets to distinguish two or more devices to be identified that have a complete state machine configuration within any similarity range.

15. The Bluetooth Device Identification System (DIS) according to claim 13, wherein, The device identification system stores or dynamically generates minimum distinguishable data packet sequences (MDPS), which can be used to determine a series of query data packets to distinguish two or more devices to be identified that have a complete state machine configuration within any similarity range.

16. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, The process steps also include: Determine whether any given device to be identified has transmitted and / or will transmit a response data packet including at least one device-specific actual value, and if so, mask the device-specific actual value when storing the corresponding response data value in the database.

17. The Bluetooth Device Identification System (DIS) according to claim 4, wherein, The process steps also include: Determine whether any given device to be identified has transmitted and / or will transmit a response data packet including at least one device-specific actual value; if so, mask the device-specific actual value when storing the corresponding response data value in the database; and One or more attributes of at least one of the response data values, including masked device-specific actual values, are used as a second factor to determine the known device differentiation behavior of the given device to be identified, wherein the one or more attributes include, but are not limited to, whether any of the response data values ​​contains these masked data values.

18. The Bluetooth Device Identification System (DIS) according to claim 2, wherein, The processor, the memory, and at least one Bluetooth chip processor and / or a field-programmable gate array capable of receiving and interpreting Bluetooth signals are part of a single integrated circuit.

19. The Bluetooth Device Identification System (DIS) according to claim 4, wherein, The processor, the memory, and at least one Bluetooth chip processor and / or a field-programmable gate array capable of receiving and interpreting Bluetooth signals are part of a single integrated circuit.

20. The Bluetooth Device Identification System (DIS) according to claim 12, wherein, At least two of the complete state machine configurations that may exist on a given device to be identified are identical at the edge but have different internal sub-state configurations, so that the given device to be identified can be more accurately identified by determining the actual sub-state configuration of the device in response to a given state machine query.

Images