System and process for Bluetooth device identification

Abstract

This provides a computing system for performing the identification of the type of computing device that communicates via the wireless Bluetooth protocol. [Solution] A computing system including a customized or uncustomized computing system that transmits queries via all protocols described in the Bluetooth specification and vendor-specific protocols, comprising analyzing raw data in combination with behavioral data and ground truth data about known devices in order to establish device identification for any computing device communicating via Bluetooth, and, if ground truth data is unavailable, inferring device identification with relevant confidence levels based on the combined data of all collected data.

Description

Technical Field

[0001] Statement Regarding Federally Sponsored Research and Development Not applicable.

[0002] Copyright Notice Portions of the disclosure herein may contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure in the form it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights. 37 C.F.R. 1.71(d).

[0003] The concepts of the present invention relate to a computing system configured for Bluetooth device identification and a process therefor, and more particularly to a computing system configured for Bluetooth device identification that utilizes a plurality of Bluetooth protocols and other Bluetooth-related data, and a process therefor.

Background Art

[0004] The wireless protocol of Bluetooth for information transmission was defined in 1999. In a subsequent update, Bluetooth Enhanced Data Rate (EDR) was introduced and defined in 2004, and the prior Bluetooth wireless protocol was retroactively named Basic Rate (BR). These protocols are collectively referred to as Bluetooth BR / EDR. The Bluetooth Low Energy protocol was defined in 2009, and many new technologies and protocols that are not compatible with BR / EDR were added. These technologies and protocols are collectively referred to as BLE herein.

[0005] Bluetooth defines the concept of a "profile" as a document that describes "the necessary functions and characteristics of each layer in a Bluetooth system" (Non-Patent Literature 1). It also states that "[a] A profile defines not only vertical interactions between layers, but also peer-to-peer interactions of specific layers between devices." Therefore, Bluetooth profiles can be considered supplementary specifications that go beyond the Bluetooth core specification. This data includes additional data and behaviors that devices can optionally conform to in order to achieve interoperability. Profiles may be publicly available and standardized, or they may be private and vendor-specific. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] U.S. Patent Application Publication No. 2022 / 312507A1 [Patent Document 2] U.S. Patent Application Publication No. 2021 / 058393A1 [Patent Document 3] U.S. Patent Application Publication No. 2020 / 236004A1 [Patent Document 4] U.S. Patent No. 9,712.266B2 [Non-patent literature]

[0007] [Non-Patent Document 1] “Bluetooth Core Specification 6.0”,(2024)https: / / www.bluetooth.com / specifications / specs / core-specification-6-0 / [Non-Patent Document 2] “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) [Non-Patent Document 3] “Fingerprinting Bluetooth-Low-Energy Devices Based on the Generic Attribute Profile”(2021) by Celosia and Cunche (https: / / inria.hal.science / hal-02359914 / file / paper.pdf) [Non-Patent Document 4] “Bluetooth Low Energy Device Identification Based on Link Layer Broadcast Packet Fingerprinting”(2023) by Zhang et al. (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) [Non-Patent Document 5] “Fingerprinting and analysis of Bluetooth devices with automata learning”(2022) by Pferscher and Aichernig (https: / / arxiv.org / pdf / 2211.16074) [Non-Patent Document 6] “Blue's Clues: Practical Discovery of Non-Discoverable Bluetooth Devices” (2023) by Tucker et al. https: / / ieeexplore.ieee.org / stamp / stamp.jsp?tp=&arnumber=10179358 [Non-Patent Document 7] “Discontinued Privacy:Personal Data Leaks in Apple Bluetooth-Low-Energy Continuity Protocols”(2020) by Celosia and Cunche(https: / / petsymposium.org / popets / 2020 / popets-2020-0003.pdf) [Non-Patent Document 8] https: / / learn.microsoft.com / en-us / openspecs / windows_protocols / ms-cdp / 77b446d0-8cea-4821-ad21-fabdf4d9a569 [Non-Patent Document 9] https: / / learn.microsoft.com / en-us / windows-hardware / design / component-guidelines / bluetooth-swift-pair [Non-Patent Document 10] https: / / www.bluetooth.com / specifications / specs / device-id-profile-1-3 / [Overview of the project] [Problems that the invention aims to solve]

[0008] Prior research on identifying Bluetooth devices can be categorized into four types. Category 1 Bluetooth device identification systems attempt to identify a single device over a long period of time, regardless of the device type. A common use case for such systems is to perform access control, granting access to a single authenticated device while preventing access from other devices that may attempt to impersonate the authenticated device. Patent Document 1 Wang et al. and Patent Document 2 Alpert et al. are examples of such systems. Another common use case is to track a single device over a long period of time in order to intentionally make tracking difficult, despite the fact that the Bluetooth primary device address (BDADDR) is designed to change over time. Patent Document 3 Tavares et al. is an example of this. Unlike the systems disclosed herein, these systems are not intended to distinguish and identify, for example, an Apple® iPhone® versus a Samsung® television.

[0009] Category 2 Bluetooth device identification systems attempt to create a fingerprint of a specific device based on its unique wireless characteristics. This category often overlaps with Category 1 (for example, both Patent Document 1 Wang et al. and Patent Document 2 Alpert et al. use these techniques). The system disclosed herein may include such a fingerprinting system as another source of multi-source information as described herein, but this information is not the preferred data source. This is because such information is primarily useful for identifying individual devices (e.g., device #1 versus device #2) over time, but does not contribute much to what type of device it is. In other words, it is not a strong signal to distinguish that device #1 is an iPhone® and device #2 is a television. Physical layer characteristic fingerprinting is more indicative of the Bluetooth chip wireless hardware and is therefore primarily suited to distinguishing that device #1 uses Bluetooth chip vendor #1 and device #2 uses Bluetooth chip vendor #2. However, this is only one aspect of the overall device identification that the system of the present invention described herein achieves.

[0010] Category 3 Bluetooth device identification systems use a single data source to create a Device ID (DID) "fingerprint" of a Device Identified (DTI). Examples include Non-Patent Documents 2 and 3. Both papers use a single data source, the General Attribute Profile (GATT). GATT information includes a hierarchy of "services" and "characteristics." The former paper collects only the hierarchical information and calls it the fingerprint. The latter paper collects information, and even deeper information, by reading specific values ​​from the GATT characteristics. However, both fingerprints completely ignore other information available through other protocols, profiles, and behavioral information. Another example of a single data source system is Non-Patent Document 4, which analyzes only BLE advertising data. Almost all systems described in academic research are single data source systems. These systems collect and synthesize data from a comprehensive set of protocols, profiles, and behaviors, including those not described in any prior related technology.

[0011] Category 4 Bluetooth device identification systems are multi-data-source systems. A single such system is described in Non-Patent Literature 5 of the academic literature. This is also the only system that incorporates behavioral analysis into an attempt at device fingerprinting. This system uses a technique known as "fuzzing" to explore the state machine of the DTI, in an automated manner, where data of several packet types may be randomized and invalidated. This approach has only been applied to a limited number of protocols, such as BLE Link Layer (LL) control packets, Security Manager Protocol (SMP), and Attribute Protocol (ATT). As a result, a state machine is generated that represents the edge as a packet type and the node as the estimated internal state of the target DTI. However, this system takes hours to generate a baseline DID of the DTI. Such a system is not suitable for on-demand device identification for hundreds or thousands of Bluetooth devices present in busy environments. This system cannot create a DID for a device that is not under the control of the system owner and already has ground truth about what kind of device it is. In other words, while it's possible to create two DIDs, the system cannot determine whether one is for an Apple® iPhone® and the other for an Apple® MacBook® unless it is explicitly told which type of device each DID corresponds to. Furthermore, this system did not pursue identifying the least distinguishing sequence within the state machine that could be used to distinguish devices with as few queries as possible, rather than trying every possible permutation. In contrast, our system can create highly reliable and meaningful DIDs even without ground truth. Moreover, our system focuses on behavioral analysis for device identification, is highly performant (completed in seconds), and can scale to a population of thousands of DTIs simultaneously. [Means for solving the problem]

[0012] Therefore, a system that can detect and distinguish different types of devices is needed.

[0013] Also, a system is needed that can start connections to other devices in question in order to detect and distinguish different devices by synthesizing device identification from multi-source acquisition of data from all protocol layers, profiles, and operations.

[0014] There is also a need for a system that can identify the types of devices communicating via the Bluetooth wireless protocol by sending queries via all possible protocols described in the Bluetooth specification and vendor-specific protocols.

[0015] There is also a need for a system that can collect raw and operational information about devices communicating via the Bluetooth wireless protocol and identify the device model, manufacturer, Bluetooth chip in use, Bluetooth chip vendor, software / firmware version, etc.

[0016] There is also a need for a system that can collect raw and operational information about devices communicating via the Bluetooth wireless protocol and determine a specific Bluetooth chip inside these Bluetooth communication devices in order to determine whether the device is vulnerable to wireless exploitation of the Bluetooth firmware.

[0017] There is also a need for a system that not only utilizes the inference mechanism of a state machine but also adds a function to generate a minimum difference packet sequence from the differences between two or more state machines.

[0018] These features and / or other features and the usefulness of the concept of the present invention will become apparent and will be more readily understood from the following description of the embodiments, taken in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0019] [Figure 1] This invention illustrates a system for synthesizing information related to the identification of a Bluetooth device, according to an exemplary embodiment of the concept of the present invention. [Figure 2] This describes a process for synthesizing various types of information relating to the identification information of a Bluetooth device, according to an exemplary embodiment of the concept of the present invention. [Figure 2A] Figure 2 shows a subprocess of raw data collection, which involves iterating through all levels of the BR / EDR and BLE protocol stacks to generate a DID D118 for all Bluetooth communication devices, and sending packets to all discovered devices for identification. [Figure 2B] Figure 2 illustrates an exemplary embodiment of the subprocess of behavioral analysis for all possible protocol stack layers. [Figure 2C] Figure 2 illustrates a subprocess of the inference engine used in the process of synthesizing information about the identification of a Bluetooth device, according to an exemplary embodiment. [Figure 3] This describes a system for synthesizing information related to the identification of a Bluetooth device, according to another exemplary embodiment of the concept of the present invention. [Figure 4] This invention presents yet another exemplary embodiment of the concept of the present invention, a system for synthesizing information related to the identification of a Bluetooth device. [Figure 5] This invention presents yet another exemplary embodiment of the concept of the present invention, a system for synthesizing information related to the identification of a Bluetooth device. [Modes for carrying out the invention]

[0020] The drawings illustrate a process for manufacturing the present invention according to an exemplary embodiment of the concept of the present invention, and the overall concept of the present invention may be recognized as having other equally valid embodiments, and is therefore not to be considered limiting in scope.

[0021] Next, embodiments of the general concept of the present invention will be described in detail, examples of which are shown in the accompanying drawings, and similar reference figures refer to similar elements throughout. The embodiments below will describe the general concept of the present invention with reference to the drawings. In describing the general concept of the present invention, detailed descriptions of related well-known functions or configurations that may reduce the clarity of the essential points of the general concept of the present invention will be omitted in order to keep the detailed description concise.

[0022] In this specification, the terms “first” and “second” are used to describe various elements, but it will be understood that these elements should not be limited by these terms. These terms are used merely to distinguish one element from another. Thus, without departing from the teachings of this disclosure, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element.

[0023] Expressions such as "at least one of ~" modify all elements of an enumeration when they follow an enumeration, but do not modify any individual elements of the enumeration.

[0024] All terms used herein, including descriptive or technical terms, should be construed as having meanings obvious to those skilled in the art. However, in this specification, the meanings of terms may differ due to the intent of the lexicographer, case law, or the emergence of new technologies. In addition, some terms may be arbitrarily selected by the inventors, in which case the meaning of the selected terms will be detailed in the detailed descriptions herein. Therefore, terms used herein should be defined throughout this specification based on the meanings of terms generally defined in conjunction with their descriptions.

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

[0026] An exemplary embodiment of the general concept of the present invention relates to a computing system configured for Bluetooth device identification and a process therefor, and more particularly to a computing system configured for Bluetooth device identification utilizing multiple Bluetooth protocols and other Bluetooth-related data, and a process therefor.

[0027] Figure 1 shows a block diagram of a Bluetooth device identification system (DIS) 100 for synthesizing various different pieces of information about a Bluetooth DTI and determining its DID D118, according to an exemplary embodiment of the concept of the present invention. The DIS 100 in this exemplary embodiment is a custom-designed DIS 100 optimized for Bluetooth transmit / receive functionality with maximum flexibility and optimized for ideal device identification functionality, through the inclusion of custom hardware, firmware, and software, including reconfigurable hardware such as a field-programmable gate array (FPGA). For example, this DIS 100 may include a main processor 102a and main memory 101a, as well as 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 program stored in main memory 101a and running on the main processor 102a. The Bluetooth chip may support both BR / EDR and BLE, or support only a single technology. Furthermore, multiple such chips (or processors) may exist to allow querying many DTIs in parallel. Each of these chips runs customized firmware and can transmit non-Bluetooth compliant packets sent from the main processor 102a wirelessly without rejecting them. The customized firmware on the Bluetooth chip can also allow the main processor 102a to create packets that are not normally within the main processor's authority, in accordance with the standard Bluetooth division of responsibilities between the main processor 102a and Bluetooth processors 106, 108, etc. Each Bluetooth chip can be connected to an amplifier 113 (113a-113b) so that the transmit power is amplified before transmission if the chip itself does not support transmission at maximum allowable power.Furthermore, each Bluetooth chip 106, 108, etc., can be connected to a high-gain antenna 114 (114a-114b) to ensure reliable reception of responses from physically distant DTIs. Additionally, the customized hardware included in the DIS 100 according to this exemplary embodiment can utilize reconfigurable hardware such as a field-programmable gate array FPGA 110. Such reconfigurable hardware can be configured as a software-defined radio (SRD) transceiver capable of transceiver all 40 (2MHz bandwidth) BLE or 80 (1MHz bandwidth) BR / EDR radio frequency (RF) channels in parallel in the 2.4GHz radio spectrum. This FPGA 110, like the Bluetooth chips 106 and 108, can also be connected to amplifiers 112c and high-gain antennas 114c. The purpose of the Bluetooth chips and / or FPGAs is to function as transmitters / receivers for wireless Bluetooth transmission to and from the DTI, as directed by the main processor 102a.

[0028] The DIS 100 shown in the exemplary embodiment of Figure 1 can be carried out according to an exemplary process as described with reference to Figure 2.

[0029] Figure 2 shows a process for synthesizing various types of information relating to the Bluetooth DTI DID D118 according to an exemplary embodiment of the concept of the present invention. Referring to Figure 2, the process in this example begins in step S202 with the discovery of all nearby BLE and BR / EDR type Bluetooth devices within the area. This step S202 includes using discovery procedures defined in the Bluetooth Core Specification. However, this step S202 may also include any known non-standardized discovery procedures, such as listening to Bluetooth wireless channels using a software-defined radio (SDR) to discover devices that are not active in discoverable mode (Non-Patent Literature 6).

[0030] For each detected Bluetooth communication device, in step S204, DIS 100 attempts to request all directly queryable information from all possible layers present. During step S204 of the process, DIS 100 iterates through all levels of the BR / EDR and BLE protocol stacks and sends packets to all detected DTIs to assist in the generation of DID D118. The term “protocol stack” is used herein to refer to specific packet types outlined in the Bluetooth specification and the procedures for using those packets, where one protocol may layer or “stack” another protocol when higher-layer protocol data is encapsulated in lower-layer protocol data units (PDUs). In the Bluetooth specification, the term "protocol stack layer" may refer to physical channels, physical links, logical transports, logical links, or other similar terms, or it may refer to specific packetized protocols or packet types 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, and if new packet types and protocols are introduced in new specifications, this system can simply be updated to use the new packet types and protocols without deviating from the spirit and scope of the overall concept of the present invention.

[0031] Examples of Bluetooth protocol stack layers for BR / EDR implementations include query scan physical channels, page scan physical channels, Link Manager Protocol (LMP), and Service Discovery Protocol (SDP). Examples of Bluetooth protocol stack layers for BLE implementations include advertising packet types transmitted over advertising physical channels (e.g., ADV_IND, ADV_SCAN_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, etc.) and Link Layer (LL) protocols.

[0032] Some protocols, such as the Link Layer Control and Adaptation Protocol (L2CAP) or Security Manager Protocol (SMP), are technically shared across the protocol stacks of both BR / EDR and BLE. However, in practice, only certain packet types and functionalities are shared, while other packets are exclusively available to either BR / EDR or BLE. Similarly, higher-level protocols, such as the Attributes (ATT) protocol, are technically available to both BR / EDR and BLE, but in practice they are primarily adopted through BLE implementations.

[0033] The iteration of target information sources is also performed for Bluetooth "profiles." A profile is supplementary information to the Bluetooth core specification, summarizing the operation and dependencies between layers, as well as the methods of communication between devices to achieve interoperability. For example, a Bluetooth profile may exist for how a weighing scale transmits and formats information such as weight and obesity level, and what services a client must expose to request that information. The definition of this profile allows a weighing scale manufacturer's phone application or a third-party application to know how to communicate with any weighing scale that conforms to the profile. In step S204, information from all official Bluetooth Special Interest Group (SIG) profiles is used in addition to the Bluetooth core specification. In this way, the process in step S204 can dig deeper into the data to find information that may indicate a possible device manufacturer or Bluetooth chip manufacturer, such as a company ID defined by Bluetooth-SIG. It should be noted that step S204 is not limited to official information defined by Bluetooth-SIG, but may also utilize vendor-specific protocol and data information published in public documents such as patent applications ("Synchronization of multi-channel audio communicated over Bluetooth Low Energy" by Linde et al., Patent Document 4), published research (Non-Patent Document 7), or the inventors' own unpublished research. Vendor-specific information is imported via individual protocol and profile definitions provided in data D110 and used as part of the processing in step S204.

[0034] Next, step S204 will be described in more detail with reference to Figure 2A. Figure 2A shows the raw data collection subprocess (step S204) by iterating through all levels of the BR / EDR and BLE protocol stacks and profiles, and sending packets to all discovered devices to generate DID D118 for all DTIs, according to the process shown in the exemplary embodiment of Figure 2.

[0035] Referring to Figure 2A, the subprocess of step S204 in Figure 2 begins at step S400. Step S400 involves the process of collecting raw information that the DTI may be broadcasting about itself. For example, in BR / EDR, this may include AdvData contained within Extended Query Response (EIR) packets as part of the discovery process. In the case of BLE, this may be AdvData within an advertising packet (e.g., ADV_IND, ADV_NONCONN_IND, etc.). AdvData may include information standardized by Bluetooth, such as the complete or incomplete device name, the device's transmit power, and a flag indicating whether the device supports both BR / EDR and BLE simultaneously. AdvData may also include "Manufacturer-Specific Data" (MSD), which is not fully defined by the Bluetooth SIG, with the exception that MSD-type data should begin with a 2-byte SIG-assigned company ID.

[0036] After passively collectible information is gathered in step S400, step S401 performs the process of selecting a known packet type for the protocol / profile of interest. This step S401 is part of an iterative and active process repeated for all known protocols and Bluetooth profiles, whether standardized by Bluetooth or customized by vendors. For example, in step S401, DIS 100 selects 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. After the BLE protocol, or in parallel with the BLE protocol, BR / EDR protocols such as LMP, SDP, and RFCOMM may be selected. Subsequently, as defined by data D110, it may switch to vendor-specific protocols such as Apple® LE Audio Protocol (LEAP) or Wireless iPhone® Accessory Protocol (WiAP). After covering all protocols, profile-specific queries are executed sequentially, for example, the "A / V remote control profile" defined by Bluetooth-SIG, followed by the "asset tracking profile," then the "basic audio profile," and so on. Finally, in step S401, the process moves to vendor-specific profiles, such as Silicon Labs® Over-The-Air (OTA) firmware updates defined in data D110.

[0037] In step S402, each individual packet type of the selected profile or protocol is sent by DIS 100 to collect information from DTI. This specification describes examples of packet types, which are not exhaustive and are intended only to illustrate examples of queryable information not described in previously known processes. As an example, suppose in step S401, DIS 100 has selected the L2CAP protocol. Within this protocol, there is a packet type called L2CAP_LE_CREDIT_BASED_CONNECTION_REQ, which is sent from DIS 100 to DTI to establish a type of connection from which other data can be transmitted. In step 402, DIS sends the packet, and in step S403, DIS determines whether DTI has responded. If no response is received due to reasons such as wireless interference or the device being out of range, this is recorded in database D120 in step S404. If a response is received, in step S405, it is checked whether the response was 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 packet are stored in database D120 in step S406. For the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet sent by DIS 100, the expected non-error response is the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. Certain fields of this packet can distinguish between different operating systems and thus provide some potential OS identification information that contributes to the DTI's DID D118. After storing any information regarding the DTI response, DIS 100 checks in step S408 whether there are any further L2CAP packets to send, and if so, returns to step S402 to continue sending different information queries.

[0038] Another typical example is when, in step S401, DIS 100 has selected the LMP protocol. In step S402, one of the LMP packets that can be sent is LMP_FEATURES_REQ. This is a features request that DIS 100 can send, and the expected response from DTI is the LMP_FEATURES_RES response. Both packets have the same format and content and consist of a 64-bit bit field. Each bit corresponds to a specified feature that can indicate whether it is Reserved for Future Use (RFU) or whether DTI supports it (the bit is set to 1) or not (the bit is set to 0). The exact combination of bits can indicate a specific Bluetooth chip vendor or both. DIS 100 sends LMP_FEATURES_REQ in step S402, determines in step S403 whether it received a response, and if so, records the lack of a response in step S404. If a response is received, step S405 checks whether it is an error message. If it is an error, it is recorded in step S407; otherwise, the actual response data is recorded in step S406. Then, in step S408, it is checked whether there are still LMP packets to send. If there are, the process returns to step S402 and continues sending different information queries.

[0039] Currently, the Bluetooth 6.0 core specification defines 88 LMP packet types. With very few exceptions, almost all LMP packet requests and responses can provide useful information for creating the DID D118 of the DTI. It should be noted that other protocols and packet types can be obtained and processed for the purpose of creating the DID D118 described herein, without departing from the spirit and scope of the overall concept of the invention, as described herein.

[0040] This pattern of using almost every packet type to provide some useful information is repeated for all other protocol and profile types. Previous systems, such as those cited in paragraph

[0007] , are designed to simply request all information about the device from sources such as GATT and AdvData and to consider only this information as DID D118. However, in the process described with reference to the exemplary embodiment in Figure 2, DIS 100 1) captures and synthesizes information across all protocol and profile layers, 2) captures not only protocol and profile information defined by Bluetooth-SIG but also vendor-specific confidential information, and 3) collects information from protocol and profile layers that are not originally intended to contribute to DID D118 in the form of GATT or AdvData (such as LMP, L2CAP, SMP, etc.).

[0041] As shown in Figure 2A, the literal received data in step S406 is not the only thing considered as part of DID D118. This process also collects information regarding whether no response was received from the device in step S404, or whether an error response was received in step S407. While not always as useful as receiving the expected response, it is possible that certain types of DTIs may always choose not to respond to some packets, or always respond with errors to some packets, just as is part of DID D118. Furthermore, because other data protocols, such as WiFi, as well as Bluetooth, use the 2.4GHz RF spectrum, data transmission is inherently susceptible to interference and packet loss is possible. Similarly, the device may move out of range while attempting data collection. Therefore, due to data loss, the DTI response may sometimes only partially match DID D118. It is necessary to know whether the lack of response is an inherent characteristic of DID D118, or can be explained by packet loss, and therefore the DTI should match a less reliable DID D118 due to the incomplete match.

[0042] When each packet type of a given protocol / profile layer receives a response (or determines that no response has been received based on a timeout), the process shown in Figure 2A can determine in step S408 whether there are any more packets to send from this protocol / profile layer. If there are more packets to send, the process in Figure 2A returns to step S402 and sends the next packet type. If there are no more packets to send, the process proceeds to step S409, where it can determine whether this protocol / profile layer has any behaviors that can be examined to help determine DID D118. If the process in Figure 2A (step S204 in Figure 2) determines in step S409 that the protocol / profile does not have any known device-distinguishing behaviors, the process in Figure 2A can check in step S410 whether there are any other protocol / profile layers to query. If it is determined in step S410 that there are other protocol / profile layers to query, DIS 100 returns to step S401 and repeats the process for that protocol / profile layer. Otherwise, active data collection is completed.

[0043] If the process in Figure 2A determines in step S409 that the protocol / profile has known device-specific behavior, the process in Figure 2A proceeds to the process shown in Figure 2B, which shows the detailed process of step S206 in Figure 2.

[0044] A given protocol layer may have many device-specific operations. Therefore, step S500 in Figure 2B can be used to select and prepare to perform each of these operations.

[0045] Referring to Figure 2B, step S500 can select a known device-distinguishing operation for this protocol layer from the BLE data D111 or the BR / EDR data D112, depending on the type of analysis performed in step S409 in Figure 2A. Step S501 can perform a specific behavioral evaluation of the DTI. The following is a typical example of a non-extensive behavioral evaluation. Paragraph

[0047] states that LMP_FEATURES_REQ is a 64-bit feature bit vector sent by DIS 100, and LMP_FEATURES_RES is the response sent back by the DTI. Possible operations of the DTI are when the features reported in LMP_FEATURES_RES depend on the features sent by DIS 100 in LMP_FEATURES_REQ. Therefore, for example, if all bits of LMP_FEATURES_REQ are set to 0, DTI may send a different value to LMP_FEATURES_RES than if all bits of LMP_FEATURES_REQ were set to 1. Alternatively, DTI may always send back the exact same LMP_FEATURES_RES regardless of the value of LMP_FEATURES_REQ. Thus, one exemplary operational evaluation that may be performed in step S501 is that DIS 100 may explicitly send a different value to LMP_FEATURES_REQ than the one sent in step S402, and then record an operational response indicating whether LMP_FEATURES_RES is different from the one recorded in step S404 or S406. For example, DIS 100 in step S506 may record 0x00 in database D120 for a response with no difference, and 0x01 for a response with a difference. DIS 100 can also store the raw value received for LMP_FEATURES_RES in step S505 (or the error in step S507, or the lack of a response in step S503).This is because the response itself can vary depending on the Bluetooth chip, the device model, the specific firmware version, or other factors.

[0046] Another example of behavioral analysis concerns inferences about the internal state machine implementation of software and firmware running on the DTI. The Bluetooth Core Specification defines numerous finite state machines to describe the states a device can be in. For example, the "State diagram of Link Controller" in the Bluetooth 6.0 specification shows that a BR / EDR device can be in the states "Standby," "Synchronization Train," "Synchronization Scan," "Page," "Page Scan," "Inquiry," "Inquiry Scan," and "Connection." In all state machines, state transitions respond to specific packets the device receives or specific packets the device chooses to send based on user input. For example, a user using an interface within the operating system to discover nearby Bluetooth devices can put a BR / EDR device into the "Inquiry Scan" state or a BLE device into the "Scanning" state. However, the state machine diagrams in the Bluetooth specification do not show the exact packet sequences or host controller interface (HCI) sequences that cause transitions between states. Rather, that information is scattered throughout this specification. Thus, the concepts of the present invention can construct idealized state diagrams based on the sum of the information in the Bluetooth specification. For example, in the case of a BLE device, it may be detected by DIS 100 because the device is in the "Advertising" state and its advertisement was collected in step S400. However, DIS 100 can then send a "CONNECT_IND" packet to initiate a connection to DTI, and DTI then enters the "Connection" state. Once in this state, many new substates become available for protocols that do not require authentication or encryption. However, other protocols, such as L2CAP or GATT profiles, may need to establish authentication or encryption before they can query for complete information.This requires the use of a Security Manager Protocol (SMP) state machine, where devices can perform actions such as pairing or unpairing, bonding or unbinding, unencrypted, unauthenticated encrypted, or authenticated encrypted. Certain messages within SMP, such as "Pairing Request," "Pairing Confirmation," "Pairing Random," and "Security Request," can drive a DTI through its internal state machine. However, invalid messages may be sent, or valid messages may be sent in an invalid order compared to how the exchange is specified. This can reveal to another device how a particular device's state machine is implemented.

[0047] Prior systems, such as those described in paragraph

[0008] , are not suitable for performing on-demand device identification for hundreds or thousands of Bluetooth devices present in busy environments. In contrast, the DIS 100 in the exemplary embodiment shown in Figure 1 implements several relevant state machine inference mechanisms but also adds a key missing component that has not been previously implemented: the ability to generate a “minimum difference packet sequence” from the differences of two or more state machines. That is, given complete state machines for 10 very similar related Bluetooth chips from the same vendor, the DIS 100 performs further analysis of the state machines to find the minimum packet sequence that passes through the states of all the provided devices and yields a set of responses that can be used to distinguish chip 1 against chip 2, etc. Because this minimum difference sequence is far more time-efficient (about seconds, rather than hours) than inferring the complete state machine, the DIS 100 can be used with thousands of DTIs. This unique contribution by the DIS 100 is one of the novel features that makes such systems practical for behavioral analysis. Additionally, the DIS 100 in the exemplary embodiment shown in Figure 1 can perform state machine analysis not only on baseline Bluetooth core specification protocols as in previous studies, but also on vendor-specific protocols such as Bluetooth profiles and information contained in data D110 (see Figure 2).

[0048] Furthermore, referring to Figure 2B, it can be understood from the context of the previous example that the nature of the response data can change significantly. Specifically, as with the raw data case, the baseline response may not receive any reply in step S502 and store that fact in step S503, or an error may be received in step S504 and store that fact in step S507. However, there are also more complex cases where data is received in step S505 and the raw data is stored, and the observed device operation is described in some operation-dependent way in step S506.

[0049] Step S508 evaluates whether there are any further operations to analyze within the current protocol / profile layer. If so, the process in Figure 2B returns to step S501 to evaluate the next operation; otherwise, the process returns to step S410 in Figure 2A, where it is determined whether there are any further protocol / profile layers to analyze. If so, the process in Figure 2a returns to step S401 and repeats the process for that protocol / profile layer. If it is determined in step S10 that there are no more protocol / profile layers to analyze, the process shown in Figure 2A completes active data collection.

[0050] Once step S206 in Figure 2 (the process in Figure 2B) is completed, step S208 in Figure 2 begins. Step S208 formats all collected data for storage in database D120. Step S208 also stores any raw data that has not yet been stored in database D120. This raw data is then post-processed using step S210 to extract meaningful semantic information. Input to step S210 can be information regarding protocol D113, profile D114, and a custom-created vendor-specific data parser or protocol D115 as defined in the Bluetooth specification. A published example of what a vendor-specific protocol parser might look like is shown in Non-Patent Literature 7. In this study, the authors reverse-engineered and deciphered the meaning of Apple's "Manufacturer-Specific Data" (MSD) contained in BLE AdvData. For example, they found that they could extract messages when one or both earbuds of Apple® AirPods are in a person's ear rather than in the charging case. However, this past research is outdated, and new message types have been introduced that are not documented in open literature. DIS 100 in Figure 1 incorporates such up-to-date and confidential information regarding vendor-specific data protocols and information that has been found to be relevant to this system.

[0051] Some vendors, such as Microsoft, publish specifications describing BLE MSD format data (Non-Patent Documents 8 and 9). However, these specifications may become outdated and no longer match the information observed in actual packets. For example, the concept of the present invention was based on observing the D118 DID-related device name in such packets, which is not described in the Microsoft specification (Non-Patent Document 8) at the time of writing.

[0052] An example of a Bluetooth profile containing D118 DID-related information that can be described in data D114 is the device identification profile (Non-Patent Literature 10). This is a profile that extends the Service Discovery Protocol (SDP) for BR / EDR systems. The profile outlines data fields such as a 2-byte VendorID, a 2-byte ProductID, and a 2-byte Version. The VendorID field can be either a company ID assigned by the Bluetooth-SIG or a company ID assigned by the USB-SIG (the VendorIDSource field indicates which). This type of information can directly identify the product vendor, and possibly the Bluetooth chip vendor (if the product vendor does not override the ID). The Version field of the device identification profile has a specific format defined as "the value of the field is 0xJJMN for version JJ.MN (JJ - major version number, M - minor version number, N - sub-minor 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.

[0053] However, it should be understood that D118 DID-related information is often included in profiles that are not directly related to device identification. For this reason, all Bluetooth profiles are analyzed for D118 DID-related information, and data D114 incorporates collected information targeting such information.

[0054] After all available semantic information has been extracted and processed in step S210 (see Figure 2), the data is fed into an inference engine, which is described in more detail with reference to Figure 2C (step S212).

[0055] Referring to Figure 2C, the subprocess steps of the inference engine (step S212) are as follows: Step S600 of this subprocess takes in ground truth data D116, which is information about the known correct DID D118 of the device based on the Bluetooth device address (BDADDR). Database D120 uses BDADDR as a unique index for each recognized device. Thus, in steps S601 and S602, the process in Figure 2C iterates through all ground truth BDADDRs and checks whether information about that device is already stored in the local database. Step S603 begins by examining all database tables that store BLE data and determines whether there is data for a given BDADDR. If not, the process proceeds to step S608. However, if there is information in any of the tables, step S604 examines all such information. In step S605, it may be necessary to remove or mask out certain types of data that are known to change naturally over time between two identical devices or between identical devices. For example, GATT data may contain a device-specific serial number. When attempting to create a DTI baseline DID D118, literal serial numbers should be excluded. However, the fact that a GATT-readable serial number exists should be included. Similarly, a device may have a name that includes part of the BDADDR. The pattern of the name excluding this BDADDR component may be common to 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), this name can function as part of the DID D118. For example, Samsung® headphones may have a literal name of "Galaxy Buds Pro (A42D)". The "Galaxy Buds Pro" part is common to all such Samsung® headphones.However, a more precise match is given by the regular expression "^Galaxy Buds Pro ￥￥￥([A-F0-9]{4}￥￥￥)$", where ^ indicates the beginning of the pattern and $ indicates the end of the pattern, [A-F0-9]{4} refers to four characters from the set of uppercase A-F and digits 0-9 (uppercase hex characters), and the "￥" character is used to "escape" the "(" and ")" characters so that they are interpreted as literal "(" and ")" characters rather than being interpreted according to special regular expression rules. This regular expression can be extended with additional metadata indicating that a match is only made if the four characters that match the [A-F0-9]{4} pattern in the device name also match the last four characters of BDADDR. This results in a DID D118 with maximum precision to verify that the device is a pair of Samsung® Galaxy Buds Pro headphones.

[0056] In step S606, the complete information present in database D120 after mapping in step S606 is exported by adding this estimated fingerprint to the estimated fingerprint list D117. Note that the estimated fingerprint contains almost the same information as DID D118, but they are not the same. The estimated fingerprint is data generated from ground truth data, and therefore the confidence level of the data is almost 100% (however, some naturally changing data may not be considered initially, and updates may be necessary as the understanding of the data progresses). DID D118 is generally less reliable because it may perfectly match one estimated fingerprint, partially match one or more estimated fingerprints, or the estimated fingerprints may not match at all.

[0057] Referring again to Figure 2C, in step S607, the system determines whether a given BDADDR exists in any of the BR / EDR database tables. If not, the system returns to step S602 and processes the next BDADDR. If it does exist, the system proceeds to step S609. It should be noted that there are four types of BDADDR in BLE, and only one of them, the "public" BDADDR, can be used in both BLE and BR / EDR. Therefore, a given BDADDR may appear only in BLE, only in BR / EDR, or in both database tables.

[0058] In step S609, all records of all information for a given BDADDR are collected. In step S610, information is deleted or masked as necessary, as was done in step S605. Then in step S611, the information is added to the estimated estimated fingerprint list D117. At this point, since it is known that information from BLE for this BDADDR has already been processed or does not exist, the process returns to step S602. In step S602, having processed all BDADDRs of ground truth data, the process stops the inference engine, and the system continues from step S214 in Figure 2.

[0059] Referring to Figure 2, in step S214, the system can utilize all the information about all currently detectable devices from step S202, all available raw information collected in step S204 and post-processed in step S210, all available behavioral information collected in step S206, and all available estimated fingerprints from step S212 output as D117 (by the inference engine).

[0060] The system is ready to synthesize this information to create a DID D118 for each DTI. As mentioned earlier, a DID D118 may perfectly match one estimated fingerprint in D117, partially match one or more estimated fingerprints, or not match any estimated fingerprints at all. If a DID D118 perfectly matches one estimated fingerprint, the confidence level is reported according to the stored ground truth confidence level. If the ground truth data was created by the system creator, the confidence level will be 100%. However, since ground truth data can be received from external entities via a crowdsourcing system, the confidence level associated with that data may be rated below 100%, based on user reputation, manual ratings indicating trustworthiness, etc. However, if multiple users submit matching ground truth data, the confidence level may increase.

[0061] If DID D118 partially matches multiple estimated fingerprints, confidence is reported according to a scoring system that may include statistical techniques such as weighted averages, Bayesian inference, and machine learning. If DID D118 does not match any of the available estimated fingerprints, the system reports confidence for each field and for DID D118 as a whole, based on the weighting of the individual data available. For example, if all data from the minimum difference packet series is available, a high confidence can be obtained that a given Bluetooth chip is the reported chip. Or, if there are multiple fields indicating the same manufacturer (e.g., both GATT and IEEE Organization-Specific ID (OUI) data related to a BDADDR of type "Public"), this will also be reported with high confidence. However, if there are conflicting fields, for example, if the BDADDR indicates the company "Qualcomm®" but the GATT field reports the company "Bose®", more complex rules are used to distinguish the field that is known to more frequently contain the Bluetooth chip manufacturer company ID. Therefore, step S214 incorporates all rules regarding the collection of all DID D118 fields, as well as the reporting of confidence levels for the DID D118 as a whole and for individual fields.

[0062] As shown in Figure 2, D118, there are many types of information that may ultimately be incorporated into the final DID D118 of the DTI. These may include, but are not limited to, the Bluetooth chip manufacturer, specific chip model and revision, Bluetooth module manufacturer, specific module model, device manufacturer, device model, software and firmware versions, the device's "appearance" (as specified by the Bluetooth Core Specification), the functions and services provided by the device, and the confidence level for the aforementioned assessment.

[0063] Once the final DID D118 is created for a given DTI, this created DID D118 is made available to the system's users. This can be done via a desktop PC's graphical user interface, command line interface, web application interface, telephone application interface, or other computing device with a graphical user interface. Finally, in step S216, information about the DID D118 and any additional data D119 is made available for export to a crowdsourcing system. This can be done via peer-to-peer transactions between DISs, or by sending the DID D118 information to a centralized server capable of receiving and sending it.

[0064] Figure 3 shows a system for synthesizing information related to the identification of a Bluetooth device, according to another exemplary embodiment of the concept of the present invention. This figure shows how a less capable system than that in Figure 1 can be built using commercially available (COTS) components, such as those found in a personal computer (PC). Such a system may have main memory 101b that can store and run software or firmware. It may also have a main processor 102b that can run the specified software or firmware. It is also possible to have a separate Bluetooth chip, such as 103b, which may support either BLE or BR / EDR, or both. The Bluetooth processor needs to be connected to an antenna 104b to enable longer-range wireless transmission. The communication channel by the Bluetooth wireless signal 115d is between the antenna 104c of DTI 099b.

[0065] COTS systems have many limitations when building a DIS. Their Bluetooth processors may not support both BR / EDR and BLE. Antenna designs may be optimized for minimizing physical footprint rather than maximizing received signal. The signal may not reach the DTI because it may transmit at a lower power than the maximum power allowed by wireless regulations. Firmware on the Bluetooth chip will likely perform integrity checks on packets transmitted wirelessly and reject packets that do not comply with the Bluetooth specification. Also, the Bluetooth chip probably cannot tune to multiple radio frequencies simultaneously and will likely hop between frequencies in a pattern defined by the Bluetooth specification.

[0066] Figure 4 shows a system for synthesizing information about Bluetooth device identification information according to yet another exemplary embodiment of the concept of the present invention. This figure shows how a less capable system than that in Figure 1 can be built using commercially available (COTS) components, such as those found in a mobile phone or tablet. Such a system would share many of the limitations described in paragraph

[0069] . Such a system may have main memory 101c on which software or firmware can be stored and run. It may also have a main processor 105 on which specified software or firmware can be run. It may also have a Bluetooth chip, or a chip logically different from the main processor, but they are packaged as a single different system-on-a-chip (SoC). These Bluetooth chips may support only BLE and BR / EDR, or both. The Bluetooth processor needs to be connected to antenna 104d to enable longer-range wireless transmission. The communication channel by the Bluetooth wireless signal 115e is between the antenna 104e and DTI 099c.

[0067] Figure 5 shows a system for synthesizing information related to the identification of a Bluetooth device, according to yet another exemplary embodiment of the concept of the present invention. This system represents a hybrid of the customized, maximum-capability system described in 100 of Figure 1 and a COTS-based system such as 111 shown in Figure 3 or 4. By hybridizing these different designs, it is possible to overcome the limitations inherent in COTS systems while benefiting from the cost reductions associated with mass-produced COTS systems, such as the lower prices of memory, compute, display, and other functions. One system (100 or 111) has ultimate control and is responsible for sending commands to the other system. These commands and the data returned after command execution may be transmitted via a wired control channel 143 or a wireless control channel 142. The wireless control channel can opportunistically utilize existing required wireless antenna functions, such as a 2.4GHz Bluetooth antenna 104f connected to 111, or 104g connected to 100. However, an alternative wireless control channel may also be used so as not to conflict with the Bluetooth signal. As with other systems, the Bluetooth wireless channel 115f remains necessary for communication with the DTI 099d via the Bluetooth antenna 104h for information gathering.

[0068] The general concept of the present invention can be embodied as computer-readable code on a non-temporary computer-readable medium. The non-temporary computer-readable medium may include a computer-readable recording medium and a computer-readable transmission medium. The computer-readable recording medium is any data storage device capable of storing data as a program that can subsequently be read by a specifically configured computer system capable of performing functions such as those described with reference to DIS 100, as shown in Figure 1. 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 tape, floppy disks, and optical data storage devices. The computer-readable recording media may also be distributed across a specially configured network-connected computer system so that the computer-readable code is stored and executed in a distributed manner. The computer-readable transmission medium can transmit carrier waves or signals (e.g., wired or wireless data transmission over the Internet). Furthermore, functional programs, code, and code segments for realizing the general concept of the present invention can be readily interpreted by a skilled programmer in the art to which the general concept of the present invention belongs.

[0069] While several embodiments of the general concept of the present invention have been shown and described, those skilled in the art will understand that modifications to these embodiments can be made without departing from the principles and spirit of the general concept of the present invention, the scope of which is defined in the appended claims and equivalents. [Explanation of Symbols]

[0070] 101a, 101b, 101c: Main memory (memory) 102a, 102b: Main processor 106: Bluetooth BR / EDR processor (Bluetooth chip processor) 108: Bluetooth Low Energy Processor (Bluetooth Chip Processor) 115a, 115f: Bluetooth data acquisition channels (acquisition channels) DIS: Bluetooth Device Identification System DTI: Identified Device D120: Database

Claims

1. A Bluetooth device identification system (DIS), Memory that stores the program that executes the process steps, A database that stores data received from DTI, One or more Bluetooth chip processors comprising transceivers that discover nearby Bluetooth communication devices in order to identify Low Power (BLE) and Basic Rate / Extended High Data Rate (BR / EDR) type Identifiable Target Devices (DTIs) within an area, To collect data received from the discovered DTI, an acquisition channel is connected to each of the one or more Bluetooth chip processors, A main processor configured to execute a process step, wherein the process step is Select a known packet type of the target protocol / profile received from the discovered DTI, To collect information from the discovered DTI, each individual packet type is transmitted externally, The DTI receives a response from each of the transmitted packet types, including the protocol / profile layer, and stores the received response in a database. The received protocol / profile layer is to determine whether it has any operations that can be used to determine the Device Identifier (DID), For each of the received protocol / profile layers, select a known device differentiation behavior. To perform the operational evaluation of the aforementioned DTI, To store the collected data in the aforementioned database, the collected data is formatted, The main processor, A Bluetooth device identification system (DIS) is provided.

2. A Bluetooth device identification system (DIS), A memory for storing a program, wherein the program includes a set of instructions, each of which corresponds to one or more process steps, A database stored in memory for storing and / or tracking response data values ​​from Bluetooth devices (DTIs) to be identified, wherein the response data values ​​are generated by sending query packets to one or more DTIs, and the database stores the actual response packet values ​​when response packets are received. One or more Bluetooth chip processors comprising transceivers that discover low-power (BLE) and / or basic-rate / high-data-rate (BR / EDR) type Bluetooth DTIs within the area, To collect data received from the discovered DTI, an acquisition channel is connected to each of the one or more Bluetooth chip processors, A processor configured to execute the program and the process steps thereof, wherein the process steps are Selecting one or more known query packet types of one or more target protocols and / or profiles received from the discovered DTI, To generate a response packet from the discovered DTI, each selected individual query packet type is sent to at least one of the discovered DTIs. In response to each of the aforementioned query packet types, one or more response packets containing protocol and / or profile information are received from the DTI, and the corresponding response data values ​​are stored in the database. A processor, which includes formatting the collected data for storage in the aforementioned database, A Bluetooth device identification system (DIS) is provided.

3. Bluetooth device identification system (DIS) according to claim 2, wherein the database can also store a corresponding non-response packet value if no response packet is received in response to any given query packet.

4. The aforementioned process step is The process involves determining whether any of the received protocol / profile layers have an operation that can be used to determine the Device Identifier (DID), For each of the received protocol / profile layers that exhibits such behavior, select a known device differentiation behavior. This further includes performing an operational evaluation of the DTI in order to collect additional response data values. Bluetooth device identification system (DIS) according to claim 2.

5. If the database does not receive a response packet in response to any given query packet, it may also store the corresponding non-response packet value, and the process step is: The received protocol / profile layer is to determine whether it has any operations that can be used to determine the Device Identifier (DID), For each of the received protocol / profile layers, select a known device differentiation behavior. This further includes performing an operational evaluation of the DTI in order to collect additional response data values. Bluetooth device identification system (DIS) according to claim 2.

6. The aforementioned process step is To determine whether it is highly likely that a response packet in response to a given query packet was not received due to packet loss during transmission, a response error by a given DTI, or the given DTI not having a corresponding response value for a given query packet; For each of the received protocol / profile layers, the determination from the previous step is used as a factor for determining known device differentiation behavior, To collect additional response data values, further include including the known device differentiation behavior determined in the previous step as part of the operational evaluation of the DTI, Bluetooth device identification system (DIS) according to claim 5.

7. At least one of the query packet types has a plurality of possible valid configurations, and the process step is In order to obtain a first response packet having a first response data value and a second response packet having a second response data value, at least one of the query packets is sent in at least two valid configurations, To generate a difference value, the first response data value and the second response data value are compared, and the difference value is used as a factor in determining known device differentiation behavior for each of the received protocol / profile layers. To collect additional response data values, further include including the known device differentiation behavior determined in the previous step as part of the operational evaluation of the DTI, Bluetooth device identification system (DIS) according to claim 2.

8. Bluetooth device identification system (DIS) according to claim 2, wherein the Bluetooth chip processor can also passively detect one or more independent packets transmitted by Bluetooth DTI within the area, each independent packet having an independent data value, and the independent data packet values ​​can be stored in the database.

9. Bluetooth device identification system (DIS) according to claim 4, wherein the Bluetooth chip processor can also passively detect one or more independent packets transmitted by Bluetooth DTIs within the area, each independent packet having 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 known device differentiation behavior for a given DTI.

10. Bluetooth device identification system (DIS) according to claim 2, wherein the Bluetooth DIS can transmit one or more bad query packets, the bad query packets are intentionally configured to be non-compliant with one or more different valid Bluetooth protocols and / or Bluetooth standards, and response packets sent by a given DTI in response to a bad query packet generate bad query response data values ​​that can be stored in the database.

11. Bluetooth device identification system (DIS) according to claim 4, wherein the Bluetooth DIS can transmit one or more bad query packets, the bad query packets are intentionally configured to be non-compliant with one or more otherwise valid Bluetooth protocols and / or Bluetooth standards, and a response packet sent by a given DTI in response to a bad query packet generates a bad query response data value which can be used as a second factor in determining known device differentiation behavior of a given DTI.

12. Bluetooth device identification system (DIS) according to claim 2, wherein at least one of the query packet types is a state machine query packet that can affect the full state machine configuration of a given DTI, the full state machine configuration of the given DTI in response to the receipt of the given state machine query packet can be determined by the DIS to generate a full state machine response value, and the full state machine response value can be stored in the database.

13. Bluetooth device identification system (DIS) according to claim 4, wherein at least one of the query packet types is a state machine query packet that can affect the full state machine configuration of a given DTI, the full state machine configuration of the given DTI in response to the receipt of the given state machine query packet can be determined by the DIS to generate a full state machine response value, and the full state machine response value can be used as a second factor in determining known device differentiation behavior for the given DTI.

14. Bluetooth device identification system (DIS) according to claim 12, wherein the DIS stores or dynamically generates a sequence of query packets that can be used to determine a sequence of query packets that differentiate two or more DTIs having full state machine configurations within an arbitrary similarity range.

15. Bluetooth device identification system (DIS) according to claim 13, wherein the DIS stores or dynamically generates a sequence of query packets (MDPS) which can be used to determine a sequence of query packets that differentiate two or more DTIs having full state machine configurations within an arbitrary similarity range.

16. The aforementioned process step is The method further includes determining whether any given DTI has and / or transmits (has transmitted) any response packet containing at least one device-specific measured value, and if so, masking out the device-specific measured value when the corresponding response data value is stored in the database. Bluetooth device identification system (DIS) according to claim 2.

17. The aforementioned process step is Determine whether any given DTI has and / or transmits (has transmitted) any response packet containing at least one device-specific measured value, and if so, mask out the device-specific measured value when the corresponding response data value is stored in the database. A second factor in determining known device differentiation behavior for a given DTI is to use at least one characteristic of the response data values ​​that include any masked-out device-specific measured values, including, but not limited to, whether any of the response data values ​​include any masked-out data values. Bluetooth device identification system (DIS) according to claim 4.

18. Bluetooth device identification system (DIS) according to claim 2, wherein the processor, the memory, and at least one Bluetooth chip processor and / or 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 field-programmable gate array capable of receiving and interpreting Bluetooth signals are part of a single integrated circuit.

20. Bluetooth device identification system (DIS) according to claim 12, wherein at least two of the full state machine configurations that can exist on a given DTI are identical on the edge but have different internal substate configurations, so that a given DTI can be more accurately identified by determining its actual substate configuration in response to a given state machine query packet.

Images