KR102004006B1 - Extensions to trigger parameters table for interactive television - Google Patents

Abstract

A method, a computer program, a receiving apparatus, and an information providing apparatus are disclosed. The method includes receiving content from a content source and displaying the received content on a display. The first trigger is extracted from the closed caption data associated with the received content. The receiving apparatus searches the trigger parameters table (TPT) based on the extracted first trigger. The TPT includes at least one event associated with one or a combination of a first media time of the received content and a trigger identifier and is stored in the memory of the receiving device. In addition, the receiving device processes the event based on one or a combination of the second triggers including the first media time and the trigger identifier equal to the current media time of the received content.

Description

[0001] EXTENSIONS TO TRIGGER PARAMETERS TABLE FOR INTERACTIVE TELEVISION FOR INTERACTIVE TELEVISION [0002]

Cross-reference to related application

This application claims priority to U.S. Provisional Application No. 61 / 509,679, filed July 20, 2011, under 35 U.S.C. §119 (e), which is incorporated herein by reference in its entirety. This application is also related to U.S. Provisional Application No. 61 / 531,360, filed September 6, 2011; U.S. Provisional Application No. 61 / 613,869, filed March 21, 2012; U.S. Provisional Application No. 61 / 613,880, filed March 21, 2012; And U.S. Provisional Application No. 61 / 636,488, filed on April 20, 2012, and claims priority under 35 U.S.C. §119 (e), which is incorporated herein by reference in its entirety. This application is also related to U.S. Serial No. 13 / 490,216, filed June 6, 2012, the full text of which is incorporated herein by reference.

The embodiments described herein generally relate to a method, a computer program, a receiving apparatus, and an information providing apparatus for trigger compaction. More specifically, the embodiments described herein relate generally to trigger compaction and trigger parameters table (TPT).

background

Modern television and set-top boxes can perform a number of functions in addition to receiving and presenting television broadcasts. Some of the features include a display of an electronic programming guide (EPG), a widget that allows a television viewer to pull up a web page and tools alongside the right side of the program being watched on the television . Many of these functions require the television or set-top box to receive additional data. For example, in the case of an EPG, a television or set-top box would need to receive program information.

In some cases, additional data is provided with the television broadcast. When additional data is provided in this manner, the amount of data that can be provided is often limited. As a result, it may be necessary to reduce the amount of additional data provided with the television broadcast or to obtain additional data from another source.

According to an embodiment of the present invention, a method of a receiving apparatus for processing triggers is provided. The method includes receiving content from a content source and displaying the received content on a display. The first trigger is extracted from the closed caption data associated with the received content. The receiving apparatus searches the trigger parameters table (TPT) based on the extracted first trigger. The TPT includes at least one event associated with one or a combination of a first media time of the received content and a trigger identifier and is stored in the memory of the receiving device. In addition, the receiving device processes the event based on one or a combination of the second triggers including the first media time and the trigger identifier equal to the current media time of the received content.

There is also provided, in accordance with an embodiment of the present invention, a computer readable storage medium having stored thereon instructions for causing a computer to perform a method of a receiving apparatus as described above, when executed by a computer.

According to an embodiment of the present invention, a receiving apparatus is provided. The receiving apparatus includes a receiver, a display interface, an extracting unit, and a processor. The receiver is configured to receive content from a content source. The display interface is configured to display the received content. The extraction unit is configured to extract a first trigger from the closed caption data associated with the received content. The processor is configured to retrieve a trigger parameter table (TPT) based on the extracted first trigger. The TPT includes at least one event associated with one or a combination of a first media time and a trigger identifier of the received content. The processor is further configured to store the TPT in the memory of the receiving device and process the event based on one or a combination of the second triggers including a first media time and a trigger identifier equal to the current media time of the received content .

According to the embodiment of the present invention, an information providing apparatus including a memory and a communication unit is provided. The memory is configured to store a trigger parameter table (TPT). The TPT includes at least one event associated with one or a combination of media time and trigger identifier of the content to be provided to the receiving device. The communication unit is configured to provide the TPT to the receiving device. The TPT is provided at the location identified in the trigger included in the closed caption data associated with the content provided to the receiving device.

A more complete understanding of the present invention and many other attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description taken in conjunction with the accompanying drawings.
1 illustrates an example including a content source, a receiving device, a trigger parameters table (TPT) server, a triggered declarative object (TDO) server, and an automatic content recognition (ACR) Broadcast system;
2 is a block diagram of an exemplary receiving apparatus;
3 is a processor-centric block diagram of an exemplary receiving device;
4A shows a flow diagram of an exemplary method for processing a trigger;
4B shows a flow diagram of an exemplary method for processing a trigger when an entire transport stream (TS) is available;
4C shows a flow diagram of an exemplary method for processing triggers when Internet access is available;
Figure 5 shows a more detailed flow diagram of an exemplary method of a Declarative Object (DO) engine for processing triggers;
6A shows an exemplary trigger timing of the pre-generated content;
6B shows an exemplary trigger timing for live content;
Figures 6C and 6D show an exemplary trigger and associated TPT;
7 is a block diagram of an exemplary information providing apparatus;
8 is an exemplary computer;
9A is an exemplary method for processing non-closed caption text data;
9B is an exemplary format of a trigger command delivered in non-closed caption text data;
Figure 9C shows an exemplary trigger syntax; And
Figure 10 is an exemplary normative syntax for triggers.

While the invention is susceptible of embodiment in many different forms, there is shown in the drawings and hereinbelow specific embodiments thereof, which are to be regarded as illustrative of the principles, and in which the present invention is shown and described It is to be understood that the invention is not intended to be limited to the particular embodiments described. In the following description, like reference numerals are used to describe the same, similar or corresponding parts in several figures.

In interactive television applications, in addition to program audio and video, viewers are provided with additional (i.e., supplemental) content that allows them to interact with programming in a certain way. Additional content is as simple as an Internet URL (uniform resource locator) that points to a website that can provide additional information about the program, item, or service being viewed. That is, the interactive element may provide text and / or graphics to enhance the program video. The latter example is an element that displays updated statistics of a particular player during a sport event process.

Often, the behavior or appearance / disappearance of these interactive elements depends on the timing of events within the program. The television receiver rendering these objects must be able to receive appropriate signaling to know when and how to adjust for the display of interactive elements. The objects that perform this signaling function may be referred to as "triggers " because they act to trigger certain actions at a specified time. The kinds of actions that can be triggered are infinite. A simple example is to perform some specified action, such as "execute" (initiate the operation of the interactive function), "conceal" (remove all visible elements from the display), display or update certain text or graphics, "(All operation termination and memory resource release).

The trigger itself must be transported from a point in the distribution chain where the interactive element is always fed and operated to the consumer's receiver. Various transport methods for trigger objects are possible. The trigger may be included in a digital transport multiplex at a variety of different locations, or may be provided by an Internet-based server and accessed by internet-connected receivers. Possible locations within the digital transport include video or audio "user data" in a closed caption transport (described in more detail below), adaptation of an MPEG-2 Transport Stream packet in a descriptor carried in a program specific information In the field, embedded in audio, modulated within the video itself in luminance or chromaticity.

In each case, smaller triggers are preferred. For example, triggers that can be represented by about 30 bytes (or textual characters) provide greater flexibility and greater efficiency in transport than triggers that are more than 100 bytes in size. In embodiments of the present invention, a method for providing an interaction that is achieved using a small or "compact" trigger is described.

Referring now to the drawings, FIG. 1 illustrates a content source 10, a receiving device 20 (e.g., a digital television receiver device), a trigger parameters table (TPT) server 40, A triggered declarative object (TDO) server 50, and an optional automatic content recognition (ACR) The receiving device 20 accesses the TPT server 40, the TDO server 60, and / or the ACR system 60 via one or more communication networks, such as the Internet 30. [ In other embodiments, the TPTs stored in the TPT server 40 and / or the TDOs stored in the TDO server 60 are provided to the receiving device 20 by the content source 10 or the ACR system 60.

The broadcast system 2 is presented with interactive digital television features, whereby temporally synchronized supplemental content associated with events in the content provided by the content source 10 is presented to the viewer. Supplemental content includes one or a combination of media types such as audio, video, text, or image, and / or one or more interactive elements. In one embodiment, the behavior and appearance of the supplemental content is associated with the events in the content and synchronized in time.

In one embodiment, the content source 10 provides content to the receiving device 20 via terrestrial broadcasting. In another embodiment, the content source 10 may be a data communication network such as a satellite broadcast, a cable television transmission, a terrestrial television broadcast, a cellular network, and a local area network (LAN), a wide area network (WAN) Provide the content through at least one. The content provided by the content source 10 includes one or more television programs, whether the content is a movie, a sporting event, a segment of a multi-part series, a news broadcast or the like. In addition, the content provided by the content source 10 may also include content similar to an advertisement, an information advertisement, and other programs that may not be reported as programs in the EPG.

The receiving apparatus 20 receives the content provided by the content source 10 and displays the content on the display 350 shown in Fig. In one embodiment, the display 350 is an integral part of the receiving device 20, such as a television set. Alternatively, the display 350 may be external to the receiving device 20, such as a television set connected to a set-top box.

According to one embodiment, the receiving device 20 accepts Declarative Objects (DO) and renders them with content (e. G., Audio / video content of the program) received from the content source 10 It contains a declarative object (DO) engine. The DO engine renders the DO in response to a specific request from the user or in response to a trigger event. The DO that is rendered in response to a trigger event is called a triggered declaration object (TDO).

A TDO is a downloadable software object created by a content provider, a content creator, or a service provider, and may include a declarative content (e.g., text, graphics, Descriptive markup, script and / or audio). An embodiment of TDO is described in U.S. Serial No. 12 / 959,529, filed December 3, 2010, entitled " Announcement of Triggered Declarative Objects "by Blanchard et al., Which is hereby incorporated by reference in its entirety . However, the TDO is not limited to the structure described by Blanchard et al., Which allows many attributes defined therein to be part of the TDO to be placed in the trigger depending on the functionality and triggering of the particular TDO, or vice versa, or not at all Because.

TDO is generally considered "declarative" content to distinguish it from "executable" content, such as applications running on operating system platforms or Java applets. Although TDO is generally considered to be a declaration object, the TDO player (for example, the DO engine) supports a scripting language that is an object-oriented programming language. In the example shown here, the TDOs are received from the content or service provider ahead of the time they are executed and make the TDO available on demand. In addition, an explicit trigger signal may not be needed and the TDO may be triggered by a self-triggering of the trigger signal or by some action other than the reception of the trigger signal. Various standards bodies can define transport behavior for content and metadata for TDO, associated behavior, appearance, triggering behavior, and content and metadata for TDO. In addition, requirements for timing accuracy of TDO actions on audio / video can be defined by standards bodies.

A trigger is a file name for an object that has already been downloaded (upon command of execution, hold, termination, etc., or based on TPT) that has already been downloaded (for example, when instructing a download of a TDO or TPT) (E.g., a television program) of a content that refers to a particular TDO instance or TPT by the use of an identifier or identifier. Certain TDOs may have meaning only in conjunction with certain content. An example is a TDO that collects viewer response data, such as a vote on a game show or contest.

In one embodiment, the DO engine receives associated triggers to match various points within the content (e.g., trigger events), such as a scene change or the beginning or end of an ad segment. Triggers are divided into two types: (1) triggers that are processed by the DO engine, and (2) triggers that are passed to the TDO by the DO engine for processing. Triggers associated with Type 1 instructions are associated with commands executed by, for example, the DO engine. Triggers associated with a Type 2 instruction are associated with parameters (e.g., instructions, data, etc.) to be processed within the DO itself, for example, to cause the occurrence, behavior, or change of state of the associated supplemental content.

The trigger may be transported as a broadcast emission stream, for example, as described in U.S. Patent Application No. 13 / 216,375, which is incorporated herein by reference in its entirety. For example, the trigger may be a Packetized Elementary Stream (PES) of MPEG-2 Transport Stream (TS), as described in U.S. Provisional Application Serial No. 61 / 613,869, filed March 21, ), Or a DTV closed caption stream. In other embodiments, the trigger is embedded in the content itself. For example, the trigger may be restored by processing audio or video that is embedded in the audio or video portion of the content and decoded at the receiving device 20. [

For some methods of transporting triggers, smaller sized objects are preferred. In this case, the trigger must be able to be represented within a small number of bits or bytes. In addition, some transport methods may limit the maximum size of the trigger to a fixed number of bytes, as in the case of using a DTV closed caption channel.

In one embodiment, when the trigger is transported in a broadcast delivery stream, the trigger is a "URL String", such as URI_type = 0 URL (Interactive TV Trigger), in the DTV closed caption channel, It is passed on the called instruction. Based on the size of the trigger, the trigger can be segmented into a plurality of segments. In one embodiment, when a trigger is split into a plurality of segments, each segment is a segment of the first segment, where each segment is (1) the first of two or more; (2) whether the first nor the last; (3) Last perception; And (4) a type that indicates whether there is only one. Any predefined values may be used to identify the type of the particular segment. Also, in one embodiment, the type information defines a sequential ordering of the segments. In another embodiment, the type information may be used to carry any information about the segments to allow the receiving device 20 to reconstruct the trigger.

For example, if the trigger is less than 26 characters in length, the trigger is transmitted in a non-segment (e.g., type = 11). If the trigger is between 27 and 52 characters in length, it is sent in two segments (the first segment is type = 00 segment and the second segment is type = 10 segment). However, in other embodiments, any other criteria may be used to determine how the trigger is segmented. Further, in addition to or as an alternative to using service number 6, other service numbers may be used. The trigger type is included in the trigger syntax shown in FIG. 9C.

FIG. 9A illustrates an exemplary process performed by the receiving device 20 when a trigger is delivered over the closed caption channel of the DTV. The receiving apparatus 20 accesses such a trigger when accessing, for example, an MPEG-2 transport stream, a part of the entire broadcast multiplex, or a compressed type of content. The process begins at S902 where closed caption data containing closed caption text is received within a first standard service block having a predetermined service number in the range 1-6. In S904, the non-closed caption text data is received in a standard service block having the same service number as the predetermined number. In general, the standard service used for non-closed caption text data may be any one or combination of service numbers n between 1 and 6, which may be the first few service numbers used for subtitle text data, This is because the service number 6 is relatively rare in the embodiment.

In step S906, the receiving apparatus 20 analyzes the closed caption text data (for example, into a parsing computer process module) from the closed caption data indicated by the service number 6 (or n). In order to extract the trigger and perform the function based on the trigger, the non-closed caption text data is then processed in step S908. In one embodiment, the above-mentioned non-closed caption text data is carried in CEA-708 compatible variable length instructions. However, in other embodiments, the non-closed caption text data is carried in CEA-708 fixed length instructions or a combination of variable and fixed length instructions.

The DTV closed caption channel may be used as an alternative to triggers or in addition to triggers to provide other types of data (e.g., one or more parameters suitable for ingestion or processing by one or more TDOs, a subtitle window for 3D content, And a data stream including disparity data used to render a graphics object, such as < RTI ID = 0.0 > a < / RTI > This other type of data may be provided via one or more standard service blocks having a predetermined number (s) different from the standard service block (e.g., service # 5, 4 or 3) carrying the trigger, It is possible to use different predetermined command code sequences within the same standard service block.

In one embodiment, the triggers are delivered using one of the unused code points, e.g., 0x98 in the CEA-708 C3 code space, to convey a variable-length short trigger. Reference is made to Figure 9b for an exemplary specification of the CEA standard format (e.g., as an extension to CEA-708). The trigger is a variable-length instruction passed in a set of C3 codes as defined in CEA-708.

The trigger command shown in Figure 9B provides for the transport of interactive TV trigger data. As described above, in one embodiment, the trigger command is transported in standard subtitle service # 6. In the above instruction coding, the length L is an unsigned integer indicating the number of bytes following the header, in the range 11 to 27.

As specified in Section 7.1.11.2 of the CEA-708-D, variable-length instructions are represented by the EXT1 character followed by a number in the range 0x90 to 0x9F, where the "0x" notation represents a number in hexadecimal format. In the instruction format shown in FIG. 9B, the EXT1 character (0x10) is followed by 0x98. In this context, 0x98 is the instruction identifier for the trigger instruction. However, any other unused instruction identifier may be associated with the trigger instruction. CEA-708-D According to the syntax defined in section 7.1.11.2, the next byte contains a 2-bit type field, a zero bit, and a following 5-bit length field.

In one embodiment, the trigger () data structure follows a byte containing a length field. The syntax of an example of trigger data is shown in pseudocode in Fig. 9c. In the exemplary trigger syntax of Figure 9c, the trigger_type is a 4-bit unsigned integer representing the type of the following trigger. In one embodiment, only Type 0 triggers are defined. Therefore, the value of the trigger_type is set to zero. The receiving device 20 is expected to ignore instances of the trigger instruction that represent triggers of any other (unrecognized) type. In another embodiment, the trigger_type is set to one value indicating an interactive TV trigger and another value indicating that the URL is an Internet server location used for service usage reporting.

Also, in one embodiment, the trigger_character is an 8-bit ASCII character whose value is limited to those that allow a Uniform Resource Identifier (URI) according to RFC 2396. The character string formed by trigger () is a valid URI according to RFC 2396, including by reference in its entirety.

The use of variable length DTV closed captioning commands in service # 6 to transport the trigger provides: (1) robust (explicit) signaling of the presence of the trigger; (2) Signaling of the type of trigger (for future expansion); (3) a transport format that is a natural extension to the existing CEA-708 DTV CC protocol; And (4) Transparent transport methods for legacy receivers.

Triggers may be transported through other paths, such as the Internet. In one embodiment, when the trigger is not available via a broadcast delivery stream, the receiving device 20 may transmit the A / V samples of the content being received by the receiving device 20 to the ACR system 60 , Thereby acquiring the trigger via the ACR system 60. [

In one embodiment, when the receiving device 20 does not access the broadcast TS or the broadcast triggers, the receiving device 20 identifies the content and the media time being viewed through the ACR system 60. In this case, the TPT and associated files are usually retrieved from the Internet server (e.g., TPT server 40) identified by the trigger. However, in one embodiment, the ACR system 60 will not be responsible for providing updated triggers, for example, to establish timing for live events. Instead, the updated triggers will be distributed from the TPT server 40 identified by the locator_part of the trigger, as described below. In other embodiments, the updated triggers may be provided by the ACR system 60, for example, when the ACR system 60 and the TPT server 40 are combined into a single system.

In the case of ACR, the receiving device 20 is expected to perform access to the TPT server 40 to open channels on which the updated triggers can be received. For example, the protocol for trigger refresh may follow the Long Polling method defined in RFC 6202, which is hereby incorporated by reference in its entirety.

Embodiments of the present invention provide some approach to system design in which a tree can be represented in a small number of bytes to enable convenient and reliable transport. Representation of a trigger with a small number of bytes is necessary for small, compact and reliable triggers for transport methods with limited data carrying capacity; And the need to accommodate variable-size payloads that are often difficult to transport. Some embodiments of the present invention may also be implemented in a flexible system (e.g., where the actions and behaviors are not coded in the TDO itself, but are indicated by data in the associated tables) in which the TDO can be " To solve the desire to provide. This allows a single TDO script to be made available in a variety of situations.

The motivation behind the concept of triggers is that the files that make up the TDO and the data files used by the TDO to take a certain action are given a predetermined amount of time to transmit to the receiving device 20 . Although the user experience of the interactive elements can be produced prior to the broadcast of the content, certain behaviors must be finely timed to match the events of the program itself, e.g., commercial ad segments. The broadcast system 2 separates the delivery of the declared object and associated data, script, text and graphics from the signaling of the specific timing of the playout of the interactive events (i.e., the trigger).

Triggers perform various timing-related signaling functions as support for interactive services. Triggers are multifunctional; Depending on their structure, exemplary trigger instances may perform one or more of the following functions:

Location of file directories (accessible via a File Delivery over Unidirectional Transport (FLUTE) session in an outgoing stream, an Internet browser, or both) containing interactive elements such as TPT, TDO, graphics, and data files Signaling;

Indicating that the interactive content for an incoming program segment is available for pre-loading;

Display the current Media Time of the associated audio / video or audio-only content;

• a reference to a specific interactive event within the TPT and signaling that the event will be executed at the now or later specified media time;

• Indication that access to the Internet server will spread randomly over a specified time period to avoid peak demand.

An exemplary normative syntax for triggers is shown in FIG. This trigger syntax is based on an absolute URI according to RFC 3986, which is hereby incorporated by reference in its entirety, with the exception of the <scheme> and ": //" portions, with additional constraints specified below.

The syntax definition shown in FIG. 10 is similar to the ABNF (Augmented Backus-Unicode) defined in RFC 5234, which is hereby incorporated by reference in its entirety, except that a vertical bar symbol "| & Naur Form) grammar. Rules are separated from the definition by an equal sign "=", indentation is used to continue defining rules across more than one line, and literals quoted in parentheses "(" and ") Elements are grouped together, optional elements are included in the brackets "[" and "], elements preceded by <n> * specify n or more iterations of subsequent elements, n is the default value of 0 to be.

In one embodiment, the additional constraints include: (1) the maximum length of the trigger does not exceed 52 bytes; (2) The host name part of the trigger is the registered Internet domain name. The maximum length of 52 bytes is set in the embodiment in which the trigger is transmitted to the service channel # 6 through the DTV closed caption channel as described above. However, different maximum lengths may be set if the trigger is transmitted via another part of the DTV closed caption channel or via other transport methods.

In some embodiments, the trigger is considered to consist of three parts, two of which are required, one of which is optional: <domain name part> / <directory path ( directory path)> [? &Lt; parameters >].

<Domain name part> refers to the registered Internet domain name. The <directory path> is an arbitrary character string that identifies the directory path under control and management of entities that have rights to the identified domain name. The combination of <domain name portion> and <directory path> uniquely identifies a set of files that can be processed by the receiving device 20 to add interactivity to the associated content.

The <parameter> part of the trigger is optional. In the presence, this may carry one or more parameters associated with the trigger. In one embodiment, the trigger carries parameters within the query string (e.g., the part of the trigger on the right side of the "?"). The format defined for the query string may be, for example, <event time>, optionally followed by <spread>; (2) <media time>, followed by optional <spread>; (3) <other>, optionally followed by <spread>; And (4) diffusion.

In one embodiment, the parameters are formatted according to the following rules:

&Lt; Event time > - a trigger event ID specified by a decimal number referring to two parameters, "e = &quot;, followed by an event ID (eventID) in the associated TPT, and & Timing value specified by a string of 1 to 7 characters in length representing the hexadecimal number representing the new media timing.

<Media time> - A term specified by a character string of 1 to 7 characters in length that represents a hexadecimal number representing "m =" followed by the current media time in milliseconds.

&Lt; Diffusion > - a term specified by "& s = " when specified by "s =" in the case of a unique term and appended to another term, Represents a decimal number representing the time in seconds that all receivers, including the receiver, should attempt to access the Internet server identified in the trigger. Each individual receiving device 20 derives a random time within a specified interval and delays the access request by that amount so that the demand peak that may occur at the first appearance of the trigger in the receiving device 20 is spread in time .

<Other> - specified by a character other than "e", "E", "m", "M", "s", "S", "t", or "T" followed by equals and alphanumeric strings term. The second <other> term may appear after the first; If present, the start of the second term is separated by the "&" character. Each receiving device 20 is expected to ignore the unrecognized terms.

Examples of valid triggers and their functions are given in Table 1 below:

Query terms ("e", "m", "s", and "t") other than those defined above may appear in the trigger to define one or more other predetermined functions. Thus, in one embodiment, the following triggers are legal and each receiving device 20 is expected to process them accordingly:

a.xbc.tv/77?a=6EE43f. The receiving apparatus 20 can be used as a pre-load, but the "a" term is ignored if not recognized.

a.xbc.tv/133-Ar4?w=3&s=10. The receiving device 20 can be used as a pre-load with the spreading parameter 10, but ignores the "w"

x.tv/E7?B=OK&C=OK&S=10. The receiving device 20 can be used as a pre-load with the spreading parameter 10, but ignores the "B" and "C" It should be noted that according to the embodiment, the query term identifier may or may not be case-sensitive.

When the TPT is specified as an XML Schema, an exemplary namespace for this schema is http://www.atsc.org/XMLSchemas/tpt/2012/1, which indicates that the schema is the major version 1 . In one embodiment, the "schema" element of the XML schema includes a "version" attribute set to a value of 1.0 indicating that the minor version of the schema is zero.

In order to provide flexibility for future changes in the schema, the decoders (e.g., receiving devices 20) of the TPT instance documents with the defined namespace must follow the "Must Ignore" rule. That is, decoders should ignore elements and attributes that they do not recognize as errors, but ignore them.

An embodiment of the TPT structure is shown in Table 2 below. "@" The following items are attributes; Others are elements.

The TPT structure of Table 2 includes major and minor protocol version attributes at the TPT level (top level). In one embodiment, these attributes function similarly to the way in which the namespace may be used to specify different types of TPT data structures for scalability. The primary and secondary protocol versions allow the receiving device 20 to conveniently identify which particular TPT instance corresponds to the first release of the standard or to what future release.

The TPT structure of Table 2 also includes a simplified XML specification of the spreading mechanism. In contrast to a complex type of diffusion mechanism called a diffusion type with a single attribute, the diffusion mechanism is simply simplified to an attribute of the event type.

The complex diffusion type relates to the diffusion that occurs during repeated transfer of the TPT. The first issue may indicate that one of the four receivers should attempt to access the server. The second issue may indicate that one of the three must be accessed. The last one will indicate that all the rest should be accessed. In the case of more realistic use, the TPT may be searched once, and almost all receivers may want to start searching for the assets referenced at that moment. A one-parameter method is suitable for this application.

The conventional three-parameter method included these items:

Rate: The attribute of the diffusion element. This represents the number of timings divided for randomized spreading of the instruction execution timing of the integer.

Range: The attribute of the diffusion element. This represents the range of randomized spreading of the instruction execution timing in seconds.

Period: The attribute of the diffusion element. This represents the time period during which the randomized spreading of the instruction execution timing in seconds after the start time of the instruction is applied. That is, the receiver operates considering diffusion only during this period.

The TPT structure of Table 2 also includes a live trigger element added to the TPT (highest level) level, corresponding to a complex type called a liveTrigger Type. In one embodiment, a live trigger type consists of one required attribute and two optional attributes. The required attribute specifies the server's URL or other location within the TS that can provide an updated trigger for live events. The optional parameter specifies how the polling will be done (e.g., periodic, or "long" polling), and if it is periodic, specifies the duration of the polling cycle. However, in other embodiments, the live trigger type may be composed of different combinations of required attributes and optional attributes.

The TPT structure of Table 2 further includes capability elements in the Application Type. This feature allows a given application to be associated with zero or more "capability codes". Each code identifies a data type whose support at the receiving device 20 for that data type as a data type is essential for a meaningful presentation of the application. The given code may be any predetermined symbol or value, such as an integer value referencing a predetermined definition, or it may be an Internet media type string (formerly known as a mime-type string). The resource definition may be any audio or video codec, for example, with the required level of decoding capability of the receiving device 20 (for codecs known as profiles and levels).

The capability code allows, in the presence, to confirm in advance whether the receiving device 20 has the ability to decode the content (e.g., TDO and other assets associated with the application) before downloading it do. For example, if support for a predetermined codec or a predetermined protocol level is required, the receiving apparatus 20 should be able to determine whether or not to support it.

The exemplary semantics of the fields of the TPT structure are as follows:

tpt : The root element of the TPT. One tpt element describes all or part (temporal) of one programming segment.

id : The attribute of the tpt element, such as a string that uniquely identifies the programming segment to which this tpt element is targeted. In one embodiment, the id string is the locator_part of the corresponding trigger, as described above.

tptType (tptType) : The attribute of the tpt element. In one embodiment, this attribute is a string indicating the updatability of this tpt element. This value is either "static" or "dynamic". If "static", all timing references in the tpt instance are valid media time values. If it is "dynamic &quot;, the tpt element may not contain valid media time values. Thus, in this case, the receiving device 20 is expected to acquire and process triggers including an &quot; event time &quot; parameter to know the appropriate media time for different events. The receiving apparatus 20 can also obtain the updated timing by receiving an update (more recent version) of the TPT.

MajorVersion : required attribute of the tpt element that is an integer value in the range 1 to 99 that indicates the major protocol version of this TPT instance. The value of the majorVersion for this version of the protocol is set to one in one embodiment. Each receiving device 20 is expected to discard the instances of the TPT indicating the values of the main version for which support is not available.

Note that in some embodiments, one TPT instance may describe interactive events for multiple versions of the protocol. For example, a single TPT instance may be available to receivers that also support protocol version 2.0, as well as receivers that only understand protocol version 1.0. A receiver of the latter type may discard all or a portion of the TPT that contains 1.0-level elements and may process portions of the TPT that contain 2.0-level elements.

MinorVersion : An optional attribute of the tpt element that is an integer value in the range 0 to 99 that indicates the minor protocol version of this TPT instance. The value of the minor version is set to zero in one embodiment. Each receiving device 20 is expected not to discard the instances of the TPT that represent the minor version unrecognized values. The minor protocol version is used to indicate changes to the TPT protocol that are not important enough to cause compatibility problems with older receivers built according to the previous minor protocol version. For receivers that do not recognize a sub-protocol version of a given value, they can find and process certain data elements that older receivers will ignore.

tpt Version (tptVersion) : The attribute of the tpt element, which is a positive integer value indicating the version number of the tpt element identified by the id attribute. The tpt version is incremented each time a change is made to the TPT.

Updating Time (updatingTime): Optional attribute of the tpt element. In the presence, this positive integer value indicates the number of seconds that the receiving device 20 should use when acquiring the updated TPT by polling. The updating time parameter is valid only when the tpt type is "dynamic". Note that one way for the delivery of updated event timings is to issue a trigger that includes an < event time > parameter.

Start Mt (beginMt): Optional attribute of the tpt element. In the presence, this indicates the beginning Media Time of the segment or segment described by this TPT instance.

Exit Mt (endMt): optional attribute of the tpt element. In the presence, this represents the ending Media Time of the segment or segment described by this TPT instance.

ExpireDate: Optional attribute of the tpt element. In the presence, this represents the expiration date and time of the information contained in this TPT instance. If the receiving device 20 caches tpt, it can be reused up to the expiration date. The expiration date is formatted as an xs: dateTime string.

LiveTrigger: This optional complex type specifies the information used in the case of dynamic tpt.

Live Trigger URL (liveTriggerURL): Required attribute of the live trigger element This string represents the URL of the server that will provide the updated trigger in case of live broadcast.

LongPoll : An optional property of the live trigger element. This Boolean element, if true, indicates that the receiving device 20 should use a " long polling "protocol to receive the updated trigger. If false, the receiving device 20 indicates that it should perform regular polling at the interval indicated in the pollPeriod attribute.

Poll period (pollPeriod) : An optional property of the live trigger element. This parameter indicates the time period in seconds that the receiving apparatus 20 should use when polling the live trigger server, in the presence. The value 30 indicates, for example, that the receiving device 20 should request an updated trigger every 30 seconds.

Event : The child element of the tpt element. This represents each event that affects TDO operation and life-cycle. One or more events may appear in the TPT instance.

Event ID (eventID): The attribute of the event element. This represents the unique identifier of the instruction in the form of an unsigned integer. The range of uniqueness of the event ID is, in one embodiment, the entire duration of the programming segment. The event ID is referenced by a trigger that includes an < event time > parameter.

Start time (startTime) : Optional attribute of the event element. In the presence, this indicates the start of a valid period for the event on the media time. The receiving apparatus 20 is expected to execute a command when the media time reaches the value of the start time (startTime).

End time (endTime) : Optional attribute of the event element. In the presence, this indicates the end of a valid period for the event on the media time. The receiving apparatus 20 is expected not to execute the command when the media time passes the value of the end time (endTime).

Destination : Optional attribute of the event element. In the presence, this represents the targeted device for this event. If the targeted device is the receiving device 20 itself, the value is a "receiver" or any other predetermined value. If the target device is not the receiving device 20, this indicates another device type or application type.

Action : The attribute of the event element. This represents the event action type that controls the application (TDO) operation and the life-cycle. In one embodiment, the value is any one of the following:

"Register": If possible, obtain and pre-cache the resources of the application.

"Suspend-execute": suspends any other currently running application and launches the application. If the application has not yet been pre-cached, the receiving device 20 needs to acquire the resources of the application before launching the application. If the target application is pending, the receiving device 20 resumes it with the previous state.

"Terminate-execute": Terminates any other currently running application and launches the application. If the application has not yet been pre-cached, the receiving device 20 needs to acquire the resources of the application before launching the application. If the target application is pending, the receiving device 20 resumes it with the previous state.

"Suspend-resume": suspends any other currently running application and resumes the application.

"Terminate-resume": Terminates any other currently running applications and resumes the application.

"Terminate": Terminate the application.

"Suspend": Holds the running application. It is required to be maintained until the UI and application engine status are restarted.

"Event": Fire stream events that depend on the application script.

Diffusion : An optional attribute of an event element. In the presence, this integer value represents the period N in seconds. The purpose of the spreading parameter is to smooth the peak at the server load. The receiving device 20 is expected to delay this amount of time prior to accessing the Internet server to compute a random period in the range 0 to N and retrieve the content referenced by the URLs in the TPT.

Application : The child element of the command. This represents the application targeted by the command (for example, TDO).

AppID (appID): Required attribute of the application element. This represents the unique identifier of the application (TDO). In one embodiment, the format is a predetermined globally unique format.

AppType: Required attribute of the application element. This represents the application format type. In one embodiment, the unique value may be "html5 &quot;.

url: Required attribute of the application element. This indicates the URL from which the receiving apparatus 20 can acquire the application.

Priority (priority): Select the application elements take effect Boolean (Boolean) property. If the receiving device 20 caches after using the application resources once, then the receiving device may need to manage a plurality of application resources. The priority represents the caching priority among applications competing for the cache memory space. Values are canonical (value false or 0) or high (value true or 1). If this attribute is not present, in one embodiment, the cache priority is considered to be normal. Alternatively, in another embodiment, the cache priority may be considered high when this attribute is not present.

ExpireDate : Optional attribute of the application element. The expiration date parameter is used to help the receiving device 20 manage memory resources. This indicates the date and time, and after this date and time the receiving device 20 can securely delete the application resources. The expiration date is expressed in the xs: dateTime format.

Capability: An element of an application element that is a sequence of zero or more capability code strings. Each capability code string is an integer or a media type string. When the capability code string is an integer, the integer value may be a supported video codec, a supported audio codec, a supported "browser" profile, a supported DO engine profile, Which corresponds to capabilities such as supported memory size (e.g., for signaling the network). The receiving device 20 is expected to process each capability element to determine if it supports the indicated capability. If more than one capability code is not supported, the receiving device 20 is expected to ignore the application instance. In yet another embodiment, the receiving device 20 may determine an application instance based on a predetermined or user-defined priority of each of the non-capable capability codes.

Stream event (streamEvent): The child element of the event element. This represents a stream event that allows the application to operate in synchronization with the broadcast signal if the action attribute of the command element is "event &quot;.

Stream event ID ( streamEventID ): Required attribute of the event element. This represents the unique identifier of the stream event. A reference between a stream event and an application may be realized by this identifier.

Data: the child element of the event element. It describes the embedded data related to the stream event, if any. The target application will read and use this data.

An embodiment of the XML schema of the TPT is defined in the following Table 3:

In one embodiment, the receiving device 20 is configured to receive an updated version of the TPT when available. The ability to receive an updated version of the TPT provides increased flexibility in providing trigger events when it is difficult to precisely determine the exact timing of trigger events, such as in the case of live programming. During live programming, the TPT may be updated to include timing information once the timing information is determined. For example, an updated version of the TPT may include modified or new timing information associated with a trigger for displaying supplemental content during live programming. In another example, the TPT may be updated to reference different content based on the results of the live event.

In another embodiment, the TPT remains unchanged as the program proceeds. The execution timing of a specific interactive event is determined by the appearance of a trigger that refers to a specific event. When the receiving device 20 receives the trigger, the event referenced in the TPT is executed.

Certain types of triggers may indicate that the TDO has reached the time to perform a given action, but a series of timed actions may be played out without a trigger. The TPT optionally provides timing information for various interactive events related to "media time ". Each item of interactive content has a timeline for its playout; One point on this timeline is called the media time. That is, the media time is a parameter that refers to a point in the playout of an audio / video or audio content item. For example, a 30 minute program may have an interactive event from the start of the program at a media time of 10 minutes 41 seconds, i.e., a media time of 10:41. The TPT may include an entry indicating the details of the event occurring at time 10:41. Once the receiving device 20 has determined the current timing for the start of the program, the TPT can be used to play out all subsequent events.

The receiving device 20 can determine the availability of the updated TPT by referring to a non-real-time (NRT) file in FLUTE, such as the file version number indicated in the Transport Object Identifier You can decide. FLUTE is defined in RFC 3926, which is hereby incorporated by reference in its entirety. In another embodiment, the receiving device 20 receives the updated TPT by posting a GET request to the TPT server 40 that remains pending until a new TPT is available. In another embodiment, the receiving device 20 periodically accesses the source of the TPT to determine if a new TPT is available. Alternatively, the receiving device 20 accesses the source identified by the above-described live trigger element.

Likewise, compact triggers may be available through an Internet-based server. As in the TPT update, the receiving device may post a GET request to the TPT server 40 that remains pending until a new trigger is available.

Figure 2 shows an embodiment of a receiving device 20. The receiving device 20 is a digital television receiver device that can be included in a television set or set-top box. The receiving device 20 includes a tuner / demodulator 202 that receives content from one or more content sources, such as terrestrial or cable television transmissions. The receiving apparatus 20 also receives the content from the satellite broadcast, or alternatively receives it. The tuner / demodulator 202 receives the transport stream (TS) demultiplexed by the demultiplexer 206 into an audio and video (A / V) stream. The audio is decoded by the audio decoder 210 and the video is decoded by the video decoder 214. Further, the uncompressed A / V data may be received via an uncompressed A / V interface (e.g., an HDMI interface) that may be selectively used.

In one embodiment, the TS includes side information such as one or more of caption data, TDO, trigger, TPT, and the like. However, in other embodiments, a subset or all of the A / V content and / or side information may be received via the Internet 30 and the network interface 226. [

Storage unit 230 is provided for storing Internet-forwarding content, such as Internet Protocol Television (IPTV) or NRT. The stored content may be played by demultiplexing the content stored in the storage unit 230 by the demultiplexer 206 in a manner similar to that of the content of other sources. The storage unit 230 may also store one or more TDOs, triggers, and TPTs acquired by the receiving device 20.

The receiving device 20 generally includes a CPU 238 coupled to one or more buses (e.g., bus 250) to a work memory 240, a program memory 242, and a graphics subsystem 244, Lt; RTI ID = 0.0 &gt; and / or &lt; / RTI &gt; CPU 238 receives the closed caption data from demultiplexer 206 as well as any other information such as TDO annunciation and EPG used for rendering graphics and passes that information to graphics subsystem 244. [ The graphics output by the graphics subsystem 244 is combined with the video image by the compositor and video interface 260 to produce an output suitable for display on the video display. Also, the CPU 238 receives non-closed caption text data, as described above.

CPU 238 also operates to perform the functions of receiving device 20, including processing of associated triggers, TDO, TPT, and browser operations (e.g., contained in closed caption data). The browser action includes access to the service specified by the URL given by the TDO or trigger. CPU 238 also operates to execute a script object (control object), its trigger (s), etc., contained in the TDO, e.g., using the DO engine.

Although not shown in FIG. 2, the CPU 238 may be coupled to any one or combination of the resources of the receiving device 20 to centralize control of one or more functions. In one embodiment, the CPU 238 also operates to supervise the control of the receiving device 20, including the tuner / demodulator 202 and other television resources.

A more processor-centric view of the receiving device 20 is shown in FIG. Memory and storage 230, 240, and 242 are collectively shown as memory 310. In addition, the processor 300 includes one or more processing units, such as a CPU 238. Likewise, various demodulators, decoders, and the like that initially process digital television signals are collectively shown as television receiver / tuner 320. The receiving device 20 further includes a remote controller 360 in communication with the remote controller receiver interface 340. [ In addition, the display 350 is connected to a display interface 330 that includes, for example, an uncompressed A / V interface and / or a compositor 260 and is connected to the receiving device 20 An integrated display or a connected display device as in the case where the receiving device 20 is integrated into a set-top box.

Memory 310 includes various functional program modules and data. Memory 310 stores data used by receiving device 20. The memory 310 in the receiving device 20 may be configured to store data in a form suitable for storing data in the form of disk storage as well as other forms of storage such as, for example, network memory devices, magnetic storage elements, magneto-optical storage elements, flash memory, Such as non-volatile storage devices, including non-volatile storage devices. When TDO 316 is received, TDO 316 is stored in memory 310. The TDO execution is performed by the DO engine 312. The TDO, when executed by the DO engine 312, presents the supplemental content based on timing information stored in one or more triggers associated with the TDO and / or the associated TPT 318. The memory 310 also stores, in one embodiment, the TPT 318, which defines one or more parameters for each trigger associated with the TDO.

4A provides an overview of an exemplary method for processing triggers, for example, In step S402, the receiving apparatus 20 receives content (e.g., a television program) from a content source, such as the content source 10. [ The received content is presented to the user of the receiving apparatus 20 in step S404. In step S406, the receiving apparatus 20 extracts the compact trigger from the closed caption data associated with the received content. The receiving apparatus 20 processes the compact trigger to determine the position of the TPT in step S408.

In step S410, the receiving apparatus 20 retrieves the TPT from the determined position and stores the TPT in the first memory of the receiving apparatus 20. [ Also, in step S412, the receiving device 20 processes the received and stored TPT to identify the necessary resources, including the triggered declaration object (TDO) associated with the TPT. In yet another embodiment, the location of one or more required resources is identified by one or more distinct compact triggers. The determined necessary resources are subsequently retrieved and stored in the second memory of the receiving device 20 in step S414. In step S416, the receiving device 20 determines the media time or waits for a compact trigger to identify the event. In step S418, when the media time arrives and / or the compact trigger identifies the event, the receiving device performs an action on the declaring object (e.g., TDO) or the declaring object performs the function based on the data in the TPT To handle the same event. The event processed in step S418 may be a Type 1 command that knows how to execute by the receiving device 20 (e.g., the DO engine 312) or a Type 2 command that the receiving device 20 sends to the TDO for execution The first and second memories may correspond to different parts of the storage 230 or the working memory 240, or to the same memory, such as discrete memories.

The trigger must be time-synchronized strictly with the audio / video content (e.g., to match the ad boundary or scene change), but the TPT can be delivered well before the event it describes. Since the receiving apparatus 20 can acquire or download the TPT in advance before use over a period such as a few seconds or several minutes, it becomes possible to use the Internet for transporting the TPT.

In one embodiment, the TDO is downloaded from the TDO server 50 and the TPT is downloaded from the TPT server 40 in response to receiving one or more triggers associated with the currently received content. For example, the receiving device 20 receives a first compact trigger that identifies the location of the TPT. The receiving device 20 downloads the TPT from the TPT server 40 in response to receiving the first compact trigger. Subsequently, the receiving apparatus 20 processes the TPT and determines that the TDO is a necessary resource. In one embodiment, the receiving device 20 determines that the TDO is a necessary resource based on the inclusion of the TDO location in the TPT. In response, the receiving apparatus 20 receives the TDO from the TDO server 50. [ In another embodiment, the receiving device 20 receives a second compact trigger that identifies the location of the TDO. It should be noted that, in the case of receipt of the second compact trigger, the order in which the triggers identify the location of the TPT and TDO may be reversed.

In yet another embodiment, the receiving device 20 receives a compact trigger that identifies the location of the TDO. The receiving apparatus 20 searches TDO from the position identified by the compact trigger. Subsequently, after the TDO is executed, the TDO itself causes a download of the associated TPT.

As mentioned above, in one embodiment, once the internet address (URL) of the TPT server is identified by the trigger, the receiving device 20 uses it to obtain the TPT. Upon receipt of the TPT, various other referenced assets (e.g., TDOs, files, multimedia assets, etc.) are retrieved by the receiving device 20 and stored in memory for possible future use. Once the media time is known, the receiving device 20 begins processing the TPT to find out if there is a "Type 1" or "Type 2"

In step S418, when the receiving device 20 receives a trigger associated with the type 1 command (e.g., to execute TDO), the DO engine 312 executing on the processor 300 executes the TDO. If the receiving device 20 receives the trigger associated with the type 2 instruction in step S418, the receiving device 20 passes the trigger data to the TDO while the TDO is executing, which means that the information contained in the trigger associated with the type 2 instruction Retrieves at least one parameter associated with the trigger event stored in the TPT based on the tag value (e.g., tag value, media time, etc.). In another embodiment, DO engine 312 retrieves at least one parameter and passes the retrieved at least one parameter to TDO. The TDO performs a function based on at least one parameter retrieved.

Figures 4b and 4c provide a more detailed illustration of the retrieval of the TPT and other necessary resources in accordance with one embodiment. Upon receipt of a trigger via broadcast transmission or interaction with the ACR system 60, the receiving device 20 accesses the file referenced by the URL of the locator_part of the trigger (the left part of "?) Is expected to do. As described above, depending on whether the receiving apparatus 20 accesses the entire broadcast transport stream, two file delivery paths are possible.

4B shows a case where the entire TS is available to the receiving apparatus 20 having no or poor internet access. The triggering process begins at step S430, where the receiving device 20 processes the program map table (PMT) of the broadcast virtual channel to find the coordinates of the associated IP subnet. In step S432, the receiving apparatus 20 processes a Service Map Table (SSC) of an associated IP subnet to search for a service map table (SMT). In step S434, the receiving apparatus 20 finds the coordinates of the FLUTE session based on the retrieved SMT. In step S436, the receiving apparatus 20 obtains a FLUTE file delivery table (FDT) for the FLUTE session, each of which provides a list of content items together with the content-location value. In step S438, the receiving apparatus 20 compares the locator_ portion of the trigger against the content-position values until a match is found. In step S440, the receiving device 20 searches for the file (s) associated with the matched content-location value to find the TPT. In step S442, the receiving apparatus 20 retrieves any other file referenced by the TPT from the FLUTE session.

4C shows a case where good Internet access is available. The triggering process starts in step S450, at which time the receiving device 20 performs an internet http GET using the locator_ portion of the trigger. In one embodiment, the Internet http GET is performed using a spread algorithm. In step S452, the receiving device 20 processes the returned TPT to find and retrieve other content items that may be needed.

In one embodiment, when the receiving device 20 accesses both the entire TS and the good Internet connection, the receiving device 20 defaults to searching for the TPT over the entire TS to reduce the load on the Internet server. In other embodiments, the receiving device 20 may make a TPT search over the Internet by default or based on predetermined criteria (e.g., the time required for a full TS and TPT search over the Internet, (E.g., based on other processing of the receiving device 20 such as &lt; RTI ID = 0.0 &gt; and / or &lt; / RTI &gt;

5 is a more detailed diagram of an exemplary method for processing a trigger associated with a Type 2 instruction (e.g., a "life cycle" or "DO engine" instruction) using a DO engine. In step S502, DO engine 312 determines whether a trigger associated with a type 2 command (e.g., a "DO event" command) has been received. In one embodiment, DO engine 312 determines the type of trigger based on whether the trigger specifies an instruction to be executed by DO engine 312. [ For example, if the trigger includes a tag value assigned to a command to be executed by the DO engine 312. In another embodiment, the DO engine 312 determines whether a trigger is associated with a Type 1 or Type 2 command based on the information contained in the TPT entry. For example, the TPT entry itself may contain information specifying that the trigger corresponds to a Type 1 or Type 2 command. In another example, the DO engine 312 determines if the TPT contains a DO engine command.

When it is determined in step S502 that a trigger associated with the type 2 command is received, the DO engine extracts the information contained in the trigger in step S504. In one embodiment, the trigger information includes one or more of a table entry containing parameters and data associated with one or a combination of a TDO identifier (e.g., a TDO URL) and a TPT reference and / or the trigger event. The TDO identifier may be any unique identifier, such as a reference number, a URL, a symbol, or some other representation. The reference may be a tag value such as an index number (small integer) or media time. In some embodiments, the trigger includes only a reference number.

In step S506, the DO engine determines based on the extracted TDO identifier whether the trigger is associated with the currently executing TDO. If it is determined that the trigger is associated with the currently executing TDO, then in step S508 the reference (e.g., the tag value) extracted from the trigger is provided to the TDO via the trigger application program interface (API) function. The tag value may be extracted with the TDO identifier or at any time before the tag value is provided to the TDO.

If it is determined that the trigger is not associated with the currently executing TDO, then in one embodiment the trigger is discarded and the DO engine 312 returns to step S502 to wait for receipt of the next trigger associated with the type 2 instruction. Alternatively, the DO engine 312 may temporarily suspend or terminate the currently executed TDO and may execute the TDO associated with the trigger before proceeding to step S508. For example, in one embodiment, if it is determined that the trigger is not associated with a currently executing TDO, the currently executing TDO is terminated or pending and the TDO associated with the trigger is executed. If the currently executing TDO is held, execution of the held TDO is resumed when the trigger associated with the held TDO is received later.

6A shows an example of triggers that are delivered in conjunction with two programming segments. In this example, both segments are "pre-created ", meaning that the content does not come from a live broadcast; Interactive elements were added after creation.

As shown, just prior to the occurrence of programming segment 1, a "pre-load" trigger is passed to allow the receiving device 20 the opportunity to acquire the TPT and interactive content associated with programming segment 1 . The transfer of the pre-load trigger is optional; If not transmitted, each receiving device 20 is expected to use the first trigger found within the segment to acquire the content.

The triggers are transmitted throughout segment 1, as shown, to indicate the current media time for the segment. Note that the first frame of a segment should be associated with media time zero, which is common and helpful, but there is no such requirement. Periodic delivery of media time triggers is necessary to allow any receiving device 20 encountering that channel to synchronize and acquire interactive content.

Immediately before the start of segment 2, a pre-load trigger for that incoming segment is transmitted.

In the case of pre-generated content (i.e., non-live), in one embodiment, the TPT acquired by the receiving device 20 after the processing of the first trigger defines the timing of all elements of the interactive experience for that segment . What is needed for the receiving device 20 and the TDO to play out the interactive elements is knowledge of the media timing altogether; The TPT describes interactive events related to media time.

In the case of live content, the TPT still contains data and information pertaining to different interactive events, but the timing of the playout of these events can not be known until an action in the program is unfolded during the broadcast. In the live case, the "event-timing" function of the trigger is used. In this mode, the trigger signals that the specified interactive event in the TPT will be retimed back to the specified new value of media time. Alternatively, the trigger may indicate that a given event should be executed immediately. 6B shows a live-event occasion.

The example of FIG. 6B shows a program segment called "segment 3" having nine triggers. The functions of each numbered trigger are as follows:

Trigger 601 is a pre-load trigger that references a directory from which files for segment 3 can be retrieved. Trigger 602 is a media time trigger used to establish playout timing for segment 3. The trigger 603 is an event re-timing adjustment trigger indicating that an event in the TPT will be retimed to occur at media time 240 at event &lt; RTI ID = 0.0 &gt; The hatched area represents the time interval before 240 when the trigger 403 can be delivered to the receiving device 20. Trigger 604 is another media time trigger. The trigger 605 is an event retiming adjustment trigger that indicates that an event in the TPT will be retime adjusted to occur at media time 444. Triggers 606 and 607 are additional media time triggers. Trigger 608 is an event trigger that indicates that an event with event_id = 12 in the TPT is to be executed immediately. Trigger 609 is also an event retiming adjustment trigger that indicates that in TPT an event with event_id = 89 will be retimed to occur at media time 900.

As shown in FIGS. 6C and 6D, in one embodiment, the TPT includes a primary key (e.g., tag element, media time, etc.) that associates each element (row) in the table with an associated trigger event. Each trigger will, in turn, refer to a specific event in the TPT by this key.

6C shows a TPT 616 that includes only parameters for a particular TDO (e.g., TDO 159) in accordance with one embodiment. In one embodiment, before executing the TDO with ID 159, the receiving device 20 downloads the TDO itself with the associated files, one of which is the TPT. TDO provides script-level access to the TPT. As mentioned above, according to the embodiment, the TPT is downloaded before or after the TDO, the TDO is downloaded from the location identified by the TPT, the TPT is downloaded from the location identified by the TDO, and so on.

The TS 612 carrying the content is associated with a plurality of events identified by the triggers 614A-614F. Triggers 614A-614C and 614F are associated with Type 1 commands; Triggers 614D and 614E are associated with Type 2 commands. The triggers associated with the Type 1 instruction are processed by the DO engine 312, while the triggers associated with the Type 2 instruction are processed by the TDO.

6C, the receiving device 20 receives triggers 614A and 614B that identify the location of the TPT 616 and the TDO 159, respectively. The receiving device 20 retrieves and stores the TPT 616 and the TDO 159 based on the identified locations. It should be noted that the TPT 616 and the TDO 159 may be received in any order. Further, in another embodiment, the TPT 616 identifies the location of the TDO 159, or the TDO 159 identifies the location of the TPT 616.

Each of triggers 614D and 614E is associated with a row (or element) in the TPT, such as TPT 616, and includes a reference to a particular entry in the TPT, e.g., using the tag value. DO engine 312 extracts the tag value from each of triggers 614D and 614E associated with the Type 2 instruction and provides the extracted tag value to the currently executed TDO. The TDO uses the tag value to determine at least one parameter associated with the trigger. Then, as mentioned above, the TDO performs its function based on at least one parameter retrieved. It should be noted that the reference to the TPT entry is not limited to a tag value, but may be any symbol or representation that can be used to refer to an entry in the TPT.

Further, in one embodiment, predetermined tag values (e.g., tag values below 16) are associated with predetermined commands to be executed by the DO engine 312. [ Thus, certain triggers such as a subset or all of the triggers associated with type 1 instructions need not be associated with a row (or element) of the TPT. For example, when the receiving apparatus 20 receives the trigger 614C having the tag value 5, the receiving apparatus 20 executes the TDO 159 stored in the receiving apparatus 20. [ In another example, DO engine 312 may terminate or suspend TDO 159 when receiving device 20 receives a trigger 614F with tag value 7. Thus, in these examples, the tag value 5 is specified as an "Execute" command and the tag value 7 is specified as an "end"

In one embodiment, the predetermined tag values are specified as an instruction to be executed by the DO engine 312 in the standard. The specified basic trigger types to be executed by the DO engine 312 itself include "register", "execute", "hold", "resume", and "end". Any other tag values, symbols, or representations may be reserved for DO engine commands. Further, in other embodiments, triggers associated with a Type 1 instruction refer to entries in the TPT 616 or in a separate TPT to provide any parameters required to execute the instruction. For example, when a trigger is associated with a Type 1 instruction that is a "load TDO ", the trigger includes a TDO location (e.g., a URL) or a reference to a location (e.g., an entry in the TPT) And can be acquired by the receiving apparatus 20. That is, in other embodiments, a trigger associated with a Type 1 instruction may include a reference to an entry in the TPT that identifies the location of the TDO to be retrieved and executed, as shown for the example of FIG. 6D.

6C, TPT 616 includes TPT entries (e.g., tag value 19 or 21) used by TDO 159 when it reaches a specified media time. The arrival of the specified media time may be determined based on the reception of the trigger, including the specified media time, or may be determined by the receiving device 20. For example, the TDO 159 monitors the current media time of the received content and processes the parameters when the media time is equal to 15000 and 18500, respectively. Alternatively, the DO engine 312 monitors the current media time and delivers the tag value to the TDO 159 at the appropriate time.

In one embodiment, the media time represents the number of milliseconds elapsed in the received content. However, other arbitrary time units may be used to indicate the media time. Any one or more of the triggers 614A-614F may also include additional parameters, such as media time information to be used by the receiving device 20, the DC engine 312 and / or the TDO 159, And may be included as a reference point for determining the current media time.

6D shows an exemplary TPT that includes parameters for triggers associated with Type 1 and Type 2 commands. It should be noted that separate TPTs for Type 1 and Type 2 instructions may alternatively be provided. Triggers 654A, 654B, 654D, and 654E are associated with Type 1 commands; Trigger 654C is associated with a Type 2 instruction. As described above, in one embodiment, the receiving device 20 searches the TPT 656 based on a trigger 654A that identifies the location of the TPT 656. [ In addition, the receiving device 20 processes the TPT 656 and determines that the resources required for the TPT include TDO1 and TDO2. Subsequently, the receiving apparatus 20 searches for TDO1 and TDO2 based on the positions identified in the TPT 656. [

When the receiving device receives the trigger 654B, in one embodiment, the DO engine 312 determines whether the corresponding tag (s) within the predetermined range of tag values (e.g., a tag value less than 16) Based on the value, determines that the trigger is associated with a Type 1 instruction. In another embodiment, DO engine 312 determines that a trigger is associated with a type 1 command based on the presence of an instruction, such as "Execute" in the corresponding TPT entry or some other identifying information. Receiving apparatus 20 executes TDO1 in response to receipt of trigger 654B.

When the receiving device 20 receives the trigger 654C, the DO engine 312 extracts the tag value from the trigger 654C and determines that the trigger is associated with a Type 2 command. In one embodiment, DO engine 312 determines that trigger 654C is associated with a Type 2 command based on a tag value (e.g., a tag value of 16 or greater) that falls outside a predetermined range. In another embodiment, DO engine 312 makes a decision based on the information contained in TPT 656. [ DO engine 312 provides the extracted tag value to TDO1. TDO1 uses the tag value to determine at least one parameter associated with the trigger. TDO1 also performs a function based on at least one parameter.

6D, the receiving apparatus 20 receives the triggers 654D and 654E. These triggers provide the receiving device 20, the DO engine 312, and / or the TDO with a reference point for determining the current media time in the received content. DO engine 312 and / or the executing TDO monitors the current media time to determine if any entries in TPT 656 should be processed. For example, if the DO engine 312 determines that the current media time is 20000, the DO engine executes TDO2 according to the TPT entry with the tag value 21. In another example, if DO engine 312 or TDO1 determines that the current media time is 15000, TDO1 will process or process the parameters contained in the TPT entry with tag value 19. In yet another embodiment, the media time information contained in the trigger itself is used to identify the TPT entry.

The TPT 606 shown in Figures 6C and 6D includes a reference to an image file. As shown in FIG. 6C, one graphic is associated with each tag value or media time. However, TPTs 606 and 656 are not so limited and may refer to one or a combination of different media types, such as audio, video, image, and / or one or more interactive elements. As noted above, predetermined tag values (e.g., below 16) may be specified as the instruction to be processed by the DO engine in the standard. Thus, in one embodiment, the TPT includes only entries for tag value 16 and higher. In another embodiment, TPT entries are provided for all tag values.

For example, when the receiving device 20 receives the trigger 614D with the tag value 16, the DO engine 312 delivers the tag value 16 to the currently executing TDO 159. DO engine 312 passes the tag value by calling the trigger API function supported by DO engine 312 and passes the tag value to TDO 159. [ The trigger API function may be included in a separate programming component of the DO engine 312 or the receiving device 20. The TDO 159 accesses the TPT 616 to determine that the parameters associated with the trigger are "product1.jpg" and numbers 104 and 226. [ In one embodiment, the function performed by the TDO 159 based on the determined parameters includes rendering the image file "product1.jpg" at location X, Y (104, 226)

However, the TPT is not limited to including information about image files and location, but may include media time (as mentioned above) that specifies the timing of any given interactive element, validity information that defines the expiration date of the trigger , An ability code that allows the receiving device 20 to determine whether it can provide TPT or supplemental content associated with a particular TPT entry, and the like. The TPT may include a URL that the TPT may use to fetch the updated parameter set from the Internet server, where the data set represents weather reports, sports scores, player statistics, or any other time-sensitive data. As another example, a TPT may be processed by a receiving device that supports "ATSC 2.7+ ", which is a minimum request code such as support for certain media formats and decoders, essential and non-essential capabilities, Lt; RTI ID = 0.0 &gt; a &lt; / RTI &gt;

Note that in one embodiment, the DO engine 312 itself does not attempt to interpret anything carried in a given row of the TPT instance, such as the row identified by the tag value 21 in the TPT 616. The information contained in the TPT instance can only be known and interpreted by a TDO designed to work together. Thus, the number and type of parameters included in the TPT may be customizable based on the requirements of the associated TDO. That is, the TPT is not limited to including a predetermined set of parameters and may include any parameters required by a particular TDO.

7 shows an information providing apparatus 700 that may be included in a content source 10, a TPT server 40, a TDO server 50, an ACR system 60, or a stand-alone device . As shown in FIG. 7, the information providing apparatus 700 includes a memory 710 and a communication unit 720. The memory 710 may be any type of non-volatile storage device, including, for example, network memory devices, magnetic storage elements, magneto-optical storage elements, flash memory, core memory, and / , &Lt; / RTI &gt; The communication unit 720 may also be implemented using one or a combination of a terrestrial broadcast transmitter, a cable broadcast transmitter, a satellite uplink transmitter, a network interface (e.g., WLAN card, Ethernet card, etc.)

The memory 710 is configured to store a TPT that includes at least one event associated with one or a combination of media time and trigger identifier of the content to be provided to the receiving device. The communication unit 720 provides the TPT stored in the memory 710 to the receiving apparatus 20. [ For example, the communication unit 720 provides the TPT to the receiving device 20 via TS or the Internet. The TPT is provided at the location identified in the trigger included in the closed caption data associated with the content provided to the receiving device.

8 is configured to function as any one or combination of the content source 10, the receiving device 20, the TPT server 40, the TDO server 50, the ACR system 60, and the information providing device 700 Fig. 8 is a block diagram showing an example of the hardware configuration of the computer 800; Fig.

8, the computer 800 includes a central processing unit (CPU) 802, a read only memory (ROM) 804, a random access memory (RAM) 804, ) &Lt; / RTI &gt; One or more buses 808 are also connected to the input-output interface 810. The input-output interface 810 is connected to an input unit 812 formed by a keyboard, a mouse, a microphone, a remote controller, and the like. The input-output interface 810 also includes an output 814 formed by an audio interface, a video interface, a display, a speaker, etc.; A recording unit 816 formed by a hard disk, a nonvolatile memory or the like; A communication unit 818 formed by a network interface, a modem, a USB interface, a FireWire interface, or the like; And a drive 820 for driving a removable medium 822 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory or the like.

According to one embodiment, the CPU 802 loads the program stored in the recording unit 816 into the RAM 806 via the input-output interface 810 and the bus 808, The TPR server 40, the TDO server 50, the ACR system 60, and the information providing device 700. The information processing apparatus 200 is a computer program that is executed by the computer system 100. [

The various processes described above do not need to be processed in chronological order in the order shown in the flowchart; The steps may also include those being processed in parallel or individually (e.g., in a concurrent or object-oriented manner).

In addition, the program may be processed on a distributed basis by a single computer or a plurality of computers. The program may be transmitted to a remote computer or computers for execution.

Also, in this specification, the term "system" refers to a collection of a plurality of components (devices, modules (components), etc.). All of the component elements may or may not be housed in a single enclosure. Thus, a plurality of devices each housed in a separate enclosure and connected via a network are regarded as a network, and a single device formed by a plurality of modules housed in one enclosure is also considered a system.

It should also be understood that the techniques are not limited to the embodiments described above in implementation, and that various modifications, variations, and alternatives to the techniques may be made as long as they are within the spirit and scope of the present technology.

For example, the technology may be organized for cloud computing so that a single function can be shared and collaboratively processed among multiple devices over a network.

Further, each of the steps described with reference to the flowcharts described above may be executed in a manner shared by a plurality of devices as well as a single device.

Further, if one step includes a plurality of processes, these processes included in the step may be performed in a manner shared by a plurality of devices as well as a single device.

Numerous modifications and variations of the present invention are possible in light of the above teachings. It is, therefore, to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Claims (20)

A trigger processing method of a receiving apparatus,
Receiving content from a content source;
Displaying the received content on a display;
Extracting a first trigger from closed caption data associated with the received content;
Triggering information, wherein the trigger information comprises at least one event associated with one or a combination of a first media time and a trigger identifier of the received content, based on the extracted first trigger; Searching;
Extracting from the closed caption data a second trigger indicating that the event is re-timed to a second media time, or a second trigger indicating immediate execution of the event;
Storing the trigger information in a memory of the receiving apparatus; And
Processing the event by the receiving device based on one or a combination of the second trigger including the first media time and the trigger identifier equal to the current media time of the received content
/ RTI &gt; 2. The method of claim 1, wherein receiving the content comprises:
Receiving the content via at least one of a satellite broadcast, a cable television transmission, a terrestrial television broadcast, and the Internet. 3. The method of claim 1 or claim 2, wherein the step of retrieving the trigger information comprises:
Processing program map information of a broadcast virtual channel associated with the received content;
Processing a service signaling channel (SSC) to retrieve service map information;
Discovering the coordinates of a FLUTE (File Delivery over Unidirectional Transport) session;
Obtaining a FLUTE File Delivery Table (FDT);
Comparing the locator-part of the first trigger against the content-location values in the FLUTE FDT until a match is found; And
Retrieving the trigger information based on the matched content-position value
/ RTI &gt; 3. The method of claim 1 or claim 2, wherein the step of retrieving the trigger information comprises:
And performing an internet http GET using the locator-portion of the first trigger. 3. The method of claim 1 or 2, wherein extracting the first trigger comprises:
Extracting the first trigger from non-closed caption text data in a service block having a service number in the range 1 to 6. 3. The method of claim 1 or 2, wherein extracting the first trigger comprises:
And extracting the first trigger from non-closed caption text data in a service block having service number 6. 3. The method according to claim 1 or 2,
Determining the current media time based on the second media time
&Lt; / RTI &gt; 3. The method according to claim 1 or 2,
Associating the event contained in the trigger information stored in the memory with the second media time
&Lt; / RTI &gt; 3. The method according to claim 1 or 2,
Wherein processing the event comprises immediately processing an event associated with the trigger identifier. 18. A non-transitory computer-readable storage medium having stored thereon instructions for causing a computer to perform a method of a receiving apparatus for processing a trigger when executed by a computer, the method comprising:
Receiving content from a content source;
Displaying the received content on a display;
Extracting a first trigger from closed caption data associated with the received content;
Triggering information, wherein the trigger information comprises at least one event associated with one or a combination of a first media time and a trigger identifier of the received content, based on the extracted first trigger; Searching;
Extracting from the closed caption data a second trigger indicating that the event is re-timed to a second media time, or a second trigger indicating immediate execution of the event;
Storing the trigger information in a memory of the receiving apparatus; And
Processing the event by the receiving device based on one or a combination of the second trigger including the first media time and the trigger identifier equal to the current media time of the received content
Gt; computer-readable &lt; / RTI &gt; storage medium. As a receiving apparatus,
A receiver configured to receive content from a content source;
A display interface configured to display the received content;
An extraction unit configured to extract a first trigger from the closed caption data associated with the received content; And
The processor comprising:
Based on the extracted first trigger, trigger information - the trigger information includes at least one event associated with one or a combination of a first media time and a trigger identifier of the received content,
Storing the trigger information in a memory of the receiving apparatus,
The first media time being equal to the current media time of the received content, and a second trigger comprising a trigger identifier, the first media time being equal to the current media time of the received content,
Wherein the extracting unit is configured to extract from the closed caption data a second trigger indicating that the event is to be re-timed to a second media time or that is indicative of immediate execution of the event. 12. The method of claim 11,
Wherein the receiver is configured to receive the content via at least one of a satellite broadcast, a cable television transmission, a terrestrial television broadcast, and the Internet. 13. The system according to claim 11 or 12,
Processing program map information of a broadcast virtual channel associated with the received content;
Processing a service signaling channel (SSC) to retrieve service map information;
Find the coordinates of a FLUTE (File Delivery over Unidirectional Transport) session;
Acquires the FLUTE File Delivery Table (FDT);
Compares the locator-part of the first trigger against the content-location values in the FLUTE FDT until a match is found;
And to retrieve the trigger information based on the matched content-position value. 13. The method according to claim 11 or 12,
Wherein the processor is configured to perform an internet http GET using the locator-portion of the first trigger to retrieve the trigger information. 13. The method according to claim 11 or 12,
Wherein the extracting unit is configured to extract the first trigger from non-closed caption text data in a service block having a service number in a range of 1 to 6. 13. The method according to claim 11 or 12,
Wherein the extracting unit is configured to extract the first trigger from non-closed caption text data in a service block having service number 6. 13. The method according to claim 11 or 12,
Wherein the processor is configured to determine the current media time based on the second media time. 13. The method according to claim 11 or 12,
Wherein the processor is configured to associate the event contained in the trigger information stored in the memory with the second media time in response to the second trigger. 13. The method according to claim 11 or 12,
Wherein the processor is configured to immediately process the event associated with the trigger identifier in response to the second trigger. An information providing apparatus comprising:
A memory configured to store first trigger information comprising at least one event associated with one or a combination of a media time and a trigger identifier of a content to be provided to a receiving device; And
A communication unit configured to provide the first trigger information to the receiving device
/ RTI &gt;
Wherein the first trigger information is provided at a location identified in a trigger included in closed caption data associated with content provided to the receiving device,
Wherein the closed caption data further comprises a second trigger indicating that the event is to be re-timed to a second media time or indicating an immediate execution of the event.

Images