Emergency alert signals for satellite systems

Abstract

A notification system for satellite broadcasts is provided, the system comprising a database that is a depository for notification information, an encoder that encodes notification information from the database for satellite broadcasts, and a data linker that associates encoded notification information with at least one packet identifier (PID) for transmission to at least one satellite system transponder. Additionally, a receiver is described that can decode notification information from any multimedia content stream source utilizing a detector, a decoder and a notification information lookup.

Description

RELATED APPLICATIONS

This application claims priority to provisional application entitled “STREAMING DATA PAUSE FUNCTIONS” with Ser. No. 61/070074 filed on Mar. 20, 2008, incorporated herein by reference.

BACKGROUND

Customers of a television satellite system are normally out of touch with the real time alerts in their area. This is especially true if local channels are not supported or people are using pause functions to delay the time when program content is actually watched or watching the previously recorded content on a digital video recorder (DVR). For example, present satellite systems have no means to send alerts from the National Weather Service (NWS), other government agencies, or any other priority message that is important enough to immediately notify the user. Local broadcast systems can do this easily by overlaying warning messages over their actual broadcasts. However, most satellite broadcasting systems are not local and, thus, can not easily determine what weather information is pertinent to different viewers in vastly different geographical areas. Thus, satellite services do not have an emergency notification system that can be automated or supported with a minimal amount of resources.

SUMMARY

Real time emergency alert data is sent immediately to a screen associated, for example, with a satellite system, digital cable, IP (internet protocol) video, FiOS (fiber optic service), or other digital set top box and the like. Applications such as weather alerts, national security alerts, or loss of service notifications can be issued by the service provider and would appear automatically on the screen as a screen warning or as icons instructing which channel to tune to for more information. These can consist of small icons with text, text only, overlays, and/or ticker tape banner and the like on the screen with the content re-formatted for a full screen, full pictures, picture-in-picture streams, audio alerts, and/or all of the above.

In one aspect of the present principles a notification system for satellite broadcasts is provided, the system comprising a database that is a depository for notification information, an encoder that encodes notification information from the database for satellite broadcasts, and a data linker that associates encoded notification information with at least one packet identifier (PID) for transmission to at least one satellite system transponder.

According to another aspect, a method is provided comprising the steps of encoding notification information for satellite broadcasting and associating the encoded notification information with a packet identifier (PID) in a satellite system for transmission to at least one transponder. The method can be further enhanced by collecting notification information in a database at common location prior to encoding.

According to yet another aspect, a method of receiving notification information is provided comprising the steps of receiving notification information from a notification packet identifier (PID) for a media content distribution system, and bypassing local signal control of a local content distribution system device to allow dissemination of the notification information to a viewer.

The above presents a simplified summary of the subject matter in order to provide a basic understanding of some aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of embodiments are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the subject matter can be employed, and the subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features of the subject matter can become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a notification system in accordance with an aspect of an embodiment.

FIG. 2 is a block diagram of a notification receiver in accordance with an aspect of an embodiment.

FIG. 3 is an example of a satellite broadcast system utilizing a notification system in accordance with an aspect of an embodiment.

FIG. 4 is a flow diagram of a method of embedding notification information in a multimedia content stream in accordance with an aspect of an embodiment.

FIG. 5 is a flow diagram of a method of decoding notification information from a multimedia content stream in accordance with an aspect of an embodiment.

DETAILED DESCRIPTION

The subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject matter. It can be evident, however, that subject matter embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the embodiments.

As used in this application, the term “component” is intended to refer to hardware, software, or a combination of hardware and software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, and/or a microchip and the like. By way of illustration, both an application running on a processor and the processor can be a component. One or more components can reside within a process and a component can be localized on one system and/or distributed between two or more systems. Functions of the various components shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software.

When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting instances and embodiments of the invention are intended to encompass both structural and functional equivalents. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

“Notification Information” refers to alerts/notifications typically of an urgent nature such as in an emergency and/or other state where information needs to be timely disseminated to viewers and can include, but is not limited to, text, icons, audible streams, code (e.g., standardized representation code and/or proprietary representation code and the like), instructions (for retrieving information, displaying information and/or for interpreting information and the like), and/or referrals to other information sources, and the like.

Systems and methods described herein show how to implement priority MPEG (motion picture experts group) transport signals and packet identifier (PID) numbers that can flow through a system to the video decoders while all other signals in the system can either be paused or stopped. This feature assures a viewer that when a notification service is enabled; the audio, video, or icons on the screen can report emergency and other information that is local to their needs yet from a national broadcast. This can be accomplished by the resources of, for example, a satellite service provider knowing the zip code of individual set top boxes, access to the internet to access the alert/notification databases such as, for example, NWS, or local channel content. Frequently the closed caption text data contains warning information if local channels are being used, but this is not dependable since the user might not be tuned to these stations during alert conditions.

A central processor collects the warning database at a common location, encode the warning/notification information in a simple standard, and then place the information on select PIDs in, for example, a satellite system and send them up to each transponder. To ensure coverage (but not necessary) every transponder can contain the information since, as a worst case, a user would have access to only one tuner at a time. Some receivers now have a network tuner that only collects guide data. These messages can be inserted in this stream as additional advanced programming guide (APG) data. A low cost method of this system can transmit emergency/alert packets when needed, but this makes verification that the system is working difficult.

A receiver will receive the signals and provide a special watch in software and/or hardware for the emergency/notification PIDs. It is suggested to broadcast the PIDs, for example, every 3 to 60 seconds, so the system knows it is receiving the emergency/notification information even though the information inside a packet might represent a “no alert status.” The frequency of the packets can also be a function of the alert status—higher priority alerts being transmitted at a higher frequency, etc. The user interface can be fully automated by knowing the customer's address to pair it with the location, or it can be private where the user enters zip code information at each receiver (e.g., set top box), and the software extracts the information from the packet based on the zip code.

The basic information containing every zip code and alerts could be contained in a small amount of information. Assume 10 bytes/zip code and 100,000 zip codes for 1 MB of data over a minute or two of time as a worst case. The software searches a reserved/select PID for the zip code information and extracts the alerts. The alerts could point to another audio/video stream or simply enable special characters to be highlighted on the screen or pre-arranged messages displayed. In general, the packets should be in the clear so receivers (e.g., set top boxes) do not have to be authorized to receive the specialty warnings. The system architecture can allow the information to pass through paused, stopped or offline systems (e.g., user watching a digital video disc (DVD) or pre-recorded material rather than a direct broadcast can still receive notifications).

In one instance, a notification receiver monitors incoming packets that are being processed to detect alerts. This allows for oversight of the process in case other environmental factors can have an influence on the notification. For example, if a geographical area is in an alert condition and a rain fade eliminates the notification input, the receiver can post a message that the receiver has lost contact with the transmitter (e.g., satellite, cell phone, cable, Internet, etc.) and the user should, for example, consider moving to a safe spot or turning on a radio to try to receive the latest local emergency information.

FIG. 1 is a block diagram 100 of a notification system 102 having a notification information encoder 106 that encodes notification information from a notification information database 104. The notification information database 104 can be a centralized database or a federated (e.g., linked) database. A centralized database can allow consolidation of similar notification information. Sources for the notification information can include, but are not limited to, weather services, public announcement services, public safety services, defense services, and/or public health services and the like. In one aspect, the notification information database 104 can contain complete notification messages and the like. In another aspect, the notification database 104 can contain standardized messages and/or message codes. For example, the database 104 can contain notification information such as “please tune to your local emergency broadcast station” or simply a code such as “1234” which can represent the “please tune to your local emergency broadcast station” to a notification receiver (described below). Thus, when a standard is adopted, the notification database 104 can easily accommodate the standardization and/or continue to store full length and/or abbreviated messages and the like.

Likewise, the encoder 106 can encode full length messages and/or abbreviate the notifications based on allowable bit counts and the like. The encoder augments the notifications so that they can be more easily transmitted. This can include reducing and/or increasing the number of bits required to encode the notification to properly prepare it for transmission. This can include transforming the notification into other hex, decimal or binary forms as well. After encoding of the notification, a data linker 108 associates the encoded notification with an MPEG packet identifier (PID). A selected PID can be one that is predetermined according to a standard and/or one that has been selected specifically for notifications in a proprietary system and the like. Proper PID selection allows a notification receiver to detect the notification and decode it so that it can be viewed by an end user. Standardization (e.g., setting aside specific PID ranges, etc.) would allow different notification receivers to properly detect PID notification messages. After the data linker 108 associates the proper PID with the encoded notification information, it is available to be sent to a transmitter such as, for example, a satellite transponder and the like.

FIG. 2 is a block diagram 200 of a notification receiver 202 that detects notification information in a multimedia content stream. The notification information received has been previously encoded and associated with a select PID before the notification receiver 202 receives it. The notification receiver 202 does not require the notification information be obtained from a particular type of source. For example, the notification information can be obtained from, but is not limited to, cell phone systems, Internet systems, satellite systems, cable systems and/or fiber optic service (FiOS) and the like. In addition to these types of systems, home gateways can also provide notification information to the notification receiver 202. Home gateways allow multiple types of communication systems to appear as a single system to home users. Thus, the notification receiver 202 can receive notifications from a home gateway as an indirect source from one of the previously stated sources and the like. As long as the notification information is properly encoded and associated with a select PID, the notification receiver can properly detect the notification.

The notification receiver 202 has a notification information detector 204 that receives incoming multimedia content streams and detects notification information. This is typically accomplished by detecting predetermined PIDs that are known to contain notification information. The list of known PIDs can be in a lookup table that can be updated periodically and/or the list of notification PIDs can be transmitted in other messages to the notification receiver. It is also possible that a user can directly program the notification receiver 202 with notification detection PIDs and/or other detection information and the like. Once notification information is detected, a notification information decoder 206 decodes the notification information. In some instances, the detector 204 can require additional security information before allowing a PID to be decoded. This is to prevent unwanted entities surreptitiously using known reserved PIDs to transmit unwanted information such as, for example, advertisements and the like that would hinder and/or interrupt a user's viewing experience and the like. The security information can be stored in the notification receiver 202, entered by a user, and/or transmitted as a separate message. The decoded information can be, but is not limited to, a full text message, an icon, standardized codes, and/or proprietary codes, and the like. Additional information can also be decoded such as, for example, location information (e.g., zip code, state, city, address, etc.) to facilitate in determining if a notification is pertinent to a particular notification receiver. This can be necessary in, for example, national broadcasts that cannot control where the broadcasts are received (e.g., satellite broadcast systems, etc.). For example, all weather notifications can be streamed at once for all areas, but only the geographically correct notifications are displayed to viewers.

A notification information lookup 208 then accepts the notification information and determines if the notification information is pertinent for this particular receiver. For example, the notification information lookup 208 can use optional sources of data such as receiver location information 210 and/or notification message lookup table 212 and the like. The optional receiver location information 210 can be resident in the notification receiver 202 through a factory setting, a transmitted message, and/or through user inputs (e.g., a user enters their zip code, city, state, and/or address, etc.). The optional notification message lookup table 212 can be from a standard and/or a standardized (e.g., proprietary standard) source. Like the receiver location information 210, the notification message lookup table 212 can be received via the factory, a transmitted message and/or via user input and the like. The notification message lookup table 212 can contain, for example, lookup tables that associate notification codes with actual messages, software routines (e.g., routines that can further instruct a video processor, sound processor, or other type of processor, etc.), and/or other types of instructions (e.g., display notification in red letters, trigger audible warnings, etc.). These additional sources can aid the notification information lookup 208 to determine if the notification information should be displayed and/or how the notification information should be displayed and the like. Once this information is determined, the notification information can be displayed to a viewer.

The process described above can be achieved even when a multimedia content delivery device is paused or stopped. The notification receiver 202 is not limited by these features and can process the notification information regardless of their state. For example, if a viewer is using a personal video recorder or watching a DVD, the notifications can still be displayed. Likewise, a use can pause streaming multimedia content and still receive notifications sent through a home gateway, cell phone, and/or landline telephone system and the like, drastically increasing the viewers situational awareness in emergency situations.

FIG. 3 is an example of a satellite broadcast system 300 utilizing a notification system. The main control 302 has access to a centralized database for notifications. The notifications are routed through a switch 304 into encoders 306 where the notifications are encoded and packaged for transmission through satellite dishes 308. A satellite tuner 310 receives the encoded notifications and processes them through filter/data extractors 312. The filter/data extractors 312 act as detectors and decoders to retrieve the notifications. This example is greatly simplified and is included as an illustration to show both transmission and reception concepts.

In view of the exemplary systems shown and described above, methodologies that can be implemented in accordance with the embodiments will be better appreciated with reference to the flow charts of FIGS. 4-5. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the embodiments are not limited by the order of the blocks, as some blocks can, in accordance with an embodiment, occur in different orders and/or concurrently with other blocks from that shown and described herein. Moreover, not all illustrated blocks may be required to implement the methodologies in accordance with the embodiments.

FIG. 4 is a flow diagram of a method 400 of embedding notification information in a multimedia content stream. The method 400 starts 402 by collecting notification information in a database at a common location 404. However, the method 400 is still viable even if the notification information is not stored in a common location. Databases can be linked despite geographical distances and still be considered as a single database and the like. The notification information is then encoded 406 to format the notification information for transmission. As described above, this can be accomplished in many different ways including converting to hex, decimal, binary, and/or ASCII and the like as well as using algorithms and/or also truncating or adding bits to prepare the notification information for transmission. The encoded information is then associated with a packet identifier (PID) for broadcast transmission 408, ending the flow 410. The PID can be a standardized PID and/or proprietary PID that is known to contain notification information. This knowledge allows notification receivers to properly detect which PIDs contain notifications. Additionally, security information can be added before transmission to keep unwanted information from being forced on unsuspecting viewers. If only the PID knowledge is required for decoding information, advertisers and the like could easily transmit advertisements surreptitiously as notification information. Adding additional security information allows the receivers to discard any notification PIDs that do not contain the correct security information, thus eliminating this potential misuse of the notification feature.

FIG. 5 is a flow diagram of a method 500 of decoding notification information from a multimedia content stream. The method 500 starts 502 by detecting notification information from a multimedia content stream 504. This can be accomplished in many ways such as, for example, detecting particular PIDs that are associated with notification information and the like. Some systems can include security information as well that is required to be met before a PID is acceptable. Once detected (and accepted), the detected notification information is decoded 506. The decoded notification information is then optionally associated with a receiver location and/or a notification message 508. As described above, some notifications can be relevant only to particular geographical areas (e.g., weather, etc.). Thus, knowing the receivers location can help to retrieve the correct notification. In some systems the notification information can just be a code and/or abbreviated message. Thus, an optional lookup table can be used to determine the full text message, proper icon, additional instructions, and/or display instructions and the like. The notification information and/or notification message is then displayed to a viewer 510, ending the flow 512. This occurs regardless of the current state of the receiver. The notification is processed even if the receiver is paused or stopped. This advantageously increases the viewer's emergency situational awareness, even while viewing stored content such as with a PVR or DVD and the like. This can include bypassing local signal control of a local content distribution system device to allow dissemination of the notification information to a viewer and the like.

What has been described above includes examples of the embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the embodiments, but one of ordinary skill in the art can recognize that many further combinations and permutations of the embodiments are possible. Accordingly, the subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

Claims

1. A notification system, comprising:

an encoder that encodes notification information for satellite broadcasts; and

a data linker that associates encoded notification information with at least one packet identifier (PID) for transmission to at least one satellite system transponder.

2. The system of claim 1 further including a database for storing notification information.

3. The system of claim 2, wherein the database is in a centralized location.

4. The system of claim 1, wherein the notification information comprises emergency alerts.

5. The system of claim 1, wherein the encoder encodes the notification information according to a notification standard.

6. The system of claim 1, wherein the encoder encodes the notification information based on at least one geographical satellite broadcast region.

7. The system of claim 1, wherein the encoder encodes the notification information based on standardized notification message indicator.

8. The system of claim 1, wherein the at least one packet identifier (PID) is a unique notification PID.

9. A method, comprising the steps of:

encoding notification information for satellite broadcasting; and

associating the encoded notification information with a packet identifier (PID) in a satellite system for transmission to at least one transponder.

10. The method of claim 9 further comprising the step of:

collecting notification information in a database at common location prior to encoding.

11. The method of claim 9 further comprising the step of:

encoding the notification information with a geographical identifier.

12. The method of claim 9 further comprising the step of:

encoding emergency alerts as part of the notification information.

13. The method of claim 9 further comprising the step of:

encoding the notification information according to a notification standard.

14. The method of claim 9 further comprising the step of:

encoding the notification information based on at least one geographical satellite broadcast region.

15. The method of claim 9 further comprising the step of:

encoding the notification information based on a standardized notification message indicator.

16. The method of claim 9 further comprising the step of:

associating the encoded notification information with at least one unique notification PID.

17. A method of receiving notification information, comprising the steps of:

receiving notification information from a notification packet identifier (PID) for a media content distribution system; and

bypassing local signal control of a local content distribution system device to allow dissemination of the notification information to a viewer.

18. The method of claim 17 further comprising the step of:

verifying that the notification information is associated with a recipient device before allowing the bypassing of the local signal control.

19. The method of claim 18 further comprising the step of:

determining association with a recipient device of the notification information based on geographical indicators encoded into the packet identifier and location of the recipient device.

20. The method of claim 17 further comprising the steps of:

associating the notification information with a notification message stored in the recipient device; and

displaying the stored notification message to the viewer without regard to the operational state of the recipient device.