Switching and Sharing of ATC3 Application Context

Abstract

Techniques are described that extend and / or improve the Advanced Television Systems Committee (ATSC) 3.0 television protocol in ensuring delivery of next generation broadcast television services. When a mobile receiver (300) automatically switches from presenting a service on a first frequency (306) to a second frequency (308), such as when the mobile receiver (300) is moving through a boundary region (304) between two broadcast stations, the current broadcast station application can be notified (804 / 904 / 1000) and, depending on the context, can continue to run (806) or send data to the new broadcast station application (906 / 1004).

Description

Technical Field

[0001] This application relates to technological advancements that are necessarily rooted in computer technology and are targeted at digital televisions, specifically regarding the Advanced Television Systems Committee (ATSC) 3.0.

Background Art

[0002] The Advanced Television Systems Committee (ATSC) 3.0 standard group is a set of numerous industry technical standards for delivering next-generation broadcast television, as shown in A / 300. ATSC 3.0 supports the provision of a wide range of television services, such as televised video, two-way services, non-real-time data delivery, and tailored advertising, for numerous receiving devices from ultra-high-definition televisions to wireless phones. ATSC 3.0 also integrates the coordination between broadcast content (referred to as "Over the Air") and related broadband delivery content and services (referred to as "Over the Top"). ATSC 3.0 is designed to have the flexibility to easily incorporate advancements without the need to comprehensively review any related technical standards as technology evolves.

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

Summary of the Invention

Problems to be Solved by the Invention

[0004] As further understood in this specification, when an ATSC 3.0 receiver changes services (channels) from one channel including a related broadcast station application to another channel, it should check whether the newly signaled broadcast station application exists on the new channel. If such a broadcast station application exists and the broadcast station application of the new channel has the same "context ID" or "application context ID" as the old channel, the original broadcast station application should continue to execute without interruption. However, if this principle does not exist, the broadcast station application can only receive a service change notification as a result of user action. Furthermore, if two broadcast station applications have different context IDs (or the context IDs are the same but different uniform resource locators (URLs)) and are related applications (for example, stations in neighboring areas are collaborating), the original broadcast station application may wish to send data to the destination broadcast station application. Therefore, the ATSC A / 344:2021 standard includes a mechanism for a broadcast station application to request and receive a service (channel) change notification. However, if this principle does not exist, significant restrictions will be imposed on context IDs, actions derived from user actions, application URLs, etc. This principle solves the coordination problem between broadcast station applications during auto-tuning, such as when crossing the boundary area in a multi-frequency network (MFN), and facilitates a fully integrated viewer experience for both collaborating broadcast stations within the same broadcast area and collaborating broadcast stations in adjacent broadcast areas.

Means for Solving the Problems

[0005] Accordingly, in a digital television in which at least one receiver can receive broadcast signals from at least first and second digital television broadcast assemblies, a method includes automatically handing off a presentation of a first digital TV service from a first frequency to a second frequency. The method includes signaling, in response to handing off the presentation, that the presentation is scheduled to be handed off or has been handed off to a first broadcast station application (BA) associated with the first frequency, and selectively transmitting data associated with the first BA to a second BA associated with the second frequency.

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

[0007] In some implementations, the first BA is associated with a first uniform resource list (URL), 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 BAs being the same. In other implementations, the first BA is associated with a first uniform resource list (URL), the second BA is associated with a second URL, and the method includes transmitting 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 BAs being the same.

[0008] 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 regardless of whether the first and second BAs have a common uniform resource locator (URL).

[0009] In an implementation example, the condition for changing the frequency includes that the first tuner loses the first signal. In other implementation examples, the condition for changing the frequency includes that the first signal deteriorates. In still other implementation examples, the condition for changing the frequency includes that the quality of the second signal exceeds the quality of the first signal.

[0010] Note that in some embodiments, the first BA can notify the receiver that data should be passed to the second BA, and if it is necessary to do so, the first BA maintains the data up-to-date or periodically calls an API to update the receiver about what data needs to be passed.

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

[0012] In another aspect, a device includes at least one receiver having at least one processor programmed with instructions that configure the processor to execute a first broadcast station application (BA) that presents a first service received at 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 the presentation of the first service received at the first frequency to the presentation of the first service received at a second frequency associated with a second BA, and to signal about the switch to the first BA.

[0013] The details of the present application can be best understood by referring to the accompanying drawings which show like elements with like reference numerals with respect to both its structure and operation.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Modes for Carrying Out the Invention

[0015] This disclosure relates to the technological advancements of digital televisions such as Advanced Television Systems Committee (ATSC) 3.0 televisions. System examples herein can include ATSC 3.0 source components and client components connected via broadcast and / or network so as to be able to exchange data with each other. Client components can include one or more computer devices such as portable televisions (e.g., smart TVs, Internet-capable TVs), portable computers such as laptop and tablet computers, and other mobile devices such as smartphones and further examples described below. These client devices can operate in various operating environments. For example, some of the client computers can employ an operating system such as an operating system of Microsoft, or a Unix operating system, or Android (registered trademark) manufactured by Apple Computer or Google. These operating environments can be used to execute one or more browsing programs such as browsers created by Microsoft, Google or Mozilla, or other browsing programs capable of accessing a website hosted by an Internet server described below.

[0016] The ATSC 3.0 Publication A / 344 incorporated herein by reference can be related to the technologies described herein, among other things.

[0017] The ATSC 3.0 source component can include a broadcast transmission component and a server and / or gateway that can include one or more processors that execute instructions configuring the source component to perform data broadcasting and / or data transmission via a network such as the Internet. Examples of client components and / or local ATSC 3.0 source components can include game consoles such as Sony PlayStation (registered trademark), personal computers, and the like.

[0018] Information can be exchanged between the client and the server via a network. For this purpose and for security, the server and / or the client can include a firewall, a load balancer, a temporary storage, and a proxy, as well as other network infrastructure for enhancing authenticity and security.

[0019] As used herein, an instruction means a computer-implemented step for processing information within a system. The instructions can be implemented in software, firmware or hardware, and can include any type of program steps performed by components of the system.

[0020] The processor can be a single-chip or multi-chip processor that can execute logic by means of various lines such as address lines, data lines and control lines, as well as registers and shift registers.

[0021] The software modules illustrated by the flowcharts, and the user interfaces herein, can include various subroutines, procedures, etc. Without limiting the present disclosure, the logic disclosed as being executed by a particular module can also be redistributed to other software modules, and / or combined into a single module, and / or utilized within a shareable library. Although the flowchart form can be used, it should be understood that the software can also be implemented as a state machine or other logical method.

[0022] The principles described herein can be implemented as hardware, software, firmware, or any combination thereof, and thus exemplary components, blocks, modules, circuits, and steps are described in terms of their functional aspects.

[0023] In addition to what was suggested above, logic blocks, modules, and circuits can be implemented or executed using a general-purpose processor, a digital signal processor (DSP), a field programmable gate array (FPGA), or other programmable logic devices such as application specific integrated circuits (ASICs), discrete gates or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor can be implemented by a controller, a state machine, or a combination of computer devices.

[0024] The functions and methods described below, when implemented in software, are not limited to the following, but can be written in a suitable language such as Hypertext Markup Language (HTML)-5, Java (registered trademark) / Javascript, C#, C++, etc., and 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 disc read-only memory (CD-ROM), or other optical disc storage such as digital versatile disc (DVD), magnetic disc storage, or other magnetic storage devices including removable thumb drives. A certain connection can construct a computer-readable medium. Such connections can include, by way of example, wired cables including optical fiber, coaxial cable, digital subscriber line (DSL), and twisted pair wire.

[0025] The components included in one embodiment can be used in any suitable combination in other embodiments. For example, any of the various components described and / or shown in the figures herein can be combined, replaced, or excluded from other embodiments.

[0026] The description of "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 only A, only B, only C, both A and B, both A and C, both B and C, and / or all of A, B, and C, etc.

[0027] Referring to FIG. 1, an example of an ATSC 3.0 source component denoted as "broadcast station equipment" 10 can typically include over-the-air (OTA) equipment 12 that wirelessly broadcasts television data to a plurality of receivers 14 such as an ATSC 3.0 television via orthogonal frequency division multiplexing (OFDM) in a one-to-many relationship. One or more receivers 14 can communicate with one or more companion devices 16 such as a remote control device, a tablet computer, and a mobile phone via a typically wireless short-range link 18 that can be implemented by Bluetooth (registered trademark), low-energy Bluetooth, other near-field communication (NFC) protocols, infrared (IR), etc.

[0028] Also, one or more of the receivers 14 can communicate with the over-the-top (OTT) equipment 22 of the broadcast station equipment 10 via a wired and / or wireless network link 20 such as the Internet, typically in a one-to-one relationship. The OTA equipment 12 can be located at the same position as the OTT equipment 22, or both the OTA equipment 12 and the OTT equipment 22 of the broadcast station equipment 10 can also communicate with each other remotely through appropriate means. In any case, the receiver 14 can receive an ATSC 3.0 television signal via OTA through a tuned ATSC 3.0 television channel, or can also receive related content including a television via OTT (broadband). Note that the computer devices described in all the figures of this specification can include some or all of the components shown for the various devices in FIGS. 1 and 2.

[0029] Next, referring to FIG. 2, the details of the component examples shown in FIG. 1 can be seen. FIG. 2 shows an example of a protocol stack that can be implemented by a combination of hardware and software. The broadcast station uses an ATSC 3.0 protocol stack appropriately modified for the broadcast station side shown in FIG. 2 to deliver one or more program elements via a computer network (referred to herein as "broadband" and "over-the-top" (OTT)) and wireless broadcast (referred to herein as "broadcast" and "over-the-air" (OTA)), i.e., a hybrid service delivery can be transmitted. FIG. 2 also shows an exemplary stack including hardware that can be implemented by a receiver.

[0030] Disclosed from the perspective of the broadcast station equipment 10 in FIG. 2, 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 in the topmost application layer 204. The application layer 204 can include one or more software applications operating in a runtime environment, for example, written in HTML5 / Javascript. Without limitation, the applications in the application stack 204 can include a linear TV application, an interactive service application, a companion screen application, a personalized application, an emergency alert application, and a usage report application. Usually, the application is embodied in software representing elements experienced by the viewer, including video coding, audio coding, and a runtime environment. As an example, an application can be provided that enables control of dialogs by the user, use of alternative audio tracks, and control of audio parameters such as normalization and dynamic range.

[0031] Below the application layer 204 is the presentation layer 206. The presentation layer 206 includes, on the broadcast (OTA) side, a broadcast audio / video playback device called a media processing unit (MPU) 208 that decodes audio / video content broadcast wirelessly when implemented in a receiver and plays it on one or more displays and speakers. The MPU 208 is configured to present International Organization for Standardization (ISO) base media file format (BMFF) data representations 210 and high efficiency video coding (HEVC) video, for example, with audio in the Dolby Audio Compression (AC)-4 format. The ISO BMFF is a general file structure for time-based media files that are split into "segments" and presentation metadata. Basically, each file is a group of nested objects, each with a type and length. The MPU 208 can access a broadcast-side encrypted media extension (EME) / common encryption (CENC) module 212 to facilitate decryption.

[0032] Figure 2 further shows that, on the broadcast side, the presentation layer 206 can include a signaling module that includes either a Moving Picture Experts Group (MPEG) media transfer (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. The NRT content can include, but is not limited to, stored alternative advertisements.

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

[0034] The broadband side of the presentation layer 206 can include, similar to the broadcast side, NRT content in a file 226 and a signaling object 228 that provides playback signaling.

[0035] Below the presentation layer 206 in the protocol stack is the session layer 230. The session layer 230 includes either the MMT protocol 232 or the ROUTE protocol 234 on the broadcast side. Note that the ATSC standard provides the option of using MPEG MMT for transmission, which is not shown here.

[0036] The session layer 230 includes the 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 construct a basic service list and provide bootstrap discovery of broadcast content. The "ROUTE Signaling" table includes a Media Presentation Description (MPD) delivered via the User Datagram Protocol (UDP) by the ROUTE transport protocol.

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

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

[0039] Below the network layer 248, there is a physical layer 250 that includes a broadcast transmission / reception facility 252 and a (single / multiple) computer network interface 254 for communicating on the respective physical media related to both sides. The physical layer 250 can include modulation and demodulation modules to convert Internet Protocol (IP) packets for transmission on the related media, add a forward error correction function to enable error correction at the receiver, and incorporate modulation and demodulation functions. The physical layer 250 converts bits to symbols for long-distance transmission and bandwidth efficiency improvement. The physical layer 250 typically includes a wireless broadcast transmitter that uses orthogonal frequency division multiplexing (OFDM) to broadcast data wirelessly on the OTA side and a computer transmission component that transmits data via the Internet on the OTT side.

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

[0041] Generally, each receiver 14 includes a protocol stack that is complementary to the protocol stack of the broadcast station equipment.

[0042] The receiver 14 of FIG. 1 can 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. The receiver 14 can be an Android (registered trademark) - based system. Alternatively, the receiver 14 can also be implemented by a computerized Internet - enabled (“smart”) telephone, a tablet computer, a notebook computer, and a wearable computer device, etc. Nevertheless, the receiver 14 and / or other computers described herein are to be understood as being configured to implement the present principles (e.g., communicate with other devices to implement the present principles, execute the logic described herein, and execute any of the other functions and / or operations described herein).

[0043] Therefore, in order to implement such a principle, the receiver 14 can be established by some or all of the components shown in FIG. 1. For example, the receiver 14 can be implemented by a high-definition or ultra-high-definition "4K" or higher flat screen, and can or cannot be a touch-responsive type that receives user input signals via touch on the display, and can include one or more displays 258. The receiver 14 can also include one or more speakers 260 for outputting audio according to this principle, and at least one additional input device 262, such as an audio receiver / microphone, for inputting audible commands for controlling the receiver 14 into the receiver 14. Examples of the receiver 14 can further include one or more network interfaces 264 for communicating via at least one network such as the Internet, WAN, LAN, PAN, etc. under the control of one or more processors 266. Therefore, the interface 264 can be, for example, a Wi-Fi transceiver, which is an example of a wireless computer network interface such as a mesh network transceiver. The interface 264 can be, but is not limited to, a Bluetooth (registered trademark) transceiver, a Zigbee (registered trademark) 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). The processor 266 is understood to control the receiver 14 to implement this principle, including other elements of the receiver 14 described in this specification, such as controlling the display 258 to present images and receive inputs. Further, the network interface 264 can be, for example, a wired or wireless modem or router, or other suitable interfaces such as a wireless phone transceiver or the Wi-Fi transceiver described above.

[0044] In addition to the above, the receiver 14 may include one or more input ports 268, such as a high-definition multimedia interface (HDMI (registered trademark)) 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 the receiver 14 to present audio to the user through the headphones from the receiver 14. For example, the input port 268 can be connected to a cable or satellite source of audio-video content via wired or wireless means. Thus, the source can be a standalone or integrated set-top box or satellite receiver. Alternatively, the source can also be a game console or a disc player.

[0045] In some cases, the receiver 14 can further include one or more computer memories 270, such as disk-based storage or solid-state storage, which are not temporary signals, embodied as a standalone device within the chassis of the receiver, as a personal video recorder (PVR) or video disc player for playing audio-video (AV) programs inside or outside the chassis of the receiver, or as a removable storage medium. Also, in some embodiments, the receiver 14 is configured to receive geographical location information from, for example, at least one satellite or cellular phone tower and provide this information to the processor 266, and / or the receiver 14 includes a position or location receiver 272, such as, but not limited to, a cellular phone receiver, a global positioning system (GPS) receiver, and / or an altimeter, configured to determine the altitude at which the receiver 14 is disposed together with the processor 266. However, it should be understood that other suitable position receivers other than a cellular phone receiver, a GPS receiver, and / or an altimeter can also be used in accordance with this principle to determine the position of the receiver 14 in all three dimensions, for example.

[0046] Continuing the description of the receiver 14, in some embodiments, the receiver 14 can include one or more cameras 274, such as a thermal detection camera, a digital camera such as a web camera, and / or a camera integrated with the receiver 14 and controllable by the processor 266, for collecting photos / images and / or videos according to the present principle. Also, the receiver 14 can include a Bluetooth (registered trademark) transceiver 276 or other near field communication (NFC) element for communicating with other devices using Bluetooth (registered trademark) and / or NFC technology, respectively. An example of the NFC element can be a radio frequency identification (RFID) element.

[0047] Furthermore, the receiver 14 can include one or more auxiliary sensors 278 (such as motion sensors such as an accelerometer, a gyroscope, a cyclometer or a magnetic sensor and combinations thereof) that provide inputs to the processor 266, an infrared (IR) sensor for receiving IR commands from a remote control device, an optical sensor, a speed and / or cadence sensor, a gesture sensor (for detecting gesture commands), etc. An IR sensor 280 can also be provided for receiving commands from a wireless remote control. A battery (not shown) can also be provided to power the receiver 14.

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

[0049] The methods described herein can be implemented as software instructions executed by a processor, a specially configured application specific integrated circuit (ASIC) or field programmable gate array (FPGA) module, or any other convenient method understood by those skilled in the art. The software instructions, when employed, can be embodied on a non-transitory device such as a CD ROM or a flash drive. Alternatively, the software code instructions can be embodied in a transient configuration such as a wireless signal or an optical signal, or through a download via the Internet.

[0050] Next, FIG. 3 shows a simplified digital TV system such as an ATSC 3.0 system. In FIG. 3, a mobile or fixed digital TV receiver, such as an ATSC 3.0 receiver 300 that can include some or all of the relevant components described above in connection with FIGS. 1 and 2, is disposed in a boundary region 302 between a first and a second ATSC 3.0 broadcast station or assembly 304, and signals from both broadcast stations 304 are picked up by the receiver 300 within the region 302. From the first broadcast station 304, a first ATSC 3.0 service (“Service A”) is broadcast at a first frequency 306, while from the second broadcast station 304, the same Service A or an equivalent Service B is broadcast at a second frequency 308 different from the first frequency 306. The receiver 300 picks up both frequencies, i.e., the receiver 300 picks up the signals from both broadcast stations 304.

[0051] FIG. 4 shows a non-limiting exemplary embodiment of a digital TV receiver, such as an ATSC 3.0 receiver 400, that can include some or all of the relevant components described above in connection with FIGS. 1 and 2. In the illustrated example, the ATSC 3.0 receiver 400 can be a fixed receiver, such as a receiver disposed within a home, for example. In some examples, the ATSC 3.0 receiver 400 can be a mobile receiver, such as one implemented in a cellular phone or disposed within a moving vehicle.

[0052] The exemplary ATSC 3.0 receiver 400 shown in FIG. 4 includes a tuner 402 that sends signals 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.

[0053] In contrast, FIG. 5 shows a non-limiting example embodiment of a digital TV receiver, such as an ATSC 3.0 receiver 500, which can include some or all of the related components described above in connection with FIGS. 1 and 2. In the illustrated example, the ATSC 3.0 receiver 500 can be a mobile receiver, such as being implemented in a mobile phone or disposed within a moving vehicle. In some examples, the ATSC 3.0 receiver 500 can be a fixed receiver, such as a receiver disposed within a home, for example.

[0054] The example ATSC 3.0 receiver 500 shown in FIG. 5 includes a plurality of 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 should be 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 should be understood that it can have more or fewer antennas. The receiver 500 can switch the antenna inputs to the tuners, and thus can perform switching to swap the antenna inputs between the tuners after the first tuner receives signals from, for example, three antennas and the second tuner receives signals from the fourth antenna. Two antennas can also provide inputs to each respective tuner. Inputs can also be provided from all four antennas to a single tuner. These and other antenna-tuner configurations can be changed on-the-fly during operation as needed. The antennas can be movable with respect to the receiver.

[0055] This specification describes RF frequency quality metrics and can identify and remember such quality metrics. Quality metrics can include, for example, error rates that can be represented by, for example, signal-to-noise ratio (SNR) and packet error number (PEN). Quality metrics can include resolution, such as whether the service is high definition (HD) or standard definition (SD). Quality metrics can also include bitrate and form factor that recognize 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 signatures are made), audio description, and other content aspects. Quality metrics can include locality preference (such as being able to recognize a preference for a first region over a second region in a duplicate service from the second region because, for example, the channels in the first region are strong but all the advertisements are for the first region and not for the second region that the user desires). Quality metrics can include the quality of the user interface handled in the service.

[0056] In a non-limiting example, during a scan, the SNR can be determined by looking at both the received signal strength at each received frequency and any accompanying noise at that frequency and finding the quotient of these. The error rate can be determined, for example, by determining the percentage of lost packets (by looking at the lost packet numbers) and / or by determining the percentage of received packets that contain errors determined by an error correction algorithm.

[0057] FIG. 6 shows logic executable by a transmitter, such as an OTA transmitter or an OTT transmitter, to transmit services at one or more frequencies, including service "A" on frequency "A" in the example of FIG. 6. 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), and also transmits ("signals") one or more overlapping services on different frequencies.

[0058] FIG. 7 shows receiver logic according to this principle. Starting from block 700, a first service transmitted from a broadcast station at a first frequency ("A") is received and presented on an AV device. Proceeding to decision state 702, the receiver determines, using, for example, one or more of the quality metrics described herein, whether an overlapping broadcast, partial broadcast, equivalent broadcast, or preferred broadcast of the first service received at 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 in block 704, performs an automatic handoff from the presentation of the first service at frequency A to the presentation of the service received at frequency B. Otherwise, the receiver continues to present the content from the first frequency (A) in block 700.

[0059] Note that in an implementation example, the condition for changing the frequency can include the first tuner completely losing the first signal (frequency). In other examples, the condition for changing the frequency can include the first signal degrading below a threshold. In yet other implementation examples, the condition for changing the frequency includes the quality of the second signal (frequency) exceeding the quality of the first signal (frequency) as described above.

[0060] Figures 8-10 illustrate various conditional techniques for broadcast station application management by the automatic service handoff of block 704 of FIG. 7. Typically, a broadcast station application (BA) is downloaded from a broadcast station by an ATSC 3.0 receiver using ROUTE / DASH or MMT to perform various functions. A broadcast station application can include a downloaded set of interrelated documents intended to be executed in an application environment to provide interactivity or perform one or more functions such as targeted advertisement insertion. The documents of the application can include, but are not limited to, HTML, JavaScript, CSS, XML, and multimedia files. The application can access other data that is not part of the application itself. A broadcast station application can be distinguished from other applications by its ability to support localized interactivity without a broadband connection. BA means the client-side functionality of a wide range of web applications that provide interactive services. This distinction is made because the broadcast station only transmits client-side documents and code.

[0061] Although state 800 is shown in a decision flow format, it is understood that the logic of the existing (pre-handoff) BA (the broadcast station application "A" in FIG. 8) can equally use the same context ID as the new (post-handoff) BA (the broadcast station application "B" in FIG. 8) when tuning from channel A to channel B as a result of an automated process to show that FIG. 8 applies to the service handoff of block 704. If this condition is not met, the logic in FIG. 8 ends at state 802. On the other hand, if the condition of state 800 is met, the logic proceeds to block 804 to notify the broadcast station application A that the service has changed. In state 806, the broadcast station application A can continue to execute without interruption during and after the service handoff to the new frequency.

[0062] Note that the context ID is a unique uniform resource identifier (URI) that is signaled in a broadcast and determines which resources the receiving - side processor provides to the associated broadcast station application. A resource can be associated with multiple application context identifiers, but a BA is associated with only a single context ID. The context ID can be further specified in the "Guidelines for Implementation: DASH - IF Interoperability Point for ATSC 3.0", which is incorporated herein by reference and is the DASH - IF HTML entry page location description (HELD) section of the DASH Industry Forum.

[0063] Figure 9 shows another condition for automatic service handoff. Figure 9 starts from state 900 and, in the second option, proceeds to block 902, or in the first option, proceeds directly to decision block 904 ( "option" means "embodiment"). In block 902, the BA associated with the first frequency A supplies and / or updates the data to be transferred to the second (alternate) BA associated with the second frequency B. The logic proceeds from block 902 of the second option or directly from the starting state 900 of the first option to block 904 and determines whether the first and second BAs having both the same application context ID and the same uniform resource list (URL) are signaled. If so, the logic ends at state 906 (basically participating in the logic of Figure 8).

[0064] 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 and notifies the first BA associated with frequency A that the frequency being tuned is changing. Proceeding to block 910, in this option, a response containing data to be transferred to the second BA, i.e., the BA for the new (second) frequency B, is received from the first BA.

[0065] The logic reaches state 912 directly from block 910 of the first option or from the negative result of the verification in decision block 904 of the second option to end the first BA and start the second BA in state 914. The application from the first BA is transferred to the second BA at block 916. Thereafter, the logic ends in state 906.

[0066] Figure 10 shows yet another condition for managing the BA during an automatic service handoff. At block 1000, during an automatic tuning from one frequency carrying a service to another frequency carrying the same service, such as may occur when a mobile receiver passes through a boundary region between two transmitters, the existing BA ( "A") on the original frequency is notified that a handoff is imminent. Proceeding to block 1002, the original BA ( "A") is notified that data must be provided to the receiver or can be provided (i.e., is mandatory or optional), and the receiver provides this data to the broadcast station application ( "B") for the second frequency at 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.

[0067] Although the principles have been described with reference to several example embodiments, these embodiments are not intended to be limiting, and it will be understood that the subject matter claimed herein can also be implemented using a variety of other configurations.

Claims

1. In a digital television in which at least one receiver can receive broadcast signals from at least first and second digital television broadcast assemblies, automatically handing off the presentation of a first digital TV service from a first frequency to a second frequency; signaling, in response to handing off the presentation, that the presentation is scheduled to be handed off or is being handed off to a first broadcast station application (BA) associated with the first frequency; selectively transmitting data associated with the first BA to a second BA associated with the second frequency; A method comprising the above.

2. Identifying whether a context ID associated with the first BA is the same as a context ID associated with the second BA, The method according to claim 1.

3. Continuing to execute the first BA throughout the period during which the presentation of the first digital TV service is automatically handed off from the first frequency to the second frequency in response to the context IDs of the first and second BAs being the same, The method according to claim 2.

4. The first BA is associated with a first uniform resource locator (URL), 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 BAs being the same, The method according to claim 2.

5. The first BA is associated with a first uniform resource locator (URL), the second BA is associated with a second URL, and the method includes transmitting data associated with the first BA to the second BA and executing the second BA to present the first digital TV service in response to the context IDs of the first and second BAs being the same, The method according to claim 2.

6. 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 regardless of whether the first and second BAs have a common uniform resource locator (URL), The method according to claim 1.

7. Automatically handing off the presentation of the first digital TV service from the first frequency to the second frequency in response to the loss of the first frequency. The method according to claim 1. **Claim 8** Automatically handing off the presentation of the first digital TV service from the first frequency to the second frequency in response to degradation of the first frequency. The method according to claim 1. **Claim 9** Automatically handing off the presentation of the first digital TV service from the first frequency to the second frequency in response to the quality of the second frequency exceeding the quality of the first frequency. The method according to claim 1. **Claim 10** An apparatus comprising at least one receiver, the at least one receiver Receives a first digital television (DTV) service at a first frequency, Presents the first DTV service on at least one audio-video display device, Receives the first DTV service at a second frequency, Switches from the presentation of the first DTV service received at the first frequency to the presentation of the first DTV service received at the second frequency in response to at least one handoff condition being met, Signals the switch to a first broadcast station application (BA) associated with the first frequency, Selectively transmits data associated with the first BA to a second BA associated with the second frequency. Is configured as An apparatus characterized by that. **Claim 11** 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. The apparatus according to claim 10. **Claim 12** The receiver is configured to continue executing the first BA throughout the period during which the presentation of the first DTV service is automatically handed off from the first frequency to the second frequency in response to the context IDs of the first and second BAs being the same. The apparatus according to claim 11. **Claim 13** The first BA is associated with a first Uniform Resource Locator (URL), 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 IDs of the first and second BAs being the same. The apparatus according to claim 11.

14. The first BA is associated with a first Uniform Resource Locator (URL), the second BA is associated with a second URL, and the receiver is configured to transmit data associated with the first BA to the second BA in response to the context IDs of the first and second BAs being the same, and to execute the second BA to present the first DTV service. The apparatus according to claim 11.

15. An apparatus comprising at least one receiver, wherein the at least one receiver receives a first digital television (DTV) service at a first frequency, presents the first DTV service on at least one audio-video display device, receives the first DTV service at a second frequency, switches from presenting the first DTV service received at the first frequency to presenting the first DTV service received at the second frequency in response to at least one handoff condition being met, signals the switch to a first broadcast station application (BA) associated with the first frequency, and is configured to transmit data associated with the first BA to the second BA in response to handoff of the presentation, regardless of whether the context ID of the first BA is the same as the context ID of a second BA associated with the second frequency and whether the first and second BAs have a common Uniform Resource Locator (URL). An apparatus characterized by the above.

16. An apparatus comprising at least one receiver including at least one processor programmed with instructions, the instructions causing the processor to execute a first broadcast station application (BA) that presents a first service received at a first frequency, including at least one digital television service, on at least one audio-video (AV) display device. automatically switch the presentation of the first service received at the first frequency to the presentation of the first service received at a second frequency associated with a second BA, signal the first BA about the switch, and be configured to, characterized by the apparatus.

17. The instruction is executable to selectively transmit data associated with the first BA to the second BA. The apparatus according to claim 16.

18. The first BA is associated with a first uniform resource locator (URL), the second BA is associated with a second URL, and the instruction is executable to switch the first BA from the first URL to the second URL in response to the context IDs of the first and second BAs being the same. The apparatus according to claim 16.

19. The first BA is associated with a first uniform resource locator (URL), the second BA is associated with a second URL, and the instruction is executable to transmit data associated with the first BA to the second BA and execute the second BA to present the first service in response to the context IDs of the first and second BAs being the same. The apparatus according to claim 16.

Images