WO2015095567A1 - Dynamic guide for video broadcasts and streams - Google Patents

Abstract

Systems and methods provide for distributing updates to breaking events. A method for transmitting alerts to a display regarding a time relevant event includes: aggregating program information from a plurality of different service providers, wherein the information is associated with planned content broadcasts; receiving an addition or a change to the aggregated information, wherein the addition or the change is associated with the time relevant event; determining the relevance of the time relevant event to a user; transmitting an alert to a device which the user currently has active; and displaying the alert as an overlay.

Description

DYNAMIC GUIDE FOR VIDEO BROADCASTS AND STREAMS

RELATED APPLICATIONS

[0001] The present invention is related to, and claims priority from, the U.S.

Provisional Patent Application serial number 61/918,021, entitled "Dynamic Guide for Video Broadcasts and Streams", filed on December 19, 2013 and the disclosure of which is incorporated herein by reference.

BACKGROUND

[0002] Technologies associated with the communication of information have evolved rapidly over the last several decades. Television, cellular telephony, the Internet and optical communication techniques (to name just a few things) combine to inundate consumers with available information and entertainment options. Taking television as an example, the last three decades have seen the introduction of cable television service, satellite television service, pay-per-view movies and video-on-demand. Whereas television viewers of the 1960s could typically receive perhaps four or five over-the-air TV channels on their television sets, today's TV watchers have the opportunity to select from hundreds, thousands, and potentially millions of channels of shows and information. Video-on-demand

technology, currently used primarily in hotels and the like, provides the potential for in-home entertainment selection from among thousands of movie titles.

[0003] The technological ability to provide so much information and content to end users provides both opportunities and challenges to system designers and service providers. One challenge is that while end users typically prefer having more choices rather than fewer, this preference is counterweighted by their desire that the selection process be both fast and simple. Unfortunately, the development of the systems and interfaces by which end users access media items has resulted in selection processes which are neither fast nor simple. Consider again the example of television programs. When television was in its infancy, determining which program to watch was a relatively simple process primarily due to the small number of choices. One would consult a printed guide which was formatted, for example, as series of columns and rows which showed the correspondence between (1) nearby television channels, (2) programs being transmitted on those channels and (3) date and time. The television was tuned to the desired channel by adjusting a tuner knob and the viewer watched the selected program. Later, remote control devices were introduced that permitted viewers to tune the television from a distance. This addition to the user-television interface created the phenomenon known as "channel surfing" whereby a viewer could rapidly view short segments being broadcast on a number of channels to quickly learn what programs were available at any given time.

[0004] Despite the fact that the number of channels and amount of viewable content has dramatically increased, the generally available user interface, control device options and frameworks for televisions has not changed much over the last 30 years. Printed guides are still the most prevalent mechanism for conveying programming information. The multiple button remote control with up and down arrows is still the most prevalent channel/content selection mechanism. The reaction of those who design and implement the TV user interface to the increase in available media content has been a straightforward extension of the existing selection procedures and interface objects. Thus, the number of rows in the printed guides has been increased to accommodate more channels. The number of buttons on the remote control devices has been increased to support additional functionality and content handling, e.g., as shown in Figure 1. However, this approach has significantly increased both the time required for a viewer to review the available information and the complexity of actions required to implement a selection. Arguably, the cumbersome nature of the existing interface has hampered commercial implementation of some services, e.g., video-on-demand, since consumers are resistant to new services that will add complexity to an interface that they view as already too slow and complex.

[0005] In addition to increases in bandwidth and content, the user interface bottleneck problem is being exacerbated by the aggregation of technologies. Consumers are reacting positively to having the option of buying integrated systems rather than a number of segregable components. An example of this trend is the combination television/VCR/DVD in which three previously independent components are frequently sold today as an integrated unit. This trend is likely to continue, potentially with an end result that most if not all of the communication devices currently found in the household will be packaged together as an integrated unit, e.g., a television/VCR/DVD/internet access/radio/stereo unit. Even those who continue to buy separate components will likely desire seamless control of, and interworking between, the separate components. With this increased aggregation comes the potential for more complexity in the user interface. For example, when so-called "universal" remote units were introduced, e.g., to combine the functionality of TV remote units and VCR remote units, the number of buttons on these universal remote units was typically more than the number of buttons on either the TV remote unit or VCR remote unit individually. This added number of buttons and functionality makes it very difficult to control anything but the simplest aspects of a TV or VCR without hunting for exactly the right button on the remote. Many times, these universal remotes do not provide enough buttons to access many levels of control or features unique to certain TVs. In these cases, the original device remote unit is still needed, and the original hassle of handling multiple remotes remains due to user interface issues arising from the complexity of aggregation. Some remote units have addressed this problem by adding "soft" buttons that can be programmed with the expert commands. These soft buttons sometimes have accompanying LCD displays to indicate their action. These too have the flaw that they are difficult to use without looking away from the TV to the remote control. Yet another flaw in these remote units is the use of modes in an attempt to reduce the number of buttons. In these "moded" universal remote units, a special button exists to select whether the remote should communicate with the TV, DVD player, cable set-top box, VCR, etc. This causes many usability issues including sending commands to the wrong device, forcing the user to look at the remote to make sure that it is in the right mode, and it does not provide any simplification to the integration of multiple devices. The most advanced of these universal remote units provide some integration by allowing the user to program sequences of commands to multiple devices into the remote. This is such a difficult task that many users hire professional installers to program their universal remote units.

[0006] Some attempts have also been made to modernize the screen interface between end users and media systems. However, these attempts typically suffer from, among other drawbacks, an inability to easily scale between large collections of media items and small collections of media items. For example, interfaces which rely on lists of items may work well for small collections of media items, but are tedious to browse for large collections of media items. Interfaces which rely on hierarchical navigation (e.g., tree structures) may be speedier to traverse than list interfaces for large collections of media items, but are not readily adaptable to small collections of media items. Additionally, users tend to lose interest in selection processes wherein the user has to move through three or more layers in a tree structure. For all of these cases, current remote units make this selection process even more tedious by forcing the user to repeatedly depress the up and down buttons to navigate the list or hierarchies. When selection skipping controls are available such as page up and page down, the user usually has to look at the remote to find these special buttons or be trained to know that they even exist. Accordingly, organizing frameworks, techniques and systems which simplify the control and screen interface between users and media systems as well as accelerate the selection process, while at the same time permitting service providers to take advantage of the increases in available bandwidth to end user equipment by facilitating the supply of a large number of media items and new services to the user have been proposed in U.S. Patent Application Serial No. 10/768,432, filed on January 30, 2004, entitled "A Control Framework with a Zoomable Graphical User Interface for Organizing, Selecting and

Launching Media Items", the disclosure of which is incorporated here by reference.

[0007] However, many genres of video which are currently distributed do not work well with the various traditional types of guides. For example, consider news, sports, weather and other types of dynamic information shows. In many cases, the only information a traditional guide contains is the name of the program such as "News Night" or the

participants in a sports match. However, when events are happening in real time the current guide approach has no means of addressing this dynamic content, e.g., what news is currently being covered in News Night.

[0008] One method which currently allows viewers to occasionally see information associated with a new or breaking sports event can be seen when subscribing to a service such as ESPN Sportscenter. For example, with this type of service, by identifying their favorite teams, the user may get certain breaking sports events to pop upon on a device, e.g., their tablet or smart phone. However, it would then be up to the viewer to keep their device with them and find the appropriate channel. Limitations with this method include a lack of providing a head-up on screen display and that it cannot be tied to the user's viewing.

[0009] There are other challenges associated with keeping viewers informed of events. For example, for certain types of news stories a series of press conferences can often occur with a short lead time. The announcement regarding such a press conference may be available on a website associated with the news channels, but is often only disseminated verbally on the news channel or by putting promotional tags at the bottom of the screen which are seen only by those watching the broadcast. This greatly reduces the possibility of keeping tabs on the event without constantly remaining on the specific network channel.

[0010] Additionally, human nature can also play a part in how people keep abreast of events or do not keep abreast of events. For example, at first thought having a viewer continue watching a particular network would seem to be a behavior that a network would want to reinforce. However, the natural human inertial tendency to remain where they are can also work against the network. Once a person has changed the channel to watch other programming, they are less like to check back in to a previous channel. Therefore, the viewer may not become aware of something happening that is a breaking event until much later in time.

[0011] Another issue with guides used today, is that most guide data is submitted to guide services well in advance of the programming date. Breaking events may cause some scheduling data to be updated and distributed in the short term, but the update timeframe is usually measured in hours, not minutes, in the event of a program change. [0012] Accordingly, it would be desirable to provide systems and method which address the above mentioned drawbacks and limitations.

SUMMARY

[0013] According to one embodiment there is a method for transmitting alerts to a display regarding a time relevant event, the method includes: receiving, at a communication interface, program information from a plurality of different programming networks;

aggregating the program information into a framework; storing, in a memory, instructions for transmitting information to a device; editing the program information; receiving, at the communication interface, an update from a programming network about a time relevant event; determining, based on stored instructions and the update, by a processor whether to transmit information to the device, wherein the information is associated with the update about the time relevant event; transmitting, by the communication interface, the information to the device based on the step of determining whether to transmit the information to the device; and displaying the information as an overlay on the device.

[0014] According to an embodiment there is a method for transmitting alerts to a display regarding a time relevant event, the method includes: aggregating program

information from a plurality of different service providers, wherein the information is associated with planned content broadcasts; receiving an addition or a change to the aggregated information, wherein the addition or the change is associated with the time relevant event; determining the relevance of the time relevant event to a user; transmitting an alert to a device which the user currently has active; and displaying the alert as an overlay.

[0015] According to another embodiment, there is a system for transmitting alerts to a display regarding a time relevant event, the system includes: a processor configured to aggregate program information from a plurality of different service providers, wherein the information is associated with planned content broadcasts; a communication interface configured to receive an addition or a change to the aggregated information, wherein the addition or the change is associated with the time relevant event; the processor configured to determine the relevance of the time relevant event to a user; the communication interface configured to transmit an alert to a device which the user currently has active; and a display configured to display the alert as an overlay.

[0016] According to another embodiment, there is a method for aggregating program information from different programming networks, the method includes: receiving program information from a plurality of different programming networks; aggregating the program information into a framework; storing instructions for transmitting information to a device; receiving an update from a programming network about a time relevant event; determining, based on stored instructions and the update, whether to transmit information to the device; and transmitting the information to the device based on the step of determining whether to transmit the information to the device.

[0017] According to another embodiment, there is a device configured to aggregate program information from different programming networks, the device comprising: a communication interface configured to receive program information from a plurality of different programming networks; a processor configured to aggregate the program information into a framework; a memory configured to store instructions for transmitting information to a device; the communication interface configured to receive an update from a programming network about a time relevant event; the processor configured to determine, based on stored instructions and the update, whether to transmit information to the device; and the communication interface configured to transmit the information to the device based on the step of determining whether to transmit the information to the device. [0018] According to another embodiment, there is a method for transmitting a message associated with a time relevant event by a content producer, the method comprising: receiving information including metadata associated with the time relevant event directly from the content producer's network at a dynamic guide service; determining, by the dynamic guide service, which users to send the message associated with the time relevant event;

transmitting the message to a device of at least one user based on the step of determining; and displaying at least a portion of the content of the message on the device.

[0019] According to another embodiment, there is a system for transmitting a message associated with a time relevant event by a content producer, the system comprising: a communication interface of a dynamic guide service configured to receive information including metadata associated with the time relevant event directly from the content producer's network; a processor of the dynamic guide service configured to determine which users to send the message associated with the time relevant event; the communication interface configured to transmit the message to a device of at least one user based on the step of determining; and a display configured to display at least a portion of the content of the message on the device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings illustrate exemplary embodiments of the present invention, wherein:

[0021] FIG. 1 depicts a conventional remote control unit for an entertainment system;

[0022] FIG. 2 depicts a media system in which embodiments can be implemented;

[0023] FIG. 3(a) shows a 3D pointing device with which embodiments can be implemented;

[0024] FIG. 3(b) illustrates a user employing a 3D pointing device to provide input to a user interface on a television according to an embodiment;

[0025] FIG. 4 shows a LiveGuide alert on a display according to an embodiment;

[0026] FIG. 5 depicts an architecture in which LiveGuide can be used according to an embodiment;

[0027] FIG. 6 is a flow chart showing a use example for LiveGuide according to an embodiment;

[0028] FIG. 7 is a flow chart of a method according to an embodiment;

[0029] FIG. 8(a) is a flow chart of another method according to an embodiment;

[0030] FIG. 8(b) is a flow chart of another method according to an embodiment; and

[0031] FIG. 9 depicts a device according to an embodiment. DETAILED DESCRIPTION

[0032] The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.

[0033] Embodiments provide a service, a so-called "LiveGuide" service that ties directly into the scheduling system of broadcast and streaming video networks to provide dynamic, real-time guide data. This data can be presented to the viewer in various ways. For example, the data can be presented by a LiveGuide application, a third party application that uses the LiveGuide API, or in other manners as desired by a network operator to which a user is subscribed to receive the data. Embodiments which use LiveGuide can provide the data in real-time via both push and pull mechanisms.

[0034] Prior to discussing such embodiments in detail, and in order to provide some context for this discussion, an exemplary aggregated media system 200 in which the present invention can be implemented will first be described with respect to Figure 2. Those skilled in the art will appreciate, however, that the present invention is not restricted to

implementation in this type of media system and that more or fewer components can be included therein. Therein, an input/output (I/O) bus 210 connects the system components in the media system 200 together. The I/O bus 210 represents any of a number of different of mechanisms and techniques for routing signals between the media system components. For example, the I/O bus 210 may include an appropriate number of independent audio "patch" cables that route audio signals, coaxial cables that route video signals, two-wire serial lines or infrared or radio frequency transceivers that route control signals, optical fiber or any other routing mechanisms that route other types of signals.

[0035] In this exemplary embodiment, the media system 200 includes a

television/monitor 212, a video cassette recorder (VCR) 214, digital video disk (DVD) recorder/playback device 216, audio/video tuner 218 and compact disk player 220 coupled to the I/O bus 210. The VCR 214, DVD 216 and compact disk player 220 may be single disk or single cassette devices, or alternatively may be multiple disk or multiple cassette devices. They may be independent units or integrated together. In addition, the media system 200 includes a microphone/speaker system 222, video camera 224 and a wireless I/O control device 226. According to exemplary embodiments of the present invention, the wireless I/O control device 226 is a 3D pointing device. The wireless I/O control device 226 can communicate with the entertainment system 200 using, e.g., an IR or RF transmitter or transceiver. Alternatively, the I/O control device can be connected to the entertainment system 200 via a wire. One or more hard drives (or disks or flash drives) 280 can be provided for storage of recorded video, music or other media.

[0036] The entertainment system 200 also includes a system controller 228.

According to one exemplary embodiment of the present invention, the system controller 228 operates to store and display entertainment system data available from a plurality of entertainment system data sources and to control a wide variety of features associated with each of the system components. As shown in Figure 2, system controller 228 is coupled, either directly or indirectly, to each of the system components, as necessary, through I/O bus 210. In one exemplary embodiment, in addition to or in place of I/O bus 210, system controller 228 is configured with a wireless communication transmitter (or transceiver), which is capable of communicating with the system components via IR signals or RF signals. Regardless of the control medium, the system controller 228 is configured to control the media components of the media system 200 via a graphical user interface described below.

[0037] As further illustrated in Figure 2, media system 200 may be configured to receive media items from various media sources and service providers. In this exemplary embodiment, media system 200 receives media input from and, optionally, sends information to, any or all of the following sources: cable broadcast 230, satellite broadcast 232 (e.g., via a satellite dish), very high frequency (VHF) or ultra high frequency (UHF) radio frequency communication of the broadcast television networks 234 (e.g., via an aerial antenna), telephone network 236 and cable modem 238 (or another source of Internet content). Those skilled in the art will appreciate that the media components and media sources illustrated and described with respect to Figure 2 are purely exemplary and that media system 200 may include more or fewer of both. For example, other types of inputs to the system include AM/FM radio and satellite radio.

[0038] More details regarding this exemplary entertainment system and frameworks associated therewith can be found in the above-incorporated by reference U.S. Patent Application entitled "A Control Framework with a Zoomable Graphical User Interface for Organizing, Selecting and Launching Media Items". Additionally, the interested reader is also referred to U.S. Patent Application Serial No.11/437,215, entitled "Global Navigation Objects in User Interfaces", filed on May 19, 2006, the disclosure of which is incorporated here by reference. Alternatively, remote devices and interaction techniques between remote devices and user interfaces in accordance with the present invention can be used in conjunction with other types of systems, for example computer systems including, e.g., a display, a processor and a memory system or with various other systems and applications.

[0039] The present invention is not limited to systems including 3D pointers and may be used with 2D devices or remote control devices such as that illustrated in Figure 1.

However 3D pointing devices enable the translation of movement of the device, e.g., linear movement, rotational movement, acceleration or any combination thereof, into commands to a user interface. An exemplary loop-shaped, 3D pointing device 300 is depicted in Figure 3(a), however the present invention is not limited to loop-shaped devices. In this exemplary embodiment, the 3D pointing device 300 includes two buttons 302 and 304 as well as a scroll wheel 306 (scroll wheel 306 can also act as a button by depressing the scroll wheel 306), although other exemplary embodiments will include other physical configurations. User movement of the 3D pointing device 300 can be defined, for example, in terms of rotation about one or more of an x-axis attitude (roll), a y-axis elevation (pitch) or a z-axis heading (yaw). In addition, some exemplary embodiments of the present invention can additionally (or alternatively) measure linear movement of the 3D pointing device 300 along the x, y, and/or z axes to generate cursor movement or other user interface commands. An example is provided below. A number of permutations and variations relating to 3D pointing devices can be implemented in systems according to exemplary embodiments of the present invention. The interested reader is referred to U.S. Patent Application Serial No. 1 1/119,663, entitled (as amended) "3D Pointing Devices and Methods", filed on May 2, 2005, U.S. Patent Application Serial No. 11/119,719, entitled (as amended) "3D Pointing Devices with Tilt Compensation and Improved Usability", also filed on May 2, 2005, U.S. Patent Application Serial No. 11/119,987, entitled (as amended) "Methods and Devices for Removing Unintentional Movement in 3D Pointing Devices", also filed on May 2, 2005, U.S. Patent Application Serial No. 11/119,688, entitled "Methods and Devices for Identifying Users Based on Tremor", also filed on May 2, 2005, and U.S. Patent Application Serial No.

11/480,662, entitled "3D Pointing Devices", filed on July 3, 2006, the disclosures of which are incorporated here by reference, for more details regarding exemplary 3D pointing devices which can be used in conjunction with exemplary embodiments of the present invention.

[0040] It is anticipated that 3D pointing devices 300 will be held by a user in front of a display 308 and that motion of the 3D pointing device 300 will be translated by the 3D pointing device into output which is usable to interact with the information displayed on display 308, e.g., to move the cursor 310 on the display 308. For example, such 3D pointing devices and their associated user interfaces can be used to make media selections on a television as shown in Figure 3(b), which will be described in more detail below. Aspects of exemplary embodiments of the present invention can be optimized to enhance the user's experience of the so-called "10-foot" interface, i.e., a typical distance between a user and his or her television in a living room. For example, interactions between pointing, scrolling, zooming and panning, e.g., using a 3D pointing device and associated user interface, can be optimized for this environment as will be described below, although the present invention is not limited thereto.

[0041] Referring again to Figure 3(a), an exemplary relationship between movement of the 3D pointing device 300 and corresponding cursor movement on a user interface will now be described. Rotation of the 3D pointing device 300 about the y-axis can be sensed by the 3D pointing device 300 and translated into an output usable by the system to move cursor 310 along the y₂ axis of the display 308. Likewise, rotation of the 3D pointing device 308 about the z-axis can be sensed by the 3D pointing device 300 and translated into an output usable by the system to move cursor 310 along the x₂ axis of the display 308. It will be appreciated that the output of 3D pointing device 300 can be used to interact with the display 308 in a number of ways other than (or in addition to) cursor movement, for example it can control cursor fading, volume or media transport (play, pause, fast-forward and rewind). Additionally, the system can be programmed to recognize gestures, e.g., predetermined movement patterns, to convey commands in addition to cursor movement. Moreover, other input commands, e.g., a zoom-in or zoom-out on a particular region of a display (e.g., actuated by pressing button 302 to zoom-in or button 304 to zoom-out), may also be available to the user.

[0042] According to exemplary embodiments of the present invention, user interfaces may use, at least in part, zooming techniques for moving between user interface views. The zooming transition effect can be performed by progressive scaling and displaying of at least some of the UI objects displayed on the current UI view to provide a visual impression of movement of those UI objects away from an observer. In another functional aspect of the present invention, user interfaces may zoom-in in response to user interaction with the user interface which will, likewise, result in the progressive scaling and display of UI objects that provide the visual impression of movement toward an observer. More information relating to zoomable user interfaces can be found in U.S. Patent Application Serial No. 10/768,432, filed on January 30, 2004, entitled "A Control Framework with a Zoomable Graphical User Interface for Organizing, Selecting and Launching Media Items", and U.S. Patent Application Serial No. 09/829,263, filed on April 9, 2001, entitled "Interactive Content Guide for Television Programming", the disclosures of which are incorporated here by reference. [0043] Movement within the user interface between different user interface views is not limited to zooming. Other non-zooming techniques can be used, in addition to zooming or as an alternative thereto, to transition between user interface views. For example, panning can be performed by progressive translation and display of at least some of the user interface objects which are currently displayed in a user interface view. This provides the visual impression of lateral movement of those user interface objects to an observer.

[0044] Returning now to the application illustrated in Figure 3(b), the GUI screen

(also referred to herein as a "UI view", which terms refer to a currently displayed set of UI objects) seen on television 320 is a home view. In this particular exemplary embodiment, the home view displays a plurality of applications 322, e.g., "Photos", "Music", "Recorded", "Guide", "Live TV", "On Demand", and "Settings", which are selectable by the user by way of interaction with the user interface via the 3D pointing device 300. Such user interactions can include, for example, pointing, scrolling, clicking or various combinations thereof. For more details regarding exemplary pointing, scrolling and clicking interactions which can be used in conjunction with exemplary embodiments of the present invention, the interested reader is directed to U.S. Patent Application Serial No. 11/417,764, entitled "METHODS AND SYSTEMS FOR SCROLLING AND POINTING IN USER INTERFACE", to Frank J. Wroblewski, filed on May 4, 2006, the disclosure of which is incorporated here by reference.

LiveGuide

[0045] As described above, LiveGuide is a dynamic guide service that ties directly into the scheduling system of broadcast and streaming video networks, as well as other service providers, to collect and to provide dynamic, real-time guide data. Prior to describing LiveGuide in more detail, two scenarios in which LiveGuide can be used will first be described.

[0046] According to a first scenario, which uses one or more embodiments associated with LiveGuide (described in more detail below), there is a breaking news event happening. Moving forward in time, the breaking news event has reached a period of inactivity with only sporadic updates which has led people to stop watching the news channels which were reporting the event and instead people have turned to other programming to watch. These people are expected to check back in once in a while for updates regarding the breaking news event.

[0047] According to an embodiment, the LiveGuide service is directly tied into the news channel's scheduling system that is necessary to operate the news program. Reporters, camera operators, satellite service, anchor cues all have to be synchronized when dealing with a live event. To perform this synchronization, there is an internal scheduling system operated by the network which manages this information. Continuing the example, regarding the breaking news event, suppose that a news network adds to their internal schedule that at 11 :40 am, the local Sheriff will be holding a press conference and the news network resources need to be in place and ready.

[0048] Once the news network makes this addition to their internal schedule, the

LiveGuide service picks up the addition and transmits the information to a data center, e.g., a communication node, where the addition is then sent to all LiveGuide enabled devices. As a result, these devices can make that data available to people who are watching. For example, a LiveGuide enabled connected TV can have a pop-up appear on the bottom of the screen informing the viewer that the press conference will begin in eight minutes and asking the viewer whether they would like to immediately tune to that channel, tune to that channel automatically in eight minutes, or to ignore the option. The viewer can then indicate their desired action.

[0049] For a second scenario, consider a sports event which can be a very dynamic situation. Shows such as the NFL RedZone have shown that viewers enjoy jumping to games when something is happening, e.g., a score change. However, the viewer only has that option if they watch NFL RedZone, so if their favorite team is playing at the moment, the viewer would be more likely inclined to choose to watch their favorite team and miss out on the dramatic events happening in other sporting events.

[0050] Using LiveGuide in this second scenario, the LiveGuide service could transmit information such as a field goal is about to be attempted with two seconds left on the clock in a game. A LiveGuide enabled device would make this information available to the viewer. The viewer could then choose to quickly tune to the other game to watch the attempt and then return, or be returned, to the primary game that they were watching.

[0051] According to an embodiment, an example of a LiveGuide alert or message which is displayed showing desired information is shown in Figure 4. Figure 4 includes an active TV display 402, and a LiveGuide alert 404. In this example, the LiveGuide alert 404 includes a channel logo 406, information including time 408 of the event 410 described in the alert and a plurality of options 412 for the viewer to select however, more or fewer items can appear in the LiveGuide alert 404 as desired. These options 412 include the following: (1) Go to Channel Now; (2) Go to Channel at Time; and (3) Ignore. While only three options are shown in Figure 4, it is to be understood that more or fewer viewer options can be used as desired. Additionally, other information can be shown, e.g., related information, paid subscription information and the like. [0052] According to an embodiment, the LiveGuide service can be composed of a series of parts that integrate with the existing broadcast infrastructure. An example of the components associated with the LiveGuide service can include some or all of, but are not limited to, networks, network switching centers, database(s), editorial service and devices which can support LiveGuide. An example of an infrastructure associated with a LiveGuide embodiment is shown in Figure 5. The LiveGuide architecture 500 can include one or more network switching centers 502, 504, 506, 508, a LiveGuide database 510 which may be a cloud based dynamic database, a LiveGuide editorial service 512, and a plurality of platforms for deploying the LiveGuide on or through (smart TVs 514, set-top boxes (STBs) 516, streaming devices 518, mobile devices 520 and the general web browsers/PC plugins which use the Internet 522).

[0053] Broadcast networks, in general, operate using very specific timing. For example, if a press conference is going live at a certain time, the technical people involved, e.g., camera, audio, satellite unit, etc., all need to be aware of when the press conference is going to happen. Location talent also needs to be prepared. Additionally, the main switching center of the network needs to be aware of the schedule and the on-air talent in the studio will need to have the information to lead in to the remote segment. Keeping all of these different pieces, which are typically located in many different locations, synchronized is a part of the centralized operation at the network. To support this, computer software can be integrated with the scheduling/managing operations and can transmit the upcoming scheduling information as soon as it changes or is updated. This software can be automated and connected directly to the scheduling system, or the data can be entered manually.

[0054] According to an embodiment, the LiveGuide cloud based dynamic database 510 is a so-called "always synchronized" guide. In other words, as the scheduling

information is received by the LiveGuide database it is cataloged and integrated into the LiveGuide database. Errors can be identified and corrected automatically by

programs/applications associated with the dynamic database 510. The LiveGuide cloud based dynamic database 510 can be aggregated and consolidated with LiveGuide scheduling data coming in from other connected networks.

[0055] According to an embodiment, the LiveGuide editorial service 512 is an optional stage/service component of the system. The LiveGuide editorial service 512 is the stage of the LiveGuide process where consolidated data can be reviewed directly by a person. Additionally metadata can be added or redundancies not caught by the computer algorithms used by the LiveGuide database 510 can be corrected in this stage. The LiveGuide editorial service 512 can also provide a "dummy check" to uncover computer errors in the data. Paid promotional and/or marking LiveGuide updates can be added to the output from the

LiveGuide editorial service 512.

[0056] According to an embodiment, devices, e.g., smart TVs 514, STBs 516, streaming devices 518, mobile devices 520 and/or general web browsers/PC plugins 522, that are LiveGuide enabled can receive push (or pull) notifications of the schedule updates. These push notifications can include times, descriptions, sources and the like. In other words, these push notification can include all of the information necessary to provide the receiving device with the ability to access the broadcast/stream if it is available to them. According to an embodiment the LiveGuide service can provide the basic implemented applications for use on a device. Alternatively and/or additionally, the LiveGuide service can provide an Application Program Interface (API) that provides third party developers access to both push and pull data for use in other applications.

[0057] According to an embodiment, a LiveGuide application can know and/or learn a viewer's interests as well as viewing habits. For example, LiveGuide can track what someone is viewing, use a viewer's recording history, and store information associated with what a user subscribes to, e.g., breaking news, weather updates, and information associated with favorite sports teams. Additionally, according to an embodiment, LiveGuide can perform trending to identify items of general interest to users.

[0058] According to an embodiment, a LiveGuide application can prioritize the display of data which is presented to users. This displayed data can be different for each user or have some commonality between users. For example, the viewer can identify favorite channels for viewing news so that when a breaking news event is available on multiple news channels, that favorite appears first or at the top of the displayed list. Alternatively, the LiveGuide application can use behaviors, such as the news channel that is most often viewed, to prioritize if no specific favorite is identified. According to another embodiment, channels or other service providers can pay to promote themselves and their offerings to increase their priority status as compared to other viewing options.

[0059] According to an embodiment, LiveGuide can link to traditional guides associated with services, e.g., a conventional cable channel guide or grid portion of the guide. The LiveGuide can integrate with an item, e.g., a TV show, listed in the grid by providing additional information. A person can select any show in the guide and see a description of the episode and, for programs that have LiveGuide data, additional information can be added to the description. For example, suppose that a viewer was watching a weather show, with a LiveGuide enabled-device additional information could be provided associated with upcoming events in the guide and/or as some form of an overlay information, e.g., associated with an upcoming live report such as a 9: 12 live update about a hurricane from Miami. According to another embodiment, LiveGuide data could also pre-empt the guide entirely as LiveGuide may change the current show "Newstime Tonight" to "Live Coverage of the Crisis in Brazil" based on, for example, LiveGuide prioritization schemes as described herein.

[0060] According to an embodiment, multiple broadcast networks can be integrated with LiveGuide as well as numerous service providers, e.g., cable companies, Internet feeds, satellite providers and FIOS. A similar amount of integration can be used for each content provider, or the integration can be tailored for each network and/or service provider.

[0061] According to an embodiment, LiveGuide can include search abilities based on data associated with LiveGuide which is stored in a database. Search options can include trending topics and or categories, with results being displayed on the viewer's device.

Alternatively, LiveGuide can perform an expanded search. Expanded search in this context describes expanding the scope of the search to potentially related items which are beyond the specifically entered search terms. For example, if a viewer is a fan of the show "Big Bang Theory", as known by LiveGuide, a search request entered by the viewer for "What's on next" could return information associated with the show and/or stars of the show, e.g., the search of "What's on next" could return information that the show's star, Jim Parsons, is the guest on the show "The View" at 11 :35 am even though the viewer did not enter any specific information about this topic. Additionally, the search may also return information literally associated with "What's on next".

[0062] Now that various operating scenarios for what LiveGuide can deliver have been described, an overview of how LiveGuide can operate to deliver its services will now be described. According to an embodiment, as described above, LiveGuide can use already existing scheduling of a network broadcast or stream to create an "up-to-the-minute" guide. Once the data is collected, automatically or manually, the LiveGuide service can associate that data with specific times/networks/shows/locations to provide the information in a personalized form for the viewer based, for example, upon what channels/streams are available to the viewer and/or how the viewer is accessing them. According to an

embodiment, this personalized form can also be influenced by user inputs, learned user preferences over time, and paid prioritization by service providers.

[0063] According to an embodiment, the editorial component of LiveGuide can process accumulated data through another level of assessment where more unusual or critical information factors can be human interpreted, associated and integrated with the

automatically generated data. By offering this optional human interpretation and its integration into the system, LiveGuide can interpret the unexpected or unplanned items that the computer algorithm(s) used by LiveGuide might not be able to handle as effectively.

[0064] According to an embodiment, the LiveGuide service can be adapted so that it is available through any Internet Protocol (IP) connection using most any mobile device or device capable of operating a web browser. This allows for almost immediate access to the services provided by LiveGuide, in most cases, for the user. LiveGuide can also support a multitude of display option for the presentation of data for the user. This allows a user/viewer to decide how the user wishes to communicate with the LiveGuide outputs. This can also create a sense of urgency around the data that is useful to the content provider and in some cases encouraging the user to take action(s) where appropriate. [0065] According to an embodiment, LiveGuide can support non-guide paid or unpaid communications transmitted through the service to LiveGuide enabled devices. These communications can include public service announcements (PSAs), promotions,

sponsorships, advertisements, enticements, non-TV events, etc. According to an

embodiment, these communications can be tied to the type or to a specific show currently being watched for the cases where the LiveGuide enable device supports providing that type of information. Additionally, these communications can be initiated by anyone via the LiveGuide service.

[0066] According to an embodiment, the LiveGuide service API can include methods for returning usage or other user action data back to the service for purposes of tracking, determining value, and other analytics associated with the information provided by the service. According to an embodiment, the user may need to "opt-in" to any such user tracking. Additionally, this tracking could be made anonymous such that the service could identify the client device so that target guide alerts/events could be sent to a device without specific user identification, e.g., by identifying with a unique identifier of the device such as the media access control (MAC) address.

[0067] According to another embodiment, a method by which the update information initially enters the LiveGuide system is independent from the system itself. For example, as long as the data is packaged appropriately and delivered, than the method by which the packaging occurred is considered to be agnostic from the overall function. As a result, data could be entered manually by the producer of a show instead of being directly tied-in to a system. The data could be entered via mobile applications in the field or directly through a web based form. Additionally, data could be the direct output of plugins to existing general product systems, or proprietary add-ons to specific systems built around the unique aspects of a network's structure or content.

[0068] According to an embodiment, applications which can be LiveGuide applications or third party applications that deliver information to a viewer can also have a number of different methods for performing communications. These applications can communicate the LiveGuide updates directly through, for example, pop-ups, system messaging, update indicators (glowing indicators showing that new information is available), text messages, or verbal messages generated and delivered via traditional verbal message mechanisms, such as, land or mobile phones. The applications can also update existing or traditional guides with additional information. According to another embodiment, the applications can make all or part of the LiveGuide data available in a searchable/browseable formatted via the application or a web interface.

[0069] According to an embodiment, an example of a method for using the

LiveGuide system/service will now be described with respect to Figure 6. Initially, in step 602, an event is planned. Event scheduling data 604 is then added to a network's internal schedule in step 606. In step 608, the event data is sent to a LiveGuide database, e.g., LiveGuide database 510. Either automatically or manually, as shown in step 610, the event data is received by the LiveGuide cloud based database (or other LiveGuide database). In step 612, the event data is parsed and sorted. In step 614, elements of or all of the parsed and sorted event data is stored (with most or all data being searchable and retrievable) in the event data primary database. In optional steps 616 and 618, there is human review of the event data and human editing of the event data, respectively. In step 620, promotional event data can be transmitted/stored in the event data primary database. This promotional event data can be associated with the event scheduling data. New data notification 614 can be determined by either or both the event data primary database or the LiveGuide API 622. The LiveGuide API 622 interacts with both the event primary database and Liveguide enabled devices 626 by both pushing new data notifications 624 to the LiveGuide enabled devices 626 and by receiving input, as described in previous embodiments, from the LiveGuide enabled devices 626 which can then be used as input to the event data primary database as applicable. After the LiveGuide enabled device(s) 626 receive the new data notification 624, the LiveGuide event data is displayed on the device in step 628.

[0070] Figure 7 illustrates a method flow associated with transmitting alerts to a display regarding a time relevant event in accordance with embodiments. Therein, at step 702, program information is aggregated from a plurality of different service providers, wherein the information is associated with planned content broadcasts; at step 704, an addition or a change to the aggregated information is received, wherein the addition or the change is associated with the time relevant event; at step 706, the relevance of the time relevant event to a user is determined; at step 708, an alert is transmitted to a device which the user currently has active; and at step 710, the alert is displayed as an overlay.

[0071] Figure 8(a) illustrates a method flow associated with aggregating program information from different programming networks in accordance with embodiments.

Therein, at step 802, program information from a plurality of different programming networks is received; at step 804, the program information is aggregated into a framework; at step 806, instructions for transmitting overlays to a device are stored; at step 808, an update is received from a programming network about a time relevant event; at step 810, based on the stored instructions and the update, whether to transmit an overlay to the device is determined; and at step 812, the overlay is transmitted to the device based on the step of determining whether to transmit the overlay to the device.

[0072] Both Figures 7 and 8(a) show the determination of relevance occurring prior to the alert being transmitted to a device. According to another embodiment, the transmission to the device can occur prior to the determination of relevance. Additionally, according to an embodiment, the determination of the relevance of the time relevant event can be performed at the LiveGuide database 510 or at the device, or at both locations.

[0073] According to an embodiment, LiveGuide updates can generate a sense of urgency to check out what is happening in various aspects of the world, e.g., breaking news stories or a reminder that the season finale of a show is going to start in five minutes. The LiveGuide service can also be used as an internal reminder so a viewer can mark shows they want to be reminded about without marking them for recording, such as live sporting or concert events. Marketing or promotional LiveGuide events can also be generated where a viewer may be rewarded for acting quickly.

[0074] According to an embodiment, LiveGuide can also be used in support of public services as an additional point of contact for crisis or emergency information targeting a specific area. For example, while not designed to be a replacement to existing emergency information channels, since LiveGuide can be targeted to a location, the LiveGuide service can be used, for example, as a supplement to a tornado warning system and provide direct access to the channel broadcasting the critical information.

[0075] According to an embodiment, LiveGuide can provide a direct curated link between a content producer and the viewer. One method, as described above, is to build into the production system already in use at a studio or a network, a linkage to send data directly to the LiveGuide database. For example, the network has a programming center that is determining the upcoming programming minute -by-minute and by connecting directly into that programming center's software operations, LiveGuide data can be updated without much need for special human actions.

[0076] According to an embodiment, another method for providing a direct curated link between the content producer and the viewer can include more direct action while providing additional editorial control. In this scenario, the programming center submits LiveGuide events directly to the service via a content producer API specifically for submissions. The content producer API can be a protected API such that data is marked, e.g., signed or protected, in such a way that only the content producer can submit information from them. Since it is an API, the content producer may have the submission process integrated into their existing system(s) in which case this embodiment would be similar to the previously described method. According to an alternative embodiment, software can be provided that is registered with the service so that the data can be entered and sent directly from the interface. The data can be considered to include features which assist in describing the data, e.g., temporal, categorized and prioritized. These features can be used to control when the data is seen (temporal), what type of interests as, for example, defined by the receiver make it applicable (categorized), and what level of importance the data has for a specific viewer or device that the data is being sent to (prioritized). A common theme to each of the following three examples is that the content is provided directly to the viewer from the content producer.

[0077] An example using the above-described method is now described. Cable News

Network (CNN) is showing a press conference of a local law enforcement officer discussing a small plane accident that occurred earlier in the day. The press conference is set for 1 :35 pm. CNN programming informs some of their social media people about the time of the event. The social media people submit the event to LiveGuide with the timing information along with metadata describing where the event occurred, the nature of the event, and any other desired information. The LiveGuide service informs viewers who have registered in the area at all levels of priority (since it is a local event), whereas outside of the local region this event is considered to be a lower priority event and therefore informs "news junkies" and/or people interested in plane-related events. Additionally, other people can become informed based on other information and/or preferences, e.g., one of the passengers on the plane is a company executive in a specific field so that metadata including this information causes the event to become visible to those interested in the subject field.

[0078] For another example, consider a sporting event. It is nearing the end of baseball season and a team is trying to hold on to a one game advantage over their rival and they happen to currently be playing against each other. A sports network informs LiveGuide via their in-house connected software that the game just tied up in the bottom of the 8^th by the home team. Since the game is not playing nationally, those viewers in the region get informed of the channel while other viewers get a link to the media stream. In this example, this event is not a planned event, but rather an event associated with something occurring right now.

[0079] A third example is an example involving embargoed data. A TV network typically sends out reminders the airing day of new episodes of their various hit comedy series. Those airing dates are known well in advance and have a time setting that holds that announcement until a time near-enough that the reminder is not forgotten. The same API can be used except this time the API is used for an event schedule well in advance.

[0080] According to embodiments, LiveGuide is intended to and can provide having data input directly into the system from the content producers. LiveGuide is not required to use data supplied from social media contacts or other so-called "unofficial" sources.

LiveGuide can be considered to be a more up to the minute and dynamic form of a guide which is created and submitted directly by the content producer as compared to more traditional guides. According to an embodiment, other forms of unofficial information are not included in the core LiveGuide description and are specifically excluded to the degree that they would be segmented from official data at the receiver's end. This can allow for preventing situations where people could "spoof an official source or clutter the receiver's alerts.

[0081] According to an embodiment, LiveGuide and the alerts/information provided to users, is not an information spray to the user resulting from have a program scrape websites and/or feeds. Instead, LiveGuide uses a curated process where the content producer has an interest in avoiding overwhelming the user, especially with content of limited relevance to the user. Accordingly, according to an embodiment, LiveGuide allows for preventing user from getting overwhelmed by content. One method for controlling the amount of information from LiveGuide to a user is allowing and/or working with a user to refine a user's subjects/interests of relevance. In other words, the better control the user has over getting only relevant information can be obtained by refining or understanding by the system the user's subjects/interests.

[0082] For example, compare LiveGuide to alternative processes, such as Twitter.

Twitter, unlike LiveGuide, uses data supplied by social media contacts or other unofficial sources and also the uses the concept of urgency while providing a single destination for the information. In an automated mode one can only follow providers on Twitter, and in a manual process one can also look at trending topics. Also, on Twitter, information is interspersed and cluttered with all different types of information from events to musings, jokes, expressions of outrage, etc., all of which are fed to the user under the same banner. Because Twitter is not curated by the providers, it can also be full of false information and the onus is on the users to figure it out.

[0083] According to an embodiment, LiveGuide puts filtering and curation requirements on the provider who has a vested in staying relevant to the user which are differentiating aspects of LiveGuide from, for example, Twitter.

[0084] Given the above, the issue of overwhelming the user can be considered to be more of an intellectual problem than a practical problem. Since LiveGuide data reception can be totally under the control of the viewer/receiver, they always have the option of turning off any and all information from a specific provider, multiple providers or all providers. This can be considered to be no different than managing your e-mail preferences with a company which range from adding or removing specific areas of interest to fully unsubscribing everything associated with the company.

[0085] According to an embodiment, there can be a few levels of control

implemented in LiveGuide that are beyond or in addition to a user's preferences. LiveGuide is a general service and viewers opt-in to different providers or subjects. As a result, the content producers have a vested interest in not annoying their viewers. Certainly if a content provider is spamming users with notices every few minutes about what is "up next", the users are probably going to turn that particular feed off. This is a loss of a viewer which is undesirable from the point of view of the content provider. Therefore, there is some reasonable expectation that content providers will manage some portion of what is sent to users as alerts so as not to overwhelm viewers.

[0086] Managing subjects and alerts associated therewith, is a more challenging situation. For example, covering a subject as broad as sports could certainly result in an avalanche of notices coming from many different providers about many event moments which would be hard to control with simple provider opt-in/opt-out controls.

[0087] According to an embodiment, to address these issues, multiple levels of controls can be implemented. One control can be to assign a priority level to events. This can be done by a provider where they set a level of importance to the event. For example, a close baseball game can have a lower priority level that a close baseball game that has playoff implications which in turn would have a lower priority level than a close game for the championship. A viewer could set priority levels and thus filter out lower level ones for a more general class like sports. According to an embodiment, these general priority levels could be overridden, for example because the viewer sets a high priority for one of the teams, e.g., their home sports team. Algorithms can be used to determine what is applicable. In addition, analogous to Pandora, the viewer could respond to individual event notices with "more like this", or "don't want", etc., that can further refine the determination algorithm for that viewer over time.

[0088] According to an embodiment, there is a method for transmitting a message associated with a time relevant event by a content producer as shown in Figure 8(b). The method includes: at step 814, receiving information including metadata associated with the time relevant event directly from the content producer's network at a dynamic guide service; at step 816, determining, by the dynamic guide service, which users to send the message associated with the time relevant event; at step 818, transmitting the message to a device of at least one user based on the step of determining; and at step 820, displaying at least a portion of the content of the message on the device.

[0089] The embodiments described herein provide for using the LiveGuide system/service for distributing, among other features, information associated with live events which can be received and displayed by devices. An exemplary device 900 will now be described with respect to Figure 9. Device 900 can contain a processor 902 (or multiple processor cores), memory 904, one or more secondary storage devices 906, a display 908 and an interface unit 910 to facilitate communications between device 900 and the LiveGuide system 600 (as well as the linking communication network(s)). The memory 904 or secondary storage device 906 can store software/applications associated with LiveGuide, e.g., applications which enable LiveGuide on the device 900. Display 908 can display incoming alerts and other received information from the LiveGuide system 600 as overlays or other desired display formats. Examples of the device 900 which can be LiveGuide enabled include smart TVs 514, STBs 516, streaming devices 518, mobile devices 520 and/or general web browsers/PC plugins. Device 900 further includes the ability to provide feedback, e.g., selecting provided options or submitting preferences, to the LiveGuide system 600. Thus, the device 900 can perform the functions described herein associated with LiveGuide enabled devices.

[0090] According to another embodiment, device 900 can also perform the functions of the LiveGuide system 600, i.e., device 900 can be a server/database which performs the various functions such as aggregation of received content, determining what to do with a received time relevant event and transmission of overlays as described herein. The memory 902 can perform the storage functions of the LiveGuide database 510. The display 908 can be used in support of manual editing of received information as described above.

Additionally, one or more input devices (not shown) can also be used in support of the optional manual editing abilities.

[0091] Systems and methods for processing data according to exemplary

embodiments of the present invention can be performed by one or more processors executing sequences of instructions contained in a memory device. Such instructions may be read into the memory device from other computer-readable mediums such as secondary data storage device(s). Execution of the sequences of instructions contained in the memory device causes the processor to operate, for example, as described above. In alternative embodiments, hardwire circuitry may be used in place of or in combination with software instructions to implement the present invention.

[0092] Numerous variations of the afore-described exemplary embodiments are contemplated. The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, used herein, the article "a" is intended to include one or more items.

Claims

WHAT IS CLAIMED IS:

1. A method for transmitting alerts to a display regarding a time relevant event, the method comprising:

aggregating (702) program information from a plurality of different service providers, wherein the information is associated with planned content broadcasts;

receiving (704) an addition or a change to the aggregated information, wherein the addition or the change is associated with the time relevant event;

determining (706) the relevance of the time relevant event to a user;

transmitting (708) an alert to a device which the user currently has active; and displaying (710) the alert as an overlay.

2. The method of claim 1, wherein the step of transmitting an alert to a device occurs through a push mechanism.

3. The method of claim 1, wherein the step of transmitting an alert to a device occurs through a pull mechanism.

4. The method of claim 1, further comprising:

receiving use parameters from the user which are used at least in part to determine the relevance of the time relevant event to the user.

5. The method of claim 1, further comprising:

receiving use parameters from a network provider which provides service to the user's active device, the user parameters which are used at least in part to determine the relevance of the time relevant event to the user.

6. The method of claim 1, wherein the displayed overlay is text describing the addition or the change associated with the time relevant event.

7. The method of claim 1, wherein the displayed overlay includes at least one interactive choice for the user describing the addition or the change associated with the time relevant event.

8. The method of claim 1, further comprising:

receiving a request from a user to perform a search;

performing the search based on the received request and other associated information; and

returning at least one search result as an overlay.

9. The method of claim 8, wherein the other associated information includes information indirectly associated with the request.

10. The method of claim 9, wherein the at least one search result includes at least one item indirectly associated with the request.

11. The method of claim 1 , further comprising: reviewing the aggregated information; and

correcting errors in the aggregated information.

12. The method of claim 1, further comprising:

inserting paid promotional updates as overlays.

13. A system for transmitting alerts to a display regarding a time relevant event, the system comprising:

a processor (904) configured to aggregate (702) program information from a plurality of different service providers, wherein the information is associated with planned content broadcasts;

a communication interface (910) configured to receive (704) an addition or a change to the aggregated information, wherein the addition or the change is associated with the time relevant event;

the processor (904) configured to determine (706) the relevance of the time relevant event to a user;

the communication interface (910) configured to transmit (708) an alert to a device which the user currently has active; and

a display (908) configured to display (710) the alert as an overlay.

14. The system of claim 13, wherein a push mechanism is used to transmit an alert to a device.

15. The system of claim 13, wherein a pull mechanism is used to transmit an alert to a device.

16. The system of claim 13, further comprising:

the communication interface configured to receive use parameters from the user which are used at least in part to determine the relevance of the time relevant event to the user.

17. The system of claim 13, further comprising:

the communication interface configured to receive use parameters from a network provider which provides service to the user's active device, the user parameters which are used at least in part to determine the relevance of the time relevant event to the user.

18. The system of claim 13, wherein the displayed overlay is text describing the addition or the change associated with the time relevant event.

19. The system of claim 13, wherein the displayed overlay includes at least one interactive choice for the user describing the addition or the change associated with the time relevant event.

20. The system of claim 13, further comprising:

the communication interface configured to receive a request from a user to perform a search; the processor configured to perform the search based on the received request and other associated information; and

the communication interface configured to return at least one search result as an overlay.

21. The system of claim 20, wherein the other associated information includes information indirectly associated with the request.

22. The system of claim 21, wherein the at least one search result includes at least one item indirectly associated with the request.

23. The system of claim 13, further comprising:

a process for reviewing the aggregated information; and

a process for correcting errors in the aggregated information.

24. The system of claim 13, further comprising:

an editorial function configured to insert paid promotional updates as overlays.

25. A method for transmitting a message associated with a time relevant event by a content producer, the method comprising:

receiving (814) information including metadata associated with the time relevant event directly from the content producer's network at a dynamic guide service;

determining (816), by the dynamic guide service, which users to send the message associated with the time relevant event;

transmitting (818) the message to a device of at least one user based on the step of determining; and

displaying (820) at least a portion of the content of the message on the device.

26. The method of claim 25, wherein the metadata includes information about the location of the time relevant event.

27. The method of claim 25, wherein the step of determining is based at least in part on user assigned priority information for subject matter related to the time relevant event.

28. The method of claim 25, wherein only information provided by the content producer is received by users.

29. The method of claim 25, wherein receiving information including metadata associated with the time relevant event to at the dynamic guide service is done via a protected application programming interface.

30. The method of claim 25, further comprising:

assigning each of a plurality of content categories to one of a plurality of priority levels;

assigning the time relevant event to one of the plurality of content categories; and determining whether to send the message to the device of the at least one user based on the priority level associated with the time relevant event and a priority level of messages which are permitted to be sent to the at least one user device.

31. A system for transmitting a message associated with a time relevant event by a content producer, the system comprising:

a communication interface (910) of a dynamic guide service configured to receive (814) information including metadata associated with the time relevant event directly from the content producer's network;

a processor (904) of the dynamic guide service configured to determine (816) which users to send the message associated with the time relevant event;

the communication interface (910) configured to transmit (818) the message to a device of at least one user based on the step of determining; and

a display (908) configured to display (820) at least a portion of the content of the message on the device.

32. The system of claim 31 , wherein the metadata includes information about the location of the time relevant event.

33. The system of claim 31 , wherein determining is based at least in part on user assigned priority information for subject matter related to the time relevant event.

34. The system of claim 31 , wherein only information provided by the content producer is received by users.

35. The systme of claim 31 , wherein receiving information including metadata associated with the time relevant event to at the dynamic guide service is done via a protected application programming interface.

36. The system of claim 31 , further comprising:

the processer configured to assign each of a plurality of content categories to one of a plurality of priority levels;

the processor configured to assign the time relevant event to one of the plurality of content categories; and

the processor configured to determine whether to send the message to the device of the at least one user based on the priority level associated with the time relevant event and a priority level of messages which are permitted to be sent to the at least one user device.