Method for broadcasting digital data to a plurality of receivers

CROSS-REFERENCE TO RELATED APPLICATIONS

0001<b>]</b> This application claims priority from <patcit id="pcit0001" dnum="US62635104" dnum-type="L"><text>U.S. Provisional Patent Application Ser. Nos. 62/635,104 for "Methodology Developed for the Transfer of Digital Information by Broadcasting to an Unlimited Number of Receivers" filed February 26, 2018</text></patcit>, and <patcit id="pcit0002" dnum="US62792003B"><text>62/792,003, for "System and Method for Broadcasting Digital Data to Receivers," filed January 14, 2019</text></patcit>.

FIELD OF THE INVENTION

0002<b>]</b> This invention relates to the wireless broadcast of digital information to a plurality of receivers, especially in environments where bi-directional communications are not possible or practical.

BACKGROUND OF THE INVENTION

0003<b>]</b> In environments where large groups of people congregate, such as at sporting events, rallies, speeches, concerts, etc., access to digital data using mobile phones and wireless devices is unreliable.

0004<b>]</b> In such instances, high numbers of mobile devices compete for the attention of a cellular network's nearby antennas. Although a mobile device user may see bars on the device's screen showing there is a signal available, data is not being received and returned from the cellular network consistently. Such networks may be further strained by "high traffic" because such events are frequently occasions when recipients 120 are apt to use data-heavy applications and multimedia such as voice, photo, media and video sharing that consume large amounts of network bandwidth.

0005<b>]</b> Analogous network overload occurs in emergency situations or during disasters. Following the Boston Marathon bombing, for example, mobile phone carriers were swamped with traffic as thousands of people attempted to reach loved ones in the Boston area. In the aftermath of natural disasters, terrorist attacks, and other such incidents worldwide, telecommunications networks simply are not able cope with a sharp increase in voice call volume or data traffic (e.g., text/SMS and multimedia messages). Recipients 120 of every major mobile carrier reported outages in the Boston metropolitan area during the event. This led to the spreading of unconfirmed rumors that were taken as facts by the media, such as the Associated Press incorrectly reporting that mobile service had been shut off in Boston to prevent remote detonation of bombs with mobile phone times.

0006<b>]</b> Natural disasters may also cause cellular networks to be unreliable. Shortly after hurricane Sandy, for example, the FCC warned that mobile service was devastated by the storm (https://www.fastcompany.com/3002578/post-sandy-fcc-warns-worsening-cell-phone-networks). Although Sandy involved a physical destruction of mobile network infrastructure that was very different from high network volume, the basic elements are the same.

0007<b>]</b> When disaster strikes, the decentralized nature of the network means that entire geographic regions can be compromised by increased network usage, particularly from recipients 120 seeking real-time information from central (e.g., news, governmental) sources in the areas related to an event. When bandwidth at carrier site is strained, recipients 120 are prevented from making calls and communicating digital, and in particular, multimedia data.

0008<b>]</b> Similarly, in poor connectivity environments, communication between mobile devices and mobile or other networks may be unreliable, particularly when combined with "high density" locations such as construction sites, healthcare facilities, shopping malls, convention centers, etc.

0009<b>]</b> Despite these challenges, recipients 120 expect to remain connected via their mobile devices anytime and anywhere. Cellular and networking companies have deployed a mix of strategies to increase reliability under such circumstances. For example, current cellular technologies will allow an approximate maximum of 2,000 simultaneous connections per cell tower or distributed antenna system (DAS) sector. At a large event like a stadium football game, in order to reach 50,000 fans simultaneously, 25 cell phone towers would be required. Some networks have added or upgraded antennas in or near large-capacity venues and in the cell towers nearby, and some have installed "small cells" to improve capacity inside large-crowd venues like sports stadiums. Small cells have a smaller range than regular cell towers, but they can supplement those towers to boost capacity in dense areas. Networks also deploy temporary cell sites to large-capacity venues, sometimes referred to as a "cell on wheels," or <i>cows,</i> to boost network connectivity.

0010<b>]</b> Newer venues are also more likely to have Wi-Fi, which relieves stress on the cellphone network. But historically, Wi-Fi equipment has been installed high up in ceilings or walls. Signals can thus be interrupted by obstructions from steel and other construction materials. And mobile device recipients 120 can be relativity far away from the routers, comprising communication with the network. Wi-Fi capacity also tends to be smaller: current Wi-Fi technology allows less than 200 simultaneous connections per access point (antenna). Access points also typically only have a 100 foot leave.

0011<b>]</b> However, these network improvements have not made network service in crowded areas consistently reliable, particularly with respect to communication of digital data, e.g., photos, videos, and multimedia content. Even with improved infrastructure in place, technical challenges and limitations associated with the proximity of the multiple transmitters, movement of fans, and other complexities make it impossible to reach all of the attendees simultaneously.

0012<b>]</b> Current digital file transfer protocols such as TCPIP, Bluetooth, and other protocols require a bi-directional communication link to function in order to provide a back-channel for digital acknowledgement of proper file reception. The bi-directional nature of the communication between, e.g., a cell tower and a mobile device means that communications or transmissions can be dropped if there is an interruption in communications. There exist certain file transfer protocols that do not require bi-directional feedback, such as UDP, but these protocols still require continuous, uninterrupted reception of an entire file in order to assure uncorrupted data is transmitted and successful received at the receiving end. Accordingly, a need exists for file transfer protocols that permit receipt of uncorrupted digital data even where the signal is not perfectly continuous and uninterrupted.

0013<b>]</b> With respect to emergency situations and natural disasters, Congress has directed the establishment of a process for the creation of a national mobile alerting system, now known as WEA, whereby participating commercial mobile service ("CMS") providers transmit emergency alerts to their subscribers. Since then, there has been a high level of participation by CMS providers, with all four major wireless carriers participating in the system, which accounts for 98.6% of the U.S. population being served. Yet despite most areas of the country now being covered, there is continued concern about the content, presentation and geographic targeting of the WEA Messages.

0014<b>]</b> In recent years, the Commission has expended considerable time and effort on the question of improving the content and method of delivery of WEA Messages. For example, capabilities of WEA Messages have been 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 reduce public confusion caused by difficult-to-understand abbreviations. But there is still a need for improvement in the quality of WEA Alert messaging, particularly with respect to multimedia, which can not only improve the content of the information provided, but also assist in further identifying the actual nature and location of emergency situations (such as by providing maps in alerts). The recent confusion caused by a false WEA Alert Message regarding a supposed missile attack on Hawaii has increased this push to improve messaging through inclusion of multimedia. Similarly, in the case of the recent California fires in the Santa Barbara area, residents and first responders could have benefited from multimedia such as maps that would have more clearly delineated the areas affected by evacuation orders.

0015<b>]</b> CMS carriers and others in the telecommunications industry assert that insertion of multimedia in WEA Alerts is not yet feasible. The industry's standards organization, Alliance for Telecommunications Industry Solutions ("ATIS") maintains that "[c]ell broadcast technology is not designed for multimedia" and "numerous issues that would make the presentation of multimedia content in WEA notifications problematic if not technically infeasible." (<nplcit id="ncit0001" npl-type="s"><text>Comments of The Alliance for Telecommunications Industry Solutions in PS Docket 15-91, January 13, 2016</text></nplcit>, at 9.) ATIS further contends that "presentation of multimedia content, such as maps, photos and hazard symbols, in WEA notifications [is] problematic if not technically infeasible[.]" (<i>Id.</i> at 10.)

0016<b>]</b> Improved systems and methods for broadcasting digital data, particularly in emergency situations, or in high-density, poor connectivity environments, is desired.

0017] Additionally, improved systems and methods for broadcasting multimedia, particularly in emergency situations, or in large capacity venues, is desired.

0018<b>]</b> Further, improved systems and methods for broadcasting encrypted messages that are relevant to an event or emergency are desired, and additionally, broadcasting messages to selected receivers is desireable, e.g., certain emergency responders.

0019<b>]</b> Sponsors and marketers are likewise seeking better ways to connect to recipients on mobile devices at large events (e.g., sporting events or concerts) to execute brand activation campaigns. <patcit id="pcit0003" dnum="US2013091251A1"><text>US-A1-2013/091251</text></patcit> discloses broadcasting encoded media (audio/video) data by HTTPs streaming over Internet.

SUMMARY OF THE INVENTION

0020<b>]</b> The invention comprises; according to claim 1, a method for broadcasting digital data that that eliminate the need for either a feedback loop, or uninterrupted reception of a data stream, in order to accurately transfer digital, and in some instances, multimedia, information. More particularly, the invention permits the wireless broadcast of digital information to a plurality of receivers in environments where bi-directional communications are not possible or practical.

BRIEF DESCRIPTION OF THE DRAWINGS

0021] The invention is disclosed with reference to the accompanying drawings, wherein: <ul id="ul0001" list-style="none"><li><figref idref="f0001">Fig. 1</figref> is a diagram illustrating a portion of a system architecture according to one embodiment of the invention;</li><li><figref idref="f0002">Fig. 2</figref> is a diagram illustrating a portion of a system architecture according to one embodiment of the invention;</li><li><figref idref="f0003">Fig. 3</figref> is a diagram illustrating an example mobile receiver and a host device according to one embodiment of the invention;</li><li><figref idref="f0004">Fig. 4</figref> is a diagram illustrating an example display on a host device according to one embodiment of the invention;</li><li><figref idref="f0005">Fig. 5A</figref> is an illustrative diagram of an example schema for a display according to one embodiment of the invention;</li><li><figref idref="f0006">Fig. 5B</figref> is an illustrative diagram of an example reference table according to one embodiment of the invention;</li><li><figref idref="f0007">Fig. 5C</figref> is another illustrative diagram of an example reference table according to one embodiment of the invention;</li><li><figref idref="f0008">Fig. 5D</figref> is another illustrative diagram of an example reference table according to one embodiment of the invention;</li><li><figref idref="f0009">Fig. 5E</figref> is an annotated a diagram illustrating an example display on a host device according to one embodiment of the invention, where the references refer to location information within a reference table;</li><li><figref idref="f0010">Fig. 6A</figref> is an illustrative diagram of an example message structure schema according to one embodiment of the invention;</li><li><figref idref="f0010">Fig. 6B</figref> is an illustrative diagram of an example message structure according to one embodiment of the invention;</li><li><figref idref="f0011">Fig. 7</figref> is a flow diagram illustrating a method according to one embodiment of the invention;</li><li><figref idref="f0012">Fig. 8</figref> is a diagram illustrating a portion of a system architecture for transmitting emergency alerts according to one embodiment of the invention;</li><li><figref idref="f0013">Fig. 9A</figref> is an illustrative diagram of an example emergency alert message structure schema and sample emergency alert message according to one embodiment of the invention;</li><li><figref idref="f0014">Fig. 9B</figref> is diagram illustrating an example Extensible Markup Language (XML) schema structure and sample emergency alert message;</li><li><figref idref="f0015">Fig. 10</figref> is a flow diagram illustrating a method according to one embodiment of the invention;</li><li><figref idref="f0015">Fig. 11</figref> is a block diagram illustrating an example hardware implementation according to one embodiment of the invention; and</li><li><figref idref="f0016">Figs. 12</figref> is a block diagram illustrating the functionality of an example implementation according to one embodiment of the invention.</li></ul>

0022<b>]</b> Corresponding reference characters indicate corresponding parts throughout the several views. The examples set out herein illustrate several embodiments of the invention but should not be construed as limiting the scope of the invention in any manner.

DETAILED DESCRIPTION

0023<b>]</b> Turning now to <figref idref="f0001">FIG. 1</figref>, a system for communicating data with a large number of devices in a one to many configuration is provided. The system is operable to push any type of digital information, including, but not limited to, digital files, streaming data, multimedia files, and digital functions which can then be used for command and control of digital devices.

0024<b>]</b><figref idref="f0001">FIG. 1</figref> illustrates a system 100 deployed in a venue 110 to communicate digital data to a large groups of recipients 120 each having a mobile receiver 130. The venue 110 is equipped with local (and/or a central) server, a data server 140 and a transmitter 150 for broadcasting data wirelessly. Transmitter 150 may be a small (e.g., 4 foot) antenna deployed 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 operating on a remote computer device. Each mobile receiver 130 can retransmit data to a host device 160, such as a mobile 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, if used, is operable to run an application 170 that is displayed or otherwise made available on host device 160 data received from the mobile receiver 130, and permits transmission of responses thereto over networks available to host device 160, preferably TCP/IP networks. System 100 may interconnect with other access networks, but for simplicity those entities/interfaces are not shown. As shown, system 100 provides packet-switched services.

0025<b>]</b> In one embodiment, recipients 120 receive encrypted or coded messages intended only for their mobile receiver 130 by registering their mobile receiver 130 with a central service detailed in <figref idref="f0002">FIG. 2</figref>.

0026<b>]</b> In an embodiment illustrated in <figref idref="f0002">FIG. 2</figref>, a data feed (which may include data broadcast programming) is provided venue 110 via the internet from a networked central service 200. Central service 200 may include servers, which can be Web servers or streaming servers tailored for the audio/video streaming application. The files on the servers may contain any type of audio/video/text/command content. Central service 200 directs an audio/video/text/command file to the client by sending the file into a socket. Both TCP and UDP socket connections may be used. Before sending the audio/video/text/command file into the network, the file is segmented, and the segments are encapsulated with header information appropriate for audio/video/text/command traffic, described in further detail below. Data formatting and generation may be accomplished at central service 200, or a similar service local to a venue. Data server 140 is capable of receiving content from more than one server (central service 200, or one or more local services). In one embodiment, data server 140 stores all messages on a "carousel"-type buffer and constantly broadcast the contents of the buffer via transmitter 150. "Carousel"-type refers to a session protocol that repeatedly broadcasts a set of data packets over an amount of time in order to ensure that they are received by one or more receivers.

0027<b>]</b> Operators at the central service may manually enter encapsulation data element by element or, alternatively, central service may be operable to automatically enter encapsulation data.

0028<b>]</b> At venue 110, the data feed is received at data server 140 and communicated to transmitter 150 via, e.g., via a UDP protocol on an ethernet connection. Data server 140 may include a serving gateway and a Packet Data Network (PDN) gateway, and a control node that processes the signaling between central service 200 or local service(s) and mobile receivers 130. Transmitter 150 may be a permanently installed arena transmission antenna that sends out an RF signal over a selected distance, for example, a 3.5 square mile/6 km area (one mile /1.6km radius). Transmitter 150, in one embodiment, transmits a one-way data broadcast between 217-220MHz (200kbps). With FCC permission, the selected distance may be larger. Several types of transmission mechanisms as are known in the art may be employed, including pulse-code modulation (PCM) over an FM radio signal, ISDB-T, ISDB-T, multimedia broadcasting, Digital System E, T-DMB, DVB-H, DVB-SH, FLO, RAVIS and DVB-T2 Lite.

0029<b>]</b> Turning to <figref idref="f0003">FIG. 3</figref>, mobile receiver 130 and host device 160 are shown. Mobile receiver 130 may be a stand-alone receiver, designed to interface with and control a separate, non-digital device. In another form, mobile receiver 130 is operable to relay data to host device 160 via a wired or wireless communications protocol, e.g., Bluetooth. In yet another embodiment, mobile receiver 130 is integral to host device 160. In one embodiment, mobile receiver 130 is designed to be installed into vehicles, powered by the car's electrical system and powered up when the car is running. In another embodiment, mobile receiver 130 is portable and powered by batteries and turned on by a user. Mobile receiver 130 operations can use any RF frequency capable of sustain digital communications. In one embodiment, mobile receiver 130 operates on a frequency of 217 MHz.

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

0031<b>]</b> Mobile receiver 130 may have a port or connector (e.g., USB) for charging and data upload, and control switches, e.g., buttons, to activate and control various functions. A status/data transmission indicator, for example, a light, may also be provided. Mobile receiver 130 may be in the form of a small fob, via Bluetooth or other communications link including, but not limited to IR, short range EMF, near field transmission, etc., to a host device 160. Mobile receiver 130 may be operable to receive broadcast data from transmitter 150. Mobile receiver 130 may further include a transceiver to communicate with or otherwise transmit and receive data to and from host device 160, such as an acknowledgement signal or a control signal. In one embodiment, neither mobile receiver 130 nor host device 160 has broadband back/reverse channel capability back to central service 200, rather, host device 160 communicates with mobile receiver 130 via short range communications or narrow band back channel. Mobile receiver 130 may also communicate with a plurality of fixed transceivers located around venue 110 for that purpose. Mobile receiver 130 may further include a radio receiver or chip operable to receive standard FM radio broadcasts in the 88-108 MHZ frequency band. In one embodiment, mobile receiver 130 is a configuration of modules on host device 160 including an FM radio receiver.

0032<b>]</b> Mobile receiver 130 may be assigned identifying information, such as a MAC address or other identifying code, such as EMEI or equivalent. Mobile receiver 130-assigned identifying information may be used so that a particular mobile receiver 130 can receive data broadcast transmissions intended to be both generally broadcast to all devices and specifically directed to identified mobile receiver(s) 130. Alternatively, the MAC address or other identifying code from the host device 160 can be used to specifically direct transmissions to an individual or group of recipients 120.

0033<b>]</b> In one embodiment, mobile receiver 130 is configured as an intermediary receiver/transceiver that is operable to receive transmissions from central service 200, optionally decode them, and transmit them further to host device 160. The transmission from mobile receiver 130 to host device 160 may be accomplished by any communication link that is available in host device 160, or by a plug-in module if a port is available on the device, such as a Bluetooth adapter. Mobile receiver 130 is operable to communicate with host device 160 via application 170 running on host device 160, or via a terminal emulator program, such as Remote Desktop from Microsoft^®. Application 170 allows compact message communications to control screens that may be previously stored in host device 160.

0034<b>]</b> Turning to <figref idref="f0004">FIG. 4</figref>, host device 160 is shown with a display 410. Host device 160 may be a cellular mobile phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, an in-car radio, a digital audio player (e.g., MP3 player), a camera, a game console, or any other similar device. Host device 160 may also be referred to by those skilled in the art as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a 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 with an application 170 to receive or process the data broadcast at venue 110. In one embodiment, recipients 120 download application 170 to host device 160 from an appropriate application provider or app store. When recipients 120 open application 170, application 170 is configurable to sync or otherwise communicate with mobile receiver 130 (wired or wirelessly, e.g., via Bluetooth). Mobile receiver 130 transmits broadcast data to host device 160 that is processed by application 170. Separate or integrated helper application(s) like media players may be employed for playing audio/video data. Application 170 may further decompress the audio/video on the fly during play, suppress packet jitter, provide a graphical user interface for display to a recipient, etc.

0035<b>]</b> In one embodiment, application 170 displays broadcast data on display 410, which may be viewable by recipients 120 the same way as a traditional website or mobile app. In one embodiment, application 420 may include a user profile associated with host device 160. The user profile may be include user preferences, including, for example, preferred language. If it anticipated that a particular broadcast will need to be able to send individual or group messages, then there will be address provisions defined whereby specific messages and instructions can be delivered over the air that will only be actionable by a receiver matching the address. Broadcast data may be displayed in the language specified in the user profile. In some embodiments, host device 160 may be a base station, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology. In one embodiment, host device 160 and mobile receiver 130 are configured within the same physical device.

0036<b>]</b> In one exemplary embodiment, system 100 is deployed in football stadium to communicate digital data to game attendee recipients 120 each having a mobile receiver 130, in the form of a small (e.g., 1 inch by 1 inch) Bluetooth-enabled fob or pocket receiver. The football stadium is equipped with data server 140 and a transmitter 150, a 4 foot tall antenna for broadcasting data wirelessly to the mobile receivers 130. Each mobile receiver 130 receives broadcast data from transmitter 150, including, for example, game scores and statistics, video highlights and replays, messages, fan contests, advertisements, announcements, weather updates, custom programs, promotions, live video, etc., and retransmits the broadcast data to paired host device 160 via Bluetooth, including mobile phones, tablets, computers, or other wireless devices.

0037<b>]</b> The host team or stadium owner, for example, may generate revenue by requiring a portion of sales made through mobile receivers during an event, or charging for sponsorships or advertisements broadcast during a game. The host devices 160 are operable to run an application 170 such as an app that is downloaded prior to or during the game from the Apple or Android App Stores, for example. When activated by a recipient, the application processes and displays broadcast data made available on host device 160 data received from the mobile receiver 130 fob.

0038<b>]</b> The application running on host device 160 is configurable such that it displays information on display 410 based upon instructions provided in the broadcast. These instructions may reference tables containing specific information to display, for example, as shown in <figref idref="f0005 f0006 f0007 f0008">FIGS. 5A-D</figref>. The manner in which broadcast data is being used will depend on the programming of host device 160 paired to mobile receiver 130. In an effort to keep the data organized into small increments, a memory map may be organized in a series of "tables". 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 addressed individually by application 170 on the host device 160. Although it is not necessary, it may be preferable to organize the tables in such a way as to have the data stored in each table be similar in nature. Application 170 that runs on host device 160 will be written so that any part of the displayed information that will change will be controlled by a data set being stored in one of the tables, as shown.

0039<b>]</b> In these examples, data types are indicated with "B" for octet and "S" for string. Symbols for certain features may be represented as well, for example, {GF}, which refers to a group filtered message or messages requiring evaluation of the Group ID, and {Sticky}, which means in this example that once set to "True," it should not be changed to false, even if instructions broadcast to host device 160 indicate otherwise.

0040<b>]</b> In one example shown in <figref idref="f0005">FIG. 5A</figref>, at row 12, column E, the broadcast indicates where the application should look to find the appropriate "home team" roster (in this case, table 3) and at row 12, column F, the "visiting team" roster (table 4) Each column has a "Team ID" (octet) that corresponds to the table that contains the roster for that team. An example table configuration that would contain the specific data for such rosters is shown in <figref idref="f0006">FIG. 5B</figref>. Turning back to <figref idref="f0005">FIG. 5A</figref>, a video display is referenced in row 11, column C. Exemplary reference table T200 is shown in <figref idref="f0007">FIG. 5C</figref>. In this example, the first cell in the table indicates how many additional cells are required to build the complete video. Photos or other multimedia files may be provided for in the same way. Other information can likewise be provided for in lookup tables, such as screen color, an exemplary lookup table is provided in <figref idref="f0008">FIG. 5D</figref>. Preferably, the amount of data per cell is kept small. Tables are re-created over and over with each transmission from the transmitter stream at a speed of, e.g., 200 kilobits per second. In one example, every cell of every table is re-written every 5 seconds. New information is therefore able to be displayed without re-rendering the entire display.

0041<b>]</b> Turning to <figref idref="f0009">FIG. 5E</figref>, host device 160 and display 410 are shown with an exemplary "home page" for application 170. Overlayed are comments indicating application 170's references to the appropriate data to be displayed. For example, the graphic or logo for the first team displayed 510 is mapped to Table 1, row 0, column 2. Since the referenced element is a graphic (or photo, logo, etc.), the data at the referenced cell location in Table 1 will be assigned to a specific graphic file. In another example, the game time 520 ("3pm ET") is found in the cell located at Table 1, row 0, column 1. As the information within the cells at each location is changed or removed over time, the display will update with the new information. In one embodiment, the data specified in the table, row, and column location will be displayed by application 170 as the data appears in the table cell (e.g., text or numbers). In another embodiment, the data included in the referenced table cell is equivalent to a command to display some other data. For example, the "game status" of the Alabama v. Clemson game is indicated by data located in Table 1, row 1, column 1, which contains the numeral 4. In this example, the contents of Table 1, row 1, column 1 reference specific text that should be displayed or additional actions, as shown in Table 1: <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1</title><tgroup cols="2"><colspec colnum="1" colname="col1" colwidth="39mm" /><colspec colnum="2" colname="col2" colwidth="76mm" /><thead valign="top"><row><entry align="center">Table 1, Row 1 Column 1</entry><entry align="center">Reference</entry></row></thead><tbody><row><entry>1</entry><entry>1 = display game start time, including time zone</entry></row><row><entry>2</entry><entry>2 = display contents of cell Table 1, row <i>x</i>, column 0</entry></row><row><entry>4</entry><entry>4 = display text "FINAL"</entry></row><row><entry>5</entry><entry>5 = display text "POSTPONED"</entry></row><row><entry>6</entry><entry>6, 7, 8, 9, 10, 11, 12 = display text "FORFEIT"</entry></row><row><entry>23</entry><entry>23 = display text "DELAYED"</entry></row></tbody></tgroup></table></tables> Application 170, then, when the numeral 4 is included in the cell Table 1, row 1, column 1, displays the text "FINAL" as shown in 5E.

0042<b>]</b> In one embodiment, recipients 120 can interact with data shown on display 410. For example, when a user "clicks" or taps or otherwise interacts on a section of the display 410 that is linked to that cell, assuming there is some level of connectivity to the internet, host device 160 will connect to the URL and relay a request along with the recipients' 120 contact information. For example, this may include a purchase request. In this manner, the broadcast content can enable a user to browse a catalog or menu without using the internet to download the content, and then relay a purchase request over the internet.

0043<b>]</b> Turning to <figref idref="f0010">FIG. 6A</figref>, an exemplary message encapsulation protocol 500 that permits transmission of broadcast data without the need for bi-directional communication is shown. The message protocol allows for the transmission of digital instructions, files, streaming data, or any other type of digital information to plurality of devices, simultaneously.

0044<b>]</b> In one embodiment, the digital information being broadcast is structured such that each octet of data is contained in a message that has a preamble including address information for intended mobile receiver(s) 130, as well as a location of the data within a larger file, if appropriate. This address information allows for data to be transmitted in any sequence necessary to accomplish the tasks of the overall network. Binary data can be intermixed with larger data files without corrupting the larger file. Address information can be in the form of, for example, a database address, table structure, or memory map. Each message being transmitted contains all address information necessary for the intended mobile receiver(s) 130 to interpret and execute or store the broadcast data.

0045<b>]</b> When a data transmission is broadcast from central service 200, it will preferably have a multi-octet message data structure, with a preamble (or post-amble) that identifies, among other things, a venue ID, which identifies which stadium/venue the data transmission is intended to reach. Because there may be multiple events running simultaneously and in close proximity, mobile receiver(s) 130 may be, in certain embodiments, pre-set set to a particular event/venue when activated. The structure may also include a message type, such as "general broadcast" to be received by every mobile receiver 130 for venue 110, or "specific" to a particular mobile receiver 130, which may be determined by matching mobile receiver 130's identifying information, such as a match of mobile receiver 130's MAC address. In one embodiment, an application operating on host device 160 is programmed to automatically communicate to central service 200 that it is operating and what venue it is receiving a broadcast from. Central service 200 then links this information to a database of recipients 120 that was, e.g., created when the application was initially installed on the user's host device. A mobile receiver 130's MAC address can be associated with a venue in the database and refer to that if/when central service 200 needs to pass along an individual/group message. The structure may further include, in the case of a specific-type message, further octets with the mobile receiver 130's identifying information (e.g., MAC address). The structure may also include a memory map or message-type identifier, which tells the mobile receiver 130 and/or host device 160 (if appropriate), how the broadcast data should be used, and/or where it should be stored in a pre-defined memory map. In one embodiment, this information is defined in the application when installed on host device 160. When address information is stored in the pre-defined cell location (described below) matches mobile receiver 130's MAC address, the content of the payload of that particular message may be acted upon as defined in the application. The structure will further include message data. In the case of a video or picture, the message may be a single or group of pixels.

0046<b>]</b> In one embodiment, in order to account for the lack of backchannel bandwidth, accommodations have been made to insure message delivery without a back-channel acknowledgement signal. Central service 200 will preferably continuously transmit all messages for a predetermined period of time even if they have long been received by host devices. This will allow "backfill" of message data that might have been missed in the first transmission but due to lack of acknowledgement, there is now way to know which data is missing. By continually retransmitting for the predetermined period of time, most messages will ultimately be completely delivered without the need to acknowledge. In a sports application, for example, a score will constantly be retransmitted unless/until it has changed. At that point, the revised score will become a part of the carousel broadcast. Content being used by the application will be constantly be rebroadcast using this carousel methodology so that at any given point in time the most current information is available to the user.

0047<b>]</b> In <figref idref="f0010">FIG. 6A</figref>, an exemplary container format or header information 610 for transmitting a data stream for use with the systems and methods described herein, or others, is provided. The messages can be of various lengths, from a few as 9 octets up to 60 octets.

0048<b>]</b> 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 discussed above, this is a number that is set by the transmitter program and sent by the central service 400, and is unique to each event/venue, and/or event/venue/date. Transmitter program, in one embodiment, is a software program running on central service 200 or any local service used at a particular event. Transmitter program (and local service transmitter programs) are responsible for creating all message packets to be broadcast at a particular event. These message packets are then communicated to data server 140 where they are added to the carousel buffer for continuous broadcast by transmitter 150 until changed or removed (e.g., by central service 200 or a local service). Software in the host device 160 saves the VenueID number in memory (e.g., NVRAM), such that it compares the "01" Octet of each message with the VenueID number saved. If the number saved is the same as the number contained in octet "01" of a message, then it can be ignored, and the message should be processed normally, i.e., parsed and saved to memory. If the number contained in octet "01" of a message is different than what has been saved in memory, then all data stored in all the tables will be cleared, and the new number saved. New tables are then created and loaded with the data in subsequent received messages. In one embodiment, using this process, old data that may be stored in a recipient's host device's display is "cleared" when he or she goes to a new event, location, or venue. In another embodiment, an exception is provided when the VenueID=0. In this case, a memory reset is not initiated, and the received message is processed as an "Individual-Address" or message intended for a specific mobile receiver 130. The first six octets of an "Individual-Address" message may be used to indicate the identifying information of a mobile receiver 130, e.g., MAC address or other ID of the intended mobile receiver 130. All other mobile receivers 130 will then ignore this message.

0049<b>]</b> Octet "02" 613 contains a number (C_L) that indicates whether or not the data that follows will be the entire contents of a cell in one of the tables, or whether it is one of a series of messages that will be used to populate the cell. For example, if C_L is a "0", then the data that follows will be the entire contents of the cell. The contents of that message will overwrite the data being currently stored in the cell (if any). If C_L is "1", then the contents of that message will be the first part of what will eventually be a series of characters in that cell. If C_L is "2", then the contents will be appended to the end of what was sent in an earlier message, and so on. In one example, anytime C_L is set at "0" or "1", then all data currently stored in cell is overwritten.

0050<b>]</b> Octet "03" 614 contains a number that indicates 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, etc. The Checksum is not counted in the message length calculation.

0051<b>]</b> Octets "04" 615, "05" 616, and "06" 617 contain the address location for the information contained in octets "07" through "P_L+7". In one example, Octet "04" 615 indicates the table number, Octet "05" 616 indicates the row number, and Octet "06" 617 indicates the column number of a location where the data is to be stored. Since P_L indicates the number of octets being stored in the cell, information contained in octets "07" through "P_L+7" are stored sequentially in the cell specified by Octets "04", "05", and "06".

0052<b>]</b> The last octet (P_L+8) 618 is always the Checksum. This octet is used to validate each message received, but it is not stored in the table.

0053<b>]</b><figref idref="f0010">FIG. 6B</figref> provides 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.

0054<b>]</b> In one embodiment, each packet of a message to be broadcast is a standalone item. The address scheme described above allows for any packet that has been properly received by a mobile receiver 130 to be saved, assembled, and displayed by a paired host device 160 with any other required packets, independent of whether or not other content has yet to be fully transmitted. In other words, if the text portion of an alert message is split between five packets, then as soon as those five packets are received, the message can be displayed on host device 160, even though there may be more packets still being broadcast that belong to, for example, an associated multimedia file like a photo or video. By way of example, as shown in <figref idref="f0005 f0006 f0007 f0008 f0009">FIG. 5</figref>, row 0, column 0 is used to display announcements sent to all recipients 120 at a game. Message packets do not necessarily have to be received by mobile receiver 130 in sequential order, nor do they have to be contiguous.

0055<b>]</b> In one embodiment, the system functions at any baud rate. Time delays between messages have no impact, nor do the packets necessarily need 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.

0056<b>]</b> In one embodiment, the message format is provided for RF broadcasting of multimedia content. In an alternative embodiment, the message format is used to allow for the broadcasting of the same type of content over the entire Internet via UDP. Since individual packets within the data stream can be received in any order, and do not require acknowledgement of receipt, packets can be transmitted over a UDP connection. Allowing for the use of UDP can dramatically increase the speed and reduce the infrastructure requirements of a typical internet server used by someone who is attempting to serve content over the internet to millions of simultaneous recipients 120. Since UDP is a "connectionless" protocol, the data being transmitted over it can be simultaneously received and processed by millions of recipients 120 without having to increase bandwidth at the server, or router capacity based on user demand for the data. Also, since there are no requirements for data receipt acknowledgement, transfer rates will rise dramatically due to reduced network congestion.

0057<b>]</b> In a further embodiment, multimedia messages or digital data may be transmitted to an FM transmitter to recipients 120 having mobile receivers 130 wherein the mobile receivers 130 (whether physically integrated or separate from host device 160) comprise an FM radio chip. Host devices 160 like cellular phones or automobile control panels/car radio or stereos or similar combination radio/navigational systems may contain FM radio chips. Digital data/multimedia information may be segmented and encapsulated using header information as provided above, modulated to be sent over FM, and then broadcast from FM transmitters to the mobile receivers 130 (like the FM tuner and demodulator chip and related modules in a car stereo system, for example) at, for example, 56kb/s. In the case of car stereo mobile receivers 130, each packet can be alternated over the left/right stereo channel. Software application(s) on the host device 160 would receive (or optionally pull) data from the FM chip and decode and re-assemble the segments to render the message. The carrier frequency of such a system is likely country dependent and may be selected by one of ordinary skill.

0058<b>]</b> In a further embodiment, transmitter 150 is constantly transmitting and retransmitting the entire structure of the broadcast data being used by mobile receivers 130 at venue 110. As the broadcast data changes (lap times, weather, scores at a football game, for example), a new message is transmitted that overwrites previously broadcast data in cells such that display 410 on a host device 160 changes to reflect the updated broadcast data. If the broadcast data is being used to provide information to application 170 for display on display 410, then display 410 can be changed immediately, without having to re-transmit the entire dataset used to generate the display originally.

0059<b>]</b> Host device 160 constantly regenerates or refreshes display 410, by monitoring the broadcast data from mobile receiver 130 to host device 160. If any broadcast data is changed by a sequence of messages from transmitter 150, then display 410 is updated as soon as those messages are received at mobile receiver 130, transmitted to host device 160, and processed and displayed by application 170. This may apply broadcast data formatting or display preference information (e.g., screen colors). Any portion of the information shown on display 410 can be changed to indicate an event has occurred (e.g., changing the screen to yellow when a race goes under a caution alert). Exemplary applications 420 may be configured such that any content that a publisher would like to be able to control or change can be found in tables defined at the beginning of the application programming process. These features can include text, pictures, screen layout, equipment of the host device (like the flashlight on a smartphone), or sounds that can be played back over host device 140's speakers. Content and instructions can be transmitted and stored in specific locations in the cells of the tables, and application written to look for the content/instructions in those defined cells.

0060<b>]</b> Thus, even without an acknowledgement signal sent back to transmitter 150 from receiver(s) 130, display 410 on host device 160 should eventually fully populate with the complete intended broadcast data, even if broadcast data is initially missing or lost in transmission.

0061<b>]</b> In one embodiment, broadcast data being transmitted can also include digital instructions that can be used to control devices located at venue 110, as illustrated in <figref idref="f0001">FIG. 1</figref>. This may be particularly useful for devices where not being hard-wired to a larger network is desirable. Because each message being transmitted contains address information specifying which mobile receiver 130 it is intended for, mobile receivers 130 can be built to emit control signals to turn other devices on or off, as well as configure and/or control these devices with digital commands being embedded in the broadcast data. For example, mobile receivers 130 may be operable as controllers for larger screen devices or track lighting (Jumbotron^® devices, for example). At a racetrack, for example, it may be difficult to set up hardwire controllers at each electronic sign. Instead, system 100 could be used to control a large device from a mobile receiver 130 and no controller wiring will be required.

0062<b>]</b> In <figref idref="f0011">FIG. 7</figref>, a method of broadcasting data 700 to a plurality of mobile receivers is shown. In step 701, a central service 200 communicates data including content, e.g., sports scores, event updates, emergency information, multimedia, etc. to a system deployed in a venue 110, for example, via the Internet. The venue 110 is equipped with a data server 140 and a transmitter 150 for broadcasting data wirelessly. In step 702, data from central service 200 is received at data server 140, which is in communication with transmitter 150. In step 703, data server 140 communicates broadcast data to be broadcast to recipients 120 each having a mobile receiver 130 to transmitter 150. In step 704, transmitter 150 transmits broadcast data to mobile receiver(s) 130, which contain at least one transceiver, and are paired with host device(s) 160. In step 705, mobile receiver(s) 130 receive broadcast data and in step 706, transmits broadcast data to host device(s) 160, which are running applications to process and/or display the broadcast data. In step 707, responses from host device(s) 160 are transmitted back to system 100 (if any) via a network available to host device 160, such as a TCP/IP network. In one embodiment, this feature may be used where menu or catalog items are broadcast to recipients 120, and then if a user wants to purchase something from the menu or catalog items, the user selects an item (via application 170), and the purchase request, along with, e.g., payment information, can be relayed back to the store via a TC/PIP network (e.g., cellular or Wi-Fi).

0063<b>]</b> In one embodiment, data server 140 is operable to selectively transmit data received from central service 200. Data authorized for all recipient(s) in a location may be transmitted to transmitter 150 for general broadcast to all mobile receivers 130. Data authorized for only select recipients may be accessible by host device(s) 160 only if the recipient(s) possess or enter, for example, a required code, or, in another embodiment, only to mobile receiver(s) 130 having certain identifying information. In one embodiment, this service may be implemented by either central service 200, or a local service.

0064<b>]</b> In another embodiment, transmitter 150 is constantly broadcasting the entire structure of the data to be communicated to mobile receiver(s) 130 using the carousel methodology. Thus, even without an acknowledgement signal sent from mobile receiver(s) 130, displays on the host device(s) 160 eventually fully populate even if data is initially missing/lost.

0065<b>]</b> Turning to <figref idref="f0012">FIG. 8</figref>, an embodiment of the methods and systems of the invention suitable for application in emergency or disaster situations 900 is provided. Until there is widespread deployment of LTE or other broadcast technology in the U.S., WEA multicast messages containing multimedia content are not available generally in emergency situations. WEA is a public safety system that allows customers who own certain wireless phones and other compatible mobile devices to receive geographically-targeted, text-like messages alerting them of imminent threats to safety in their area. Cell phones are not currently equipped to receive multimedia broadcast messages. One embodiment of the invention provides a system wherein recipient(s) wishing to receive WEA multicast messages are provided with mobile receivers 810, for example, a small, Bluetooth^®-equipped digital receiver used to receive a message transmitted in packets, and then re-transmit the message to a host device 820 (e.g., a mobile phone) using Bluetooth^® protocols. On the host device 820, the message is received and processed by a software application which contains the codec and APIs necessary to compile the message packets back into text, binary commands, or multimedia content, as appropriate.

0066<b>]</b> By way of example, in a hurricane, government authorities (e.g., FEMA) could distribute mobile receivers 810 to emergency personnel or residents of an affected area so that recipients can receive up-to-date information, weather and news alerts, or emergency alerts from government officials, with multimedia information such as maps, videos, photos, etc. Multimedia messages can be broadcast to mobile receivers 810 from a mobile or temporary transmitter deployed in a relevant geography, area, or venue (e.g., shelter). Recipients can download an application ahead of the disaster to their mobile phones or other host devices that can be paired with mobile receivers 810 via any available communications channel, e.g., Bluetooth.

0067<b>]</b><figref idref="f0013">FIGS. 9A</figref> and <figref idref="f0014">9B</figref> provide exemplary information for governmental alert messages transmitted through the systems and methods of the invention. <figref idref="f0013">FIG 9A</figref> is an example of an Emergency Alert message as specified in the Common Alert Protocol, Ver.1.2 document using extensible markup language (XML), which is the universally adopted method for distributing Emergency Alert Messages, both nationally and internationally. <figref idref="f0014">FIG 9B</figref> shows how the information in this XML message could be converted to a table format, compliant with the broadcast format described in this invention.

0068<b>]</b> In this embodiment, transmitter 150 is constantly sending out the entire structure of the data shown, which is stored in tables. As things change (e.g., "urgency" level or "certainty" level, or image file or GIF), a broadcast data message will overwrite the data in the cell where that data was stored. Host device 160 display 410 will change to reflect the updated information.

0069<b>]</b> 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. 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 can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

0070<b>]</b> Turning to <figref idref="f0015">FIG. 10</figref> a flow diagram is provided. At step 1000, host device 160 running application 170 activates a file delivery session for a broadcast service at a venue 101. Host device 160 begins to download content on a defined network address and port associated with a transport session ID of the file delivery session. At step 1001, the host device 160 receives at least one first media segment associated with a digital file broadcast at venue 101. At step 1002, the 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., pictures, audio, and video. At a particular venue, a table is defined to store the digital information required to create the desired digital file, as a series of cells contained in a table. The digital file is divided up into segments (for example, between 20-60 octets each), and then each segment is stored in a different cell within the table. Application 170 running on host device 160 evaluates the contents of received media segments, and combines them in the proper order according to so that the original digital file is accessible or viewable by a user.

0071<b>]</b><figref idref="f0015">FIG. 11</figref> illustrates a conceptual data flow diagram illustrating the data flow between different components in an exemplary apparatus 1100. The apparatus may be a host device 160. The apparatus 1100 includes a broadcast data management module 1101 that is operable to activate a session in a broadcast network at a venue. The apparatus 1100 further includes a broadcast data processing module 1102 that is operable to receive a data stream in the session from a network 1103. The data stream includes at least one encapsulated digital data file segment, wherein the at least one encapsulated digital data file segment is associated with address information. The apparatus 1100 further includes a data caching module 1104 that is operable to cache the at least one encapsulated digital data file segment. The apparatus 1100 further includes a content processing module 1105 that is used to decode multimedia encapsulated digital data file segments for playback while also using the cached encapsulated digital data file segments. The broadcast data processing module 1102 may be further operable to receive additional encapsulated digital data file segments associated with the digital data file. As such, each step in the aforementioned flow chart may be performed by a module and the apparatus 1100 may include one or more of those modules.

0072<b>]</b><figref idref="f0016">FIG. 12</figref> is a diagram illustrating an example of a hardware implementation for an apparatus 1200 employing a processing system 1201. The processing system 11201 may be implemented with a bus architecture. The processing system 1201 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 1201 and the overall design constraints. The processing system 1201 links together various circuits including one or more processors and/or hardware modules, represented by the processor 1202, the modules 1203, 1204, 1205, and 1206, and the computer-readable medium 1207. The processing system 1201 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits known in the art. The processing system 1201 may be coupled to a transceiver 1208. The transceiver 1208 is coupled to one or more antennas 1209. The transceiver 1208 provides a means for communicating with various other apparatus over a transmission medium. The processing system 1201 includes a processor 1202 coupled to a computer-readable medium 1210. The processor 1202 is responsible for general processing, including the execution of software stored on the computer-readable medium 1210. Software, when executed by the processor 1202, causes the processing system 1200 to perform the various functions described above for any particular apparatus. The computer-readable medium 1210 may also be used for storing data that is manipulated by the processor 1202 when executing software. The modules 1203, 1204, 1205, and 1206 may be software modules running in the processor 1202, resident/stored in the computer readable medium 1210, one or more hardware modules coupled to the processor 1202, or some combination thereof. The processing system 1201 may be a component of the host device 160 and/or mobile receiver 130 and may include other memories and processors.

0073<b>]</b> 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. Further, 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.

0074<b>]</b> 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. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more." Unless specifically stated 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 come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase "means for."

0075<b>]</b> Therefore, it is intended that the invention not be limited to the particular embodiments disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims.