WO2012154541A1

WO2012154541A1 - Broadcast-initiated delivery of auxiliary content using triggers

Info

Publication number: WO2012154541A1
Application number: PCT/US2012/036479
Authority: WO
Inventors: Cedric ARNAUD-BATTANDIER; Gerrit De NOOIJER; Hendrik Willem DEN BOK; Klaas-Pieter LOOREN DE JONG
Original assignee: Thomson Licensing
Priority date: 2011-05-06
Filing date: 2012-05-04
Publication date: 2012-11-15

Abstract

The present disclosure involves the synchronization of auxiliary content from a server with primary content from a broadcaster or content owner. The play-out center/broadcaster, in a general sense, represents a facility where content is transmitted from such a location and such content can be transmitted to a service provider that can be a satellite, cable, telecom, mobile or over the air terrestrial broadcaster for transmission to a device such as a television (or any other primary screen in the home). The auxiliary content to resides on a server for delivery to a consumption or second screen device through a communication network or broadband connection and to be synchronized with the viewing of the content on the main screen.

Description

BROADCAST-INITIATED DELIVERY OF AUXILIARY CONTENT USING

TRIGGERS

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Serial No. 61/483,178 filed May 6, 2011 and U.S. Provisional Application Serial No. 61/494,552 filed June 8, 2011, which are incorporated by reference herein in their entirety.

Background

Technical Field

The present invention generally relates to providing additional content related to displayed content.

Description of Related Art

Traditionally additional content related to a displayed movie or program is only available to a user via physical media such as a DVD or Blue Ray disc wherein such material is provided as supplemental materials on a DVD or Blue Ray disc. In instances where such additional content is available (such as a Wiki) there is no correlation between the supplemental materials and the main movie or program.

Summary

The present disclosure is to be able to implement an early stage second-screen experience with a relatively short time to market, staying close to existing platforms and existing technology. Especially the installed base in the households should preferably remain untouched to dodge barriers that could slow down acceptance and embrace of the public.

A solution is found in establishing the connectivity between first screen and second screen where such a relationship is not designated in the living room in an architecture where the first screen and the second screen can receive content from at least one source that is different source. That is, the two paths of both content and interactive data remain independent, and timing is attached in the play-out of the content. The second screen operates independently of the first screen, and the user is just invited through broadcasted content to log on to a specified Web application with the second screen, which could e.g. be an iPad, PC, cellular phone, and the like. Knowing that the web application will greatly enhance the user's experience, it is supposed to be likely that users will be prepared to manually synchronise to the Web application.

It is expected, that the synchronisation accuracy will have some tolerance of several seconds due to variations in distribution networks resulting in different delays between broadcasted and interactive content. This will not be critical for many of the possible applications. Advertising or background interactive information for example are not critical in timing, as long as it still fits within a window of some minutes where it is broadcast content related. An accuracy of some seconds will be achievable in almost all situations.

Once logged in to the relevant Web application, the second screen device receives information updates continuously that follow the actual broadcasted content.

Generally speaking, at the play-out side, time codes are tagged to the broadcast content and triggers are scheduled using the same time codes. The triggers are connected directly to the Web application server. Each trigger will force the Web application server to publish updates to the Web content instantly to all connected devices. Through the broadband network, the second screen device of the user will show the updated content. From the user's experience, the second screen remains in sync by this mechanism. In accordance with one embodiment, a method of synching auxiliary content related to primary content being transmitted is provided. The method involves receiving a play-out list comprising timing information for the transmission of primary content and events corresponding to auxiliary content, transmitting the primary content to a primary screen device in accordance with the play-out list, and transmitting event data to a server for pushing out auxiliary content in accordance with the play-out list.

In accordance with another embodiment, a system for synching auxiliary content related to primary content being transmitted is provided. The system includes a play-out center and a server. The play-out center is configured to receive a play-out list comprising timing information for the transmission of primary content and events corresponding to auxiliary content, transmit the primary content to a primary screen device in accordance with the play-out list, and send event data to a server for pushing out auxiliary content in accordance with the play-out list. The server is configured to receive the transmitted event data at the server and push out auxiliary content in response to the received event data.

Brief Description of the Drawings

Figure 1 is a system diagram outlining the delivery of video and audio content in accordance with one embodiment.

Figure 2 is another system diagram outlining delivery of video and audio content to the home in accordance with one embodiment.

Figure 3 is a diagram depicting a play-out list in conjunction with a delivery system in accordance with one embodiment.

Figure 4 is a diagram depicting another play-out list in conjunction with a delivery system in accordance with one embodiment.

Figure 5 is a diagram depicting a play-out list in accordance with one

embodiment.

Figure 6 is a diagram depicting another play-out list in accordance with one embodiment.

Figure 7 is a flow diagram depicting an exemplary process in accordance with one embodiment.

Figure 8 is a diagram depicting an exemplary methodology of synching

between devices in accordance with one embodiment.

Figure 8 is an exemplary user interface for configuring events in accordance with one embodiment.

Figure 9is another exemplary user interface for configuring events in

accordance with one embodiment.

Figure 10 is another exemplary user interface for configuring events in

accordance with one embodiment.

Figure 1 lis another exemplary user interface for configuring events in

accordance with one embodiment.

Detailed Description

Specifically, the present disclosure involves the synchronization of auxiliary content from a server with primary content from a broadcaster or content owner. The play- out center/broadcaster, in a general sense, represents a facility where content is transmitted from such a location and such content can be transmitted to a service provider that can be a satellite, cable, telecom, mobile or over the air terrestrial broadcaster for transmission to a device such as a television (or any other primary screen in the home). In addition from the play-out center, the content can be delivered in a video on demand setting such as video over IP or in other methodologies known in the art.

The primary or broadcast content is known as the television shows or other types of programming that are traditionally broadcasted from a television broadcaster. Examples of primary content includes, but is not limited to, sports show, tv series, movies, talk shows, news programs and the like. It is expected that primary or broadcast content is meant for a primary screen device such as a television, although other devices can be used as a primary screen device (such as a mobile phone, tablet, PC, and the like). For example, broadcast content typically has breaks known as advertising breaks for commercials are placed within such advertising breaks and shown at such periodic times. In association with premium content from a broadcaster such as HBO or Showtime, there may not be commercials, but there may be a need to have supplemental auxiliary content with the broadcast content, as explained below.

Auxiliary content represents any secondary content related to the primary content and can include trailers, video games, interactive content, webpages, advertising, shopping, coupons, social networking related content and other sort of "special features". The present disclosure allows for such auxiliary content to reside on a server for delivery to a consumption or second screen device through a communication network or broadband connection and to be synchronized with the viewing of the content on the main screen. This ability allows a content producer to re-utilize the special features that they create related to their content, where such content can enrich and complement as to be

synchronized with broadcast account.

In some embodiments of the present disclosure, a generic play-out list (which uses fixed events) can be used for designating when content and advertisements are to be transmitted to a primary screen device. This is unlike a tradition playlist which is supplied by a broadcaster where programming and commercials are designated in a relative fashion. For example, when using a playlist, a broadcaster designates that a commercial break is 10 minutes within a program. This is contrasted with the presented play-out list where a specific time (10:30:00 UTC) is used for the transmission of content, commercial, or auxiliary content. It is to be appreciated that regardless of whether a play-out list or playlist is used, or a combination of the two, the concepts of the embodiments listed below can be used for having triggers that cause a server to push auxiliary content.

A play-out list is used at the point of the broadcaster/play-out center to denote when primary or broadcast content is played and when commercials are to be inserted within the broadcast content. The structure of a play-out list can be as generic as using content identifiers and a series or time stamps designated when such content is to be played, although other play-out lists are known. One aspect of the current disclosure provides in addition event data such as time triggers that can be added to the play-out list where each of these time triggers are then transmitted to the server hosting the auxiliary content events to be played on any output device with a screen such as a mobile phone, tablet, media player, or other type of generic entertainment device which consumes content. These time triggers, are linked to the play-out list. Auxiliary content can be either denoted by its own IDs or be elements providing the information to play the first scheduled event which can be for example metadata or instructions indicating what auxiliary content to play. Auxiliary content can also contain a time stamp indicating the exact moment when the auxiliary information is to be presented to the viewer, in which case the trigger can be sent in advance. These triggers with the respective times that they are supposed to be played would then be transmitted via a connection to a server which would provide or push that auxiliary content at the specified time noted in the play-out list.

Table 1 represents a generic play-out list, although other playlists can be used in accordance with the principles listed herein. Timestamp information (for any device) is coordinated against an external time source and/or the internal time play-out source, where the content reaches the devices in FIG. 1 and FIG. 2 can use a common time reference within seconds or less depending on the delivery network.

ProgramA and ProgramB represent broadcasted programming that is played-out for broadcast or transmission by a broadcaster/play-out center at the specified time listed by Time Stamp. Likewise, CommericalA and CommericalB are advertisements that are played between the segments of programs. Again, the timestamp information indicates when the content corresponding to a content ID is played out. EVENTS represent the auxiliary content that is meant to be provided or pushed by the server at the time specified by the Time Stamp. The XML file for the events is instructions that server can use to push specified auxiliary content. The form of auxiliary content can be in the form of video, audio, pictures, flash animations, HTML5 content, web pages, HTML code, JavaScript, and the like.

TABLE 1

In tandem, the broadcast programming would be capable of being used by different output devices such as a television set, set top box, and the like. Hence, by using the play out list one can specify both when broadcast programming is transmitted for broadcast and in addition have auxiliary content be synchronized and provided or pushed out to media devices based on the time trigger information in the playlist. The advantage to the present disclosure is that all the content does not have to originate from one source i.e., the broadcaster. In the present disclosure, a flexible system is described for content delivery where two types of content (primary and auxiliary) can be delivered in synchronized at the same time, for delivery on one or two separate devices. Such delivery will be explained in more detail below. One aspect of the present disclosure is that the disclosure does not require any uplink/return path from the home to identify and notify the delivery of content to the main screen while still providing a synchronized auxiliary content being delivered to secondary screens.

In the system 100 of Figure 1 a broadcaster/play-out center 110 utilizes a play-out list to designate when primary content is transmitted for delivery to a primary display device such 120 as a television. The broadcaster 110, in the play-out list has events which correspond to auxiliary content. The transmission of primary content can be transmitted directly from a play-out center 110 to a television 120 through various transmission modalities 130 such as cable, IPTV, TCP/IP, satellite, over the air terrestrial broadcast, and the like. Alternatively there can be a service provider that relays the broadcast content from the play out center to the television device where the modalities listed previously can be used by such a service provider.

From the play-out center/broadcaster 110, there exists a communication link 140 to a server 150. The play-out center/broadcaster 110 in accordance with information that is designated in the play-out list will transmit information representing events and times that such events should be provided or pushed to second screen consumption devices 160 such as mobile phones, tablets, entertainment devices, media players, computers, and the like. As previously described above, the content ID can be any type of identifier which corresponds to content which can be for example a URI. In addition, the time trigger information represents the time that such content which corresponds to the content identifier is to be provided or pushed to a second screen media consumption device 160. Within the setting of Figure 1, the server 150 when it receives the event data including content ID and/or time information, will access its own reserves and push out the content that corresponds to the event at the specified time. One thing to note about this disclosure is that a television 120 does not need to be the primary screen. For example, as stated earlier, a first consumption device such as a mobile phone, tablet, personal computer, and the like can operate as the primary screen, while a second consumption device can operate as the second screen device for receiving the auxiliary information. On the consumption side, a consumption device 160 such as those represented by the mobile phone, tablet, entertainment device, and the like in FIG. 1, can be running a browser which is connected to the server 150. The operation of a browser where the server can update the browser with new content by using a browser refresh command, a Post command in reference to a framework such as REST, a JavaScript event handler, and the like. Alternatively, the consuming device 160 can be running a client program such as Silverlight, Adobe Flash, Adobe Air, and the like where audio and video is provided or pushed to the client program. As a second alternative, the consuming device can be running an application (BD-Live compatible, for example) that is developed specifically for the reception of the auxiliary content which would be provided or pushed from the server to the consuming device. As a third alternative, an application which is loaded with preload content for a consuming device, where the server can tell the consuming device to output specified content and/or have external content provided or pushed to the consuming device from the server. Figure 2 represents a different system 200 where at a specified time the server 150 will negotiate with a separate content server 210 for the delivery of such content to be provided or pushed to various consumption devices. The location of such content servers 210 can reside in the instructions of the EVENT XML file, or can be located internal to a look up list present within the server 150 that receives the event data. In FIG. 2, the same concepts as described above in regard to Figure 1 can be applied. Some differences in the framework can be that the server(s) (150 and/or 210) can interact with an entertainment device 220 (as a consumption device) and the server can also interact with connected television 230. In this embodiment, it is possible to completely eliminate the use of an external consumption device (i.e., the entertainment device 220), where the connected television or the primary connected device providing the content (be it a STB, a gateway, a game console, etc) and will get content from both the server (150 and/or 210) through a bi-directional communication path and the broadcaster/play-out center 110. It is still expected that most situations will have auxiliary content outputted on the entertainment device 220 while the primary broadcast content will be outputted on the television 230 regardless whether it is connected.

An alternative embodiment to the present invention can utilize the communication interface 240 between the primary connected device or television 230 and the entertainment device 220 such that the connection television or main connection device 230 can query whether or not the entertainment device 220 is active. If the entertainment device 220 is active, the auxiliary content will be delivered to the entertainment device 220 for output while the primary broadcast content can be outputted on the connected television or primary screen 230 whether through the broadcast signal transmitted to the TV or through a notification to sync with the adequate web service from a web server. If the connected television or primary connected device 230 determines that the entertainment device 220 is not active, the auxiliary and primary broadcast content can then be outputted on the primary screen 230 (for example the TV). The inventors recognize that the event data can limit the playback of auxiliary content to specific output devices. Hence, in an optional embodiment, there can be information that restricts the playback of content to an entertainment device 230 (or a specific type of consumption device 160 such as a mobile phone, tablet, PC, and the like). Hence, even though different types of consumption devices 160 can be running the same platform (such as Android or Windows 7), the server can limit playback to the Android or Windows platform running on a specific manufacturer's devices (Technicolor), and restrict the playback of other manufacturer's devices (Samsung/LG/HTC/Motorola, etc.) or service providers (ATT, Verizon). This case, for a business rule, can be expanded to consider that specific auxiliary content can be made available for a specific platform (Android) and restricted from a second platform (Windows 7/ Apple OS v. 4 or 5). Other variations are possible in accordance with the principles of the present disclosure. This additional restriction can be noted as metadata transmitted to the server of FIGS. 1-4.

A presentation of restrictive metadata for content is represented in Table 2 below in an additional field of metadata, called permissions, is used. The field "+" means that the auxiliary content will be provided or pushed to a second screen device 160, 230 while a "-" means that the auxiliary content will not be provided or pushed to the second screen device 160, 230. The attributes of a second screen device 160, 230 are determined by referencing something such as the MAC address, IP address, and the like where the ISP, manufacturer, and operating of the device can be determined (as representative fields). When specifying for example that +ATT and +IOS comports means that a device that is running on a ATT service using Apple IOS, the auxiliary content will be provided or pushed to that device. While a device with a -ANDROID will not receive such auxiliary content (as for EVENT A). For EVENTC, the determination is made based on a device's manufacturer where for ANDROID, devices made by LG and Technicolor will receive the auxiliary content, while devices made by Samsung, will not. Other examples can be made in accordance with these principles.

TABLE 2

The system 300 of FIG. 3 introduces a concept of a playlist version of a play-out list 310 where a broadcaster designates to a play-out center 110 a specific order of programming and commercials that are to be transmitted by the broadcast center 110.

Specifically, such a playlist 310 is going to be relative to attributes of the program content itself, where a commercial break is designated to be at a certain point in the program content (10 minutes into a program), instead of being at a specific time (10:30:00 UTC 2/12/2011). This relative aspect of the playlist 310 gives a play-out facility 110 a bit of flexibility that does not reside in the use of a play-out list that uses an absolute play-out

(i.e. a specific time for playback). Specifically, the playlist version of the play-out list will have a series of events that are noted to be "x time" into the playback of content (in the present case, Adl is 15 minutes into playback and Ad2 is 16 minutes in playback).

Referring now to the playlist 500 of Figure 5, the broadcaster has to be able to setup the storage of multi-layer content 510 with metadata 520 bundled in a database, to ensure rebroadcast, archiving, traceability and time accuracy. Accuracy can be improved with help of a general UTC time code reference 530. This would even enable functionality where auxiliary data can be pre-loaded to the secondary device.

Specifically, the play-out process involves a detailed playlist 500. The playlist is the guiding component in the MAM (Media Asset Management) system that connects all parts of the bundled content together with regards to database management and timing information. The playlist 500 is based on the information in the metadata 520 tagged to the content in the media bundle 510. All content items are time -tagged to the master timeline 540 in order to ensure that it is played out nicely in sync. Referring to one timeline (as for Figure 5) is important not only for synchronisation during linear play-out. From a broadcaster's perspective, it is the preferred way to adequately ensure that content can be archived, stored and retrieved as a coherent package. Re -use of material is not limited to broadcast operators, but is also relevant when VoD functionality is to be implemented or when PVR functions have to be supported as well in combination with the second screen interactivity.

Auxiliary content may require that the Web service is controlled in an automated way. Once the process is automated and refers to the master time reference in the media bundle, uploading the auxiliary content to the Web server will become a part of the broadcaster's role. In fact, it adds a new 'experience' component to the media that is handled within the broadcaster's expertise area.

FIG. 5 gives an example of the dependencies between the different contents of the media bundle with regards to timing. Within the MAM system the entire bundle is related with regards to timing through the master time reference. The metadata, carrying descriptive information of the contents within the bundle, has a central role. However dependent of the same time reference, the metadata enables search functions and traceability once the content is stored, archived or referred to from external applications.

Due to the metadata and the time reference it is secured that all parts of the bundle are kept together during live transmission and in retrieval systems.

In the concept it may be possible to refer the metadata to a World clock reference. This option enables user equipment as well to be triggered in a very accurate way in those applications that require such accuracy. Obviously the equipment will have to have such a feature, but in general, networks do offer clocking references as well that are connected to the World clock or GPS.

Returning to FIG. 3 which involves the use of a playlist 310 version of a play-out list, this embodiment of the present disclosure can have just time events where the play-out center 110 will send a time trigger 320 to the server 150 to provide or push content at certain times relative to the play-out of broadcast content. For example, triggers can be designated that 5 minutes and 7 minutes into a broadcast, a trigger is transmitted to the server for an event (representing the pushing of auxiliary content) is to occur. With just the use of time information, it is expected that a server 150 would have a pre-existing list of content to be provided or pushed out when notified. Hence, upon the receipt of the trigger at five minutes in the playback of content, the server will provide or push out to a secondary screen (consumption device 160) content that has been pre-designated as a "first event". Likewise, seven minutes in the content, the server 150 will receive a trigger from the play-out center 110 to transmit auxiliary content designated as a second event. This process can be repeated ad infinitum. This embodiment does not specify content from the point of the play-out center 110; instead the trigger only contains time information.

The system of FIG. 4 again depicts the use of a playlist 410 type of play-out list, but in this example the event data is configured such that at a specified time, a trigger is sent with a specific content ID 420 to the server for playback for a secondary screen. For example, 10 minutes into the play-out of broadcast content, a first event corresponding to content A is transmitted to the server 150 as a trigger . Upon the receipt of such a trigger 420, the server 150 can push Content A to various secondary screens. Likewise, at a second time, 12 minutes into the play-out of broadcast content, a second trigger is transmitted from the play-out center 110 to the server 150 which designates Content B. Hence, the server 150 will transmit such Content B at the time designated in the trigger.

FIG. 6 depicts a further embodiment of the disclosure which uses a video on demand or video over IP system. In this case, a playlist 600 is used to indicate when commercial breaks and events corresponding to auxiliary information are to take place relative to specific content 620. The difference with FIG. 5 is that the content is delivered in a non-real time manner where a user can use trick play functions to fast forward or rewind the broadcast content. Hence, the system will keep track of where a user operating a primary screen 120 is relative to their position in the broadcast content, where the triggers for auxiliary content will be delivered to the server at specified points. For example, using VOD or catch-up content, a user can skip ahead X amount of minutes in the watching of broadcast content. The play-out center can then note where a user is and send the triggers that occur from the point that a user resumes playback. Hence, even though the events that are from 0 minutes to X minutes are skipped, any events for auxiliary content after X minutes can be triggered for playback by the play-out center in accordance with

designations made in the playback list. That is, if auxiliary content can be specified to be provided or pushed via server by a trigger at time X+l seconds, if specified. Optional aspects of the present disclosure can use a migration of one-screen hybrid broadcast into an even more hybrid user experience using the primary and secondary screen in a very efficient way.

Additionally, for the timing reference setup listed above, an alternative approach applies he described timing reference setup can be proprietary protocol, but in a DVB distribution environment it may well be connected to applied standards in order to ensure a broad support of existing equipment. Relevant standards that are used for ad-insertion and triggering of events are SCTE30, SCTE35, SCTE118-1. Further triggering incorporated in distributed signals can be made compatible to some one-screen standards using the DSM- CC carousel, in analogy with HbbTV ETSI TS 102 796 and DVB Application Signalling Specification (TS 102 809). Web server content should match existing second screen standards like CEA-2014 (CE-HTML).

FIG. 7 is a flowchart 700 depicting one exemplary embodiment of a methodology using the techniques and functionality described in this disclosure. At its core the method involves three steps: receiving a play-out list comprising timing information for the transmission of primary content and events corresponding to auxiliary content (step 710), transmitting the primary content to a primary screen device in accordance with the play-out list (step 720), and transmitting event data to a server for pushing out auxiliary content in accordance with the play-out list (step 730). In certain embodiments, the method may further include the initial step of generating a play-out list (step 705). In still other embodiments, the method can further include the steps of receiving the transmitted event data at the server (step 740), pushing out auxiliary content in response to the received event data (step 750), receiving the transmitted primary content at a primary screen device (step 760), displaying the primary content on the primary screen device (step 770), receiving the provided or pushed out auxiliary content at a consumption device (step 780), and displaying the auxiliary content on the consumption device (step 790). The functionality embodied in these steps has been described above. Use cases

Several use cases exist for supplying auxiliary content with an asset (such as video content), the auxiliary content being synchronized to the video programming using triggers. The deployment of the triggers is through a play-out center (as described previously). The use cases are as follows:

On-air (Pre-recorded content)

In a general play-out On air' situation, content is prepared beforehand and is played from a playlist. The providing or pushing out of content to a second consumption device has one scheduling an event by assigning an asset or clip or multiple assets or clips to the event. This is done by having metadata either enclosed or supplied with the clip information or an event list with associated time codes (sequencing the clips scheduled to play at determined moments of the event). It is expected that the re-use of the asset for a new event will carry the same metadata or event list with time codes and so the correct triggering information for the supply of auxiliary content for this asset can be consistent when the asset is played.

Live (Live content)

In a live environment, preparing the content and triggers requires a different approach than that for pre-recorded content. Here a workflow can be implemented where triggers are manually or automatically defined in real time to activate complementary content (available on servers, on the web, ...). At the same time, the specific trigger is connected to the relative timeline of the asset and the generated trigger information is included in the metadata or on an event list that will be linked to the asset afterwards for archiving purposes. For future use, the triggering information is part of the clip which can be activated whenever the content is consumed again. That is, a file can be generated which will link the triggering information from the auxiliary content to an asset, after a real-time designation is made between the two pieces of media.

VoD or Catch-Up

In a VoD or Catch-Up environment, a trigger information file can be transferred from the play-out system to a web application at fixed time intervals (which can be defined as needed) in order to synchronize auxiliary content and an asset, where the playback of both content can take place at different times for each user operating a VoD system. The web application on the server ideally intercepts individual triggers in order to play-out the relevant content to each individual VoD user.

Alternately, in a VoD or Catch-Up environment, the event list with the trigger information can be linked to the content or embedded in the metadata of the content which communicates the trigger information to the web service or application or alternate server at the identified moments of the event list in order to synchronize the delivery of auxiliary content with the main asset. The web service or application or alternate server ideally intercepts individual triggers in order to play-out the relevant content to each individual VoD user. The web service or application or alternate server can also be linked to an identified asset being streamed to an individual from the network and, with the end user having previously identified himself or logged on to the application, can be delivered the adequate complementary event linked to the primary content being viewed.

FIG. 6 shows two methodologies that can be used to trigger time sequenced events whether related to an actual time code 610 or a relative time code linked to the launch of the content and how the related complementary events can be identified using any of these two time codes.

Examples of triggering information/date

Triggering information can be included in the play-out system, as explained when one uses the Publitronic broadcast system (although this is done for illustrative purposes). The suggested GUI is a possible solution which can be used in accordance with the concepts presented herein.

The data transferred to the web service or application or alternate server could be carried in multiple formats. The likely formats are HTTP, a SOAP call with an XML file or an FTP to a 'watch folder' to transfer information.

Although the equipment will be connected over an IP connection and distance between the devices is not typically a real issue, one can desire to locate the broadcast play- out platform and the web service or application or alternate server in the same geographic location, as they would have to work as one connected platform. Data fields that can be used for metadata or included in the event list (this list is not exhaustive) event name / ID

event start

event link (in case link to external services)

trigger ID

time code in clip

application reference

Playlist

The events listed in the playlist link to the clips in the database that are 1 : 1 connected to their metadata. Trigger information is then part of the metadata fields. The playlist is typically a database application which keeps track of the progress of the clip.

The playlist is therefore able to precisely identify when it is playing out a clip and how far it is in the clip play-out. If metadata is embedded in the clip, the play-out will read the metadata and send the information to the connected service on the server. If there is an event list attached to the clip, the play-out will identify when it has reached the identified time schedule relative to the play-out of the clip and: either send the time notification to the server that can link the time trigger to the relevant event to push to the second screen, or link the time trigger to an event and notify the server to send the identified event to the second screen.

Play-out platform

Using a play-out platform, such as PubliTronic, the system operates according to the channel-out-of-a-box principle. This means that the PubliTronic play-out device does not only play video clips, but also handles additional tasks. Like audio processing/limiting, teletext, subtitling, on-screen graphics, captions, etc. The addition of the principles within this document allows for the addition of auxiliary content which can be synched to an asset. In addition, the PubliTronic platform does not cover real-time intervention on the playlist or secondary events when used in a live television setting. Everything else that is possible with traditional play-out, will be possible with the PubliTronic platform too. However cheaper in CAPEX as well as OPEX.

The PubliTronic play-out device is called Nexus and is based on Linux operating system. It is possible to write and execute your own source code on the device (in C++, Java, Ruby or Python). Such additional applications have entrance to the playlist database and the asset database.

Adding trigger moments beforehand

Website trigger moments can be added to clips manually within the PubliTronic MAM system, or eventually in an external MAM system which is linked to the PubliTronic platform. This is done by adding clip time codes and a corresponding ID. The time code is the relative website trigger moment within the clip. The ID will be recognized by the web server, this corresponds to the name of a specific webpage or event that should go online or delivered to the required user on that specific moment.

Adding trigger moments at real-time

Website trigger moments can be created in real time by an administrator page on the web server itself. This will be necessary for live broadcasts, where you don't know the exact trigger moments beforehand. Once the user selects a webpage and clicked 'Update', the web server will immediately update the content of the webpage.

If the live broadcast will be repeated at a later moment (i.e. played from a live recorded video file), it might be handy to reuse the original manual triggers. Therefore, the web server should register the manual triggers and send them in a text file (or something like that) to the play-out MAM, so the manual triggers can be stored in the clip data and can be reused.

Interface

Examples of a user interface for configuring events in the exemplary Cobalt of PubliTronic systems can be seen in FIGs 8-11. There will be a direct link between the play-out device and the server that hosts the events or the website related to the program, through a local share (if the devices are within the same network) or through the internet. Several internet transfer protocols are possible: FTP (using watch folders), SOAP (through HTTP), or a direct HTTP request.

A dedicated service on the play-out device will keep track of the actual playlist and read in the clip metadata at what moments (relative to start of clip) triggers should be sent to the (web)server or send time trigger information linked to an event list provided with the time schedules needed to be triggered. At the right moment, a small file with trigger information will be sent to the (web) server (or SOAP or HTTP request will be done). The (web) server recognizes the trigger and updates the webpage corresponding to the specified ID or delivers the related event to the end user device.

The present description illustrates the principles of the present disclosure. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its spirit and scope.

All examples and conditional language recited herein are intended for informational purposes to aid the reader in understanding the principles of the disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.

Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herewith represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor ("DSP") hardware, read only memory ("ROM") for storing software, random access memory ("RAM"), and nonvolatile storage.

Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

Although embodiments which incorporate the teachings of the present disclosure have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments for a method and system for providing media recommendations (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. While the example set forth above has focused on an electronic device, it should be understood that the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which, when loaded in a computer system, is able to carry out these methods. Computer program or application in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduction in a different material form. Additionally, the description above is intended by way of example only and is not intended to limit the present invention in any way, except as set forth in the following claims.

Claims

CLAIMS:

1. A method of synching auxiliary content related to primary content being transmitted, the method comprising:

receiving a play-out list comprising timing information for the transmission of primary content and events corresponding to auxiliary content;

transmitting the primary content to a primary screen device in accordance with the play-out list; and

transmitting event data to a server for providing auxiliary content in accordance with the play-out list.

2. The method of claim 1 , wherein the play-out list comprises a playlist with timing information relative to the play-out of the primary content.

3. The method of claim 1, wherein the play-out list comprises a playlist with timing information relative to a universal clock.

4. The method of claim 1, further comprising:

generating a play-out list.

5. The method of claim 1, wherein the play-out list is generated during the transmission of the primary content.

6. The method of claim 1, wherein the event data comprises timing triggers.

7. The method of claim 6, wherein the event data further comprises content identifiers.

8. The method of claim 1, wherein the steps are performed at a play-out center.

9. The method of claim 1, further comprising:

receiving the transmitted event data at the server; and

providing auxiliary content in response to the received event data.

10. The method of claim 9, further comprising:

receiving the provided auxiliary content at a consumption device; and

displaying the auxiliary content on the consumption device.

11. The method of claim 1 , further comprising:

receiving the transmitted primary content at a primary screen device; and displaying the primary content on the primary screen device.

12. The method of claim 1 wherein the transmission of the primary content comprises broadcasting the primary content.

13. The method of claim 1, wherein the transmission of the primary content comprises video on demand (VOD) delivery of the primary content.

14. The method of claim 1, wherein the transmission of the primary content is performed over traditional broadcasting modalities.

15. The method of claim 1, wherein the transmission of the event data is performed using network protocols.

16. The method of claim 1, wherein the event data comprises consumption device restrictions.

17. A system for synching auxiliary content related to primary content being transmitted, the system comprising:

a play-out center configured to receive a play-out list comprising timing information for the transmission of primary content and events corresponding to auxiliary content, transmit the primary content to a primary screen device in accordance with the play-out list, and send event data to a server for pushing out auxiliary content in accordance with the play-out list; and

a server configured to receive the transmitted event data at the server and provide auxiliary content in response to the received event data.

18. The system of claim 17, further comprising:

a consumption device in communication with the server configured to receive the provided auxiliary content and display the auxiliary content.

19. The system of claim 17, further comprising:

a primary screen device in communication with the play-out center configured to receive the transmitted primary content and display the primary content.

20. The system of claim 17, further comprising:

a content server in communication with the server containing the auxiliary content.