Systems and methods for broadcasting digital data to a plurality of receivers

This application is filed Feb. 26, 2018, U.S. Provisional Patent Application No. 62/635,104, entitled "Methodology Developed for the Transfer of Digital Information by Broadcasting to an Unlimited Number of Receivers," and Jan. 2019 No. 62/792,003 entitled "System and Method for Broadcasting Digital Data to Receivers," filed on Dec. 14, is hereby incorporated by reference in its entirety.

More particularly, the present invention relates to wireless broadcasting of digital information to multiple receivers in environments where two-way communication is not possible or impractical.

In environments with large crowds, such as sporting events, gatherings, lectures, concerts, etc., access to digital data using mobile phones and wireless devices is unreliable.

In such cases, many mobile devices compete for attention to the nearby antenna of the cellular network. A user of a mobile device may see a bar on the device's screen indicating that there is a signal available, but data is consistently not being received from the cellular network and is not being returned. It has not been. Such a network could be useful when recipients 120 tend to use data-heavy applications and multimedia, such as voice, photo, media, and video sharing, which consume a large amount of network bandwidth. Because it happens so often, it can be further burdened by "high traffic".

Similar network overloads occur in emergencies or during disasters. After the Boston Marathon bombings, for example, cell phone carriers were flooded with traffic as thousands of people tried to contact their loved ones in the Boston area. In the aftermath of natural disasters, terrorist attacks, and other such incidents around the world, telecommunications networks experience surges in voice call capacity or data traffic (e.g., text/SMS and multimedia messages). The increase cannot be coped with at all. All major mobile carrier recipients120 reported outages in the Boston metropolitan area during the event. As a result, the corroboration received as fact by the media, such as the Associated Press erroneously reporting that mobile service had been shut down in Boston to stop remote detonation of bombs in cell phone hours, has been rife. Rumors spread.

Natural disasters can make cellular networks unreliable. In the immediate aftermath of Hurricane Sandy, for example, the FCC warned that mobile services were hit hard by the storm (https://www.fastcompany.com/3002578/post-sandy-fcc-warns-worsening-cell-phone -networks). Sandy involved a physical disruption of mobile network infrastructure that was quite different from increasing network capacity, but the basic elements were the same.

When a disaster strikes, network decentralization can reduce network usage by recipients 120 seeking real-time information from central (e.g., news, government) sources, especially within the region related to the event. means that entire geographic regions may be at risk due to an increase in Bandwidth strain at carrier sites prevents recipients 120 from making phone calls and communicating digital data, especially multimedia data.

Similarly, in poor connectivity environments, communication between mobile devices and mobile networks or other networks can be "high density", especially in construction sites, medical facilities, shopping malls, convention centers, etc. can be unreliable when combined with the location of

Despite these challenges, recipients 120 expect to remain connected via their mobile devices anytime, anywhere. Cellular and network companies have deployed various strategies to improve reliability under these circumstances. For example, current cellular technology will allow up to approximately 2,000 simultaneous connections per cell tower or distributed antenna system (DAS) sector. A big event like a football game in a stadium would require 25 cell phone towers to reach 50,000 fans simultaneously. Some networks have added or upgraded antennas at or near venues with greater capacity and on nearby cell towers, some at large crowd venues such as sports stadiums. Some have installed "small cells" to improve capacity. Small cells have less range than regular cell towers, but can complement these towers for increased capacity in high density areas. The network also places temporary cell sites, sometimes referred to as "cells on wheels" or cows, at high capacity venues to increase network connectivity.

Newer venues are also likely to have Wi-Fi, which reduces the load on cell phone networks. However, historically, Wi-Fi devices have been installed high on ceilings or walls. As a result, the signal may be blocked by obstructions from steel and other construction materials. Also, the mobile device recipient 120 may be relatively far away from the router that provides communication with the network. Wi-Fi capacity also tends to be smaller, and current Wi-Fi technology does not even allow 200 simultaneous connections per access point (antenna). Access points are also typically only 100 feet apart.

However, these network improvements have not made network service consistently reliable in congested areas, especially for the communication of digital data, such as photos, videos, and multimedia content. Even with improved infrastructure in place, technical challenges and limitations associated with the proximity of multiple transmitters, fan behavior, and other complexities make it impossible to reach all participants simultaneously .

Current digital file transfer protocols, such as TCPIP, Bluetooth, and others, require a working two-way communication link to provide a back channel for digital acknowledgment of receipt of correct files. For example, the bi-directional nature of communication between cell towers and mobile devices means that if there is an interruption in communication, the communication or transmission can be lost. Although there are certain file transfer protocols, such as UDP, that do not require two-way feedback, these protocols use file It still requires full continuous and uninterrupted reception. Therefore, there is a need for a file transfer protocol that allows reception of uncorrupted digital data even where the signal is not completely continuous and uninterrupted.

For emergencies and natural disasters, Congress has directed the establishment of a process for the creation of the National Mobile Alert System, now known as WEA, and the participating commercial mobile services ("CMS"). mobile service) providers send emergency alerts over WEA to their subscribers. Since then, more CMS providers have joined, with all four major wireless carriers joining the system, serving 98.6% of the US population. However, although most parts of the country are now covered, there continue to be concerns about the content, phrasing and geographic coverage of WEA messages.

In recent years, the Commission has devoted considerable time and effort to the issue of improving the content and manner of delivery of WEA messages. For example, the power of WEA messages was enhanced in 2016 by increasing the character length of messages to 360 characters. This improves the quality of information available to the public during emergencies and reduces public confusion caused by difficult-to-understand abbreviations. But especially for multimedia, which not only improves the content of the information provided, but can also assist in further identifying the actual nature and location of the emergency (such as by showing a map in the alert). , there is still a need to improve the quality of WEA alert messaging. The recent confusion caused by an incorrect WEA warning message about a supposed missile attack on Hawaii has bolstered this effort to improve messaging by including multimedia. Similarly, in the case of the recent California fires in the Santa Barbara area, residents and first responders responders could have benefited from multimedia, such as maps that more clearly delineated the areas affected by evacuation orders.

CMS carriers and others in the telecommunications industry claim that including multimedia in WEA alerts is not yet feasible. The industry standards body, the Alliance for Telecommunications Industry Solutions ("ATIS"), states that "[c]ell broadcast technology was not designed for multimedia" and that "it is technically impractical." If not possible, there are many issues that make the representation of multimedia content within WEA notifications unwieldy," argues NPL 1's comments. ATIS states that "[is] problematic, if not technically unfeasible, [.] the presentation of multimedia content such as maps, photographs, and hazard signs in WEA notices." 10 o'clock) and further claims.

<p><nplcit><text>The Alliance for Telecommunications Industry Solutions in PS Docket 15-91, January 13, 2016</text></nplcit></p>

<p>Improved systems and methods for broadcasting digital data are desired, especially in emergency situations or in highly congested and poorly connected environments.</p><p>Additionally, improved systems and methods for broadcasting multimedia are desired, especially in emergency situations or in high capacity venues.</p><p>Additionally, improved systems and methods for broadcasting cryptographic messages regarding events or emergencies are desired, additionally broadcasting the messages to selected receivers, such as certain emergency response personnel.</p><p>Sponsors and marketers alike are looking for better ways to connect with recipients on mobile devices and run brand revitalization campaigns at large events (e.g. sporting events or concerts). there is</p>

<p>The present invention, in one form thereof, addresses the need for feedback loops or the need for uninterrupted reception of data streams in order to accurately transfer digital information and, in some cases, multimedia information. including systems, protocols, and methods for broadcasting genderless digital data. More particularly, the present invention enables wireless broadcast of digital information to multiple receivers in environments where two-way communication is not possible or impractical.</p><p>In another form, the invention disclosed herein provides systems, methods, and communication protocols for transmitting continuous data streams that do not require bidirectional feedback.</p><p>In yet another form, the present invention includes systems and methods for communicating data with many devices in a one-to-many (1:MANY) configuration using novel container formats or header information. This includes any type of digital information, including but not limited to digital files and media, streaming data, and digital functions, which can then be used for command and control of digital devices. , allows to "push" to multiple receivers at a particular venue or within a chosen radius.</p><p>One general aspect includes a system for wirelessly broadcasting multimedia data to a plurality of mobile receivers, segmenting the multimedia data into two or more digital data segments;2 Encapsulating one or more digital data segments with header information and communicating two or more digital data segments to a remote data server for broadcast to multiple remote mobile receivers wherein the header information includes at least one of a venue identifier, identifying whether multimedia data is destined for all of a plurality of mobile receivers at the venue; an octet, a data type index, a continuity index indicating whether a digital data segment is one of a sequence, a total octets index indicating the total number of octets in each of two or more digital data segments, and/or include address location information indicating the location where each of the two or more digital data segments is to be stored. Header information also includes a checksum. A remote data server for receiving two or more digital data segments, storing two or more digital data segments, and broadcasting to multiple remote mobile receivers , operable to repeatedly transmit two or more digital data segments to the transmitter. The system also includes a transmitter operable to broadcast two or more digital data segments received from the remote data server to multiple mobile receivers. A plurality of mobile receivers each including an antenna and a unique identifier and paired with at least one host device to receive two or more digital data segments from the transmitter and two or more digital - At least one pair of data segments is operable to retransmit to the host device. Each host device includes a display, receives two or more digital data segments, reformats the two or more digital data segments into multimedia data, and displays multimedia data. is operable to display the Other examples of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. .</p><p>Implementations may include one or more of the features of a return channel from at least one paired host device to a central service via an alternate communication network that does not include a transmitter, said alternate communication network but a TCP/IP communication channel from at least one of the plurality of mobile receivers to the central service and/or a plurality of short range proximity receivers within range of at least one of the plurality of mobile receivers including. The system further includes user profiles associated with each of the plurality of mobile receivers. The central service can further redistribute the two or more digital data segments for broadcast to remote data servers for a predetermined period of time. Implementations of the described techniques may include hardware, methods or processes, or computer software on computer-accessible media.</p><p>and displaying the multimedia data on the host device. Other examples of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. .</p><p>A further aspect includes a system for wirelessly broadcasting multimedia data to a plurality of mobile receivers, segmenting the multimedia data into digital data segments; It includes a central service operable to communicate digital data segments to a remote data server for encapsulation with header information and broadcast to a plurality of remote mobile receivers. The system sends the remote service data with the second header information to the remote data server for broadcasting with the digital data segments and the first header information from the central service to a plurality of remote mobile receivers. It also includes a remote service operable to communicate. The remote data server receives digital data segments and first header information from the central service; receives remote service data and second header information from the remote service; It may be further operable to store the data segment, the first header information, the second header information and the remote service data. A remote data server sends digital data segments, first header information, second header information, and remote service data to a transmitter, for broadcast to multiple mobile receivers, in a carousel buffer. can be sent repeatedly via The transmitter is operable to broadcast the digital data segment, first header information, second header information, and remote service data to multiple mobile receivers. Other examples of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. .</p><p>However, a further general aspect includes a system for wirelessly broadcasting multimedia data to a plurality of mobile receivers, segmenting the multimedia data into digital data segments; operable to encapsulate segments with header information and communicate each digital data segment with header information to a remote data server for broadcast to multiple remote mobile receivers; Contains a central service that runs a possible transmitter program. The header information includes a venue identifier, a digital data segment type indicator, a mobile receiver identifier, a continuity indicator indicating whether each digital data segment is one of a sequence, each digital data segment a total octet index indicating the total number of octets in the data server, address location information indicating the location where the digital data segment is to be stored, and a checksum, the data server confirming that the digital data segment is stored in the central service operable to receive a digital data segment and add the digital data segment to a carousel buffer for continuous broadcast by the transmitter until modified or removed by the . Other examples of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. .</p><p>Another general aspect includes a method of processing data for a mobile receiver, the method receiving and demodulating a first FM broadcast signal including a first container and a first digital data segment. where the first container is 9 to 60 octets and the Venue Identifier, Digital Data Segment Type Indicator, Mobile Receiver Identifier, First Digital Data Segment is one of a sequence a total number of octets index indicating the total number of octets in the first digital data segment; an address location information indicating the location where the first digital data segment is to be stored; , and a checksum; and receiving and demodulating a second FM broadcast signal including a second container and a second digital data segment. where the second container is from 9 octets to 60 octets and the Venue Identifier, Digital Data Segment Type Indicator, Mobile Receiver Identifier, Second Digital Data Segment are second in sequence a total octet index indicating the total number of octets in the second digital data segment; a second address indicating the location where the second digital data segment is to be stored; receiving and demodulating a second FM broadcast signal including the location information and a second checksum. Other examples of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. .</p><p>The present invention is disclosed with reference to the accompanying drawings.</p>

<figref num="1">FIG. 2 illustrates part of a system architecture according to one embodiment of the invention;</figref><figref num="2">FIG. 2 illustrates part of a system architecture according to one embodiment of the invention;</figref><figref num="3">FIG. 2 illustrates an example mobile receiver and host device according to one embodiment of the present invention;</figref><figref num="4">FIG. 4 shows an example display on a host device according to one embodiment of the present invention;</figref><figref num="5A">FIG. 4 is an illustrative diagram of an example schema for display according to one embodiment of the present invention;</figref><figref num="5B">FIG. 4 is an illustrative diagram of an example lookup table (A) according to one embodiment of the present invention;</figref><figref num="5C">FIG. 4 is another illustrative diagram of an example lookup table according to one embodiment of the present invention;</figref><figref num="5D">FIG. 4B is another illustrative diagram of an example lookup table (A) according to one embodiment of the present invention;</figref><figref num="5E">FIG. 4 is an annotated diagram showing an example display on a host device according to one embodiment of the present invention, where reference numerals refer to location information in a lookup table;</figref><figref num="6A">FIG. 4 is an illustrative diagram of an example message structure schema according to one embodiment of the present invention;</figref><figref num="6B">FIG. 4 is an illustrative diagram of an example message structure according to one embodiment of the present invention;</figref><figref num="7">4 is a flowchart illustrating a method according to one embodiment of the invention;</figref><figref num="8">1 illustrates part of a system architecture for sending emergency alerts according to one embodiment of the present invention; FIG.</figref><figref num="9A">Fig. 2 shows an example emergency alert message as specified in the Common Alert Protocol, version 1.2, using extensible markup language (XML);</figref><figref num="9B">Figure 9B illustrates how the information in the XML message of Figure 9A can be converted into a table format according to one embodiment of the present invention;</figref><figref num="10">4 is a flowchart illustrating a method according to one embodiment of the invention;</figref><figref num="11">1 is a block diagram illustrating an example hardware implementation according to one embodiment of the present invention; FIG.</figref><figref num="12">1 is a block diagram illustrating the functionality of an example implementation according to one embodiment of the invention; FIG.</figref>

Corresponding reference characters indicate corresponding parts throughout the several figures. The examples provided herein illustrate several embodiments of the invention and should not be construed as limiting the scope of the invention in any way.

Turning now to Figure 1, a system is provided for communicating data with many devices in a one-to-many configuration. The system can be of any type including, but not limited to, digital files, streaming data, multimedia files, and digital functions that can later be used for command and control of digital devices. is operable to push digital information from

FIG. 1 shows system 100 positioned at venue 110 for communicating digital data to a large number of recipients 120 each having a mobile receiver 130 . Venue 110 is equipped with data server 140 and transmitter 150 for wirelessly broadcasting data. Transmitter 150 may be a small (eg, 4 feet) antenna located at venue 110 . In one embodiment, transmitter 150 and data server 140 are integrated into the same physical device. Alternatively, transmitter 150 is controlled and/or configured by software running on a remote computing device. Each mobile receiver 130 can retransmit the data to a host device 160, such as a cell phone, or use the data to command/control other equipment. In one embodiment, mobile receiver 130 and host device 160 are integrated into the same physical device. The host device 160, when used, is operable to run an application 170 displayed or otherwise made available on the host device 160 on which data is received from the mobile receiver 130. Yes, allowing the response to be sent to the mobile receiver 130 over any network available to the host device 160, preferably a TCP/IP network. System 100 may interconnect with other access networks, but for simplicity these entities/interfaces are not shown. As shown, system 100 provides packet-switched services.

In one embodiment, recipient 120 registers with recipient 120's mobile receiver 130 the central service detailed in FIG. Or receive an encoded message.

In one embodiment shown in FIG. 2, data feeds (which may include data broadcast programming) are provided to venues 110 from a networked central service 200 via the Internet. The central service 200 can include a server, which can be a web server or streaming server made for audio/video/text/command streaming applications. Files on the server can contain any type of audio/video text/command content. The central service 200 directs audio/video text/command files to clients by sending the files to a socket. Both TCP and UDP socket connections may be used. Before sending an audio/video file over a network, the file is segmented and the segments are encapsulated with header information suitable for audio/video text/command traffic, described in further detail below. Data initialization and generation may occur at the central service 200 or similar services local to the venue. Alternatively, central service 200 may be located at venue 110 . Venue 110 may be equipped with central services and/or local services, described below. Data server 140 may receive content from more than one server (central service 200 or one or more local services). In one embodiment, data server 140 stores all messages in a "carousel" type buffer and continuously broadcasts the contents of the buffer via transmitter 150 . A "carousel" type refers to a session protocol that repeatedly broadcasts a set of data packets over time to ensure that the set of data packets is received by one or more receivers.

An operator of the central service may manually enter the encapsulated data elements element by element, or alternatively the central service may be operable to automatically enter the encapsulated data.

At venue 110, the data feed is received at data server 140 and communicated to transmitter 150, for example, via UDP protocol over an Ethernet connection. Data server 140 may include serving and packet data network (PDN) gateways and control nodes that handle signaling between central service 200 or local services and mobile receivers 130 . . Transmitter 150 may be a permanently mounted arena transmit antenna that transmits RF signals over a selected distance, for example, an area of 3.5 square miles/6 square kilometers (radius of 1 mile/1.6 km). good. Transmitter 150, in one embodiment, transmits unidirectional data broadcast between 217 MHz and 220 MHz (200 kbps). With FCC approval, the chosen distance may be greater. Several types of transmission mechanisms as known in the art may be used, including pulse code modulation (PCM) on FM radio signals, ISDB-T, ISDB-T, multimedia broadcasting, digital Includes System E, T-DMB, DVB-H, DVB-SH, FLO, RAVIS, and DVB-T2 Lite.

Turning to FIG. 3, mobile receiver 130 and host device 160 are shown. Mobile receiver 130 may be a stand-alone receiver designed to interface and control a separate non-digital device. Alternatively, mobile receiver 130 is operable to relay data to host device 160 via a wired or wireless communication protocol, such as Bluetooth. In yet another embodiment, mobile receiver 130 is integrated into host device 160 . In one embodiment, the mobile receiver 130 is designed to be attached to a vehicle, is powered by the vehicle's electrical system, and is activated when the vehicle is running. In another embodiment, the mobile receiver 130 is portable, battery operated, and turned on by the user. Operation of the mobile receiver 130 can use any RF frequency capable of sustaining digital communications. In one embodiment, mobile receiver 130 operates at a frequency of 217 MHz.

Mobile receiver 130 receives broadcast data through its own receiver/antenna. Each mobile receiver 130 recovers the information modulated onto an RF carrier and provides the information to the controller/processor at mobile receiver 130 or host device 160 . A controller/processor can be associated with memory that stores program codes and data. Memory may also be referred to as computer-readable medium. In the host device 160, the controller/processor performs demultiplexing between transport and logical channels, packet reassembly, decoding, header decompression, and control signal processing. The controller/processor can also be responsible for error detection.

The mobile receiver 130 has a port or connector (eg USB) for charging and data upload, and can control switches, eg buttons, to activate and control various functions. A status indicator/data transmission indicator, eg light, may be provided. Mobile receiver 130 may be in the form of a small fob via Bluetooth or other communication links including but not limited to IR, short-range EMF, short-range transmission, etc. to host device 160. . Mobile receiver 130 may be operable to receive broadcast data from transmitter 150 . Mobile receiver 130 may further include a transceiver for communicating, or otherwise transmitting and receiving, data, such as acknowledgment or control signals, to host device 160 . In one embodiment, neither mobile receiver 130 nor host device 160 have broadband back channel/broadband reverse channel capabilities back to central service 200; Communicate with mobile receiver 130 via range communication or a narrowband back channel. The mobile receiver 130 may also communicate with multiple fixed transceivers around the venue 110 for this purpose. Mobile receiver 130 may further include a radio receiver or chip operable to receive standard FM radio broadcasts in the 88 MHZ to 108 MHZ frequency band. In one embodiment, mobile receiver 130 is an arrangement of modules on host device 160 that includes an FM radio receiver.

Mobile receiver 130 may be assigned identification information such as a MAC address or other identification code such as EMEI or equivalent. so that specific mobile receivers 130 can receive data broadcast transmissions that are intended to be both broadcast globally to all devices and specifically directed to identified mobile receivers 130; Identification information assigned to the mobile receiver 130 may be used. Alternatively, a MAC address or other identifying information from host device 160 can be used to designate direct transmission to an individual or group of recipients 120 .

In one embodiment, mobile receiver 130 is an intermediate receiver/transceiver operable to receive transmissions from central service 200, optionally decode them, and transmit them further to host device 160. configured as Transmission from the mobile receiver 130 to the host device 160 is done by any communication link available on the host device 160 or by a plug-in module if a port on the device such as a Bluetooth adapter is available. may be broken. The mobile receiver 130 is operable to communicate with the host device 160 through an application 170 running on the host device 160 or through a terminal emulator program such as Remote Desktop from Microsoft(R). is. Application 170 enables compact messaging for controlling screens that can be pre-stored on host device 160 .

Turning to FIG. 4, host device 160 having display 410 is shown. The host device 160 may be a cellular mobile phone, smart phone, session establishment protocol (SIP) phone, laptop, personal digital assistant (PDA), satellite radio, global positioning system, multimedia device, vehicle radio or It may be a navigation system or computer, video device, digital audio player (eg, MP3 player), camera, game console, or any other similar device. Host device 160 may also be referred to by those skilled in the art as mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device. , a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable name. Host device 160 may be configured by application 170 to receive or process data broadcast at venue 110 . In one embodiment, recipient 120 downloads application 170 to host device 160 from a suitable application provider or app store. When recipient 120 opens application 170, application 170 can be configured to synchronize or otherwise communicate with mobile receiver 130 (wired or wireless, eg, via Bluetooth). Mobile receiver 130 transmits broadcast data processed by application 170 to host device 160 . A separate or integrated helper application such as a media player may be used to play the audio/video data. application

In one embodiment, application 170 displays broadcast data on display 410 that can be viewed by recipients 120 similar to a conventional website or mobile app. In one embodiment, application 420 may include a user profile associated with host device 160 . A user profile may include user preferences, including, for example, preferred languages. If it is anticipated that a particular broadcast will require the ability to send individual or group messages, that specific messages and instructions will be delivered over the air that can only be executed by receivers matching the address. address provisioning will be defined. Broadcast data may be displayed in the language specified in the user profile. In some embodiments, the host device 160 is a base station, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), or It may be some other suitable terminology. In one embodiment, host device 160 and mobile receiver 130 are configured within the same physical device.

In one exemplary embodiment, the system 100 had a mobile receiver 130 in the form of a small (e.g., 1 inch by 1 inch) Bluetooth-equipped fob or pocket receiver, respectively. Deployed in football stadiums to communicate digital data to receivers 120 of game participants. The football stadium is equipped with a 4-foot tall antenna for wirelessly broadcasting data to data server 140 and transmitter 150, mobile receivers 130. FIG. Each mobile receiver 130 receives, for example, game scores and statistics, video highlights and replays, messages, fan contests, advertisements, announcements, weather updates, custom programs, promotions, live video, etc. broadcast data including from transmitter 150 and retransmits the broadcast data via Bluetooth to a paired host device 160 including a mobile phone, tablet, computer, or other wireless device.

For example, host teams or stadium owners generate revenue by claiming a portion of the sales made through mobile receivers during events, or by charging for sponsorships or advertisements broadcast during games. be able to. Host device 160 is operable to run applications 170, such as apps downloaded before or during a game, for example from the Apple Store or Android App Store. When activated by a recipient, the application processes and displays broadcast data made available on the host device 160 from which the data was received from the fob of the mobile receiver 130 .

Applications running on host device 160 can be configured to display information on display 410 based on the instructions provided in the broadcast. These instructions can refer to tables containing specific information to be displayed, for example, as shown in FIGS. 5A-5D. The manner in which broadcast data is used will depend on the programming of host device 160 paired with mobile receiver 130 . A memory map may be organized in a series of "tables" to keep the data organized in small increments. In one configuration, there can be up to 255 different tables, with up to 255 rows and 255 columns per table. Each "cell" in the table will contain a single item that can be individually addressed by the application 170 on the host device 160 . Although it is not necessary, it may be preferable to organize the tables so that the data stored in each table is similar in nature. An application 170 running on the host device 160 can control any portion of the display information that is to change by storing the data set in one of the tables, as shown. It will be written as it will be.

In these examples, the data type is indicated by 'B' for octets and 'S' for strings. For example, {GF}, which refers to one or more group-filtered messages requesting evaluation of the group ID and, in this example, indicating that the instructions broadcast to the host device 160 change to false. Symbols for certain features may also be represented, such as {Sticky}, which means that once set to "true" they should not be changed to false. To avoid confusion with systems that use other than 8 bits for a "byte", it is understood that when this disclosure or charts refer to a "byte" it refers to an "octet" or 8 bits. should.

In one example shown in FIG. 5A, at row 12, column E, the broadcast broadcasts the appropriate "home team" roster (in this case, Table 3) and at row 12, column F, the "visiting team". Indicates where the application should look to find the roster (Table 4). Each column has a "Team ID" (octet) corresponding to the table containing this team's roster. An illustrative table configuration that would contain such roster specific data is shown in FIG. 5B. Returning to FIG. 5A, at row 11 column C, reference is made to the video display. An exemplary lookup table T200 is shown in FIG. 5C. In this example, the first cell in the table indicates how many additional cells are needed to build the complete video. Pictures or other multimedia files may be provided as well. Other information such as screen color can be similarly provided in the lookup table, an exemplary lookup table is shown in FIG. 5D. The amount of data per cell is preferably kept small. The table is recreated many times and each transmitted from the transmitter stream at a rate of, for example, 200 kilobits per second. In one example, every cell in every table is rewritten every 5 seconds. Thus, new information can be displayed without re-rendering the entire display.

Turning to FIG. 5E, host device 160 and display 410 are shown with an exemplary "home page" for application 170 . A comment is overlaid indicating the application's 170 reference to the appropriate data to be displayed. For example, the first team's graphical symbol or logo displayed at 510 is mapped to Table 1, Row 0, Column 2. Since the reference element is a graphic symbol (or photo, logo, etc.), the data for the reference cell location in Table 1 will be assigned to a specific graphic symbol file. In another example, game time 520 ("3:00 PM ET") is found in the cell at table 1, row 0, column 1. As the information in the cell at each location is changed or removed over time, the display will update with new information. In one embodiment, the data specified in the table, row, and column positions will be displayed by application 170 as the data appears in the table cells (eg, text or numbers). In another embodiment, the data contained in the lookup table cell corresponds to a command to display some other data. For example, the "game status" of a game of Alabama vs. Clemson is indicated by the data in table 1, row 1, column 1 containing the number 4. In this example, the contents of Table 1, Row 1, Column 1 refer to specific text or additional actions to be displayed, as shown in Table 1.

<tables><img file="JP7170751B2_D0001.tif" /></tables>Application 170 then displays the text "confirmed" as shown at 5E when cell Table 1, Row 1, Column 1 contains the number 4.

In one embodiment, recipient 120 can interact with data shown on display 410 . For example, when a user "clicks" or taps, or otherwise interacts with, a section of display 410 linked to that cell, assuming there is some degree of connectivity to the Internet, host device 160 will connect to the URL and relay the request along with the recipient's 120 contact information. For example, this may include purchase requests. In this way, broadcast content can allow users to browse catalogs or menus and then relay purchase requests over the Internet without having to use the Internet to download the content.

Turning to FIG. 6A, an exemplary message encapsulation protocol 500 that enables transmission of broadcast data without requiring two-way communication is shown. Message protocols allow digital instructions, files, streaming data, or any other type of digital information to be sent to multiple devices simultaneously.

In one embodiment, the digital information that is broadcast consists of each octet of data in a message with a preamble containing the address information of the intended mobile receiver 130 and, where appropriate, the location of the data within a larger file. structured to fit. This address information allows data to be sent in any sequence necessary to accomplish the overall network task. Binary data can be mixed with larger data files without destroying the larger files. Address information can be in the form of database addresses, table structures, or memory maps, for example. Each message sent contains all the address information necessary for the intended mobile receiver 130 to interpret, act on, or store the broadcast data.

Multi-octet message data with a preamble (or postamble) identifying in particular a Venue ID identifying which stadium/venue the data transmission is to reach when the data transmission is broadcast from the central service 200 It will preferably have a structure. Since there may be multiple events taking place at the same time and in close proximity, the mobile receiver 130 may, in certain embodiments, be preset to a particular event/venue when activated. good. This structure also matches the identity of the mobile receivers 130, such as matching the "global broadcast" to be received by all mobile receivers 130 for the venue 110, or the MAC address of the mobile receivers 130. A message type such as "specific" for a particular mobile receiver 130 can be included, which can be determined by configuring. In one embodiment, an application running on the host device 160 automatically sends the application to the central service 200 on which it is running and to any venue where the application is receiving the broadcast. programmed to communicate. Central service 200 then links this information, for example, to a database of recipients 120 created when the application was first installed on the user's host device. The MAC address of the mobile receiver 130 is associated with the venue in the database and can indicate when/when the central service 200 needs to deliver individual/group messages. This structure may also include additional octets with the mobile receiver's 130 identification (eg, MAC address) for certain types of messages. This structure may also contain memory maps or message type identifiers, which indicate how the broadcast data should be used and/or any predefined Tell mobile receiver 130 and/or host device 160 (if appropriate) where to store in the memory map. In one embodiment, this information is defined within the application when installed on host device 160 . If the address information stored in the predefined cell location (described below) matches the MAC address of the mobile receiver 130, then the contents of the payload of this particular message are executed as defined by the application. may be This structure will further contain the message data. For video or images, the message may be a single or group of pixels.

In one embodiment, adjustments have been made to ensure message delivery without back channel acknowledgment signals to account for back channel bandwidth shortages. Central service 200 will preferably continuously transmit all messages for a predetermined period of time, even if all messages have been received by the host device for a long time. This would allow "backfilling" of message data that may have been lost in the first transmission, but due to lack of authorization, to know what data is missing. There are currently specifications for By continuously resending for a given period of time, most messages will eventually be delivered completely without the need for approval. In sports applications, for example, scores will be constantly resent unless/until they change. At this point, the reviewed scores will become part of the carousel broadcast. The content used by the application will be constantly rebroadcast using this carousel method so that the latest information is available to the user at any given time.

FIG. 6A shows exemplary container format or header information 610 for transmitting data streams for use with the systems and methods described herein or elsewhere. Messages can be of various lengths, from as small as 9 octets to 60 octets.

The '0' octet 611 of each message contains a 'message ID'. This number indicates the type of message that follows. The '01' octet 612 is the 'venue ID'. As mentioned above, this is a number set by the transmitter program and sent by the central service 400, unique to each event/venue and/or event/venue/date. A transmitter program, in one embodiment, is a software program that runs on the central service 200 or on any local service used at a particular event. The transmitter program (and local service transmitter programs) is responsible for creating all message packets to be broadcast on a particular event. These message packets are then communicated to data server 140, where the message packets are continuously transmitted by transmitter 150 until modified or removed (eg, by central service 200 or local service). added to the carousel buffer for broadcast. Software within host device 160 stores the venue ID number in memory (eg, NVRAM) by comparing the '01' octet of each message to the stored venue ID number. If the saved number is the same as the number contained in octet '01' of the message, the saved number can be ignored and the message is processed normally, i.e. parsed, should be stored in memory. If the number contained in octet "01" of the message is different from the one stored in memory, all data stored in all tables will be cleared and the new number will be stored. A new table is then created and loaded with the data in subsequent received messages. In one embodiment, using this process, when a recipient goes to a new event, location, or venue, the recipient's host - Old data that may be stored on the device's display is "cleared". In another embodiment, an exception is made when venue ID=0. In this case, no memory reset is initiated and received messages are treated as "individual addresses" or messages directed to a particular mobile receiver 130 . The first six octets of the "Individual Address" message may be used to indicate the identity of the mobile receiver 130, eg, the intended mobile receiver's 130 MAC address or other ID. All other mobile receivers 130 will then ignore this message.

Octet '02' 613 indicates whether the data that follows will be the entire contents of a cell in one of the tables, or if the data that follows will be the sequence of messages that will be used to populate the cell. A number (C_L.). For example, C_L.is '0', the following data becomes the entire contents of the cell. The contents of this message will overwrite the data currently stored in the cell (if any). C._L.is "1", the content of this message will be the first part of what will eventually become the string of characters in this cell. C._L.is "2", the content will be attached to the end of what was sent in the previous message, and so on. In one instance, C_L.is set to '0' or '1', all data currently stored in the cell is overwritten.

Octet '03' 614 contains a number indicating how many total octets are in the message. This number is 8+P_L., where P_L.indicates the number of octets in the actual payload of the message. P._L.=0 indicates a 1-octet payload, P_L.=1 indicates a 2-octet payload, and so on. Checksums are not counted in calculating message length.

Octets '04' 615, '05' 616, and '06' 617 replace octets '07' to 'P'_L.Stores the address position of the information stored up to +7. In one instance, octet '04' 615 indicates the table number, octet '05' 616 indicates the row number, and octet '06' 617 indicates the column number where the data is to be stored. . P._L.indicates the number of octets stored in the cell, so octets "07" through "P_L.+7" is stored sequentially in the cells designated by octets "04", "05", and "06".

The last octet (P_L.+8)618 is always a checksum. This octet is used to validate each message received, but is not stored in the table.

FIG. 6B shows an exemplary message. In this structure, MID=F4=variable length message, VID=48, PID=17, LEN=9, AT=table#=17, AR=row#=1, AC=column#=1, data=D0+D1 = 01, 00, CHK = AD.

In one embodiment, each packet of a message to be broadcast is an independent item. The addressing scheme described above ensures that any packet correctly received by the mobile receiver 130 is paired with any other required packet, regardless of whether the other content has already been completely transmitted. - Allows to be stored, assembled and displayed by the device 160; In other words, if the text part of the alert message is split between 5 packets, as soon as these 5 packets are received, the message will be transferred to the associated multimedia file, e.g. Even though more packets belonging to them may still be broadcast, they can be displayed at the host device 160 . By way of illustration, as shown in FIG. 5, row 0, column 0 is used to display announcements sent to all recipients 120 in the game. Message packets need not necessarily be received by mobile receiver 130 in order, nor need they be consecutive.

In one embodiment, the system works at any baud rate. Time delays between messages have no effect, and packets do not necessarily have to be sent at the same rate throughout the broadcast transmission. In one example, the message format is transmitted at a baud rate of 4800 baud.

In one embodiment, a message format is provided for RF broadcasting of multimedia content. In one alternative embodiment, the message format is used to enable broadcasting the same type of content over the Internet via UDP. Individual packets within a data stream can be received in any order and do not require acknowledgment of receipt, so packets can be sent over a UDP connection. Enabling the use of UDP dramatically improves speed and the infrastructure of a typical Internet server used by those looking to serve content over the Internet to millions of concurrent recipients 120 It is possible to reduce the requirements. Since UDP is a "connectionless" protocol, data sent over UDP can be received simultaneously by millions of recipients 120 without the need to increase server bandwidth or router capacity based on user demand for data. can be processed. Also, since there is no need for data acknowledgments, transfer rates will increase dramatically due to reduced network congestion.

In a further embodiment, multimedia messages or digital data may be transmitted from an FM transmitter to recipient 120 with mobile receiver 130 (even if physically integrated into host device 160). , separate from the host device 160), the mobile receiver 130 comprises an FM radio chip. A host device 160, such as a cellular phone, or an automobile control panel/car radio or stereo, or similar combination radio/navigation system, may contain an FM radio chip. Digital data/multimedia information is segmented and encapsulated using header information as indicated above, modulated for transmission over FM, and then sent from an FM transmitter (e.g., car may be broadcast at, for example, 56 kb/s to mobile receivers 130 (such as FM tuner and demodulator chips and related modules in stereo systems). For a car stereo mobile receiver 130, each packet may alternate between left and right stereo channels. A software application on the host device 160 will receive (or optionally extract) the data from the FM chip, decode and reassemble the segments to recreate the message. Carrier frequencies for such systems may vary from country to country and may be selected by those skilled in the art.

In a further embodiment, transmitter 150 is constantly transmitting and retransmitting the entire broadcast data structure for use by mobile receivers 130 at venue 110 . When the broadcast data (e.g., football game lap times, weather, scores) changes, new messages are sent that overwrite the previously broadcast data in the cell, resulting in updated broadcast data. Display 410 of host device 160 changes to reflect. When broadcast data is used to provide information to the application 170 for display on the display 410, the display 410 does not need to retransmit the entire data set originally used to generate the display. , which can be changed immediately.

Host device 160 constantly regenerates or refreshes display 410 by monitoring broadcast data from mobile receiver 130 to host device 160 . If any broadcast data is changed by a series of messages from the transmitter 150, the display 410 will be updated as soon as these messages are received by the mobile receiver 130 and sent to the host device 160, processed and displayed by the application 170; It can apply broadcast data initialization or display preference information (eg screen color). Any portion of the information shown on the display 410 can be changed to indicate that an event has occurred (eg, change the screen to yellow when racing is under warning). . Exemplary application 420 may be configured such that any content that a publisher wishes to be able to control or modify can be found in tables defined at the beginning of the application programming process. These features can include text, images, screen layouts, host device instruments (such as flashlights in a smart phone), or sounds that can be played on the speaker of the host device 140. can. Content and instructions can be sent and stored at specific locations within the cells of the table, and applications can be written to look for content/instructions within these defined cells. be.

Therefore, even without an acknowledgment signal sent back from receiver 130 to transmitter 150, display 410 of host device 160 shows the complete intended broadcast, even if the broadcast data was initially dropped, lost, or lost during transmission. The data should eventually be fully populated.

In one embodiment, the transmitted broadcast data can also include digital instructions that can be used to control devices at venue 110, as shown in FIG. This can be particularly useful for devices that are desired not to be hardwired to a larger network. Since each message sent contains address information specifying which mobile receiver 130 each message is intended for, the mobile receiver 130 can be used to turn other devices on or off, as well as to broadcast Can be constructed to emit control signals to configure and/or control these devices with digital commands embedded in the data. For example, the mobile receiver 130 may be operable as a controller for a larger screen device, or a rail-based mobility device (eg, a Jumbotron(R) device). On a racetrack, for example, it can be difficult to set up hardwired controllers for each electronic display. Alternatively, the system 100 could be used to control larger devices from the mobile receiver 130, and it would not be necessary for the controller to be wired.

In FIG. 7, a method of broadcasting data 700 to multiple mobile receivers is shown. At step 701, the central service 200 communicates data, including content such as, for example, sports scores, event updates, emergency information, multimedia, etc., to systems located at venues 110, via, for example, the Internet. . Venue 110 is equipped with data server 140 and transmitter 150 for wirelessly broadcasting data. At step 702 data from central service 200 is received at data server 140 in communication with transmitter 150 . In step 703 , data server 140 communicates broadcast data to transmitters 150 to be broadcast to recipients 120 with mobile receivers 130 respectively. In step 704 , transmitter 150 transmits broadcast data to mobile receivers 130 containing at least one transceiver and paired with host device 160 . At step 705, the mobile receiver 130 receives the broadcast data and, at step 706, transmits the broadcast data to the host device 160 running an application for processing and/or displaying the broadcast data. . In step 707, the response from host device 160 is transmitted back to system 100 (if any) via the network available to host device 160, such as a TCP/IP network. In one embodiment, this feature may be used when a menu or catalog item is broadcast to recipients 120, and if the user wishes to purchase something from the menu or catalog item, the user can ( application 170) and a purchase request is sent to a TC/PIP network (e.g., cell

In one embodiment, data server 140 is operable to selectively transmit data received from central service 200 . Data authorized to all recipients at one location may be sent to transmitter 150 for global broadcast to all mobile receivers 130 . Data authorized only for selected recipients is transmitted by the host device 160 or, in another embodiment, by the host device 160 only if the recipient possesses or enters the required code, for example, by providing certain identifying information. may be accessible only to mobile receivers 130 that have In one embodiment, this service may be implemented by a central service 200 or a local service.

In another embodiment, transmitter 150 uses a carousel method to constantly broadcast the entire structure of data to be communicated to mobile receiver 130 . Therefore, even without an acknowledgment signal sent from the mobile receiver 130, the display of the host device 160 will eventually fully populate, even if data is initially missing/lost.

Turning to FIG. 8, an embodiment of the method and system of the present invention suitable for use in an emergency or disaster situation 900 is shown. Until LTE or other broadcast technologies are widely deployed in the United States, WEA multicast messages containing multimedia content will generally not be available in emergency situations. WEA allows customers with certain wireless phones and other compatible mobile devices to receive geographically targeted text-like messages that alert them to imminent threats to safety in their area. It is a public safety system that allows Cell phones are not currently equipped to receive multimedia broadcast messages. One embodiment of the present invention provides a system whereby a receiver desiring to receive a WEA multicast message receives the message sent in packets and then uses the Bluetooth(R) protocol. A mobile receiver 810 is provided, eg, a small Bluetooth(R) equipped digital receiver, used to retransmit messages to a host device 820 (eg, a mobile phone). On host device 820, messages are received by a software application that contains the necessary codecs and APIs to compile message packets back into text, binary commands, or multimedia content, as appropriate. processed by

As an illustration, in hurricanes, government authorities (e.g., FEMA) may provide recipients with updates, weather and news alerts, or emergency alerts from government officials in multimedia information such as maps, videos, photos, etc. Mobile receivers 810 can be distributed to paramedics or residents in the affected areas as they can. Multimedia messages can be broadcast to mobile receivers 810 from mobile or temporary transmitters located in relevant geographies, regions, or venues (eg, shelters). The recipient can send the application to the recipient's mobile phone or other host device, which can be paired with the mobile receiver 810, via any available communication channel, such as Bluetooth, prior to the disaster. can be downloaded.

9A and 9B show exemplary information about government alert messages transmitted through the systems and methods of the present invention. Figure 9A is an illustration of an emergency alert message as specified in the Common Alert Protocol using Extensible Markup Language (XML), Ver. It is a widely-adopted method for national and international distribution. Figure 9B shows how the information in this XML message can be converted into a table format in accordance with the broadcast format described in this invention.

In this embodiment, transmitter 150 is constantly sending out the entire structure of data shown stored in the table. As things change (e.g. "urgency" or "certainty" levels, or image files or GIFs), the broadcast data message will overwrite the data in the cell where this data was stored. . The display 410 of host device 160 will change to reflect the updated information.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any instruction or data structure. and any other medium that can be accessed by a computer that can be used to carry or store desired program code in the form of . Disk and disc, as used herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), and floppy discs; A disk usually reproduces data magnetically, while a disk reproduces data optically with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Turning to FIG. 10, a flow chart is shown. At step 1000 , host device 160 running application 170 activates a file delivery session for broadcast service at venue 101 . The host device 160 begins downloading content on the defined network address and port associated with the transport session ID of the file delivery session. At step 1001 , host device 160 receives at least one first media segment associated with a digital file broadcast at venue 101 . At step 1002 , host device 160 receives at least one second media segment associated with the digital file broadcast at venue 101 . In one embodiment, this method is used to transfer digital files (e.g., images, audio, and video).At a particular venue, the desired digital file is stored as a series of cells in a table. A table is defined to store the digital information needed to create a file.The digital file is divided into segments (eg, between 20 and 60 octets each), each segment is then Stored in different cells in the table, an application 170 running on the host device 160 evaluates the contents of the received media segments and, according to the original digital file, becomes accessible or visible by the user. are combined in canonical order.

FIG. 11 shows a conceptual data flowchart showing the data flow between different components in the exemplary device 1100 . The device may be host device 160 . Apparatus 1100 includes a broadcast data management module 1101 operable to activate a broadcast network session at a venue. Apparatus 1100 further includes a broadcast data processing module 1102 operable to receive data streams from network 1103 during a session. The data stream includes at least one encapsulated digital data file segment, and the at least one encapsulated digital data file segment is associated with address information. Apparatus 1100 further includes a data cache module 1104 operable to cache at least one encapsulated digital data file segment. The apparatus 1100 has a content processing module 1105 used to decode multimedia encapsulated digital data file segments for playback while also using cached encapsulated digital data file segments. further includes Broadcast data processing module 1102 may be further operable to receive additional encapsulated digital data file segments associated with the digital data file. Accordingly, each step of the flowcharts described above may be performed by a module, and apparatus 1100 may include one or more of these modules.

FIG. 12 is a diagram showing an example implementation for an apparatus 1200 using a processing system 1201. As shown in FIG. Processing system 11201 may be implemented with a bus architecture. Processing system 1201 may include any number of interconnecting buses and bridges, depending on the particular application of processing system 1201 and overall design constraints. Processing system 1201 links together various circuits including one or more processors and/or hardware modules represented by processor 1202, processing modules 1203, 1204, 1205, and 1206, and computer readable medium 1207. do. Processing system 1201 may also be linked with various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits known in the art. Processing system 1201 may be coupled to transceiver 1208 . Transceiver 1208 is coupled to one or more antennas 1209 . Transceiver 1208 provides a means for communicating with various other devices over a transmission medium. Processing system 1201 includes a processor 1202 coupled to computer readable media 1207 . Processor 1202 is responsible for overall processing, including execution of software stored in computer readable media 1207 . The software, when executed by processor 1202, causes processing system 1201 to perform the various functions described above for any particular device. Computer readable media 1207 may also be used to store data that is manipulated by processor 1202 when executing software. Modules 1203, 1204, 1205, and 1206 are software modules residing/stored on computer readable medium 1207 running on processor 1202, one or more hardware modules coupled to processor 1202, or any of these modules. may be some combination of Processing system 1201 may be used by host device 160 and/or mobile

It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Additionally, some steps may be combined or omitted. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Accordingly, the claims are not intended to be limited to the embodiments shown herein, but are intended to be accorded full scope consistent with the language of the claims, References to elements in the singular are construed as "one and only" unless specifically indicated as such. is not intended to mean "one)", but rather "one or more". Unless specifically indicated otherwise, the term "some" refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later become known to those skilled in the art are expressly incorporated herein by reference and claimed. is intended to be encompassed by the scope of Moreover, nothing disclosed herein is intended to be dedicated to the public, regardless of whether such disclosure is expressly recited in the claims. No claim element should be interpreted as means plus function unless the element is explicitly described using the phrase "means for."

Therefore, it is not intended that the invention be limited to the particular embodiment disclosed as the best mode contemplated for carrying out the invention, but that the invention be construed to include all implementations that come within the scope and spirit of the appended claims. It is intended to include examples.