WO2016178319A1

WO2016178319A1 - Carrying multiple event times within a trigger

Info

Publication number: WO2016178319A1
Application number: PCT/JP2016/002220
Authority: WO
Inventors: Kiran M. MISRA; Sachin G. Deshpande
Original assignee: Sharp Kabushiki Kaisha
Priority date: 2015-05-06
Filing date: 2016-04-27
Publication date: 2016-11-10

Abstract

A device for receiving information, the device comprising: a receiver configured to receive a trigger,and a processor configured to process the trigger wherein, the trigger is an element whose function is to identify signaling and establish timing of playout of interactive events, and a syntax of the trigger includes a first information indicating a first set of identifiers relating to a first application and a first event, and an optional second information indicating a second set of identifiers relating to a second application and a second event.

Description

CARRYING MULTIPLE EVENT TIMES WITHIN A TRIGGER

The present invention relates to carrying multiple event times within a trigger. [Background Art]

Interactive television is a convergence between television and computers. Interactive television permits consumers to receive personalized content and in some cases interact with the content. Interactive television also facilitates the inclusion of customized commercial (e.g. advertisement) content targeted to the particular consumer.

The interactive television includes the broadcast of the show together with a data channel associated with the broadcast to be received by a receiver. The broadcast may be in the form of a over-the-air broadcast to a receiver or a network based broadcast, such an Internet based broadcast (e.g. using broadband) or a hybrid broadcast where part of the information is received over-the-air and part of it is received over the Internet e.g. using broadband. The data channel may accompany the broadcast, such as encoding it in the vertical blanking interval or in a watermark in the images. Alternatively, the data channel may be a separate data channel included together with the broadcast. In some cases, the data channel may be a separate channel from the broadcast. A data channel may include embedded uniform resource locators (URLs). The URLs (i.e., the effective addresses of locations or Web sites on the Internet) may be used to retrieve related network based content, such as executable applications.

In some cases, the applications are triggered to be executed by triggers within the data channel. However, sometimes the applications do not terminate properly thus inhibiting the user experience of viewing the broadcast content. Accordingly, it is desirable to trigger the applications in a manner that decreases the likelihood that the user experience of viewing the broadcast content and accompanying application will be decreased.

The foregoing and other objectives, features, and advantages of the invention will be more readily understood upon consideration of the following detailed description of the invention, taken in conjunction with the accompanying drawings.

According to the present invention, there is provided a device for receiving information, the device comprising: a receiver configured to receive a trigger ,and a processor configured to process the trigger wherein, the trigger is an element whose function is to identify signaling and establish timing of playout of interactive events, and a syntax of the trigger includes a first information indicating a first set of identifiers relating to a first application and a first event, and an optional second information indicating a second set of identifiers relating to a second application and a second event.

FIG. 1 illustrates a bitstream with advertisements. FIG. 2 illustrates delivery of a pair of segments. FIG. 3 illustrates delivery of a segment. FIG. 4 illustrates a syntax for a trigger. FIG. 5 illustrates a modified syntax for a trigger. FIG. 6 illustrates a decoder for receiving the bitstream, triggers, and advertisements.

<ACRONYMS USED>
IP: Internet Protocol
TV: Television
HTML: HyperText Markup Language
XHTML: eXtensible HyperText Markup Language
XML: eXtensible Markup Language
CSS: Cascaded Style Sheets
MHEG: Multimedia Hypertext Experts Group
DTG: Digital TV Group
HBBTV or HbbTV: Hybrid Broadcast Broadband TV
OIPF: Open IPTV Forum
DAE: Declarative Application Environment
<DEFINITIONS>
'reserved' － Set aside for future use.

'Trigger' － A signaling element whose function is to identify signaling and establish timing of playout of interactive events.

'Media Time' － A parameter referencing a point in the playout of an audio/video or audio content item. In an example, the parameter value may correspond to real time or wall-clock time. In an example, the parameter value may correspond to UTC (Coordinated Universal Time).

x..y indicates integer values ranging from x to y, both inclusive.

x ∈ {a..b} indicates that x may take on any integer value from a..b
x ∈ {a} indicates that x takes on value a
x ≦ y: x less than or equal to y
x < y: x less than y
x ≧ y: x greater than or equal to y
<DETAILED DESCRIPTION OF PREFERRED EMBODIMENT>
Referring to FIG. 1, a typical broadcast stream consists of a sequence of television programs. Each television program may consist of an underlying video show, which is typically broken up into segments separated by advertisements and/or other interstitial material. The broadcast stream may include a segment of show A, a first advertisement Ad 1, a second advertisement Ad 2, a first segment of show B, a third advertisement Ad 3, a fourth advertisement Ad 4, a second segment of show B, and a fifth advertisement Ad 5. The segments may be generally referred to as show content and the advertisements may be generally referred to as interstitial content. The show content and interstitial content may or may not have an interactive adjunct data service associated with it. The term “interactive service segment” or “segment” refers to a portion of an interactive adjust service that is treated by the broadcaster as an integrated unit. An interactive service segment is typically, but not necessarily, associated with a single show or a single piece of interstitial material.

A model to execute such interactive adjunct data services may include, for example, a direct execution model and a triggered declarative object (TDO) model. In the direct execution model, a declarative object (DO) can be automatically launched as soon as the virtual channel is selected. A virtual channel is said to be “selected” on a receiving device when it has been selected for presentation to a viewer. This is analogous to being “tuned to” an analog TV channel. A DO can communicate over the Internet with a backend server to get detailed instructions for providing interactive features―creating displays in specific locations on the screen, conducting polls, launching other specialized DOs, etc., all synchronized with the audio-video program.

In the TDO model, signals can be delivered in the broadcast stream or via the Internet in order to initiate TDO events, such as launching a TDO, terminating a TDO, or prompting some task by a TDO. These events can be initiated at specific times, typically synchronized with the audio-video program. When a TDO is launched, it can provide the interactive features it is programmed to provide.

The term Declarative Object (DO) can consist of a collection constituting an interactive application. An application may be a collection of documents constituting a self-contained enhanced or interactive service. Documents of an application are, for example: HTML, XHTML, Java, JavaScript, CSS, XML, multimedia files, etc. An interactive application may be capable of carrying out tasks based on input from a broadcaster or viewer.

The term “Triggered Declarative Object” (TDO) can be used to designate a Declarative Object that has been launched by a Trigger in a Triggered interactive adjunct data service, or a DO that has been launched by a Trigger, and so on iteratively.

A basic concept behind the TDO model is that the files that make up a TDO, and the data files to be used by a TDO to take some action, all need some amount of time to be delivered to a receiver, given their size. While the user experience of the interactive elements can be authored prior to the broadcast of the content, certain behaviors must be carefully timed to coincide with events in the program itself, for example the occurrence of a commercial advertising segment.

The TDO model separates the delivery of declarative objects and associated data, scripts, text and graphics from the signaling of the specific timing of the playout of interactive events.

The element that establishes the timing of interactive events is the Trigger.

The information about the TDOs used in a segment and the associated TDO events that are initiated by Triggers is provided by a data structure called the “TDO Parameters Table” (TPT).

A TPT may contain information about TDOs of segments and the Events targeted to them. TDO information may correspond to an application identifier (appID), an application type, application name(s), application version, location of files which are part of the application, information that defines application boundary, and/or information that defines application origin. Event information within a TPT may contain an event identifier (eventID), action to be applied when the event is activated, target device type for the application, and/or a data field related to the event. A data field related to event may contain an identifier (dataID), data to be used for the event. Additionally, a TPT may also contain information about trigger location, version, required receiver capabilities, how long the information within the TPT is valid, when a receiver may need to check and download a new TPT.

Actions control an application’s lifecycle. Actions may indicate to which state an application may transition.

In an example, event(s) may correspond to application lifecycle control action(s).

In an example, application lifecycle control action(s) may correspond to event(s).

An Application Information Table (AIT) may provide information on for e.g. the required activation state of applications carried by it, application type, application profile, application priority, application version, application identifier (appID) etc. Data in the AIT may allow the broadcaster to request that the receiver change the activation state of an application. Note － An AIT may contain some data elements which are functionally equivalent to some data elements in TPT.

Application profile may identify profile required by the application. A receiver implementing the application profile is capable of executing the application. In an example, the application profile may corresponds to features required by that application e.g. Audio/Video content download feature, Personal Video Recorder feature. In an example, it may be required that all receivers implement a set of features that corresponds to a profile (e.g. basic profile, minimum profile, universal profile) and applications corresponding to this profile can be executed by the receiver. In an example, features may correspond to identifiers called capability codes.

Application priority may indicate the priority of the application relative to other applications (which may be signaled).

Application type may be communicated by means of an ID. This mapping may be maintained by a registering authority for e,g, Digital Video Broadcasting (DVB), Advanced Television Systems Committee (ATSC). An example mapping between ID and application types is listed in Table (1) below:

An Activation Messages Table (AMT) contains the equivalent of the Activation Triggers for a segment. It is typically generated by the content creator, and in some scenarios it might be delivered to receivers in lieu of individual Activation Triggers.

An application lifecycle control information may instruct that an application starts automatically when a service is selected.

An application lifecycle control information may instruct that an application may be allowed to run when a service is selected, but the application does not run automatically on selection of a service.

An application lifecycle control information may instruct stopping a running application or instruct that the application cannot be started.

An application lifecycle control information may instruct that application files should be fetched/cached by a receiver, if possible.

An application lifecycle control information may instruct that a running application should be suspended. Access to some resources may be denied for suspended applications. Passing of a set of events to event listeners may not be carried out for suspended applications.

An application lifecycle control information may instruct that application may be disabled and cannot be started.

The trigger is a signaling element whose function is to identify signaling and establish timing of playout of interactive events. Triggers can perform various timing-related signaling functions in support of interactive services. Triggers can be multi-functional; depending on their structure, a particular Trigger instance can perform one or more of the following functions:

It is to be understood that in an example embodiment information contained within TPT, AIT, AMT may be re-organized in any suitable fashion. It is to be understood that in an example embodiment all or some of the information contained within TPT, AIT, AMT may be moved to other table(s).

Referring to FIG. 2, a trigger operation is described by way of an example. FIG. 2 is a diagram showing an embodiment of trigger timing in case of pre-produced content. The triggers are delivered in association with two programming segments. In this example, both segments are “pre-produced,” meaning that the content is not from a live broadcast (for e.g. when all the content is available before it is transmitted); interactive elements have been added in post-production.

As shown, a short time prior to the occurrence of programming segment 1, a “pre-load” Trigger can be delivered to allow receivers an opportunity to acquire associated data structures containing application, event, application lifecycle control, data information for e.g. the TPT, AIT, AMT etc., and interactive content associated with programming segment 1. If a pre-load Trigger is not received because it was not transmitted, receivers can be expected to use the first Trigger they see within the segment to acquire the content.

Triggers can be sent throughout segment 1, as shown, to indicate the current Media Time (labeled “m” in the figure) relative to the segment. Periodic delivery of Media Time Triggers can be necessary to allow receivers who are just joining the channel to synchronize and acquire the interactive content. Just prior to the beginning of segment 2, a pre-load Trigger for that upcoming segment is sent.

In the case of pre-produced content (non-live), the receiver can acquire associated data structure containing application, event, application lifecycle control, data information for e.g. using TPT, AIT, AMT, after processing the first Trigger. The acquired information can define the timing of all elements of the interactive experience for that segment. All that is needed for the receiver and TDO to play out the interactive elements can be the knowledge of the media timing; the acquired associated information can describe interactive events relative to Media Time.

Referring to FIG. 3, for the case of live content, the acquired associated data structure e.g. TPT, AIT, AMT, may contains data and information pertinent to different interactive events, however the timing of playout of those events can be known only as the program unfolds during the broadcast. For the live case, the “event-timing” function of the Trigger is utilized. In this mode, the Trigger can signal that a specified interactive event is to be re-timed to a specified new value of Media Time. Alternatively, the Trigger can indicate that a certain event is to be executed immediately.

In an example, for the live case the trigger may contain information controlling life-cycle of application(s). In this mode, the Trigger can signal that a specified interactive event is to be re-timed to a specified new value of Media Time. Alternatively, the Trigger can indicate that a certain event is to be executed immediately.

The functions of triggers of segment 3 of FIG. 3 are now described.

A first trigger 300 is a pre-load trigger, which refers to a directory of files for segment 3.

A second trigger 310 is a media time trigger which is used to indicate the playout timing of segment 3.

A third trigger 320 is an event re-timing trigger and indicates that the event with eventID=2 in the acquired associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT is to be re-timed to occur at Media Time 240. The area indicates the time interval prior to 240 over which Trigger #3 may be delivered to receivers.

A fourth trigger 330 is a media time trigger.

A fifth trigger 340 is an event re-timing trigger and indicates that the event with eventID=5 in the acquired associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT is to be re-timed to occur at Media Time 444.

A sixth 350 and seventh 360 triggers are media time triggers.

An eighth trigger 370 is an event Trigger and indicates that the event with eventID=12 in the acquired associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT is to be executed immediately.

A ninth trigger 380 is an event re-timing Trigger and indicates that the event with eventID=89 in the acquired associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT is to be re-timed to occur at Media Time 900.

A Trigger containing a <media time> parameter is called a Time Base Trigger, since it is used to establish a time base for event times.

A Trigger containing an <event time> parameter is called an Activation Trigger, since it sets an activation time for an event.

Referring to FIG. 4, the trigger syntax may include both Activation messages and Time Base messages that can have the following general “Trigger” format under certain delivery circumstances. The syntactic definition may be described using the Augmented Backus-Naur Form (ABNF) grammar, except that the vertical bar symbol “I” is used to designate alternatives. Rules are separated from definitions by an equal “=”, indentation is used to continue a rule definition over more than one line, literals are quoted with “ ”, parentheses “(” and “)” are used to group elements, optional elements are enclosed in “[” and “]” brackets, and elements may be preceded with <n>* to designate n or more repetitions of the following element; n defaults to 0.

When defining a syntax the following terms may be used:

In one embodiment the following 7-bit ASCII representation may be used for the terms:

When defining a syntax the operator "*" preceding an element indicates repetition. The full form of the operator is:

This Trigger syntax is based on the Uniform Resource Identifier (URI): Generic Syntax as defined in IETF RFC 3986, excluding the <scheme> and “://” portion, with additional restrictions.

The trigger may include a locator_part and terms. terms may be omitted. If terms are present, locator_part and terms may be connected by ‘?’.

The locator_part may include a hostname part and a path_segments part, which may be connected by ‘/’.

The hostname may include domainlabel and toplabel, and domainlabel may be repeated 0 times or more along with ‘.’. That is, hostname may include repeated domainlabel connected with toplabel or include only toplabel.

domainlabel may include one alphanum, or include alphanum or “-” repeatedly inserted between alphanum and alphanum 0 times or more.

toplabel includes one alpha, or include alphanum or “-” repeatedly inserted between alpha and alphanum 0 times or more.

path_segments includes one segment, which is followed by segment repeated 0 times or more. segment’s may be connected by ‘/’.

segment includes alphanum which is repeated once or more.

terms may include one of event_time or media_time, which may be followed by spread, or version, or others. spread, version, and others may be omitted. If spread, version, and others are present, then a ‘&’ may be placed ahead of spread, version, and others and also spread, version, and others may be placed after event_time or media_time.

Spread may include digit repeated once or more after ‘s=’.

event_time may include two terms, an interactive eventID designated by “e=” followed by two or three decimal numbers with a dot (“.”) separating them, referencing the appID in the associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT of the TDO targeted by the event, the eventID of the specific event, and optionally the dataID of the Data element to be used for this event activation, plus an optional timing value term designated by “t=” followed by a string 1 to 8 characters in length representing a hexadecimal number indicating a new media timing for the designated event. If the “t=” part is not present, that means the timing for the designated event is the arrival time of the Trigger.

media_time may include two terms, a media timestamp term designated by “m=” followed by a character string of 1 to 8 characters in length representing a hexadecimal number indicating the current Media Time for e.g. in units of milliseconds, and an optional contentID term designated by “c=” followed by a character string representing an identifier for the content currently being viewed. The contentID term is intended to support the Direct Execution model of interactive service implementation. In that model Time Base Triggers are passed in to the DO after it is launched, and the DO delivers the contentID to the backend server in order to identify the context for the interaction.

version may be a term designated by “v=” followed by a character string of 1 to 3 characters in length representing a decimal number indicating the version of the data structure(s) containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT associated with this Trigger. Receivers are expected to process the version parameter to identify the need to acquire an updated associated data structure(s) containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT.

spread may be a term designated by “s=” followed by a character string of 1 to 3 characters in length representing a decimal number indicating when receivers should attempt to access the Internet server identified in the Trigger. In an example, the character string indicates the time (e.g. in number of seconds/milliseconds), over which all receivers should attempt to access the Internet server identified in the Trigger. Each individual receiver is expected to derive a random time within the designated interval and delay the access request by that amount, thereby spreading in time the peak in demand that might otherwise occur at the first appearance of a Trigger at the receiver. In another example, the character string indicates the time which should elapse before a receiver may attempt to access the Internet server identified in the Trigger.

other is a term designated by a character other than "e", "E", "m", "M", "s", "S", "t", or "T", followed by the equals-sign and an alphanumeric string. Receivers are expected to disregard unrecognized terms.

others may include 1 or more other.

other may include resv_cmd or user_cmd and alphanum which are repeated once or more and are connected by ‘=’.

resv_cmd may be alphanum excluding ‘c’, ‘e’, ‘m’, ‘s’, ‘t’, or ‘v’.

user_cmd may be upalpha
lowalpha may equal lowercase “a” through “z”. upalpha may equal uppercase “A” through “Z”. Digit may equal “0” through “9”. Hexdigit may equal “0” through “9” and “a” through “f”.

In an example, the length of the trigger may not exceed 52 bytes. In addition, the hostname portion of the Trigger can be a registered Internet domain name.

A Trigger can be considered to consist of three parts.

<domain name part>/<directory path>[?<parameters>]
The <domain name part> can reference a registered Internet domain name. The <directory path> can be an arbitrary character string identifying a directory path under the control and management of the entity who owns rights to the identified domain name.

In the TDO model, the combination of <domain name part> and <directory path> can uniquely identify an associated data structure containing application, event, application lifecycle control, data information e.g. TPT, AIT, AMT that can be processed by a receiver to add interactivity to the associated content.

In the direct execution model, the combination of <domain name part> and <directory path> can uniquely identify the DO to be launched.

The <parameters> portion of the Trigger is optional. When present, it can convey one or more parameters associated with the trigger.

For the trigger syntax listed in FIG. 4, the following cardinality combinations of application (ac), event (ec), data (dc), event time (et) and media time (mt) as shown in Table (2) is allowed.

Each row corresponds to a valid cardinality combination.

The cardinality combination listed in second row of Table (2) corresponds to a trigger carrying 1 field for application, 1 field for event, 0 or 1 field for event data, 0 or 1 field for event time and no media time field.

The cardinality combination listed in third row of Table (2) corresponds to a trigger carrying only a media time field.

In a example, events may correspond to application lifecycle control actions.

The trigger may identify the location of an associated data structure containing application, event, application lifecycle control, data information e.g. the TPT, AIT, AMT using <domain name part> and <directory path>. The trigger through <domain name part> and <directory path>, can identify the application to be launched.

As described the lifecycle of applications can be controlled using triggers. A first trigger may be used to instantiate an application, and subsequently a second trigger may be used to terminate an application. Unfortunately, since the second trigger is not included with the first trigger, if the second trigger is lost due to a transmission outage or unrecovered watermarks carrying trigger metadata, the application event associated with the second trigger may never occur. By way of example, if the application associated with the first trigger is not terminated by the second trigger, there may be cases where the broadcast will not be returned to the show which is disruptive to the user’s experience. Thus, the triggering technique should be suitable to guarantee that a return to the show occurs at the end of a commercial break. Furthermore, the triggering technique with additional syntax that is capable of guaranteeing a return to the show (e.g., second trigger) should be facilitated in a transparent manner to the underlying triggering technique. In an example, a commercial is served during the break by executing an application. The application may fetch the commercial (or a part thereof) prior to start of break, starts showing the commercial at the start of a break and stops running when the break is over.

As illustrated in FIG. 4, the syntax is limited to a single event time per trigger, which implies that an application life cycle events, for example corresponding to (i) start showing ads (ii) return to network programming, which occur at different time instances require the signaling of multiple triggers. To achieve the capability to guarantee the termination of an application, the syntax may be modified to optionally carry more than one event time information in the signaling. In this manner, a single trigger is capable of carrying multiple event times. As an example, carrying different event times allows a single trigger to carry timing information for both start of a commercial break and return to network programming thus guaranteeing that a receiver gets either both pieces of information or none.

Referring to FIG. 5, a technique to achieve multiple event time information using a single trigger may be achieved by modifying the event_time to further include more than one event with the same event_time_string. For example, the event_time_string 500 may include a first digit for the appID 510, a second digit for the eventID 520, a third digit for the dataID (optional) 530, together with one or more additional sets of two or three digits 540. The additional set(s) of two or three digits likewise would be representative of a fourth digit for the appID 550, a fifth digit for the eventID 560, and a sixth digit for the dataID (optional) 570. In this manner, event_time_string can reference multiple sets of appID/eventID/dataID, where each of the sets may be different from one another. For example, the event_time_string may represent the events to suspend the currently running application and start a different application, and both of these events are to occur at the same time. Since both the suspension of the currently running application and the starting of the different application are provided in the same event_time_string, either both events will occur or neither of the events will occur if the event_time_string is lost in transmission.

The syntax may achieve sending multiple events, each of which with a different time, with the same trigger by modifying the event_time syntax to further include more than one event_time_string with the same event_time. Each of the event_time_string’s included in the event_time may have a different time indication as indicated by the “&t=” 580 of the corresponding event_time_string. It is noted that if the “&t=” is omitted, then the events corresponding to the event_time_strings would occur at the same time.

The semantics of the <event time> of FIG. 5 may be characterized as two terms, an interactive event ID designated by “e=” followed by two or three decimal numbers with a dot (“.”) separating them, referencing the appID, the eventID of the specific event, and optionally the dataID of the Data element to be used for this event activation. Other sets of (appID,eventID)/ (appID,eventID,dataID) may be optionally specified as well. An optional timing value term designated by “t=” followed by a string of 1 to 8 characters in length representing a hexadecimal number indicating a new media timing for the designated event(s) specified just prior to the timing value term. If the “t=” part is not present, that refers to the timing for the designated event(s) is the arrival time of the Trigger.

By way of example, a target ad scenario may be signaled by the following:

The above may correspond to application lifecycle control actions where an application with identifier appID0 is started at break_start_time and killed at break_end_time. The application with identifier appID0 may show targeted advertisement during the break interval.

The syntax in FIG. 5 also allows specifying multiple events with a single event time (e.g., common_time), which may be needed for suspending the execution of an application (e.g., with identifier appID1) which is already running and starting the execution of another application (e.g., with identifier appID1). This may be signaled by the following:

Another variant for the Trigger syntax may be as follows:

In this variation str is repeated to achieve the specification of multiple event times.Another variant for the Trigger syntax may be as follows:

In this variation, the event_time is repeated to achieve the specification of multiple event times.

With the modified trigger syntaxes described above and in FIG. 5, the following cardinality combinations of application (ac), event (ec), data (dc), event time (et) and media time (mt) as shown in Table (3) are allowed.

N may be any pre-determined value.

The cardinality combination listed in second row of Table (3) corresponds to a trigger carrying 1 or more or field(s) for application; as many event field(s) as there are application field(s); event data field(s) that are at most as numerous as application field(s); event time field(s) that are at most as numerous as event field(s) and no media time field.

The cardinality combination listed in third row of Table (3) corresponds to a trigger carrying only a media time field.

In an example, events may correspond to application lifecycle control actions.

In an example if multiple event times are specified together, with no other type of field specified in between, within a trigger, then one of the event times may be chosen as the event time associated with corresponding event(s). In an example if multiple event times are specified together, with no other type of field specified in between, within a trigger, then the leftmost event time within the group of event times is selected for the corresponding event(s). In an example if multiple event times are specified together, with no other type of field specified in between, in a trigger, then the rightmost event time within the group of event times is selected for the corresponding event(s). In an example if multiple event times are specified together, with no other type of field specified in between, in a trigger, then the event time at a particular location within the group of event times is selected for the corresponding event(s). In an example trigger syntax it is not allowed to specify multiple event times together, with no other type of field specified in between.

When et equals ec then each event time may be associated with an event.

When et < ec, then rule(s) associating action for application with corresponding event times may be defined.

In an example, when decoding a trigger from 'left-to-right', action for a group of application(s) is carried out at event time signaled just 'after' the group of application(s) and their corresponding actions. If no event time is present 'after' a group of application(s) and their corresponding actions then the action corresponding to the group of application(s) is carried out at a pre-determined time (for e.g. trigger arrival time).

In an example, when decoding a trigger from 'left-to-right', action for a group of application(s) is carried out at event time signaled just 'before' the group of application(s) and their corresponding actions. If no event time is present 'before' a group of application(s) and their corresponding actions then the action corresponding to the group of application(s) is carried out a pre-determined time (for e.g. trigger arrival time).

In an example, when decoding a trigger from 'right-to-left', action for a group of application(s) is carried out at event time signaled just 'after' the group of application(s) and their corresponding actions. If no event time is present 'after' a group of application(s) and their corresponding actions then the action corresponding to the group of application(s) is carried out a pre-determined time (for e.g. trigger arrival time).

In an example, when decoding a trigger from 'right-to-left', action for a group of application(s) is carried out at event time signaled just 'before' the group of application(s) and their corresponding actions. If no event time is present 'before' a group of application(s) and their corresponding actions then the action corresponding to the group of application(s) is carried out a pre-determined time (for e.g. trigger arrival time).

In general, a modified trigger syntax may support carrying information for one or more of the following associations:

The association between events-group and event time may be determined based on the location of events-group and event time within the trigger. Specifically:

The association between actions-group and event time may be determined based on the location of acions-group and event time within the trigger. Specifically:

In an example, a timing value is optionally specified for each event designated by “t=” followed by the event time value. A set of event(s)/action code(s) use the event time value specified by the first occurrence of the “t=<event_time>” element/ parameter following it. If no ”t=<event_time>” element/ parameter is specified following a a set of event(s)/action code(s) then the event time for those designated event(s)/action code(s) is the arrival time of the Trigger.

In an example, the trigger syntax may be modified to include:

Referring to FIG. 6, a receiver may use a direct execution model. A similar model may be used for a triggered declarative object. A receiver may receive a broadcast signal by a tuner or otherwise. The broadcast signal may further include a trigger containing information that identifies the currently broadcast content. A trigger module may parse the broadcast signal and obtain the trigger. The trigger module may launch the application identified, and obtain a media time stamp and a content identifier. For example, the media time stamp may identify a current point in the playout of the content, such as the content being viewed. The application may be obtained through a network interface from a server.

In an example, a receiver may use a direct execution model. A similar model may be used for a triggered declarative object. A receiver may receive a signal by broadband. The broadband signal may further include a trigger containing information that identifies the currently received content. A trigger module may parse the broadband signal and obtain the trigger. The trigger module may launch the application identified, and obtain a media time stamp and a content identifier. For example, the media time stamp may identify a current point in the playout of the content, such as the content being viewed. The application may be obtained through a network interface from a server.

The terms and expressions which have been employed in the foregoing specification are used therein as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding equivalents of the features shown and described or portions thereof, it being recognized that the scope of the invention is defined and limited only by the claims which follow.

Claims

A device for receiving information, the device comprising:
a receiver configured to receive a trigger ,and
a processor configured to process the trigger wherein,
the trigger is an element whose function is to identify signaling and establish timing of playout of interactive events, and
a syntax of the trigger includes
a first information indicating a first set of identifiers relating to a first application and a first event, and
an optional second information indicating a second set of identifiers relating to a second application and a second event.