JP7699761B2 - ATC3 Application Context Switching and Sharing - Google Patents

Description

This application relates to technological advances directed to digital television that are necessarily rooted in computer technology, and in particular to Advanced Television System Committee (ATSC) 3.0.

The Advanced Television Systems Committee (ATSC) 3.0 family of standards, set forth in A/300, is a set of numerous industry technical standards for delivering the next generation of broadcast television. ATSC 3.0 supports the delivery of a wide range of television services, including televised video, interactive services, non-real-time data delivery, and tailored advertising to a multitude of receiving devices, from ultra-high definition televisions to wireless telephones. ATSC 3.0 also provides for coordination between broadcast content (referred to as "over the air") and related broadband-delivered content and services (referred to as "over the top"). ATSC 3.0 is designed to be flexible so that as technology evolves, advances can be easily incorporated without the need to overhaul any of the associated technical standards.

As understood herein, an ATSC 3.0 receiver scans for services, including within a reception area that includes two or more frequencies carrying the same or equivalent services, such as may occur in a border area where broadcast signals from two local ATSC 3.0 broadcast stations overlap. Such border areas exist within a multi-frequency network (MFN).

As will be further understood herein, when an ATSC 3.0 receiver changes service (channel) from one channel with an associated broadcaster application to another, it should check whether the new channel has a broadcaster application signaled, and if such a broadcaster application exists and the broadcaster application of the new channel has the same "context ID" or "application context ID" as the old channel, the original broadcaster application continues to run uninterrupted. However, without the present principles, the broadcaster application can only receive notification of a service change as a result of a user action. Furthermore, if the two broadcaster applications have different context IDs (or the same context ID but different uniform resource locators (URLs)), but are related applications (e.g., stations in neighboring areas are working together), the original broadcaster application may want to send data to the destination broadcaster application. Thus, the ATSC A/344:2021 standard includes mechanisms for broadcaster applications to request and receive notification of service (channel) changes, which, in the absence of the present principles, impose significant limitations on context IDs, user action-derived actions, and application URLs. The present principles solve the coordination problem between broadcaster applications during auto-tuning, such as when crossing boundary regions in a multi-frequency network (MFN), facilitating a well-integrated viewer experience for both cooperating broadcasters in the same broadcast area and cooperating broadcasters in adjacent broadcast areas.

Thus, in a digital television in which at least one receiver is capable of receiving broadcast signals from at least a first and a second digital television broadcast assembly, a method includes automatically handing off a presentation of a first digital TV service from a first frequency to a second frequency. In response to handing off the presentation, the method includes signaling a first broadcast application (BA) associated with the first frequency that the presentation will be or has been handed off, and selectively transmitting data associated with the first BA to a second BA associated with the second frequency.

In some embodiments, the method may include identifying whether a context ID associated with the first BA is the same as a context ID associated with the second BA. Optionally, the method may include, in response to the context IDs of the first and second BAs being the same, continuing to run the first BA throughout a period during which presentation of the first digital TV service is automatically handed off from the first frequency to the second frequency.

In some implementations, the first BA is associated with a first uniform resource list (URL) and the second BA is associated with a second URL, and the method includes switching the first BA from the first URL to the second URL in response to the context IDs of the first and second BA being the same. In other implementations, the first BA is associated with a first uniform resource list (URL) and the second BA is associated with a second URL, and the method includes sending data associated with the first BA to the second BA and executing the second BA to present the first service in response to the context IDs of the first and second BA being the same.

In some implementations, the method includes transmitting data associated with the first BA to the second BA in response to handing off the presentation, regardless of whether the context ID of the first BA is the same as the context ID of the second BA and whether the first and second BAs have a common uniform resource locator (URL).

In one implementation, the condition for changing the frequency includes the first tuner losing the first signal. In another implementation, the condition for changing the frequency includes the first signal degrading. In yet another implementation, the condition for changing the frequency includes the quality of the second signal exceeding the quality of the first signal.

Note that in some embodiments, the first BA can notify the receiver that data should be passed to the second BA, and if this needs to be done, the first BA will keep the data up to date or call an API periodically to update the receiver on what data needs to be passed.

In another aspect, an apparatus includes at least one receiver configured to receive a first digital television (DTV) service on a first frequency, present the first DTV service on at least one audio-video display device, and receive the first DTV service on a second frequency. The receiver is configured to switch from presenting the first DTV service received on the first frequency to presenting the first DTV service received on the second frequency in response to at least one handoff condition being satisfied, and to signal a first broadcast application (BA) associated with the first frequency about the switch.

In another aspect, an apparatus includes at least one receiver having at least one processor programmed with instructions that configure the processor to execute a first broadcast application (BA) that presents a first service received on a first frequency on at least one audio-video (AV) display device. The first service includes at least one digital television service. The instructions are executable to automatically switch a presentation of the first service received on the first frequency to a presentation of the first service received on a second frequency associated with a second BA and signal the first BA about the switch.

The details of this application, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like elements are designated with like reference numerals.

FIG. 1 illustrates the Advanced Television Systems Committee (ATSC) 3.0 system. FIG. 2 illustrates components of the device shown in FIG. 1. FIG. 1 is a diagram illustrating a specific system example. FIG. 1 illustrates a first example embodiment of a digital TV receiver. FIG. 2 illustrates a second example embodiment of a digital TV receiver. FIG. 1 illustrates example transmitter logic in example flow chart form in accordance with present principles. FIG. 1 illustrates example receiver logic in example flow chart form in accordance with present principles; 8 illustrates in flow chart form the logic of the broadcast station application signaling with automatic handoff technique of FIG. 7 in accordance with the present principles. 8 illustrates in flow chart form the logic of the broadcast station application signaling with automatic handoff technique of FIG. 7 in accordance with the present principles. 8 illustrates in flow chart form the logic of the broadcast station application signaling with automatic handoff technique of FIG. 7 in accordance with the present principles.

The present disclosure relates to technological advances in digital television, such as Advanced Television System Committee (ATSC) 3.0 television. An example system herein may include an ATSC 3.0 source component and a client component connected via broadcast and/or network to exchange data with each other. The client components may include one or more computing devices, such as portable televisions (e.g., smart TVs, Internet-enabled TVs), portable computers, such as laptops and tablet computers, and smartphones and other mobile devices, including further examples described below. These client devices may operate in a variety of operating environments. For example, some of the client computers may employ operating systems such as Microsoft's operating system, or the Unix operating system, or Android (registered trademark) manufactured by Apple Computer, Inc. or Google, Inc., as examples. These operating environments may be used to run one or more browsing programs, such as browsers created by Microsoft, Google, Inc., or Mozilla, or other browsing programs that can access websites hosted by Internet servers, as described below.

ATSC 3.0 Publication A/344, which is incorporated herein by reference, may be particularly relevant to the techniques described herein.

The ATSC 3.0 source component may include a broadcast transmission component and a server and/or gateway that may include one or more processors executing instructions that configure the source component to broadcast and/or transmit data over a network such as the Internet. Specific examples of client components and/or local ATSC 3.0 source components include gaming consoles such as Sony PlayStation (registered trademark), personal computers, etc.

Information may be exchanged between the client and the server over a network. For this purpose and for security, the server and/or client may include firewalls, load balancers, temporary storage, and proxies, as well as other network infrastructure that enhances authenticity and security.

As used herein, instructions refer to computer-implemented steps for processing information within a system. Instructions may be implemented in software, firmware, or hardware and may include any type of program step performed by a component of the system.

The processor can be a single-chip or multi-chip processor capable of performing logic through various lines such as address lines, data lines and control lines, as well as registers and shift registers.

The software modules described by the flowcharts and user interfaces herein may include various subroutines, procedures, and the like. Without limiting the disclosure, logic disclosed as being performed by a particular module may also be redistributed among other software modules and/or combined into a single module and/or utilized within a shareable library. Although a flowchart format may be used, it should be understood that the software may also be implemented as a state machine or other logical method.

The principles described herein may be implemented as hardware, software, firmware, or a combination thereof, and thus example components, blocks, modules, circuits, and steps are described in terms of their functionality.

In addition to those suggested above, the logic blocks, modules and circuits may be implemented or performed using general purpose processors, digital signal processors (DSPs), field programmable gate arrays (FPGAs) or other programmable logic devices such as application specific integrated circuits (ASICs), discrete gate or transistor logic, discrete hardware components, or any combination of these designed to perform the functions described herein. A processor may be implemented by a combination of controllers, state machines, or computing devices.

The functions and methods described below, when implemented in software, can be written in any suitable language, including but not limited to HyperText Markup Language (HTML)-5, Java/Javascript, C#, C++, and can be stored in or transmitted through a computer-readable storage medium, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disk read-only memory (CD-ROM), or other optical disk storage, such as digital versatile disk (DVD), magnetic disk storage, or other magnetic storage devices, including removable thumb drives. A connection can constitute the computer-readable medium. Such connections can include, by way of example only, wired cables, including optical fiber, coaxial cable, digital subscriber line (DSL), and twisted pair cable.

Components included in one embodiment may be used in other embodiments in any suitable combination. For example, any of the various components described herein and/or illustrated in the figures may be combined, substituted, or excluded from other embodiments.

The phrase "having at least one of A, B, and C (similarly, "having at least one of A, B, or C" and "having at least one of A, B, C") includes A only, B only, C only, both A and B, both A and C, both B and C, and/or all of A, B, and C, etc.

With reference to FIG. 1, an example of an ATSC 3.0 source component, designated as a "broadcast station facility" 10, may include an over-the-air (OTA) facility 12 that broadcasts television data wirelessly via orthogonal frequency division multiplexing (OFDM) to multiple receivers 14, such as ATSC 3.0 televisions, typically in a one-to-many relationship. The one or more receivers 14 may communicate with one or more companion devices 16, such as remote control devices, tablet computers, and mobile phones, via a short-range link 18, which is typically wireless and may be implemented by Bluetooth, low-energy Bluetooth, other Near Field Communication (NFC) protocols, infrared (IR), and the like.

One or more of the receivers 14 may also communicate, typically in a one-to-one relationship, with over-the-top (OTT) equipment 22 of the broadcast facility 10 via a wired and/or wireless network link 20, such as the Internet. The OTA equipment 12 may be co-located with the OTT equipment 22, or both equipment 12, 22 of the broadcast facility 10 may be remote from each other and communicate with each other through suitable means. In either case, the receiver 14 may receive ATSC 3.0 television signals over the OTA via a tuned ATSC 3.0 television channel, or may receive related content, including television, over the OTT (broadband). Note that the computer devices described in all figures herein may include some or all of the components shown for the various devices in Figures 1 and 2.

Referring now to FIG. 2, details of the example components shown in FIG. 1 can be seen. FIG. 2 illustrates an example protocol stack that can be implemented by a combination of hardware and software. A broadcaster can transmit a hybrid service distribution that distributes one or more program elements over a computer network (referred to herein as "broadband" and "over the top" (OTT)) and over the air (referred to herein as "broadcast" and "over the air" (OTA)) using the ATSC 3.0 protocol stack, appropriately modified for the broadcaster side, shown in FIG. 2. FIG. 2 also illustrates an example stack including hardware that can be embodied by a receiver.

2 from the perspective of the broadcast facility 10, one or more processors 200 accessing one or more computer storage media 202, such as any memory or storage described herein, can be implemented to provide one or more software applications at a top application layer 204. The application layer 204 can include one or more software applications written in, for example, HTML5/Javascript that operate in a runtime environment. Applications in the application stack 204 can include, but are not limited to, linear TV applications, interactive services applications, companion screen applications, personalization applications, emergency alert applications, and usage reporting applications. Typically, applications are embodied in software that represents elements of the viewer experience, including video coding, audio coding, and runtime environment. By way of example, applications can be provided that allow the user to control dialogue, use alternative audio tracks, and control audio parameters such as normalization and dynamic range.

Below the application layer 204 is the presentation layer 206. The presentation layer 206 includes a broadcast audio-video playback device called a media processing unit (MPU) 208 on the over-the-air (OTA) side that, when implemented in a receiver, decodes the over-the-air broadcast audio-video content and plays it on one or more displays and speakers. The MPU 208 is configured to present the International Organization for Standardization (ISO) Base Media File Format (BMFF) data representation 210, and video in High Efficiency Video Coding (HEVC), with audio in, for example, Dolby Audio Compression (AC)-4 format. ISO BMFF is a generic file structure for time-based media files that are divided into "segments" and presentation metadata. Essentially, each file is a set of nested objects, each with its own type and length. The MPU 208 has access to a broadcast-side encrypted media extension (EME)/common encryption (CENC) module 212 to facilitate decryption.

FIG. 2 further illustrates that on the broadcast side, the presentation layer 206 can include signaling modules including either a Moving Picture Experts Group (MPEG) Media Transport (MMT) Protocol (MMTP) signaling module 214 or a real-time object delivery over unidirectional transport (ROUTE) signaling module 216 to deliver non-real-time (NRT) content 218 accessible to the application layer 204. NRT content can include, but is not limited to, stored alternative advertisements.

On the broadband (OTT or computer network) side, if implemented by a receiver, the presentation layer 206 may include one or more Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH) players/decoders 220 to decode and play audio-video content from the Internet. For this purpose, the DASH players 220 may access an EME/CENC module 222 on the broadband side. DASH content may be provided as DASH segments 224 in ISO/BMFF format.

The broadband side of the presentation layer 206, like the broadcast side, can include NRT content in files 226 as well as signaling objects 228 that provide playback signaling.

Below the presentation layer 206 in the protocol stack is the session layer 230, which includes either the MMT protocol 232 or the ROUTE protocol 234 on the broadcast side. Note that the ATSC standard provides the option to use MPEG MMT for transmission, but this is not shown here.

The session layer 230 includes an HTTP protocol 236 that can be implemented as HTTP-secure (HTTP(S)) on the broadband side. The broadband side of the session layer 230 can also employ an HTTP proxy module 238 and a service list table (SLT) 240. The SLT 240 includes a table of signaling information used to build a basic service list and provide bootstrap discovery of broadcast content. The "ROUTE signaling" table includes a media presentation description (MPD) that is delivered over the User Datagram Protocol (UDP) by the ROUTE transport protocol.

Below the session layer 230 in the protocol stack is the transport layer 242 for establishing low-latency, loss-tolerating connections. The transport layer 242 uses UDP 244 on the broadcast side and Transmission Control Protocol (TCP) 246 on the broadband side.

The non-limiting example protocol stack shown in FIG. 2 also includes a network layer 248 below the transport layer 242. The network layer 248 uses the Internet Protocol (IP) on both sides for IP packet communication, with multicast delivery being typical on the broadcast side and unicast on the broadband side.

Below the network layer 248 is the physical layer 250, which includes broadcast transmission/reception equipment 252 and computer network interface(s) 254 for communicating on the respective physical mediums associated with both sides. The physical layer 250 converts Internet Protocol (IP) packets for transmission on the associated medium and may include modulation and demodulation modules to incorporate modulation and demodulation functions, as well as adding forward error correction to allow for error correction at the receiver. The physical layer 250 converts bits into symbols for long distance transmission and improved bandwidth efficiency. The physical layer 250 typically includes a wireless broadcast transmitter on the OTA side that broadcasts data over the air using Orthogonal Frequency Division Multiplexing (OFDM), and a computer transmission component on the OTT side that transmits data over the Internet.

On the broadband side, the DASH Industry Forum (DASH-IF) profile can be used, transmitted over various protocols (HTTP/TCP/IP) in the protocol stack. Media files in the DASH-IF profile, which is based on ISO BMFF, can be used as a distribution, media encapsulation and synchronization format for both broadcast and broadband distribution.

Typically, each receiver 14 includes a protocol stack that is complementary to the protocol stack of the broadcast station equipment.

Receiver 14 of FIG. 1 may include an Internet-enabled TV having an ATSC 3.0 TV tuner 256 (equivalent to a set-top box that controls a TV), as shown in FIG. 2. Receiver 14 may be an Android-based system. Alternatively, receiver 14 may be implemented by a computerized Internet-enabled ("smart") phone, tablet computer, notebook computer, wearable computing device, and the like. Nevertheless, it should be understood that receiver 14 and/or other computers described herein may be configured to implement the present principles (e.g., communicate with other devices to implement the present principles, execute logic described herein, and perform any other functions and/or operations described herein).

Receiver 14 may thus be established by some or all of the components shown in FIG. 1 to implement such principles. For example, receiver 14 may include one or more displays 258, which may or may not be touch-enabled, implemented by a high definition or ultra-high definition "4K" or higher flat screen to receive user input signals via touch on the display. Receiver 14 may also include one or more speakers 260 for outputting audio in accordance with the present principles, and at least one further input device 262, such as an audio receiver/microphone, for inputting audible commands to receiver 14, such as to control receiver 14. Examples of receiver 14 may further include one or more network interfaces 264 for communicating over at least one network, such as the Internet, WAN, LAN, PAN, etc., under the control of one or more processors 266. Thus, interface 264 may be a Wi-Fi transceiver, which is an example of a wireless computer network interface, such as, but not limited to, a mesh network transceiver. The interface 264 can be, but is not limited to, a Bluetooth transceiver, a Zigbee transceiver, an Infrared Data Association (IrDA) transceiver, a wireless USB transceiver, a wired USB, a wired LAN, a power line, or a Multimedia over Coax Alliance (MoCA). It should be understood that the processor 266 controls the receiver 14 to implement the present principles, including other elements of the receiver 14 described herein, such as controlling the display 258 to present images and receive inputs. Additionally, the network interface 264 can be, for example, a wired or wireless modem or router, or other suitable interface, such as a wireless telephone transceiver or a Wi-Fi transceiver as described above.

In addition to the above, receiver 14 may also include one or more input ports 268, such as a High-Definition Multimedia Interface (HDMI) port or a USB port, for physically connecting (using a wired connection) to another CE device, and/or a headphone port for connecting headphones to receiver 14 to present audio from receiver 14 to a user through the headphones. For example, input port 268 may connect via wire or wireless to a cable or satellite source of audio-video content. Thus, the source may be a separate or integrated set-top box or satellite receiver. Alternatively, the source may be a game console or disc player.

Receiver 14 may further include one or more computer memories 270, such as non-transitory disk-based or solid-state storage, embodied in some cases as a stand-alone device within the receiver chassis, as a personal video recorder (PVR) or video disk player for playing audio-video (AV) programs, or as a removable storage medium, inside or outside the receiver chassis. In some embodiments, receiver 14 may also include a position or location receiver 272, such as, but not limited to, a mobile phone receiver, a global positioning satellite (GPS) receiver, and/or an altimeter, configured to receive geographic location information, for example, from at least one satellite or mobile phone tower and provide this information to processor 266 and/or determine the altitude at which receiver 14 is located with processor 266. However, it should be understood that other suitable position receivers other than a mobile phone receiver, a GPS receiver, and/or an altimeter may be used in accordance with the present principles to determine the location of receiver 14, for example, in all three dimensions.

Continuing with the description of the receiver 14, in some embodiments, the receiver 14 can include one or more cameras 274, which can include one or more of a thermal imaging camera, a digital camera such as a webcam, and/or a camera integrated into the receiver 14 and controllable by the processor 266, to collect pictures/images and/or videos in accordance with the present principles. The receiver 14 can also include a Bluetooth transceiver 276 or other near field communication (NFC) element for communicating with other devices using Bluetooth and/or NFC technology, respectively. An example NFC element can be a radio frequency identification (RFID) element.

Additionally, the receiver 14 may include one or more auxiliary sensors 278 (such as motion sensors such as accelerometers, gyroscopes, cyclometers, or magnetic sensors and combinations thereof) that provide input to the processor 266, infrared (IR) sensors for receiving IR commands from a remote control device, optical sensors, speed and/or cadence sensors, gesture sensors (for detecting gesture commands), etc. An IR sensor 280 may also be provided for receiving commands from a wireless remote control. A battery (not shown) may also be provided to power the receiver 14.

The companion device 16 may include some or all of the elements shown in relation to the receiver 14 described above.

The methods described herein may be implemented as software instructions executed by a processor, a suitably configured application specific integrated circuit (ASIC) or field programmable gate array (FPGA) module, or any other convenient manner as would be understood by one of ordinary skill in the art. The software instructions, if employed, may be embodied in a non-transitory device such as a CD ROM or flash drive. Alternatively, the software code instructions may be embodied in a transitory configuration such as a radio or optical signal, or through download over the internet.

3, a simplified digital TV system such as an ATSC 3.0 system is shown. In FIG. 3, a mobile or fixed digital TV receiver such as an ATSC 3.0 receiver 300, which may include some or all of the relevant components described above in connection with FIG. 1 and FIG. 2, is located in a boundary area 302 between a first and a second ATSC 3.0 broadcast station or assembly 304, and signals from both stations 304 are picked up by the receiver 300 in the area 302. The first broadcast station 304 broadcasts a first ATSC 3.0 service ("Service A") on a first frequency 306, while the second broadcast station 304 broadcasts the same Service A or an equivalent Service B on a second frequency 308 different from the first frequency 306. The receiver 300 picks up both frequencies, i.e., the receiver 300 picks up signals from both stations 304.

FIG. 4 illustrates a non-limiting example embodiment of a digital TV receiver, such as an ATSC 3.0 receiver 400, which may include some or all of the associated components described above in connection with FIGS. 1 and 2. In the illustrated example, the ATSC 3.0 receiver 400 may be a fixed receiver, such as a receiver located in a home. In some examples, the ATSC 3.0 receiver 400 may be a mobile receiver, such as implemented in a mobile phone or located in a moving vehicle.

The example ATSC 3.0 receiver 400 shown in FIG. 4 includes a tuner 402 that sends a signal picked up from one or more antennas 406 to a demodulator 404. The receiver 400 includes only one tuner, only one demodulator, and only one antenna.

In contrast, FIG. 5 illustrates a non-limiting example embodiment of a digital TV receiver, such as an ATSC 3.0 receiver 500, which may include some or all of the associated components described above in connection with FIGS. 1 and 2. In the illustrated example, the ATSC 3.0 receiver 500 may be a mobile receiver, such as, for example, implemented in a mobile phone or located in a mobile vehicle. In some examples, the ATSC 3.0 receiver 500 may be a fixed receiver, such as, for example, a receiver located in a home.

The example ATSC 3.0 receiver 500 shown in FIG. 5 includes multiple tuners 502 that transmit signals picked up from one or more antennas 506 to respective demodulators 504. In the illustrated non-limiting example, the ATSC 3.0 receiver 500 has two tuners and two demodulators, but it is understood that it can have more or fewer tuners/demodulators. In the illustrated non-limiting example, the ATSC 3.0 receiver 500 has four antennas, but it is understood that it can have more or fewer antennas. The receiver 500 can switch antenna inputs to the tuners, so that a first tuner receives signals from three antennas, etc., a second tuner receives a signal from a fourth antenna, and then the antenna inputs are swapped between the tuners. Two antennas can provide inputs to each respective tuner. All four antennas can provide inputs to a single tuner. These and other antenna-tuner configurations can be changed on the fly during operation as needed. The antenna can be movable relative to the receiver.

Quality metrics of RF frequencies are described herein and such quality metrics can be identified and stored. Quality metrics can include, for example, signal-to-noise ratio (SNR) and error rate, which can be expressed by packet error count (PEN). Quality metrics can include, for example, resolution, such as whether the service is high definition (HD) or standard definition (SD). Quality metrics can also include bit rate and form factor, recognizing that not all HD is the same. Quality metrics can include content attributes, such as whether the service supports foreign languages, accessibility signaling (e.g., where the sign is), voice portrayal, and other content aspects. Quality metrics can include locality preferences (e.g., a first region's channels are strong, but a duplicate service from a second region can be granted preference over the first region because all the ads are for the first region and not the second region as the user desires). Quality metrics can include the quality of the user interface featured in the service.

In a non-limiting example, the SNR can be determined during a scan by looking at both the received signal strength at each receive frequency and any associated noise at that frequency and taking the quotient. The error rate can be determined, for example, by determining the percentage of packets that are lost (by looking at the lost packet number) and/or by determining the percentage of received packets that contain errors as determined by an error correction algorithm.

FIG. 6 illustrates logic executable by a transmitter, such as an OTA transmitter or an OTT transmitter, to transmit services on one or more frequencies, including, in the example of FIG. 6, service "A" on frequency "A." Proceeding to block 602, the transmitter or another transmitter in the system transmits a service list of services and corresponding RF frequencies, such as in a Service List Table (SLT), as well as transmitting ("signaling") one or more overlapping services on different frequencies.

Receiver logic according to the present principles is shown in FIG. 7. Starting at block 700, a first service transmitted on a first frequency ("A") from a broadcast station is received and presented on an AV device. Proceeding to decision state 702, the receiver determines, using, for example, one or more quality metrics described herein, whether a duplicate, partial, equivalent, or preferred broadcast of the first service received on a different frequency ("B") from a different transmitter, typically when crossing a boundary region, has a higher signal quality than the first frequency (A), and performs an automatic handoff from the presentation of the first service on frequency A to the presentation of the service received on frequency B at block 704. If not, the receiver continues to present content from the first frequency (A) at block 700.

Note that in one implementation, the condition for changing the frequency can include the first tuner losing the first signal (frequency) entirely. In another implementation, the condition for changing the frequency can include the first signal degrading below a threshold. In yet another implementation, the condition for changing the frequency can include the quality of the second signal (frequency) exceeding the quality of the first signal (frequency), as described above.

8-10 show various conditional techniques for broadcaster application management by the automatic service handoff of block 704 of FIG. 7. Typically, broadcaster applications (BAs) are downloaded from broadcasters by ATSC 3.0 receivers using ROUTE/DASH or MMT to perform various functions. Broadcaster applications can include a downloaded set of interrelated documents that are intended to run in the application environment to perform one or more functions, such as providing interactivity or targeted ad insertion. Application documents can include (but are not limited to) HTML, JavaScript, CSS, XML, and multimedia files. Applications can access other data that is not part of the application itself. Broadcaster applications can be distinguished from other applications by their ability to support localized interactivity without a broadband connection. BA refers to the client-side functionality of a broad range of web applications that provide interactive services. This distinction is made because broadcasters only transmit client-side documents and code.

Although state 800 is shown in decision flow format, to illustrate that FIG. 8 applies to the service handoff of block 704, it is understood that the state logic could equally well be used where the existing (pre-handoff) BA (station application "A" in FIG. 8) has the same context ID as the new (post-handoff) BA (station application "B" in FIG. 8) when tuning from channel A to channel B as a result of the automated process. If this condition is not met, the logic of FIG. 8 ends at state 802. On the other hand, if the conditions of state 800 are met, the logic proceeds to block 804 to notify station application A that the service has changed. In state 806, station application A can continue to run uninterrupted during and after the service handoff to the new frequency.

Note that the Context ID is a unique Uniform Resource Identifier (URI) signaled in the broadcast that determines which resources the receiving processor provides to the associated broadcaster application. A resource can be associated with multiple application context identifiers, but a BA is only associated with a single Context ID. The Context ID may be further specified in "Guidelines for Implementation: DASH-IF Interoperability Point for ATSC 3.0", DASH Industry Forum, which is incorporated herein by reference, which is the HTML Entry Page Location Description (HELD) portion of the DASH-IF.

Figure 9 illustrates another condition for automatic service handoff. Figure 9 starts at state 900 and proceeds to block 902 for the second option or directly to decision block 904 for the first option ("option" means "embodiment"). In block 902, the BA associated with the first frequency A provides and/or updates data to be passed to the second (alternative) BA associated with the second frequency B. The logic proceeds from block 902 for the second option or directly from start state 900 for the first option to block 904 to determine whether a first and second BA with both the same application context ID and the same uniform resource list (URL) have been signaled. If so, the logic ends at state 906 (essentially involving the logic of Figure 8).

On the other hand, if the first and second BAs do not have the same context ID or the same URL, the logic of the first option (embodiment) proceeds to block 908, where it notifies the first BA associated with frequency A that the tuned frequency is to be changed. Proceeding to block 910, this option, a response is received from the first BA that includes data to be passed to the second BA, i.e., the BA of the new (second) frequency B.

The logic reaches state 912 either from block 910 in the first option or directly from a negative result of the verification in decision block 904 in the second option to end the first BA and start the second BA in state 914. The application from the first BA is handed off to the second BA in block 916. The logic then ends in state 906.

10 illustrates yet another condition for managing BAs during an automatic service handoff. In block 1000, upon automatic tuning from one frequency carrying a service to another frequency carrying the same service, such as may occur when a mobile receiver is passing through a boundary region between two transmitters, an existing BA ("A") on the original frequency is notified of the impending handoff. Proceeding to block 1002, the original BA ("A") is notified that it must or can provide data to the receiver (i.e., mandatory or optional), which the receiver provides to the broadcast station application ("B") on the second frequency in block 1004. This process can be used regardless of whether the context ID of BA "A" is the same as the context ID of BA "B" and regardless of whether the BAs have the same URL as each other.

Although the present principles have been described with reference to certain example embodiments, it will be understood that these embodiments are not intended to be limiting and that the subject matter claimed herein may be implemented using a variety of alternative configurations.

Claims (19)

1. A digital television, at least one receiver capable of receiving broadcast signals from at least first and second digital television broadcast assemblies, comprising:
automatically handing off a presentation of a first digital TV service from a first frequency to a second frequency;
in response to handing off the presentation, signaling to a first broadcaster application (BA) associated with said first frequency that the presentation is to be or has been handed off;
selectively transmitting data associated with the first BA to a second BA associated with the second frequency;
The method according to claim 1, further comprising: identifying whether a context ID associated with the first BA is the same as a context ID associated with the second BA;
The method of claim 1. in response to the context ID of the first and second BAs being the same, continuing to execute the first BA throughout a period during which presentation of the first digital TV service is automatically handed off from the first frequency to the second frequency.
The method of claim 2. the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, the method including, in response to the context ID of the first and second BA being the same, switching the first BA from the first URL to the second URL.
The method of claim 2. the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, and the method includes, in response to the context IDs of the first and second BAs being the same, sending data associated with the first BA to the second BA and executing the second BA to present the first digital TV service.
The method of claim 2. sending data associated with the first BA to the second BA in response to handing off the presentation, regardless of whether a context ID of the first BA is the same as a context ID of the second BA and whether the first and second BAs have a common Uniform Resource Locator (URL).
The method of claim 1. responsive to the first frequency being lost, automatically handing off presentation of the first digital TV service from the first frequency to the second frequency.
The method of claim 1. automatically handing off presentation of the first digital TV service from the first frequency to the second frequency in response to the first frequency being degraded.
The method of claim 1. automatically handing off the presentation of the first digital TV service from the first frequency to the second frequency in response to a quality of the second frequency exceeding a quality of the first frequency.
The method of claim 1. An apparatus comprising at least one receiver, the at least one receiver comprising:
receiving a first digital television (DTV) service on a first frequency;
presenting the first DTV service on at least one audio-video display device;
receiving the first DTV service on a second frequency;
switch from a presentation of the first DTV service received on the first frequency to a presentation of the first DTV service received on the second frequency in response to at least one handoff condition being satisfied;
signalling a first broadcaster application (BA) associated with said first frequency about said switching;
selectively transmitting data associated with the first BA to a second BA associated with the second frequency;
It is configured as follows:
An apparatus comprising: The receiver is configured to identify whether a context ID associated with the first BA is the same as a context ID associated with the second BA.
11. The apparatus of claim 10 . the receiver is configured, in response to the context ID of the first and second BAs being the same, to continue executing the first BA throughout a period during which presentation of the first DTV service is automatically handed off from the first frequency to the second frequency.
12. The apparatus of claim 11 . the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, and the receiver is configured to switch the first BA from the first URL to the second URL in response to the context ID of the first and second BA being the same.
12. The apparatus of claim 11 . the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, and the receiver is configured, in response to the context IDs of the first and second BAs being the same, to send data associated with the first BA to the second BA and execute the second BA to present the first DTV service.
12. The apparatus of claim 11 . An apparatus comprising at least one receiver, the at least one receiver comprising:
receiving a first digital television (DTV) service on a first frequency;
presenting the first DTV service on at least one audio-video display device;
receiving the first DTV service on a second frequency;
switch from a presentation of the first DTV service received on the first frequency to a presentation of the first DTV service received on the second frequency in response to at least one handoff condition being satisfied;
signalling a first broadcaster application (BA) associated with said first frequency about said switching;
configured to transmit data associated with the first BA to the second BA in response to handing off a presentation, regardless of whether a context ID of the first BA is the same as a context ID of a second BA associated with the second frequency and regardless of whether the first and second BAs have a common Uniform Resource Locator (URL).
An apparatus comprising : 1. An apparatus comprising at least one receiver including at least one processor programmed with instructions, the instructions causing the processor to:
executing a first broadcast station application (BA) for presenting a first service received on a first frequency, the first service including at least one digital television service, on at least one audio-video (AV) display device;
automatically switching the first service offering received on the first frequency to the first service offering received on a second frequency associated with a second BA;
signaling the first BA about the switch;
Configure it as follows:
An apparatus comprising: the instructions are executable to selectively transmit data associated with the first BA to the second BA.
17. The apparatus of claim 16 . the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, and the instructions are executable to, in response to a context ID of the first and second BA being the same, switch the first BA from the first URL to the second URL.
17. The apparatus of claim 16 . the first BA is associated with a first Uniform Resource Locator (URL) and the second BA is associated with a second URL, and the instructions are executable to, in response to a context ID of the first and second BA being the same, send data associated with the first BA to the second BA and execute the second BA to present the first service.
17. The apparatus of claim 16 .

Images