Methods and systems for sharing broadcast source information during audio broadcast sessions

Abstract

This document discloses a method and system for sharing broadcast source information during an audio broadcast session. The method includes: determining, based at least on user input from a user of a sending device and a request from at least one receiving device, whether broadcast source information associated with the audio broadcast session should be shared with at least one receiving device. The method further includes: in response to determining that the broadcast source information should be shared with at least one receiving device, selecting a transmission medium for sharing the broadcast source information by the sending device. Furthermore, the method includes: transmitting one or more data packets including the broadcast source information by the sending device through the selected transmission medium.

Description

Technical Field

[0001] This disclosure relates to wireless communication, and more specifically, to a system and method for sharing broadcast source information during an audio broadcast session. Background Technology

[0002] Today, with the rise of Bluetooth Low Energy (BLE) audio, significant progress has been made in the field of audio streaming. BLE audio supports media streaming using both classic Bluetooth and BLE protocols. Compared to classic Bluetooth, BLE is designed to significantly reduce power consumption. Low Energy (LE) audio has spawned new application scenarios, including multi-stream audio, Low Complexity Communication Codec (LC3), LE audio broadcasting, and personal audio sharing.

[0003] BLE broadcasting involves the concepts of "source," "assistant," and "receiver." The "assistant" role is unique in BLE broadcasting. The broadcast source is the sender of data. The broadcast receiver is the recipient of data. The broadcast receiver receives assistance from the broadcast assistant in locating and connecting to the broadcast source.

[0004] In Wi-Fi access point (AP) information sharing, hotspot details and passwords are exchanged between the hotspot AP (sender) and the client (receiver). In contrast, information about a broadcast source is shared between the broadcast source and auxiliary devices, rather than directly between the broadcast source (sender) and the broadcast receiver (receiver). Wi-Fi AP information includes detailed parameters specific to the Wi-Fi technology, such as the AP name and password. BLE broadcast source information, on the other hand, includes additional data such as the quality of the audio from the source and broadcast-related metadata, such as media player name, track name, artist information, and other relevant information.

[0005] Figure 1 An exemplary scenario 100 depicting Bluetooth Low Energy (LE) audio broadcasting technology for broadcast audio according to existing technology is shown. LE audio introduces broadcast audio into Bluetooth technology, a new feature that enables an audio transmitter 101 to broadcast to an unlimited number of nearby Bluetooth audio receivers (e.g., headphones, earbuds, hearing aids) 103. Broadcast audio opens up tremendous new opportunities for innovation, including powerful new capabilities such as LE audio broadcasting. LE audio broadcasting transmission begins with an LE audio broadcast including announcement messages 105. These announcement messages 105 provide key information about the broadcast, such as the name, metadata associated with the audio stream 109, codec configuration, etc., and one or more audio streams 109 (e.g., stereo audio streams for the left and right channels). The LE audio broadcast transmitter 101 acts as the LE audio broadcast source.

[0006] Additionally, the LE audio broadcasting assistant 107 actively scans these notification messages 105 and presents a user interface (UI) that allows the user to select the LE audio broadcast they wish to join, similar to a user selecting a Wi-Fi network in a public place. Once an LE audio broadcast is selected, the assistant 107 transmits the necessary information to the LE audio broadcasting receivers 103 to allow them to join the broadcast. These receivers 103 are referred to as LE audio broadcasting audio receiving devices, or "scanning commissioners."

[0007] In certain scenarios, a User Equipment (UE) can act as both a LE audio broadcast source and a LE audio broadcast assistant. In this case, the UE is referred to as a "concurrent LE audio broadcast source and assistant." Furthermore, when the UI for selecting the LE audio broadcast source is unavailable, it offloads the scanning function to the LE audio broadcast assistant through a role referred to as the "LE audio broadcast scan commissioner." In such cases, the LE audio broadcast receiving device assumes the dual roles of "LE audio broadcast scan commissioner" and "LE audio broadcast receiver."

[0008] In addition, to join a regular LE audio broadcast, users typically use methods such as searching, scanning, or tapping. In the search method, the user (i.e., the audio broadcast receiver) uses their broadcast assistant—usually a device with a user interface, such as a phone, tablet, or watch—to find and join the LE audio broadcast; similar to a user searching for and connecting to a Wi-Fi network, for example, using broadcast source 1. In the scanning method, the user uses their broadcast assistant to scan a quick response (QR) code, thus seamlessly joining the broadcast. In the tapping method, the user, for example, uses their broadcast assistant to tap the LE audio broadcast transmitter, much like the "tap to pay" method, to access the broadcast. However, traditional methods of accessing broadcasts have several drawbacks, especially when a group of users attempts to join the same broadcast. These problems include the following:

[0009] Duplicate broadcast names: When multiple broadcast sources use the same name, it can confuse users. For example, if multiple broadcasters use the name "Broadcast Source 1", users may have difficulty determining which is the correct source because the LE audio specification does not require unique broadcast names.

[0010] Password sharing: If the broadcast is protected, users will need to manually enter a password after finding and selecting the broadcast. This can be inconvenient and error-prone, especially in public places.

[0011] Multiple user actions: Users must go through several steps—finding the broadcast, selecting the broadcast, and synchronizing information between their device and the broadcast source. In group scenarios, this can lead to excessive power consumption and latency because each member performs these steps.

[0012] Fixed QR code display: QR codes are usually static, meaning users need to physically move near the code to scan and join the broadcast. If the QR code is displayed in printed form, each user must approach it, which is often inefficient in crowded or large spaces.

[0013] Fixed Near Field Communication (NFC) Touch Terminals: Similar to QR codes, NFC touch terminals are also stationary. Users must walk close to the touch terminal to touch it and join the broadcast, which can create a potential bottleneck in busy environments.

[0014] Risk of joining a malicious broadcast: Malicious broadcasters may impersonate legitimate LE audio broadcast sources. If a user accidentally connects to these sources, they may risk receiving harmful data that could damage their device.

[0015] These issues highlight the challenges of current approaches to incorporating LE audio broadcasting, particularly in group settings where efficiency, security, and ease of use are paramount.

[0016] Figure 2 A timing diagram 200 depicting audio broadcasting using Broadcast Isochronous Stream (BIS) according to the prior art is shown. BIS transmits data using a connectionless isochronous channel. Specifically, BIS does not require acknowledgment from the user or receiver. Furthermore, BIS enhances its robustness by repeating the same audio packets, which helps maximize the likelihood of successful reception by the audio receiver.

[0017] Figure 3 Example 300 depicting periodic announcement (PA) events from the same announcement set according to the prior art is shown. Periodic announcements are used when data needs to be sent at regular, fixed intervals. This form of announcement involves sending announcement messages at fixed intervals, with the announcement message data changing occasionally. Periodic announcements also utilize offloading, where announcement messages are first sent on the primary channel, pointing to auxiliary packets located on secondary channels. Additionally, upon receiving instructions from the host, the scanner searches for periodic announcement synchronization information set in the SyncInfo field of the AUX_ADV_IND PDU to scan for periodic announcement messages.

[0018] Figure 4 An example 400 of a broadcast isochronous synchronization group (BIG) for broadcast audio according to the prior art is shown. The process begins when a user starts playing music, causing the user's device (referred to as a "mobile device") to initiate music broadcasting. The mobile device (including an auxiliary device) displays a list of all nearby broadcast sources and allows the user to select one. In this example, the user selects the broadcast source "ABC Music," and audio streaming is subsequently initiated via the selected broadcast.

[0019] Figure 5 Example 500 depicts an Extended Announcement (EA) for a BIG according to existing technology. Following the previous Example 400, Example 500 details how broadcasts utilize the main announcement channel. Each Broadcast Isochronous Synchronization Group (BIG) requires its own personalized announcement set, which includes ADV_EXT_IND packets. Additionally, AUX_ADV_IND is transmitted over 37 common channels, each containing BIG-specific announcement data. This data includes a Universally Unique Identifier (UUID) for the broadcast audio announcement service and UUIDs for other services.

[0020] In addition, the AUX_SYNC_IND package utilizes the Additional Controller Advertisement Data (ACAD) field to identify BIGInfo and AdvData. This information is used to determine the Basic Audio Broadcast Service UUID and the broadcast audio base, ultimately enabling the creation and transmission of the BIS.

[0021] Additionally, according to existing technology, the Broadcast Audio Stream Endpoint (BASE) is transmitted in a Periodic Announcement (PA) packet. The BASE is used to inform the scanning device of the codec configuration and other metadata related to the Broadcast Isochronous Group (BIG), which carries one or more broadcast audio streams.

[0022] In addition, the Broadcast Audio Scanning Service (BASS) is a service initiated in the receiver to expose detailed information about broadcast audio streams known to the BASS, which broadcast audio stream(s) the BASS is connected to, and whether the BASS needs a broadcast assistant to help manage this information and establish connections. Furthermore, the BASS works in conjunction with the broadcast assistant to manage broadcast connections selected and managed by the user. The BASS is a key part of extending the broadcast ecosystem, using BLE connections to facilitate the distribution and control of broadcast information. Table 1 below illustrates the characteristics of the BASS:

[0023] [Table 1]

[0024]

[0025] The device that carries the BASS and manages its characteristics is called a BASS server, which can include devices such as earbuds, headphones, and hearing aids. On the other hand, the device that interacts with the BASS characteristics is called a BASS client, which can include phones, tablets, televisions, and watches. Furthermore, source operation involves the following process: the BASS client shares broadcast source information with the BASS server and requests the BASS server to synchronize with the PA emitted by the broadcast source, and subsequently synchronizes with the BIS from the broadcast source.

[0026] Figure 6A diagram depicting a periodic announcement synchronization transmission (PAST) 600 according to the prior art is shown. In this process, a broadcast assistant 603 scans for announcement messages indicating the presence of extended announcement messages, operating similarly to any other scanning device. These announcement messages can be broadcast by an audio source 601. Once the broadcast assistant 603 detects these announcement messages, it can synchronize with the associated periodic announcement sequence, which includes the broadcast audio announcement service UUID. The broadcast assistant then identifies the accompanying BIGInfo and BASE structures. Before reading and parsing the BASE metadata, the broadcast assistant 603 can apply filtering operations to the scan results. It then provides the user with a list of available broadcast streams, typically displaying human-readable "ProgramInfo". Once the user makes a selection, the broadcast assistant 603 uses the PAST process to transmit the relevant information to the broadcast receiver (also called the broadcast receiver end) 605. This allows the broadcast receiver 605 to directly access the appropriate announcement packet, retrieve BIGInfo and BASE, and synchronize with the broadcast isochronous synchronization stream (BIS) without performing an additional scan. This efficient process is called PAST.

[0027] Figure 7 A sequence flowchart 700 of broadcast stream rendering (BSR) according to the prior art is shown. Figure 7 As shown, in steps 701a and 701b, an LE connection is established between audio source 702 (e.g., a mobile device) and left earbud 704 and right earbud 706. In step 703, the user clicks the "Find Broadcast" button to locate nearby broadcast sources. In step 705, the mobile device finds the broadcast source, and the user clicks on the listed broadcast source in the UI. In step 707, audio source 702 sends an add source command to left earbud 704. In step 709, audio source 702 sends an add source command to right earbud 706. In step 711, left earbud 704 and right earbud 706 request PAST information from audio source 702. In step 713, audio source 702 sends PAST information to both earbuds 704 and 706. In steps 715a and 715b, earbuds 704 and 706 are now synchronized with PA and simultaneously synchronized with BIS. In steps 717a and 717b, both earpieces 704 and 706 begin rendering the BIS package.

[0028] In addition, the broadcast code is used to decrypt the encrypted BIS. The "SetBroadcast_Code" operation is used by the user to provide the broadcast code to the server, enabling the server to decrypt the encrypted BIS. Broadcast assistants can obtain the broadcast code using out-of-band methods, such as via Bluetooth, NFC, or QR codes, as shown in Table 2 below:

[0029] [Table 2]

[0030]

[0031] In the existing method of joining LE audio broadcasts by scanning and selecting sources, each user must navigate to a connection page for multiple user actions. The user clicks the "Find a Broadcast" button. Then, the user scans for and selects a broadcaster. The user then sends synchronization information to the broadcast receiver to join the broadcast. When a group of users must perform these steps individually, it results in unnecessary power consumption and latency before each user connects. For example, a group of four users visits a location where broadcast source 1 is playing a silent TV broadcast. The first user decides to listen to the music playing on the silent TV in the location and connects their earphones to their phone. This user navigates to the earphone connection page, clicks "Find a Broadcast," and waits for available broadcasts to be listed. After selecting the broadcast on the silent TV, the user enters a password, synchronizes to the broadcast, and begins listening. However, when the second, third, and fourth users attempt to synchronize to the same broadcast, these users must repeat the entire process individually because the broadcast cannot be shared. This results in each user consuming approximately 4 to 5 mAh of power, and the entire synchronization process takes approximately 8-10 seconds per user.

[0032] In another exemplary scenario, a group of four users are in a shopping mall. Each store in the mall may have a broadcast source for broadcasting products / discounts / entertainment. If multiple broadcast sources with the same name exist in any area, users are likely to not find a broadcast source of interest, or join a broadcast with the same name, or even worse, join a broadcast source that maliciously mimics other sources. For example, the first user (User 1) wants to connect to a burger shop broadcast source called "Broadcast Source 2." However, there are multiple broadcasters with the same name. Similarly, the second user (User 2) tries to search for a broadcast source called "Fashion." However, their screen displays multiple other broadcast sources. Furthermore, the third user (User 3) connects to Broadcast Source 2. However, they find that it is a different broadcaster with the same name, and the broadcast source they want is not even listed in the user interface (UI). This could also be a malicious broadcast source. Similarly, because there are multiple broadcasters with the same name, the fourth user (User 4) wants to connect to the "Broadcast Source 2" broadcast source by touch / QR code, but they are far away from the broadcast source.

[0033] In another example of broadcast code and password sharing, a group of four users are watching a football match, and the first user turns on a private broadcast on their TV to minimize disturbance to their neighbors. The first user (User 1) connects to this private broadcast via a phone scan and sync using their earpiece. To do this, the first user (User 1) navigates to the earpiece connection page, clicks the "Find Broadcast" button, waits for the broadcast to appear, and then enters the password to sync and listen. However, the second, third, and fourth users (User 2, User 3, and User 4) must repeat this entire process to access the same football broadcast because the broadcast stream cannot be directly shared. As a result, each user must manually access their TV settings to display the QR code for the broadcast code or rely on the first user to verbally share the password with them. This limitation of traditional broadcasting not only creates unnecessary steps but also leads to wasted time and effort, complicating the experience for all participating users.

[0034] Figure 8 Example 800 depicting a malicious broadcast scenario according to existing technology is shown. In this scenario, a user and a friend are in a public place surrounded by multiple LE audio broadcast sources from various locations such as convenience stores, public transportation systems, restaurants, and gas stations. While most of these sources are genuine, some may be malicious imposters designed to mimic real LE audio broadcast sources by using the same names and metadata. These fake broadcast sources may mislead LE audio broadcast consumers, tricking them into connecting to a malicious source; this malicious source may transmit harmful data via broadcast isochronous synchronization streams. The user's friend (the second user) informs the first user to connect to an LE audio broadcast source at a bus stop to obtain real-time bus updates. However, due to the lack of a clear method to distinguish between genuine and fake broadcast sources, the first user is at high risk of unwittingly joining a malicious broadcast at a fake bus stop. This could have serious consequences, as the user may unknowingly receive and interact with malicious data. This scenario highlights the importance of establishing mechanisms to verify and authenticate LE audio broadcast sources to protect users from such threats.

[0035] Currently available audio data sharing methods do not support the re-sharing of broadcast sources. Furthermore, current methods require cumbersome steps to join a broadcast, resulting in high power consumption and high latency when joining.

[0036] Current methods for joining LE audio broadcasts have revealed some significant drawbacks, especially when a group of users attempt to connect to the same broadcast. These issues can drastically degrade the user experience, and as audio broadcast applications become more widespread, these challenges urgently need to be addressed. Some of these drawbacks are as follows:

[0037] Duplicate broadcast names: When a user attempts to join a broadcast, each user must navigate to the earphone connection page, click "Find Broadcasts," and scan for available broadcasters. If multiple broadcast sources use the same name (e.g., "Broadcast Source-1" or "Broadcast Source-2"), this can confuse users because the LE audio specification does not mandate unique broadcaster names. This lack of clear identification makes it difficult for users to determine which broadcaster to choose, resulting in a frustrating user experience—especially in environments with a large number of similar broadcast sources.

[0038] Poor user experience (multiple user actions): Connecting to a broadcast involves several repetitive steps: navigating to the earbud connection page, finding the broadcast, selecting the broadcaster, and syncing with the earbuds. If a group of users attempts to connect to the same broadcast, each user must go through this process independently, resulting in unnecessary time delays and power consumption. It is estimated that this process can take approximately 8-10 seconds per user and consume approximately 4-5 mAh of battery power. This lengthy and energy-intensive process is both inconvenient and inefficient, especially in group scenarios.

[0039] Password sharing: When broadcasting is protected, users must manually enter a password to join. Each user must find and accurately enter the password, adding further obstacles to the process. This step is cumbersome, especially in group settings that require multiple password sharing sessions.

[0040] The risk of joining malicious broadcast sources: Malicious attackers may spoof broadcast sources by mimicking the names of legitimate broadcasters (e.g., using the same audio broadcast source name). This poses a security risk because users may inadvertently connect to harmful broadcast sources that could transmit malicious data to their devices. The lack of reliable mechanisms for verifying and distinguishing legitimate sources from fake ones exacerbates user vulnerability.

[0041] The fixed nature of QR codes and NFC touch terminals: QR codes and NFC touch terminals offer alternatives to joining broadcasts, but users must be physically present and remain in a fixed location. This requires each user to walk up to the QR code or NFC terminal to scan or touch and join the broadcast. This method is inconvenient, especially in crowded spaces, and limits the flexibility of joining broadcasts remotely or seamlessly.

[0042] However, there is currently no technology in audio broadcasting that allows a user connected to the broadcast to share that connection information with another user. As a result, each user must go through the entire process independently, leading to inefficiency and a poor user experience. In addition, this process consumes unnecessary battery power (4-5mAh) and takes 8-10 seconds, further reducing user satisfaction.

[0043] Given the increasing use of audio broadcasting, these issues are becoming more prominent and urgently need to be addressed to improve the overall user experience, simplify the connection process, and reduce security risks.

[0044] Therefore, in view of the above problems, it is advantageous to provide an improved system and method that can overcome the above problems and limitations related to audio broadcasting. Summary of the Invention

[0045] Solution to the problem

[0046] This summary is provided to introduce some concepts in a simplified format, which will be further described in the detailed description of the invention. This summary is not intended to identify key or essential inventive concepts of the invention, nor is it intended to define the scope of the invention.

[0047] According to embodiments of this disclosure, a method for sharing broadcast source information during an audio broadcast session is disclosed herein. The method includes: determining, by the sending device, whether broadcast source information associated with the audio broadcast session should be shared with at least one receiving device, based at least on user input from a user of a sending device and a request from at least one receiving device. The method further includes: in response to determining that the broadcast source information should be shared with at least one receiving device, selecting a transmission medium for sharing the broadcast source information by the sending device. Furthermore, the method includes: transmitting one or more data packets including the broadcast source information by the sending device through the selected transmission medium.

[0048] According to embodiments of this disclosure, a system for sharing broadcast source information during an audio broadcast session is disclosed. The system includes at least one processor configured to: determine, based at least on user input from a user of a transmitting device and a request from at least one receiving device, whether broadcast source information associated with the audio broadcast session should be shared with at least one receiving device. The at least one processor is further configured to: select a transmission medium for sharing the broadcast source information in response to determining that the broadcast source information should be shared with at least one receiving device. The at least one processor is further configured to: transmit one or more data packets including the broadcast source information via the selected transmission medium.

[0049] To further illustrate the advantages and features of the invention, a more specific description of the invention will be given with reference to specific embodiments of the invention shown in the accompanying drawings. It should be understood that these drawings depict only exemplary embodiments of the invention and should not be considered as limiting its scope. The invention will be described and explained with reference to additional features and details, as well as the accompanying drawings. Attached Figure Description

[0050] These and other features, aspects, and advantages of the invention will become better understood when the following detailed description is read with reference to the accompanying drawings; throughout the drawings, similar reference numerals denote similar parts, wherein:

[0051] Figure 1 An exemplary scenario depicting Bluetooth Low Energy (LE) audio broadcasting technology for broadcasting audio according to existing technology is shown;

[0052] Figure 2 A timing diagram depicting audio broadcasting using broadcast isochronous synchronization stream (BIS) according to the prior art is shown;

[0053] Figure 3 Example 400 depicts periodic notification (PA) events from the same notification set according to the prior art;

[0054] Figure 4 An example of a broadcast isochronous synchronization group (BIG) for broadcast audio according to the prior art is shown;

[0055] Figure 5 An example depicting an Extended Announcement (EA) for BIG based on existing technology is shown;

[0056] Figure 6 A diagram depicting the Periodic Notification Synchronization Transmission (PAST) according to the prior art is shown;

[0057] Figure 7 A sequence flowchart of broadcast stream rendering (BSR) according to the prior art is shown;

[0058] Figure 8 An example depicting a malicious broadcasting scenario based on existing technology is shown;

[0059] Figure 9 A scenario illustrating the sharing of broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure is shown;

[0060] Figure 10 A flowchart illustrating a method for sharing broadcast source information during an audio broadcast session according to one or more embodiments of the present disclosure is shown;

[0061] Figure 11a and Figure 11b A sequence flowchart of an exemplary method for sharing broadcast source information among broadcast auxiliary devices according to one or more embodiments of the present disclosure is shown;

[0062] Figure 12 Line diagrams depicting a method for sharing broadcast source information between broadcast assisting devices using near field communication (NFC) according to one or more embodiments of the present disclosure are shown.

[0063] Figure 13 A line diagram depicting a method for sharing broadcast source information between broadcast auxiliary devices using QR codes, according to one or more embodiments of the present disclosure, is shown.

[0064] Figure 14 Line diagrams depicting a method for sharing broadcast source information between broadcast auxiliary devices using near-field sharing, according to one or more embodiments of the present disclosure;

[0065] Figure 15 Line diagrams depicting a method of sharing broadcast source information between broadcast auxiliary devices using network services, according to one or more embodiments of the present disclosure;

[0066] Figure 16 A scenario is illustrated where a server is used to share broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure;

[0067] Figure 17 A scenario is illustrated using directional broadcasting to share broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure;

[0068] Figure 18 Examples illustrating the reduction of the risk of joining malicious broadcasts according to one or more embodiments of this disclosure are shown;

[0069] Figure 19 Use case scenarios for sharing broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure are illustrated;

[0070] Figure 20 One or more embodiments according to this disclosure are shown, targeting Figure 23 An exemplary scenario is illustrated by a line diagram depicting the steps of a method for sharing broadcast source information between broadcast auxiliary devices;

[0071] Figure 21 An architecture of a system for sharing broadcast source information among broadcast auxiliary devices according to one or more embodiments of the present disclosure is shown;

[0072] Figure 22 An environment for sharing broadcast source information via buttons in a broadcast-assisted user interface (UI) according to one or more embodiments of the present disclosure is illustrated; and

[0073] Figure 23 A block diagram of a system for sharing broadcast source information during an audio broadcast session according to one or more embodiments of the present disclosure is shown.

[0074] Furthermore, those skilled in the art will recognize that the elements shown in the figures are for the sake of brevity, and that the elements in the figures need not be drawn to scale. For example, the flowcharts illustrate the methods according to the most prominent steps involved to aid in understanding various aspects of the invention. Moreover, in terms of the construction of the apparatus, one or more components of the apparatus may have been represented in the figures by conventional symbols, and the figures may show only those specific details relevant to understanding embodiments of the invention, so that the figures are not obscured by details that would be obvious to those of ordinary skill in the art benefiting from the description herein. Detailed Implementation

[0075] To facilitate an understanding of the principles of this disclosure, reference will now be made to various embodiments and the specific language to be used in describing these embodiments. However, it will be understood that this is not intended to limit the scope of this disclosure, and such changes and further modifications made to the illustrated systems, as well as such further applications of the principles of this disclosure illustrated therein, are things that would normally occur to those skilled in the art to which this disclosure pertains.

[0076] Those skilled in the art will understand that the foregoing general description and the following detailed description are for the purpose of interpreting this disclosure and are not intended to limit this disclosure.

[0077] Whether a feature or element is limited to being used only once, it may still be referred to as “one or more features” or “one or more elements” or “at least one feature” or “at least one element”. Furthermore, the use of the terms “one or more” or “at least one” does not preclude the absence of that feature or element, unless otherwise specified by restrictive language, including but not limited to: “requires one or more…” or “requires one or more elements”.

[0078] This document refers to several "exemplary embodiments". It should be understood that embodiments are examples of possible implementations of any feature and / or element of this disclosure. Some embodiments have been described to illustrate one or more potential ways in which specific features and / or elements of this disclosure satisfy the requirements of uniqueness, utility, and non-obviousness.

[0079] The use of phrases and / or terms including, but not limited to, “first embodiment,” “another embodiment,” “alternative embodiment,” “one embodiment,” “embodiment,” “multiple embodiments,” “some embodiments,” “other embodiments,” “further embodiments,” “even more embodiments,” “additional embodiments,” or other variations, does not necessarily refer to the same embodiment. Unless otherwise stated, one or more specific features and / or elements described in connection with one or more embodiments may be present in one embodiment, or in more than one embodiment, or in all embodiments, or may not be present in any embodiment. While one or more features and / or elements may be described herein in the context of a single embodiment only, or in the context of more than one embodiment, or in the context of all embodiments, these features and / or elements may also be provided individually, or in any suitable combination, or not at all. Conversely, any feature and / or element described in the context of separate embodiments may alternatively be implemented as present together in the context of a single embodiment.

[0080] Any and all details set forth herein are used in the context of some embodiments and should therefore not be considered as limiting factors of the disclosure presented.

[0081] The terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process or method that includes the list of steps may include not only those steps but also other steps not expressly listed or inherent to such process or method. Similarly, without further constraints, a list of one or more devices, subsystems, elements, structures, or components preceded by “comprising…” does not exclude the presence of other devices, subsystems, elements, structures, or components, or additional devices, subsystems, elements, structures, or components.

[0082] The term “coupled” and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are physically in contact with each other. The terms “send,” “receive,” and “communicate,” and their derivatives include both direct and indirect communication. The term “or” is an inclusive term, meaning “and / or.” The phrase “associated with” and its derivatives refer to including, being included in, interconnected with, containing, being contained within, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, intertwine, juxtapose, proximate, bound to or bound to, having, possessing the properties of, having a relationship to or with, etc. The term “controller” refers to any device, system, or part thereof that controls at least one operation. The functionality associated with any particular controller can be centralized or distributed, whether local or remote. When used with a list of items, the phrase “at least one of” means that different combinations of one or more items from the list can be used, and it is possible that only one item from the list is needed. For example, "at least one of A, B, and C" includes any combination of: A, B, C, A and B, A and C, B and C, and A and B and C, and any variations thereof. As an additional example, the expression "at least one of a, b, or c" can mean only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof. Similarly, the term "set" means one or more. Accordingly, a set of items can be a single item or a collection of two or more items.

[0083] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and implemented in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable media does not include wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media in which data can be permanently stored and media in which data can be stored and subsequently rewritten, such as rewritable optical discs or erasable memory devices.

[0084] This disclosure provides techniques for enabling the re-sharing of broadcast source information in LE audio broadcasting systems. The disclosed techniques address a critical gap in the current framework where users cannot share broadcast information between their devices. The disclosed techniques significantly improve efficiency and user experience, especially in group settings where multiple users are interested in the same broadcast.

[0085] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0086] For clarity, the first digit of the reference numerals for each component in this disclosure indicates the drawing number of the corresponding component. For example, at least in Figure 1 The attached figures are shown with reference numerals beginning with the number "1". Similarly, at least in Figure 2 The figure shows the reference numerals that begin with the number "2".

[0087] It should be noted that throughout this specification, the terms "broadcast session" and "audio broadcast session" are used interchangeably. Furthermore, throughout this specification, the term "broadcast auxiliary equipment" is used interchangeably with "user."

[0088] Figure 9 A scenario 900 is illustrated, illustrating the sharing of broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure. The present disclosure provides a solution in which user A, after successfully synchronizing to LE audio broadcast, can share broadcast source information with other users (e.g., user B, user C, and user D) via their auxiliary device. This avoids the need for each user to individually repeat the entire scanning and synchronization process. For example, as... Figure 9 As shown, a group of four users (also known as broadcast auxiliary devices 903, 905, 907, and 909) access a location named XYZ, which is transmitting multiple LE audio broadcasts, all with the same or similar names (e.g., XYZ-1, XYZ-2). This confuses the users, as they struggle to identify the correct broadcast to synchronize with. User A 903 goes to the location counter and synchronizes with the actual broadcast stream from broadcast source 901. After synchronization, User A 903 can share broadcast information (info) with the other users in the group (User B 905, User C 907, and User D 909) using one of the following methods:

[0089] QR code sharing: User A 903 generates a QR code containing broadcast information, and other users only need to scan the QR code to connect.

[0090] NFC Touch Sharing: User A 903 shares broadcast details by allowing other users to use NFC to touch their devices on User A's device.

[0091] Bluetooth Sharing: User A 903 shares broadcast details with nearby devices via Bluetooth.

[0092] Family Account Sharing: If all users (903, 905, 907, 909) are part of a shared family account or group account, broadcast details will be automatically shared, allowing them to synchronize without further action.

[0093] Therefore, users B, C, and D synchronize to the broadcast without directly synchronizing with broadcast source 901 or manually searching for the broadcast.

[0094] refer to Figure 10 For reference Figure 9 The techniques discussed will be further explained. Therefore, in conjunction with Figure 9 right Figure 10 An explanation was provided.

[0095] Figure 10 A flowchart of a method 1000 for sharing broadcast source information during an audio broadcast session according to one or more embodiments of the present disclosure is shown. It should be noted that method 1000 can be performed between a transmitting device and at least one receiving device, wherein the transmitting device and at least one receiving device correspond to broadcast auxiliary devices in an audio broadcast environment. For example, the transmitting device may be with… Figure 9 The device 903 in the middle corresponds to it, and at least one receiving device can be with Figure 9 The devices (905, 907, and 909) correspond to this. Furthermore, the sending device 903 and at least one receiving device (905, 907, and 909) are part of an interconnected network, such as a cloud network, a family group interconnected via a similar network (e.g., a home Wi-Fi network), a group of friends interconnected via a similar network (e.g., an office Wi-Fi network), and similar interconnected networks. Additionally, method 1000 can be performed at the sending device 903.

[0096] refer to Figure 10In step 1001, method 1000 may include determining whether to share broadcast source information associated with an audio broadcast session with at least one receiving device. In one embodiment, the transmitting device 903 may determine whether the broadcast source information should be shared with at least one receiving device (905, 907, 909) based on user input from a user of the transmitting device 903. In another embodiment, the transmitting device 903 may determine whether the broadcast source information should be shared with at least one receiving device (905, 907, 909) based on a request from at least one receiving device (905, 907, 909). In an embodiment, the transmitting device 903 (also referred to as broadcast assistant 1, or BA1) may connect to the broadcast source before determining whether to share the broadcast source information with at least one receiving device (905, 907, 909, also referred to as broadcast assistant 2, or BA2). BA1 may connect to audio headset broadcast receiver 1 (BS1). BA1 may assist BS1 in synchronizing to the broadcast source selected by the users of BS1 and BA1. In one embodiment, the user of BA1 can provide user input for sharing broadcast information with BA2. For example, the user of BA2 can click "Share" via a button on BA1. In another embodiment, BA2 can, for example, notify BA1 via a message that the broadcast source information should be shared.

[0097] Subsequently, in step 1003, method 1000 may include selecting a transmission medium from a plurality of transmission media for sharing broadcast source information. Step 1003 may be performed in response to determining that broadcast source information should be shared with at least one receiving device (905, 907, 909). In embodiments, the plurality of transmission media may include, but is not limited to: Bluetooth (BT), Bluetooth Low Energy (BLE), Wi-Fi, Near Field Communication (NFC), Near Field Sharing, Network-based Sharing, Quick Response (QR) Code, or Out-of-Band (OOB) Communication. Furthermore, the sending device 903 (i.e., BA1) may receive user selection input from a user of the sending device 903 to select a transmission medium. For example, BA1 may display various transmission media for sharing broadcast information, and the user may select a transmission medium from among the various transmission media. In another embodiment, the sending device 903 may receive a request message from at least one receiving device (905, 907, 909). This request may include a transmission medium for sharing broadcast information, and the user may select the transmission medium from among the various transmission media.

[0098] Therefore, in step 1005, method 1000 may include sending one or more data packets including broadcast source information via the selected transmission medium. The one or more data packets may include, but are not limited to: broadcast source identifier (ID), broadcast source name, broadcast code, metadata related to the broadcast content, broadcast source address, and the address type of the broadcast source address.

[0099] In an exemplary embodiment, if the transmission medium is a QR code, a QR code is generated using the broadcast source information object and displayed on the UI of BA1. However, if NFC is selected, BA1 will begin to act as an NFC touch point. However, if the transmission medium is BT or Near Field Sharing, BA1 can act as a data sending device. Additionally, if the transmission medium is [not specified], the broadcast source information can be shared in the cloud.

[0100] Therefore, BA2 can connect to broadcast source 901 using broadcast source information. For example, if the broadcast source information is shared via an NFC touch point, BA2 can touch BA1 to receive the broadcast source information. If BA1 generates a QR code, BA2 can scan the QR code to obtain the broadcast source information. If BA1 shares via BitTorrent or Near Field Sharing, the broadcast source information can be received via BitTorrent or Near Field Sharing applications. If the broadcast source information is shared using a network, BA2 can download the broadcast source information from the cloud.

[0101] BA2 can parse broadcast source information to obtain detailed information about broadcast source 901. Therefore, BA2 can assist broadcast receiver 2 (BS2) associated with BA2 in joining a broadcast session using one of the following methods based on the broadcast source information provided by BA1:

[0102] A. If the received broadcast source information is sufficient to join the broadcast session, that is, if BA2 has received the periodic announcement (PA) synchronization information, then BA2 can perform the add source operation to assist BS2 in joining the broadcast session.

[0103] B. If the received information is insufficient to join the broadcast, i.e., if BA2 does not receive PA synchronization information from BA1, BA2 can automatically perform a scan to find a broadcast source 901 that matches the broadcast source information. Once found, BA2 can perform the add source operation. (See reference) Figures 11a-22 Method 1000 is described in further detail.

[0104] Figures 11a-11bA sequence flowchart of an exemplary method 1100 for sharing broadcast source information between broadcast auxiliary devices according to one or more embodiments of the present disclosure is shown. In step 1101, the broadcast source (BT1) initiates a broadcast session and sends EA, PA, and BIS. In step 1102, devices BA1-BS1, BA2-BS2, and BA3-BS3 establish a connection via BLE. In step 1103, a device that does not support LE audio (e.g., a smartwatch) connects to BA3 via a BT / BLE link. In step 1104, the user of BA1 initiates a scan for nearby broadcast sources and lists all available broadcast sources. The user selects BT1 from the list of all available broadcast sources. In step 1105, BA1 performs an add source operation on BS1, allowing BS1 to join the BT1 broadcast session. In step 1106, BS1 successfully joins BT1 and notifies BA1. In step 1107, BA1 enables the “Share via…” function and generates broadcast source information associated with broadcast source BT1, also referred to as BT1 information. In step 1108, the user selects a transmission medium (e.g., QR code, NFC touch, quick share, Bluetooth, or family account) to share BT1 information with BA2. In step 1109, BA2 parses the BT1 information, retrieving detailed information such as broadcast ID, name, code, and address. In step 1110, if the BT1 information is sufficient, BA2 performs an add-source operation on BS2, synchronizing BS2 with BT1. In step 1111, if the BT1 information is insufficient, BA2 scans for nearby broadcasts that match the BT1 details. Once a match is found, BA2 stops scanning and completes the add-source operation to assist BS2 in synchronizing with BT1. In step 1112, BS2 notifies BA2 after successfully joining BT1. Additionally, BA2 enables "Share via…" through its UI and generates an information object similar to BA1. In step 1113, non-LE audio devices with NFC can touch BA2 and receive BT1 information. In step 1114, the non-LE audio device shares the received BT1 information with BA3 via Bluetooth / BLE. For other devices such as BS3, repeat steps 1108 to 1114. If any BS loses synchronization with BT1, it will notify its corresponding BA, which will disable the "Share via..." button in the UI to indicate the loss of synchronization. Therefore, the disclosed method outlines an efficient approach for sharing broadcast source information among multiple devices, thereby achieving smooth synchronization between different users and improving the overall user experience in broadcast scenarios.

[0105] Figure 12A line diagram depicting a method 1200 for sharing broadcast source information between broadcast assisting devices using NFC, according to one or more embodiments of the present disclosure, is shown. In an exemplary embodiment, four users (i.e., user 1, user 2, user 3, and user 4) visit a place called XYZ. There, the users want to listen to a broadcast being broadcast in a café. However, when the users search for available broadcasts, they find four different options all named "XYZ," which confuses them about which one to connect to. To resolve this issue, user 1 goes to the counter and scans the correct broadcast. Now, in order for other users to also listen, each of the other users needs to go to the counter and scan a QR code or touch a designated NFC point to receive the broadcast information. Therefore, the present disclosure provides a solution to the aforementioned problem, such as... Figure 12 As shown. In this embodiment, broadcast source 901 can play a song during an audio broadcast session. In step 1201, broadcast source 901 broadcasts EA, PA, and BIG. In step 1202, user 1 joins the broadcast session using the conventional method described above. In step 1203, user 1 performs a source addition operation. In step 1204, user 1 sends a synchronization information request to broadcast source 901. In step 1205, user 1 receives PAST information from broadcast source 901 in response to the synchronization information request. In step 1206, user 1 synchronizes to PA. In step 1207, the "Share via…" option is enabled in the UI of user 1's device. Accordingly, user 1 selects NFC as the transmission medium for sharing broadcast source information, and his device now acts as an NFC card simulator. In step 1208, user 1 shares the broadcast source information with user 2 via NFC. In step 1209, user 2 joins the broadcast session by simply touching his device to user 1's device, bypassing the conventional steps. In step 1210, user 2 performs a source addition operation and synchronizes to PA. In step 1211, user 2 shares the broadcast source information with user 3. In steps 1212 and 129, user 3 synchronizes with PA, similar to steps 1209 to 1210. Furthermore, in steps 1214 and 1215, user 4 synchronizes with PA after receiving the broadcast source information from user 3, similar to steps 1209 to 1210.

[0106] In another embodiment, broadcast source information can be shared using Bluetooth instead of NFC, as referenced. Figure 12 As described above. In this scenario, users 903, 905, 907, and 909 can connect to broadcast source 901 by setting their devices to be discoverable via Bluetooth. This process is similar to... Figure 12 The process described in the article is similar, with the only difference being that Bluetooth is used as the transmission medium for sharing broadcast source information.

[0107] Figure 13A line diagram depicting a method for sharing broadcast source information between broadcast auxiliary devices using QR codes according to one or more embodiments of the present disclosure is shown. It should be noted that steps 901-1306, 1310-1311, 1313, and 1315 are identical to steps 1201-1206, 1210-1211, 1213, and 1215. Therefore, for the sake of brevity, the same descriptions are not repeated. The process is similar to... Figure 12 The process described is similar, except that a QR code is used as the transmission medium for sharing broadcast source information. Therefore, in step 1307, the "Share via…" option is enabled in the UI of user 1's device 903. Accordingly, user 1 selects a QR code as the transmission medium for sharing broadcast source information, and the QR code is displayed on user 1's device. In step 1308, user 1 shares the broadcast source information with user 2 via the QR code. In step 1309, user 2 opens a QR code scanning application on his device to obtain the broadcast source information. User 2 scans the QR code shared by user 1 and joins the broadcast session, bypassing the regular steps. Furthermore, in steps 1311-1312, user 3 synchronizes to the PA after receiving the broadcast source information from user 2, similar to steps 1308-1310. Similarly, in step 1314, user 4 synchronizes to the PA after receiving the broadcast source information from user 3, similar to steps 1309-1310.

[0108] Figure 14 A line diagram depicting a method for sharing broadcast source information between broadcast auxiliary devices using near-field sharing, according to one or more embodiments of the present disclosure, is shown. It should be noted that steps 1401-1406, 1410-1411, 1413, and 1415 are identical to steps 1401-1406, 1410-1411, 1413, and 1415. Therefore, for the sake of brevity, the same descriptions are not repeated. The process is similar to... Figure 12 The process described is similar, except that near-field sharing is used as the transmission medium for sharing broadcast source information. Therefore, in step 1407, the "Share via…" option is enabled in the UI of user 1's device 903. Accordingly, user 1 selects near-field sharing as the transmission medium for sharing broadcast source information. In step 1408, user 1 shares the broadcast source information with user 2 via near-field sharing. In step 1309, user 2 accepts the request shared by user 1 via near-field sharing to obtain the broadcast source information. Furthermore, in steps 1411-1412, user 3 synchronizes to the PA after receiving the broadcast source information from user 2, similar to steps 1408-1410. Similarly, in step 1414, user 4 synchronizes to the PA after receiving the broadcast source information from user 3, similar to steps 1409-1410.

[0109] Figure 15A line diagram illustrating a method for sharing broadcast source information between broadcast auxiliary devices using a network service, according to one or more embodiments of the present disclosure. In an exemplary embodiment, a group of four users are watching a football match together. The first user uses Home Sharing to connect to a broadcast service on their television and recommends the broadcast to the other users in the group. The other users agree to connect to the broadcast on their television via Home Sharing by making their devices discoverable through their device UIs. Users can click on the broadcast and join directly without a password. The first user opens the Home Sharing UI on their device, enters the contact number of a second user, and adds them to the family group. The first user then edits the group members to include a third and fourth user. By clicking "Invite," the first user sends invitations to the other users. Simultaneously, the second user opens the auxiliary UI on their device and connects directly to the first user's television without having to enter a broadcast code. Thus, broadcast source information can be shared using Home Sharing, a network service, as described in the references... Figure 15 The discussion focuses on steps 1501-1506, 1510-1511, 1513, and 1515. It should be noted that steps 1501-1506, 1510-1511, 1513, and 1515 are identical to those steps 1501-1506, 1510-1511, 1513, and 1515. Therefore, for the sake of brevity, the identical descriptions will not be repeated. This process is similar to... Figure 14 The process described is similar, with the only difference being the use of a network service as the transmission medium for sharing broadcast source information. Therefore, in step 1507, the "Share via…" option is enabled in the UI of user 1's device 903. Accordingly, user 1 selects a network service (i.e., the family account) as the transmission medium for sharing broadcast source information. In step 1508, user 1 shares the broadcast source information with user 2 via the family account. In step 1309, user 2 opens the UI of the family account and accepts the request shared by user 1 via the family account to obtain the broadcast source information. Furthermore, in steps 1511-1512, user 3 synchronizes to the PA after receiving the broadcast source information from user 2, similar to steps 1508-1510. Similarly, in step 1514, user 4 synchronizes to the PA after receiving the broadcast source information from user 3, similar to steps 1509-1510.

[0110] Figure 16 This illustrates a scenario where a server is used to share broadcast source information between broadcast auxiliary devices, according to one or more embodiments of this disclosure. Figure 16As shown, device 1601 acts as the broadcast source, while device 1603 acts as a broadcast assistant (BA) synchronized with broadcast source 1601. When device 1605 wants to connect to broadcast source 1601, device 1605 sends a request to server 1602. Server 1602 forwards this request to all devices associated with the same home account, namely devices 1607 and 1609. Since BA 1603 is already synchronized with broadcast source 1601, BA 1603 provides server 1602 with the necessary information (i.e., broadcast source information) to allow device 1605 to synchronize with broadcast source 1601. Devices 1607 and 1609 may ignore the request because they are not synchronized with broadcast source 1601. Server 1602 then relays the broadcast source information from device 1603 to device 1605, enabling device 1605 to successfully synchronize with broadcast source 1601.

[0111] Figure 17 A scenario illustrating the use of directional broadcasting to share broadcast source information among broadcast auxiliary devices, according to one or more embodiments of this disclosure, is shown. For example... Figure 17 As shown, device 1701 acts as the broadcast source, while device 1703 acts as a broadcast assistant (BA) synchronized with the broadcast source 1701. When device 1705 wants to connect to the broadcast source 1701, device 1705 sends a directed broadcast to all devices logged in using the same family account (i.e., devices 1703, 1707, and 1709). All devices within Bluetooth range receive this directed broadcast and decide whether to respond or ignore the request. Since BA 1703 is already synchronized with the broadcast source 1701, BA 1703 provides device 1705 with the necessary information (i.e., broadcast source information) to synchronize with the broadcast source 1701. BA 1703 can establish wireless communication with device 1705 to transmit the broadcast source information. Devices 1707 and 1709 may ignore the request because they are not synchronized with the broadcast source 1701. Device 1705 successfully synchronizes with the broadcast source 1701 based on the received broadcast source information.

[0112] Figure 18 Examples illustrating the reduction of the risk of joining malicious broadcasts according to one or more embodiments of this disclosure are shown. Figure 18As shown, User 1801 and a friend (such as User 1803) are in a public place surrounded by multiple LE audio broadcast sources from locations such as convenience stores, public transportation systems, restaurants, and gas stations. While most of these sources are likely genuine, some may be fake or spoofed sources mimicking legitimate LE audio broadcasts by using the same names and metadata, intended to confuse the user. These fake sources may be maliciously set up to send harmful data via simultaneous streaming, such as broadcasts. User 1803 notifies User 1801 to connect to the LE audio broadcast from the bus stop to receive real-time updates. However, unable to distinguish between genuine sources and imposters, User 1801 risks accidentally connecting to a malicious broadcast from a fake bus stop. To mitigate this risk, when User 1801 encounters multiple sources with similar names, they hesitate to choose any due to concerns about the potential danger of connecting to fake broadcasts. In this scenario, User 1803, already connected to a genuine broadcast, can use a reference... Figures 12-17 Any of the described methods allows user 1801 to share the real broadcast source information. This allows the first user to confidently join the real broadcast, reducing the risk of connecting to a malicious source.

[0113] Figure 19 A use case scenario 1900 is illustrated for sharing broadcast source information between broadcast auxiliary devices according to one or more embodiments disclosed herein. Sharing broadcast source information between a BA1 1901, which does not support broadcast audio scanning / LE audio services, and a BA2 1903, which does support these services, can be accomplished via Bluetooth (BT) or Bluetooth Low Energy (BLE). An example of BA1 1901 could be a watch, while BA2 1903 could be a laptop computer, smartphone, or television. BA1 1901 obtains the broadcast source information via NFC touch and relays this data to the paired BA2 1903 via a BT / BLE connection. Once BA2 1903 receives the broadcast source information, it begins scanning for nearby broadcast sources. BA2 1903 specifically scans for periodic announcement messages from broadcast source 1905, which are identified by metadata in the broadcast source information it receives from BA1 1901, thereby enabling broadcast receivers (BS) 1907 (e.g., earbuds or headphones) connected to BA2 1903 to join a broadcast session.

[0114] Figure 20 One or more embodiments according to this disclosure are shown, targeting Figure 19The following is a linear diagram illustrating the steps of a method 2000 for sharing broadcast source information between broadcast auxiliary devices, as an exemplary scenario. In step 2001, broadcast source 1905 begins a broadcast session. In step 2002, BA1 1901 (i.e., a watch) acts as an NFC reader to obtain broadcast source information from broadcast source 1901. In step 2003, the broadcast source information is shared via NFC. In step 1904, BA1 1901 shares the broadcast source information with BA2 1903 via BT. In step 2005, BA2 1903 begins scanning for periodic announcement messages from broadcast source 1901. In step 2006, a synchronization information request is sent from BS 1907 to BA2 1903. In step 2007, PAST information is shared from BA2 1903 to BS 1907. In step 1908, BS 1907 initiates an add source operation and synchronizes with PA.

[0115] Figure 21An architecture of a system 2100 for sharing broadcast source information between broadcast assisting devices according to one or more embodiments of the present disclosure is shown. System 2100 may include, but is not limited to: a Bluetooth setup module 2101 (also referred to as a broadcast assisting UI), a broadcast QR code generator / scanner 2103, a broadcast touch simulator / reader 2105, a quick share 2105, and a BT / BLE / SPP 2107, as well as other components well known to those skilled in the art. The broadcast assisting UI element 2101 can be added to assisting party activities. Once a BS connected to the BA joins a broadcast session, the UI element 2101 can become visible and clickable. If the BS no longer listens to the broadcast session, the UI element 2101 can become grayed out and unclickable. Furthermore, the QR code generator 2103 can create a QR code based on the Uniform Resource Identifier (URI) of the broadcast source information. The QR code generator 2103 obtains the broadcast source information and code from the Broadcast Audio Scanning Service (BASS) client service. The QR code scanner 2103 scans the QR code using a camera and parses the URI. If the URI contains a BASS identifier, module 2103 requests the BASS client service to perform an "Add Source" operation, thereby joining the broadcast session. Module 2103 generates a BASS URI containing broadcast source information. Additionally, the broadcast touch simulator 2105 can create "touch points" on the BA for other users to touch their devices. The touch simulator 2105 can generate broadcast source information and codes from the BASS client service. The touch reader 2105 can receive the BASS URI via NFC touch. If the URI contains a BASS identifier, the touch reader 2105 can request the BASS client service to perform an "Add Source" operation, thereby joining the broadcast session. The Quick Share receiver framework 2107 can be modified to parse the BASS URI and display a pop-up request to the user, allowing the user to decide whether to join the broadcast session or ignore it. If the user chooses to join the broadcast session, the Quick Share framework 2107 can request the BASS client service to perform an "Add Source" operation. The BT / BLE / SPP framework 2109 can be modified to parse the BASS URI and display a pop-up request to the user, allowing the user to decide whether to join the broadcast session or ignore it. If the user chooses to join the broadcast session, the BT / BLE / SPP framework 2109 can request the BASS client service to perform the add source operation.

[0116] Figure 22An environment for sharing broadcast source information via a button in a broadcast auxiliary user interface (UI) according to one or more embodiments of the present disclosure is illustrated. For example, as shown, a broadcast receiver (e.g., earphone 2201) is connected to a telephone 2203 acting as a broadcast auxiliary (BA). Earphone 2201 is synchronized to a PA belonging to the broadcast source. Earphone 2201 can enable "Share via..." via a button in the BA UI. Furthermore, by disabling the button, earphone 2201 can disconnect from BA 2203. Additionally, the button can also be enabled when earphone 2201 loses synchronization with the PA.

[0117] Figure 23 A block diagram of a system for sharing broadcast source information during an audio broadcast session, according to an embodiment of the present disclosure, is shown.

[0118] Figure 23 The configuration can be understood as part of the configuration of the sending device 1303. Furthermore, according to another embodiment, the above reference... Figures 13-2 The four disclosed techniques can be implemented in system 2300. Non-limiting examples of system 2300 include electronic devices, mobile devices, and user devices.

[0119] In this embodiment, system 2300 corresponds to sending device 1301. (See reference...) Figure 23 The system 2300 may include a "processor" (i.e. at least one processor) 2301, communication circuitry 2303 (e.g., a communicator or communication interface) and memory 2305.

[0120] As an example, at least one processor 2301 may be a single processor or multiple processors, and all processors may include multiple computing circuits. Processor 2301 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. Among other capabilities, processor 2301 is configured to acquire and execute computer-readable instructions and data stored in memory 2305. Processor 2301 may include one or more processors. In this case, one or more processors 2301 may be a general-purpose processor (e.g., a central processing unit (CPU), application processor (AP), etc.), a graphics-only unit (e.g., a graphics processing unit (GPU), a vision processing unit (VPU)), and / or an AI-specific processor (e.g., a neural processing unit (NPU)). One or more processors 2301 may control the processing of input data according to predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory (i.e., memory 2305). These predefined operating rules or AI models are provided through training or learning.

[0121] The communication circuit 2303 can perform the function of transmitting broadcast source information via a wireless channel. In one embodiment, the communication circuit 2303 can transmit broadcast source information to the sending device 1303 according to the technology disclosed herein. In another embodiment, at least one processor 2301 can execute through the communication circuit 2303. Figure 14 Operations 1401-1405.

[0122] Memory 2305 may include any non-transitory computer-readable medium known in the art, including, for example, volatile memory (such as static random access memory (SRAM) and dynamic random access memory (DRAM)); and / or non-volatile memory (such as read-only memory (ROM), erasable programmable ROM, flash memory, hard disk, optical disk, and magnetic tape). Memory 2305 may also store broadcast source information according to the techniques disclosed herein. Furthermore, memory 2305 may include an operating system for performing one or more tasks of system 2300, as executed by a general-purpose operating system in the communications field.

[0123] Therefore, the disclosed technology provides for the re-sharing of broadcast source information among users (i.e., broadcast assistants).

[0124] Therefore, this disclosure provides various advantages, such as:

[0125] Efficiency: Only one user needs to scan and synchronize to the broadcast, while other users can quickly join using the shared information.

[0126] Reduced power consumption: Directly sharing broadcast details avoids unnecessary power consumption (e.g., multiple users repeatedly scanning and synchronizing).

[0127] Eliminate confusion: Eliminates the risk of users joining the wrong broadcast or feeling overwhelmed by multiple broadcast options with similar names.

[0128] Improved user experience: The process is simplified, saving time, and it is easier for groups to seamlessly join the same broadcast.

[0129] Enhanced security: Because users connect to the correct broadcast source using the disclosed technology, the risk of connecting to malicious broadcast sources is reduced. Since malicious / harmful broadcasts attempt to mimic the same name as the original broadcast source, the disclosed technology prevents users from connecting to such sources.

[0130] Therefore, the disclosed technology significantly improves the user experience in LE audio broadcasting environments by allowing users to efficiently share broadcast source information. The disclosed technology eliminates the need for individual scanning and synchronization for each user, thus minimizing confusion, reducing power consumption, and saving time. The disclosed technology is particularly useful in public places, cafes, or situations where multiple users want to connect to the same broadcast without having to go through tedious repetitive steps.

[0131] In this application, unless otherwise expressly stated, the use of singular forms includes plural forms, and the use of "or" means "and / or". Furthermore, the use of the terms "comprising" or "having" is not limiting. Any scope described herein will be understood to include the endpoints and all values ​​between the endpoints. Within the scope of this invention, features of the disclosed embodiments can be combined, rearranged, omitted, etc., to produce additional embodiments. Furthermore, certain features may sometimes be advantageous without corresponding use of other features.

[0132] Although at least one exemplary embodiment has been given in the foregoing detailed description, it should be understood that numerous variations exist.

Claims

1. A method (1000) for sharing broadcast source information during an audio broadcast session, the method (1000) comprising: Based at least on user input from a user of the sending device and a request from at least one receiving device, the sending device determines (1001) whether broadcast source information associated with the audio broadcast session should be shared with the at least one receiving device; In response to determining that the broadcast source information should be shared with the at least one receiving device, the sending device selects (1003) a transmission medium from a plurality of transmission media for sharing the broadcast source information; as well as The sending device transmits (1005) one or more data packets including the broadcast source information via the selected transmission medium.

2. The method (1000) according to claim 1, wherein, The selection of the transmission medium includes: Receive one of the following at the sending device: User selection input from the user of the sending device, used to select the transmission medium among the plurality of transmission media; or A request message from the at least one receiving device for using one of the plurality of transmission media; and The sending device selects the transmission medium based on either the received user input or the request message.

3. The method (1000) according to claim 1, wherein, The multiple transmission media include Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, Near Field Communication (NFC), Near Field Sharing, Network-based Sharing, Quick Response QR Code, or Out-of-Band (OOB) Communication.

4. The method (1000) according to claim 1, wherein, The one or more data packets include at least one of the following: broadcast source identifier ID, broadcast source name, broadcast code, metadata related to the broadcast content, broadcast source address, and address type of the broadcast source address.

5. The method (1000) according to claim 1, wherein, The sending device and the at least one receiving device are part of an internetwork.

6. A system (2300) for sharing broadcast source information during an audio broadcast session, the system (2300) comprising: At least one processor (2301) is configured as follows: Based at least on user input from the user of the sending device and a request from at least one receiving device, determine whether broadcast source information associated with the audio broadcast session should be shared with the at least one receiving device; In response to determining that the broadcast source information should be shared with the at least one receiving device, a transmission medium for sharing the broadcast source information is selected from a plurality of transmission media; as well as One or more data packets, including the broadcast source information, are transmitted through the selected transmission medium.

7. The system (2300) according to claim 6, wherein, in order to select the transmission medium, the at least one processor (2301) is configured to: Receive one of the following: User selection input from the user of the sending device, used to select the transmission medium among the plurality of transmission media; or A request message from the at least one receiving device for using one of the plurality of transmission media; and The transmission medium is selected based on either the received user input or the request message.

8. The system (2300) according to claim 6, wherein, The multiple transmission media include Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, Near Field Communication (NFC), Near Field Sharing, Network-based Sharing, Quick Response QR Code, or Out-of-Band (OOB) Communication.

9. The system (2300) according to claim 6, wherein, The one or more data packets include at least one of the following: broadcast source identifier ID, broadcast source name, broadcast code, metadata related to the broadcast content, broadcast source address, and address type of the broadcast source address.

10. The system (2300) according to claim 6, wherein, The sending device and the at least one receiving device are part of an internetwork.

Images