Obfuscation of Replaceable Content in the Advanced Television Systems Committee (ATSC) 3.0 System

Abstract

Describe a technique for hiding aspects of the RC of the Advanced Television Systems Committee (ATSC) 3.0 television protocol in order to robustly deliver next-generation broadcast television services. In this way, the skip strategy can be blocked by delivering (304) the information necessary for RC playback immediately before the occurrence of the insertion.

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 data services such as television broadcast media, two-way services, non-real-time data delivery, and tailored advertising for numerous receivers from ultra-high-definition televisions to wireless phones. ATSC 3.0 also consolidates the coordination between broadcast content (referred to as "Over the Air") and related broadband delivery content and services (referred to as "Over the Top"). The term "service" as used herein is defined in ATSC 3.0 as the entire group of media components presented to the user, and the components can be of multiple media types. A service can be continuous or intermittent. A service can be real-time or non-real-time, and a real-time service consists of a series of TV programs. 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. This principle relates to advancements as shown below.

Summary of the Invention

Means for Solving the Problems

[0003] This principle relates to obfuscating the start time and duration of ATSC 3.0 advertisements to prevent a receiver from adopting an advertisement skipping strategy that is inconvenient for the business model of the broadcasting station.

[0004] As understood herein, ATSC 3.0 can provide television content using Dynamic Adaptive Streaming over HyperText Transfer Protocol (HTTP) (DASH) as described in the international standard ISO / IEC 23009-1 that defines a Media Presentation Description (MPD). ATSC 3.0 is defined to use two types of dynamic live MPDs to facilitate content that is encoded and delivered in real time, and also to enable some content to be replaced with replacement content (RC) tailored to a particular user. The first type of dynamic live MPD uses a segment naming convention based on a segment template and an incremental numbering scheme, which may or may not need to be continuously updated during content playback, and requires a clock on the receiver synchronized to the broadcast to correctly infer the number, and thus the name, of the available segments present at the so-called "live edge" of the encoded stream. The segment numbering template type of the dynamic live MPD is suitable for content delivered over-the-air (OTA), and the decoder clock can also be maintained in a standby state synchronized to the OTA broadcast clock.

[0005] The second type of dynamic live MPD explicitly includes the presentation timestamp (PTS) of the segment start time in the segment name using a segment time template and lists only segments that are playable on the receiver. The second type of dynamic live MPD is particularly suitable for segments delivered live over-the-top (OTT) when a synchronized broadcast clock is not available or when the duration of the segment varies due to live encoding of the segment and is not well-known in advance. The segment time line is represented in the SegmentTimeline element of the DASH MPD. Unlike the index mode of the segment number template, the segments explicitly defined within the dynamic live segment time template must always be available to the receiver, and thus the last segment in the list is known to be the live edge that does not require clock synchronization. Therefore, this second type of dynamic live MPD addresses the issues when the receiver clock is not synchronized with the broadcaster clock for technical reasons (or not synchronizable) and especially when the segments in the stream are delivered over-the-top without being exactly synchronized with the clock in the broadcast channel. A receiver that first tunes to a specific channel can immediately start playback therefrom by simply extracting the live edge from the information in the MPD.

[0006] Accordingly, in one aspect, a digital television system, such as an Advanced Television Systems Committee (ATSC) 3.0 system, includes at least one receiver of digital television content having segment timeline signaling. The broadcast stream includes periods of replaceable content but is initially configured to use a segment timeline-based MPD that does not include information regarding a start time at which the content needs to be played, an indication of the duration of the content to be replaced, or an indication of when the content is to be replaced. In the ATSC 3.0 system, a broadcast station application (app) can be received and initiated that extracts metadata within the stream through a mechanism defined in ATSC 3.0 and distributes the metadata to the app. Typically, the metadata is obfuscated in a scheme known only to the app. The app can interpret from the metadata what the start time and duration are, and can know the time suitable for instructing the receiver to download and cache the RC, and the time suitable for the receiver to prepare an MPD period during which the RC can be played. Typically, this last step is just prior to the start time of playing the RC.

[0007] In an implementation example, the instructions can be executable to receive information in a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH) Media Presentation Description (MPD) segment timeline time-based data structure. Information regarding the RC can be received within an Early Available Period (EAP) described in ISO / IEC 23009-1 (DASH) that includes only Extensible Markup Language (XML) Linking Language (XLink) metadata and does not include the content, the duration of the content, and / or the start time. In such a case, the broadcast station app can utilize a computer network to interpret the metadata to receive the start time and content duration required to replace the content at a future point in time.

[0008] Alternatively, the information regarding the RC can be received within the Early Availability Period (EAP) in a form that only contains XLink and no content, and can only be read by the broadcast station app, and includes the start time and / or the length of the content. In such a case, the instruction can be executable to cause the receiving app to receive the start time and the length of the content from the broadcast station app in an unencrypted form at the receiving app, and configure the receiving app to play the RC at the start time.

[0009] Furthermore, the instruction can also be executable to receive the instruction of the start time and / or the content duration in an event stream notification included in the DASH period before the EAP including the XLink.

[0010] In some examples, multiple Early Availability Periods (EAPs) each containing an XLink related to the respective duration of the content to be replaced. The instruction can be executable to select an EAP including the XLink related to the duration of the RC in response to receiving the instruction of the start time.

[0011] In another aspect, a digital television system includes at least one source of broadcast digital television content and at least one processor configured with instructions executable to transmit information to at least one receiver in a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH) media presentation description (MPD) segment timeline data structure. The information is related to replacement content (RC) and does not include a start time for playing the RC and / or a duration of the content to be replaced, or includes the start time and / or duration in a form that can only be read by a broadcast application (app) provided by a digital television broadcast station so that the receiver can use this information to prepare for inserting the RC and play the RC by receiving an instruction of the start time after the preparation for inserting the RC. The digital television logic can select replaceable content by itself (client-side content exchange) or enable selection by the broadcast station application (server-side content exchange).

[0012] In another aspect, in a digital television system, a method includes receiving information related to replacement content (RC), the information not including a start time for playing the RC or a duration of the content to be replaced, or including the start time and duration in a form that can only be read by a broadcast application (app) provided by a digital television broadcast station. The method includes using this information to prepare for inserting the RC and receiving an unencrypted instruction of the start time after receiving the information related to the RC. The RC is played at the start time.

[0013] The details of the present application, regarding both its structure and operation, can be best understood by referring to the accompanying drawings, in which like elements are denoted by like reference numerals.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Best Mode for Carrying Out the Invention

[0015] This disclosure relates to the technological advancements of Advanced Television Systems Committee (ATSC) 3.0 television. The systems 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. The client components can include one or more computer devices such as televisions (e.g., smart TVs, Internet-enabled TVs), personal computers such as laptop and tablet computers, and mobile devices such as smartphones and further examples to be described later. These client devices can operate in various operating environments. For example, some of the client computers can employ an operating system such as the operating system of Microsoft Corporation as an example, or a Unix operating system, or an operating system such as 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 that can access websites hosted by Internet servers to be described later.

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

[0017] Between the client and the server, information can be exchanged 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 to enhance authenticity and security.

[0018] 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 step that the components of the system undertake.

[0019] The processor can be a conventional general-purpose 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.

[0020] The software modules described 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. The flowchart format can be used, but it should be understood that the software can also be implemented as a state machine or other logical method.

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

[0022] In addition to what has been 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 of these designed to perform the functions described herein. The processor can be implemented by a controller, a state machine, or a combination of computer devices.

[0023] 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 disk storage such as digital versatile disc (DVD), magnetic disk storage, or other magnetic storage devices including removable thumb drives. A certain connection can construct a computer-readable medium. Such connections can include, for example, wired cables including optical fiber, coaxial cable, digital subscriber line (DSL), and twisted pair wire.

[0024] 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.

[0025] "A system having at least one of A, B, and C (similarly, "a system having at least one of A, B, or C", and "a system having at least one of A, B, C")" includes systems having 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.

[0026] Referring to FIG. 1, an example of an ATSC 3.0 source component denoted as "broadcast station equipment" 10 can 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) typically 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.

[0027] 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 equipment 12, 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 OTA via a tuned ATSC 3.0 television service, or can also receive related content including the television via an OTT (broadband) path. 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.

[0028] Next, referring to FIG. 2, the details of the components shown in FIG. 1 can be seen. FIG. 2 shows a protocol stack that can be implemented by a combination of hardware and software. As will be described later, the broadcast station can use 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)), and can transmit a hybrid service delivery.

[0029] The broadcast station facility 10 can include one or more processors 200 that access one or more computer storage media 202, such as any memory or storage described herein, to provide one or more software applications in the topmost application layer 204. The application layer 204 can include one or more software applications that operate in a runtime environment and are written in, for example, HTML5 / Javascript. Without limitation, the applications of 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 that represents elements experienced by the viewer, including video coding, audio coding, and the 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.

[0030] 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)-based Media File Format (BMFF) data representations 210 and High Efficiency Video Coding (HEVC) video in, for example, Dolby Audio Compression (AC)-4 format audio. 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.

[0031] 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 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 replacement advertisements.

[0032] On the broadband (OTT or computer network) side, when 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 back audio / 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.

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

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

[0035] 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.

[0036] 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.

[0037] The protocol stack 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. Multicast delivery is typical on the broadcast side, and unicast is typical on the broadband side.

[0038] 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 the mechanical access code (MAC) format to suit 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 usually includes a wireless broadcast transmitter that broadcasts data wirelessly using orthogonal frequency division multiplexing (OFDM) on the OTA side and a computer transmission component that transmits data via the Internet on the OTT side.

[0039] 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 in 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.

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

[0041] The receiver 14 of FIG. 1 can include an Internet-capable TV having an ATSC 3.0 TV tuner 256 (equivalent to a set-top box that provides audio-visual display to a TV monitor) as shown in FIG. 2. The software architecture within the receiver 14 can be based on the Android® operating system. Alternatively, the receiver 14 can also be implemented by a computerized Internet-capable (“smart”) telephone, a tablet computer, a notebook computer, and a wearable computer device, etc. Nevertheless, it should be understood that the receiver 14 and / or other computers described herein are 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).

[0042] Accordingly, to implement such a principle, the receiver 14 can be constructed 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 touches 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 an audible command 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. Accordingly, the interface 264 can be, by way of example and not limitation, 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, by way of example and not limitation, 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). The processor 266 is understood to control the receiver 14 to implement this principle, including other elements of the receiver 14 described herein, such as controlling the display 258 to present images and receive inputs. Further, the network interface 264 can be other suitable interfaces, such as a wired or wireless modem or router, or a wireless phone transceiver or the Wi-Fi transceiver described above.

[0043] 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.

[0044] In some cases, the receiver 14 may further include one or more computer memories 270, such as disk-based storage or solid-state storage, which are not temporary signals and are embodied as a standalone device within the receiver chassis, as a personal video recorder (PVR) or video disc player for playing audio-video (AV) programs inside or outside the receiver chassis, or as a removable storage medium. Also, in some embodiments, the receiver 14 may be 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 may include 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, which is 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.

[0045] 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) elements for communicating with other devices using Bluetooth (registered trademark) and / or NFC technology, respectively. An example of an NFC element can be a radio frequency identification (RFID) element.

[0046] Furthermore, the receiver 14 can also 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) for providing an input 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 for powering the receiver 14.

[0047] The companion device 16 can include some or all of the elements shown in connection with the receiver 14 described above.

[0048] The methods described herein can be implemented as software instructions executed by a processor, a specially configured application specific integrated circuit (ASIC), or a field programmable gate array (FPGA) module, or any other convenient means understood by one of ordinary skill in the art. The software instructions, if 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 or optical signal, or downloaded via the Internet.

[0049] Before proceeding to FIG. 3, in ATSC 3.0, MPEG DASH is used for transmitting AV content, and this content can include replacement content (RC) such as advertisements, or content intended for user personalized replacement. (As described in ATSC A / 344) ATSC 3.0 uses multi - periods including XLink tags to signal the position of such RC. However, as understood herein, this may cause the position of RC that can be easily skipped by the client to be known in advance, which is inconvenient for the broadcaster's business model. This principle can utilize the segment timeline element of the MPEG DASH MPD that distributes just - in - time (JIT) information in the DASH manifest file (the MPD is updated for each additional segment). The JIT information prevents advanced knowledge of new periods until the very last moment and eliminates naive RC replacement strategies by "malicious" receivers. XLink is an early notification that tells the broadcaster application (an application supplied by the broadcaster and operating on the HTML5 service of the client receiver) that the application needs to call the client receiver to cache the content and prepare to replace the existing content. Since XLink is associated with the period to be replaced, if XLink included in the clear the RC start time and / or duration of the content to be replaced, it might be possible to skip due to advanced knowledge of XLink.

[0050] To address this, an XL link can be sent during an early period that has no start time, as further explained below. In DASH, this period is known as the Early Availability Period (EAP); see ISO / IEC 23009-1. The EAP can have metadata within a Period tag, but it has no start time or duration of the content to be replaced, or at least not in plain text, i.e., in an unencrypted or non-obfuscated form. Thus, using the segment timeline, it is only necessary to reveal the start time of the EAP just-in-time (including the most recent MPD update), so there is insufficient time to implement a strategy of skipping the RC. The XL link itself can be revealed at any time using the EAP to allow for the content replacement preparation time.

[0051] Next, refer to Figure 3. Starting from block 300, information about replacement content (RC), such as a replacement ad tailored to a specific user of a specific receiver, is transmitted from the broadcast station well before the time when the receiver stores it. This replacement content can also be made available (within a cached ad replacement system) well before the time when the receiver fetches it. In an example embodiment, this information can include an XL link. However, this information does not include the start time and duration of the RC of the content to be replaced, and at least not an unencrypted or non-obfuscated version of the start time.

[0052] Proceed to block 302 and, at block 304, input a waiting period (or a trigger from a program guide or broadcast studio equipment) for components of receivers other than the broadcast station application such that the start time becomes clear immediately before the start time of RC. Generally, the start time can be made clear a few milliseconds or seconds before the start time so that the start time becomes clear some time after the information regarding RC becomes clear and there is insufficient time for a compromised receiver to execute a skip strategy. The start time and / or duration of the content to be replaced can be made clear by transmitting the start time / duration to the receiver outside the band, or by other techniques described herein, or the start time / duration can be made clear by the broadcast station application receiving the start time / duration in an encrypted or otherwise obfuscated form with XLink and simply not providing the clear text indication of the start time / duration to the remaining components of the receiver until immediately before the start time.

[0053] A specific method is shown in FIG. 4. Starting from block 400, transmit one or more EAPs along with respective XLinks including the encrypted start time of the content to be replaced and, if necessary, the encrypted duration. At block 402, provide the XLink to the components necessary for the receiver to resolve the XLink, but without providing the start time / duration in preparation for RC insertion. At block 404, the broadcast station application can decrypt the start time but does not share this with other components of the receiver. At block 405, the broadcast station application can command the receiver to cache the content OTA, or fetch and cache it from OTT, or otherwise make the content available from the OTT server without caching, and then pass on a command to replace the period including this XLink at an appropriate time to prepare for content replacement. At block 406, the broadcast station makes the start time of RC clear to the receiver within a new playback period thereafter. At block 407, the receiver replaces this period with an RC period if it has been pre - commanded to do so.

[0054] Block 408 indicates that multiple EAPs can be used, and each EAP has a unique duration that only the broadcast station application can know by decrypting the XLinks. In other words, by signaling multiple EAPs in the DASH manifest file, each having its own XLink and enabling caching of different types or durations of RC, the broadcast station can be enabled to select in JIT which EAP to add subsequent over-the-air AV segments to according to the content that ultimately needs to be replaced. When this selection matches the cached replacement content notified by the xlink, the receiver replaces it at this point.

[0055] Block 410 indicates that it is played by the receiver at the start time regardless of whether the RC period is the original one or a replaced one.

[0056] Another method is shown in FIG. 5. Some or all of the RC information including the type duration and start time indication is carried in the event stream notification and sent to the receiver. Details of the DASH event stream notification can be found in ATSC A / 344. The event stream notification is added to the current playback period to signal (using the ATSC 3.0 signaling method) the broadcast station application about the type and duration of the replaceable content that is due to appear soon. After being notified of this information, the broadcast station application can cache the RC at block 502. The client receiver is allowed to play the RC at the start time at block 506 without knowing until JIT at block 504 when the replacement start time will occur.

[0057] FIG. 6 shows a segment timeline period 600 including a start time 602 without data. Period 600 contains only metadata such as XLink and no content. Period 600 can also omit the duration of the content to be replaced.

[0058] On the one hand, FIG. 7 shows a segment timeline period 700 that includes an encrypted start time 702. Period 700 contains only metadata such as XLink and does not contain content. Period 700 can also contain, in encrypted form, the duration of the content to be replaced.

[0059] Since the DASH manifest needs to be refreshed continuously and at appropriate times, the segment timeline is ideal for concealing content. The segment timeline places a heavy burden on the recording and playback of client receivers, which is a technology that also enables pausing of live TV. Pausing and recording are ways that can enable the client to have more advanced knowledge of the content, but the segment timeline burdens this.

[0060] The technology described herein can be implemented through ATSC 3.0 and, optionally, DASH IOP. Client implementation can require that the client receiver support EAP from the MPEG DASH main standard in segment timeline mode.

[0061] Below, a more detailed multi-period segment timeline DASH manifest file is described, showing an EAP that includes xlink metadata intended to be interpretable only by the broadcaster app. The receiver is expected to notify the broadcaster app of this xlink at the first occurrence of the xlink, as a result of which the broadcaster app decides what to do, whether to cache OTT, cache OTA, prepare for live OTT replacement, or not replace anything. Then, the broadcaster app executes a caching operation as needed and instructs the receiver to prepare for period replacement. TIFF2025522452000002.tif240170

[0062] Next, an explanation is given of a multi-period dynamic MPD that replaces an empty period with a non-empty period containing the latest segment delivered OTA along the start time of this period. The broadcast station app can instruct the receiver to replace this period with an alternative period for the replaceable content. Receivers not instructed to replace the period continue playback into this period as normal. As the latest "live" segment is added to the second period, old segments disappear from the first period. Since the receiver has been informed about the xLink for RC in the past, pre-instructed to replace this period, and now knows the start time within the period that is currently being used for playback of replaceable content, the MPD is edited on the receiver so that the replaced content is surely played back instead of the segment being delivered OTA. In a third MPD among these, another multi-period with period id p14 becomes a new period where the broadcast station starts adding. Period ids p13 and p14 have start times, and the difference between them determines the duration of p13 that should exactly match the content replaced for seamless playback. To ensure this match, the duration can be encoded within the xLink so that the broadcast station app can interpret it, or the broadcast station app can contact the OTT server to obtain the duration. TIFF2025522452000003.tif249170 TIFF2025522452000004.tif152170

[0063] The period containing replaceable content elapses, and at this point, a new non-replaceable period appears at the live point. TIFF2025522452000005.tif248170 TIFF2025522452000006.tif154169

[0064] 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 be implemented using a variety of other configurations.

Explanation of Signs

[0065] 300 Transmit replacement content information 302 Wait until just before starting 304 Specify start time 306 Playback

Claims

1. A digital television system, comprising: at least one receiver for digital television content having segment time line signaling, said receiver being programmed with instructions that: receive information regarding replacement content (RC), information that does not include a start time for playing said RC, or information that includes the start time in a form that can only be read by a broadcast application (app) provided by a digital television broadcast station; receive an indication of the start time immediately before the start time; play said RC at the start time; configure said receiver to do so; A system characterized by this.

2. The instructions are: executable to receive said information in a dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) media presentation description (MPD) segment time line time-based data structure; The system according to claim 1, which is executable as described above.

3. Said information is received within an early available period (EAP) that includes only metadata and does not include the start time or duration of the content or the content to be replaced. The system according to claim 2.

4. The instructions are executable to receive an indication of the start time from a computer network. The system according to claim 3.

5. Said information is received within an early available period (EAP) that includes only metadata and does not include content, and includes an indication of the start time in a form that can only be read by said broadcast station app. The system according to claim 2.

6. The instructions are executable to receive at least an indication of the start time in an unencrypted form from the broadcast station app at the receiver app and configure the receiver app to play said RC at the start time. The system according to claim 5.

7. The instructions are executable to receive an indication of the start time in an event stream notification included in a DASH period. The system according to claim 1.

8. The instructions are: receive a plurality of early available periods (EAPs), each of which is related to a respective extensible markup language (XML) linking language (XLink), and each XLink is related to a respective duration. Selecting the EAP including XLInk related to the duration of the RC The system according to claim 2, which is executable as such. **Claim 9** A digital television system, comprising at least one source of broadcast digital television content, and at least one processor configured with instructions, wherein the instructions are information regarding replacement content (RC), information not including a start time for playing the RC, or information including the start time in a form that can only be read by a broadcast application (app) provided by a digital television broadcast station, such that at least one receiver uses the information to prepare for insertion of the RC and can play the RC by receiving an indication of the start time after preparation for insertion of the RC, and transmits the information to the receiver in a dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) media presentation description (MPD) segment timeline time-based data structure. being executable as such A digital television system, characterized by the above. **Claim 10** The information is transmitted within an early availability period (EAP) that includes only metadata and does not include content or a start time. The digital television system according to claim 9. **Claim 11** The instructions are executable to transmit an indication of the start time to the receiver using a computer network. The digital television system according to claim 10. **Claim 12** The information is transmitted within an early availability period (EAP) that includes only metadata and does not include content, and includes the start time in a form that can only be read by a broadcast station app in the receiver. The digital television system according to claim 9. **Claim 13** The instructions are executable to transmit an indication of the start time in an event stream notification included in a DASH period. The digital television system according to claim 9. **Claim 14** The instructions are to transmit a plurality of early availability periods (EAPs) to the receiver, each related to a respective extensible markup language (XML) linking language (XLink), and each XLink related to a respective duration. transmitting an instruction of length to the receiver so that the receiver can select the EAP including XLInk related to the duration of the RC The digital television system according to claim 9, which is executable as described above.

15. In a digital television system receiving information regarding replacement content (RC), which does not include the start time for playing the RC or includes the start time in a form that can only be read by a broadcast application (app) provided by a digital television broadcast station receiving the start time after receiving the information regarding the RC playing the RC at the start time A method characterized by including the above.

16. receiving the information in a dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) media presentation description (MPD) segment timeline time-based data structure The method according to claim 15.

17. receiving the information within an early available period (EAP) that only includes metadata and does not include content or an instruction of the start time The method according to claim 16.

18. receiving an instruction of the start time from a computer network The method according to claim 17.

19. receiving the information within an early available period (EAP) that only includes metadata and does not include content, and includes the start time in a form that can only be read by the broadcast station app receiving the start time in an unencrypted form from the broadcast station app in a receiver app, and configuring the receiver app to play the RC at the start time The method according to claim 16, including the above.

20. receiving an instruction of the start time in an event stream notification included in a DASH period The method according to claim 16.

Images