NL2015755B1

NL2015755B1 - Over-the-top digital media distribution of automated time-zone shifted content to client devices.

Info

Publication number: NL2015755B1
Application number: NL2015755A
Authority: NL
Inventors: Albert Anita Jooris Pieter
Original assignee: Listycon Bvba
Priority date: 2015-11-09
Filing date: 2015-11-09
Publication date: 2017-05-26
Also published as: WO2017081059A1

Abstract

Methods and system are described enabling over-thetop delivery of automated time (zone)-shifted content to one or more client devices. The method may comprise: receiving a content request from at least one client device, the request comprising a content identifier for identifying (stored) linear content; determining or receiving a client time TCL associated with the client device, the client time being indicative of the time in the time-zone in which the client device is located; a broadcast time TBC being indicative of the time in the time-zone in which the requested content is broadcasted; and, a back-end time TBE being indicative of the time in the time-zone in which the back-end server is located; determining a back-end playback time TBEPB for the requested (stored) linear content on the basis of the client time TCL, the broadcast time TBC and the back-end time TBE; and, transmitting the requested linear content to the client device on the basis of the determined back-end playback time TBEPB, preferably the back-end playback time TBEPB being used to determine the starting point of the transmission of the requested (stored) linear content.

Description

Over-the-top digital media distribution of automated time-zone shifted content to client devices

Field of the invention

The invention relates to over-the-top digital media distribution of automated time-zone shifted content to client devices. In particular, though not exclusively, the invention relates to methods and systems for providing over-the-top automated time-zone shifting and prime time tracking services to client devices, as well as a client device and a network node for use in such a systems and a computer program product for using such methods.

Background of the invention

As the television viewing experience is expanding fast in an ever-changing market comprising of new Technologies and using existing technologies in different ways to offer more, faster and better TV-services to the end user, there is clearly the need for a multiple-broadcaster Over-the-Top (OTT) Operator. Such an operator would be linking any broadcaster or content provider's content and metadata and end users based on a single systems-interface. This interface would distribute and receive over the Internet (OTT) or via a Content Delivery Network (CDN) the content/(meta)Data worldwide in a controlled, structured, secured, licensed and time-shifted manner and allowing broadcasters and content/(meta)data providers the Control of several distribution parameters as they see fit.

So far, for linear television services most of the existing standardized solutions include closed networks of e.g. cable operators, telecom operators, satellite operators, etc. forming a distribution network for reaching end users in a local or limited area and with a vast subset of broadcasted linear content (or channels). In these systems, the end user typically pays money for channels he or she may not be interested in as the operator offers typically a set of channels that are considered as mostly watched in a certain region, thus ruling out special groups of potential users like emigrants and immigrants, ex-patriots, the business traveller, the holiday traveller etc.

However, with the increased quality of service and high-speed Internet the World Wide Web offers an open network for content delivery services. Unfortunately, the offerings are scattered and non-centralized and often non-licensed transmissions occur. Furthermore, the viewing of such content often lacks the 'Living Room Experience' one would like to enjoy when watching TV, including high quality and uninterrupted streaming, fast zapping, etc.

On top of having broadcasters offering content over the Internet in a secured and structured way, the easiness of getting the content onto a large screen for such 'living room'-viewing experience plays an important role for accessing the end-user with high usability experience. Therefore, the devices used for playback should be small and mobile like an HDMI stick for the travelling party and could still be Set-top-box alike for the longer-term residing users.

Current existing solutions (like from ROKU, Chromecast, Apple TV, Amazon Fire, Netflix, Sling TV) offer on demand and linear broadcast channels over the Internet. This is by means of existing technologies for ingest, processing, storage and distribution through a back-end (virtual in the Cloud or Local Centralized / Decentralized) and with playback and storage on HDMI Sticks, Set-Top Boxes, Smartphones, Tablets, Smart-TV's, Laptop, Notebooks, PC's, etc. Some of the existing solutions need an end user to look for the content first on the internet e.g. by means of a smartphone and then activate the streaming to a TV set by means of an HDMI Stick.

The On Demand Content is not played out in a linear sequential way, so the end user can just get that Content whenever he wants. In addition, operators already offer services like 'Catch UP TV' where linear content is being stored for a certain number of days. The end user now can go back in time in the Electronic Program Guide and search for his favourite channels / events that were transmitted in the past days . US2008109857A1 describes a broadcast system comprising network-based time-shifting capabilities in order to present transmission of content to subscribers in different time-intervals and more specific in different time-zones. The broadcast system is configured to broadcast time-shifted content blocks at different times according to a pre-defined schedule. This system is configured to deliver so-called near video on demand (nVOD) services wherein multiple copies of linear content are broadcasted as multiple media streams at specific and pre-scheduled time intervals on different channels in parallel. When a user wants to watch an event from the start, he/she needs to manually search and tune in on one of these pre-scheduled channels that fits best to the actual time he/she starts watching or the time-zone he/she is in.

Such content delivery scheme is however very bandwidth intensive and is generally provided only by large operators with a great deal of redundant capacity and not for all available channels. The reason for this is that if an operator would want to cover all channels in all time-zones in this way, each channel would need to be broadcasted as many times as there are time-zones and all in parallel. Furthermore, as a result, a travelling end-user -being subscribed to such a service and having a media device for rendering broadcasted media and travelling through different time-zones-, still manually needs to look up and zap to the channel that matches (best) with his time-zone. This is because originally the offered content is not aligned with all the time-zones, except for the one the Broadcaster is transmitting in. Such time alignment is especially important for prime time events where publicity is of utmost importance, as most users will watch prime time events (as such content is deemed most interesting to watch to most common viewers) regardless of the time-zone he or she is in.

Hence, from the above it follows that there is a need in the art for improved methods and systems that enable delivery of over the top content delivery services for viewing linear and (less time-affected) on demand content in any time-zone while maintaining as much as possible the end-user's "living room viewing experience as if he/she were at home". In particular, there is a need in the art for improved methods and system for automatic time-shifting services for content delivery so that a user does not notice that his favourite home channels are transmitted at a different time than what he is used to.

Summary of the invention

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, a method or a computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Functions described in this disclosure may be implemented as an algorithm executed by a processor/microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is the aim of the methods and systems described in this disclosure to enable services that automatically eliminate timezone differences for enhanced viewing experiences of linear content across different time-zones while respecting security, licensing and digital rights management (DRM) systems. The methods and system described in this disclosure enable automated timezone shifting (ATS) and prime time tracking- (PTT) services for travelling client devices. These services provide shortcuts to information that will make a traveler known and familiar with his new environment at the press of a key on the remote control unit or client application. The methods and system described in this disclosure further enable a subscriber access to his or her favorite channels (even when travelling abroad or emigrating for many years) and enables viewing of these favourite channels on any display system anywhere over the w o r 1 d .

Whereas current models for watching television have mostly introduced systems for people that are residing within one time-zone, there are a number of shortcomings in the current television services offered to travelling persons. Time-zone differences that can occur cause viewers to see e.g, at 9 pm local time of the country one moved to, what their favorite broadcaster from their country of origin is transmitting at 3 am at night in case of 6h timezone difference. This might be e.g. a black screen, a still picture, repetitive news of weather information etc. Furthermore, broadcasters would like to reach as many people of their intended group (e.g. all people in one country) during prime time. This is the time that the broadcaster can ask for more money for publicity as there are more viewers. So it is in the broadcaster's interest to also reach all national residents that travel or (temporily) live abroad (in a different time-zone e.g.) at that same prime time. The operator service will bring the national channels to people abroad, but the intended prime time of the broadcaster is now shifted along with the timezone difference, It may also be in the viewers interest to start watching at the intended prime time events as these are mostly the ones that attract most viewers, as they are the best or most wanted events of the d a y. Wit h t h e cur r e nt imp1eme nt a t i ο ns, v i ewers need t o s t ar t looking up the events and times themselves, sometimes not with easy-to-use User Interfaces.

The embodiments described in this disclosure will solve in the best possible way the above-mentioned problems.

In one aspect, embodiments of the present invention may relate to a method for enabling a back-end server transmitting time-shifted content to one or more client devices comprising.

In embodiment, the method may comprise: receiving a content request from at least one client device, the request comprising a content identifier for identifying stored linear content; determining or receiving a client time Tcl associated with the client device, the client time being indicative of the time in the time-zone in which the client device is located; and, a broadcast time Tbc indicative of the time in the time-zone in which the requested content is broadcasted; determining a back-end playback time Tbepb for the requested stored linear content on the basis of the client time Tcl, the broadcast time Tbc and a back-end time Tbe, the back-end time being indicative of the time in the time-zone in which the back-end server is located; and, transmitting the requested linear content to the client device using the determined back end playback time Tbepb as starting point of the transmission of the requested stored linear content. The method thus provides automatic time-shifting services for over-the-top (OTT) content delivery of linear and (less time-affected) on demand content in any time-zone thereby providing a "living room viewing experience" as if the end-user was at home. The method automatically time-shifts transmission of content so that a user does not notice that his favourite home channels are transmitted at a different time than what he is used to. These automatic time-shifting services are realized by monitoring time information of client devices, broadcasters and the backend system.

In an embodiment, the method may comprise receiving linear or on-demand content and meta data from a broadcaster or content/(meta)data provider and storing the received content and metadata in a storage module of the back-end.

In an embodiment, the client time may be determined based on location information associated with the client device, preferably the location information including an IP address of the client device and/or geo-location information of the client device. In another embodiment, the client time may be received from the client device wherein said client device is configured to render a graphical user interface for enabling a user to enter the current time of the time-zone the client device is located in.

In an embodiment, the method may include receiving a registration request from the client device, the registration request comprising a client device identifier; storing a client device identifier associated with said client device, the client time Tcl; the broadcast time Tbc and the back-end time Tbe in a storage medium of the back-end system.

In an embodiment, determining a back-end playback time Tbepb may further comprise: comparing the client time Tcl with the broadcast time Tbc; and, setting the back-end playback time Tbepb on the basis of this comparison.

In an embodiment, the back-end playback time T BEPB IHcLy be set: to the back-end time TBe if the broadcast time TBc is substantially equal to the client time Tcl; to TBe - (TBc - TCB) if the broadcast time TBc is larger than the client time Tcl; and, and to: TBE - (TBC - TCB) - T24 if the broadcast time TBC is smaller than the client time Tcl, wherein T24 represents a time period of 24 hours.

In an embodiment, the request for content comprises a time-shift indicator for signaling the back-end to transmit the requested linear content in accordance with the back-end playback time TBBpB.

In an embodiment, the method may include: receiving electronic programming (EPG) data for one or more television channels, said EPG data comprising a time schedule indicative of when one or more programs of a television channel are going to be transmitted; and, displaying at least part of said time schedule on the basis of broadcaster playback time TBCpB, preferably displaying which programs are going to be transmitted in a time interval defined on the basis of broadcaster playback time TBcpB. In an embodiment, the time interval shown on the User Interface or used by the client device may be defined by TBcpB - X minutes to TBcpB + X minutes. Hence, the method may also provide a time-shifted EPG that is calculated in accordance with such a time-interval.

In an embodiment, the method may comprise: determining or receiving a whitelist comprising one or more content identifiers of stored linear content for which time-shifted transmission is allowed; or, a blacklist, comprising one or more content identifiers of stored linear content for which time-shifted transmission is not allowed; determining whether said requested content may be transmitted on the basis of said back-end playback time on the basis of the content identifier in said content request and the one or more content identifiers in said whitelist or said blacklist. Hence, white or blacklists may be generated in order to determine whether time-shifting of the content is allowed by e.g. the broadcaster .

In a further aspect, the invention may relate to a method transmitting time-shifted content, preferably by a back-end system, to one or more client devices wherein the method may comprise: receiving a content request from at least one client device, the request comprising channel for identifying stored linear content associated with a television channel; determining or receiving a prime time parameter PT associated said television channel, the prime time parameter PT being indicative of the prime time as defined by either broadcaster, back-end or client device; and, a broadcast time Tbc indicative of the time in the time-zone in which the requested content is broadcasted; and, determining or receiving a prime time offset parameter PToffs for defining a time-window PT-PToffs to PT+PToffs for determining if a real-time or time-shifted transmission of the prime time content should take place for a given channel; determining or receiving a back-end playback time Tbepb for the requested stored linear content on the basis of the prime time parameter, the broadcast time Tbc and a back-end time Tbe, the back-end time being indicative of the time in the time-zone in which the back-end server is located; and, transmitting the requested linear content to the client device using the determined backend playback time Tbepb and / or broadcaster playback time Tbcpb as starting point of the transmission of the requested linear content. In this embodiment, the content is automatically time shifted on the basis of a prime time parameter that indicates the prime time.

In an embodiment, the prime time parameter PT may be determined based on a prime time parameter PTcl associated with the client time, a prime time parameter PTbc associated with the broadcaster and/or a prime time parameter PTbe associated with the back-end.

In an embodiment, determining a back-end playback time Tbepb may further comprise: comparing the prime time parameter PT with the broadcast time Tbc; and, setting the back-end playback time Tbepb: - to the back-end time Tbe if the broadcast time Tbc is PT-PToffs - Tbc - PT + PToffs; - to Tbe - (Tbc - PT) if Tbc > PT + PToffs; and, - to Tbe - (Tbc ~~ PT) - T24 if Tbc < PT - PToffs. wherein T24 represents a time period of 24 hours .

In another aspect, the invention may relate to a back-end server system adapted to transmit time-shifted content to one or more client devices comprising: at least one computer readable storage medium having computer readable program code embodied therewith, and at least one microprocessor coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the microprocessor is configured to perform executable operations comprising: receiving a content request from at least one client device, the request comprising a content identifier identifying stored linear content; determining or receiving a client time Tcl associated with at least one client device, the client time being indicative of the time in the time-zone in which the at least one client device is located; and, a broadcast time Tbc indicative of the time in the time-zone in which the requested content is broadcasted; determining or receiving a back-end playback time Tbepb for the requested stored linear content on the basis of the client time Tcl, the broadcast time Tbc and a back-end time Tbe indicative of the time in the time-zone in which the backend server is located; and, transmitting the requested linear content to the at least one client device using the determined back-end playback time Tbepb as starting point of the transmission of the requested linear content.

In an embodiment, the back-end server system may comprise: determining whether said requested content may be transmitted on the basis of said back-end playback time Tbepb on the basis of the content identifier in said content request and one or more content identifiers in a whitelist or a blacklist, the whitelist comprising one or more content identifiers of stored linear content for which time-shifted transmission is allowed; and, the blacklist comprising one or more content identifiers of stored linear content for which time-shifted transmission is not allowed.

In a further aspect, the invention may relate to a client device configured for requesting time-shifted content from a back-end server system comprising: at least one computer readable storage medium having computer readable program code embodied therewith, and at least one microprocessor coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the microprocessor is configured to perform executable operations comprising: selecting a content identifier associated with stored linear content, the linear content being associated with a broadcast time Tbc indicative of the time in the time-zone in which the content is broadcasted; determining or retrieving a client time Tcl indicative of the time in the time-zone in which the client device is located, determining or retrieving a back-end time Tbe indicative of the time in the time-zone in which the backend storage module is located; determining a back-end playback time Tbepb on the basis of the client time TCl, the broadcast time Tbc and a back-end time Tbe; transmitting a content request to the back-end server system, the request comprising the content ID and the determined back-end playback time Tbepb; and, receiving the requested linear broadcasted content from the back-end server system which is configured to use the back-end playback time Tbepb to determine the video transmission starting point for transmitting the requested stored linear content to the client device.

Moreover, the invention may also relate to a computer program for carrying out the methods described herein, as well as to a non-transitory computer readable storage-medium storing the computer program provided.

Embodiments of the present invention will be further illustrated with reference to the attached drawings, which schematically will show embodiments according to the invention. It will be understood that the present invention is not in any way restricted to these specific embodiments.

Brief description of the drawings

Fig. 1 depicts a schematic of a television system configured for providing client devices automated time-zone shifting and prime time tracking services according to an embodiment of the invention.

Fig. 2 depicts a method for providing automated time-zone shifting services to one or more client devices according to an embodiment of the invention.

Fig. 3 depicts a method for providing prime time tracking services to one or more client devices according to an embodiment of the invention.

Fig. 4 depicts a client device module for enabling (automated) time-zone shifting and prime time tracking services according to an embodiment of the invention.

Fig. 5 depicts a block diagram illustrating an exemplary data processing system that may be used as described in this disclosure.

Detailed description

Fig. 1 depicts a schematic of a content delivery system configured for providing client devices automated time-zone shifting and prime time tracking services according to an embodiment of the invention. In particular, Fig. 1 depicts a schematic of a TV system 100 according to an embodiment of the invention wherein the TV system may be configured as an Operator Service for over-the-top (OTT) delivery content and wherein the television system is configured for providing client devices automated time-zone shifting and prime-time tracking services.

The content delivery system may comprise a back-end system (in short "back-end") 102 and one or more client devices 104i-4 wherein the back-end system is configured for storing, processing, and redistributing multimedia content 112i-2 and metadata 113 (including EPG data) associated with the multimedia content. A client device may be implemented as a client (software) application on a media processing device (not shown), e.g. an HDMI stick, STB, smart phone, electronic tablet, smart TV, etc., which is configured for receiving and processing content from the back-end such that it can be rendered on a display system. A back-end storage module 120 may be configured to receive content from content providers and/or service providers which hereafter are referred to as broadcasters 110i,2. Here, the term content may be construed broadly including linear television, on demand video, games, Internet database services, etc. The content may be stored together with associated metadata, e.g. data for an Electronic Program Guide (EPG) module 126. The content and associated metadata may be ingested by the back-end storage module 120 comprising one or more content media storage servers 130 via a secure ingest network 114 or as installed directly in the back-end. Before storage, the content may be processed for enabling secure access (e.g. on the basis of a conditional access scheme and/or Digital Rights Management (DRM) system for secure storage and transcoding) by the client devices. The content storage 130 may be implemented as a cloud storage system or one or more local storage servers.

The stored and secured content may then be made available for distribution via one or more networks 116, e.g. one or more CDNs (Content Delivery Network) and/or the Internet to client devices. A CDN may comprise a network of network nodes 118, e.g. caches, enabling distributed content delivery to client devices. In an embodiment, the ingest network may be part of a CDN. DRM information may be exchanged with a client device in order to enable/disable storage and playback of the content. Encoded (and encrypted) media data may be transmitted to the client devices on the basis of a suitable streaming protocol e.g. an HTTP adaptive streaming (HAS) or the like, allowing continuous transmission of media data to the client device. Other suitable streaming protocols may include the RTP /RTCP/RTSP protocols (respectively Real Time Transport

Protocol, Real Time Transport Control Protocol and Real Time Streaming Protocol) or the like. A bidirectional communication channel between the back-end and a client device may be used in order to transmit protocol messages, e.g. requests messages for media data, between the back-end and client device. A Customer Relation Management (CRM) module 128 associated with the back-end may keep track of transactions, address information and entitlement information, which is passed to a billing and invoicing system. The CRM system may be configured for monitoring channels which have been viewed and the duration of the viewing and collect network information/metrics for quality assessment.

The content delivery system of Fig. 1 may be implemented as a centralized system wherein the back-end provides content to client devices anywhere in the world via the Internet and/or one or more CDNs. Alternatively, the content delivery system may be implemented as a decentralized system comprising a back-end associated with main storage servers or cloud storage and additional decentralized storage and distribution channels (remote hubs) either via dedicated (leased) connections or via the Internet and/or one or more CDNs networks so that an optimal Quality of Service (QoS) regarding the delivery of content can be realized, taking regulatory, technical and/or cost efficient optimizations into account. Such centralized or decentralized back-end systems are hereafter simply referred to with the term "back-end" unless stated clearly otherwise. Regardless of a centralized or decentralized system or a combination of both, the TV system enables content distribution to any country where a client device is residing in or travelling to. The client devices are configured for receiving, decoding and/or storing media data, e.g. audio/video (AV) media data, and associated metadata .

When a client device is receiving content transmitted by the back-end, the client device may send a heartbeat signal to the back-end, its remote hubs (decentralized solution) or even directly to storage servers (some types of which can be seen as Video Severs for On Demand content e.g.). The heartbeat signal may be monitored and/or logged by the backend server system 102 in order to determine if a client device is still connected to the back-end, its remote hubs or one or the other storage server or Cloud connection and/or is still receiving content from a certain provider. Such a heartbeat signal could then also carry information for logging the time a client device is receiving and/or recording content and/or information required for an automated time shifting (ATS) module 122 and/or prime time tracking (PTT) module 124. The Heartbeat signal may be configured as a periodic signal that is typically (but not necessarily) sent out in periods of minutes (e.g. every 1 min, 2 min, 3 min, 5 min, etc.).

As shown in Fig. 1, the back-end is configured to monitor time-zone information associated with the broadcasters and client devices that are connected to the back-end. The time-zone information may include a back-end time attribute Tbe (see back-end server system 102) representing the time registered in the time-zone of the back-end, a broadcast time attribute Tbc representing the time registered in the time-zone of the broadcaster (See 110i and IIO2 and their respective indicated times TBci and TBc2); and, a client time attribute TCl representing the time registered in the time-zone wherein the client device is located in (see IO61-4 and their respective times TcLi-4) · The time instances TBe, TBc, TCl happen at the same moment wherein the time instance Tcl is time the user is watching a broadcasted channel that is played out to the client device.

The back-end may store time information for each client device on a time-shift database 132. For example, in an embodiment, the back-end may register a client identifier ID, e.g. an IMSI (International Mobile Subscriber Identity), together with the client time attribute Tcl and the broadcast time attribute Tbc. The time-zone information may be used by the ATS and PTT modules in order to deliver OTT services for client devices of subscribers that are travelling all over the world. The services delivered by the ATS and PTT modules will be described hereunder in more detail with reference to Fig. 2 and 3 .

Fig. 2 depicts a flow diagram illustrating a method for providing automated time-zone shifting services to one or more client devices according to an embodiment of the invention. In particular, Fig. 2 depicts a flow diagram illustrating a method for automatically shifting linearly broadcasted content from a first time-zone to another second time-zone. The process depicted in Fig. 2 may hereafter be referred to as automated time-zone shifting or ATS. The method may be implemented as an operator service between the back-end (and/or its hubs) (e.g. a server in the back-end of a service operator) and one or more client devices as described with reference to Fig. 1.

The process may include ingestion of content associated with different broadcasts, e.g. live broadcasts, originating from one or more broadcasters. For example, in steps 202-206 of Fig. 2 (multi)media content & data associated with different live streams may be ingested and stored on a storage system of the back-end, wherein each live stream may be associated with a broadcast time Tbc in a particular time-zone. Additionally, metadata associated with the content as depicted in step 208 of Fig. 2, e.g. EPG data and other content metadata, may be sent and stored at the back-end as well. The back-end may store the content for a predetermined period of time (e.g. content of a particular television channel that has been broadcasted in the past x days).

In an embodiment, broadcasters and/or content providers may provide whitelist or blacklist information to the back-end, wherein the back-end system is configured to use the white and/or blacklist information in order to form a whitelist comprising one or more content identifiers of stored linear content for which time-shifted transmission is allowed; and/or, to form a blacklist, comprising one or more content identifiers of stored linear content for which time-shifted transmission is not allowed. The whitelist and/or blacklist may be stored on a storage medium of the back-end system. The back-end system may then use the white and/or blacklists to check whether the requested content may be transmitted in a time-shifted way. This way, a broadcaster can be offered control whether the content may be used for automatic time-shift services.

In an embodiment, time-zone information associated with client devices and the broadcasters may be monitored by the back-end, wherein time-zone information includes a backend time attribute Tbe representing the time registered in the time-zone of the back-end, a broadcast time attribute Tbc representing the time registered in the time-zone of the broadcaster; and, a client time attribute Tcl representing the time registered in the time-zone wherein the client device is located in. The time instances TBe, TBc, TCl happen at the same moment wherein the time instance Tcl represents the time at which the user is watching a television channel that is played out to the client device.

In this disclosure different formats may be used when comparing and calculating time instances. For example, a 24 hours' format (00:00h-23:59h) may be used for describing time instances, wherein 24:00h being the same as 00:00h but other time formats may also be used. Alternatively and/or in addition, Universal Time Codes (UTC) and offsets for Daylight Savings Time may be taken into account when calculating and comparing time instances but also other international standards for time references in different Time-zones may be used where applicable. Different offsets may apply depending on the chosen reference standards.

The method further includes one or more client devices registering to the back-end by transmitting a registration message to the back-end (step 210). The customer relation management (CRM) system that may be part of the backend may execute the registration process. The registration message may comprise one or more client device identifiers, e.g. a mobile subscriber identity (an ISMI) and/or a network address, e.g. the IP address for registering the client device with the back-end. A client identifier may also include a unique conditional access number or a smartcard number (virtual or physical smartcard).

The registration of the client device to the back-end may include a user identify himself by entering account login credentials (e.g. a unique account name and password or the like) on the client device which is sent in the registration message to the back-end. If the registration is successful, the back-end may send the client device a message acknowledging that the registration process was successfully executed (step 212).

During or after the registration process the back-end may determine whether the client device has access to an automated time-shift service for time-shifting content associated with e.g. a live-stream to a time in the time-zone in which the client is located. In an embodiment, the back-end may check whether the ATS function is set to "ON" for a registered client device (step 214). To that end, messages sent by the client device to the back-bend, such as a registration message, may include an ATS indicator, e.g. a flag or the like, for indicating whether the client device has access to the ATS function.

The registration message may comprise setting information for enabling an ATS function in the back-end to time-shift requested content, e.g. a live event. For example, in an embodiment, the setting information may include location information associated with the geolocation of the client device. The location information may be associated with the IP address of the client device, which provides an indication in which area (down to country and city), and thus in which time-zone, a client device is located. Alternatively, and/or in addition, the location information may include geo-coordinates of a GPS unit in a media-processing module that might be implemented in the client device. The location information may be used by the back-end and/or client device in order to determine a time-zone associated with a client device. Based on the thus determined time-zone, a client time value Tcl can be determined.

Alternatively, the setting information may include a client time value Tcl representing the current local time in the time-zone of the client device. To that end, the client device may be associated with a wall-clock module that keeps track of the time in time-zone the client device is located in. The wall-clock module may determine the time according to the local time standard, i.e. the time that is dependent on the time-zone. In another embodiment, the client device may be configured to render a graphical user interface on a display for enabling a user to enter the current time of the time-zone the client device is located in.

Transmission of the setting formation from the client device to the back-end may be triggered by different events, including client-side events, e.g.: the client device connecting, e.g. registering, to the back-end; detecting of a modification of the setting information of a client device (e.g. the client device enters a new time-zone) or selection of a television channel. Alternatively, the transmission may be triggered by a network-side event (e.g. the back-end requesting setting information from the client device). In yet a further embodiment, setting information associated with the client device may be periodically transmitted to the back-end.

Once the client device is registered with the backend it may receive metadata, e.g. EPG data, associated with content that can be accessed via the back-end (step 216).

The client device may use the EPG data to display the content that is available for a user. When the user selects a linear broadcast service (a television channel) using the client device (step 218), the client device may sent a request message comprising an identifier associated with the selected content to the back-end, in particular the ATS module in the back-end, requesting the back-end transmission of the selected content (step 220). If necessary, before executing the ATS function the ATS-module may update the time information of the client device based on the selected content. For example, it may update the time information of the client device (as stored in the time-shift database) with the broadcast time Tbc2 associated with the selected content2 (see step 204).

Thereafter, the ATS function may be executed in order to automatically time-shift the requested content based on the time information in the time-shift database. The ATS function may check whether the requested content is present on the whitelist or blacklist (step 222). If the requested content is blacklisted the ATS function may be disabled for the requested content. Alternatively, if the requested content is not on the whitelist, the ATS may be disabled.

In case the ATS function is disabled (turned OFF) for the requested content, the execution of the ATS function is skipped and the content request is forwarded to the back-end storage. The requested content is selected and transmitted to the client device as a linear live broadcast. In that case, the systems for live transcoding and live encryption will pass their signal for segmentation payload preparation from where it is passed onto the Content Delivery Network (CDN) for transmission to the client device. The content, transmitted at broadcaster's time Tbc, is received at the client device at time Tcl . The broadcaster playback reference time is then set equal to the client device Tbcpb = TBc. There is no time shifting even though the time-zones may be different.

In contrast, when the ATS function is enabled for the requested content (turned ON), the ATS function may calculate a back-end play-back time for the requested content. In that case, the ATS function may retrieve the time-zone information associated with the client device (step 224), i.e. the client time Tcl, the broadcast time Tbc and the back-end time Tbe and determine a back-end playback time Tbepb (step 226) for enabling the delivery of the content in accordance with the time-zone a client is in. Depending on the time-zones of the client device and the broadcaster, three different situations may occur.

In a first situation, for any given timestamp, the time in the broadcaster's time-zone Tbc may be substantially identical to the time in the client device's time-zone Tcl, i.e. Tbc=Tcl · Here, the term substantially identical may relate to the fact that when comparing time instances associated with time-zones small time differences (several seconds, few minutes) may exist. These small time differences may be related to small differences in content metadata and differences in system reference clocks of broadcasters, the Internet, back-end system, client devices, etc.

The content received by the client device at time Tcl is referred to in the broadcaster's time-zone as Tbc . Because Tbc equals Tcl the back-end systems for live transcoding and live encryption will pass their signal for segmentation payload preparation from where it is passed onto the Content Delivery Network (CDN) for transmission to the client device. The linear broadcasted service (the TV channel) is transmitted to the client device as being live-transmitted by the broadcaster. The client device is in the same time-zone as the broadcaster's linear channel. The content transmitted at broadcaster's time Tbc is received at the client device at time Tcl. No time-zone shifting of the content is initiated as Tbc=TCl . The back-end playback reference time Tbepb remains unchanged, as no offset needs to be calculated to define the Broadcasters playback time Tbcpb, which is then set to the time of client and broadcaster: Tbcpb = TBc = TCl . As there is no time-zone difference between broadcaster and the client device, there will be no time-zone differences noticeable for the user of the client device.

In a second situation, the time in the broadcaster's time-zone Tbc is 'later' than the time in the client device's time-zone Tcl at timestamp Tl: Tbc > Tcl. From the client device's time-zone perspective at time Tcl, the broadcasted content was already transmitted and stored in the back-end one to multiple hours ago because the broadcaster's transmission is in a time-zone that is ahead of the client device's time-zone. For timestamp Tl the following relation is valid:

wherein x hi. For the same and any given timestamp Tl, the broadcaster's content is stored in the back-end at time instance Tbe of the time-zone of the back-end. To automatically perform the time-zone shifting a rewind-offset RWoffs may be calculated as follows:

The rewind offset at timestamp Tl equals the broadcaster's time in the broadcaster's time-zone (Tbc) minus the client device's time in client device's time-zone (Tcl). Given the above expressions for Tbc and RWoffs, the indexed starting point of the back-end playback time Tbepb for the requested linear broadcasted channel may be calculated as follows :

wherein x represents the hours difference between the broadcaster's and the client device's time-zones and x>=l.

This means that for any given timestamp Tl and any given broadcasted channel in a time-zone that is ahead of the client device's time-zone, the calculated content playback starting point Tbepb for content stored in the back-end equals the time in the back-end's time-zone minus "the positive time difference between the broadcaster's and client device's time-zones" .

The time reference Tbcpb of the broadcaster's content that was stored at that time Tbepb in the back-end may be calculated as follows:

Hence, for any given timestamp T1 and any given broadcasted channel in a time-zone that is ahead of the client device's Time-zone, the calculated time reference of the broadcaster's content Tbcpb selected as starting point for playback in the back-end by means of the time Tbepb eguals the time in the client device's time-zone Tcl . In that case, for the receiving client device, it will now seem as if the presented 'broadcasted content' is synchronized with his own time-zone: the broadcasted channel's transmitted content has been time-zone-shifted to the client device's time-zone. Technically, the back-end storage system jumps to the stored and indexed point Tbepb for this linear broadcast channel and starts to play back the broadcaster's stored content (from broadcaster's time Tbcpb = client device's time TCl) to the Content Delivery Network .

In a third situation, the time in the broadcaster's time-zone Tbc is 'earlier' than the time in the client device's time-zone Tcl for a timestamp Tl, i.e.: Tbc<Tcl . From the client device's time-zone perspective at time Tcl, the broadcasted content has not yet been transmitted nor stored in the backend and this for one to multiple hours to come because the broadcaster's transmission is in a time-zone that is lagging (or running behind) the client device's time-zone. As the reguested content at time Tcl was not yet transmitted when referenced in the broadcaster's time-zone and therefore not yet stored in the back-end, the content from the day before at time Tcl will be presented. For Timestamp Tl is then valid: Tbc = Tcl - x hours; x being > 1). In that case, the rewind-offset RWoffs may be expressed as follows:

Hence, when compared to the situation wherein Tbc>Tcl, in this case an extra day (24 hours) needs to be added to the rewind offset to reflect the linearly broadcasted content from the day before which was already stored on the back-end storage system. The requested back-end playback time Tbepb may then be calculated by the ATS function as follows:

wherein x is the hours difference between the Broadcaster's and the client device's time-zones and x > 1. This means that for any given timestamp T1 and any given broadcasted channel in a time-zone that is lagging the client device's time-zone, the calculated content playback starting point stored in the back-end equals the time in the back-end's time-zone plus "the positive time difference between the broadcaster's and client device's time-zones" minus 24 hours.

The time reference Tbcpb of the broadcaster's content that was stored in the back-end may be calculated as follows:

In other words, for any given timestamp T1 and any given broadcasted channel in a time-zone that is lagging the client device's time-zone, the calculated time reference of the broadcaster's content Tbcpb selected as starting point for playback from the broadcaster's stored content in the back-end by means of the time Tbepb equals the time in the client device's time-zone Tcl from the previous day. Hence, for the receiving client device, it will now seem as if the presented 'broadcasted content' is synchronized with his own time-zone but with content from the day before.

The broadcasted channel's transmitted content has been time-zone-shifted to the client device's time-zone with an extra day difference. Technically, the back-end storage system jumps to the stored and indexed point Tbepb for this linear broadcast channel and starts to transmit the stored content (from broadcaster's time Tbcpb = client device's time Tcl from the day before) to the content delivery network.

Once the back-end playback time for the requested content is determined in the above-described manner, the content request comprising the calculated back-end playback time Tbepb may be forwarded to the storage module of the backend (step 228), which may use the determined back-end playback time as starting point of the transmission of the requested linear content (step 230). In that storage, at that specific calculated back-end time Tbepb for the requested broadcast content, the broadcast time reference is Tbcpb with Tbcpb = TCp -24h as calculated above.

In the automated time-zone shifting mode as described above with reference to Fig. 2, the Electronic Program Guide (EPG) data available on the client device may be adapted on the basis of the rewind offset RWoffs (as calculated above) for each individual linear broadcasted channel. This may be performed so that the EPG data reflect the events that are being played back from storage (or also in the case of live linear broadcast where the RWoffs = 0) with broadcaster playback time reference Tbcpb for each individual channel and with the client device's time Tcl as the offset (reference of what is playing 'now' from the perspective of the user at the client device time).

Time shifting of the EPG data may be realized as follows. The EPG metadata (XML data e.g.) available for each broadcasted channel comprise date and time information for each event that is being broadcasted. When referring to EPG data on a user interface of the client device, the client device time Tcl is used as reference to display the EPG data on the screen, e.g. events running at Tcl - X minutes to events running until Tcl + X minutes (wherein X represents number of minutes chosen by the back-end operator for good user interface experience).

The broadcaster playback reference time Tbcpb is what is currently playing or what would be played out if the client device selects any channel in the automated time-zone shifting mode. Therefore, each channel presents its event's EPG data with reference Tbcpb - X Minutes to Tbcpb + X minutes. As soon as the client device requests this information the back-end will automatically download the correct EPG data from the time in the past (or current EPG in case of live linear viewing). For channels where Tbcpb was calculated from the previous day an indication in the user interface may be shown next to the broadcaster channel name or icon to indicate that the event data presented in the grid is from the day before.

Hence, from the above, it follows that during the process as described with reference to Fig. 2, per client ATS time information associated with the ATS function may be stored in the time-shift database of the back-end, wherein the time information may include: - a parameter indicating the client time of the client device in its time-zone (further referenced as Tcl) ; - a parameter indicating the broadcast time of the requested broadcasted channel in its time-zone (further referenced as TBc) ; - a parameter referring to the number of hours content is time shifted (further referenced as yx'); - a parameter indicating a rewind offset in the back-end for calculating an indexed starting point for playback of stored (linear) content (further referenced as RWoffs ) ; - a parameter indicating the time in the back-end in its time-zone (further referenced as Tbe) - the time instances TBc, TBe and TCl at any given timestamp T1 - a parameter indicating a back-end playback starting point for playback of stored content for a particular channel and for a particular client device from back-end time offset perspective (further referenced as Tbepb) ; - a parameter indicating a broadcaster content playback starting point for playback of stored content for a particular channel and for a particular client device from broadcast time offset perspective (further referenced as Tbcpb)

The automated time-zone shifting function as described with reference to Fig. 1 and 2 above, may be implemented as an over-the-top (OTT) service for content delivery to client devices. In whatever time-zone a client device is located, the function delivers linear content in accordance with the time in the time-zone in which the client device is located. In a first example, a live stream on the Olympics that is broadcasted in Germany at 8 am, may be delivered to client devices requesting the live stream at 8 am irrespective in which time-zone the client devices are located thereby substantially increasing the user experience of users that travel through different time-zones. In another second example, an end user with Belgian Nationality and normally residing in Belgium and having his own favourite Belgian channels travels to Toronto, Canada with his client device and subscribed to the service. He now enters his room with internet connection (or if none available connection on the mobile networks with 4G e.g. can be considered) at 21:00 hours (9 pm) and wants to start watching one of his own favourite Belgian channels, so he tunes to such a channel. The selected broadcaster is a Belgian broadcaster with Belgian time-zone references. Without the automated time-zone shifting function, the end user sees at 9 pm in Toronto what his selected channel is broadcasting live at that same moment, being what is broadcasted at 3 am at night in Belgium as the time-zone in Toronto Canada is 6 hours earlier than the time-zone in Belgium. However, the end user activates the ATS function and the ATS invention detects automatically the time-zone the client device is in, calculates the rewind offset to find the automated time-zone shifted starting point of the selected broadcaster's content and instructs the back-end to start playing the content from that point onwards, so 6 hours earlier. With ATS enabled, the broadcaster playback time is no longer 3 am at night, but is now automatically redirected to 9 pm in the evening from the previous day, being still the day the end user is residing in Canada, Toronto. In other words, for this end user it is now as he were watching in Belgium, so without any time-zone differences.

It is submitted that in another embodiment the calculating logic may also be on the client device's side (instead of the network side). Communication and information exchange would follow similar flows as depicted in Fig 2. with the Client Device calculating the required back-end playback times or broadcaster playback times and sending that information to the back-end to retrieve the content from the correct and automatically time-zone shifted playback starting point in the Storage Servers. This embodiment is described in more detail with reference to Fig. 4 and Fig 5.

Fig. 3 depicts a flow diagram illustrating a method for providing prime time tracking and, optionally, automatic time-shifting services to one or more client devices according to an embodiment of the invention. In particular, Fig. 3 depicts a flow diagram illustrating a method for tracking prime time events of a television channel (Prime Time Tracking or PTT) and transmitting linearly broadcasted content from a starting point in the back-end storage system that is identified by a prime time parameter. The PTT function may be combined with the ATS function as described with reference to Fig. 2. The method may be implemented as an operator service between the back-end (e.g. a server in the back-end of a service operator) and one or more client devices as described with reference to Fig. 1.

The process of Fig. 3 may include ingestion of content associated with different broadcasts, e.g. live broadcasts, originating from one or more broadcasters. For example, in steps 302-306 of Fig. 3 (multi)media content & data associated with different live streams may be ingested in a similar way as described with reference to Fig. 2. During ingest the back-end may also receive metadata associated with the ingested content including the broadcast time Tbc and EPG data (step 308) .

Additionally, the back-end may receive one or more prime time parameters PTchi-3, wherein a prime-time parameter PTch may represent an important viewing time of the day (prime time) for a predetermined television channel from the broadcaster (channel) point of view (see steps 302-306). In an embodiment, the parameter may be delivered to the client device by inserting such information to the XML data of metadata providers (for example EPG information). In another embodiment, the parameter may be inserted as Event Information in the broadcasts stream, (e.g. as EIT P/F data (Event Information Table Preset/Following) and/or the Broadcaster's EIT-schedule (Event Information Table Schedule) as known from television standards such as e.g. DVB standards or the like.

Similar prime-time parameters PTcl and PTbe may be provided to the back-end indicating the most important viewing time of the day (prime time) for a television channel from the perspective of a client device and the back-end respectively. The prime-time parameters may have a default value. Further, the prime-time parameters comprising information on the prime time periods may be provided in any type of format including (text) strings, arrays or enumeration fields, integers, HH:MM:SS format, XML-format, etc.

Different priorities may be assigned to the different prime-time parameters PTcl, PTbe, PTch. In particular, depending on the priorities set in the back-end, one of the prime time parameters may have priority over the others. For example, if PTcl has priority then the prioritized prime time parameter PT = PTcl, if PTbe has priority then PT = PTbe, if PTch has priority then PT = PTch. The non-prioritized prime time parameters may be ignored or may be used for other purposes. The prioritized and non-prioritized prime time parameters may be stored in the time-shifting database.

Similar to the process in Fig. 2, one or more client devices may register to the back-end (steps 310-312). During or after the registration process, the back-end may determine whether a client device has access to an automated prime time tracking (PTT) service. Such service may be configured to -for example - automatically time-shift content that is broadcasted at prime time in the time-zone of a broadcaster wherein the time-shifting is determined such that the content is transmitted to the client device at prime time in the time-zone of the client device. The back-end may check whether the PTT function is set to "ON" for a registered client device (step 314). To that end, messages sent by the client device to the back-end may include a PTT indicator, e.g. a flag or the like, for indicating whether the client device has access to the ATS function.

Once the client device is registered with the backend, it may receive metadata, e.g. EPG data, associated with content that can be accessed via the back-end (step 316).

The client device may use the EPG data to select content (step 318) and to send a reguest message comprising an identifier of the selected television channel (step 320) to the back-end. Thereafter, the back-end may invoke the PTT function and, optionally, the ATS function in order to automatically time-shift the reguested content on the basis of the time information in the time-shift database.

The PTT function may check whether the reguested content is present on the whitelist or blacklist (step 322).

If the reguested content is blacklisted the PTT function may be disabled for the reguested content. Alternatively, if the reguested content is not on the whitelist, the PTT may be disabled.

In case the time-shifted services are allowed on the basis of the whitelist and/or blacklist, the determined (prioritized) prime time parameter PT may be used for the calculation of the back-end playback index Tbepb and/or the calculation of the broadcaster playback index Tbcpb which are used to identify from which point in time the television broadcast should be played back.

The back-end system has access to the ATS and PTT setting information as described above with reference to Fig. 1 wherein the setting information may either be locally stored in the back-end system or retrieved from a client device.

The back-end system may also have access to account information (User Name, password, etc.) and a network address, e.g. an IP Address, of the client device.

Further, per client PTT time information associated with PTT function may be stored in the time-shift database of the back-end, wherein the time information may include: - a prime-time parameter PTcl indicating a specific date and/or time associated with the client device; - a prime-time parameter PTbe indicating a specific date and/or time associated with the back-end; - a prime-time parameter PTch indicating a specific date and/or time set by the broadcaster for one or more television channels; - a prime-time parameter PT which will be set to either PTcl, PTbe or PTch depending on which has a higher priority . - a parameter PToffs (Prime Time Offset) (e.g. expressed in HH:MM:SS but other formats may apply) used to calculate a time-window which functions as a threshold to identify if jumping to the defined prime time should take place or not for a given channel. This parameter may also be used by the back-end (and/or client device) to calculate an indexed starting point for playback of stored (linear) content in relation to a particular time per channel being defined as "prime time" by either broadcaster, back-end or client device's parameters; - a parameter Tbepb_lk indicating the last known back-end playback time for a given channel and a client device; - a parameter Iabm associated with a client device indicating an Automated Bookmark Index for a channel indicating which content or part of en event was being transmitted last;

These parameters and their use are described hereunder in more detail. The transmission of linear broadcasted content may depend on whether the ATS and/or PTT functions are activated.

In a first embodiment, both the ATS and PTT function may be activated. In that case, the linear broadcasted content selected by the client device may be transmitted by the backend from the indexed starting point Tbepb of the storage for this channel representing the prime time as defined by the prime time parameter PT that may be determined by prioritizing one of the parameters PTCl, PTBe or PTCh.

The back-end playback time Tbepb may be calculated on the basis of the relation between broadcaster's time Tbc, the back-end time Tbe and the prime time parameter PT as stored in the time-shift database (steps 324 and 326). The following situations can be distinguished:

In a first situation, at given timestamp Tl, the time in the broadcaster's time-zone Tbc is greater than or equal to the prime time PT minus the prime time offset PToffs and is smaller than or equal to the prime time PT plus the prime time-offset PToffs (i.e. PT-PToffs — Tbc — PT + PToffs) ·

The linear broadcasted content is returned by the back-end as it is being live-transmitted by the broadcaster.

The back-end playback time Tbepb is equal to the actual back-end time Tbe (Tbepb = TBe) . In that case there is no need to playback from stored content as such, so therefore also the broadcaster playback time Tbcpb may be set to TBc. The back-end systems for live transcoding and live encryption will pass their signal for segmentation payload preparation from where it is passed onto a content delivery network (CDN) for transmission to the client device. The content transmitted at broadcaster's time Tbc is received at the client device at time Tcl . Time-zone differences may be noticeable for a user.

In a second situation, at a given timestamp Tl, the time in the broadcaster's time-zone Tbc is greater (later) than the prime time parameter PT plus the prime time-offset PToffs (i.e. Tbc > PT + PToffs) . The back-end playback time Tbepb for a given linear broadcasted content may be expressed in terms of TBE and a rewind offset

as follows:

The back-end playback time Tbepb may then be used as a reference to find the indexed starting point in the stored linear content. The time reference of the broadcaster's content Tbcpb that was stored at that time Tbepb in the back-end can then be calculated as follows:

In other words, for any given Timestamp T1 and any given broadcasted channel for which the broadcaster's actual time Tbc is greater than prime time PT plus the prime time offset PToffs, the calculated time reference of the broadcaster's content Tbcpb (selected as starting point for playback in the back-end by means of the time Tbepb) equals the prime time PT. For the user it will now seem as if the presented broadcasted content is starting exactly at the prime time as set by the parameter PT. Technically, the back-end jumps to the stored and indexed point Tbepb of the linear broadcast channel and starts to transmit the stored content (from broadcaster's time Tbcpb = prime time PT) to the CDN.

In a third situation, at any given timestamp Tl, the time in the broadcaster's time-zone Tbc is smaller (earlier) than the prime time PT minus the prime time offset PToffs (i.e. Tbc < PT - PToffs) ·

The back-end playback time Tbepb for a given linear broadcasted content may be expressed in terms of Tbe and a rewind offset RWoffs = Tbc - PT + 24 hours as follows:

This back-end playback time Tbepb may be used as a reference to find the indexed starting point in the stored linear

Broadcasted content for the given linear broadcast content.

The time reference of the broadcaster's content Tbcpb that was stored at that time Tbepb in the Back-end can then be calculated as follows:

Hence, for any given timestamp T1 and any given broadcasted channel for which the broadcaster's actual time Tbc is smaller than the prime time PT minus the prime time offset PToffs, the calculated time reference of the broadcaster's content Tbcpb (selected as starting point for playback in the back-end by means of the time Tbepb) equals the prime time PT minus 24 hours. In other words, for the client device, it will now seem as if the presented 'broadcasted content' is starting exactly at the prime time as set by the parameter PT but with the content from exactly 1 day earlier. Technically, the back-end jumps to the stored and indexed point Tbepb which is the prime time PT from the previous day for this linear broadcast content and starts to transmit the content (from broadcaster's time Tbcpb = PT - 24 hours) to the CDN.

In a second embodiment, only the PTT function may be activated while the ATS function is disabled. In that case, the linear broadcasted content selected by the client device may be transmitted by the back-end from the indexed starting point Tbepb of the storage for this channel representing the prime time as defined by the prime time parameter PT that may be determined by prioritizing one of the parameters PTcl, PTbe or PTch.

In that case, at each channel change or when this setting is selected, the linear broadcasted content is transmitted by the back-end from the indexed starting point Tbepb of the storage for this channel representing the prime time as defined by the prime time parameter PT (as set by and prioritized by one of the parameters PTcl, PTBe or PTch) . Depending on the relation between broadcaster's time Tbc and the set prime time PT, back-end playback time Tbepb may be calculated in a similar way as described above.

In particular, in case PT-PT0ffs d TBc d PT+PT0ffs the linear broadcasted content is returned by the back-end as it is being live-transmitted by the broadcaster. The back-end playback time Tbepb is equal to the actual back-end time TBe (Tbepb = Tbe) .

In case Tbc > PT + PToffs the back-end playback time can be expressed as Tbepb = Tbe - RWoffs = Tbe - (TBc - PT) in a similar way as described above with reference to the case where the ATS function is activated.

In case TBc < PT - PToffs the broadcaster has not yet reached the set prime time PT for that day. Because the ATS setting is turned OFF, the back-end playback time will be calculated as follows: Tbepb = TBe . The linear broadcasted service (channel) is returned by the back-end as it is being live-transmitted by the broadcaster (= Linear Live Broadcast). The back-end Playback time Tbepb is equal to the actual Back-end Time Tbe: Tbepb = TBe. There is no need to playback from stored content as such, so therefore also the broadcaster playback Time Tbcpb = Tbc. The back-end system for Live Transcoding and Live Encryption may pass their signal for Segmentation Payload Preparation from where it is passed onto a CDN for transmission to the client devices. The content transmitted at broadcaster's time Tbc is received at the client device at time Tcl . Time-zone differences can therefore be noticeable for the user. Content defined as prime time content by the parameter PT is not yet available for that day and therefore is ignored.

Once the back-end playback time is determined as described above, the PTT module may sent the content request comprising the determined playback time to the back-end storage system (step 328) which in response may start transmitting the requested content using the determined backend playback time as starting point of the transmission of the requested linear content (step 330). A broadcaster has an advantage if as many people as possible are viewing the transmitted content during prime time, as - per definition - prime time means the most important time of the day because most people are watching then. If a broadcaster could increase the number of viewers during prime time, the income from publicity could also potentially grow for the broadcaster. For an end user prime time means also that the broadcaster is transmitting his content that is deemed to be most interesting to most viewers. Therefore it is of great interest to both Broadcasters and viewers to be able to automatically align broadcasters' defined prime time to any time a viewer might start watching, in particular the traveling viewer whose personal 'prime time' might be at a complete other time due to different time-zone's for instance.

For example, a Belgian business traveler that traveled to Canada, Toronto, where it is 6 hours earlier than in Belgium. The business traveler has had a long day of work behind him when he enters his (hotel) room with internet connectivity at approx. 22hl0 minutes (10:10 pm). The business traveler has a client device which he connects to the TV and a subscription to the service described in this patent and starts watching at 10:17 pm local time in Toronto. The business traveler selects one of his favorite Belgian channels. ATS and PTT are both OFF at this point. The broadcasted content is the one from 4:17 am the next day as it is already 6 hours later in Belgium compared to the viewer in Toronto, Canada. Instead of the user having to start looking for the most interesting content that selected channel might have to offer, the viewer enables the PTT function. Assuming the broadcaster has set a Prime Time parameter to 7 pm and an Prime time offset of 15 min for that day and for that channel, the exact starting point of the content is calculated automatically as per one of the calculation as described above, so that the 7 pm prime time content as intended by the Broadcaster is transmitted to the business traveler's client device, even if he is watching at 10:17 pm. So in this use case where the Broadcaster's actual time is 4:17 am of the next day (6 hours later than in Belgium), the transmitted content is the one that actually was transmitted at the Broadcaster's prime time of 7 pm in Belgium. Viewer and broadcaster are aligned automatically in an instant by selecting one function on the client device. If such a viewer would then also check the EPG data, then this data would be aligned in the User Interface of the client device to the exact content that is being transmitted as will be outlined further down in this patent. A combination of different prime time's, different actual broadcaster's transmission times and different settings (including whitelist / blacklisted channels for the PTT or ATS functions) may cover different use cases a viewer could encounter, regardless of the time-zone he is in and regardless of the time he starts to watch. This is the strength and uniqueness of this invention. Special use cases may cover channel changes behavior while PPT setting is on is covered in the following part of this patent.

In a further embodiment, an Automated Bookmark Index (ABM) Iabm may be used. This parameter may be set as follows: when a transmission of a linear channel is stopped (e.g. due to a channel change on the client device) the parameter Iabm (available for each channel) is set to the current (at the time of stopping the transmission) broadcaster Playback Time Tbcpb (which e.g. may be stored as an index on the storage server) from the channel that was transmitted. In other words, Iabm = Tbcpb. For each channel for which the transmission is stopped, the ABM index Iabm may be set and stored in the backend. At the same time the last known back-end playback time is also set: Tbepb_lk = Tbepb.

As to avoid that a user who is doing several channel changes back and from channels he already selected, would always jump back to the defined prime time when PTT is ON, the back-end system can provide a solution as follows.

While the setting PTT is still unchanged and ON and the user does a channel change away from the current channel (e.g. away from Channel 1) and eventually after a certain time back to that Channel (in our example channel 1) for which the prime time playback was already started earlier, the new broadcaster playback time or Index for that channel 1 will be equal to where the last transmission stopped (Iabm) plus the elapsed time between the last stop of the transmission and the restart of the transmission for such channel (in our example Channel 1) . The elapsed time is then: TBe - TBepb_lk (with TBEpB_lk being the back-end last known play back time) and the new broadcaster playback time will be:

Wherein TBE < TBEpB_lk in order to compensate for a new day that started at Back-end side after the elapsed time (23:59 turning into 00:00 one minute later, but going into the next day). Deactivation of the Prime Time Tracking (PTT = OFF) and reactivating it (PTT = ON) will trigger a recalculation of the back-end playback time or Index (TBBpB) and the broadcaster playback time or Index (Tbcpb) and for any given channel that is being transmitted to a specific client device as described above .

In the PTT prime time tracking mode, the Electronic Program Guide (EPG) data available on the client device will also be adapted with the rewind offset RWoees for each individual linear broadcasted channel. This is done so that it reflects the events that are being played back from storage (or also in the case of live linear broadcast where the RWoees = 0) with broadcaster playback time reference TBcpB for each individual channel and with the client device's time Tcl as the Offset (reference of what is playing 'now' from user perspective at client device's time).

This may be done as follows: the EPG (XML) Metadata available for each broadcasted channel has date / time information for each event that is being broadcasted. When referring to EPG data on the user interface of the client device, the client device time Tcl is used as reference to show the data on the screen: events running at Tcl - X minutes to events running until Tcl + X minutes (with X being number of minutes chosen by the back-end operator for good user interface experience).

The broadcaster playback reference time Tbcpb is what is currently playing or what would be played out if the client device selects any channel in prime time tracking mode. Therefore, each channel's EPG data is presented from the events running from time Tbcpb - X minutes to Tbcpb + X minutes. As soon as the client device requests this information the back-end will automatically download the correct EPG data from the time in the past (or current EPG in case of live linear viewing). For channels where the broadcast playback reference time Tbcpb was calculated from the previous day an indication in the User Interface can be shown next to the broadcaster channel name or icon to indicate that the event data presented in the grid is from the day before.

Although the services described with reference to Fig. 1-3 are described as network implemented services, the invention is not limited thereto. Fig. 4 and 5 hereunder describe client devices that are configured to execute at least part of the time-shifting functionalities as described with reference to Fig. 1-3.

Fig. 4 depicts a remote control unit and a client device configured for requesting (automated) time-shifted content from a back-end server system according to an embodiment of the invention (400). In particular Fig. 4 depicts a client device module 402 adapted to connect to a back-end server system as e.g. described with reference to Fig. 1. The client device module may be implemented in a suitable hardware device, e.g. an HDMI stick, STB, smart phone, electronic tablet, smart TV, etc., which is configured for receiving and processing content from the back-end such that it can be rendered on a display system.

The client device module may comprise a microcontroller (CPU) 404 connected to a memory 405 for executing software code associated with software applications that are stored in the memory.

In order to allow a user to connect to the Internet or a CDN wirelessly by means of a wireless interface 412 (e.g. a WiFi module or the like) and, optionally, a wired interface 414 (e.g. an Ethernet port). Further, in an embodiment, the client device module may be configured to connect a media processing or display device, e.g. a television set, video projector, Blu-Ray recorder etc. by means of a suitable media processing device interface 416, like for instance (but not limited to) an HDMI interface according to one of the HDMI Interface standards (or with slight customized modifications if so required).

In some variants, the client device module may comprise a remote control interface for receiving and executing remote control unit (RCU) commands originating from a remote control device 418. The RCU interface 419 may comprise a bi-directional communication module, e.g. RF, Bluetooth, WiFi or IR communication module. In some embodiment, the remote control module may be implemented on a (mobile) device, e.g. a smartphone or an electronic tablet.

In this particular embodiment, at least part of the ATS and/or PTT functionality may be implemented in the client device. For example, in an embodiment, the microcontroller 404 may be further connected to an ATS module 406 and/or PTT module 408 connected to a time-shift database 410 comprising parameters that are needed for execution of the ATS and PTT services. The ATS and PTT modules are configured to execute methods as described with reference to Fig. 2 and 3 respectively. Hence, when connecting to the back-end, the client device may be used to request linear content from the back-end, wherein the content request may comprise a back-end playback time parameter Tbepb for the requested stored linear broadcast content. When the back-end receives the request it may use the back-end playback time Tbepb in order to determine the video transmission starting point in the stored linear broadcasted content.

In some embodiment, the client device module may be controlled by a remote control unit that comprises a microcontroller 420 connected to a user interface (UI) 422, and an RCU Interface 419. The user interface can be simply physical keys or buttons on the RCU, as well as a graphical user interface, for rendering one or more touch sensitive areas 424 on a graphical screen or could be voice controlled for instance. In the case of a graphical UI, it may comprise different touch sensitive areas in order to allow a user to select content and activate and deactivate different time-shifting services. For example, in an embodiment, a touch sensitive area 424 may be associated with a button for activating or deactivating the time-shift services such as ATS and PTT. Alternatively, a touch sensitive area may allow a user to toggle easily between Prime-Time tracking, Auto Time-Zone Shifting and Linear Live Viewing. Further touch sensitive areas may represent buttons for navigation and selection in an EPG.

Fig. 5 depicts a block diagram illustrating an exemplary data processing system that may be used in a computing system as described in this disclosure.

As shown in Fig. 5, the data processing system 500 may include at least one processor 502 coupled to memory elements 504 through a system bus 506. As such, the data processing system may store program code within memory elements 504. Further, the processor 502 may execute the program code accessed from the memory elements 504 via a system bus 506. In one aspect, the data processing system may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that the data processing system 500 may be implemented in the form of any system including a processor and a memory that is capable of performing the functions described within this specification.

The memory elements 504 may include one or more physical memory devices such as, for example, local memory 508 and one or more bulk storage devices 510. The local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system 500 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from the bulk storage device 510 during execution.

Input/output (I/O) devices depicted as an input device 512 and an output device 514 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, or the like. Examples of output devices may include, but are not limited to, a monitor or a display, speakers, or the like. Input and/or output devices may be coupled to the data processing system either directly or through intervening I/O controllers.

In an embodiment, the input and the output devices may be implemented as a combined input/output device (illustrated in Fig. 5 with a dashed line surrounding the input device 512 and the output device 514). An example of such a combined device is a touch sensitive display, also sometimes referred to as a "touch screen display" or simply "touch screen". In such an embodiment, input to the device may be provided by a movement of a physical object, such as e.g. a stylus or a finger of a user, on or near the touch screen display . A network adapter 516 may also be coupled to the data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and/or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and/or networks to the data processing system 500, and a data transmitter for transmitting data from the data processing system 500 to said systems, devices and/or networks. Modems, cable modems, and Ethernet cards are examples of different types of network adapter that may be used with the data processing system 500.

As pictured in Fig. 5, the memory elements 504 may store an application 518. In various embodiments, the application 518 may be stored in the local memory 508, the one or more bulk storage devices 510, or apart from the local memory and the bulk storage devices. It should be appreciated that the data processing system 500 may further execute an operating system (not shown in Fig. 5) that can facilitate execution of the application 518. The application 518, being implemented in the form of executable program code, can be executed by the data processing system 500, e.g., by the processor 502. Responsive to executing the application, the data processing system 500 may be configured to perform one or more operations or method steps described herein.

In one aspect of the present invention, the data processing system 500 may represent a module or a device as described herein. In another aspect, the data processing system 500 may represent a client data processing system. In that case, the application 518 may represent a client application that, when executed, configures the data processing system 500 to perform the various functions described herein with reference to a "client". Examples of a client can include, but are not limited to, a personal computer, a portable computer, a mobile phone, or the like.

Various embodiments of the invention may be implemented as a program product for use with a computer system, where the program(s) of the program product define functions of the embodiments (including the methods described herein). In one embodiment, the program(s) can be contained on a variety of non-transitory computer-readable storage media, where, as used herein, the expression "non-transitory computer readable storage media" comprises all computer-readable media, with the sole exception being a transitory, propagating signal. In another embodiment, the program(s) can be contained on a variety of transitory computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., flash memory, floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored. The computer program may be run on a processor .

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the implementations in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present invention. The embodiments were chosen and described in order to best explain the principles and some practical applications of the present invention, and to enable others of ordinary skill in the art to understand the present invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

A method for sending automated time-zone-shifted content, preferably through a back-end system, to one or more client devices comprising: receiving a content request from at least one client device, the request containing a content identifier includes for identifying (stored) linear content; determining or receiving a client time Tcl associated with the client device, wherein the client time is indicative of the time in the time zone in which the client device is located; a broadcast time Tbe indicative of the time in the time zone in which the back-end server is located; determining a back-end playback time Tbepb for the requested (stored) linear content on the basis of the client time TCl, the broadcasting time TBc and the back-end time Tbe, "and sending the requested linear content to the client device on the basis of of the determined back-end playback time Tbepb, preferably the back-end playback time that is used to determine the starting point of the transmission of the requested (stored) linear content.

Method according to claim 1, wherein the client time is determined based on location information associated with the client device, preferably the location information that includes an IP address of the client device and / or geolocation information from the client device.

The method of claims 1 or 2, wherein the client time is received from the client device wherein said client device is arranged to display a graphical user interface to enable a user to view the current time of the time zone in which the client device is located configure.

The method of any one of claims 1 to 3, wherein said method further comprises: receiving a registration request including a client device identification; storing a client device identification associated with said client device, the client time TCl; the broadcast time TBc and the back-end time TBe in a storage medium of the back-end system.

The method of any one of claims 1 to 4, wherein determining a back-end playback time TBEPB further comprises: comparing a back-end playback time Tcl with the broadcasting time TBc; and, setting the back-end playback time TBEPB: to the back-end time TBe if the broadcast time TBC is substantially equal to the client time TCl; on TBE - (TBC - Tcl) if the broadcast time TBC is greater (later in time) than the client time TCl; and, on TBE - (TBC - Tcl) - T24 if the broadcast time TBc is shorter (earlier in time) than the client time Tcl, where T24 represents a 24-hour period.

The method according to any of claims 1 to 5, wherein the request for content comprises a time shift indication for signaling to the back-end to send the requested linear content in accordance with the back-end playback time Tbepb.

The method of any one of claims 1 to 6, comprising: determining or receiving a whitelist comprising one or more content identifications of stored linear content for which time-shifted content is permitted; or, a blacklist comprising one or more content identifications of stored linear content for which time-shifted transmission is not permitted; determining whether said requested content can be sent based on the content identification in said content request and the one or more content identifications in said white list or said black list.

A method for sending automated time-shifted content, preferably a back-end system, to one or more client devices, comprising: receiving a content request from at least one client device, the request comprising channel for identifying ( stored) linear content associated with a television channel; determining or receiving a prime time parameter PT associated with said television channel, the prime time parameter PT being indicative of the prime time as defined by a broadcasting organization, the back-end system, or a client device; and, a prime time offset parameter PToffs associated with said television channel for defining a time window PT-PToffs to PT + PToffs for determining whether a real-time or time-shifted broadcast of the prime-time content should take place for a given channel; and, a broadcast time Tbc indicative of the time in the time zone in which the requested content is broadcast; and, a back-end time Tbe indicative of the time in the time zone in which the back-end server is located; and, determining or receiving a back-end playback time Tbepb for the requested (stored) linear content based on the prime time parameter PT, the prime time offset parameter PToffs, the broadcast time Tbc and a backend time Tbe; and, sending the requested linear content to the client device based on the determined backend playback time Tbepb, wherein preferably the back-end playback time Tbepb is used to determine the starting point of the transmission of the requested (stored) linear content.

The method of claim 8, wherein the prime time parameter PT is determined based on a prime time parameter PTcl associated with the client time, a prime time parameter Tbc associated with the broadcasting organization and / or a prime time parameter Tbe that is associated with the back end.

The method of claims 8 or 9 wherein determining a back-end playback time Tbepb further comprises: comparing the prime time parameter PT with the broadcast time Tbc; and, setting the back-end playback time Tbepb: at the back-end time Tbe if the broadcasting time Tbc satisfies

on Tbe ~~ (Tbc ~~ PT) if Tbc> PT + PToffs; and, on Tbe - (Tbc - PT) - T24 if Tbc <PT - PToffs, where T24 represents a time span of 24 hours.

A method according to any of claims 1 to 7 or claims 8 to 10, further comprising: receiving metadata, preferably metadata comprising electronic program (EPG) data associated with one or more television channels wherein said metadata includes a time schedule indicative of when one or more programs from a television channel will be broadcast; determining a playing time Tbcpb of a broadcasting organization for the requested (stored) linear content based on the client time Tcl and the broadcasting time Tbc and related to the back-end playing time Tbepb; and, displaying at least a portion of said time schedule based on the playing time Tbcpb of the broadcasting organization, preferably showing which programs are to be broadcast in an interval defined on the basis of Tbcpb, more preferably said time interval defined by Tbcpb - X minutes to Tbcpb + X minutes.

A back-end server system adapted to send automated time-shifted content to one or more client devices, comprising: at least one computer-readable storage medium in which computer-readable code is embodied, and at least one microprocessor that is coupled to the computer-readable storage medium, wherein responsive to executing the computer-readable program code, the microprocessor is arranged to perform executable operations, comprising: receiving a content request from at least one client device, the request including a content d identification includes identifying stored linear content; determining or receiving a client time Tcl associated with at least one client device, wherein the client time is indicative of the time in the time zone in which the at least one client device is located; and, a broadcast time Tbc indicative of the time in the time zone in which the requested content is broadcast; and wherein a back-end time Tbe is indicative of the time in the time zone in which the back-end server is located; and / or, determining or receiving a prime time parameter PT, wherein the prime time parameter PT is indicative of the prime time as defined by either broadcasting organization, back-end or client device; and, a prime time offset parameter PToffs for defining a time window PT-PT0ffs to PT + PT0ffs for determining whether a real-time or time-shifted transmission of the prime time content should take place for a given channel; determining a back-end playback time Tbepb for the requested (stored) linear content on the basis of the client time TCl, the broadcasting time TBc, the back-end time Tbe, and / or, on the basis of the prime time parameter PT and the prime time offset PToffs parameter; and, sending the requested linear content to the client device based on the determined backend playback time Tbepb, wherein preferably the back-end playback time Tbepb is used to determine the starting point of the transmission of the requested (stored) linear content.

The back-end server system of claim 12, wherein the executable operations further comprise: receiving metadata, preferably metadata comprising electronic program (EPG) data associated with one or more television channels, said metadata being a include a time schedule that is indicative of when one or more programs from a television channel are to be broadcast; determining a playing time Tbcpb of a broadcasting organization for the requested (stored) linear content based on the client time Tcl and the broadcasting time Tbc and related to the back-end playing time Tbepb; and, displaying at least a portion of said time schedule based on the playing time Tbcpb of the broadcasting organization, preferably showing which programs are going to be broadcast in a time interval defined on the basis of Tbcpb, more preferably said time interval defined by Tbcpb - X minutes to Tbcpb + X minutes.

A back-end server according to claim 12 or 13, comprising: determining whether said requested content can be sent based on said back-end playback time based on the content identification in said content request and one or more content identifiers in a white list or a black list, wherein the white list comprises one or more content identifiers of stored linear content for which time-shifted transmission is permitted; and, wherein the blacklist includes one or more content identifiers of stored linear content for which time-shifted transmission is not allowed.

A client device adapted to request automated content from a back-end server system, comprising: at least one computer-readable storage medium with computer-readable program code embodied therewith, and at least one microprocessor coupled to the computer-readable storage medium, wherein responsive to executing the computer-readable program code, the microprocessor is arranged to perform executable operations, comprising: selecting a content identifier associated with (stored) linear content, the linear content associated with a broadcast time Tbc indicative of the time in the time zone in which the content is broadcast; determining or receiving a client time Tcl indicative of the time in the time zone in which the client device is located, and a back-end time Tbe indicative of the time in the time zone in which the back-end storage module is located; and / or, determining or receiving a prime time parameter PT, wherein the prime time parameter PT is indicative of the prime time as defined by either broadcasting organization, back-end or client device; and a prime time offset parameter PToffs for defining a time window PT-PT0ffs to PT + PT0ffs for determining whether a real-time or time-shifted broadcast of the prime time content should take place for a given channel; determining a back-end playback time Tbepb based on the client time TCl, the broadcast time TBc, the backend time Tbe; and / or, based on the prime time parameter PT and the prime time offset parameter PToffs; sending a content request to the backend server system that is arranged to use the back-end playback time Tbepb to determine the video transmission start point for sending the requested (stored) linear content to the client device.