Multi-device broadcast network for context and awareness

Abstract

Various aspects include methods for supporting contextual broadcast networking by a device. Aspects provide for a cross-ecosystem platform that enables a transition from a device-centric fragmented user experience to a seamless user experience. Some aspects can include decrypting a broadcast message received from a radio controller if the broadcast message indicates an account identity value matches a pre-computed account identity value and is not a duplicate; generating a data element from the decrypted broadcast message; storing the data element in a data cache; and signaling an interrupt indicating the data element is available. Further aspects include a radio controller receiving a first scan interval from a primary host of the device and a second scan interval from a secondary host of the device; scheduling primary host scan windows based on the first scan interval, and canceling any secondary host second scan windows that overlap with any of the scheduled primary host first scan windows.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 235,694, filed August 21, 2021, entitled “Multi Device Broadcast Network For Context And Awareness,” the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Long Term Evolution (LTE), 5G New Radio (NR), and other newly developed communication technologies allow wireless devices to transmit information at data rates several orders of magnitude higher (e.g., in gigabits per second) than were available just a few years ago.

[0004] Today's communication networks are also more secure, resistant to multipath fading, allow for lower network traffic latency, and provide better communication efficiency (e.g., measured in bits per second per unit of bandwidth). Summary of the Invention

[0005] Various aspects may include methods for supporting context broadcast networking performed by the device. Such methods may include: determining, on a low-power island of the device, which is interfaced with a radio controller of the device, whether a broadcast message received from the radio controller indicates that an account identity value matches a pre-calculated account identity value; in response to determining that the broadcast message received from the radio controller indicates that the account identity value matches the pre-calculated account identity value, determining on the low-power island of the device whether the broadcast message received from the radio controller is a duplicate message; in response to determining that the broadcast message received from the radio controller is not a duplicate message, decrypting at least a portion of the broadcast message received from the radio controller on the low-power island of the device; in response to decrypting the at least a portion of the broadcast message received from the radio controller, generating one or more data elements from the broadcast message received from the radio controller on the low-power island of the device; sending the one or more data elements from the low-power island of the device to a shared data cache of the device; and signaling from the low-power island of the device to another processor of the device or sending an interrupt indicating that the one or more data elements are available in the shared data cache. In some aspects, the one or more data elements may indicate the context state, settings, events, or capabilities of another device.

[0006] In some aspects, the low-power island may be configured such that: determining that a broadcast message received from the radio controller indicates an account identity value matching a pre-calculated account identity value and determining that the broadcast message received from the radio controller is not a duplicate message occurs when the low-power island is in a first operating mode; decrypting at least a portion of the broadcast message received from the radio controller, generating one or more data elements from the broadcast message received from the radio controller, sending the one or more data elements from the low-power island of the device to the shared data cache of the device, and signaling or sending an interrupt indicating that the one or more data elements are available in the shared data cache occurs when the low-power island is in a second operating mode; and the first operating mode is a lower-power operating mode than the second operating mode.

[0007] In some respects, the account identity value indicated in the broadcast message received from the radio controller and a matching pre-calculated account identity value can indicate that the device shares the same account credentials with the device that sent the broadcast message received from the radio controller.

[0008] In some aspects, determining whether a broadcast message received from a radio controller is a duplicate message may include: comparing the salt value of the broadcast message received from the radio controller with a salt value log; and determining that the broadcast message received from the radio controller is a duplicate message in response to a match between the salt value of the broadcast message received from the radio controller and the salt value in the salt value log.

[0009] Some aspects may also include: ignoring broadcast messages received from the radio controller in response to determining that a broadcast message received from the radio controller does not indicate that an account identity value matches a pre-calculated account identity value, or determining that a broadcast message received from the radio controller is a duplicate message.

[0010] Some aspects may also include: the device's low-power island monitoring broadcast messages received by the radio controller on the transport layer at a selected periodicity, wherein the selected periodicity is different from the periodicity of another processor of the device monitoring broadcast messages received by the radio controller on the transport layer. Such aspects may also include: increasing the selected periodicity in response to a user's close proximity; and decreasing the selected periodicity in response to a user's lack of close proximity. In some aspects, the transport layer may be a Bluetooth transport layer.

[0011] Another aspect includes a method for periodic scan scheduling for a device's radio controller. Such a method may include: receiving at the device's radio controller a first scan interval from a primary host and a second scan interval from a secondary host; scheduling a primary host scan window by the radio controller based on the first scan interval from the primary host; determining, at least partially based on the second scan interval from the secondary host, any secondary host scan window that overlaps with any of the scheduled primary host first scan windows; and canceling any secondary host second scan window determined to overlap with any of the scheduled primary host first scan windows.

[0012] In some respects, the primary host may be associated with an advanced operating system that interfaces with the radio controller, and the secondary host may be associated with a low-power island that interfaces with the radio controller. In some respects, the radio controller may be a Bluetooth radio controller.

[0013] In some aspects, the scan interval from the primary host of the device can define a first scan window length, and the scan interval from the secondary host of the device can define a second scan window length different from the first scan window length. In such aspects, the scan interval from the primary host of the device can define a first scan cycle, and the scan interval from the secondary host of the device can define a second scan cycle different from the first scan cycle.

[0014] Another aspect includes a device having a processor configured with processor-executable instructions for performing operations of any of the methods outlined above. Another aspect includes a device having components for performing functions of any of the methods outlined above. Another aspect includes a non-transitory processor-readable medium storing processor-executable instructions thereon, the processor-executable instructions being configured to cause the processor of the device to perform operations of any of the methods outlined above. Attached Figure Description

[0015] The accompanying drawings, which are incorporated herein and form part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain the features of the claims.

[0016] Figure 1A This is a conceptual system block diagram illustrating an exemplary communication system.

[0017] Figure 1B This is a system block diagram illustrating an example decomposed base station architecture for a wireless communication system suitable for implementing any of the various implementation schemes.

[0018] Figure 2 This is a component block diagram illustrating the components of an exemplary wireless modem system that can be used in devices implementing various embodiments.

[0019] Figure 3A This is a component block diagram illustrating the software and hardware architecture of a primary instance of context broadcast networking according to various implementation schemes.

[0020] Figure 3B This is a component block diagram illustrating the software and hardware architecture of a primary instance of context broadcast networking and one or more auxiliary instances of auxiliary context broadcast networking according to various implementation schemes.

[0021] Figure 3C This is a component block diagram illustrating the software and hardware architecture of context broadcast networking instances according to various implementation schemes.

[0022] Figure 4A , Figure 4B and Figure 4C The variations of context broadcast networks over time according to various implementation schemes are illustrated.

[0023] Figure 4D Aspects of simultaneous context broadcasting networks according to various implementation schemes are illustrated.

[0024] Figure 5 The cloud server architectures according to various implementation schemes are shown.

[0025] Figure 6 This is a process flowchart illustrating a method for supporting context broadcast networking by a device, according to various implementation schemes.

[0026] Figure 7 This is a flowchart illustrating a method for selecting a data element format according to various implementation schemes.

[0027] Figure 8A This is a block diagram illustrating examples of data element formats for core namespace data elements and data element formats for short namespace data elements according to various implementation schemes.

[0028] Figures 8B to 8D This is a block diagram illustrating message formats for broadcast transmission according to various implementation schemes.

[0029] Figure 9 This is a block diagram illustrating exemplary message formation for a set of data elements according to various implementation schemes.

[0030] Figure 10A , Figure 10B , Figure 10C and Figure 10DExemplary encrypted fragments according to various implementation schemes are shown.

[0031] Figure 11 This is a process flowchart illustrating a method for selecting a variable radio frequency (RF) transmission layer according to various implementation schemes.

[0032] Figure 12 This is a process flowchart illustrating a method for user proximity-based radio resource management according to various implementation schemes.

[0033] Figure 13A This is a process flowchart illustrating a method for supporting context broadcast networking by a device, according to various implementation schemes.

[0034] Figure 13B This is a process flowchart illustrating a method for supporting context broadcast networking by a device, according to various implementation schemes.

[0035] Figure 14 This is a process flowchart illustrating the equipment configuration methods according to various implementation schemes.

[0036] Figure 15A , Figure 15B and Figure 15C Exemplary operations for device registration and configuration according to various implementation schemes are shown.

[0037] Figure 16A This is a flowchart illustrating a method for changing device settings or application settings according to various implementation schemes.

[0038] Figure 16B and Figure 16C Exemplary interactions in a context broadcast network according to various implementation schemes are shown.

[0039] Figure 17A This is a process flowchart illustrating a method for periodic scan scheduling of a radio controller according to various implementation schemes.

[0040] Figure 17B Examples of periodic scan scheduling based on various implementation schemes are shown.

[0041] Figure 18 It is a component block diagram of IoT devices applicable to various implementation schemes.

[0042] Figure 19 This is a component diagram of an exemplary server applicable to various implementation schemes.

[0043] Figure 20 It is a component block diagram of a device applicable to various implementation schemes.

[0044] Figure 21 This is a component diagram of an exemplary computing device suitable for use with various implementation schemes.

[0045] Figure 22 This is a component diagram of an exemplary wireless headphone device suitable for use with various implementations.

[0046] Figure 23 This is an illustration of a head-mounted device (e.g., an extended reality (XR) headset) suitable for implementing various implementation schemes. Detailed Implementation

[0047] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and particular embodiments are for illustrative purposes only and are not intended to limit the scope of the claims.

[0048] Various implementations include methods and systems for supporting context broadcast networking by devices. Some implementations include cross-ecosystem platforms that enable a shift from device-centric, fragmented user experiences to seamless ones. Some implementations include platforms that support inter-device communication of status information broadcast, which may not be the domain of original equipment manufacturers (ODMs) and / or original equipment manufacturers (OEMs). Some implementations include platforms that can be extended by ecosystem participants. Some implementations include platforms that deliver platform services without user-perceptible latency and / or battery life impact. Some implementations include platforms that support devices with and / or without internet connectivity. Some implementations include platforms that prevent fragmentation by exposing APIs for various implementations in a manner independent of operating system approvals. Some implementations include context broadcast networks that can be established between devices without requiring network establishment or network availability (or announcement) operations to be performed by the devices in the network.

[0049] The terms “device,” “wireless device,” “user equipment” (UE), and “UE computing device” are used herein to refer to any or all of the following: cellular phone, smartphone, portable computing device, personal or mobile multimedia player, laptop computer, desktop computer, tablet computer, smartbook, ultrabook, handheld computer, wireless email receiver, wireless headset (e.g., wireless headphones, wireless earbuds, etc.), wireless wearable device (e.g., smartwatch, smart sensor, wireless fitness tracker, etc.), internet-enabled multimedia cellular phone, wireless router device, wireless appliance, smart TV, smart speaker, medical device and equipment, entertainment device (e.g., wireless game controller, music and video player, satellite radio, etc.), wireless communication elements in autonomous and semi-autonomous vehicles (cars, drones, robotic vacuum cleaners, etc.), wireless devices attached to or incorporated into various mobile platforms, and similar devices including memory, wired and / or wireless communication components and programmable processors.

[0050] The term "IoT device" is used herein to refer to any of a variety of devices, including processors and transceivers for communicating with other devices or networks. For ease of description, examples of IoT devices are described as communicating via a radio frequency (RF) wireless communication link; however, IoT devices can communicate with another device (or user) via wired or wireless communication links, for example, as a participant in a communication network such as IoT. Such communication may include communication with another wireless device, base stations (including cellular communication network base stations and IoT base stations), access points (including IoT access points), or other wireless devices. In various respects, an IoT device can be an example of a device.

[0051] The phrase "head-mounted device" and the acronym (HMD) are used herein to refer to any wearable electronic display system that presents at least some computer-generated images to a user. An HMD may present only computer-generated images, or a combination of computer-generated images and real-world images from the user's physical environment (i.e., what the user would see without glasses). An HMD enables a user to view the generated images within the context of a real-world scene. Non-limiting examples of head-mounted devices include helmets, glasses, virtual reality (VR) glasses, augmented reality (AR) glasses, mixed reality (MR) glasses, extended reality (XR) headsets (e.g., headsets that provide VR, AR, MR, and / or other types of immersive or semi-immersive visual experiences), electronic goggles, and other similar technologies / devices, or may be included therein. Head-mounted devices may include various hardware components such as a processor, memory, a display, one or more cameras (e.g., worldview cameras, staring cameras, etc.), and a wireless interface for connecting to the Internet, a network, or another computing device. In some embodiments, the head-mounted device processor may be configured to execute XR software applications. In various respects, HMD devices can serve as examples of devices.

[0052] In some embodiments, the head-mounted device may be an accessory for and / or for receiving information from a device (e.g., a desktop, laptop, smartphone, tablet, etc.), wherein all or part of the processing is performed on the processor of the wireless device. Therefore, in various embodiments, the head-mounted device may be configured to perform all processing locally on the processor within the head-mounted device, offload all major processing to a processor in another computing device (e.g., a laptop computer in the same room as the head-mounted device), or distribute major processing operations between the processor in the head-mounted device and the processor in the other computing device. In some embodiments, the processor in the other computing device may be a "cloud" server, with the processor in the head-mounted device or an associated wireless device communicating with the server via a network connection (e.g., a cellular network connection to the Internet).

[0053] Various implementation schemes are capable of transmitting and receiving data according to either the Institute of Electrical and Electronics Engineers (IEEE) 16.11 standard or either the IEEE 802.11 standard. Standard, Code Division Multiple Access (CDMA), CDMA-2000, Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE) (also known as Enhanced GPRS (EGPRS)), Terrestrial Trunking Radio (TETRA), Wideband CDMA (WCDMA), Evolved Data Optimized (EV-DO), 1xEV-DO, EV-DO Revision A, EV-DO Revision B, High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Evolved High-Speed ​​Packet Access (HSPA+), Long Term Evolution (LTE), AMPS RF signals, or any other known signals used to transmit within a wireless, cellular, or Internet of Things (IoT) network, such as IEEE 802.15.4 protocols (e.g., Thread, ZigBee, and Z-Wave), 6LoWPAN, Bluetooth Low Energy (BLE), LTE Machine-Type Communications (LTE MTC), Narrowband LTE (NB-LTE), Cellular IoT (CIoT), Narrowband IoT (NB-IoT), BT Smart, Wi-Fi, LTE-U, LTE-Direct, MuLTEfire, and wide-area physical layer interfaces (PHYs) with relatively extended distances, such as Random Phase Multiple Access (RPMA), Ultra Narrowband (UNB), Low Power Long Range (LoRa), Low Power Long Range Wide Area Network (LoRaWAN), Weightless, Global Microwave Access Interoperability (WiMAX), or Multicast Domain Name Service (DNS) (mDNS) or IP Connected Home (CHIP), or systems utilizing 3G, 4G, or 5G or other specific implementations thereof.

[0054] The term "System-on-a-Chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources and / or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general-purpose and / or special-purpose processors (digital signal processors, modem processors, video processors, etc.), blocks of memory (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, regulators, oscillators, etc.). A SOC may also include software for controlling the integrated resources and processors, as well as software for controlling peripheral devices.

[0055] The term "System-in-Package" (SIP) is used herein to refer to a single module or package containing multiple resources, computing units, cores and / or processors on two or more IC chips, a substrate, or a System-on-a-Chip (SoC). For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SoCs coupled together and packaged adjacently (e.g., on a single motherboard or in a single IoT device) via high-speed communication circuitry. The proximity of the SoCs facilitates high-speed communication and the sharing of memory and resources.

[0056] As used herein, the terms “SIM,” “SIM card,” and “subscriber identity module” can be used interchangeably to refer to a memory that may be an integrated circuit or embedded within a removable card and stores the International Mobile Subscriber Identity (IMSI), associated keys, and / or other information used to identify and / or authenticate wireless devices on a network and enable communication services with the network. Examples of SIM include the Universal Subscriber Identity Module (USIM) provided in the Long Term Evolution (LTE) 3GPP standard and the Removable Subscriber Identity Module (R-UIM) provided in the 3GPP standard. Universal Integrated Circuit Card (UICC), Embedded UICC (eUICC), Integrated SIM (iSIM), and Integrated UICC (iUICC) are other terms for SIM. Additionally, SIM can also refer to a Virtual SIM (VSIM), which can be implemented as a remote SIM profile loaded into an application on a wireless device and implements normal SIM functionality on the wireless device.

[0057] Because the information stored in a SIM enables a wireless device to establish a communication link with a specific network for one or more specific communication services, the term "SIM" is also used herein as a shorthand reference to the communication services associated with and enabled by the information stored in a particular SIM, since the SIM, the communication network, and the services and subscriptions supported by that network are related to each other. Similarly, the term SIM can also be used as a shorthand reference to the protocol stack and / or modem stack, as well as the communication processes used in establishing and conducting communication services with subscriptions and networks enabled by the information stored in a particular SIM.

[0058] The various implementations described herein use the term "server" to refer to any computing device capable of functioning as a server (such as a primary switching server, web server, mail server, document server, content server, or any other type of server). A server can be a dedicated computing device or a computing device that includes a server module (e.g., running an application that enables the computing device to operate as a server). A server module (e.g., a server application) can be a full-featured server module or a lightweight server module or secondary server module configured to provide synchronization services between dynamic databases on the receiving device (e.g., a lightweight server application or secondary server application). A lightweight server or secondary server can be a simplified version of server-type functionality implemented on the receiving device, thereby enabling the receiving device to function as an Internet server (e.g., an enterprise email server) only to the extent necessary to provide the functionality described herein.

[0059] As used herein, the terms “network,” “system,” “wireless network,” “cellular network,” and “wireless communication network” can be used interchangeably to refer to part or all of an operator’s wireless network associated with a wireless device and / or a subscription on that wireless device. The technologies described herein can be used in various wireless communication networks, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), FDMA, Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), and others. Generally, any number of wireless networks can be deployed in a given geographical area. Each wireless network can support at least one radio access technology, which can operate on one or more frequencies or frequency ranges. For example, a CDMA network can implement Universal Terrestrial Radio Access (UTRA) (including the Wideband Code Division Multiple Access (WCDMA) standard), CDMA2000 (including the IS-2000, IS-95, and / or IS-856 standards), etc. Similarly, a TDMA network can implement GSM Evolution GSM Enhanced Data Rate (EDGE). For example, OFDMA networks can support evolved UTRA (E-UTRA) (including the LTE standard), IEEE 802.11 (WiFi), IEEE 802.16 (WiMAX), and IEEE 802.20. Etc. Reference may be made to wireless networks using the LTE standard; therefore, the terms “Evolved Universal Terrestrial Radio Access,” “E-UTRAN,” and “eNodeB” are used interchangeably herein to refer to wireless networks. However, such citations are provided merely as examples and are not intended to exclude wireless networks using other communication standards. For example, while various third-generation (3G), fourth-generation (4G), and fifth-generation (5G) systems are discussed herein, those systems are cited merely as examples and can be replaced by future generations of systems (e.g., sixth-generation (6G) or higher) in various examples.

[0060] The terms “network operator,” “operator,” “mobile network operator,” “communications operator,” and “service provider” are used interchangeably herein to describe a wireless communication service provider that owns or controls elements to sell and deliver communication services to end users and provides the necessary provisioning and credentials as a strategy to be implemented in user equipment subscriptions.

[0061] As the number of devices users interact with daily (e.g., phones, laptops, watches, headphones, car infotainment systems, speakers, TVs, IoT devices, etc.) increases, users often find multi-device user experiences frustratingly complex and unintuitive. While such devices may be considered "smart" from an internet connectivity perspective, they often cannot be "smart" together from a local connectivity perspective. This complex user experience drives consumers away from technology or towards single-manufacturer ecosystems that offer intuitive and seamless experiences.

[0062] For a wireless device to function well, it may need to be aware of its surroundings, including what other nearby devices are doing and how the user interacts with other wireless devices. This awareness can then be used to guide the user through an intuitive user experience and interactions with the wireless device.

[0063] Various implementations offer cross-ecosystem platforms that enable a shift from fragmented, device-centric user experiences to seamless ones. These platforms allow developers to create consistent and seamless user experiences across devices, regardless of the device's operating system or ecosystem.

[0064] Devices according to various embodiments may utilize one or more radio technologies to create new logical broadcast networks, where application and / or operating system components can share and consume connectivity information. In various embodiments, devices may include platform-level software components that can expose services through consistent application programming interfaces (APIs) that can cross ecosystem boundaries and be accessed equally by different applications and / or different operating systems.

[0065] Various implementation schemes may utilize cloud components to a limited extent. In various implementation schemes, the cloud architecture can facilitate information exchange between wireless devices and / or provide persistent configuration storage. In some implementation schemes, components that enable a seamless user experience may not require internet connectivity.

[0066] Some implementations may provide a platform that organizes a core library of context information. Some implementations may provide a platform that allows this context library to be extended by applications and operating systems. Some implementations may provide a platform that provides a simple and consistent API for sharing and consuming target context information. Some implementations may provide a platform that isolates network complexities (including transport mechanisms) from applications and operating systems. As used herein, the term "transport" may include communication technologies (such as Bluetooth), messaging standards (such as multicast Domain Name Service (DNS) (mDNS), etc.), and communication systems (such as Open Connectivity Foundation (OCF) systems, CHIP Connected Home (sometimes also referred to as physical systems), etc. Some implementations may provide a platform that manages the dynamic nature of context information exchange, thereby ensuring freshness as it is affected by user mobility, device activity, and / or other factors. Some implementations may provide a platform that delivers context information privately (e.g., in a privacy-preserving manner that reduces (or prevents) user tracking), including by providing the integrity, authenticity, and confidentiality of user information. Some implementations may provide a platform that delivers platform services without user-perceptible delays. Lack of performance and / or battery life impact. Some implementations may provide a platform that supports user privacy by preventing user tracking and providing transparency regarding data ownership and allocated usage rights. Some implementations may provide a platform that provides server application programming interfaces (APIs) for management and analytics. Some implementations may provide a platform that supports wireless devices with application processors enabled by an Advanced Operating System (HLOS). Some implementations may provide a platform that supports embedded devices with a Real-Time Operating System (RTOS). Some implementations may provide a platform that supports devices with and / or without internet connectivity. Some implementations may provide a platform that prevents fragmentation by exposing implementation APIs in a manner independent of operating system approval.

[0067] Compared to traditional Internet of Things (IoT) systems, various implementation schemes differ in the relationship between event occurrence, event transmission, and the resulting action. In traditional IoT systems, there is a causal mapping between events and actions. For example, in a traditional IoT system, a switch changing to "on" will turn on a light bulb. Additionally, in traditional IoT systems, events refer to a specific single device or a designated group of devices.

[0068] In contrast, in various implementations, the relationship between an event occurring and the action taken can be inferred. In these implementations, the event can be broadcast, received by nearby devices registered to the same account, and the actions taken by these devices (if any) depend on factors tracked by the receiving wireless device, such as the history of the received events, the history of the wireless device itself, and whether the user is actively using the device. In these implementations, the proximity perception of the device, combined with the wireless device's ability to determine the inferred context, can lead to personalized actions by the device.

[0069] Various implementations support proximity sensing, enabling the identification of user devices, nearby wireless devices, and devices actively involved in the use case. In various implementations, in addition to or instead of events, devices can transmit contextual information, thereby supporting inferences and actions that reflect the user's complete settings.

[0070] Some implementations provide a platform that may not be the hidden garden of original equipment manufacturers (ODMs) and / or original equipment manufacturers (OEMs). Some implementations provide a platform that can be extended by ecosystem participants. Some implementations provide a platform that enables rapid deployment across a large number of wireless devices. Some implementations provide a platform that enables deployment across a wide variety of wireless devices, such as telephones, voice and music devices, automotive infotainment systems, etc. Some implementations provide a platform that securely delivers information, including by providing the integrity, authenticity, and confidentiality of user information. Some implementations provide a platform that delivers platform services without user-perceptible latency and / or battery life impact. Some implementations provide a platform that provides user privacy by preventing user tracking and providing transparency in data ownership and allocated usage rights. Some implementations provide a platform that supports devices across multiple RTOS, HLOS, and ecosystems. Some implementations provide a platform that supports devices with and / or without internet connectivity. Some implementations may provide a platform that prevents fragmentation by exposing APIs independent of operating system approvals. Other implementations may provide a platform that enables cross-layer synchronization within the operating system ecosystem to leverage underlying hardware capabilities.

[0071] Some implementations support hardware offloading of communication protocol management, message filtering, and / or event triggering. Compared to HLOS operation, such hardware offloading enables a seamless user experience and / or reduced power consumption. Some implementations also support offloading communication protocol management, message filtering, and / or event triggering from higher-power processors to lower-power processors.

[0072] Some implementations provide a platform that offers basic services to application and / or operating system developers. Some implementations enable user account authentication. Some implementations enable the configuration of one or more platform identities. Various implementations may not require configuration information at the time of device manufacturing. Instead, in various implementations, information configuration may occur after device purchase and / or operation. Some implementations enable secure access to user data. Some implementations enable the publication of context information on a logical network. Some implementations enable the consumption of the latest proximity context information published to the network by other devices. Some implementations enable the determination of the latest inferred context information. Some implementations enable the provision of device capability hints on a logical network. Some implementations allow extensions to support the creation of application and / or operating system-specific contexts.

[0073] Some implementations provide a platform that enables networking between a wide variety of devices with broad capabilities. Some implementations can be deployed on a single-processor RTOS, a SoC with multiple subsystems, and / or different application execution environments (EEs).

[0074] In some implementations, each device implementation may include a primary instance hosted on the lowest power subsystem and / or low-power island. In some implementations, the primary instance may provide services to applications, operating system components, and / or operating system services. In some implementations, a device with multiple execution environments may optionally include secondary instances configured to extend the platform to applications and operating systems running on those additional execution environments. In some implementations, the primary instance and / or optional secondary instances may be supplemented by servers.

[0075] Various implementations may include layers configured to translate lower-level outputs into higher-level defined APIs, such as operating system APIs (OS APIs). For example, the OS API layer may be defined in Java or C#, while the lower-level API layers may be defined in C. In some implementations, an OS Adaptation Layer (OSAI) may be responsible for implementing the API translation, thereby maximizing portability across wireless devices and the ecosystem.

[0076] In various implementations, the manager functionality layer may be responsible for securely managing user account credentials, configuration, and communication with Open Authorization (OAuth) servers and / or platform servers. In some implementations, the manager functionality layer may also be responsible for accessing wireless device APIs to configure and bridge all wireless device-specific functions that the platform can rely on. For example, this may include configuring transport mechanisms to receive and send communications. In some implementations, the implementation of the manager functionality layer may be operating system-specific. In some implementations, the manager functionality layer may communicate with the platform engine and / or platform core via an internal interface. In some implementations, this interface may be used to configure the platform engine and platform core using data including API definitions, namespace changes, inferred updates, policy changes, etc.

[0077] In some implementations, the platform engine may be responsible for translating high-level platform APIs into one or more platform data elements shared across a logical broadcast network. In some implementations, the platform engine may provide registration and callback mechanisms for platform clients to be notified when a data element carrying context updates is received. In some implementations, the platform engine may be the sole functional component that understands the platform namespace and the meaning of data elements. In some implementations, the platform engine may use its understanding of the meaning of data elements to perform inferences and provide higher-level, value-added APIs.

[0078] In some implementations, the platform core functional layer can handle all data element communication. For this purpose, the platform core functional layer may only need to know the data element format. On the sending path, the platform core functional layer can filter all platform engine requests, apply necessary QoS, and schedule transmissions using appropriate transport mechanisms. Additionally, on the sending path, the platform core functional layer can receive an input stream of one or more data elements and / or QoS indications, organize data elements based on QoS indications, apply account-based security and privacy, select and configure transmission offloading, and / or segment the data element set into Protocol Data Units (PDUs) using the Maximum Transmission Unit (MTU) size. Encrypted data element formats can support receiver-side account and duplicate filtering. On the receiving path, the platform core functional layer can efficiently process incoming data, update the shared data element cache, and interrupt the appropriate platform engine instance so that the appropriate instance can consume the latest context information conveyed in the data element. Additionally, on the receiving path, the platform core functional layer can perform account and / or duplicate filtering, assembly, decryption, store data elements in the shared data element cache, trigger engine instances, and / or provide data element cache aging and maintenance. Engine instances can freely query the shared data element cache for the latest context.

[0079] In some implementations, the transport offloading layer can be responsible for bridging the platform's core data output to various radio or protocol transmissions, such as Bluetooth, multicast Domain Name Service (mDNS), and Connected Home IP (CHIP).

[0080] In some implementations, platform auxiliary instances can extend the benefits of the platform to other execution environments. In some implementations, each auxiliary instance may include a dedicated platform manager, platform client, and operating system (OS) software development kit (SDK) that enables applications, OS components, and / or OS services of the execution environment itself.

[0081] In some implementations, a device with an application processor and a separate low-power island can instantiate at least one platform-auxiliary instance. In some implementations, a number of devices with multiple common execution environments and / or dedicated virtual machines can instantiate several platform-auxiliary instances.

[0082] Various implementations may use one or more of several transport layers to form a logical broadcast network and exchange context and device capability information, such as Bluetooth Low Energy (LE) (e.g., using LE announcements), Bluetooth Asynchronous Connectionless (ACL) (e.g., using Bluetooth General Attribute Profile (GATT) and platform services), mDNS (e.g., using Internet Protocol (IP) transport over Wi-Fi, Ethernet and / or Zigbee connections), CHIP (e.g., using IP transport over Wi-Fi, Ethernet and / or Zigbee connections), etc.

[0083] In some implementations, a group of devices with the same account credentials may represent a platform network. Many platform devices (also referred to herein as platform nodes) may be inherently mobile, and in some implementations, the platform network may dynamically change as devices enter and leave each other's range over time. In some implementations, platform nodes may not have a role within a logical broadcast network. Instead, platform nodes may be peers, and each platform node may alternate between sharing its own context and listening to or monitoring contexts from devices within range. In some implementations, a device may support multiple account credentials associated with multiple user profiles, thereby switching the identity of the context broadcast function to the user profile or account active on the device. In some devices that support multiple simultaneous user profiles or accounts, the context broadcast function may support an independent and secure broadcast context stream corresponding to each active profile or user.

[0084] In some implementations, configuration may be a process for bootstrapping a device to a user's platform account. In some implementations, the configuration platform device may include at least one device to be connected to the Internet. In some implementations, the Internet-connected platform device may be referred to as a hub wireless device. The hub wireless device may then act as a proxy for configuring devices not connected to the Internet. In some implementations, the Internet-unconnected platform wireless device may be referred to as an accessory device.

[0085] In some implementations, the hub device may have only a single active platform account for each user profile on the hub device. In some implementations, the hub device may be required to configure accessory devices. In some implementations, the accessory device may allow each pairing instance permitted by the accessory device to have a platform account associated with it, enabling pairing to devices configured with platform account A, platform account B, or without a platform account or capability. In some implementations, the platform cloud account may be associated with an OAuth identity. In some implementations, the cloud account may store various types of data, such as user-specific persistent storage of key materials for subsequent configuration, a list of registered devices, a cached subset of device data elements, etc. In some implementations, user account access may be granted through an application, an API and / or web interface configured to enable any application to create user experiences. In some implementations, the platform cloud account may be associated with one or more OAuth identities.

[0086] In some implementations, the platform cloud may utilize an established OAuth server to determine unique identities. In other implementations, the platform cloud may utilize cloud servers to securely store account and configuration information. In various implementations, the platform cloud may provide caching services.

[0087] In some implementations, the client may not interact directly with the platform cloud. In some implementations, the client may utilize the platform API. In some implementations, the platform manager may be the only distributed component of the platform architecture that interfaces with the cloud server. In some implementations, cloud connectivity may only be required when configuring new hub devices.

[0088] In some implementations, the platform may not provide connection-oriented data sessions. For example, in some implementations, the platform may not be configured to transfer audio or video between two applications. In some implementations, the platform may be used to share contextual information that enables clients to discover and initiate connection-oriented data sessions. For example, in some implementations, broadcast context may be used to notify clients how they can initiate connection-oriented data sessions to retrieve a replication buffer stored on another device. In some implementations, the cloud server may not provide traditional cloud services.

[0089] The term “FabriQ” is used herein to discuss and / or illustrate various embodiments in the various figures. As used herein, the term “FabriQ” is used as an abbreviation to identify aspects of various embodiments relating to context broadcast networking. The term “FabriQ” as used in the following description and figures is for illustrative purposes only and is not intended to be limiting.

[0090] Figure 1A This is a system block diagram illustrating an exemplary communication system suitable for implementing any of the various implementation schemes. Communication system 100 can be a 5G New Radio (NR) network, or any other suitable network such as an LTE network, 5G (or later generation) network, etc. Although Figure 1A The illustration shows a 5G network; subsequent generations of networks may also include the same or similar elements. Therefore, references to 5G networks and 5G network elements in the following description are for illustrative purposes only and are not intended to be limiting.

[0091] Communication system 100 may include a heterogeneous network architecture comprising a core network 140 and various devices (e.g., user equipment (UE) 120a-120d, IoT device 120e, watch 120f, HMD 120g, and headset 120h shown in Figure 1). Communication system 100 may also include several base stations (shown as BS110a, BS110b, BS110c, and BS110d) and other network entities. A base station is an entity that communicates with devices and may also be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio headend, a transmit / receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next-generation Node B (gNodeB or gNB), etc. Each base station can provide communication coverage for a specific geographic area. In 3GPP, the term "cell" can refer to the coverage area of ​​a base station, a base station subsystem serving that coverage area, or a combination thereof, depending on the context in which the term is used. Core network 140 can be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, etc. While the communication system 100 is discussed with reference to various examples of the types of devices 120a-120h (such as UEs, IoT devices, HMDs, watches, headphones, etc.), these are merely examples, and devices 120a-120h can be any type of device, such as robots, vehicles, infrastructure equipment, etc.

[0092] Base stations 110a-110d can provide communication coverage for macrocells, picocells, femtocells, another type of cell, or a combination thereof. A macrocell can cover a relatively large geographic area (e.g., with a radius of several kilometers) and allows unrestricted access by mobile devices with service subscriptions. A picocell can cover a relatively small geographic area and allows unrestricted access by mobile devices with service subscriptions. A femtocell can cover a relatively small geographic area (e.g., a residential area) and allows restricted access by mobile devices associated with that femtocell (e.g., mobile devices in a closed subscriber group (CSG)). A base station used for a macrocell may be referred to as a macro BS. A base station used for a picocell may be referred to as a pico BS. A base station used for a femtocell may be referred to as a femtocell BS or a home BS.

[0093] In the example shown in Figure 1, base station 110a can be a macro BS for macro cell 102a, base station 110b can be a pico BS for pico cell 102b, and base station 110c can be a femto BS for femto cell 102c. Base stations 110a-110d can support one or more (e.g., three) cells. The terms “eNB,” “base station,” “NR BS,” “gNB,” “TRP,” “AP,” “Node B,” “5G NB,” and “cell” are used interchangeably herein.

[0094] In some examples, the cell may not be stationary, and the geographical area of ​​the cell may move depending on the location of the mobile base station. In some examples, base stations 110a-110d may interconnect with each other and with one or more other base stations or network nodes (not shown) in the communication network 100 using any suitable transport network via various types of backhaul interfaces (such as direct physical connections, virtual networks, etc.).

[0095] Base stations 110a-110d can communicate with the core network 140 via wired or wireless communication link 126. Equipment (e.g., user equipment (UE)) 120a-120h can communicate with base stations 110a-110d via wireless communication link 122.

[0096] The wired communication link 126 can use a variety of wired networks (e.g., Ethernet, TV cable, telephone, fiber optic and other forms of physical network connection) that can use one or more wired communication protocols (such as Ethernet, point-to-point protocol, high-level data link control (HDLC), advanced data communication control protocol (ADCCP) and transmission control protocol / Internet protocol (TCP / IP)).

[0097] The communication system 100 may also include a relay station (e.g., relay BS 110d). A relay station is an entity capable of receiving data transmissions from an upstream station (e.g., a base station or mobile device) and transmitting that data to a downstream station (e.g., a device (e.g., a UE) or base station). A relay station can also be a mobile device capable of relaying transmissions for other devices. In the example shown in Figure 1, relay station 110d can communicate with macro base station 110a and device 120d to facilitate communication between base station 110a and device 120d. A relay station may also be referred to as a relay base station, relay, relay, etc.

[0098] Communication system 100 can be a heterogeneous network comprising different types of base stations (e.g., macro base stations, pico base stations, femto base stations, relay base stations, etc.). These different types of base stations may have different transmit power levels, different coverage areas, and different effects on interference in communication system 100. For example, macro base stations may have high transmit power levels (e.g., 5 to 40 watts), while pico base stations, femto base stations, and relay base stations may have lower transmit power levels (e.g., 0.1 to 2 watts).

[0099] Network controller 130 can be coupled to a set of base stations and can provide coordination and control over these base stations. Network controller 130 can communicate with the base stations via backhaul. Base stations can also communicate with each other directly or indirectly, for example, via wireless or wired backhaul.

[0100] Devices (e.g., UEs, vehicles, HMDs, etc.) 120a, 120b, 120c, 120e, 120d, 120f, 120g, 120h can be distributed throughout the communication system 100, and each device can be stationary or mobile. Devices may also be referred to as access terminals, terminals, mobile stations, subscriber units, stations, user equipment (UE), broadcast devices (BWD), Internet of Things (IoT) devices, watches, headphones, head-mounted displays (HMDs), etc.

[0101] Macro base station 110a can communicate with core network 140 via wired or wireless communication link 126. Devices 120a, 120b, 120c, and 120f can communicate with base stations 110a-110d via wireless communication link 122.

[0102] Wireless communication links 122 and 124 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. Wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that can be used in wireless communication links include: 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, CDMA, WCDMA, WiMAX, Time Division Multiple Access (TDMA), and other cellular RATs for mobile phone communication technologies. Further examples of RATs that can be used in one or more of the various wireless communication links 122 and 124 within the communication system 100 include medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, and MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, Bluetooth Low Energy (LE), Multicast Domain Name Service (DNS) (mDNS), and Connected Home IP (CHIP). In addition, wired communication links 125 can be established between devices in the communication system 100 via physical wired connections between devices, such as Universal Serial Bus (USB) connections, Fast Peripheral Component Interconnect (PCIe) connections, Universal Serial Bus (USB) connections, High Speed ​​Chip Interconnect (HSIC) connections, Ethernet connections, etc.

[0103] Certain wireless networks (e.g., LTE) use Orthogonal Frequency Division Multiplexing (OFDM) on the downlink and Single-Carrier Frequency Division Multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM divide the system bandwidth into multiple (K) orthogonal subcarriers, often referred to as frequency modulation or frequency slots. Each subcarrier can be used to modulate data. Generally, modulation symbols are transmitted using OFDM in the frequency domain and SC-FDM in the time domain.

[0104] The spacing between adjacent subcarriers can be fixed, and the total number of subcarriers (K) can depend on the system bandwidth. For example, the subcarrier spacing can be 15 kHz, and the minimum resource allocation (called a "resource block") can be 12 subcarriers (or 180 kHz). Therefore, for system bandwidths of 1.25, 2.5, 5, 10, or 20 MHz, the nominal Fast Fourier Transform (FFT) size can be equal to 128, 256, 512, 1024, or 2048, respectively. The system bandwidth can also be divided into multiple subbands. For example, a subband can cover 1.08 MHz (i.e., 6 resource blocks), and for system bandwidths of 1.25, 2.5, 5, 10, or 20 MHz, there can be 1, 2, 4, 8, or 16 subbands, respectively.

[0105] While some implementations may use terminology and examples associated with LTE technology, various implementations are applicable to other wireless communication systems, such as New Radio (NR) or 5G networks. NR can utilize OFDM with a cyclic prefix (CP) on both the uplink (UL) and downlink (DL) and includes support for half-duplex operation using Time Division Duplex (TDD). A single component carrier bandwidth of 100 MHz can be supported. NR resource blocks can span 12 subcarriers with a subcarrier bandwidth of 75 kHz over a duration of 0.1 milliseconds (ms). Each radio frame can include 50 subframes with a length of 10 ms. Therefore, each subframe can have a length of 0.2 ms. Each subframe can indicate the link direction for data transmission (i.e., DL or UL), and the link direction of each subframe can be dynamically switched. Each subframe can include DL / UL data and DL / UL control data. Beamforming can be supported, and the beam direction can be dynamically configured. Precoded Multiple-Input Multiple-Output (MIMO) transmission can also be supported. MIMO configurations in DL can support up to eight transmit antennas (multilayer DL transmission with up to eight streams) and up to two streams per device. Multilayer transmission with up to two streams per device is also supported. Up to eight serving cells can be used to support aggregation of multiple cells. Alternatively, NR can support different air interfaces in addition to the OFDM-based air interface.

[0106] Some mobile devices can be considered machine-type communication (MTC) or evolved or enhanced machine-type communication (eMTC) mobile devices. MTC and eMTC mobile devices include, for example, robots, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. Wireless nodes can provide connectivity to or from a network (e.g., a wide area network such as the Internet or cellular networks) via wired or wireless communication links. Some mobile devices can be considered Internet of Things (IoT) devices, or can be implemented as NB-IoT (Narrowband Internet of Things) devices. Device (e.g., UE) 120a can be included within a housing that houses the device's components, such as processor components, memory components, similar components, or combinations thereof.

[0107] Generally, any number of communication systems and wireless networks can be deployed in a given geographical area. Each communication system and wireless network can support a specific Radio Access Technology (RAT) and can operate on one or more frequencies. A RAT may also be referred to as a radio technology, air interface, etc. A frequency may also be referred to as a carrier, frequency channel, etc. Each frequency can support a single RAT in a given geographical area to avoid interference between communication systems using different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks can be deployed. For example, a 5G Non-Self-Governing (NSA) network can use a 4G / LTE RAT on the 4G / LTE Radio Access Network (RAN) side of the 5G NSA network, and simultaneously use a 5G / NR RAT on the 5G / NR RAN side of the 5G NSA network. The 4G / LTE RAN and 5G / NR RAN can be interconnected and connected to the 4G / LTE core network (e.g., EPC network) in the 5G NSA network. The RAN can consist of base stations 110a-110d, and the RAN can be connected to the core network 140. RAN can also be referred to as Wireless Wide Area Network (WWAN).

[0108] In some implementations, two or more devices 120a-h (e.g., shown as device 120a and IoT device 120e, or device 120a and watch 120f, or device 120a and HMD 120g, or watch 120f and headset 120h) may communicate directly using one or more sidelink channels 124 (e.g., without using base stations 110a-110d as intermediaries for communication with each other). For example, devices 120a-h may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), C-V2X protocols, Bluetooth communication, Wi-Fi communication, ZigBee communication, Bluetooth Low Energy (LE) communication, multicast Domain Name Service (DNS) (mDNS) communication, IP Connected Home (CHIP) communication, mesh networking, or similar networks or combinations thereof. In this configuration, devices 120a-h can perform scheduling operations, resource selection operations, and other operations described elsewhere herein as being performed by base station 110a. Communication between these two or more devices 120a-h (e.g., shown as device 120a and IoT device 120e, or device 120a and watch 120f, or device 120a and HMD 120g, or watch 120f and headset 120h) can establish a local area network (WLAN) between these two or more devices 120a-h. In some implementations, two or more devices 120a-h (e.g., shown as device 120a and IoT device 120e, or device 120a and watch 120f, or device 120a and HMD 120g, or watch 120f and headset 120h) can be connected together via one or more wired connections (e.g., via USB connection, PCIe connection, etc.) and can communicate directly using wired communication link 125 when physically connected.

[0109] In some implementations, one or more servers 198 and / or 199 may provide data to one or more of devices 120a-h and / or these devices may receive data via core network 140. As an example, server 199 may be an Open Authorization (OAuth) server that provides authorization services to one or more of devices 120a-h via core network 140. As another example, server 198 may be a provisioning server according to various implementations, which provides provisioning information to one or more of devices 120a-h via core network 140.

[0110] Figure 1BThis is a system block diagram illustrating an exemplary decomposed base station 160 architecture suitable for implementing any of the various implementation schemes, which may be part of a communication system (e.g., communication system 100) such as a 5G (or later generation) network. (Refer to...) Figure 1A and Figure 1B The decomposed base station 160 architecture may include one or more central units (CUs) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more decomposed base station units, such as a near-real-time RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time RIC 168 associated with a Service Management and Orchestration (SMO) framework 166, or both. CUs 162 may communicate with one or more distributed units (DUs) 170 via appropriate midhaul links, such as F1 interfaces. DUs 170 may communicate with one or more radio units (RUs) 172 via appropriate fronthaul links. RUs 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a UE may be served simultaneously by multiple RUs 172.

[0111] Each of the units (i.e., CU 162, DU 170, RU 172), as well as the near-RT RIC 164, non-RT RIC 168, and SMO frame 166, may include one or more interfaces, or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via wired or wireless transmission media. Each of the units, or an associated processor or controller that provides instructions to the communication interfaces of these units, may be configured to communicate with one or more other units via a transmission medium. For example, these units may include wired interfaces configured to receive or transmit signals to one or more other units over a wired transmission medium. Additionally, these units may include wireless interfaces that may include receivers, transmitters, or transceivers (such as radio frequency (RF) transceivers) configured to receive or transmit signals, or both, to one or more other units over a wireless transmission medium.

[0112] In some aspects, the CU 162 can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to communicate with other control functions stored in the CU 162's main memory. The CU 162 can be configured to handle user plane functionality (i.e., Central Unit-User Plane (CU-UP)), control plane functionality (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 162 can be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bidirectionally with the CU-CP units via an interface such as an E1 interface. The CU 162 can be implemented to communicate with the DU 170 for network control and signaling purposes, as needed.

[0113] DU 170 may correspond to a logic unit that includes one or more base station functions for controlling the operation of one or more RU 172s. In some aspects, DU 170 may, at least in part, host one or more of the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) depending on functional partitioning (such as that defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) stored in the main memory of DU 170 or with control functions stored in the main memory of CU 162.

[0114] Lower-layer functionality can be implemented by one or more RU 172s. In some deployments, an RU172 controlled by a DU 170 may correspond to a logical node that is at least partially based on functional decomposition, such as lower-layer functional decomposition, to host RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, or both). In such architectures, the RU 172(s) may be implemented to handle over-the-air (OTA) communication with one or more UEs 120. In some implementations, the real-time and non-real-time aspects of control and user plane communication with the RU 172(s) may be controlled by the corresponding DU 170. In some scenarios, this configuration allows the DU 170(s) and CU 162 to be implemented in a cloud-based Radio Access Network (RAN) architecture, such as a vRAN architecture.

[0115] SMO framework 166 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, SMO framework 166 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operation and maintenance interfaces such as the O1 interface. For virtualized network elements, SMO framework 166 can be configured to interact with a cloud computing platform (such as Open Cloud (O-Cloud) 176) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some implementations, SMO framework 166 can communicate with the hardware aspects of the 4G RAN (such as Open eNB (O-eNB) 174) via the O1 interface. Additionally, in some implementations, SMO framework 166 can communicate directly with one or more RU 172 via the O1 interface. SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of SMO framework 166.

[0116] The non-RT RIC 168 can be configured to include logical functions enabling non-real-time control and optimization of RAN elements and resources, including AI / ML workflows for model training and updates, or policy-based guidance for applications / features in the near-RT RIC 164. The non-RT RIC 168 can be coupled to or communicate with the near-RT RIC 164, such as via an A1 interface. The near-RT RIC 164 can be configured to include logical functions enabling near real-time control and optimization of RAN elements and resources via data collection and actions through an interface such as an E2 interface connecting one or more CU 162s, one or more DU 170s, or both, and O-eNBs to the near-RT RIC 164.

[0117] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. This information can be utilized by the near-RT RIC 164 and can be received from non-network data sources or network functions at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns in performance and use AI / ML models to perform corrective actions via the SMO framework 166 (such as reconfiguration via O1) or by creating RAN management policies (such as A1 policies).

[0118] Figure 2 An exemplary wireless modem system 200 is shown that can be used in devices (e.g., devices 120a-h) implementing various embodiments. Various embodiments can be implemented on several single-processor and multi-processor computer systems, including system-on-a-chip (SOC) or system-in-package (SIP) systems.

[0119] refer to Figures 1A to 2The exemplary device 200 shown (which may be a SIP in some embodiments) includes two SOCs 202, 204 coupled to a clock 206, a voltage regulator 208, and one or more transceivers 266, wherein the transceivers are configured to transmit wireless communications to / receive wireless communications from network devices such as base station 110a and / or other wireless devices (e.g., devices 120a-h) via antennas (not shown). In some embodiments, the first SOC 202 operates as the device's central processing unit (CPU), which executes instructions by performing arithmetic, logic, control, and input / output (I / O) operations specified by instructions from a software application. In some embodiments, the second SOC 204 may act as a dedicated processing unit. For example, the second SOC 204 may act as a dedicated 5G (or next-generation) processing unit responsible for managing high-capacity, high-speed (e.g., 5Gbps, etc.) and / or very high frequency short-wavelength (e.g., 28GHz millimeter-wave spectrum, etc.) communications. In some implementations, the wireless transceiver 266 may be a wireless transceiver configured to support peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), Bluetooth communication, Wi-Fi communication, ZigBee communication, Bluetooth Low Energy (LE) communication, multicast Domain Name Service (DNS) (mDNS) communication, and IP Connected Home (CHIP) communication. In some implementations, the wireless transceiver 266 may be connected to a first SOC 202 and / or the second SOC 204 may be connected to each of one or more wireless transceivers 266 via various physical connections 267 (also referred to as interconnects, buses, etc.), wherein the physical connections include peripheral component interconnect fast (PCIe) connections, universal serial bus (USB) connections, high-speed chip-to-chip (HSIC) connections, Ethernet connections, etc. In some implementations, the first SOC 202 and / or the second SOC 204 may be configured to selectively transmit data, such as IP packets, to the wireless transceiver 266 using different connections 267.

[0120] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more of these processors, memory 220, custom circuitry 222, system components and resources 224, interconnect / bus modules 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple millimeter-wave transceivers 256, memory 258, and various additional processors 260 (such as application processors, packet processors, etc.).

[0121] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of the other processors / cores. For example, the first SOC 202 may include a processor running a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor running a second type of operating system (e.g., MICROSOFT WINDOWS 10). Furthermore, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., synchronous processor cluster architecture, asynchronous or heterogeneous processor cluster architecture, etc.).

[0122] The first SOC 202 and the second SOC 204 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support processors and software clients running on the devices. System components and resources 224 and / or custom circuitry 222 may also include circuitry for interfacing with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, and other devices (e.g., devices connected via one or more wired connections such as USB connections, PCIe connections, etc.).

[0123] The first SOC 202 and the second SOC 204 can communicate via interconnect / bus module 250. Various processors 210, 212, 214, 216, and 218 can be interconnected via interconnect / bus module 226 to one or more memory elements 220, system components and resources 224, custom circuitry 222, and thermal management unit 232. Similarly, processor 252 can be interconnected via interconnect / bus module 264 to power management unit 254, millimeter-wave transceiver 256, memory 258, and various additional processors 260. Interconnect / bus modules 226, 250, and 264 may include arrays of reconfigurable logic gates and / or implement bus architectures (e.g., CoreConnect, AMBA, etc.). Interconnect / bus modules 226, 250, and 264 can be physical connections between the various processors 210, 212, 214, 216, 218, 252, and 260, such as PCIe connections, USB connections, HSIC connections, Ethernet connections, etc. Communication can be provided by advanced interconnects, such as high-performance on-chip networks (NoC). Individual processors 210, 212, 214, 216, 218, 252, and 260 can be configured to selectively send data (such as IP packets) to each other and transceivers 256 and 266 using different ones of connector 267 and / or interconnect / bus modules 226, 250, and 264.

[0124] The first SOC 202 and / or the second SOC 204 may also include input / output modules (not shown) for communicating with resources outside the SOC, such as clock 206 and voltage regulator 208. Resources outside the SOC (e.g., clock 206, voltage regulator 208) may be shared by two or more internal SOC processors / cores.

[0125] In addition to the example SIP 200 discussed above, various implementations can be implemented in a wide variety of computing systems, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0126] Figure 3A Exemplary software and hardware architectures for a primary instance 300 of context broadcast networking, according to various implementation schemes, are shown. References Figures 1A to 3A The context broadcast networking primary instance 300 may be part of a System-on-a-Chip (SOC) such as SOC 202, 204. As an example, the context broadcast networking primary instance 300 may be at least part of modem processor 212, modem processor 252, and / or DSP 210. As another specific example, the context broadcast networking primary instance 300 may be an additional component of one or both of SOC 202 and / or 204.

[0127] The context broadcast networking primary instance 300 may include a context broadcast networking core 304 configured to execute on a low-power island (or low-power core) 302. The low-power island 302 may be optional. In some embodiments, the context broadcast networking core 304 and the shared data element cache 306 may run on the low-power island 302. In some embodiments, the low-power island 302 may be a processor and / or processing core configured to support multiple wake-ups per second. In some embodiments, the low-power island 302 may be a processor and / or processing core separate from the processor and / or processing core running an advanced operating system.

[0128] In some embodiments, the low-power island 302 may be configured to operate in different modes (such as two different modes). In a first mode (such as a low-power mode), the low-power island 302 may be configured to perform a first set of processing operations that do not exceed a first set power utilization threshold. In a second mode (such as a high-power mode), the low-power island 302 may be configured to perform a second set of processing operations that do not exceed a second set power utilization threshold. The second set power utilization threshold may be a power measurement higher than the first set power utilization threshold, such that when operating in the first mode (such as the low-power mode), the low-power island 302 uses less power than when operating in the second mode (such as the high-power mode). In some embodiments, both the first mode (e.g., low-power mode) and the second mode (e.g., high-power mode) of the low-power island 302 may be operating modes in which the low-power island 302 draws less power than the application processor. In some embodiments, the low-power island 302 may be a processor and / or processing core that supports fewer logical operations than required to run an advanced operating system. In other implementations, the context broadcast networking core 304 and the shared data element cache 306 may not operate on the low-power island.

[0129] Context broadcast networking core 304 can provide context broadcast networking services to application 322, operating system (OS) component 320, OS service 318, firmware, programmable hardware state machine, and / or any programmable entity that can generate and / or consume context information. Context broadcast networking core 304 can provide context broadcast networking services to application 322, OS component 320, and / or OS service 318 through context and awareness API 310 and / or context and awareness OS API 314.

[0130] The Context and Aware OS API 314 maximizes compatibility with devices and the ecosystem. The Context and Aware OS API 314 translates lower-level Context and Aware API 310 calls into API calls suitable for the specific device (e.g., any of devices 120a-h, 200) on which the context broadcast networking primary instance 300 is running. For example, the Context and Aware OS API 314 can be defined in Java or C#, while the Context and Aware API 310 can be defined in C. The OS Adaptation Layer (OSAL) 316 can be configured to implement API translation and / or OS licensing models. OSAL 316 manages API access based on the licensing models and capabilities of different OSs. OSAL 316 ensures that the OS API layer is accessible to clients within a framework defined by a specific device licensing model.

[0131] The Context and Awareness Manager functional layer 308 can be configured to securely manage user account credentials, configurations, and communication with an OAuth server (e.g., 199) and a context broadcast networking server (e.g., 198). The Context and Awareness Manager functional layer 308 can also be configured to access device APIs to configure and bridge all device-specific functionalities supporting context broadcast networking. For example, this could include configuring transport offload 301 and the RF chain of devices (e.g., any of devices 120a-h, 200) to receive and send broadcast communications. The implementation of the Context and Awareness Manager functional layer 308 can be operating system-specific. The Context and Awareness Manager functional layer 308 can communicate with the Context and Awareness Engine 312 via an internal interface.

[0132] The context and awareness engine 312 can be configured to translate high-level context and awareness API information into one or more context and awareness data elements (sometimes referred to herein as FarbiQ data elements for ease of reference). The context and awareness engine 312 can provide registration and callback mechanisms for applications 322, OS components 320, and / or OS services 318, enabling them to be notified when they receive data elements carrying context updates. The context and awareness engine 312 can be the sole functional component that understands the meaning of namespaces (e.g., the FabriQ namespace) and numeric elements. The context and awareness engine 312 can use its understanding of the meaning of data elements to perform inferences and provide higher-level APIs.

[0133] The Context Broadcast Networking Core Function Layer 304 can be configured to handle all data element communications. For this purpose, the Context Broadcast Networking Core Function Layer 304 only needs to know the data element format. On the transmission path, the Context Broadcast Networking Core Function Layer 304 can filter all context and awareness engine 312 requests, apply the necessary Quality of Service (QoS), and schedule transmissions across the appropriate transport offload 301 and the RF chain of the devices (e.g., any of devices 120a-h, 200). On the reception path, the Context Broadcast Networking Core Function Layer 304 can process incoming data (e.g., in an efficient manner), update the shared data element cache 306, and interrupt the appropriate context and awareness engine 312 instances so that the context and awareness engine 312 instances can consume the latest context information conveyed in the data elements. The Context Broadcast Networking Core Function Layer 304 can be configured to process the context as broadcast-ready information. On the transmit path, the Context Broadcast Networking Core Function Layer 304 can receive an input stream of one or more data elements and / or QoS indications, organize the data elements based on the QoS indications, apply account-based security and privacy, select and configure transmission offloading, and / or segment the data element set into PDUs using the Maximum Transmission Unit (MTU) size. On the receive path, the Context Broadcast Networking Core Function Layer 304 can perform account and / or copy filtering, assembly, decryption, store data elements in a shared data element cache, trigger engine instance generation, and / or provide data element cache aging and maintenance. The Context Broadcast Networking Core Function Layer 304 can query the shared data element cache 306 for the latest context.

[0134] The transmission offload 301 can be configured to bridge data output to various radio or protocol transmissions and RF chains of devices (e.g., any of devices 120a-h, 200), such as Bluetooth, mDNS, CHIP, etc.

[0135] In some implementations, the device (e.g., device 120a-h, 200) may include at least one implementation of context broadcast networking primary instance 300. In some implementations, the device (e.g., device 120a-h, 200) may include, for example, Figure 3B The example shown is at least one implementation of the context broadcast networking primary instance 300 and one or more additional context broadcast networking auxiliary instances 350.

[0136] refer to Figures 1A to 3B , Figure 3B This is a component block diagram of the software and hardware architecture of the primary instance 300 and one or more auxiliary instances 350 of the context broadcast networking system, implemented according to various schemes. (Reference) Figures 1A to 3BThe context broadcast networking primary instance 300 and / or one or more auxiliary context broadcast networking auxiliary instances 350 may be part of a System-on-a-Chip (SOC) such as SOC 202, 204. As an example, the context broadcast networking primary instance 300 and / or one or more auxiliary context broadcast networking auxiliary instances 350 may be at least part of modem processor 212, modem processor 252, and / or DSP 210. As another specific example, the context broadcast networking primary instance 300 and / or one or more auxiliary context broadcast networking auxiliary instances 350 may be an add-on to one or both of SOC 202 and / or 204.

[0137] Context broadcast networking assistant instance 350 can extend context broadcast networking operations to other execution environments. Each context broadcast networking assistant instance 350 may include its own corresponding dedicated context and awareness manager function layer 358, context and awareness API 360, context and awareness OS API 364, OSAL 366, and context and awareness engine 362 (similar to reference). Figure 3A The described context and awareness manager functional layer 308, context and awareness API 310, context and awareness OS API 314, OSAL 316, and context and awareness engine 312) support applications 372, OS components 370, and / or OS services 368 native to their respective execution environments for the context broadcast networking auxiliary instance 350. In some embodiments, a device with an application processor and a separate low-power island (e.g., devices 120a-h, 200) may instantiate at least one context broadcast networking auxiliary instance 350. In some embodiments, a device with multiple execution environments and / or dedicated virtual machines (e.g., devices 120a-h, 200) may instantiate several context broadcast networking auxiliary instances 350.

[0138] Figure 3C This is a component block diagram illustrating the software and hardware architecture of Context Broadcast Networking Instance 373 according to various implementation schemes. (Reference) Figures 1A to 3C Context networking instance 373 can be part of a System-on-a-Chip (SOC) such as SOC 202, 204. For example, context broadcast networking primary instance 300 can be at least part of modem processor 212, modem processor 252, and / or DSP 210. As another example, context broadcast networking primary instance 300 can be an additional component of one or both of SOC 202 and / or SOC 204. Context networking example 373 can be similar to reference [reference missing]. Figure 3A The described context broadcast networking primary instance 300 is an alternative exemplary configuration.

[0139] Context broadcast networking instance 373 may include a low-power island 302, an application processor 371 (e.g., 216, etc.), and a low-power island memory 363 (e.g., 220, 258, etc.). Low-power island 302 may include a context broadcast networking core 304, a transport offload 301, and a context and awareness engine 312. Low-power island memory 363 may include a shared data element cache 306.

[0140] In some embodiments, application processor 371 may be a processor with higher power consumption than low-power island 302. In some embodiments, application processor 371 may be a processor and / or processing core configured to support fewer wake-ups per second than low-power island 302. In some embodiments, application processor 371 may be a processor and / or processing core running an advanced operating system (HLOS) 357. In some embodiments, low-power island 302 may be a processor and / or processing core supporting fewer logical operations compared to application processor 371.

[0141] In some implementations, application processor 371 may enter sleep and / or inactive modes periodically, differently from low-power island 302. For example, application processor 371 may enter sleep and / or inactive modes while low-power island 302 is in awake and / or active modes. Alternatively, application processor 371 may enter awake and / or active modes less frequently than low-power island 302 within a given time period.

[0142] In context networking instance 373, one or more radio controllers 355 of a device (e.g., any of devices 120a-120h, 200) can send and / or receive over-the-air (OTA) broadcasts. The one or more radio controllers 355 can be configured to control various radio or protocol transmissions and RF chains of the device (e.g., any of devices 120a-120h, 200), such as Bluetooth, mDNS, CHIP, etc. The radio controllers 355 can output data to both the application processor 371 and the low-power island 302. The radio controllers 355 can receive data from both the application processor 371 and the low-power island 302.

[0143] In some implementations, each radio controller 355 may have at least one interface, such as one or more interfaces 375, leading to the low-power island 302, and at least one interface, such as one or more interfaces 377, leading to the application processor 371. For example, interfaces 371, 375 may be host controller interfaces (HCI) or any other type of interface. The presence of separate interfaces 371, 375 leading to the low-power island 302 and the application processor 371 enables the radio controller 355 to pass received packets to one or both of the low-power island 302 and the application processor 371.

[0144] In some embodiments, the low-power island 302 may be awake or otherwise active more frequently than the application processor 371 during a given time period (e.g., more times per second), and the low-power island 302 may enter the monitoring radio controller 355 and / or receive data from the radio controller more frequently than the application processor 371. In some embodiments, the low-power island 302 may be configured to transmit data and / or receive data from the radio controller 355 when the application processor 371 is not in an active and / or awake mode.

[0145] In some implementations, radio controller 355 may be configured to scan, monitor, listen, or otherwise receive OTA broadcast packets at a periodicity (also referred to as duty cycle) scheduled by a component of one or both of low-power island 302 and application processor 371. For example, HLOS 357 may schedule one or more of radio controllers 355 to scan, monitor, listen, or otherwise receive OTA broadcast packets at a first period (or duty cycle), and context broadcast networking core 304 may schedule one or more of radio controllers 355 to scan, monitor, listen, or otherwise receive OTA broadcast packets at a second period (or duty cycle) different from the first period.

[0146] In context networking instance 373, application processor 371 may run HLOS 357, which may include context and awareness OS API 314, OSAL 316, OS services 318, OS components 320, etc. Additionally, application 322 may run on application processor 371.

[0147] In some implementations, the context networking instance 373 may include an optional low-power client 302, which may run on a low-power client 356 and interface with the OS service 371 of the context and awareness engine 312 and / or application processor 371. The low-power client 356 may be optional because in some implementations, the functionality provided by the low-power client may not be required and / or may be provided by the context and awareness engine 312. In some implementations, the low-power client 356 and / or the context and awareness engine 312 may be configured to wake up and / or activate the application processor 371 when a data element carrying a context update is received. In some implementations, the low-power client 356 and / or the context and awareness engine 312 may provide the data element carrying a context update to the OS service 371. In some implementations, the context and awareness engine 312 may provide the data element carrying a context update to the low-power client 356.

[0148] Although Figure 3A , Figure 3B and Figure 3C An exemplary configuration of the context broadcast networking primary instance 300 and / or context broadcast networking auxiliary instance 350 and / or context broadcast networking instance 373 is shown, but... Figure 3A , Figure 3B and Figure 3C The configurations described are merely illustrative examples and are not intended to be limiting. Other exemplary configurations of context broadcast networking instances, depending on the implementation, may include: a primary instance running on a low-power island; a primary instance running on the lowest power core of the SoC or SIP; a primary instance running on any programmable core of the SoC or SIP; secondary instances running on any other programmable core of the SoC or SIP capable of generating or consuming context data; multiple secondary instances running simultaneously on any other programmable core of the SoC or SIP capable of generating or consuming context data; shared data element caches stored on memory included within the low-power island; shared data element caches stored on any shared memory implemented within the SoC or SIP; and / or shared data element caches stored on any external shared memory accessible to the SoC or SIP.

[0149] A group of devices (e.g., any one or more of devices 120a-h, 200) that have the same account credentials and each has at least one primary instance of a context broadcast network (e.g., 300) may be referred to as a context broadcast network (also referred to herein as a "FabriQ network" for ease of reference). For ease of reference, devices in such a context broadcast network (e.g., any one or more of devices 120a-h, 200) may be referred to herein as "FabriQ nodes". In some embodiments, devices in such a context broadcast network (e.g., any one or more of devices 120a-h, 200) may be inherently mobile, and the composition of the network may change as devices move into and out of each other over time. In some embodiments, devices in such a context broadcast network (e.g., any one or more of devices 120a-h, 200) may not have an assigned role in the network. Instead, in some embodiments, devices in such a context broadcast network (e.g., any one or more of devices 120a-h, 200) may be peers, and each device may alternate between sharing its own context and monitoring or listening to context broadcasts from other devices within a distance.

[0150] Figure 4A , Figure 4B and Figure 4C The variations of the context broadcast network 410 over time according to various implementation schemes are illustrated. (Reference) Figures 1A to 4C , Figures 4A to 4CThe context broadcast network 410 is shown to be from, for example Figure 4A The first time shown is as follows Figure 4B The second time shown and to such Figure 4C The changes at the third time point are shown. Figures 4A to 4C Four devices 401, 402, 403, and 404 are shown. For example, devices 401, 402, 403, and 404 can be any of devices 120a-h, 200 that include at least context broadcast networking instances (e.g., 300, 350, etc.). Figure 4A , Figure 4B and Figure 4C The self-organizing and centrally controllerless nature of a context broadcast network 410 (also referred to as a FabriQ network for ease of reference) according to various implementation schemes is illustrated.

[0151] In such Figure 4A As shown in the initial diagram, wireless devices 402 and 403 may have already formed a context broadcast network 410 (also referred to as a FabriQ network for ease of reference) because wireless devices 402 and 403 are within each other's communication range and can share the same account credentials. Wireless devices 402 and 403 may not have an assigned role in the context broadcast network 410. Wireless device 404 may be within range of at least wireless device 402, but because wireless device 404 may not share account credentials with wireless devices 402 and 403, wireless device 404 may not be part of the context broadcast network 410. Wireless device 401 may share account credentials with wireless devices 402 and 403, but wireless device 401 may be outside the communication range of wireless devices 402 and 403, therefore wireless device 401 may not be part of the context broadcast network 410 at the initial stage.

[0152] Context broadcast network 410 can be established between wireless devices 402 and 403 without requiring either wireless device 402 or 403 to perform network establishment or network availability (or announcement) operations. Instead, each wireless device 402 and 403 may simply send broadcast messages encrypted using shared account credentials. These broadcast messages can be received and decrypted by the receiving wireless device 402 or 403 using shared account credentials. The broadcast message may include data elements without first exchanging network establishment or network availability (or announcement) type messages. The ability of wireless devices 402 and 403 to broadcast and receive such broadcast messages enables the establishment of context broadcast network 410 without any prior network establishment or network availability (or announcement) operations, such that the first message broadcast and received between wireless devices 402 and / or 403 can carry one or more data elements and establish context broadcast network 410.

[0153] In such Figure 4B In the second timeframe shown, wireless device 401 may have moved within range of wireless devices 402 and 403, and wireless device 401 may have become part of the context broadcast network 410 with wireless devices 402 and 403. Wireless device 401 can become part of the context broadcast network 410 by broadcasting or receiving messages that include data elements and are encrypted using shared account credentials. Therefore, the number of nodes in the context broadcast network 410 may increase as the number of wireless devices 401, 402, and 403 sharing account credentials within range of each other may increase. Wireless device 404 may be excluded from the context broadcast network 410 because wireless device 404 may not share account credentials with wireless devices 401, 402, and 403. The ability of wireless devices 401, 402, and 403 to broadcast and receive such broadcast messages enables the establishment of a context broadcast network 410 without any prior network establishment or network availability (or announcement) operation, such that the first message broadcast and received between any of the wireless devices 401, 402, and / or 403 can carry one or more data elements and can also add wireless device 401 to the context broadcast network 410.

[0154] In such Figure 4C In the third timeframe shown, wireless device 403 may have moved out of the distance of wireless devices 402 and 401, and therefore may have been removed from the context broadcast network 410. Consequently, the number of nodes in the context broadcast network 410 may decrease from the second timeframe, as the number of wireless devices 401 and 402 sharing account credentials within their respective distances may decrease as wireless device 403 moves out of the distance. Wireless device 403 may be dropped (or removed) from the context broadcast network 410 simply by its broadcast message being out of the distance of another wireless device 401 and 402, without any specific network drop or cancellation of communication exchanged between wireless devices 401, 402, and / or 403. Wireless device 404 may be excluded from the context broadcast network 410; wireless device 404 may not share account credentials with wireless devices 401 and 402.

[0155] Figure 4D Aspects of simultaneous context broadcast networks 410 and 412 according to various implementation schemes are illustrated. (Reference) Figures 1A to 4D , Figure 4D The network state shown can be similar to that described above. Figure 4A The network state shown differs in that an additional wireless device 405 may be present. For example, the additional wireless device 405 may be any one of wireless devices 120a-120h or 200 that includes at least context broadcast networking instances (e.g., 300, 350, 373, etc.). Figure 4DThe wireless device, such as wireless device 403, is shown to be part of two context broadcast networks 410 and 412 (also referred to as the FabriQ network for ease of reference) according to some implementations.

[0156] For example, wireless device 403 in context broadcast network 410 can be a multi-user / account wireless device. Wireless device 403 can participate in multiple (e.g., two or more) context broadcast networks simultaneously, such as context broadcast network 410 established with wireless device 402 and context broadcast network 412 established with wireless device 405. For example, wireless device 403 can allocate its time to broadcast and receive messages associated with and protected by a first account shared with wireless device 402, thereby forming context broadcast network 410, and simultaneously broadcast and receive messages associated with and protected by a second account shared with wireless device 405, thereby forming network 412.

[0157] Figure 5 The cloud server 520 architecture is illustrated according to various implementation schemes. (Reference) Figures 1A to 5 Cloud server 520 may include context broadcast networking server 522 (e.g., server 198) and one or more OAuth servers 521 (e.g., server 199). Server 520 may perform differentiation functions. OAuth server 521 (e.g., server 199) may determine the unique identity of a device (e.g., device 120a-h, 200, 401-405, etc.). For ease of reference, context broadcast networking server 522 (e.g., server 198) may be referred to herein as a FabriQ server. Context broadcast networking server 522 (e.g., server 198) may securely store account and configuration information. Clients such as applications 322, 372, OS components 320, 370 and / or OS services 318, 368, etc., may not interact directly with cloud server 520. Conversely, clients such as applications 322, 372, OS components 320, 370, and / or OS services 318, 368, etc., can interact with context and awareness managers 308, 358 via APIs 310, 314, 360, and / or 362, which can interface with cloud server 520. Connectivity to context broadcast networking server 522 (e.g., server 198) may not always be necessary. For example, connectivity to context broadcast networking server 522 (e.g., server 198) may only be required during the configuration of new hub wireless devices.

[0158] Figure 6 A method 600 for supporting context broadcast networking, according to various implementation schemes, is shown. References Figures 1A to 6Method 600 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 600 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 6 The component used to perform each of the operations in method 600 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 that execute context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or parts of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0159] In box 602, the processor can perform operations to determine one or more context states, one or more settings, one or more events, and / or one or more capabilities. As an example, the one or more context states, settings, events, and / or capabilities may be associated with a device, a user of the device, and / or an application running on the device. As an example, the one or more context states, settings, events, and / or capabilities may be direct context states, settings, events, and / or capabilities, and / or inferred context states, settings, events, and / or capabilities. Context states may be representations of states or settings associated with the device, such as user settings, device settings, application settings, etc. Events may be observable operations or state changes of the device, such as application start or stop, device power on or off, user input indication (e.g., button press, touchscreen interaction, etc.), device removal from charging case, device placement into charging case, insertion or removal of power cords, reception of sensor information, etc. Contextual data may include device status (e.g., multimedia status, in-ear status, screen activity status, active application status, etc.), user activity (e.g., focusing, gaming, cycling, meetings, etc.), user location (e.g., at home, at work, in a store, attending an event, etc.), and user biometrics (e.g., body temperature, blood sugar, alertness, heart rate, etc.). This one or more contextual states, one or more settings, one or more events, and / or one or more capabilities may be periodically monitored and / or indicated to the processor via interrupts or other reports. The components used to perform the operations of box 602 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0160] In determination box 604, the processor may perform operations to determine whether any of the one or more context states, one or more settings, one or more events, and / or one or more capabilities are associated with broadcast signaling. A series of rules and / or thresholds may govern whether any of the one or more context states, one or more settings, one or more events, and / or one or more capabilities are associated with broadcast signaling. For example, certain changes to a context state may be associated with broadcast signaling. Similarly, certain settings may be associated with broadcast signaling. Similarly, certain events may be associated with broadcast signaling. For example, certain capabilities may be associated with broadcast signaling. The context states, settings, events, and / or capabilities associated with broadcast signaling may be those context states, settings, events, and / or capabilities that may be useful to other devices. The components used to perform the operations of box 604 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0161] In response to determining that none of the context states, settings, events, or capabilities are associated with broadcast signaling (e.g., determining box 604 = "No"), the processor may perform operations in box 602 to determine one or more context states, one or more settings, one or more events, and / or one or more capabilities. Thus, the processor may continue monitoring the context states, settings, events, and / or capabilities until a context state, setting, event, and / or capability associated with broadcast signaling occurs.

[0162] In response to determining that at least one context state, setting, event, and / or capability is associated with broadcast signaling (e.g., determining box 604 = "Yes"), in box 606, the processor may perform operations to generate one or more data elements based at least in part on the one or more context states, settings, events, and / or capabilities. For example, in box 606, the processor may perform operations to generate one or more data elements based at least in part on the one or more context states, settings, events, and / or capabilities associated with broadcast signaling. As an example, the one or more context states, settings, events, and / or capabilities may be associated with a device, a user of the device, and / or an application running on the device. As an example, the one or more context states, settings, events, and / or capabilities may be direct context states, settings, events, and / or capabilities, and / or inferred context states, settings, events, and / or capabilities. In some embodiments, context (and / or event) information may be transmitted in the data element (DE) using a length / tag / data (LTD) format. The LTD format enables context broadcast networking instances (e.g., 300, 350, 373, etc.) to be data agnostic. Data agnosticness enables forward and backward device compatibility. In some implementations, three data element label namespaces can be defined: “core”; “fully qualified”; and “short”. The “core” label namespace may include publicly defined data elements for context and event reporting common to many devices. The “fully qualified” label namespace may include publicly defined or privately defined data elements. The “fully qualified” label namespace may use reverse domain name space (DNS) name notation. The “short” label namespace can be a compact identity of the fully qualified namespace that facilitates efficient transmission. The components used to perform the operations of box 606 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0163] In block 608, the processor can perform operations to form one or more messages including the generated data elements. In some implementations, data elements may be aggregated together, such as based on public service quality (QoS) requirements or other common attributes of the data elements. A data element set (DE set) can be a group of aggregated data elements (DEs). A data element set may include one or more data elements connected together in any order. The data element set may be segmented based on characteristics of the transport layer (or layers) to be used for broadcast transmission, such as the maximum transmission unit (MTU) size of the transport layer. T Other attributes of the transport layer. The segmented data element set may be encrypted, and the encrypted segmented data element set may be packaged for transmission on one or more radio transport layers. In some embodiments, the operation of block 608 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). Components for performing the operation of block 608 may include one or more processors of devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of parts of context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or context broadcast networking cores (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0164] In some implementations, a message can be a private message or a public message. A public message can be operated by all devices within a distance and / or on the same network. A private message can only be understood by devices with the same user account credentials. A private message may not include any plaintext that can be clearly identified or tracked (e.g., device address, values ​​derived from account names, etc.). Both public and private messages may include generator values ​​and sets of data elements. In a private message, the generator value may be obfuscated, and the set of data elements may be encrypted. The generator value can be a time-based value or a counter-based value. The generator value can be encrypted using shared account credentials.

[0165] In block 610, the processor can perform operations to send the one or more messages to one or more transport layers for broadcast transmission. For example, the one or more messages may be packaged into encrypted, segmented sets of data elements and sent to one or more radio transport layers, such as a BLE transport layer, Zigbee transport layer, CHIP transport layer, Wi-Fi transport layer, Bluetooth ACL transport layer, etc. Messages may be sent via more than one transport layer. For example, the same data elements and / or sets of data elements may be sent as repeating messages on two or more different transport layers. In some embodiments, sending the one or more messages to the one or more transport layers for broadcast transmission may include setting backoff conditions for the broadcast of the one or more messages. For example, sending the one or more messages may include setting broadcast intervals and / or repetition values ​​for the one or more messages. In some embodiments, the broadcast interval and repetition value may be adjusted at least in part based on the device's power state. For example, device power state (e.g., battery on, low battery, etc.) entry or exit events may cause adjustments to the broadcast interval and / or repetition value. In some implementations, operation of block 610 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). Components for performing the operation of block 610 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of portions of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or context broadcast networking cores (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0166] As an example, Bluetooth LE announcements can be used to send one or more messages for broadcast transmission. Each encrypted segment can be transmitted in a Service Universally Unique Identifier (UUID) tag using a FabriQ Service UUID. This can be a custom 16-bit or 128-bit Service UUID. Encrypted segments can be announced sequentially. The interval and / or repetition for announcing segments can be based on a backoff scheme. As an example of backoff, the interval for announcing can be set to one of three values. The interval can be set to 125ms whenever the state data changes, and the segments are sent at least 6 times. After this, the interval can be increased to 1 second, and the segments are sent at least 6 times. After this, the interval can be set to 5 seconds. For example, if the state data is segmented into 8 segments, the complete state data will be sent within 1 second, and then repeated 5 times over the next 5 seconds. Then it will be sent completely every 8 seconds for the next 48 seconds. Then it will be sent every 5 seconds, for a total of 40 seconds to fully transmit the state data. This could be a trade-off between quickly sending status information to nearby devices and power efficiency.

[0167] As another example, a Bluetooth ACL can be used to send one or more messages for broadcast transmission. For instance, a FabriQ service can be exposed. This FabriQ service can have a single characteristic that allows it to be read and written. When read, it can return the next available encrypted fragment. When written, it can receive the next available encrypted fragment from the device. This allows the device to read state information from the peer at any time, and to notify the peer of local state changes at any time.

[0168] Figure 7 A method 700 for selecting a data element format according to various embodiments is shown. (Reference) Figures 1A to 7 Method 700 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 700 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 7The component used to perform each of the operations in method 700 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 that execute context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)). In some embodiments, the operation of method 700 may be combined with method 600. Figure 6 The operation of method 700 can be performed as part of the operation in box 606 that generates one or more data elements based at least in part on one or more context states, one or more settings, one or more events, and / or one or more capabilities.

[0169] In response to determining that at least one context state, setting, event, or capability is associated with broadcast signaling (e.g., determining box 604 = "Yes"), in box 701, the processor may perform an operation to generate a data element request. The data element request may be a request for data elements associated with the context state, setting, event, and / or capability associated with the broadcast signaling. The data element request may also be a request for data elements associated with the device, the user of the device, and / or an application running on the device's context state, settings, events, and / or capabilities. The components used to perform the operations of box 701 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0170] In determination box 702, the processor may perform operations to determine whether a data element with a fully qualified name is associated with the data element request. In some implementations, only a subset of data element requests may be associated with a fully qualified name. A fully qualified name may be a predefined assigned name provided to an application or service that enables the application or service to define its own data elements. For example, a fully qualified name may be associated with an OEM, ODM, software company, etc. The components used to perform the operation of box 702 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0171] In response to determining that a fully qualified name is not associated with a data element request (i.e., determination box 702 = "No"), in box 704, the processor may use the core namespace format for the data element. The core namespace format may be publicly available to all applications and services and may not require prior full qualification. Thus, any application or service may enable the use of the core namespace format to generate and use data elements. The components used to perform the operations of box 704 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processor 2 (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., context and awareness manager (e.g., 308, 358), context and awareness engine (e.g., 312, 362) and / or context broadcast networking core (e.g., 304)).

[0172] In response to determining that a fully qualified name is associated with a data element request (i.e., determination box 702 = "Yes"), in determination box 706, the processor may determine whether the fully qualified name is on a short namespace list. This short namespace list may be a list of short namespace labels previously used for fully qualified namespaces. Short namespace labels may be simplified data labels, enabling the use of less data than would have been required to send the fully qualified name itself. The components used to perform the operations of box 706 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0173] In response to determining that a fully qualified name is already in the short namespace (i.e., determining box 706 = "Yes"), in box 708, the processor can use the short namespace format. Thus, once a fully qualified name has been associated with a short namespace label, the same short namespace label can be reused for that data element in the fully qualified namespace. This allows application-to-application communication to occur using both fully qualified and short namespace formats without having to pre-configure labels for fully qualified names to the device. The components used to perform the operations of box 708 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0174] In response to determining that a fully qualified name is not in the short namespace (i.e., determination box 706 = "N"), in box 710, the processor can use a core namespace format with a qualified name label. This qualified name label can be an assigned short name label. Device-triggered short name label generation can support application-to-application communication using both fully qualified and short namespace formats without requiring a label for the fully qualified name to be pre-configured to the device. The components used to perform the operations of box 710 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0175] In box 712, the processor can add a fully qualified name to the list for use in short name resolution. This way, the short name tag is available the next time a request for a data element with the same fully qualified name occurs. Components used to perform the operations of box 712 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), or processors (e.g., 210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a portion thereof (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0176] In response to using the core namespace format in box 704, using the short namespace format in box 708, or adding a fully qualified name to the list for short name resolution in box 712, the processor may proceed to box 608 of method 600. Figure 6 ).

[0177] Figure 8A This is a block diagram illustrating examples of data element formats for core namespace data element 802 and for short namespace data element 804 according to various embodiments. (Reference) Figures 1A to 8A Core namespace data element 802 and / or short namespace data element 804 can be according to method 600 ( Figure 6 ) and / or 700 ( Figure 7 This refers to data elements generated by one or more operations of the core namespace data element 802 and / or short namespace data element 804. In these elements, the length field can be a combined length of the tag and data fields. The length field can be an 8-bit unsigned integer and supports any length from 1 to 255 octets. Each tag value can have a fixed meaning. In some implementations, tags in the core namespace can have a length of one octet. In some implementations, tags in the short namespace can have a length of two octets. In some implementations, fully qualified names that cannot be resolved to the short namespace can be tunneled via core namespace tags. The format of the data field can be determined by the tag. Since tags can have variable lengths, the data can also have variable lengths. The total length of the tag plus the data in core namespace data element 802 and / or short namespace data element 804 can be less than 255 octets. The data fields of core namespace data element 802 and / or short namespace data element 804 can be data associated with context state and / or events. This data may be provided by an application or service (e.g., applications 322, 372) and does not need to be understood by the context broadcast networking core 304 or other aspects of the context broadcast networking instance (e.g., 300, 350, 373, etc.).

[0178] Figure 8B This is a block diagram illustrating examples of message formats for broadcast transmission according to various implementation schemes. (Reference) Figures 1A to 8B The diagram illustrates a public message format 812 and a private message format 814. Public message 812 can be operated by all devices within a distance and / or on the same network. Private message 814 can only be understood by devices with the same user account credentials. Private message 814 may not include any plaintext that can be clearly identified or tracked (e.g., device address, values ​​derived from account names, etc.). Public message 812 or private message 814 may include a generator value and a set of data elements. In private message 814, the generator value may be obfuscated, and the set of data elements may be encrypted. For example, the generator value may be obfuscated according to the Advanced Encryption Standard (AES), and the data elements may be encrypted using a Cipher Block Linked Message Authentication Code (CBC-MAC) (CCM) in a counter according to AES. The generator value can be a time-based value or a counter-based value. The generator value can be encrypted using shared account credentials.

[0179] Figure 8C This is a block diagram illustrating examples of message formats for broadcast transmission according to various implementation schemes. (Reference) Figures 1A to 8C Message 820 can be a public message, such as public message 812, or a private message, such as private message 814.

[0180] Message 820 may include header element 821, such as a one-octet header element, a two-octet header element, or a header element greater than two octets. Header element 821 may indicate the format of message 820. Message 820 may include identity element 822. In some embodiments, identity element 822 may indicate the intended receiving device of message 820 (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). Identity element 822 may include encrypted metadata. In some embodiments, identity element 822 may support duplicate message filtering performed by the receiving device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405).

[0181] In some implementations, the identity element 822 may have a different structure depending on the type of message 820. For example, a public message may have an identity element 822 structure that differs from that of a private message. The size of the identity element 822 may vary. For example, the identity element 822 may be a one-octet element, a two-octet element, a three-octet element, a four-octet element, a header element larger than two octets, etc.

[0182] Figure 8D This is a block diagram illustrating examples of message formats for broadcast transmission according to various implementation schemes. (Reference) Figures 1A to 8D , Figure 8D An example of identity element 827 (e.g., an example of identity element 822) is shown, which includes associated data (AD) element 828, salt element 825, and encrypted metadata key 826.

[0183] AD element 828 may be an account identity value identifying the intended recipient of a private message. Since private messages (e.g., private message 814, etc.) can only be understood by devices with the same user account credentials, AD element 828 enables receiving devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405) to determine whether the message is intended for use by that receiving device or not. AD element 828 may be obfuscated according to AES. In some implementations, AD element 828 may be an account identity value calculated from a hash and truncation time value of an end-user private certificate field.

[0184] The account identity value of AD element 828 can be pre-calculated by a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405) using user account credentials. This pre-calculated account identity value can be referred to as a private AD value. The sending device can write the private AD value into AD element 828 of a private message. The receiving device can compare the pre-calculated account identity value (private AD value) stored at the receiving device with AD element 828 to determine whether the private AD value indicated in AD element 828 matches the stored pre-calculated account identity value (private AD value) calculated by the receiving device using user account credentials. A match between the stored private AD value and the private AD value indicated in AD element 828 indicates that the private message originated from a device with the same user account credentials and is intended for use with that receiving device. A mismatch between the stored private AD value and the private AD value indicated in AD element 828 may indicate that the private message did not originate from a wireless device with the same user account credentials (e.g., from a device with different user account credentials) and is not intended for use with the receiving device.

[0185] A mismatched private AD value may indicate that the message can be ignored and / or discarded. For messages in AD element 828 that have a private AD value that does not match a stored pre-computed account identity value (e.g., a private AD value) calculated by the receiving device using user account credentials, no further processing and / or decryption may be required. For example, such mismatched private AD value messages may not be processed, thereby avoiding processing of salt element 825 and / or encryption metadata key 826. By not consuming processing resources on such mismatched private AD value messages, processing resources and associated power consumption required for processing salt element 825 and / or encryption metadata key 826 can be saved. In some embodiments, the operation required to compare the pre-computed account identity value (private AD value) stored at the receiving device with AD element 828 may be a simple value comparison operation, which requires fewer processing resources and consumes less power than the operation required to decrypt a portion of the message.

[0186] Salt element 825 can be a unique random value for each message. The salt element may not be reused during the certificate's duration. Salt element 825 can have various sizes, such as one octet, two octets, or more than two octets. Salt element 825 can be randomly generated by the sender or sending device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405) sending the message (e.g., messages 814, 820, etc.). Salt element 825 can be unique for the set of data elements (e.g., 823, etc.) and / or messages (e.g., messages 814, 820, etc.). In some implementations, the same salt element 825 may be used across radio transport layers when sending the set of data elements (e.g., 823, etc.) and / or messages (e.g., messages 814, 820, etc.). In some implementations, the same salt element 825 may be used again when retransmitting the data element set of data (e.g., 823, etc.) and / or messages (e.g., messages 814, 820, etc.). For example, data 823 may be transmitted via both the Bluetooth radio transport layer and the Wi-Fi radio transport layer, in which case the salt element 825 may be the same in both messages received via the Bluetooth radio transport layer and the Wi-Fi radio transport layer. As another example, when retransmitting a message with the same data 823, the salt element 825 used in the original transmission may be used in the retransmission of data 823.

[0187] In some implementations, the unique association of salt element 825 with data (e.g., 823, etc.) and / or a set of data elements by the sending and / or transmitting device enables the receiving device to use salt element 825 for duplicate detection and / or filtering. For example, the receiving device may log the value of salt element 825 obtained from received messages (e.g., messages 814, 820, etc.). When subsequent messages are received, the salt element 825 in these subsequent messages can be compared with a log of salt values ​​from the received messages. A match identifying a salt element 825 with a salt value in the log of salt values ​​from the received messages indicates that the subsequent message is a duplicate message carrying received data (e.g., 823, etc.) and / or a set of data elements. If no match is identified by comparing salt element 825 with the log of salt values ​​from the received messages, this indicates that the subsequent message is a new message. The new message can be further processed and / or decrypted. Duplicate messages carrying received data (e.g., 823, etc.) and / or a set of data elements (i.e., messages with salt element 825 that matches the salt value in the salt value log of received messages) may be ignored and / or discarded. Duplicate messages may not be further processed and / or decrypted. For example, processing resources for the encrypted metadata key 826 of duplicate messages may not be incurred. By not processing messages in this way, processing resources and associated power for the encrypted metadata key 826 are saved.

[0188] Encryption metadata key 826 can be a data element encrypted by a device that sends messages (e.g., messages 814, 820, etc.) using user account credentials. Encryption metadata key 826 can be decrypted by a device receiving messages (e.g., messages 814, 820, etc.) using a key associated with the user account credentials (such as a private key associated with the user account credentials). Encryption metadata key 826 can be decrypted, and the data within it can be used, along with a private certificate, to decrypt the set of data elements of data (e.g., 823, etc.) and / or messages (e.g., messages 814, 820, etc.). Successful decryption of encryption metadata key 826 indicates that the message (e.g., messages 814, 820, etc.) was sent from and received from another device with the same account credentials. Failed decryption of encryption metadata key 826 indicates that the message (e.g., messages 814, 820, etc.) was not sent from and received from another device with the same account credentials (e.g., the message was sent from and / or received from a device with a different account).

[0189] Figure 9 This is a block diagram illustrating exemplary message formation for a set of data elements according to various implementation schemes. (Reference) Figures 1A to 9 According to method 600 ( Figure 6 ) and / or 700 ( Figure 7 One or more operations are used to perform message formation. For example, Figure 9 The message formation shown can be in box 608 of method 600 ( Figure 6 It is part of an operation that forms one or more messages, including one or more of the generated data elements. Figure 9 The message formation shown can lead to the formation of private messages, such as private messages 814, 820, etc.

[0190] Data element 902 can be generated in LTD format, for example, as shown in the reference. Figure 8A The core namespace data element 802 and / or short namespace data element 804 are discussed. Data elements may be grouped together as a data element set 903 of n data elements, such as based on common QoS requirements or other common attributes of the data elements. Although any number (n) of data elements can be combined into a dataset, the number (n) may be limited by transport layer constraints. Data element set 903 may include one or more data elements connected together in any order. At any given time, multiple DE sets may be active. DE sets can be used to organize data based on required QoS requirements (such as latency). For example, one group may be used for DE sets that need to be sent immediately (e.g., time-sensitive status information, such as an earplug entering the ear). Other DE sets may be scheduled to be sent at different rates. A DE may be part of more than one DE set.

[0191] The data element set 903 can be segmented into a series of fragments 904 based on the characteristics of the transport layer (or multiple layers) to be used for broadcast transmission, such as the maximum transmission unit (MTU) size of the transport layer. T (or other properties of the transport layer. For example) Figure 9 The diagram illustrates a data element set 903 divided into three segments (segment 0, segment 1, and segment 2). Segment 0 and segment 1 can be the same number of octet bytes, such as an MTU. T One octet, while fragment 2 can be less than or equal to the MTU. T Each octet. When preparing the set of data elements to be sent at the transport layer, it can be based on the MTU. T Divide the data element set into one or more segments. If the length of the data element set is greater than the MTU... T Then each segment before the last segment can have an MTU. T Each segment is 8 bytes. The size of the last segment can be less than or equal to the MTU. T Each segment is an octet. In some implementations, the segment length may vary for various reasons, including different header lengths, the Message Integrity Check (MIC) value being applied to the last segment, etc.

[0192] The first fragment may have a group length field, such as a 14-bit field, which describes the total length of the DE set in octets (such as 1 to 16,383 octets). The first fragment may include a fragment data field of 1 to n octets, which may be the data content of the fragment.

[0193] Each non-first fragment may have a fragment offset field, such as a 14-bit field, which describes the offset to the DE set of the fragment in octets (such as 1 to 16,383 octets). Each non-first fragment may include a fragment data field of 1 to n octets, which may be the data content of the fragment.

[0194] Segmented data element sets can be encrypted into encrypted fragments 905. The encrypted segmented data element sets can be packaged for transmission over one or more radio transport layers. Each encrypted fragment must fit within the maximum length block of the transport layer below. Each encrypted fragment may include a First Fragment Flag (FSF), which can be a 1-bit value. For example, 0 indicates that the fragment is not the first fragment, while 1 indicates that the fragment is the first fragment. The FSF can be set to 1 when the fragment contains the first portion of the state data. Each encrypted fragment may include a Last Fragment Flag (LSF), which can be a 1-bit value. For example, 0 indicates that the fragment is not the last fragment, while 1 indicates that the fragment is the last fragment. The LSF can be set to 1 when the fragment contains the last portion of the state data. Each encrypted fragment may include a Group Length / Fragment Offset field, which can be a 14-bit value. For example, when the FSF equals 1, the length of the DE set can be indicated in the Group Length / Fragment Offset field, and when the FSF equals 0, the offset from the start position of the state data can be indicated in the Group Length / Fragment Offset field. The fragment offset can be an offset to the first octet of state data in the fragment data. Each encrypted fragment may include a generator value field, which can be 8 or 48 bits. The generator value field can be 48 bits when the FSF equals 1, and 8 bits otherwise. This way, if the encrypted fragment sets the first fragment flag, it is the first fragment and will include the complete generated value. Otherwise (e.g., it is not the first fragment), it should include the least significant eight bits of the generated value. The generated value may be changed whenever the state data changes in any way (length, content, etc.) or after a fixed period of time to prevent tracking. For encryption, a temporary random number (nonce) can be created from the generator value and an initialization vector that changes periodically (e.g., every fifteen minutes). The encrypted fragment may include a 32-bit MIC field. This MIC field may only be present when the LSF equals 1. Encryption algorithms such as Advanced Encryption Standard (AES) 128 can be used to encrypt the data, generating encrypted fragmentation information and an encrypted 32-bit MIC. Additional flag bits may be present in the encrypted fragment, and the fragment offset may be less than 14 bits, such as 13 bits.

[0195] Figure 10A , 10B Figures 10C and 10D illustrate exemplary cryptographic fragments according to various implementation schemes. References Figures 1A to 10D , Figure 10A , Figure 10B , Figure 10C and / or Figure 10D The encrypted fragment can be obtained according to method 600 ( Figure 6 ) and / or 700 ( Figure 7 One or more operations and / or as referenced Figure 9 To generate, for example, Figure 10A The complete encrypted fragment is shown, which can be either the first fragment or the last fragment, for example, when only a single fragment is needed to transmit the DE set. Figure 10B An example of the first encrypted segment is shown when more than one segment is needed to transmit the DE set. Figure 10C An example of an intermediate encrypted segment is shown when more than two segments are needed to transmit a DE set. Figure 10D An example of the last encrypted segment is shown when two or more segments are needed to transmit a DE set.

[0196] Figure 11 A method 1100 for selecting an available RF transport layer according to various embodiments is shown. Reference Figures 1A to 11 Method 1100 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 1100 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 11The component used to perform each of the operations in method 1100 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 of the execution of context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or parts of the context broadcast networking instance (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking core (e.g., 304)). In some embodiments, the operation of method 1100 may be as method 600 ( Figure 6 It can be performed as part of an operation. For example, the operation of method 1100 can be performed as part of the operation in block 610 to send a message to the transport layer for broadcast transmission.

[0197] In box 1102, the processor can perform operations to determine QoS requirements. QoS requirements may include latency requirements, signal strength requirements, frequency requirements, etc., for broadcasting data elements to other devices. QoS requirements can be set in various ways, including by triggering data element broadcasting via an application or service, by user settings on the device, or by a context and awareness manager (e.g., 308, 358). QoS requirements ensure that a minimum QoS level is used for the transmission of data elements. The components used to perform the operations of box 1102 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0198] In box 1104, the processor can perform operations to determine power usage requirements. Power usage requirements may include maximum power constraints, battery usage levels, battery charging thresholds, etc. Power usage requirements can be set in various ways, including by triggering data element broadcasts via an application or service, by user settings on the device, or by context and awareness managers (e.g., 308, 358). Power usage requirements ensure that minimum power is used for data element transmission. Power requirements may change or be ignored when the device is charging or when input power is available. The components used to perform the operations of box 1104 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0199] In box 1106, the processor may perform operations to determine the available RF transport layer. The available RF transport layer may be determined based on the availability and / or state of RF radios on the device. For example, the processor may determine whether Bluetooth radio, Wi-Fi radio, Zigbee radio, CHIP radio, 5G radio, etc., are available on the device for transmitting data elements. The available RF transport layer may fluctuate based on various conditions, including user settings on the wireless device, other connection states of the radios on the device, channel conditions, etc. The components used to perform the operations of box 1106 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0200] In box 1108, the processor may select one or more available transport layers that meet QoS requirements and power usage requirements. For example, the processor may apply rule-based criteria to select one or more available RF transport layers that provide a QoS level higher than the minimum QoS requirements for the data element without causing the maximum power usage to be exceeded. Components for performing the operations of box 1108 may include one or more processors of devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0201] Figure 12 A method 1200 for user proximity-based radio resource management according to various embodiments is shown. (Reference) Figures 1A to 12 Method 1200 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 1200 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 12 The component used to perform each of the operations in method 1200 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 that execute context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)). In some embodiments, the operation of method 1200 may be combined with method 600. Figure 6 ), 700 Figure 7 ) and / or 1100 ( Figure 11 The operation is performed by ).

[0202] In determination box 1202, the processor may perform actions including determining whether the context indicates that the user is within a proximity threshold. As the user moves around, the user and the devices the user is interacting with can enter and leave the context broadcast network. For example, when a user moves within a house, the user may move into the radio range of an installed appliance (such as a smart TV) and out of the range of another device (such as a tablet left on a kitchen counter). Some devices may indicate the user's location better than others. For example, a smartwatch may indicate that the user is in a certain area, while the smartwatch moving out of radio coverage may indicate that the user has left that area. Each device may have a user proximity threshold set for that device, which may trigger the device to act differently when the user is likely to be close or when the user is not close.

[0203] Close proximity can be indicated by context determined by the device itself or by context reports in data elements transmitted by other wireless devices. For example, a device determining that it is stationary and that the user's smartwatch and headphones have moved beyond radio range can determine that the context indicates the user has left the device behind and has left home. Similarly, a device determining that the user's smartphone and smartwatch have both entered radio range can indicate that the user is close proximity. Furthermore, close proximity can be determined with high confidence by devices having "body-on" sensors such as body temperature sensors, heart rate sensors, etc., and / or by devices having front-facing cameras that use recognition (e.g., facial recognition on laptops, facial recognition on smartphones, iris recognition on smart glasses, etc.). Such "body-on" sensors and / or recognition-enabled devices can determine whether the user is actually attached to / wearing the device and / or within recognition range, indicating a higher confidence level in the location context of the device compared to devices that may not have "body-on" sensors and / or recognition-enabled devices. Components used to perform the operations of box 1202 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0204] In response to determining that a user is close in proximity (i.e., determining box 1202 = "Yes"), the processor may perform operations to reduce broadcast latency in box 1204 and reduce the monitoring or listening cycle in box 1206. Thus, when a user is close in proximity, the device can broadcast with lower latency and monitor or listen for broadcast messages from other devices more frequently. The components used to perform the operations of each of boxes 1204 and / or 1206 may include one or more processors of devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of parts of context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or context broadcast networking cores (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0205] In response to determining that the user is not in close proximity (i.e., determining box 1202 = "No"), the processor may perform operations to increase the broadcast delay in box 1208 and increase the monitoring or listening cycle in box 1210. Thus, when the user is not in close proximity, the device can broadcast with a higher delay and monitor or listen less frequently, or be otherwise configured to receive broadcast messages from other devices. This allows the device to save power when the user is not in close proximity. The components used to perform the operations of each of boxes 1208 and / or 1210 may include one or more processors of devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of parts of context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or context broadcast networking cores (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0206] Figure 13A Methods for supporting context broadcast networking according to various implementation schemes are illustrated. References Figures 1A to 13AMethod 1300 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 1300 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 13A The component used to perform each of the operations in method 1300 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 that execute context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)). In some embodiments, the operation of method 1300 may be combined with 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ) and / or 1200 ( Figure 12 The operation is performed by ).

[0207] In block 1302, the processor may perform operations including monitoring or listening and receiving broadcast messages on one or more transport layers. In some embodiments, the transport layer may be any transport layer associated with radio available on the device, such as one or more of BLE, Zigbee, CHIP, Wi-Fi, Bluetooth ACL, etc. The device may be woken up and monitored or listened to, or otherwise configured to receive broadcast messages at a selected periodicity. See reference... Figure 12 The periodicity discussed may increase or decrease in response to contextual indications that a user is adjacent to the device. In some embodiments, operation of block 1302 may be performed on a low-power island (or low-power core) (e.g., low-power island 302).

[0208] In some implementations, operation of block 1302 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1302 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1302. Components used to perform the operations of box 1302 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0209] In determination box 1304, the processor may perform an operation including determining whether any message has been received from another device with the same account credentials. The device with the same account credentials may be a device associated with the same user account. Devices associated with the same user account may share a cryptographic key, allowing devices associated with the same user account to decrypt broadcast messages to each other, while other devices may not decrypt the broadcast message. A message successfully decrypted by a device may indicate that the message was sent from and received from another device with the same account credentials. Components used to perform the operations of box 1304 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0210] In some embodiments, operation of block 1304 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1304 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1304 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1304. Similarly, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302 and 1304 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of blocks 1302 and 1304.

[0211] In response to determining that no broadcast message has been received from another device with the same account credentials (i.e., determination box 1304 = "No"), in box 1302, the processor may continue to monitor or listen for and receive one or more broadcast messages on the transport layer, as described. Thus, the processor may monitor or listen for or be otherwise configured to receive messages from other devices with the same account credentials. In some embodiments, the device may ignore broadcast messages determined not to have been received from another device with the same account credentials as that device.

[0212] In response to determining that a broadcast message has been received from another device with the same account credentials (i.e., determining box 1304 = "Yes"), in box 1306, the processor may generate one or more data elements from the broadcast message. For example, the processor may decrypt these fragments and reconstruct the data elements of the dataset. Components for performing the operation of box 1306 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0213] In some embodiments, the operation of block 1306 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, the operation of block 1306 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (such as a high-power operating mode). In some embodiments, determining that a broadcast message has been received from another device with the same account credentials (i.e., determining that block 1304 = "Yes") may trigger a transition from a first operating mode (such as a low-power operating mode) to a second operating mode (such as a high-power operating mode) for performing the operation of block 1306. The second operating mode (such as a high-power operating mode) may be a different operating mode from the first operating mode (such as a low-power operating mode) discussed with reference to blocks 1302 and 1304. The second operating mode (e.g., a high-power operating mode) may require more power and / or consume more processing resources than the first operating mode (e.g., a low-power operating mode).

[0214] For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1306 may be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for processing associated with the operation of block 1306. As another example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302 and 1304 may be performed in a first operating mode (such as a low-power operating mode), wherein only a single core is active and used for processing associated with the operation of blocks 1302 and 1304, and operation of block 1306 may be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for processing associated with the operation of block 1306.

[0215] In box 1308, the processor may send data elements to a shared data cache (e.g., shared data element cache 306). This makes the data elements available to other applications and / or services of the device. Components for performing the operations of box 1308 may include one or more processors of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0216] In some embodiments, operation of block 1308 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1308 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (such as a high-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1308 may be performed in a second operating mode (such as a high-power operating mode) in which two or more cores are active and used for processing associated with the operation of block 1308. For example, when a low-power island (or low-power core) (e.g., low-power island 302) includes more than a single core, the operation of blocks 1302 and 1304 may be performed in a first operating mode (such as a low-power operating mode) in which only a single core is active and used for processing associated with the operation of blocks 1302 and 1304, and the operation of blocks 1306 and 1308 may be performed in a second operating mode (such as a high-power operating mode) in which two or more cores are active and used for processing associated with the operation of blocks 1306 and 1308.

[0217] In box 1310, the processor may signal or send an interrupt indicating that the one or more data elements are available. This interrupt may be signaled or sent to one or more applications and / or services of the device to trigger the application and / or service to retrieve and consume the data element. Components for performing the operations of box 1310 may include one or more processors of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0218] In some embodiments, operation of block 1310 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1310 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (such as a high-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1310 may be performed in a second operating mode (such as a high-power operating mode) in which two or more cores are active and used for processing associated with the operation of block 1310. For example, when a low-power island (or low-power core) (e.g., low-power island 302) includes more than a single core, the operation of blocks 1302 and 1304 may be performed in a first operating mode (such as a low-power operating mode) in which only a single core is active and used for processing associated with the operation of blocks 1302 and 1304, and the operation of blocks 1306, 1308, and 1310 may be performed in a second operating mode (such as a high-power operating mode) in which two or more cores are active and used for processing associated with the operation of blocks 1306, 1308, and 1310.

[0219] Figure 13B Methods for supporting context broadcast networking, according to some implementation schemes, are illustrated. References Figures 1A to 13B In some implementations, the operation of method 1320 can be combined with 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ) and / or 1200 ( Figure 12 Method 1320 may be executed by the operation of the processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 1320 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on the processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by the context and awareness manager (e.g., 308, 358), the context and awareness engine (e.g., 312, 362), and / or the context broadcast networking core (e.g., 304). refer to Figures 1A to 13BThe component used to perform each of the operations in method 1320 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of the components (210, 212, 214, 216, 218, 252, 260) of the execution context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or the context broadcast networking core (e.g., context and awareness manager (e.g., 308, 358), context and awareness engine (e.g., 312, 362) and / or context broadcast networking core (e.g., 304)).

[0220] In block 1302, the processor may perform operations including monitoring or listening and receiving one or more broadcast messages on the transport layer, as described in reference method 1300. Figure 13A The similar numbered boxes are described.

[0221] In block 1322, the processor may perform operations including determining whether a broadcast message has been received. In some embodiments, determining whether a broadcast message has been received may include determining whether any transport layer associated with a radio available on the device (e.g., one or more of BLE, Zigbee, CHIP, Wi-Fi, Bluetooth ACL, etc.) has received the broadcast message. The components used to perform the operations of box 1322 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0222] In some embodiments, operation of block 1322 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1322 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1322 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1322. Again, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302 and 1322 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of blocks 1302 and 1322.

[0223] In response to determining that no broadcast message has been received (i.e., determining box 1322 = "No"), in box 1302, the processor may continue to monitor or listen for and receive one or more broadcast messages on the transport layer, as described. Thus, the processor may monitor or listen for or otherwise be configured to receive messages from other devices.

[0224] In response to determining that a broadcast message has been received (i.e., determination box 1322 = "Yes"), in determination box 1324, the processor may determine whether the account identity value indicated in the broadcast message matches a pre-calculated account identity value. In some embodiments, the account identity value may be calculated or otherwise determined based on the hash and truncation time value of the end-user private certificate field. The account identity value may be pre-calculated by a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405) using user account credentials. The pre-calculated account identity value may be referred to as a private AD value. The sending device may write the private AD value into a private message (e.g., into AD element 828).

[0225] In some implementations, in determination block 1324, the receiving device may compare a pre-calculated account identity value (private AD value) stored at the receiving device with a private AD value indicated in a received broadcast message to determine whether the two private AD values ​​match. A match between the stored private AD value and the private AD value indicated in the received broadcast message (e.g., a match between the account identity value indicated in the broadcast message and a pre-calculated account identity value stored at the receiving device) indicates that the private message originates from a device with the same user account credentials and is intended for use with that receiving device. A mismatch between the stored private AD value and the private AD value indicates that the private message does not originate from a device with the same user account credentials (e.g., from a device with different user account credentials) and is not intended for use with that receiving device.

[0226] In some implementations, comparing a pre-computed account identity value (e.g., a private AD value) stored at the receiving device with AD element 828 may involve a simple comparison operation of the private AD value stored at the receiving device with the private AD value indicated in the received broadcast message, which requires fewer processing resources and / or consumes less power than the operation of decrypting a portion of the message.

[0227] The components used to perform the operations of box 1324 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0228] In some embodiments, operation of block 1324 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1324 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1324 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1324. Similarly, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302, 1322, and 1324 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of blocks 1302, 1322, and 1324.

[0229] In response to determining that the account identity value indicated in the broadcast message does not match a pre-calculated account identity value (i.e., determination box 1324 = "No"), in box 1328, the processor may discard and / or ignore the received broadcast message. A received broadcast message having a private AD value that does not match a stored pre-calculated account identity value (e.g., a private AD value) calculated by the receiving device using user account credentials may be ignored and / or discarded with further processing or decryption. For example, processing may not be expended on such mismatched private AD value messages to decrypt any other portion of the received broadcast message. By avoiding effort on such mismatched private AD value messages, processing resources and / or power can be saved.

[0230] The components used to perform the operations of box 1328 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or a part of a context broadcast networking instance (e.g., a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304)).

[0231] In some embodiments, operation of block 1328 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1328 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1328 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1328. As another example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302, 1322, 1324, and 1328 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of blocks 1302, 1322, 1324, and 1328.

[0232] In response to discarding and / or ignoring broadcast messages in box 1328, in box 1302, the processor may continue to monitor or listen for and receive broadcast messages on one or more transport layers, as described. Thus, the processor may continue to monitor or listen for or otherwise be configured to receive messages from other devices.

[0233] In response to determining that the account identity value indicated in the broadcast message matches a pre-calculated account identity value (i.e., determination box 1324 = "Yes"), in determination box 1326, the processor may determine whether the broadcast message is a duplicate. In some embodiments, the processor may log unique elements of received broadcast messages intended for use with the device, such as salt elements (e.g., salt element 825, etc.) in the received broadcast message (e.g., messages 814, 820, etc.). In some embodiments, the unique association of salt elements with data (e.g., 823, etc.) and / or a set of data elements by the transmitting device and / or the transmitting device enables the salt elements to be used for duplicate detection and / or filtering at the receiving device. In such embodiments, in determination box 1326, the processor may determine whether the broadcast message is a duplicate by comparing the salt elements in the message with a salt value log of received messages. Identifying a match between the salt elements in the received broadcast message and the salt values ​​in the salt value log of received messages may indicate that the received broadcast message is a duplicate message carrying received data and / or a set of data elements. If the comparison does not produce a match between the salt element in the received broadcast message and the salt value log of a received message, this may indicate that the received broadcast message is a new message. Components used to perform the operations of box 1326 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., 300, 350, 373, etc.) and / or processors (210, 212, 214, 216, 218, 252, 260) of a part of a context broadcast networking instance (e.g., context and awareness manager (e.g., 308, 358), context and awareness engine (e.g., 312, 362) and / or context broadcast networking core (e.g., 304)).

[0234] In some embodiments, operation of block 1326 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, operation of block 1326 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a first operating mode (such as a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1326 may be performed in a first operating mode (such as a low-power operating mode) where only a single core is active and used for processing associated with the operation of block 1326. For example, when a low-power island (or low-power core) (e.g., low-power island 302) includes more than a single core, the operation of blocks 1302, 1322, 1324, 1326, and 1328 may be performed in a first operating mode (such as a low-power operating mode), where only a single core is active and used for processing associated with the operation of blocks 1302, 1322, 1324, 1326, and 1328.

[0235] In response to determining that a broadcast message is a duplicate (i.e., determining box 1326 = "Yes"), in box 1328, the processor may discard and / or ignore the received broadcast message. Duplicate messages carrying received data and / or a set of data elements (e.g., those messages with salt elements that match the salt values ​​in the salt value log of the received message) may be ignored and / or discarded without further processing or decryption. For example, such duplicate messages may not be processed. By not expending effort on processing encrypted data on such duplicate messages, processing resources and / or power can be saved.

[0236] In response to discarding and / or ignoring the broadcast message in box 1328, in box 1302, the processor may continue to monitor or listen for and receive broadcast messages on one or more transport layers. Thus, the processor may continue to monitor or listen for and receive messages from other devices.

[0237] In response to determining that the broadcast message is not a duplicate (i.e., determining box 1326 = "No"), in box 1330, the processor may decrypt the encrypted metadata key of the broadcast message. The encrypted metadata key may be a data element that can be encrypted by a device sending messages (e.g., messages 814, 820, etc.) using user account credentials. The encrypted metadata key may be decrypted using a key associated with the user account credentials (such as a private key associated with the user account credentials). The encrypted metadata key can be decrypted, and the data within the encrypted metadata key may be used, along with a private certificate, to decrypt the data and / or set of data elements of the received broadcast message. Successful decryption of the encrypted metadata key indicates that the received broadcast message was sent from and received from another device with the same account credentials. Failed decryption of the encrypted metadata key indicates that the received broadcast message was not sent from and received from another device with the same account credentials (e.g., the message was sent from and / or received from a device with a different account).

[0238] Components used to perform the operations of box 1330 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)).

[0239] In some embodiments, the operation of block 1330 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, the operation of block 1330 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (such as a high-power operating mode). Determining that the broadcast message is not duplicated (i.e., determining that block 1326 = "No") may trigger a transition from a first operating mode (such as a low-power operating mode) to a second operating mode (such as a high-power operating mode). The second operating mode (such as a high-power operating mode) may be a different operating mode from the first operating mode (such as a low-power operating mode) discussed in reference blocks 1302, 1322, 1326, and 1328. The second operating mode (e.g., a high-power operating mode) may require more power and / or consume more processing resources than the first operating mode (e.g., a low-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of block 1330 may be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for processing associated with the operation of block 1330. As another example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, operation of blocks 1302, 1322, 1326, and 1328 may be performed in a first operating mode (such as a low-power operating mode), wherein only a single core is active and used for processing associated with the operation of blocks 1302, 1322, 1326, and 1328, and operation of block 1330 may be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for processing associated with the operation of block 1330.

[0240] In determination block 1332, the processor may determine whether the broadcast message originates from another device with the same account credentials. A device with the same account credentials may be a device associated with the same user account. Devices associated with the same user account may share a cryptographic key, allowing devices associated with the same user account to decrypt each other's broadcast messages, while other devices may not decrypt the broadcast message. In some embodiments, successful or unsuccessful decryption of the encrypted metadata key may indicate whether the broadcast message originates from another device with the same account credentials. Successful decryption of the encrypted metadata key may indicate that the received broadcast message was sent from and received from another device with the same account credentials. Failed decryption of the encrypted metadata key may indicate that the received broadcast message was neither sent from nor received from another device with the same account credentials (e.g., the message was sent from and / or received from a device with a different account).

[0241] Components used to perform the operations of block 1332 may include one or more processors of devices (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors (210, 212, 214, 216, 218, 252, 260) that perform context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)). In some embodiments, the operations of block 1332 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). In some embodiments, the operations of block 1332 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (e.g., a high-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, the operation of block 1332 can be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for the processing associated with the operation of block 1332. As another example, when a low-power island (or low-power core) (e.g., low-power island 302) comprises more than a single core, the operation of blocks 1302, 1322, 1326, and 1328 can be performed in a first operating mode (such as a low-power operating mode), wherein only a single core is active and used for the processing associated with the operation of blocks 1302, 1322, 1326, and 1328, and the operation of blocks 1330 and 1332 can be performed in a second operating mode (such as a high-power operating mode), wherein two or more cores are active and used for the processing associated with the operation of blocks 1330 and 1332.

[0242] In response to determining that a broadcast message does not originate from another device with the same account credentials (i.e., determination box 1332 = "No"), in box 1302, the processor may continue to monitor or listen for broadcast messages on one or more transport layers. Thus, the processor may continue to monitor, listen for, and receive messages from other devices with the same account credentials, while ignoring broadcast messages determined not to have been received from another device with the same account credentials as that device.

[0243] In response to determining that the received broadcast message is from another device with the same account credentials (i.e., determination box 1332 = "Yes"), the processor may perform the operations in boxes 1306, 1308, and 1310 to generate one or more data elements from the broadcast message, send the one or more data elements to a shared data cache, and signal or send an interrupt indicating that the one or more data elements are available, as described in method 1300. Figure 13A The boxes with similar numbering are described. As described with respect to method 1300, in some embodiments, the operation of boxes 1306, 1308, and 1310 may be performed on a low-power island (or low-power core) (e.g., low-power island 302). For example, the operation of boxes 1306, 1308, and 1310 may be performed on a low-power island (or low-power core) (e.g., low-power island 302) in a second operating mode (such as a high-power operating mode). For example, when a low-power island (or low-power core) (e.g., low-power island 302) includes more than a single core, the operation of blocks 1302, 1322, 1326, and 1328 may be performed in a first operating mode (such as a low-power operating mode), in which only a single core is active and used for the processing associated with the operation of blocks 1302, 1322, 1326, and 1328, and the operation of blocks 1306, 1308, 1310, 1330, and 1332 may be performed in a second operating mode (such as a high-power operating mode), in which two or more cores are active and used for the processing associated with the operation of blocks 1306, 1308, 1310, 1330, and 1332.

[0244] In some implementations, security can be anchored to three independent roots of trust and multiple derived keys. Accounts, cloud information, and over-the-air messages are uniquely protected through encryption. User accounts and user account credentials can be the central element used to anchor all API access and inter-device communication. In some implementations, inter-device communication protection ensures user integrity and privacy and protects users from being tracked.

[0245] In some implementations, the provisioning process may enable the device to be routed to a user's account. Providing the device may require at least one hub device to be connected to the Internet. The Internet-connected device associated with the user account may be referred to herein as a hub wireless device or a hub device, or sometimes, for convenience, as a FabriQ hub or FabriQ hub device. The hub wireless device may be configured to act as a proxy for provisioning devices not connected to the Internet. The Internet-unconnected device associated with the user account may be referred herein as an accessory device or multiple accessory devices, or sometimes, for convenience, as a FabriQ accessory or FabriQ accessory device.

[0246] In some implementations, the hub wireless device may have only one active user account per user profile. In some implementations, the hub device may be required to configure accessory devices. In some implementations, the accessory device may allow each pairing instance permitted by the accessory to have one user account associated with it, enabling pairing to devices configured with, for example, account A, account B, or no account or capability. In some implementations, the user account may be associated with OAuth identity. In some implementations, the user account stored on a cloud server (e.g., server 198, 522) may store various types of data, including user-specific persistent storage of key materials for subsequent configuration, a list of registered devices, a subset of cached device data elements, etc. In some implementations, user account access may be granted through applications, web interfaces created by APIs, the operating system itself, etc.

[0247] Figure 14 A method 1400 for equipment configuration according to various embodiments is shown. (Reference) Figures 1A to 14 The operation of method 1400 can be executed by the processor of a cloud server (e.g., server 198, 522). See reference. Figures 1A to 14 The component used to perform each of the operations in method 1400 may be one or more processors of a cloud server (e.g., server 198, 522). In some embodiments, the operation of method 1400 may be combined with 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ), 1200 Figure 12 ), 1300 Figure 13A ) and / or 1320 ( Figure 13B The operation is performed by ).

[0248] In box 1402, the processor can perform operations to receive new hub device registrations. A device associated with a user account and capable of connecting to the Internet may be referred to herein as a wireless hub device or a hub device, or sometimes, for convenience, as a FabriQ hub or FabriQ hub device. The wireless hub device itself, or user equipment other than the wireless hub device, may send a registration request to the server to register a new wireless hub device. This registration request may indicate the user account and / or user of the wireless hub device. The registration request may indicate the type and / or other information of the wireless hub device.

[0249] In determination box 1404, the processor may perform operations to determine whether a user is authorized to register the hub wireless device. Operations in box 1404 may include verifying user authorization with an OAuth server.

[0250] In response to an authorization failure (i.e., confirmation box 1404 = "No"), the processor may return to box 1402 to receive another new hub wireless device registration request.

[0251] In response to successful authorization (i.e., confirmation box 1404 = "Yes"), in confirmation box 1406, the processor may determine whether the user has a context broadcast networking identity (e.g., a FabriQ identity). If the user has previously registered the device, the user may already have a registered identity or profile. If the user has not previously registered the device, a user identity or profile may be created.

[0252] In response to determining that the account does not exist (i.e., confirmation box 1406 = "No"), the processor may create an account for the user in box 1408. As part of creating the account, the user may be offered acceptance of the terms of service.

[0253] In response to creating an account in box 1408 or in response to determining that an account exists (i.e., determining box 1406 = "Yes"), in box 1410, the processor may configure a hub wireless device. Configuring the hub wireless device may include creating cryptographic material and initially establishing a security key for the user account, such as shared account credentials. In some embodiments, shared account credentials may be derived keys, such as keys derived based on OAuth server information and key material from the configuration server. In some embodiments, shared account credentials may be keys stored on the configuration server.

[0254] In box 1412, the processor may update the context broadcast networking server (e.g., 198, 522). For example, device information for hub wireless devices may be uploaded and / or stored on the context broadcast networking server (e.g., 198, 522).

[0255] In box 1418, the processor can determine whether to configure additional accessory devices. For example, additional accessory devices, such as those without internet connectivity, can be used to configure shared account credentials.

[0256] In response to determining that no additional device is configured (i.e., determination box 1418 = "No"), in box 1420, the processor may wait for the unconfigured additional device to connect.

[0257] In response to determining that an additional device needs to be configured (i.e., determination box 1418 = "Yes") or in response to a connection occurring in box 1420, the processor may determine in determination box 1422 whether the user accepts the configuration. For example, the user may be given the option to refuse or accept the configuration of the additional device.

[0258] In response to determining that the user does not accept the configuration (i.e., decision box 1422 = "No"), in decision box 1418, the processor may determine whether to configure more accessory devices.

[0259] In response to determining that the user accepts the configuration (i.e., confirmation box 1424 = "Yes"), the processor may configure the accessory device in confirmation box 1424. Configuring the accessory device may include causing the hub wireless device to send shared account credentials from the hub wireless device to the accessory device.

[0260] In box 1426, the processor may update the context broadcast networking server (e.g., 198, 522). For example, device information for an accessory device may be uploaded and / or stored on the context broadcast networking server (e.g., 198, 522).

[0261] Figure 15A , Figure 15B and Figure 15C Exemplary operations for device registration and configuration according to various implementation schemes are shown. Reference Figures 1A to 15C , Figure 15A , Figure 15B and Figure 15C The registration and configuration operations shown can be performed according to and / or in combination with method 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ), 1200 Figure 12 ), 1300 Figure 13A ), 1320 Figure 13B ) and / or 1400 ( Figure 14 To perform one or more operations. For example, Figure 15A , Figure 15B and Figure 15C The numbered lines in the text correspond to Figure 14 A single numerical designation, and may be represented according to and / or in combination method 1400 ( Figure 14 Registration and configuration operations performed by one or more operations. Figure 15A An exemplary operation for initial account creation and registration of the first hub wireless device is shown. Figure 15B An exemplary operation for subsequent hub wireless device configuration is shown. Figure 15C An exemplary operation for accessory configuration is shown.

[0262] Figure 15AThis demonstrates the ability to provide users with the capacity to enter FabriQ OAuth credentials during the first step of their ODM / EOM setup experience, after they have purchased a new FabriQ-enabled device or after their first FabriQ activation. As described in Request for Comments (RFC) 6749, the authentication service can be provided by OAuth 2.0 using a public authentication server, or directly using FabriQ if it is part of the product offering. This initial step can be performed by the user within an application on a FabriQ-enabled device and may require cloud access.

[0263] Figure 15B This demonstrates a subset of the steps used during initial configuration for registering subsequent hub wireless devices to the same FabriQ account, the difference being that the FabriQ server instance is updated instead of creating a new identity.

[0264] Figure 15C Accessory devices such as earbuds (also known as headphones) may require FabriQ credentials to be configured by a device already registered with FabriQ. For configuration, a device not connected to the internet (e.g., headphones) must first be paired with and connected to a FabriQ-configured device. Triggers for configuring a FabriQ accessory may include: 1) first out-of-the-box use; 2) reconnecting the FabriQ accessory to a FabriQ hub after a FabriQ account has already been configured on the FabriQ hub; and / or 3) using a second pairing jack to pair the FabriQ accessory with another FabriQ hub device that has its own FabriQ account. The FabriQ server instance may be updated upon completion of accessory device configuration.

[0265] In some implementations, the setup experience can be used to view a list of devices associated with an account. In some implementations, the setup experience can be used to remove lost, stolen, or no longer needed devices from an account. In some implementations, the setup experience can be used to close an account. In some implementations, removing a device and / or closing an account can trigger a process in which the FabriQ server notifies the FabriQ Manager on all devices to retrieve the latest account key / credentials. This trigger ensures that remaining devices can continue to obtain / recover the latest credentials and that lost / stolen / or unnecessary devices no longer have access to broadcast to the user / account. In some implementations, the FabriQ Manager on the hub device can verify with the FabriQ server to ensure that their credentials are still valid at startup and can rely on existing credentials for robustness until the server delivers new credentials. In some implementations, when new credentials for an account are received from the FabriQ server, the FabriQ Manager on the hub device can configure the latest key / credential information on connected accessory devices (e.g., in a manner similar to the setup experience). In some implementations, upon account deletion, the FabriQ server can notify the device that the account is no longer valid, thereby triggering the deletion of credentials on the device and its paired accessories.

[0266] In a traditional streaming and playback user experience, a user opens the earbud (or headphone) case and places the earbuds in their ears when in a room containing a smart speaker. The earbuds can be configured by the OEM / ODM to attempt to connect to the last device the earbuds were paired with, or to a range of last known devices. The user picks up their smartphone and starts streaming music using a streaming music app. The user interacts with the streaming music app, the earbud app, or the device's operating system to force a connection between the smartphone and the earbuds. This exemplary traditional experience requires the user to manage connections to audio peripherals, which can be set up through the streaming music app, the earbud app, or the operating system. Such multiple different user interactions required by traditional systems may not be desirable.

[0267] Figure 16A This is a flowchart illustrating a method for changing device settings or application settings according to various implementation schemes. Figures 1A to 16AMethod 1600 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). As an example, the operation of method 1600 may be executed by a context broadcast networking instance (e.g., 300, 350, 373, etc.) executing on a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as by a context and awareness manager (e.g., 308, 358), a context and awareness engine (e.g., 312, 362), and / or a context broadcast networking core (e.g., 304). Reference Figures 1A to 16A The component used to perform each of the operations in method 1600 may be one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as processors 210, 212, 214, 216, 218, 252, 260 that execute context broadcast networking instances (e.g., 300, 350, 373, etc.) and / or portions of context broadcast networking instances (e.g., context and awareness managers (e.g., 308, 358), context and awareness engines (e.g., 312, 362) and / or context broadcast networking cores (e.g., 304)). In some embodiments, the operation of method 1600 may be combined with method 600. Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ), 1200 Figure 12 ), 1300 Figure 13A ), 1320 Figure 13B ) and / or 1400 ( Figure 14 The operation is performed by ).

[0268] In block 1602, the processor may determine a change in user context state based on at least one received data element from another device. This one or more received data elements may have been received from the other device via broadcast transmission. The one or more data elements may indicate the context state of the other device. For example, the one or more data elements may indicate the power state, output state, usage state, etc., of the other device. A context state indicated individually by the one or more data elements, or a context state combined with context state information of the device itself, may indicate that the user context state has changed. For example, indicating that earbuds are in the user's ear and the user is streaming music may indicate that the user most likely wants to use the earbuds to listen to music. Similarly, data elements from a watch indicating that the user is walking and phone context indicating that the user has placed the phone in a stationary position may indicate that the user is moving away from the phone.

[0269] In box 1604, the processor may provide a user of the device with one or more options to change the application state, at least in part, based on a change in the user's context state. For example, the processor may provide a menu of rating options from which the user can select based on a change in the user's context state. For instance, the menu may provide a list of application connectivity changes in response to a change in user context indicating that available devices have changed due to device mobility. The user can then select an option provided to change the application state.

[0270] Figure 16B and Figure 16C Exemplary interactions in a context broadcast network according to various implementation schemes are shown. Figure 16B and Figure 16C It is shown that it can be based on and / or combined with method 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ), 1200 Figure 12 ), 1300 Figure 13A ), 1320 Figure 13B ), 1400 Figure 14 ) and / or 1600 ( Figure 16A An example operation performed by one or more operations of ). Figure 16B and / or Figure 16C The operations shown provide an intuitive user experience, eliminating unwanted user interactions required in traditional systems.

[0271] Figure 16B Exemplary operations are shown to provide a rich streaming playback experience according to various implementation schemes. For example... Figure 16BAs shown, the smart speaker can initially broadcast a message including one or more data elements indicating that the smart speaker is turned on and audio reception is enabled. Users can remove their earbuds from the case and place them in their ears. The earbuds can connect to a last-hand device, such as the user's watch. The earbuds can broadcast a message including one or more data elements indicating that the earbuds are turned on, are an audio receiver for the watch, and are in the user's ears. Users can unlock their phones. In response to being unlocked, the phone can broadcast a message including one or more data elements indicating that the phone is unlocked, the screen lights up, and the phone is active. Users can open a music streaming application. In response to the application opening, the phone can broadcast a message including one or more data elements indicating that the music application is active. The music application can use available context data to generate a pop-up window for the user, providing music playback on the earbuds or smart speaker based on the broadcast message indicating that the smart speaker and earbuds are turned on and available for audio reception. While the earbuds are in the user's ears, they can be prioritized in a list, indicating earbud preferences. The user can select earbuds, and the phone can connect to them. Music streaming applications can stream music from a phone to earbuds, and the phone can broadcast a message containing one or more data elements indicating that audio is being streamed.

[0272] Figure 16C Expanded Figure 16B The example illustrates the impact on user mobility after playback begins on earbuds. Music streaming apps can use contextual information to create pop-up options to transfer playback to a nearby smart speaker. Similarly, a watch can utilize contextual information indicating that the user has left a phone call to activate and bring a music remote app to the foreground. Figure 16B At some point after the actions shown, the user removes the earbuds from their ears and places them in the charging case, as... Figure 16CAs shown. The earbuds can broadcast a message including one or more data elements indicating that the earbuds are removed from the ear and powered off. The earbuds can disconnect from the phone, and the phone can broadcast a message including one or more data elements indicating that audio is off. The music streaming application can pause playback. The music application can use available context data to generate a pop-up window for the user, based on a broadcast message indicating that the smart speaker is on and available for audio reception, and that the phone's own speaker is present, providing music playback on the smart speaker based on available device context information. The user can select the smart speaker. The phone can connect to the smart speaker, and the phone can broadcast a message including one or more data elements indicating that audio is on. The smart speaker can start music playback. The user can put down the phone and start moving around the room. In response to being put down, the phone can broadcast a message including one or more data elements indicating that the phone is not moving. In response to the user moving, the watch can broadcast a message including one or more data elements indicating that the user is moving. In response to the context indicated by the broadcast message and known to the watch, the watch can determine that the music application is active, the user is moving, and the phone is not moving, and activate the remote control music application. The watch can broadcast messages containing one or more data elements that indicate the remote music application is active. Users can interact with the watch to select the next song.

[0273] Figure 17A This is a process flowchart illustrating a method for periodic scan scheduling of a radio controller according to some embodiments. (Reference) Figures 1A to 17A Method 1700 may be implemented by a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). In some embodiments, operation of method 1700 may be combined with method 600 ( Figure 6 ), 700 Figure 7 ), 1100 ( Figure 11 ), 1200 Figure 12 ), 1300 Figure 13A ), 1320 Figure 13B ), 1400 Figure 14 ) and / or 1600 ( Figure 16AThe operation of method 1700 can be performed by a radio controller (e.g., 355, etc.) that operates on the processor (e.g., 210, 212, 214, 216, 218, 252, 260) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). For example, the operation of method 1700 can be performed by a radio controller (e.g., 355, etc.) configured to control various radio or protocol transmissions and RF chains (such as Bluetooth, mDNS, CHIP, etc.) of the device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405). The components used to perform each of the operations of method 1700 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 that perform radio controller (e.g., 355, etc.).

[0274] In box 1702, the processor may receive scan intervals from two hosts. The hosts can be various applications, services, components, cores, firmware, programmable hardware state machines, and / or any programmable entity that can interact with a radio controller (e.g., 355, etc.) to request scan scheduling from the radio controller. For example, the two hosts could be application 322 and context broadcast networking core 304, OS component 320 and context broadcast networking core 304, OS service 318 and context broadcast networking core 304, HLOS 357 and context broadcast networking core 304, etc. The scan interval may define a scan window length and scan period for each of the respective hosts. The scan interval enables the radio controller (e.g., 355, etc.) to schedule scan windows for the hosts. Components used to perform the operation of block 1702 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 that perform the operation of a radio controller (e.g., 355, etc.).

[0275] In block 1704, the processor may determine the priorities of two hosts. In some embodiments, certain hosts may have higher priorities than others. For example, a host associated with an HLOS (e.g., HLOS 357, etc.) may have a primary priority and be given a higher scheduling priority than a host associated with a low-power island (or low-power core) (e.g., low-power island 302), such as a context broadcast networking core (e.g., context broadcast networking core 304, etc.). The host with higher priority may be considered the primary host, and the host with lower priority may be considered the secondary host. Components for performing the operations of block 1704 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 that perform radio controller (e.g., 355, etc.).

[0276] In box 1706, a processor may begin scanning two hosts. For example, a radio controller (e.g., 355, etc.) may begin scheduling RF resources for the two hosts based on a scan window length and scan period indicated in the received scan interval. Components for performing the operations of box 1706 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 performing the operations of a radio controller (e.g., 355, etc.).

[0277] In block 1708, the processor can schedule a primary host scan window. For example, a radio controller (e.g., 355, etc.) can schedule RF resources for the primary host based on the scan window length and scan period indicated in the received scan interval for the primary host. Components for performing the operation of block 1708 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 performing the operation of a radio controller (e.g., 355, etc.).

[0278] In determination box 1710, the processor may determine whether there is overlap between the primary host scan window and the secondary host scan window. Overlap may occur when the secondary host scan window is scheduled while the primary host scan window is active. Components for performing the operation of box 1710 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 executing a radio controller (e.g., 355, etc.).

[0279] In response to determining that there is an overlap between the primary and secondary host scan windows (i.e., determining box 1710 = "Yes"), in box 1712, the processor may cancel the secondary host scan window. Canceling the secondary host scan window prevents radio resources from being consumed on the secondary host scan window. Therefore, when there is an overlap between the primary and secondary host scan windows, the secondary host scan window will not appear. Components used to perform the operation of box 1712 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 that execute a radio controller (e.g., 355, etc.).

[0280] In response to determining that the primary host scan window and the secondary host scan window do not overlap (i.e., determining box 1710 = "No"), in box 1714, the processor may schedule the secondary host scan window. For example, a radio controller (e.g., 355, etc.) may schedule RF resources for the secondary host based on the scan window length and scan period indicated in the received scan interval for the secondary host. Components for performing the operation of box 1708 may include one or more processors of a device (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), such as one or more of processors 210, 212, 214, 216, 218, 252, 260 performing the operation of a radio controller (e.g., 355, etc.).

[0281] Figure 17B Examples of periodic scan scheduling based on various implementation schemes are shown. (Reference) Figures 1A to 17B , Figure 17B The scan scheduling shown is based on method 1700 ( Figure 17A This is a non-restricted example of a scan schedule for the operation execution.

[0282] Figure 17BScan windows 1750a to 1750c associated with an HLOS (e.g., HLOS 357, etc.) having a scan period 1751 are shown, as well as scan windows 1752a to 1752g associated with a low-power island (or low-power core) (e.g., low-power island 302) having a scan period 1753. A radio controller (e.g., 355, etc.) scheduling periodic scans for the HLOS and low-power island can be configured to prioritize scan windows 1750a to 1750c over scan windows 1752a to 1752g. Thus, scan windows 1750a to 1750c can be primary scan windows, and scan windows 1752a to 1752g can be secondary scan windows. When the primary scan window for the HLOS overlaps with the secondary scan window for the low-power island, the radio controller (e.g., 355, etc.) can cancel the secondary scan window. Figure 17B As shown in the combined scan scheduling, since the auxiliary scan windows 1752a, 1752d and 1752f overlap with the main scan windows 1750a, 1750b and 1750c respectively, the auxiliary scan windows 1752a, 1752d and 1752f can be cancelled.

[0283] Various implementation plans (including but not limited to the above references) Figures 1A to 17B The proposed implementation scheme can be implemented on a wide variety of IoT devices. Figure 18 The image shows an example of a circuit board used in a device. (Reference) Figures 1A to 18 The IoT device 1800 (e.g., 120a-h, 200, 401, 402, 403, 404, 405) may include a first SOC 202 (e.g., SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-capable SOC) and a temperature sensor 205. The first SOC 202 and the second SOC 204 may be coupled to internal memory 1806. Additionally, the IoT device 1800 may include or be coupled to an antenna 1804 for transmitting and receiving wireless signals from a wireless transceiver 266 or within the second SOC 204. The IoT device 1800 may include a SIM 1868. The antenna 1804 and the wireless transceiver 266, SIM 1868, and / or the second SOC 204 may support communication using various RATs (including NB-IoT, CIoT, GSM and / or VoLTE, 5G, WiMAX, CDMA-2000, LTE, EGPRS, etc.).

[0284] The IoT device 1800 may also include a voice encoding / decoding (CODEC) circuit 1810 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal provided to a speaker to generate sound supporting voice or VoLTE calls. Furthermore, one or more of the processor, wireless transceiver 266, and CODEC 1810 in the first SOC 202 and the second SOC 204 may include digital signal processor (DSP) circuitry (not shown separately).

[0285] Some IoT devices may include an internal power source, such as a battery 1812 configured to power the SOC and transceiver. Such IoT devices may include a power management component 1816 for managing the charging of the battery 1812.

[0286] Various implementation plans (including but not limited to the above references) Figures 1A to 17B The proposed implementation scheme can also be implemented in any of the various commercially available server devices (such as...). Figure 19 This is implemented on server 1900 (e.g., servers 198, 199, 521, 522) shown in the diagram. See reference. Figures 1A to 19 Such a server 1900 typically includes a processor 1901 coupled to volatile memory 1902 and mass non-volatile memory (such as a disk drive 1903). The server 1900 may also include a floppy disk drive, compact disc (CD), or digital multi-disc (DVD) drive 1906 coupled to the processor 1901. The server 1900 may also include one or more network transceivers 1904 (such as network access ports) coupled to the processor 1901 for establishing network interfaces with communication networks 1907, such as local area networks, the Internet, public switched telephone networks, and / or cellular networks (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular network) coupled to other public system computers and servers.

[0287] Figure 20 This is a component block diagram of the device 2000 applicable to various implementation schemes. (Reference) Figures 1A to 20 Various implementation schemes can be implemented on a wide variety of devices 2000 (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), examples of which are shown in […]. Figure 20The device 2000 is illustrated as a smartphone. It may include a first SOC 202 (e.g., an SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-capable SOC). The first SOC 202 and the second SOC 204 may be coupled to internal memory 2016, a display 2012, and a speaker 2014. Additionally, the device 2000 may include an antenna 2004 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. The device 2000 may include a SIM 2068. The antenna 2004 and the wireless transceiver 266, SIM 2068, and / or the second SOC 204 may support communication using various RATs (including NB-IoT, CIoT, GSM and / or VoLTE, 5G, WiMAX, CDMA-2000, LTE, EGPRS, etc.). Device 2000 may also include a menu selection button or a rocker switch 2020 for receiving user input.

[0288] The device 2000 also includes a sound encoding / decoding (CODEC) circuit 2010, which digitizes the sound received from the microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal provided to the speaker to generate sound. Furthermore, one or more of the processor in the first SOC 202 and the second SOC 204, the wireless transceiver 266, and the CODEC 2010 may include digital signal processor (DSP) circuitry (not shown separately).

[0289] Figure 21 This is a component block diagram of device 2100 applicable to various implementation schemes. (Reference) Figures 1A to 21 Various implementation schemes can be implemented on a wide variety of devices 2100 (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), examples of which are shown in Figure 21 The above describes a wearable computing device in the form of a smartwatch 2100. The smartwatch 2100 may include a SoC 200, as shown in the reference... Figure 2The first SOC (e.g., SOC-CPU) may be coupled to a second SOC (e.g., a 5G-capable SOC). The first SOC 202 and the second SOC 204 may be coupled to internal memories 2104 and 2106. Internal memories 2104 and 2106 may be volatile or non-volatile memories, and may also be secure and / or encrypted memories, or insecure and / or unencrypted memories, or any combination thereof. The first SOC 202 and the second SOC 204 may also be coupled to a touchscreen display 2120, such as a resistive touchscreen, a capacitive touchscreen, an infrared touchscreen, etc. Additionally, the smartwatch 2100 may include one or more antennas 2108 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. Antenna 2108 and wireless transceiver 266 and / or second SOC 204 can support the use of various RATs (such as one or more). Communication with Peanut, Wi-Fi, ANT+, Zigbee, CHIP, etc. The smartwatch 2100 may also include physical virtual buttons 2122 and 2110 for receiving user input, and a swipe sensor 2116 for receiving user input.

[0290] Figure 22 This is a component block diagram of device 2200 applicable to various implementation schemes. (Reference) Figures 1A to 22 Various implementation schemes can be implemented on a wide variety of devices 2200 (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), examples of which are shown in Figure 22The wearable computing device shown is in the form of a wireless headset 1200. The wireless headset 1200 may include a first SOC 202 (e.g., an SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-capable SOC). The first SOC 202 and / or the second SOC 204 may be coupled to internal memory 2206. The internal memory 2206 may be volatile or non-volatile memory, and may also be secure and / or encrypted memory, or insecure and / or unencrypted memory, or any combination thereof. The wireless headset 2200 may also include physical buttons 2214 for receiving user input. Additionally, the wireless headset 2200 may include one or more antennas 2212 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. Antenna 2212 and wireless transceiver 266 and / or first SOC 202 and / or second SOC 204 may support communication using various RATs (such as Bluetooth RAT, Wi-Fi RAT, etc.). Wireless headset 2200 may include speaker 2208 coupled to first SOC 202 and / or second SOC 204 and configured to generate audio output. Wireless headset 2200 may also include microphone 2216 coupled to first SOC 202 and / or second SOC 204 to receive audio input. Wireless headset 2200 may also include various environmental sensors or sensor packages that may include sensors, such as accelerometer 2218 and gyroscope 2219 coupled to first SOC 202 and / or second SOC 204.

[0291] Figure 23 A head-mounted device 2272 is shown that can be configured according to various implementation schemes. (Reference) Figures 1A to 23 Various implementation schemes can be implemented on a wide variety of devices 2272 (e.g., devices 120a-120h, 200, 401, 402, 403, 404, 405), examples of which are shown in Figure 22The image shows a wearable computing device in the form of a head-mounted device 2272 (such as an XR headset). The exemplary head-mounted device 2272 includes a frame 2252, two optical lenses 2254, and a first SOC 202 (e.g., an SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-capable SOC), which is communicatively coupled to an outward-facing world-view image sensor / camera 2258, an inward-facing gaze-view sensor / camera 2260, and a memory 2264. Additionally, the head-mounted device 2272 may include one or more antennas 2290 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. Antenna 2290 and wireless transceiver 266 and / or first SOC 202 and / or second SOC 204 can support communication using various RATs (such as Bluetooth RAT, Wi-Fi RAT, etc.).

[0292] The processors of IoT devices 1800, server 1900, and devices 2000, 2100, 2200, and 2272 can be any programmable microprocessor, microcomputer, or one or more multiprocessor chips that can be configured via software instructions (applications) to perform a variety of functions, including those described in the various implementations below. In some mobile devices, multiple processors may be provided (such as one processor within SOC 204 dedicated to wireless communication functions and another within SOC 202 dedicated to running other applications). Software applications can be stored in memory and then accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0293] As used in this application, the terms "component," "module," "system," etc., are intended to include computer-related entities, such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software being executed, configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. For illustration, both an application running on a device and the device itself can be referred to as a component. One or more components may reside within a process and / or a thread of execution, and components may reside on a single processor or core and / or be distributed across two or more processors or cores. Furthermore, these components can be executed from various non-transitory computer-readable media on which various instructions and / or data structures are stored. Components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, and / or process-related communication methods.

[0294] Several different cellular and mobile communication services and standards are available and envisioned for the future, all of which are feasible and benefit from various implementation schemes. These services and standards include, for example, the 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, 3rd Generation Wireless (3G), 4th Generation Wireless (4G), 5th Generation Wireless (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rate GSM Evolution (EDGE), Advanced Mobile Phone Systems (AMPS), Digital AMPS (IS-136 / TDMA), Evolved Data Optimization (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Global Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Networks (iden). Each of these technologies relates to, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any references to terms and / or technical details relating to individual telecommunications standards or technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the language of the claims.

[0295] The various embodiments shown and described are provided merely as examples illustrating the various features of the claims. However, the features shown and described for any given embodiment are not necessarily limited to the associated embodiment and may be used in conjunction with or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one of the exemplary embodiments. For example, one or more operations of methods 600, 700, 1100, 1200, 1300, 1320, 1400, 1600 and / or 1700 may replace or be combined with one or more operations of methods 600, 700, 1100, 1200, 1300, 1320, 1400, 1600 and / or 1700.

[0296] Various specific implementation examples are described in the following paragraphs. While some of the following specific implementation examples are described according to exemplary methods, other exemplary implementations may include: exemplary methods implemented by a wireless device, as discussed in the following paragraphs, the wireless device including a processor configured to perform operations of these exemplary methods; exemplary methods implemented by a wireless device, as discussed in the following paragraphs, the wireless device including components for performing functions of these exemplary methods; and exemplary methods implemented by a non-transitory processor-readable storage medium storing processor-executable instructions, as discussed in the following paragraphs, the processor-executable instructions being configured to cause a processor of the wireless device to perform operations of these exemplary methods.

[0297] Example 1. A method for supporting context broadcast networking by a device, comprising: generating one or more data elements based at least in part on context state, settings, events, or capabilities; forming one or more messages including the generated data elements; and sending the one or more messages to one or more transport layers for broadcast transmission.

[0298] Example 2. The method according to Example 1, wherein the context state, settings, events, or capabilities are associated with one or more of the device, the user of the device, or an application running on the device.

[0299] Example 3. The method according to any one of Examples 1 to 2, wherein the context state, setting, event or capability is a direct context state, setting, event or capability, or an inferred context state, setting, event and / or capability.

[0300] Example 4. The method according to any one of Examples 1 to 3, wherein generating the one or more data elements is based at least in part on the context state, settings, events, or capabilities includes: determining whether the data element is associated with a fully qualified name; and in response to determining that the data element is associated with a fully qualified name, generating the data element using a short namespace format associated with a fully qualified name.

[0301] Example 5. The method according to any one of Examples 1 to 4, wherein sending the one or more messages to one or more transport layers for broadcast transmission includes selecting one or more available transport layers that meet quality of service requirements and power usage requirements.

[0302] Example 6. The method according to any one of Examples 1 to 5, wherein sending the one or more messages to one or more transport layers for broadcast transmission includes setting a broadcast interval and a repetition value for the one or more messages.

[0303] Example 7. The method according to Example 6, wherein the broadcast interval and the repetition value are adjusted at least in part based on the power state of the device.

[0304] Example 8. The method according to any one of Examples 1 to 7 further includes: determining whether a broadcast message is received from another device having the same account credentials as the device; in response to determining that the broadcast message is received from another device having the same account credentials as the device, generating one or more data elements from the broadcast message; sending the one or more data elements to a shared data cache; and signaling or sending an interrupt indicating that the one or more data elements are available.

[0305] Example 9. The method according to Example 8 further includes: ignoring the broadcast message in response to determining that the broadcast message was not received from another device having the same account credentials as the device.

[0306] Example 10. The method according to any one of Examples 8 to 9 further includes monitoring the broadcast message at one or more transport layers at a selected periodicity.

[0307] Example 11. The method according to Example 10 further includes: increasing the periodicity in response to a user approaching closely; and decreasing the periodicity in response to a user not approaching closely.

[0308] Example 12. The method according to any one of Examples 1 to 11 further includes: determining a change in user context state based on at least one received data element from another device; and providing a user of the device with one or more options to change the application state based at least in part on the change in user context state.

[0309] Example 13. The method according to any one of Examples 1 to 12, wherein: forming one or more messages including the generated data elements is performed on the low-power island.

[0310] Example 14. The method according to Example 13, wherein determining whether a broadcast message is received from another device having the same account credentials as the device is performed on the low-power island.

[0311] Example 15. A method for supporting context broadcast networking by a device, comprising: determining, on a low-power island of the device, interfacing with a radio controller of the device, whether a broadcast message received from the radio controller indicates that an account identity value matches a pre-calculated account identity value; in response to determining that the broadcast message received from the radio controller indicates that the account identity value matches the pre-calculated account identity value, determining on the low-power island of the device whether the broadcast message received from the radio controller is a duplicate message; in response to determining that the broadcast message received from the radio controller is not a duplicate message, decrypting at least a portion of the broadcast message received from the radio controller on the low-power island of the device; in response to decrypting the at least a portion of the broadcast message received from the radio controller, generating one or more data elements from the broadcast message received from the radio controller on the low-power island of the device; sending the one or more data elements from the low-power island of the device to a shared data cache of the device; and signaling from the low-power island of the device to another processor of the device or sending an interrupt indicating that the one or more data elements are available in the shared data cache.

[0312] Example 16. The method according to Example 15, wherein the low-power island is configured such that: determining that a broadcast message received from the radio controller indicates that an account identity value matches a pre-calculated account identity value and determining that the broadcast message received from the radio controller is not a duplicate message occurs when the low-power island is in a first operating mode; decrypting at least a portion of the broadcast message received from the radio controller, generating one or more data elements from the broadcast message received from the radio controller, sending the one or more data elements from the low-power island of the device to the shared data cache of the device, and signaling or sending an interrupt indicating that the one or more data elements are available in the shared data cache occurs when the low-power island is in a second operating mode; and the first operating mode is a lower-power operating mode than the second operating mode.

[0313] Example 17. The method according to any one of Examples 15 or 16, wherein a match between the account identity value indicated in the broadcast message received from the radio controller and a pre-calculated account identity value indicates that the device shares the same account credentials with the device that sent the broadcast message received from the radio controller.

[0314] Example 18. The method according to any one of Examples 15 to 17, wherein determining whether a broadcast message received from a radio controller is a duplicate message includes: comparing the salt value of the broadcast message received from the radio controller with a salt value log; and determining that the broadcast message received from the radio controller is a duplicate message in response to a match between the salt value of the broadcast message received from the radio controller and the salt value in the salt value log.

[0315] Example 19. The method according to any one of Examples 15 to 18 further includes ignoring the broadcast message received from the radio controller in response to: determining that the broadcast message received from the radio controller does not indicate that the account identity value matches a pre-calculated account identity value; or determining that the broadcast message received from the radio controller is a duplicate message.

[0316] Example 20. The method according to any one of Examples 15 to 19 further includes: the low-power island of the device listening to broadcast messages received by the radio controller on the transport layer at a selected periodicity, wherein the selected periodicity is a periodicity different from the periodicity of another processor of the device listening to broadcast messages received by the radio controller on the transport layer.

[0317] Example 21. The method according to Example 20 further includes: increasing the selected periodicity in response to the user being close to the user; and decreasing the selected periodicity in response to the user not being close to the user.

[0318] Example 22. The method according to Example 20, wherein the transport layer is a Bluetooth transport layer.

[0319] Example 23. The method according to any one of Examples 15 to 22, wherein the one or more data elements indicate the context state, settings, events, or capabilities of another device.

[0320] Example 24. A method for periodic scan scheduling for a device's radio controller, comprising: receiving at the device's radio controller a first scan interval from a primary host of the device and a second scan interval from a secondary host of the device; scheduling a primary host scan window by the radio controller based on the first scan interval from the primary host; determining, at least in part, any secondary host scan window that overlaps with any of the scheduled primary host first scan windows by the radio controller based on the second scan interval from the secondary host; and canceling any secondary host second scan window determined to overlap with any of the scheduled primary host first scan windows by the radio controller.

[0321] Example 25. The method according to Example 24, wherein the primary host is associated with an advanced operating system that interfaces with the radio controller, and the secondary host is associated with a low-power island that interfaces with the radio controller.

[0322] Example 26. The method according to any one of Examples 24 or 25, wherein the radio controller is a Bluetooth radio controller.

[0323] Example 27. The method according to any one of Examples 24 to 26, wherein the scanning interval from the primary host of the device defines a first scanning window length, and the scanning interval from the secondary host of the device defines a second scanning window length different from the first scanning window length.

[0324] Example 28. According to the method of Example 27, wherein the scan interval from the primary host of the device defines a first scan cycle, and the scan interval from the secondary host of the device defines a second scan cycle different from the first scan cycle.

[0325] The foregoing method description and process flow diagrams are provided as exemplary examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the given order. As those skilled in the art will appreciate, the operations of the foregoing embodiments can be performed in any order. Words such as “afterward,” “then,” “next,” etc., are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. Furthermore, any reference to a singular claim element (e.g., a reference using the articles “a,” “some,” or “the”) should not be construed as limiting that element to the singular.

[0326] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the claims.

[0327] Hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver intelligent objects, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0328] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operation of the methods or algorithms disclosed herein may be implemented in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and without limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disc storage, disk storage or other magnetic storage smart objects, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically magnetically copy data, while optical discs use laser optics to copy data. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Furthermore, the operation of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium, which may be incorporated into a program product in a computer.

[0329] The above description of the disclosed embodiments is provided to enable any person skilled in the art to implement or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of the claims. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A device for supporting context broadcast networking, comprising: Radio controller; Shared data cache; The processor is coupled to the shared data cache; and Low-power island, coupled to the shared data cache and interfaced with the radio controller, wherein the low-power island is configured as follows: Determine whether the broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value; In response to determining that the broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value, it is determined whether the broadcast message received from the radio controller is a duplicate message; In response to determining that the broadcast message received from the radio controller is not a duplicate message, at least a portion of the broadcast message received from the radio controller is decrypted; In response to decrypting at least a portion of the broadcast message received from the radio controller, one or more data elements are generated from the broadcast message received from the radio controller; Send the one or more data elements to the shared data cache; as well as An interrupt is signaled to the processor indicating that one or more data elements are available in the shared data cache, thereby triggering the processor to retrieve the one or more data elements.

2. The device of claim 1, wherein the low-power island is further configured such that: It is determined that the broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value, and it is determined that the broadcast message received from the radio controller is not a duplicate message occurring when the low-power island is in a first operating mode; Decrypt at least a portion of the broadcast message received from the radio controller, generate one or more data elements from the broadcast message received from the radio controller, send the one or more data elements from the low-power island of the device to the shared data cache of the device, and signal or send an indication that the interruption occurred when the low-power island was in a second operating mode; and The first operating mode is a lower power operating mode than the second operating mode.

3. The device of claim 1, wherein a match between the account identity value indicated in the broadcast message received from the radio controller and the pre-calculated account identity value indicates that the device shares the same account credentials with the device that sent the broadcast message received from the radio controller.

4. The device of claim 1, wherein the low-power island is further configured to determine whether the broadcast message received from the radio controller is a duplicate message by performing the following operations: The salt value of the broadcast message received from the radio controller is compared with the salt value log; and In response to a match between the salt value of the broadcast message received from the radio controller and the salt value in the salt value log, it is determined that the broadcast message received from the radio controller is a duplicate message.

5. The device of claim 1, wherein the low-power island is further configured as follows: The broadcast message received from the radio controller shall be ignored in the following circumstances: Determined that the broadcast message received from the radio controller does not indicate that the account identity value matches the pre-calculated account identity value; or It is determined that the broadcast message received from the radio controller is a duplicate message.

6. The device of claim 1, wherein the low-power island is further configured as follows: The radio controller monitors broadcast messages received at the transport layer using a selected periodicity, wherein the selected periodicity is different from the periodicity of another processor of the device for monitoring broadcast messages received by the radio controller at the transport layer.

7. The device of claim 6, wherein the low-power island is further configured as follows: Increase the selected periodicity in response to the user's close proximity; and The selected periodicity is reduced in response to the user not being in close proximity.

8. The device according to claim 6, wherein the transmission layer is a Bluetooth transmission layer.

9. The device of claim 1, wherein the one or more data elements indicate the context state, settings, events, or capabilities of another device.

10. A method for supporting context broadcast networking performed by a device, comprising: On the low-power island of the device, which is interfaced with the radio controller of the device, it is determined whether a broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value; In response to determining that the broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value, it is determined on the low-power island of the device whether the broadcast message received from the radio controller is a duplicate message; In response to determining that the broadcast message received from the radio controller is not a duplicate message, at least a portion of the broadcast message received from the radio controller is decrypted on the low-power island of the device; In response to the decryption of at least a portion of the broadcast message received from the radio controller, one or more data elements are generated from the broadcast message received from the radio controller on the low-power island of the device; Send the one or more data elements from the low-power island of the device to the shared data cache of the device; as well as The low-power island of the device signals or sends an interrupt indicating that one or more data elements are available in the shared data cache to another processor of the device, thereby triggering the other processor to retrieve the one or more data elements.

11. The method of claim 10, wherein the low-power island is configured such that: It is determined that the broadcast message received from the radio controller indicates that the account identity value matches a pre-calculated account identity value, and it is determined that the broadcast message received from the radio controller is not a duplicate message occurring when the low-power island is in a first operating mode; Decrypt at least a portion of the broadcast message received from the radio controller, generate one or more data elements from the broadcast message received from the radio controller, send the one or more data elements from the low-power island of the device to the shared data cache of the device, and signal or send an interrupt indicating that the one or more data elements are available in the shared data cache when the low-power island is in a second operating mode; and The first operating mode is a lower power operating mode than the second operating mode.

12. The method of claim 10, wherein a match between the account identity value indicated in the broadcast message received from the radio controller and the pre-calculated account identity value indicates that the device shares the same account credentials with the device that sent the broadcast message received from the radio controller.

13. The method of claim 10, wherein determining whether the broadcast message received from the radio controller is a duplicate message comprises: The salt value of the broadcast message received from the radio controller is compared with the salt value log; as well as In response to a match between the salt value of the broadcast message received from the radio controller and the salt value in the salt value log, it is determined that the broadcast message received from the radio controller is a duplicate message.

14. The method of claim 10, further comprising: The broadcast message received from the radio controller shall be ignored in the following circumstances: Determined that the broadcast message received from the radio controller does not indicate that the account identity value matches the pre-calculated account identity value; or It is determined that the broadcast message received from the radio controller is a duplicate message.

15. The method of claim 10, further comprising: The low-power island of the device monitors broadcast messages received by the radio controller on the transport layer at a selected periodicity, wherein the selected periodicity is different from the periodicity of another processor of the device for monitoring broadcast messages received by the radio controller on the transport layer.

16. The method of claim 15, further comprising: Increase the selected periodicity in response to the user's close proximity; as well as The selected periodicity is reduced in response to the user not being in close proximity.

17. The method of claim 15, wherein the transport layer is a Bluetooth transport layer.

18. The method of claim 10, wherein the one or more data elements indicate the context state, settings, events, or capabilities of another device.

19. An apparatus for supporting context broadcast networking, comprising components for performing the method as claimed in any one of claims 10 to 18.

20. A non-transitory computer-readable storage medium for supporting context broadcast networking by a device, the non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method as claimed in any one of claims 10 to 18.

Images